0xB10C [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-10 📝 Original message:On 12/9/22 22:16, Peter ...
📅 Original date posted:2022-12-10
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x188CBB2648416AD5.asc
Type: application/pgp-keys
Size: 6880 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/7464f9d2/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/7464f9d2/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x188CBB2648416AD5.asc
Type: application/pgp-keys
Size: 6880 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/7464f9d2/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/7464f9d2/attachment.sig>;