<@jnewbery> I think greenaddress does a really good job of describing the change in the PR post. I'll highlight a few points about the PR and then lets go to questions.
<@jnewbery> 1. "This PR affects policy/relay only." - all transaction replacement policies are policy-only. They're not consensus. That's to say that The BIP125 replacement conditions are only applied when a node decides which transactions to accept to the mempool and relay on to peers.
<@jnewbery> Individual nodes are free to choose their own policy rules, ie which txs to accept and relay. However, it's very useful for wallets to know what other nodes in the network are going to do with transactions, so something like BIP125 is useful so wallets know how to make transactions replaceable.
<@jnewbery> This PR would change the default policy in Bitcoin Core to accept/relay replacement transactions when the original transaction is older than some configurable time
<@jnewbery> 2. There are two changes in this PR - the first is to the mempool policy, and the second is to the wallet, allowing it to bump txs that don't signal BIP125 if they're older than the configurable time
<ariard> "A number of miners will mine transactions regardless of opt-in flags" does this mean miners are overriding policy rules with custom forks of core ?
<@jnewbery> The motivation is that a user might send a transactions without BIP125 signalling and it become stuck for a long time. They want to bump the fee on the transaction but under current policy have no way to do that
<ariard> okay so it may demean user experience with RBF who are trusting than the bumped tx will be enforced, maybe it's an issue for wallet developpers
<jonatack> Do you agree with the last comment by gmax that the change has become sort of pointless, or is it still a definite concept ack like last November?
<Lightlike> do most wallets signal BIP125 (even if they don't implement RBF themselves) or is it opt-in such that basically those who implement it signal it?
<jonatack> gmax march 11: "Subsequently to my earlier comments I now think this is kinda pointless: Testing without RBF set gave me 100% confirmation or replacement rate for very low fee transactions within 20 blocks without the low fee txn rising to being minable by feerate presumably due to restarting nodes, and miners that replace anyways. Is this just motivated by either speculation on actual behaviour without measuring it
<@jnewbery> dmkathayat: a zero-conf transaction is any transaction that has not yet been confirmed in a block. They're not yet covered by any proof-of-work, so there's a risk that a conflicting transaction gets confirmed instead of it
<ajonas> It seems that the author is alone in advocating for the 6hr timeout versus most of the reviewers agreeing on 72 hours. What is the threshold for merging something that is mildly controversial like that?
<@jnewbery> If you do need more than one node, our test framework spins up a network of nodes-under-test. Take a look at setup_network() in test_framework.py
<harding> emzy: to expand on jnewbery's remark, the sendrawtransaction RPC (and the testmempoolaccept RPC) will do the same checks on transactions you pass them as the node would on transactions received over the netwrok, so you can generate replacements and test them with those RPCs.
<harding> (I would personally probably spin up at least two nodes, though, as I wouldn't feel comfortable saying a particularl relay behavior works without actually testing relay.)
<@jnewbery> jonatack: I'm still a concept ACK, because I think it makes expectations clearer. If a transactions has been in the mempool for 72 hours (or even just 6 hours) and it hasn't been confirmed, a malicious actor will be able to get it double spent
<michaelfolkson> My understanding with zero conf transactions was that the introduction of RBF was a step away from relying on them regardless of this PR. Am I missing some subtlety here?
<harding> sosthene: good question! The ultimate answer is that you need to ask the authors of the wallets that haven't enabled it. :-) However, my guess is that few wallets have implemented fee bumping, which does require some work and has some gotchas, and so they haven't bother to even try signaling BIP125.
<@jnewbery> sosthene: the consideration is on how the receiving party will treat that transaction. Merchants who otherwise accept zero-conf txs may not accept those txs if they have RBF signalled.
<@jnewbery> it's worth mentioning that this change makes much more sense in a world with always full blocks. If the mempool ever empties out then even txs with minimal feerates will be included
<michaelfolkson> The fact that only 5% of transactions signal RBF implies that I was wrong to assume that zero conf transactions had been ditched as something to be relied upon. Whatever the advice was from some core devs
<harding> If I may, I think that line of enquiry raises a useful question when looking at PRs: how useful would this actually be? If wallets aren't signaling BIP125 now, it probably means they don't have the tools to make use of RBF, which means that---even if transactions are technically replacable in the mempool---they won't be replaceable through the wallet that created them. How many users
<MaxHillebrand> harding: for example, Wasabi has not yet implemented RBF, mainly because of privacy concerns [RBF signaling decreases anonset and usage reveals change output], as well as development resources and UX clutter...
<fanquake> ajonas if there's no/minimal consensus the PR will likely just stagnate and discussion becomes sporadic/dies out (as it has done here). Any "threshold" for merging is usually hard to define.
<harding> rafeeki: child-pays-for-parent which can always be done by the receiver and can often be done by the spender (whenever there's a change output).
<@jnewbery> michaelfolkson: I'd say zero-conf transactions should never be something to be 'relied on'. Until a transaction is confirmed, it can always be double-spent
<schmidty> harding: I think that by having such a feature in Core, if it is demanded by users, will 1. incentivize users to use Core as a wallet and thus 2. incentivize other wallets/services to implement to keep up
<@jnewbery> It's obviously up to the merchant whether and under what circumstances they accept zero-conf. Bitrefill have obviously decided that they can accept zero-conf up to a certain amount if the tx meets some requirements.
<MaxHillebrand> harding: well, if you don't necessarily need to spend again, and you only generate a child 1 input - 1 output tx to bump overall fee / byte, then you add "unnecessary" tx and bytes to the chain. [well, at least the utxo set says the same in this case].
<harding> Lightlike: CPFP is always possible after the fact, although there are some limits to the maximum number of children in mempool (policy limits) for anti-DoS reasons.
<michaelfolkson> <harding>: RBF is initiated by the sender but CPFP is initiated by the intended recipient. That's the key consideration in comparing them right?
<MaxHillebrand> harding: where actually is that limit? I am thinking that we pumped against the limit of 20 child coin join transactions with Wasabi...?
<MaxHillebrand> harding: thank you!! -limitancestorcount=<n> Do not accept transactions if number of in-mempool ancestors is <n> or more (default: 25) -limitancestorsize=<n> Do not accept transactions whose size with all in-mempool ancestors exceeds <n> kilobytes (default: 101) -limitdescendantcount=<n> Do not accept transactions if any ancestor would have <n> or more in-mempoo
<@jnewbery> If you want to successfully CPFP a transaction, you need to have an idea of other nodes' mempool policies to know whether your tx will propagate
<harding> MaxHillebrand: more importantly, I think jnewbery is trying to communicate that increasing the limit on your node doesn't mean your transactions will propagate to other nodes that haven't increased their limits.
<@jnewbery> jonatack: good observation. Yes, success in getting PRs merged is usually down to keeping momentum up and encourging other contributors to review the PR
<merehap> jonatack: Since it's just a policy change, they probably just implemented in their fork of Bitcoin core, and lost interest in driving the consensus process after a year or so.
<instagibbs> harding, back to your thought experiment about the type of users that would even need the replace after N hours, indeed, I think it's partially to work around the politics of making Core's wallet walletrbf=1 by default...
<@jnewbery> merehap: I don't think that's the case here. 'just' policy downplays the importance of it. It's important for wallet makers to have an idea of what the default policy is on the network
<jonatack> merehap: good point. i suppose anyone motivated could ping the author and propose to take it over, but seems rare in practice. i've only seen jnewbery do that IIRC.
<harding> schmidty: there's no real process for that, except individual devs going out and trying to contact people. The normal process in open source projects is that we try to get companies to hire devs involved in the project so that they can communicate to their bosses about any changes that might affect the business.
<MaxHillebrand> schmidty: I estimate the "issue" of stuck transactions with low fees are existent and painfull for both merchants and users. I remember buying a cold card back when fees were so high, I did not signal RBF, and waited over one month till confirmation... [Was actually great for me, since price wen't down, so I got my hww for cheaper with this free short future :D]
<harding> schmidty: But that hasn't happened as much as I think some of us would've liked, so (as fanquake says) Optech is trying to bridge that gap to a certain extent.
<instagibbs> without trying to derail the discussion further: Any other wallets other than Core that support fee bumping but don't have it on by default?
<fanquake> harding,schmidty: there's definitely space on the repos for more businesses/CTOs etc to come and join development discussion, hopefully that is the case in future.
<Lightlike> what do you think is the likely outcome for this pr? i saw that it was milestoned for 0.19, does that mean it will probably be accepted (possibly with >6h)? Or ist still completely unclear what will happen?
<merehap> jnewbery: But wouldn't greenwallet's full node be relaying their customers' SPV requests such that it does matter what their node's policy is (assuming they expose the new functionality in their SPV wallets)? Assuming other nodes, like miners will already sometimes relay the replacement transaction. I could be misunderstanding of course.
<@jnewbery> michaelfolkson: sure. Like I said at the top, this PR actually makes two changes. One is on mempool acceptance policy, and the other is on wallet feebumping functionality.
<harding> merehap: I think greenwallet already signals BIP125, so implenting this on the node they use to relay transactions for their wallet users wouldn't benefit those users.
<merehap> harding: Makes sense. Seems like there could be a use case for greenwallet having optional RBF then allowing non-RBF replacement after 72 hours or something.
<harding> merehap: ah, indeed that could be nice, but it would require they peer with other nodes willing to relay those replacements (and eventually someone peer with miners willing to mine the replacements).
<merehap> jnewbery: I'm not sure I have anything in particular just from my 30 minutes of understanding the problem. But greenwallet did ask reviewers if there was any test cases that they are missing but I didn't see a reply there.
<merehap> Their comment was "More feedback welcome. I think it would be good to have more tests (ideas?)". Will spend a few more minutes to see if anything comes to me.
<@jnewbery> So the replacement transaction being rejected by the mempool isn't tested (the wallet rejects the feebump before constructing the replacement transaction)
<@jnewbery> Another test could be submitting the replacement transaction over P2P and checking that it's rejected, then moving time forward and checking that it's accepted
<harding> Something that may not be obvious to readers of that test is that setmocktime is a "hidden" RPC that's not displayed in the help overview (you can still request help on it specifically using: bitcoin-cli help setmocktime). I think this will give you a list of all hidden RPCs that you can use in tests: git grep '{ "hidden'