0xB10C

b10c.me

Bitcoin developer and observer

Public Key

npub1kyxqqqq8n2pu7f5pthr48zqcmr2k52vrud6wxzjpg0jsqcyhs3tshfc6vv

NIP-05 Address

b10c@b10c.me

NIP-57 Address

0xb10c@bitrefill.me

Profile Code

nprofile1qqstzrqqqqre4q70y6q4m36n3qvd34t29xp7xa8rpfq58egqvztcg4cpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgdwaehxw309ahx7uewd3hkc2fvurc

Publishing to

relay.nostr.band

nos.lol

Author Public Key

npub1kyxqqqq8n2pu7f5pthr48zqcmr2k52vrud6wxzjpg0jsqcyhs3tshfc6vv

Show more details

Last Notes

2024-10-11 12:10:15

Additional context for "DoS due to inv-to-send sets growing too large"
https://x.com/0xB10C/status/1844705899455062220
originally posted at https://stacker.news/items/719038

2024-10-11 11:54:01

Yesterday, the Bitcoin Core project disclosed three vulnerabilities fixed in v25.0.
I have old screenshots and observations from the "DoS due to inv-to-send sets growing too large" which I can share now.
(the disclosure explains the bug, this is only extra/visual context)
https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/
Monitoring the connections of one of my mainnet nodes, I observed that its connections dropped from about 200 to 35 in a matter of hours (image 1)
It turned out that the P2P communication thread of the node was spending a lot of time sorting sets of transactions it wants to announce to other peers, as these sets had grown quite large.
This flamegraph showed that significant time is spent in make_heap to sort the sets... (image 2)
At some points, my node could not keep up the P2P communication with its peers and connections started to drop. Other nodes had the same problem.
https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1544593209
https://github.com/bitcoin/bitcoin/issues/27623
The sets grew large due a high volume of small one-input one-output transactions (I think something related to BRC-20) being broadcast.
(note: images 3 & 4 show tx in blocks per day, not broadcast tx)
This was amplified by peers that never announce transactions to us (e.g. spy-nodes). For them, the sets remain larger for much longer resulting in more time spent sorting. At the time, I compiled a banlist for some IPs I found to be particularly annoying.
https://github.com/0xB10C/banlist/issues/1
This DoS caused problems in block and transaction propagation. This clearly visible on the KIT DSN Bitcoin monitoring metrics.
https://www.dsn.kastel.kit.edu/bitcoin/
(image 5 & 6)
Another interesting metric is ICMP ping time compared to Bitcoin protocol ping time.
The Bitcoin protocol ping time skyrocketed, while the ICMP ping remained fairly unaffected. The nodes had problems, the servers running them were fine.
(image 7)
PR https://github.com/bitcoin/bitcoin/pull/27610 by ajtowns fixed the problem and it was back ported for the v25.0 release.
At the same time, one of the other disclosed vulnerabilities caused block propagation problems too: nevent1qqspf29q968at872u49vk2u0nzzk03lxv478kq0lz5m609u49cf9hdspzemhxue69uhhqatjwpkx2un9d3shjtnrdakj7q3qkyxqqqq8n2pu7f5pthr48zqcmr2k52vrud6wxzjpg0jsqcyhs3tsxpqqqqqqz7ep4px ...
https://nostr.download/1b9719c6e0d5c348f6fe3198db0c49763be3deec66fa73cdc7c2658005166b0f.webp
https://nostr.download/4a3e322f4421098529a5c4fe5f31af7dde22e84301402f20fa6a57cdc253b8f8.webp
https://image.nostr.build/7c3a1fa7d7c657b93cbeef0013892c0f9c0a9ebdeebb39a4fdb2246e4b24291f.jpg
https://image.nostr.build/2ab2a033673455f5e368ba78f9ce21f2e544f9607e015e6ea29e96fbd0e74a37.jpg
https://nostr.download/6666a7e872bafbac6e78e925572035b1081010c2f67caed46db7b8749047d744.webp
https://nostr.download/1eb132e75abd75fe3be0003619dbf032efdf186213452ee16765346ea7997bab.webp
https://nostr.download/79124e8e38f61b3be9891dec359d5bf130bd2992eeab48a93792209799020d8a.webp

2024-10-11 11:43:16

Turns out ViaBTC's mutated blocks caused problems but also helped in finding a vulnerability in Bitcoin Core before v25.0..
https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/
https://b10c.me/observations/10-viabtc-blocks-without-witness-data/

2024-10-11 10:20:01

Bitcoin Core: Disclosure of hindered block propagation due to mutated blocks
https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/
originally posted at https://stacker.news/items/718945

