From: 0xB10C <b10c@b10c•me>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Date: Fri, 9 Dec 2022 17:04:05 +0100 [thread overview]
Message-ID: <f146ca66-a611-f129-ae11-6907a7333d10@b10c.me> (raw)
In-Reply-To: <Y3MlSE7AWkBgiCyr@erisian.com.au>
[-- Attachment #1.1.1: Type: text/plain, Size: 1316 bytes --]
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
[-- 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-09 16:04 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 [this message]
2022-12-09 21:16 ` Peter Todd
2022-12-10 11:59 ` 0xB10C
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=f146ca66-a611-f129-ae11-6907a7333d10@b10c.me \
--to=b10c@b10c$(echo .)me \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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