Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote: > For further monitoring, I've set-up a mempoolfullrbf=1 node and are > logging replacement events with [0]. I filter the full-RBF replacements > and list the replaced and replacement transactions here: > https://fullrbf.mempool.observer/ I think it would be helpful to list (a) how long ago the replaced transaction was seen compared to the [full RBF event] timestamp, and (b) particularly for cases where the replaced tx was the one that was mined, how long after the [full RBF event] the block was received. Might be more hassle than it's worth, but you might consider grouping all related replacements together, so that you can see: 2b771b7949e62434bf3002ad0d38f383a29b362cf2dc31627a35a883d0de36c3 [2601.19 sat/vb] 9ce405ab14e8d68c7a43d190414e39564d90bbee21f23020f2ce45136927ce9b [2448.25 sat/vb] 1a5f239e7fc008f337605e0b405579234d0fecebaf6be966000dcfaf0bcb7beb [2295.31 sat/vb] 0500a3ca5e4998fb273be9b51a4c3a75780acf28b23409a54f4260e069441e32 [2142.37 sat/vb] 955623c789eb0a7ca0848ce964325d6b2c7d1731a686d573018f6348de6c00a1 [1989.42 sat/vb] 7838bc60405f9b38a79c94f4f045b8debaf41c0a5acfdeebc6a3904188b2bbc9 [1836.48 sat/vb] 2d5e6b84602d45c5c834e0cad4db4dd8a9142ba7eff6bacdb34a97e5cfacb418 [1683.54 sat/vb] 130851951a1d9270776852491bda3e17bb08b9309e5b76b206633f88a9341604 [1530.60 sat/vb] 3c9b2530c02a22c966fa9ef60ec0acf17bd23a8b0b4c5202589c190ee770c880 [1377,66 sat/vb] 49889043ec7dae7a4f1573c5feaca6a549d88e4fb306cf3b410155ba919da83d [1224.72 sat/vb] 861156e18ae0399cd458c6f7f7faed1a94142db45f1d879b9ae78cb11cd7e96c [1071.78 sat/vb] 961bf21f1fc35edacd4929e8db67b27a52c69a593d32aab5a024757503c0490b [ 918.84 sat/vb] 5cdb24e2ed30dfc55b23820676a9d47d158fec982e77dddadc648280f0b2c914 [ 765.90 sat/vb] 159494115af33b414df77d3965de5eb191b4a3af1c1219509f3175abc5dcd132 [ 612.95 sat/vb] dcf4c0e688ee76188e9ef829d03cc66ee7da404717b9d56d74bcd75708612271 [ 460.01 sat/vb] 1971d9122551a898bcbc5183d4ea79e273dea89aa4075d4e014f8f7dd4eb8321 [ 307.07 sat/vb] c43316d2e4bb12fbb408de01d64c4b480fd7d6875db4ebbf006fdc7579546d13 [ 154.13 sat/vb] 8bbf6a0f3dd8358c6d8a81f0811216d7980288b14daeac82ff2f672ea8e4851d [ 1.19 sat/vb] [mined in 767044] at a glance as a single block (ideally with timestamps). Arguably, that might be interesting to see in general (ie for bip-125 opt-in rbf txs as well), to see how common the "offer a low fee, and raise it over time" approach is in practice. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Sat, Dec 10, 2022 at 12:59:05PM +0100, 0xB10C wrote: > On 12/9/22 22:16, Peter Todd wrote: > >> For further monitoring, I've set-up a mempoolfullrbf=1 node and are > >> logging replacement events with [0]. I filter the full-RBF replacements > >> and list the replaced and replacement transactions here: > > Question: are you taking any special steps to peer that node with other > > full-rbf nodes? I see you are in fact getting all the replacements I'd > > expect > > you to get, so you must have good peering. I'm curious what it took (if > > anything) to achieve that. Also, is that node accepting incoming > > connections? > No special steps like #25600 preferential peering or similar. I suspect > I was lucky to have a full-RBF peer (or more than one) from the start or > there are more mempoolfullrbf=1 nodes than I'd think on the network. The > node accepts incoming connections on a non-default port and currently > has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though, > as older Bitcoin Core version usually don't connect to non-default port > peers. Interesting! I'm running a full-rbf node that is (manually) connected to a few hundred v24.0 nodes to ensure good propagation. But I'm only connected to standard ports (I'm reusing the DNS seed list). So you must have a full-rbf peer purely by luck. Could you please grep your logs for which peer(s) are sending you replacements? I don't want to know the IP addresses. I'm just curious if you have exactly one full-rbf peer or more. BTW I have Antoine's preferential peering patch ported to v24.0, along with a few other minor fixes: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0 I think it'd be reasonable for you to run that, as what's more interesting is the replacements, not whether or not propagation happens to work out of the box. > > https://blockstream.info also enabled full-rbf a few days ago. But currently > > propagation to their nodes is spotty, so replacements don't always show up. > > Since my last post, five full-RBF replacements have been mined in two > blocks: > > 766733 by Luxor: > > 41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa5 1x > P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte) > 3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25 > OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte) > 9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce807 1x > P2WPKH in -> 1x P2WPKH out (22.73 sat/vByte) > 3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093 > OpenTimestamps Bob (108.25 sat/vByte) > > It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7 > days)[0] might have mempoolfullrbf=1 enabled. > > 766736 by AntPool: > > 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 > OpenTimestamps Bob (4.25 sat/vByte) > > I'm not too sure if AntPool has full RBF enabled based on this one > transaction. 3c96fe.. is the first replacement of > 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19 > sat/vByte) which they might not have seen (?). They have nearly 20% of > the network hashrate [0], so if the have mempoolfullrbf=1 set, we should > see them include more full-RBF replacements soonish. There was also > 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which > bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before > AntPool found the block. The might not have seen it yet. So according to my logs the replacement that AntPool mined, 3c96fe813, was the third replacement in a row of four replacements: 2022-12-10T07:46:09Z [mempool] AcceptToMemoryPool: peer=: accepted 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 6320 txn, 90818 kB) 2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 for 0.0234 additional fees, 0 delta bytes 2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 for 0.0234 additional fees, 0 delta bytes 2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f for 0.0234 additional fees, 0 delta bytes There's significant time between tx #2 and tx #3, and the block was found soon after #4 reached my node, so it's quite possible that AntPool was in fact running full-rbf and they simply didn't see #4 in time. Big pools tend to run many different nodes at once, splitting up hash rate between them, so they could be simply running full-rbf on a subset of their hashing power to test it out. I noticed F2Pool mined a few full-rbf replacements a few weeks ago too (they also mined a replacement that appeared to be due to them starting a new
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On 12/9/22 22:16, Peter Todd wrote: >> For further monitoring, I've set-up a mempoolfullrbf=1 node and are >> logging replacement events with [0]. I filter the full-RBF replacements >> and list the replaced and replacement transactions here: > Question: are you taking any special steps to peer that node with other > full-rbf nodes? I see you are in fact getting all the replacements I'd expect > you to get, so you must have good peering. I'm curious what it took (if > anything) to achieve that. Also, is that node accepting incoming connections? No special steps like #25600 preferential peering or similar. I suspect I was lucky to have a full-RBF peer (or more than one) from the start or there are more mempoolfullrbf=1 nodes than I'd think on the network. The node accepts incoming connections on a non-default port and currently has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though, as older Bitcoin Core version usually don't connect to non-default port peers. >> Over the last few days, I has mostly seen OP_RETURN transactions >> (presumably mostly by OpenTimestamps; but I haven't checked closely) and >> a few other non-OP_RETURN transactions. None of the replacement >> transactions have been mined yet. > They are mostly OpenTimestamps transactions; I checked against the records > from > my calendars and didn't find any OP_Return tx that wasn't one of mine. > > The two calendars making full-rbf replacements are: > > https://alice.btc.calendar.opentimestamps.org/ > https://bob.btc.calendar.opentimestamps.org/ > > The status pages currently link to https://mempool.nixbitcoin.org, which is > also running mempoolfullrbf=1 As you can see, I've started the full-rbf bounty > again on Alice. > > https://blockstream.info also enabled full-rbf a few days ago. But currently > propagation to their nodes is spotty, so replacements don't always show up. Since my last post, five full-RBF replacements have been mined in two blocks: 766733 by Luxor: 41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa5 1x P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte) 3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25 OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte) 9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce807 1x P2WPKH in -> 1x P2WPKH out (22.73 sat/vByte) 3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093 OpenTimestamps Bob (108.25 sat/vByte) It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7 days)[0] might have mempoolfullrbf=1 enabled. 766736 by AntPool: 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 OpenTimestamps Bob (4.25 sat/vByte) I'm not too sure if AntPool has full RBF enabled based on this one transaction. 3c96fe.. is the first replacement of 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19 sat/vByte) which they might not have seen (?). They have nearly 20% of the network hashrate [0], so if the have mempoolfullrbf=1 set, we should see them include more full-RBF replacements soonish. There was also 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before AntPool found the block. The might not have seen it yet. I've also updated the site to allow only showing the replacements that were mined. [0]: https://btc.com/stats/pool?pool_mode=week for future reference: https://archive.ph/TARhP OpenPGP_0x188CBB2648416AD5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote: > Hi AJ and list, > > > This seems to be pretty good evidence that we currently don't have any > > significant hashrate mining with fullrbf policies (<0.5% if there was a > > high fee replacement available prior to every block having been mined), > > despite the bounty having been collected. > > For further monitoring, I've set-up a mempoolfullrbf=1 node and are > logging replacement events with [0]. I filter the full-RBF replacements > and list the replaced and replacement transactions here: Question: are you taking any special steps to peer that node with other full-rbf nodes? I see you are in fact getting all the replacements I'd expect you to get, so you must have good peering. I'm curious what it took (if anything) to achieve that. Also, is that node accepting incoming connections? > Over the last few days, I has mostly seen OP_RETURN transactions > (presumably mostly by OpenTimestamps; but I haven't checked closely) and > a few other non-OP_RETURN transactions. None of the replacement > transactions have been mined yet. They are mostly OpenTimestamps transactions; I checked against the records from my calendars and didn't find any OP_Return tx that wasn't one of mine. The two calendars making full-rbf replacements are: https://alice.btc.calendar.opentimestamps.org/ https://bob.btc.calendar.opentimestamps.org/ The status pages currently link to https://mempool.nixbitcoin.org, which is also running mempoolfullrbf=1 As you can see, I've started the full-rbf bounty again on Alice. https://blockstream.info also enabled full-rbf a few days ago. But currently propagation to their nodes is spotty, so replacements don't always show up. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Hi AJ and list, > This seems to be pretty good evidence that we currently don't have any > significant hashrate mining with fullrbf policies (<0.5% if there was a > high fee replacement available prior to every block having been mined), > despite the bounty having been collected. For further monitoring, I've set-up a mempoolfullrbf=1 node and are logging replacement events with [0]. I filter the full-RBF replacements and list the replaced and replacement transactions here: https://fullrbf.mempool.observer/ This also tries to find out if either the replaced or replacement transaction has been included in a block upon loading the site. The yellow mined-in-badges link to the block on miningpool.observer to a) show the mining pool (if known) and b) see if the (mempoolfullrbf=0) miningpool-observer node thinks this transaction is extra / conflicts with the mined transaction. This should be the case if a full-RBF replacement transaction is mined. Over the last few days, I has mostly seen OP_RETURN transactions (presumably mostly by OpenTimestamps; but I haven't checked closely) and a few other non-OP_RETURN transactions. None of the replacement transactions have been mined yet. [0]: https://github.com/bitcoin/bitcoin/pull/26531#issuecomment-1333832906 Best, 0xB10C OpenPGP_0x188CBB2648416AD5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Mon, Dec 5, 2022 at 3:58 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > note: if it was possible to enforce this, we wouldn't need proof of work > at all. since it isn't possible, proof of work is strictly necessary. > If making empty statements were enough to convince people, we would not need to give good arguments to back our claims. Proof of work is "strictly necessary" to build blocks that are accepted by the consensus rules, that are enforced by the validation nodes that propagate those blocks. If there are multiple valid blocks that are generated close enough and some of them propagate faster than the others, then validation nodes add some economic incentive against certain practices. Miners will obviously choose what validation nodes enforce or they will lose money. On Mon, Dec 5, 2022 at 3:58 PM Michael Folkson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Daniel Lipshitz has been working on BSV apparently [0] so I guess anything > is possible with him.(...) > -- > Michael Folkson You are apparently making an Ad Hominem attack [1] so I guess your comment is not serious. Thanks for the context anyway. [1]: https://en.wikipedia.org/wiki/Ad_hominem --- Eloy > On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Good morning, >> >> That sounds like a very dangerous mode of operation. You can already hand >> a transaction to a miner privately. I hand a transaction to a miner with >> some reasonable fee, and then I go and broadcast a different transaction >> with a minimal fee that spends the same inputs. The whole network >> (including the miner I handed the tx to) could all be running with a strict >> first-seen mempool policy, but we can still have a situation where the >> miner creates a block with a different transaction from what you see in >> your mempool. If anytime this happens, the nodes running your proposed rule >> drop the block, then anyone can fork those nodes off the network whenever >> they want. >> >> Even outside of adversarial settings, Bitcoin doesn't (and doesn't >> attempt to) promise consistency across mempools. Making a consensus rule >> that enforces mempool consistency is a recipe for (unintended?) >> chainsplits. >> >> - rijndael >> >> >> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: >> >> The only option I see against the attack Peter Todd is doing to opt-in >> RBF and 0Conf bitcoin usage is working on a bitcoin core implementation >> that stops propagation of full-rbf replaced blocks. Running multiple of >> such nodes on the network will add a risk to miners that enable full-rbf >> that would work as an incentive against that. >> >> Obviously that would require adding an option on bitcoin core (that is >> not technically but politically difficult to implement as Petter Todd >> already have commit access to the main repository). >> >> That said, a sufficiently incentivized actor (like Daniel Lipshitz or >> Muun wallet developers) could work on a fork and run several nodes with >> such functionality. As far as I understand the percolation model, with 10 >> to 20 nodes running such a rule would create a significant risk for >> full-rbf miners. >> >> Regards. >> >> --- Eloy >> >> >> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >>> wrote: >>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev >>> wrote: >>> > > FYI I've gotten a few hundred dollars worth of donations to this >>> effort, and >>> > > have raised the reward to about 0.02 BTC, or $400 USD at current >>> prices. >>> > >>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >>> >>> I'm turning it back on when (if) the mempool settles down. I've got more >>> than >>> enough donations to give another run at it (the majority was donated >>> privately >>> FWIW). There's a risk of the mempool filling up again of course; hard to >>> avoid >>> that. >>> >>> Right now of course it's really easy to double spend with the obvious >>> low-fee/high-fee method as the min relay fee keeps shifting. >>> >>> > >>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c >>> > >>> > The block it was claimed in seems to have been about an hour after the >>> > default mempool filled up: >>> > >>> > https://twitter.com/murchandamus/status/1592274621977477120 >>> > >>> > That block actually seems to have included two >>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 >>> > (309sat/vb): >>> > >>> > >>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >>> >>> The second is because I turned down the full-rbf reward to more normal >>> fee >>> levels. There's also another full-rbf double-spend from the Bob >>> calendar, along >>> the
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Tue, Dec 06, 2022 at 12:39:40AM -0500, Peter Todd via bitcoin-dev wrote: > 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by > default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes > on > the network. When a node learns of a new block, it tells all it's peers that > the new block exists. > > For your censorship to work, there has to be a substantial propability that a > miner *only* runs a single node (they don't), that has no incoming peers, and > all 8 peers of that node happen to be one of your 20 censoring nodes. > Obviously, since the probability of a given peer being a censoring node is > 20/5000, all 8 being censored is extraordinarily unlikely. > > Even if you ran so many nodes that 20% of the entire network was censoring, > the > probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256% > > > This is an example of information being hard to censor and easy to spread. In > fact, for full-rbf this same math works in our favor: for a node to have a 50% > chance of connecting to at least one full-rbf peer, just 8.3% of the network > needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes. > > The percolation threshold doesn't need to be met for this to be succesful, > because someone to just run a full-rbf node that connects to every single > listening node simultaneously. FYI here's a percolation simulator for full-rbf: https://github.com/mzumsande/fullrbf_simulation It finds similar results to my math above. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote: > The only option I see against the attack Peter Todd is doing to opt-in RBF > and 0Conf bitcoin usage is working on a bitcoin core implementation that > stops propagation of full-rbf replaced blocks. Running multiple of such > nodes on the network will add a risk to miners that enable full-rbf that > would work as an incentive against that. > > Obviously that would require adding an option on bitcoin core (that is not > technically but politically difficult to implement as Petter Todd already > have commit access to the main repository). For the record, I do not and have never had commit access to anything under https://github.com/bitcoin The last time I contributed to Bitcoin Core was in Mar 1st 2017, and that was to add an explanatory comment. Pretty much the only reason why you know my name is I'm very good at argument and critique, I come up with some good ideas, and conference organizers love to put me on stage. > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. As far as I understand the percolation model, with 10 to 20 > nodes running such a rule would create a significant risk for full-rbf > miners. You do not understand the percolation model. 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on the network. When a node learns of a new block, it tells all it's peers that the new block exists. For your censorship to work, there has to be a substantial propability that a miner *only* runs a single node (they don't), that has no incoming peers, and all 8 peers of that node happen to be one of your 20 censoring nodes. Obviously, since the probability of a given peer being a censoring node is 20/5000, all 8 being censored is extraordinarily unlikely. Even if you ran so many nodes that 20% of the entire network was censoring, the probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256% This is an example of information being hard to censor and easy to spread. In fact, for full-rbf this same math works in our favor: for a node to have a 50% chance of connecting to at least one full-rbf peer, just 8.3% of the network needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes. The percolation threshold doesn't need to be met for this to be succesful, because someone to just run a full-rbf node that connects to every single listening node simultaneously. Anyway, as others' have pointed out, you're idea is also broken in other ways. But I thought it'd be worth pointing out how futile it is to even try. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
note: if it was possible to enforce this, we wouldn't need proof of work at all. since it isn't possible, proof of work is strictly necessary. On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning, > > That sounds like a very dangerous mode of operation. You can already hand > a transaction to a miner privately. I hand a transaction to a miner with > some reasonable fee, and then I go and broadcast a different transaction > with a minimal fee that spends the same inputs. The whole network > (including the miner I handed the tx to) could all be running with a strict > first-seen mempool policy, but we can still have a situation where the > miner creates a block with a different transaction from what you see in > your mempool. If anytime this happens, the nodes running your proposed rule > drop the block, then anyone can fork those nodes off the network whenever > they want. > > Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt > to) promise consistency across mempools. Making a consensus rule that > enforces mempool consistency is a recipe for (unintended?) chainsplits. > > - rijndael > > > On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: > > The only option I see against the attack Peter Todd is doing to opt-in RBF > and 0Conf bitcoin usage is working on a bitcoin core implementation that > stops propagation of full-rbf replaced blocks. Running multiple of such > nodes on the network will add a risk to miners that enable full-rbf that > would work as an incentive against that. > > Obviously that would require adding an option on bitcoin core (that is not > technically but politically difficult to implement as Petter Todd already > have commit access to the main repository). > > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. As far as I understand the percolation model, with 10 to 20 > nodes running such a rule would create a significant risk for full-rbf > miners. > > Regards. > > --- Eloy > > > On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >> wrote: >> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev >> wrote: >> > > FYI I've gotten a few hundred dollars worth of donations to this >> effort, and >> > > have raised the reward to about 0.02 BTC, or $400 USD at current >> prices. >> > >> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >> >> I'm turning it back on when (if) the mempool settles down. I've got more >> than >> enough donations to give another run at it (the majority was donated >> privately >> FWIW). There's a risk of the mempool filling up again of course; hard to >> avoid >> that. >> >> Right now of course it's really easy to double spend with the obvious >> low-fee/high-fee method as the min relay fee keeps shifting. >> >> > >> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c >> > >> > The block it was claimed in seems to have been about an hour after the >> > default mempool filled up: >> > >> > https://twitter.com/murchandamus/status/1592274621977477120 >> > >> > That block actually seems to have included two >> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 >> > (309sat/vb): >> > >> > >> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >> >> The second is because I turned down the full-rbf reward to more normal fee >> levels. There's also another full-rbf double-spend from the Bob calendar, >> along >> the same lines: >> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 >> >> I double-spent the txin of the high fee tx that got mined. But I >> mistakenly had >> RBF enabled in that double-spend, so while it propagated initially, I >> believe >> it was replaced when something (someone?) rebroadcast the high-fee 397dcb >> tx. >> >> > Timeline (utc) to me looks like: >> > >> > - 13:12 - block 763148 is mined: last one that had a min fee < >> 1.5sat/vb >> > - 13:33 - >> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 >> >is announced and propogates widely (1.2sat/vb) >> > - 18:42 - >> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 >> >is announced and propogates widely (1.2sat/vb) >> > - 21:52 - ba967010 tx is announced and propogates widely, since >> >conflicting tx 746daab9 has been removed from default >> > mempools >> > - 21:53 - murch tweets about default mempool filling up >> > - 22:03 - 397dcbe4 tx is announced and propogates widely, since >> >conflicting tx f503868 has already been removed from default >> > mempools >> >> Is that 22:03 time for 397 from your node's
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
You are doing quite big claims without explaining those, let me add a few questions inline: On Mon, Dec 5, 2022 at 10:39 AM Greg Sanders wrote: This will greatly centralize the network as well as not actually achieve > the intended goal which is literally impossible. > Why would this centralize the network? Adding more nodes that propagate valid blocks on the network should be good. Also, I cannot see why you say it is "literally impossible", could you give any explanation for your words? On Mon, Dec 5, 2022 at 11:53 AM Rijndael via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning, > > That sounds like a very dangerous mode of operation. You can already hand > a transaction to a miner privately. I hand a transaction to a miner with > some reasonable fee, and then I go and broadcast a different transaction > with a minimal fee that spends the same inputs. The whole network > (including the miner I handed the tx to) could all be running with a strict > first-seen mempool policy, but we can still have a situation where the > miner creates a block with a different transaction from what you see in > your mempool. If anytime this happens, the nodes running your proposed rule > drop the block, then anyone can fork those nodes off the network whenever > they want. > I cannot see the danger you are talking about, sending a transaction directly to a miner does not sound like anyone can do (except a miner) and is not the main workflow, usually transactions propagate on the network and it is quite difficult to have different miners with different opt-out-rbb transactions that spends the same input. In that strange scenario that you mention, the miner generated block might be lost if another miner creates an alternative block. > Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt > to) promise consistency across mempools. Making a consensus rule that > enforces mempool consistency is a recipe for (unintended?) chainsplits. > That is not entirely true for opt-out rbf transactions, as most 0conf setups are based on such consistency. And breaking a consensus rule always leads to a chainsplit. For example when a miner creates a block that double-spends an input, the normal bitcoin flow is a chain-split. That is not an unintended chainsplit, is a consensus rule enforcement. > - rijndael > > > On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: > > The only option I see against the attack Peter Todd is doing to opt-in RBF > and 0Conf bitcoin usage is working on a bitcoin core implementation that > stops propagation of full-rbf replaced blocks. Running multiple of such > nodes on the network will add a risk to miners that enable full-rbf that > would work as an incentive against that. > > Obviously that would require adding an option on bitcoin core (that is not > technically but politically difficult to implement as Petter Todd already > have commit access to the main repository). > > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. As far as I understand the percolation model, with 10 to 20 > nodes running such a rule would create a significant risk for full-rbf > miners. > > Regards. > > --- Eloy > > > On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >> wrote: >> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev >> wrote: >> > > FYI I've gotten a few hundred dollars worth of donations to this >> effort, and >> > > have raised the reward to about 0.02 BTC, or $400 USD at current >> prices. >> > >> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >> >> I'm turning it back on when (if) the mempool settles down. I've got more >> than >> enough donations to give another run at it (the majority was donated >> privately >> FWIW). There's a risk of the mempool filling up again of course; hard to >> avoid >> that. >> >> Right now of course it's really easy to double spend with the obvious >> low-fee/high-fee method as the min relay fee keeps shifting. >> >> > >> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c >> > >> > The block it was claimed in seems to have been about an hour after the >> > default mempool filled up: >> > >> > https://twitter.com/murchandamus/status/1592274621977477120 >> > >> > That block actually seems to have included two >> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 >> > (309sat/vb): >> > >> > >> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >> >> The second is because I turned down the full-rbf reward to more normal fee >> levels. There's also another full-rbf double-spend from the Bob calendar, >> along >> the same lines: >>
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is possible with him. But as others have said turning a mempool policy issue (users have always been free to choose whatever policy they like with zero chain split risk) into a consensus issue and a contentious soft fork issue at that would not be advised. I highly doubt any of the long term Muun contributors would want to support a contentious soft fork and fight a consensus rule war on this. [0]: https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev wrote: > Good morning, > > That sounds like a very dangerous mode of operation. You can already hand a > transaction to a miner privately. I hand a transaction to a miner with some > reasonable fee, and then I go and broadcast a different transaction with a > minimal fee that spends the same inputs. The whole network (including the > miner I handed the tx to) could all be running with a strict first-seen > mempool policy, but we can still have a situation where the miner creates a > block with a different transaction from what you see in your mempool. If > anytime this happens, the nodes running your proposed rule drop the block, > then anyone can fork those nodes off the network whenever they want. > > Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt > to) promise consistency across mempools. Making a consensus rule that > enforces mempool consistency is a recipe for (unintended?) chainsplits. > > - rijndael > > On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: > >> The only option I see against the attack Peter Todd is doing to opt-in RBF >> and 0Conf bitcoin usage is working on a bitcoin core implementation that >> stops propagation of full-rbf replaced blocks. Running multiple of such >> nodes on the network will add a risk to miners that enable full-rbf that >> would work as an incentive against that. >> >> Obviously that would require adding an option on bitcoin core (that is not >> technically but politically difficult to implement as Petter Todd already >> have commit access to the main repository). >> >> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun >> wallet developers) could work on a fork and run several nodes with such >> functionality. As far as I understand the percolation model, with 10 to 20 >> nodes running such a rule would create a significant risk for full-rbf >> miners. >> >> Regards. >> >> --- Eloy >> >> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev >> wrote: >> >>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >>> wrote: On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote: > FYI I've gotten a few hundred dollars worth of donations to this effort, > and > have raised the reward to about 0.02 BTC, or $400 USD at current prices. Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >>> >>> I'm turning it back on when (if) the mempool settles down. I've got more >>> than >>> enough donations to give another run at it (the majority was donated >>> privately >>> FWIW). There's a risk of the mempool filling up again of course; hard to >>> avoid >>> that. >>> >>> Right now of course it's really easy to double spend with the obvious >>> low-fee/high-fee method as the min relay fee keeps shifting. >>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c The block it was claimed in seems to have been about an hour after the default mempool filled up: https://twitter.com/murchandamus/status/1592274621977477120 That block actually seems to have included two alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 (309sat/vb): https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >>> >>> The second is because I turned down the full-rbf reward to more normal fee >>> levels. There's also another full-rbf double-spend from the Bob calendar, >>> along >>> the same lines: >>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 >>> >>> I double-spent the txin of the high fee tx that got mined. But I mistakenly >>> had >>> RBF enabled in that double-spend, so while it propagated initially, I >>> believe >>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb >>> tx. >>> Timeline (utc) to me looks like: - 13:12 -
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Good morning, That sounds like a very dangerous mode of operation. You can already hand a transaction to a miner privately. I hand a transaction to a miner with some reasonable fee, and then I go and broadcast a different transaction with a minimal fee that spends the same inputs. The whole network (including the miner I handed the tx to) could all be running with a strict first-seen mempool policy, but we can still have a situation where the miner creates a block with a different transaction from what you see in your mempool. If anytime this happens, the nodes running your proposed rule drop the block, then anyone can fork those nodes off the network whenever they want. Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt to) promise consistency across mempools. Making a consensus rule that enforces mempool consistency is a recipe for (unintended?) chainsplits. - rijndael On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: > The only option I see against the attack Peter Todd is doing to opt-in RBF > and 0Conf bitcoin usage is working on a bitcoin core implementation that > stops propagation of full-rbf replaced blocks. Running multiple of such nodes > on the network will add a risk to miners that enable full-rbf that would work > as an incentive against that. > > Obviously that would require adding an option on bitcoin core (that is not > technically but politically difficult to implement as Petter Todd already > have commit access to the main repository). > > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. As far as I understand the percolation model, with 10 to 20 > nodes running such a rule would create a significant risk for full-rbf miners. > > Regards. > > --- Eloy > > On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev > wrote: > >> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >> wrote: >>> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote: >>> > FYI I've gotten a few hundred dollars worth of donations to this effort, >>> > and >>> > have raised the reward to about 0.02 BTC, or $400 USD at current prices. >>> >>> Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >> >> I'm turning it back on when (if) the mempool settles down. I've got more than >> enough donations to give another run at it (the majority was donated >> privately >> FWIW). There's a risk of the mempool filling up again of course; hard to >> avoid >> that. >> >> Right now of course it's really easy to double spend with the obvious >> low-fee/high-fee method as the min relay fee keeps shifting. >> >>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c >>> >>> The block it was claimed in seems to have been about an hour after the >>> default mempool filled up: >>> >>> https://twitter.com/murchandamus/status/1592274621977477120 >>> >>> That block actually seems to have included two >>> alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 >>> (309sat/vb): >>> >>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >> >> The second is because I turned down the full-rbf reward to more normal fee >> levels. There's also another full-rbf double-spend from the Bob calendar, >> along >> the same lines: >> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 >> >> I double-spent the txin of the high fee tx that got mined. But I mistakenly >> had >> RBF enabled in that double-spend, so while it propagated initially, I believe >> it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx. >> >>> Timeline (utc) to me looks like: >>> >>> - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb >>> - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 >>> is announced and propogates widely (1.2sat/vb) >>> - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 >>> is announced and propogates widely (1.2sat/vb) >>> - 21:52 - ba967010 tx is announced and propogates widely, since >>> conflicting tx 746daab9 has been removed from default >>> mempools >>> - 21:53 - murch tweets about default mempool filling up >>> - 22:03 - 397dcbe4 tx is announced and propogates widely, since >>> conflicting tx f503868 has already been removed from default >>> mempools >> >> Is that 22:03 time for 397 from your node's logs? It was originally announced >> hours earlier. From one of my full-rbf nodes: >> >> 2022-11-14T14:08:37Z [mempool] replacing tx >> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with >> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 >> additional fees, -1 delta bytes >> >>> - 22:35 - block 763189 is mined >>> - 22:39 - block 763190 is mined >>> - 23:11 - block 763191 is mined >>>
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
This will greatly centralize the network as well as not actually achieve the intended goal which is literally impossible. On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The only option I see against the attack Peter Todd is doing to opt-in RBF > and 0Conf bitcoin usage is working on a bitcoin core implementation that > stops propagation of full-rbf replaced blocks. Running multiple of such > nodes on the network will add a risk to miners that enable full-rbf that > would work as an incentive against that. > > Obviously that would require adding an option on bitcoin core (that is not > technically but politically difficult to implement as Petter Todd already > have commit access to the main repository). > > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. As far as I understand the percolation model, with 10 to 20 > nodes running such a rule would create a significant risk for full-rbf > miners. > > Regards. > > --- Eloy > > > On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >> wrote: >> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev >> wrote: >> > > FYI I've gotten a few hundred dollars worth of donations to this >> effort, and >> > > have raised the reward to about 0.02 BTC, or $400 USD at current >> prices. >> > >> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >> >> I'm turning it back on when (if) the mempool settles down. I've got more >> than >> enough donations to give another run at it (the majority was donated >> privately >> FWIW). There's a risk of the mempool filling up again of course; hard to >> avoid >> that. >> >> Right now of course it's really easy to double spend with the obvious >> low-fee/high-fee method as the min relay fee keeps shifting. >> >> > >> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c >> > >> > The block it was claimed in seems to have been about an hour after the >> > default mempool filled up: >> > >> > https://twitter.com/murchandamus/status/1592274621977477120 >> > >> > That block actually seems to have included two >> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 >> > (309sat/vb): >> > >> > >> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >> >> The second is because I turned down the full-rbf reward to more normal fee >> levels. There's also another full-rbf double-spend from the Bob calendar, >> along >> the same lines: >> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 >> >> I double-spent the txin of the high fee tx that got mined. But I >> mistakenly had >> RBF enabled in that double-spend, so while it propagated initially, I >> believe >> it was replaced when something (someone?) rebroadcast the high-fee 397dcb >> tx. >> >> > Timeline (utc) to me looks like: >> > >> > - 13:12 - block 763148 is mined: last one that had a min fee < >> 1.5sat/vb >> > - 13:33 - >> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 >> >is announced and propogates widely (1.2sat/vb) >> > - 18:42 - >> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 >> >is announced and propogates widely (1.2sat/vb) >> > - 21:52 - ba967010 tx is announced and propogates widely, since >> >conflicting tx 746daab9 has been removed from default >> > mempools >> > - 21:53 - murch tweets about default mempool filling up >> > - 22:03 - 397dcbe4 tx is announced and propogates widely, since >> >conflicting tx f503868 has already been removed from default >> > mempools >> >> Is that 22:03 time for 397 from your node's logs? It was originally >> announced >> hours earlier. From one of my full-rbf nodes: >> >> 2022-11-14T14:08:37Z [mempool] replacing tx >> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with >> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for >> 0.00468 additional fees, -1 delta bytes >> >> > - 22:35 - block 763189 is mined >> > - 22:39 - block 763190 is mined >> > - 23:11 - block 763191 is mined >> > - 23:17 - block 763192 is mined including 397dcbe4 >> > >> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the >> > first three blocks, and gives similar mempool ages for those txs to what >> > my logs report: >> > >> > >> https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7 >> > >> https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309 >> > >>
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
The only option I see against the attack Peter Todd is doing to opt-in RBF and 0Conf bitcoin usage is working on a bitcoin core implementation that stops propagation of full-rbf replaced blocks. Running multiple of such nodes on the network will add a risk to miners that enable full-rbf that would work as an incentive against that. Obviously that would require adding an option on bitcoin core (that is not technically but politically difficult to implement as Petter Todd already have commit access to the main repository). That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun wallet developers) could work on a fork and run several nodes with such functionality. As far as I understand the percolation model, with 10 to 20 nodes running such a rule would create a significant risk for full-rbf miners. Regards. --- Eloy On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev > wrote: > > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev > wrote: > > > FYI I've gotten a few hundred dollars worth of donations to this > effort, and > > > have raised the reward to about 0.02 BTC, or $400 USD at current > prices. > > > > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): > > I'm turning it back on when (if) the mempool settles down. I've got more > than > enough donations to give another run at it (the majority was donated > privately > FWIW). There's a risk of the mempool filling up again of course; hard to > avoid > that. > > Right now of course it's really easy to double spend with the obvious > low-fee/high-fee method as the min relay fee keeps shifting. > > > > https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c > > > > The block it was claimed in seems to have been about an hour after the > > default mempool filled up: > > > > https://twitter.com/murchandamus/status/1592274621977477120 > > > > That block actually seems to have included two > > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 > > (309sat/vb): > > > > > https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf > > The second is because I turned down the full-rbf reward to more normal fee > levels. There's also another full-rbf double-spend from the Bob calendar, > along > the same lines: > 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 > > I double-spent the txin of the high fee tx that got mined. But I > mistakenly had > RBF enabled in that double-spend, so while it propagated initially, I > believe > it was replaced when something (someone?) rebroadcast the high-fee 397dcb > tx. > > > Timeline (utc) to me looks like: > > > > - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb > > - 13:33 - > f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 > >is announced and propogates widely (1.2sat/vb) > > - 18:42 - > 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 > >is announced and propogates widely (1.2sat/vb) > > - 21:52 - ba967010 tx is announced and propogates widely, since > >conflicting tx 746daab9 has been removed from default > > mempools > > - 21:53 - murch tweets about default mempool filling up > > - 22:03 - 397dcbe4 tx is announced and propogates widely, since > >conflicting tx f503868 has already been removed from default > > mempools > > Is that 22:03 time for 397 from your node's logs? It was originally > announced > hours earlier. From one of my full-rbf nodes: > > 2022-11-14T14:08:37Z [mempool] replacing tx > 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with > 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for > 0.00468 additional fees, -1 delta bytes > > > - 22:35 - block 763189 is mined > > - 22:39 - block 763190 is mined > > - 23:11 - block 763191 is mined > > - 23:17 - block 763192 is mined including 397dcbe4 > > > > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the > > first three blocks, and gives similar mempool ages for those txs to what > > my logs report: > > > > > https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7 > > > https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309 > > > https://miningpool.observer/template-and-block/0004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1 > > > > That presumably means those pools (AntPool twice and "unknown") are > > running with large mempools that didn't kept the earlier 1.2sat/vb txs. > > To be clear, you think that AntPool and that other exchange is running > with a > larger than normal max mempool size limit? You mean those miners *did* > keep the > earlier 1.2sat/vb tx?
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wrote: > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote: > > FYI I've gotten a few hundred dollars worth of donations to this effort, and > > have raised the reward to about 0.02 BTC, or $400 USD at current prices. > > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): I'm turning it back on when (if) the mempool settles down. I've got more than enough donations to give another run at it (the majority was donated privately FWIW). There's a risk of the mempool filling up again of course; hard to avoid that. Right now of course it's really easy to double spend with the obvious low-fee/high-fee method as the min relay fee keeps shifting. > https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c > > The block it was claimed in seems to have been about an hour after the > default mempool filled up: > > https://twitter.com/murchandamus/status/1592274621977477120 > > That block actually seems to have included two > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 > (309sat/vb): > > https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf The second is because I turned down the full-rbf reward to more normal fee levels. There's also another full-rbf double-spend from the Bob calendar, along the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 I double-spent the txin of the high fee tx that got mined. But I mistakenly had RBF enabled in that double-spend, so while it propagated initially, I believe it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx. > Timeline (utc) to me looks like: > > - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb > - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 >is announced and propogates widely (1.2sat/vb) > - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 >is announced and propogates widely (1.2sat/vb) > - 21:52 - ba967010 tx is announced and propogates widely, since >conflicting tx 746daab9 has been removed from default > mempools > - 21:53 - murch tweets about default mempool filling up > - 22:03 - 397dcbe4 tx is announced and propogates widely, since >conflicting tx f503868 has already been removed from default > mempools Is that 22:03 time for 397 from your node's logs? It was originally announced hours earlier. From one of my full-rbf nodes: 2022-11-14T14:08:37Z [mempool] replacing tx 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 additional fees, -1 delta bytes > - 22:35 - block 763189 is mined > - 22:39 - block 763190 is mined > - 23:11 - block 763191 is mined > - 23:17 - block 763192 is mined including 397dcbe4 > > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the > first three blocks, and gives similar mempool ages for those txs to what > my logs report: > > > https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7 > > https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309 > > https://miningpool.observer/template-and-block/0004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1 > > That presumably means those pools (AntPool twice and "unknown") are > running with large mempools that didn't kept the earlier 1.2sat/vb txs. To be clear, you think that AntPool and that other exchange is running with a larger than normal max mempool size limit? You mean those miners *did* keep the earlier 1.2sat/vb tx? > The txs were mined by Foundry: > > > https://miningpool.observer/template-and-block/0001382a226aedac822de80309cca2bf1253b35d4f8144f5 > > This seems to be pretty good evidence that we currently don't have any > significant hashrate mining with fullrbf policies (<0.5% if there was a > high fee replacement available prior to every block having been mined), > despite the bounty having been collected. Oh, we can put much lower bounds on that. I've been running OTS calendars with full-rbf replacements for a few months without clear evidence of a full-rbf replacement. While there was good reason to think some miners were mining full-rbf before a few years back, they probably didn't bother to reapply their patches each upgrade. `mempoolfullrbf=1` is much simpler to use. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote: > FYI I've gotten a few hundred dollars worth of donations to this effort, and > have raised the reward to about 0.02 BTC, or $400 USD at current prices. Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c The block it was claimed in seems to have been about an hour after the default mempool filled up: https://twitter.com/murchandamus/status/1592274621977477120 That block actually seems to have included two alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 (309sat/vb): https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf Timeline (utc) to me looks like: - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1 is announced and propogates widely (1.2sat/vb) - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944 is announced and propogates widely (1.2sat/vb) - 21:52 - ba967010 tx is announced and propogates widely, since conflicting tx 746daab9 has been removed from default mempools - 21:53 - murch tweets about default mempool filling up - 22:03 - 397dcbe4 tx is announced and propogates widely, since conflicting tx f503868 has already been removed from default mempools - 22:35 - block 763189 is mined - 22:39 - block 763190 is mined - 23:11 - block 763191 is mined - 23:17 - block 763192 is mined including 397dcbe4 miningpool.observer reports both 397dcbe4 and ba967010 as missing in the first three blocks, and gives similar mempool ages for those txs to what my logs report: https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7 https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309 https://miningpool.observer/template-and-block/0004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1 That presumably means those pools (AntPool twice and "unknown") are running with large mempools that didn't kept the earlier 1.2sat/vb txs. The txs were mined by Foundry: https://miningpool.observer/template-and-block/0001382a226aedac822de80309cca2bf1253b35d4f8144f5 This seems to be pretty good evidence that we currently don't have any significant hashrate mining with fullrbf policies (<0.5% if there was a high fee replacement available prior to every block having been mined), despite the bounty having been collected. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
technically, all we need is for *miners* to consistently mine "full
rbf"
There's another important point I think:
technically, all we need is for *miners* to consistently mine the
highest fee-rate transaction (or the one with the most incentive).
Miners could probably be incentivized to mine transactions that double
spend a previous transaction that isn't rbf, also.
Cheers,
-Yancy
On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:
actually, peter makes an important point here
technically, all we need is for *miners* to consistently mine "full
rbf"
as long as they do, businesses that accept 0conf will have to adjust
their risk accordingly, and the problem of misaligned incentives is
resolved
i don't think it matters what non-mining users do nearly as much
On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev
wrote:
Hi Peter,
tl;dr: I'm broadcasting full-RBF replacements paying extremely high
fees to reward miners that turn on full-RBF. I'm starting small, just
~$100/block in times of congestion. Miner and pool profit margins are
pretty small, on the order of $1k/block in many cases, so I know it
doesn't take that much more money to make a difference.
I appreciate this effort and perhaps this was all that was needed in
addition to Bitcoin Core's inclusion of full rbf support. Making it
default right away or enabling preferential peering with service
flag in a bitcoin core release was unnecessary.
If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
Sorry, I don't trust you based on some of the things you support on
Twitter. Hopefully, others will donate and help this bounty.
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via
bitcoin-dev wrote:
I'm now running a full-RBf bounty program for miners.
tl;dr: I'm broadcasting full-RBF replacements paying extremely high
fees to reward miners that turn on full-RBF. I'm starting small, just
~$100/block in times of congestion. Miner and pool profit margins are
pretty small, on the order of $1k/block in many cases, so I know it
doesn't take that much more money to make a difference.
Why should you do this? Full-RBF/zeroconf has been discussed to death.
But tl;dr: You'll earn more money, and help transition Bitcoin to a
more secure mempool policy based on economic incentives rather than
trust.
If you're a miner and want to participate, the easiest way to so is to
use the mempoolfullrbf=1 option in the upcoming Bitcoin Core v24
release (eg the 24.0rc3 tag), or use the mempoolreplacement=fee option
in Bitcoin Knots.
You can also just modify the code yourself by removing the opt-in RBF
check. For example against the v23.0 tag:
$ git diff
diff --git a/src/validation.cpp b/src/validation.cpp
index 214112e2b..44c364623 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
Workspace& ws) // check all unconfirmed ancestors; otherwise an opt-in
ancestor
// might be replaced, causing removal of this descendant.
if (!SignalsOptInRBF(*ptxConflicting)) {
- return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
"txn-mempool-conflict"); + // return
state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
"txn-mempool-conflict"); }
ws.m_conflicts.insert(ptxConflicting->GetHash());
Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
few of them:
cup.nop.lol
mug.nop.lol
jar.nop.lol
jug.nop.lol
These nodes run a preferential peering patch
(https://github.com/bitcoin/bitcoin/pull/25600) to ensure that full-RBF
nodes are interconnected to each other and replacements can easily
propagate. Also feel free to contact me if you'd like to peer with a
private node.
If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
...and yes, I'm well aware that miners could collect this bounty in
other ways, eg by raising minimum fees. Doing that also breaks
zeroconf, so I'm not too concerned.
--
https://petertodd.org 'peter'[:-1]@petertodd.org [1 [1]]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
--
[1] http://petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
--
[1] http://petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Wed, Nov 02, 2022 at 05:26:27AM -0400, Peter Todd via bitcoin-dev wrote: > I'm now running a full-RBf bounty program for miners. > > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to > reward miners that turn on full-RBF. I'm starting small, just ~$100/block in > times of congestion. FYI I've gotten a few hundred dollars worth of donations to this effort, and have raised the reward to about 0.02 BTC, or $400 USD at current prices. To be clear, this doesn't mean there will always be a $400 fee tx in the full-rbf mempool. I have to take a number of precautions to avoid the double-spend tx being mined by accident, such as only spending txouts with >2 confirmations, and waiting significant amounts of time before the 1st transaction is sent to allow for maximal propagation. > If you'd like to donate to this effort, send BTC to > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
actually, peter makes an important point here
technically, all we need is for *miners* to consistently mine "full rbf"
as long as they do, businesses that accept 0conf will have to adjust their
risk accordingly, and the problem of misaligned incentives is resolved
i don't think it matters what non-mining users do nearly as much
On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Peter,
>
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
>
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it default
> right away or enabling preferential peering with service flag in a bitcoin
> core release was unnecessary.
>
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I'm now running a full-RBf bounty program for miners.
> >
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
> >
> > Why should you do this? Full-RBF/zeroconf has been discussed to death.
> But
> > tl;dr: You'll earn more money, and help transition Bitcoin to a more
> secure
> > mempool policy based on economic incentives rather than trust.
> >
> >
> > If you're a miner and want to participate, the easiest way to so is to
> use the
> > mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> > 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> >
> > You can also just modify the code yourself by removing the opt-in RBF
> check.
> > For example against the v23.0 tag:
> >
> > $ git diff
> > diff --git a/src/validation.cpp b/src/validation.cpp
> > index 214112e2b..44c364623 100644
> > --- a/src/validation.cpp
> > +++ b/src/validation.cpp
> > @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
> Workspace& ws)
> > // check all unconfirmed ancestors; otherwise an opt-in ancestor
> > // might be replaced, causing removal of this descendant.
> > if (!SignalsOptInRBF(*ptxConflicting)) {
> > - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > }
> >
> > ws.m_conflicts.insert(ptxConflicting->GetHash());
> >
> >
> > Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
> few of
> > them:
> >
> > cup.nop.lol
> > mug.nop.lol
> > jar.nop.lol
> > jug.nop.lol
> >
> > These nodes run a preferential peering patch (
> https://github.com/bitcoin/bitcoin/pull/25600)
> > to ensure that full-RBF nodes are interconnected to each other and
> replacements
> > can easily propagate. Also feel free to contact me if you'd like to peer
> with a
> > private node.
> >
> >
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> >
> >
> > ...and yes, I'm well aware that miners could collect this bounty in
> other ways,
> > eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not
> too
> > concerned.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Hi Peter,
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.
I appreciate this effort and perhaps this was all that was needed in addition
to Bitcoin Core's inclusion of full rbf support. Making it default right away
or enabling preferential peering with service flag in a bitcoin core release
was unnecessary.
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
Sorry, I don't trust you based on some of the things you support on Twitter.
Hopefully, others will donate and help this bounty.
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev
wrote:
> I'm now running a full-RBf bounty program for miners.
>
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.
>
> Why should you do this? Full-RBF/zeroconf has been discussed to death. But
> tl;dr: You'll earn more money, and help transition Bitcoin to a more secure
> mempool policy based on economic incentives rather than trust.
>
>
> If you're a miner and want to participate, the easiest way to so is to use the
> mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
>
> You can also just modify the code yourself by removing the opt-in RBF check.
> For example against the v23.0 tag:
>
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace&
> ws)
> // check all unconfirmed ancestors; otherwise an opt-in ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> }
>
> ws.m_conflicts.insert(ptxConflicting->GetHash());
>
>
> Once you've enabled full-RBF, you need a full-RBF peer. I'm running a few of
> them:
>
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
>
> These nodes run a preferential peering patch
> (https://github.com/bitcoin/bitcoin/pull/25600)
> to ensure that full-RBF nodes are interconnected to each other and
> replacements
> can easily propagate. Also feel free to contact me if you'd like to peer with
> a
> private node.
>
>
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
>
> ...and yes, I'm well aware that miners could collect this bounty in other
> ways,
> eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not too
> concerned.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Announcement: Full-RBF Miner Bounty
I'm now running a full-RBf bounty program for miners.
tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
times of congestion. Miner and pool profit margins are pretty small, on the
order of $1k/block in many cases, so I know it doesn't take that much more
money to make a difference.
Why should you do this? Full-RBF/zeroconf has been discussed to death. But
tl;dr: You'll earn more money, and help transition Bitcoin to a more secure
mempool policy based on economic incentives rather than trust.
If you're a miner and want to participate, the easiest way to so is to use the
mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
You can also just modify the code yourself by removing the opt-in RBF check.
For example against the v23.0 tag:
$ git diff
diff --git a/src/validation.cpp b/src/validation.cpp
index 214112e2b..44c364623 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
Workspace& ws)
// check all unconfirmed ancestors; otherwise an opt-in
ancestor
// might be replaced, causing removal of this descendant.
if (!SignalsOptInRBF(*ptxConflicting)) {
-return
state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
+// return
state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
}
ws.m_conflicts.insert(ptxConflicting->GetHash());
Once you've enabled full-RBF, you need a full-RBF peer. I'm running a few of
them:
cup.nop.lol
mug.nop.lol
jar.nop.lol
jug.nop.lol
These nodes run a preferential peering patch
(https://github.com/bitcoin/bitcoin/pull/25600)
to ensure that full-RBF nodes are interconnected to each other and replacements
can easily propagate. Also feel free to contact me if you'd like to peer with a
private node.
If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
...and yes, I'm well aware that miners could collect this bounty in other ways,
eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not too
concerned.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
