⚠️ kevkevinpal opened an issue: "depriortisetransaction"
(https://github.com/bitcoin/bitcoin/issues/27807)
### Please describe the feature you'd like to see added.
If a user had already prioritized a transaction to be mined there would be no way to get it deprioritized until after this PR
https://github.com/bitcoin/bitcoin/pull/27501 which adds a new RPC call to getpriotisationmap. There should be a way to remove the prioritization entirely and set it to zero without calling two separate RPCs.
### Is your feature related to a problem, if so please describe it.
If a miner wants to deprioritize
...
(https://github.com/bitcoin/bitcoin/issues/27807)
### Please describe the feature you'd like to see added.
If a user had already prioritized a transaction to be mined there would be no way to get it deprioritized until after this PR
https://github.com/bitcoin/bitcoin/pull/27501 which adds a new RPC call to getpriotisationmap. There should be a way to remove the prioritization entirely and set it to zero without calling two separate RPCs.
### Is your feature related to a problem, if so please describe it.
If a miner wants to deprioritize
...
💬 pinheadmz commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574169936)
rpc `prioritizetransaction` can be called with a negative delta already, right?
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574169936)
rpc `prioritizetransaction` can be called with a negative delta already, right?
💬 kevkevinpal commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574172151)
> rpc `prioritizetransaction` can be called with a negative delta already, right?
Yea exactly but that requires the user to track the txid and its delta or after https://github.com/bitcoin/bitcoin/pull/27501 is merged track the txid call getpriotisationmap and then use the negative delta from there
was thinking it would be easier if the user could just specify the txid they want to remove
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574172151)
> rpc `prioritizetransaction` can be called with a negative delta already, right?
Yea exactly but that requires the user to track the txid and its delta or after https://github.com/bitcoin/bitcoin/pull/27501 is merged track the txid call getpriotisationmap and then use the negative delta from there
was thinking it would be easier if the user could just specify the txid they want to remove
💬 willcl-ark commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574177098)
`getmempoolentry` RPC also shows you the modified fee, which includes the priotirization delta (although still requires reverse calculation).
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574177098)
`getmempoolentry` RPC also shows you the modified fee, which includes the priotirization delta (although still requires reverse calculation).
💬 pinheadmz commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574177955)
> was thinking it would be easier if the user could just specify the txid they want to remove
can't you just call prioritisetransaction with txid and, like, `-999999` ?
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574177955)
> was thinking it would be easier if the user could just specify the txid they want to remove
can't you just call prioritisetransaction with txid and, like, `-999999` ?
💬 kevkevinpal commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574181505)
> > was thinking it would be easier if the user could just specify the txid they want to remove
>
> can't you just call prioritisetransaction with txid and, like, `-999999` ?
wouldn't this make the map delta never include that txid, maybe depriortisetransaction isn't the best naming but instead removing any preference on a txid. Removing it from the mapdeltas. Goal is to set the mapdelta for a txid to 0.
maybe `removepriortisation` instead?
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574181505)
> > was thinking it would be easier if the user could just specify the txid they want to remove
>
> can't you just call prioritisetransaction with txid and, like, `-999999` ?
wouldn't this make the map delta never include that txid, maybe depriortisetransaction isn't the best naming but instead removing any preference on a txid. Removing it from the mapdeltas. Goal is to set the mapdelta for a txid to 0.
maybe `removepriortisation` instead?
💬 kevkevinpal commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574182072)
> `getmempoolentry` RPC also shows you the modified fee, which includes the priotirization delta (although still requires reverse calculation).
didn't know that thanks, but ya still reverse calculation still required
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574182072)
> `getmempoolentry` RPC also shows you the modified fee, which includes the priotirization delta (although still requires reverse calculation).
didn't know that thanks, but ya still reverse calculation still required
💬 pinheadmz commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574182839)
> maybe `removepriortisation` instead?
GOTCHA, well maybe instead of a new rpc, maybe `priotirisetransaction <txid> 0` could be a magic word for reset like you want
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574182839)
> maybe `removepriortisation` instead?
GOTCHA, well maybe instead of a new rpc, maybe `priotirisetransaction <txid> 0` could be a magic word for reset like you want
🤔 pinheadmz reviewed a pull request: "Relay own transactions only via short-lived Tor or I2P connections"
(https://github.com/bitcoin/bitcoin/pull/27509#pullrequestreview-1458209334)
concept ACK
Reviewed all code - really great job with this! Very cool idea. I will continue to track this PR and look forward to testing it out more and trying to break the functional tests ;-)
I have a few questions below about implementation
(https://github.com/bitcoin/bitcoin/pull/27509#pullrequestreview-1458209334)
concept ACK
Reviewed all code - really great job with this! Very cool idea. I will continue to track this PR and look forward to testing it out more and trying to break the functional tests ;-)
I have a few questions below about implementation
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214690639)
Just so I understand: this change is required because with the PR we wouldn't send our own TX in response to a `MEMPOOL` message, so you quickly spin up a dummy peer to send the TX to us first. Then we can assert that it was relayed to `fitler_peer` ?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214690639)
Just so I understand: this change is required because with the PR we wouldn't send our own TX in response to a `MEMPOOL` message, so you quickly spin up a dummy peer to send the TX to us first. Then we can assert that it was relayed to `fitler_peer` ?
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214675802)
Why is this extra ping needed for sensitive connections ?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214675802)
Why is this extra ping needed for sensitive connections ?
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214698071)
Super cool idea! Is there common chance for failure here though? This relies on a chain of peers from the sensitive relay node back to us that haven't seen the tx yet.
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214698071)
Super cool idea! Is there common chance for failure here though? This relies on a chain of peers from the sensitive relay node back to us that haven't seen the tx yet.
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214671917)
Why use a funny value here instead of our actual subver? I'm guessing it's for extra anonymity? Could there be any downsides though, like nodes that refuse connections to certain agents?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214671917)
Why use a funny value here instead of our actual subver? I'm guessing it's for extra anonymity? Could there be any downsides though, like nodes that refuse connections to certain agents?
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214678210)
Why disconnect the sensitive connection on PONG? Could that ever happen before we send our tx messages out?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214678210)
Why disconnect the sensitive connection on PONG? Could that ever happen before we send our tx messages out?
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214696791)
nit: don't we usually do this kind of logic in one line?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214696791)
nit: don't we usually do this kind of logic in one line?
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214684616)
I was just about to ask! Wouldn't this only hurt users who don't have sensitive relay available? Maybe `MEMPOOL` requests don't matter so much but wouldn't omitting from `GETDATA` prevent our own TX from being broadcast at all?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1214684616)
I was just about to ask! Wouldn't this only hurt users who don't have sensitive relay available? Maybe `MEMPOOL` requests don't matter so much but wouldn't omitting from `GETDATA` prevent our own TX from being broadcast at all?
💬 kevkevinpal commented on issue "depriortisetransaction":
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574189200)
>
ya that could work and we wouldn't need to add a whole new rpc. That would require us to make the fee_delta param optional and if priotirisetransaction(<txid>, 0) we can check if no fee_delta and the param = 0 we set the map delta to 0
not sure if its forbidden to modify that dummy param not exactly sure it is a dummy param or its history
(https://github.com/bitcoin/bitcoin/issues/27807#issuecomment-1574189200)
>
ya that could work and we wouldn't need to add a whole new rpc. That would require us to make the fee_delta param optional and if priotirisetransaction(<txid>, 0) we can check if no fee_delta and the param = 0 we set the map delta to 0
not sure if its forbidden to modify that dummy param not exactly sure it is a dummy param or its history
💬 ariard commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214696267)
I think this introduces an interdependency between the number of outgoing transaction bytes we can receive from a peer and the maximum flow of LN commitment transaction+CPFP in weight a direct transaction-relay peer can announce to us and therefore we can validate. An `option_anchors_zero_fee_htlc_tx` LN commitment transaction weight is 900 WU with no pending HTLCs. As the orphan memory usage is implemented, it’s unclear if there is any processing guarantees for a peer announcing transaction to
...
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214696267)
I think this introduces an interdependency between the number of outgoing transaction bytes we can receive from a peer and the maximum flow of LN commitment transaction+CPFP in weight a direct transaction-relay peer can announce to us and therefore we can validate. An `option_anchors_zero_fee_htlc_tx` LN commitment transaction weight is 900 WU with no pending HTLCs. As the orphan memory usage is implemented, it’s unclear if there is any processing guarantees for a peer announcing transaction to
...
💬 ariard commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214720397)
If I understand correctly the rate-limiting accounting introduced here, whatever the number of orphan parent missing, there will be an in-flight orphan parent requests issued (i.e if we’re missing 10 parents, we’re going to issue 10 in-flight orphan parent requests).
I think this should be documented as multi-party applications and contracting protocols transactions issuers might have to assemble their packages in function.
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214720397)
If I understand correctly the rate-limiting accounting introduced here, whatever the number of orphan parent missing, there will be an in-flight orphan parent requests issued (i.e if we’re missing 10 parents, we’re going to issue 10 in-flight orphan parent requests).
I think this should be documented as multi-party applications and contracting protocols transactions issuers might have to assemble their packages in function.
💬 ariard commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214712117)
There is a argument that can be made if memory and throughputs limits (e.g `MAX_PEER_ANNOUNCEMENTS`) are applied in function of the type of transactions received (e.g v3 transactions) and that can be used to nudge multi-party and contracting protocols transactions broadcasters to use fee-bumping efficient mechanism such as one CPFP covering multiple parents due to the package limits. This would be a discount incentive by analogy with SegWit spending discounted by consensus validation rules.
O
...
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214712117)
There is a argument that can be made if memory and throughputs limits (e.g `MAX_PEER_ANNOUNCEMENTS`) are applied in function of the type of transactions received (e.g v3 transactions) and that can be used to nudge multi-party and contracting protocols transactions broadcasters to use fee-bumping efficient mechanism such as one CPFP covering multiple parents due to the package limits. This would be a discount incentive by analogy with SegWit spending discounted by consensus validation rules.
O
...