2024-10-11 10:19:19

Bitcoin Core: Disclosure of DoS due to inv-to-send sets growing too large
https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/
originally posted at https://stacker.news/items/718944

2024-08-02 12:08:19

Stats on compact block reconstructions
https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052
originally posted at https://stacker.news/items/632109

2024-07-15 15:04:23

- reply

I usually say "zero ex B ten C" or just "B ten C"

2024-07-15 14:56:25

Mining Pool Game Theory during Forks
https://b10c.me/blog/014-mining-pool-game-theory-during-forks/
originally posted at https://stacker.news/items/609264

2024-07-11 13:53:27

mining pool game theory during forks
https://x.com/0xB10C/status/1811390920744468502
originally posted at https://stacker.news/items/604715

2024-06-21 13:40:16

https://image.nostr.build/ecc450ba6b059f3708e230fcdc047d46aa8e948ecdb81ef6cc2e47eb369e55a9.jpg
During today's fork between ViaBTC (losing) and AntPool (winning), AntPool & a few other pools briefly mined empty blocks on AntPools block before switching to ViaBTCs.
https://image.nostr.build/07a809085acc8ff719173734359de295d371f8b7e04a33810feb30fbdf1e13e4.jpg
Foundry ended up mining a block on AntPool's block causing AntPool, despite giving up on it's block, to win.

2024-06-18 15:12:06

Foundry won against AntPool's competing block by switching to their own block
https://x.com/0xB10C/status/1803082081385246738
Nothing crazy, just interesting to see this playing out.

2024-05-30 22:08:17

Who mined on which previous block during the fork at height 845626?
https://x.com/0xB10C/status/1780611768081121700

2024-04-19 21:18:43

- reply

Thank you!

2024-04-19 20:45:04

25 blocks to go, halving stream is live
https://www.youtube.com/watch?v=C6D9OEjnWmA

2024-04-19 10:07:13

- reply

Isn't that what my NIP-05 address is for?

2024-04-19 10:05:17

- reply

The MIT DCI build https://pooldetective.org/ in the past, but this looks very abandoned now..

2024-04-17 20:51:22

- reply

Not too difficult, just time consuming

2024-04-17 15:59:11

