Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-10 📝 Original message:On Sat, Dec 10, 2022 at ...
📅 Original date posted:2022-12-10
📝 Original message: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=<snip>: accepted 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 6320 txn, 90818 kB)
2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f for 0.00000234 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 node, with an empty mempool).
Similarly, note how Luxor has mined a few blocks since #766733, without mining
full-rbf replacements.
I'll also note that Foundry USA mined a doublespend,
fab4df6b9b51dcfe94b366f17bccca50430f4ceb274a87f948a5493cd31a8551, which your
site shows. In that case according to my logs the two transactions were sent
essentially simultaneously, so likely just an accident of propagation. But it's
good to remind people that such double-spends are easy. :)
> I've also updated the site to allow only showing the replacements that
> were mined.
Thanks! That's very useful.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/830652f9/attachment-0001.sig>;
📝 Original message: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=<snip>: accepted 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 6320 txn, 90818 kB)
2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f for 0.00000234 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 node, with an empty mempool).
Similarly, note how Luxor has mined a few blocks since #766733, without mining
full-rbf replacements.
I'll also note that Foundry USA mined a doublespend,
fab4df6b9b51dcfe94b366f17bccca50430f4ceb274a87f948a5493cd31a8551, which your
site shows. In that case according to my logs the two transactions were sent
essentially simultaneously, so likely just an accident of propagation. But it's
good to remind people that such double-spends are easy. :)
> I've also updated the site to allow only showing the replacements that
> were mined.
Thanks! That's very useful.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/830652f9/attachment-0001.sig>;