pull down to refresh
0 sats \ 1 reply \ @0xB10C OP 11 Oct \ parent \ on: Additional context for "DoS due to inv-to-send sets growing too large" bitcoin
good bot
Earlier this year, I wrote about the mutated blocks ViaBTC is sending out: https://b10c.me/observations/10-viabtc-blocks-without-witness-data/
I think it's important to note that this is a pre-release in form of the first release canidate (thats what rc1 means). These binaries should be used to test the release, not necessarily for production deployments as they can still contain bugs.
Companies or projects relying on Bitcoin Core might want to update a part of their infrastructure to v28.0rc1 now (and other release candidates later) to be sure they are compatible with the release. The hope is that bugs and other problems are catched with the release candidates and not the final release!
130 sats \ 0 replies \ @0xB10C OP 12 Jul \ parent \ on: mining pool game theory during forks bitcoin
- Antpool does not want to be "liable" for a 2+ block chainsplit that could appear as an attempt to reorg blocks (its a way to guard reputation as an "honest" pool)
I don't think AntPool mining on it's own block could easily cause a 2+ block chainsplit. If they find a block on their own block, their side of the split wins by having the most work chain. All other pools will switch to it no matter where they mined before.
- Antpool is using the Tit for Tat Strategy (its a long-term strategy of mutual cooperation)
In this case, the Tit for Tat Strategy isn't working out against Foundry. It's known that Foundry will switch and mine on their own block (see e.g. https://x.com/0xB10C/status/1803082081385246738).
Do you have a theory why a pool would mine on the competing fork?
My guess is that they are either not aware of the game theory (doubtful as they've been in the industry for quite long), or they don't care enough. After all, there's maybe one or two forks a month involving AntPool, and even fewer ones where they end up loosing due to not mining on their own.
the transaction hash is customized to have the tx author's twitter handle and a bunch of leading zeroes
This part is incorrect :) I only learned about this transaction from mononauts tweet. While I did create
b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 a while ago, I'm not related to this transaction. I obviously can't prove it..fork.observer shows forks and stale blocks