Peter Todd [ARCHIVE] on Nostr: š Original date posted:2022-12-09 š Original message:On Fri, Dec 09, 2022 at ...
š
Original date posted:2022-12-09
š Original message: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
-------------- 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/20221209/1104ff3e/attachment.sig>;
š Original message: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
-------------- 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/20221209/1104ff3e/attachment.sig>;