Looking at the merkle branches that mining pools send to miners as part of stratum jobs, it's clear that the BTCcom pool, Binance pool, Poolin, EMCD, Rawpool, and possibly Braiins* have exactly the same template and custom transaction prioritization as AntPool.
https://image.nostr.build/33d5ac0f59082e8fbb5d02ccd9a50dccea43327ae97e10db06effaede7f7c064.jpg
Stratum v1 jobs include (parts of) the coinbase transaction and the merkle branches a miner needs to compute the merkle root. If all branches are equal across pools, the block template is exactly the same.
This is a smaller merkle-tree with the stratum job branches highlighted.
https://image.nostr.build/dab683037cc63f0e4805ae16561800dd342dd53dbb646c91e6c066044a51b2d6.jpg
Here, branch0 is the txid of the first transaction in the block after the coinbase.
In the AntPool/Binance/BTCcom/.. template, it's a manually prioritized transaction paying 9.03 sat/vbyte https://mempool.space/tx/c938e8027a7fba782a092695a53d37654021bf20df71ca91b4a6daa9198b0c73
Many of the other pools didn't prioritize a transaction and included the highest feerate transaction https://mempool.space/tx/96608dc747677d6dfbc3a2b37f8a0146abae132799b13c130066bd3716fdf91a paying 301 sat/vbyte. ViaBTC prioritized another transaction and has a vastly different template.
This indicates that F2Pool currently is not using the AntPool templates, even if they share the the same custody provider. We know from multiple occasions that F2Pool has been building their own templates (https://b10c.me/o11, https://b10c.me/o9, https://b10c.me/o8)
Note that SigmaPool and SecPool both seem to share the same template (distinct from AntPools template). Two names, but probably one pool.
Some overlap in the first branches of distinct pools is expected as these branches consist of few (usually high feerate) transactions. For example, Ocean's "default" and "core" templates overlap up to branch3. At least the first 15 tx (2⁴ - 1) in the template are equal.
* similar to EMCD in the picture, Braiins sometimes differs from AntPool in the later branches of the template. This could indicate they're only helping with AntPools transaction accelerator and directly syncing with AntPools mempool, causing occasional differences in templates.
I've heard speculation about this all being liked to an FPPS partnership with AntPool/Bitmain.
Bitmain insures against bad pool luck but you have to use Bitmains templates/transaction prioritization and pay the mining reward to the insurer for later distribution.
Essentially a pool of pools and a lot of mining centralization.

2024-04-02 11:17:10

Invalid F2Pool blocks 783426 and 784121 (April 2023)
https://b10c.me/observations/11-invalid-blocks-783426-and-784121/

2024-03-28 14:38:33

Happy Birthday, LinkingLion!
A year ago I reported about LinkingLion, an entity that's presumably linking transactions to IP addresses and has been opening hundreds of connections per minute to my monitoring nodes.
An update: https://b10c.me/blog/013-one-year-update-on-linkinglion/

2024-03-28 14:37:46

Update on LinkingLion: Reduced activity and a statement by LionLink Networks
https://b10c.me/blog/013-one-year-update-on-linkinglion/

2024-03-20 20:59:31

- reply

Also: find bugs at companies that pay a higher bug bounty.

2024-03-20 20:56:49

- reply

I agree with what you say. At the time I only saw a very very small chance that something like this could be exploitable on a pool this big..

2024-03-20 14:00:41

- reply

tl;dr: ViaBTC didn't check the header merkle root in their P2P client. Sending a block message with an old header and a modified coinbase transaction caused them to SPV mine on the old header for 30s at a time. I responsibly disclosed this to ViaBTC, and they awarded 2000 USDT.

2024-03-20 13:58:08

In January, while investigating a misbehaving client on the Bitcoin P2P network, I found a vulnerability in ViaBTC's SPV mining code that allowed a remote attacker to waste their 60 EH/s hashrate by sending a single, crafted Bitcoin P2P message.
https://b10c.me/blog/012-viabtc-spv-vulnerability-disclosure/

2024-03-18 13:03:17

ERROR: AcceptBlock: bad-witness-nonce-size…
You might have seen this in the debug log of your listening Bitcoin Core node. I dug into the origin and found that ViaBTC's mining server broadcasts mutated blocks without witness data:
https://b10c.me/observations/10-viabtc-blocks-without-witness-data/?n

2024-01-29 15:02:00

I took a look at non-standard transactions in the last 117k blocks. Here's an overview:
https://b10c.me/observations/09-non-standard-transactions/?n

2023-11-22 08:01:25

- reply

They were all picked up by other miners

2023-11-21 12:08:16

My miningpool-observer project recently reported six OFAC-sanctioned transactions as missing from blocks.
Four of these transactions were likely filtered by F2Pool. This is the first filtering based on OFAC sanctions I've seen.
More in: https://b10c.me/observations/08-missing-sanctioned-transactions?n

2023-10-09 05:58:23

- reply

hehe

2023-09-28 15:26:46

wrote down my notes on the invalid block at height 809478
tl;dr: testing new mining pool software on mainnet can indeed get you burned - especially if it already didn't work on testnet
https://b10c.me/observations/07-invalid-block-809478

2023-09-27 10:32:20

- reply

It seems like MARAPool had a transaction ordering issue.
66dfefcdc3eeec2745c11f511f6068d62f34c34c767ba0feed47f63f01ccc2d8 is the 6th tx in the invalid block.
It spends from 7d18f0eefce0497b5d0c9b61fdf816b7744587c7e5e57acc53de71d1dae59725, which is the 1454th tx in the block.

2023-09-27 09:24:12

MaraPool mined an invalid block at 809478 on mainnet. I observed the block on 9 out of 9 nodes.
ERROR: ConnectTip: ConnectBlock 000000000000000000006840568a01091022093a176d12a1e8e5e261e4f11853 failed, bad-txns-inputs-missingorspent, CheckTxInputs: inputs missing/spent
https://void.cat/d/3XxZTGnzrUdNhxHkCJ5ENg.webp

2023-05-29 15:32:29

- reply

The block looks fine on miningpool.observer:
https://void.cat/d/GEiiJTGRsBMExdJYsfgn7w.webp
https://miningpool.observer/template-and-block/00000000000000000000ef263c1a23ba30872e9982352562df5e84115b806050

2023-05-29 15:32:07

- reply

It's this one apparently: https://mempool.space/block/00000000000000000000ef263c1a23ba30872e9982352562df5e84115b806050

2023-05-10 22:13:17

more reorgs https://void.cat/d/J8YTKxTAnMTTY6evHzi3N.webp

2023-01-18 14:30:01

#[1]

2022-12-22 18:00:20

- reply

says seen on:
- wss://nostr-pub.wellorder.net
- wss://nostr-relay.wlvs.space
- wss://relay.damus.io

2022-07-11 15:39:13

- reply