Bitcoin v28 looks like it’s gonna be a banger
Login to reply
Replies (24)
Interesting, why do you think that?
Oh? Should I wait for the list show to hear about it or could you elaborate here?
What got merged that you're excited about?
Looks like IBD is getting ~30% faster, full-rbf by default, and pay-to-anchor is now standard (SUPER useful anchor outputs for CPFPing transactions, making it easier to manage fees for presigned tx protocols, like lightning but other applications too!), and i am OVER THE MOON about the move to cmake for the build system
note140h66333xtkhstjnp5lj9e0s2ssrvcrqa6cut2q0zk72ezk0uhtqtr95hm
The IBD is only faster for pruned nodes, but otherwise yes banger indeed!
Yep! Super excited! I tun a couple pruned nodes on laptops.
Thanks for doing all that work!
Sweet. Definitely going to be testing out the faster ibd
Only for pruned nodes? Using a checkpoint or assume valid or similar?
30% is a huge improvement.
Full RBF is default for my nodes, glad to see it merged.
Pay-to-anchor I don't grok.
Cmake also escapes me for understanding impact but I'm C++ retarded so if it's not cargo build hidden behind a just command within a nix shell, I don't follow. 😅
Could you please point to commits / PRs that made 30% improvements to IBD? I haven't been following project for a while....
Nice. So now my dbcache increase does even more for speed up!
Gotta get your zaps setup. I just tried to send you some sats.
Right now with a lot of presigned protocols (like lightning commitment transactions), you include a separate output thats small so that if you need to fee-bump the transaction you can CPFP that output. One problem with this is you need to have some funds locked up in this anchor. Another is that for something like lightning, each side needs to have an anchor. And also anchors are sort of unique and ad hoc. Instagibbs has been working on ephemeral anchors which are like a standardized 0-value anyone can spend output. So you dont have funds locked up, you only need one anchor and either party can bump it, and its composable with other protocols. The actual output is an OP_TRUE and then a little two byte tag. This release of bitcoin standardizes that output so nodes will relay those transactions. They’ve been consensus valid, but until now you would have had to hand them to a miner
Indeed, and dbcache will also help connect blocks faster in v28

GitHub
validation: don't clear cache on periodic flush: >2x block connection speed by andrewtoth · Pull Request #28233 · bitcoin/bitcoin
Since #17487 we no longer need to clear the coins cache when syncing to disk. A warm coins cache significantly speeds up block connection, and only...
Will do that soon!
So this is a step toward ephemeral anchors or just an orthoganal improvement for anchors?
Sent via DM for now. Thank you for what you do.
Why do folks think RBF default is a good thing? I always felt it had hidden dangers.
It's fine if you don't accept 0-conf. Not running it consumes significantly more bandwidth now because 95% of miners run it so your node is constantly having to reconstruct blocks after they are mined.

GitHub
policy: enable full-rbf by default by 1440000bytes · Pull Request #30493 · bitcoin/bitcoin
This pull request enables full rbf (mempool policy) by default. #28132 was closed recently with this comment.
Rationale:
Full RBF config option ...
It sure is 😁
