From: 0xB10C <b10c@b10c•me>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Date: Sat, 10 Dec 2022 12:59:05 +0100 [thread overview]
Message-ID: <ff27975a-78b0-f697-8e88-0d0e5e5dddb6@b10c.me> (raw)
In-Reply-To: <Y5OlpAi3wHPKxxkx@petertodd.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 3562 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6989 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-10 11:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 9:26 Peter Todd
2022-11-02 19:02 ` alicexbt
2022-11-03 13:32 ` Erik Aronesty
2022-11-09 12:14 ` email
2022-11-08 18:16 ` Peter Todd
2022-11-15 5:36 ` Anthony Towns
2022-11-15 14:43 ` Peter Todd
2022-12-05 12:20 ` El_Hoy
2022-12-05 13:38 ` Greg Sanders
2022-12-05 14:12 ` Rijndael
2022-12-05 15:33 ` Michael Folkson
2022-12-05 17:00 ` Erik Aronesty
2022-12-06 4:48 ` El_Hoy
2022-12-05 17:25 ` El_Hoy
2022-12-06 5:39 ` Peter Todd
2022-12-06 7:37 ` Peter Todd
2022-12-09 16:04 ` 0xB10C
2022-12-09 21:16 ` Peter Todd
2022-12-10 11:59 ` 0xB10C [this message]
2022-12-10 18:07 ` Peter Todd
2022-12-13 4:01 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff27975a-78b0-f697-8e88-0d0e5e5dddb6@b10c.me \
--to=b10c@b10c$(echo .)me \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox