0xB10C [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-09-07 to 2023-05-01
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:21:10

- reply

📅 Original date posted:2023-05-01
🗒️ Summary of this message: Bitcoin Core's mempool messages are gated behind stricter Net Permissions, but still accessible to trusted peers, with 20% of nodes having bloom filters enabled.
📝 Original message:Hi Will,
I shared some numbers and feedback as comment [0] on your PR wanted to
answer question 1. for completeness here too.
> Its original intention was to be publicly callable, but it is now (in
Bitcoin Core) gated behind stricter Net Permissions which make it
accessible to trusted peers only.
Bitcoin Core does only gate processing of mempool messages on
NetPermissionFlags::Mempool when bloom filters are disabled [1]. While
these are disabled by default, more than 20% (see PR comment) of nodes
on the network have bloom filters enabled. These nodes all respond to
mempool messages with INV messages.
> 1. Are there any parties who still directly rely on the BIP35 P2P
`mempool` message?
I've been receiving on average about 20 mempool messages per hour to a
well-connected NODE_BLOOM Bitcoin Core node. I've seen multiple messages
from the user agent /BitcoinKit:0.1.0/, /bitcoinj:0.*.*/Bitcoin
Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Similarly, the node
responds to the clients with INVs up to the max number of 50k entries
and with smaller (bloom) filtered INVs.
0xB10C
[0]: https://github.com/bitcoin/bitcoin/pull/27426#issuecomment-1529678174
[1]:
https://github.com/bitcoin/bitcoin/blob/d89aca1bdbe52406f000e3fa8dda12c46dca9bdd/src/net_processing.cpp#LL4603C52-L4603
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x188CBB2648416AD5.asc
Type: application/pgp-keys
Size: 10796 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/7deb635c/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/20230501/7deb635c/attachment.sig>

2023-06-07 23:17:27

- reply

📅 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>

2023-06-07 23:17:26

- reply

📅 Original date posted:2022-12-09
📝 Original message: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
-------------- 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/20221209/4c646fa1/attachment-0001.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/20221209/4c646fa1/attachment-0001.sig>

2023-06-07 23:00:41

- reply

📅 Original date posted:2021-11-29
📝 Original message:Hi Ali,
I've run into this multiple times myself. I've opened a draft PR [0]
adding a rawmempooltx publisher.
You're right. In zmq/zmqnotificationinterface.cpp the
CZMQNotificationInterface is notified about TransactionAddedToMempool.
Currently, this calls NotifyTransaction() (the publisher with the rawtx
topic) and NotifyTransactionAcceptance() (the publisher with the
sequence topic)[1]. I've added a call to a new
NotifyMempoolTransaction() function (the publisher with the rawmempooltx
topic).
I'd find a mempool transaction publisher with both the raw transaction
and transaction fee useful too. However, this requires changes to the
chain notifications in interfaces/chain.h.
[0]: https://github.com/bitcoin/bitcoin/pull/23624
[1]:
https://github.com/bitcoin/bitcoin/pull/23624/files#diff-ac4b2d3a8de2c4dd41ad9d75505ea6ce4dc87a476710a9ebee8acf9bebf5cca2L146-L148
Best,
0xB10C
On 11/26/21 5:56 PM, Ali Sherief via bitcoin-dev wrote:
>
> This has also been posted on Bitcointalk
> forum: https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261
> <https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261> I
> have republished it here hoping someone more knowledgeable can post
> some insight about this.
> ----
> It appears that the ZeroMQ topic I'm listening to, "rawtx", not only
> emits a raw transaction when it appears on the mempool, but once it's
> already confirmed too.
>
> This messes with my software, causing it to add txids, addresses, etc.
> a second time inside arrays (this means that the same transaction is
> received twice in total).
>
> Array de-duping is not a viable solution long-term (because the array
> will quickly grow to be big eventually and then this has to happen
> every time a new element is added), so I'm trying to nip the problem
> from the source by instructing Core to only publish unconfirmed
> bitcoin transactions.
>
> According to
> https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra
> <https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra>
> , it is not possible to configure this from a configuration or
> command-line option. The source code must directly be edited. But
> since the codebase has changed greatly, the proposed solution no
> longer works.
>
> ----
>
> So basically, I know that something inside
> src/zmq/zmqnotificationinterface.cpp needs to be patched, but I'm not
> sure which function, or how to do it. Because I only need unconfirmed
> transactions to be published on ZeroMQ rawtx and not confirmed ones,
> it's one of the following functions that I need to patch for my own build:
>
> CZMQNotificationInterface::TransactionRemovedFromMempool
> void CZMQNotificationInterface::BlockDisconnected
>
> Both of these call NotifyTransaction() method which I assume fires a
> message on "rawtx" channel.
>
> In the Stack Exchange question I linked above, Jonas Schnelli
> suggested adding an `if (!pblock)` check, but that was several years
> ago and the function he was referencing no longer exists.
>
> But I still wonder if the pblock check is still applicable in the
> present day (i.e. if it's indicating a block the transaction is inside).
>
> - Ali Sherief
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:00:34

- reply

📅 Original date posted:2021-11-24
📝 Original message:Thanks, Michael, for writing this up. I agree that it's good to archive
events like, for example, soft-fork activations in an ML post.
All bigger pools have now included multiple P2TR spends in their blocks.
I have a few comments on what happened at F2Pool and to some extend also
at AntPool. These were pool number three and pool number five to signal
taproot readiness. I'm not affiliated with them but was happy to help
F2Pool out and return the favor[1] when they asked for help debugging
why they don't include P2TR spends. I have the permission to share some
pool internals and hope this can help make future soft-forks even smoother.
Please take my comments with a grain of salt. On the one hand, it could
be that I'm naive in believing what the pools have told me in private
communication. On the other hand, I'm not as marked from the blocksize
war as others might be.
On 11/15/21 3:42 PM, Michael Folkson via bitcoin-dev wrote:
> [..]
>
> Block 709632: The first block where full nodes started enforcing
> Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn’t
> enforcing Taproot rules and did not include any Taproot spends (some
> with high fee rates) in this block. [..] but it does lead to
> discussions for a later time on whether Speedy Trial signaling was
> effective if some mining pools signaled readiness months previous but
> then did not enforce the new soft fork rules on activation.
>
> Block 709633: Mined by AntPool. Similar to F2Pool they didn’t include
> any Taproot spends in this block and one would assume that they also
> weren’t enforcing Taproot rules though this has not been confirmed.
>
> Block 709634: Also mined by AntPool.
>
> Block 709635: The first block which included (numerous) valid Taproot
> spends (and no invalid Taproot spends) was mined by Foundry USA.
>
> [..]
>
> [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/
> [2]: https://twitter.com/satofishi/status/1459868549674065926
> <https://twitter.com/satofishi/status/1459868549674065926?s=20>
>
> [..]
While F2Pool responded they "Will upgrade soon" [2] to my question if
they haven't upgraded their nodes yet, I think they were primarily
buying time as they them-self weren't sure what the issue is. "We are
looking into it" could have been a better and more fitting response.
An F2Pool engineer reached out on the 16th (two days after activation),
mentioning they had been running Bitcoin Core v0.21.1 for a few weeks
now and upgraded to v22.0 today (on the 16th) in the hope that this
would fix their problem of not including P2TR spends. They asked if I
could create and _not_ broadcast a P2TR spending transaction for them to
check with testmempoolaccept/sendrawtransaction/getblocktemplate.
I constructed and sent a P2TR spend and asked them to check the versions
of their nodes peers too. testmempoolaccept returned "allowed": true
(expected as they were running >= v0.21.1). However, it turned out that
they weren't connected to any P2TR-spend-relaying peers. They didn't
receive any P2TR spending transaction and couldn't include them in their
block templates. It seems like this was caused by a) using addnode to
directly connect to known, external peers that hadn't upgraded. But more
importantly, b) by applying a custom patch to their node's peer
selection behavior based on a heuristic that worked for a few years but
at some point broke without being noticed (I'm not publishing details on
purpose). F2Pool has fixed this. With connections to >= v0.21.1 nodes,
they started receiving and constructing blocks with P2TR spends.
I haven't been in contact with AntPool directly and don't know details
about their situation. Alejandro De La Torre (@bitentrepreneur)
communicated with them and said I can include the following:
"I spoke with antpool after I noticed from b10c’s tweet that they had
not included P2TR [spends]. They were quick to react when I inquired.
They had not updated to bitcoind 22.0, but had tested it and were
planning to update soon. The next day they indeed updated and were able
to include a tx with a P2TR spend."
and
"[Anpool] said that the old peer issue that F2Pool faced 'may be the
issue'."
AntPool didn't provide more information to Alejandro. It's not clear to
me what the actual issues and fixes were.
I'll leave it to someone else to properly reflect on speedy trial. I,
however, want to add: F2Pool mentioned that they "upgraded to v0.21.1
several weeks ago". This indicates that they were signaling without
being ready. I don't blame them and assume they were not the only pool
just setting the version bit. IMO some of the motivations for fake
signaling: a) Immense community pressure (e.g., on Twitter) to just set
the bit and then get ready in the next six months. b) Running nodes with
custom patches. These require longer to upgrade, especially if you want
to ensure there aren't any bugs in your patches...
It's out of the scope of the Bitcoin Core project to consider people's
custom patches, and it's impossible if they are unpublished. In this
particular case, upstreaming the patch does not make sense.
However, with only just above 50% of taproot nodes[3] (more than a week
after activation), there might still be motivation for having a feature
(sometime before the next soft-fork) to alert/warn a node operator if
his node does not have any peers relaying soft-fork X transaction.
Should PROTOCOL_VERSION be bumped to show support for soft-fork
transaction relay? Or does a service flag for relay makes sense (it
seems complicated to decommission service flags reliably)? Parsing the
subver (e.g. "/Satoshi:0.21.1/") doesn't make sense as there are not
only Bitcoin Core nodes on the network. Could there be a message that is
exchanged between two nodes to indicate soft-fork readiness?
How a node operator can be alerted, besides logging, is an
implementation detail of Bitcoin Core. Maybe a getnodealerts RPC that a
node operator can hook up to his monitoring?
Additionally, for the next soft-fork where relay is affected,
instructions for mining pool signaling could state: "Upgrade to version
Z and make sure you have a few version Z peers before starting to signal
readiness".
Thanks,
0xB10C
[3] http://azure.erisian.com.au/~aj/taproot/taproot.html

2023-06-07 22:58:46

- reply

📅 Original date posted:2021-09-07
📝 Original message:Hello,
tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.
One of the ideas for SigNet is the possibility for it to be reliably
unreliable, for example, planned chain reorganizations. These have not
been implemented yet.
My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at
implementing support for reorgs on SigNet. We are looking for feedback
on which approach and parameters to use. Please consider answering the
questions below if you or your company is interested in chain
reorganizations on SigNet.
With feedback from AJ and Kalle Alm (thanks again!), we came up with two
scenarios that could be implemented in the current SigNet miner script
[0]. Both would trigger automatically in a fixed block interval.
Scenario 1 simulates a race scenario where two chains compete for D
blocks. Scenario 2 simulates a chain rollback where the top D blocks get
replaced by a chain that outgrows the earlier branch.
AJ proposed to allow SigNet users to opt-out of reorgs in case they
explicitly want to remain unaffected. This can be done by setting a
to-be-reorged version bit flag on the blocks that won't end up in the
most work chain. Node operators could choose not to accept to-be-reorged
SigNet blocks with this flag set via a configuration argument.
The reorg-interval X very much depends on the user's needs. One could
argue that there should be, for example, three reorgs per day, each 48
blocks apart. Such a short reorg interval allows developers in all time
zones to be awake during one or two reorgs per day. Developers don't
need to wait for, for example, a week until they can test their reorgs
next. However, too frequent reorgs could hinder other SigNet users.
We propose that the reorg depth D is deterministically random between a
minimum and a maximum based on, e.g., the block hash or the nonce of the
last block before the reorg. Compared to a local randint() based
implementation, this allows reorg-handling tests and external tools to
calculate the expected reorg depth.
# Scenario 1: Race between two chains
For this scenario, at least two nodes and miner scripts need to be
running. An always-miner A continuously produces blocks and rejects
blocks with the to-be-reorged version bit flag set. And a race-miner R
that only mines D blocks at the start of each interval and then waits X
blocks. A and R both have the same hash rate. Assuming both are well
connected to the network, it's random which miner will first mine and
propagate a block. In the end, the A miner chain will always win the race.
# Scenario 2: Chain rollback
This scenario only requires one miner and Bitcoin Core node but also
works in a multiminer setup. The miners mine D blocks with the
to-be-reorged version bit flag set at the start of the interval. After
allowing the block at height X+D to propagate, they invalidate the block
at height X+1 and start mining on block X again. This time without
setting the to-be-reorged version bit flag. Non-miner nodes will reorg
to the new tip at height X+D+1, and the first-seen branch stalls.
# Questions
1. How do you currently test your applications reorg handling? Do
the two discussed scenarios (race and chain rollback) cover your
needs? Are we missing something you'd find helpful?
2. How often should reorgs happen on the default SigNet? Should
there be multiple reorgs a day (e.g., every 48 or 72 blocks
assuming 144 blocks per day) as your engineers need to be awake?
Do you favor less frequent reorgs (once per week or month)? Why?
3. How deep should the reorgs be on average? Do you want to test
deeper reorgs (10+ blocks) too?
# Next Steps
We will likely implement Scenario 1, the race between two chains, first.
We'll set up a public test-SigNet along with a faucet, block explorer,
and a block tree visualization. If there is interest in the second
approach, chain rollbacks can be implemented too. Future work will add
the possibility to include conflicting transactions in the two branches.
After enough testing, the default SigNet can start to do periodical
reorgs, too.
Thanks,
0xB10C
[0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner