Official account for the braidpool decentralized Bitcoin mining software. Decentralize share accounting, payout, and tx selection. discord.gg/pZYUDwkpPv
Earth
- Tweets 479
- Following 85
- Followers 1,007
- Likes 683
braidpool retweeted
Sharon (@nkatha_kk) is a developer based in Nairobi 🇰🇪, and an alumna of @DadaDevs and @btrust_builders.
She completed the 2026 BOSS Challenge, where she made her first major Bitcoin open-source contribution.
Her grant-funded work focuses on @braidpool's mining infrastructure: strengthening Stratum V1 reliability, addressing gaps in protocol implementation, and improving scalability.
This work helps connect existing mining ⛏️ equipment with decentralized pool software.
Nkatha also helps lead discussions at @BitDevsNBO meetups, supporting learning and knowledge-sharing within the local developer community.
1
18
50
1,983
braidpool retweeted
Ansh (@AnshSharma54105) is a developer based in India 🇮🇳 and one of the first developers to receive direct Btrust grant funding outside Africa.
His work focuses on @braidpool, a project developing decentralized Bitcoin mining ⛏️ pool infrastructure.
With the long-term grant, Ansh will focus on performance, scalability, and network resilience, helping Braidpool remain responsive and reliable as participation grows and network conditions change.
1
10
33
1,502
braidpool retweeted
Our 2024 alumnus, @braidpool contributor & current @OpenSats/@HRF grantee @zaidmstrr dropping some serious alpha for this year’s cohort on going from a summer internship → long-term contributor → full-time Bitcoin open-source dev.
Alumni pulling the next cohort forward!
7
26
719
We have a side project on AI for this @summerofbitcoin with @Aru__09, @ParthDudhe07, @AnshSharma54105, and @rasesh_shetty. AI-based, automatic transcription of conference talks! Tons of ideas!
Check out the beta: genesis-kb.github.io/
Join the Discord: discord.gg/4fK7aRPTYQ
7
7
376
This summer we've accepted 2 @summerofbitcoin students, @priyaashuu and @KKinra80406! Priya was a SoB student last summer and has been a steady contributor wrangling our front-end and we look forward to working with @KKinra80406! Look for our launch this year!
2
6
21
591
We'll do that too. Part of this analysis is to figure out WHICH covenant works for Braidpool, and it's not CTV, unfortunately. We'll champion CCV soon.
1
1
2
29
We're super excited about Binohash and have a proposal to use it to enable Braidpool payouts. What do you think? (CCV/MATT is the correct covenant opcode for Braidpool, not CTV)
discord.com/channels/1270418…
Binohash: Transaction Introspection Without Softforks
A first transaction has been mined demonstrating a limited form of covenants using only existing Bitcoin script functions. This development potentially eliminates the need for a Bitcoin light client in BitVM bridges, simplifying the construction and improving security.
We hope this development furthers research on the possibility of creating introspection and covenants-style functionality on Bitcoin without the need for softforks, and advances discussions on the usability of covenants in Bitcoin and the use-cases they enable.
Many thanks to everyone at @idealgroup, as well as @PortlandHODL and the Slipstream team at @MARA for patching their nodes to mine these wacky transactions.
Full paper in the comments 👇
1
1
7
1,086
Braidpool needs more stars so I can get the Claude 20x Max plan!
github.com/braidpool/braidpo…
5
12
476
BitVM may be a very, very good solution to ensuring payouts are correct in Braidpool. Join our discord if you want to work on this, HELP WANTED!
BitVM2 made Bitcoin bridges possible. BitVM3 cut on-chain costs by 1,000x with garbled circuits. Now @liameagen's breakthrough scheme, Argo, cuts off-chain costs by another 1,000x—making off-chain computation on Bitcoin truly efficient and practical.
👷🏻♂️👷🏻♂️👷🏻♂️
3
177
Congratulations to @zaidmstrr for receiving a grant to work on Braidpool! The Audit Mode he's been working on supports the creation of a hashrate derivatives market, a key piece of infrastructure in bitcoin that most mature commodities markets have.
opensats.org/blog/fifteenth-…
2
4
10
903
Here's some more details on audit mode and why we wanted to create it
github.com/braidpool/braidpo…
1
4
36
FWIW our payouts will be based on difficulty, not number of shares. So it's not a problem for different miners to have different targets. We aim for all miners to get one share per block, which is about a 2% share variance over a 2 week payout period.
2
29
In other news, Braidpool is an open source project with zero pool fees, not a company and we have no marketing department.
We will win on merit or not at all.
Join our discord and shoot down our ideas!
1
5
392
A share is a full and valid bitcoin block, that didn't meet bitcoin's PoW target. It commits to the coinbase, and the payouts.
In Braidpool, every node can compute this from the share chain, so we don't even need to communicate the block. Every node can independently compute it.
1
3
97
The "On Deck List" is the share-chain in Braidpool/P2Pool. You need consensus on it in order to decide who to pay. A valid share by definition pays the right amounts to the right people. But you can't do that unless all miners have the same view of the share-chain (consensus)
1
3
68
Congratulations to DMND! Everyone should be using either DMND or OCEAN until Braidpool is online.
But, you shouldn't 𝐰𝐚𝐧𝐭 to build your own blocks. Because someone else on the same pool is building a less profitable block than yours.
Braidpool will fix this.
DMND Pool Now Open To All Miners, With SOC 2 Compliance and Stratum V2 Support bitcoinmagazine.com/bitcoin-… via @bitcoinmagazine
3
10
3,480
Your pool is a financial counterparty. They owe you money. It's actually right for the miner to do diligence on the pool. It's backwards for the pool to do KYC on the miner.
2
24
Congratulations to Braidpool contributor and @bitshala_org grantee @zaidmstrr on getting his second PR merged into Bitcoin Core!
✨New follow-up bitcoin-core change opprotunity✨
📢mentioned in: #32821 rpc: Handle -named argument parsing where '=' character is used
github.com/bitcoin/bitcoin/p…
"> I'm wondering if there's a different way we can go about this without adding another table of arguments that need special treatment.
I'm also not a fan of separate tables and suggested the following change to unify them earlier: b998cc52d51b48db9271fdba0bd69e9aaccb7999 ([tag](github.com/ryanofsky/bitcoin…)). This change is just a refactoring and could be a followup.
> Perhaps we could move named argument handling and string to json conversion server side?
I think moving logic server side would avoid need for duplicate tables, but not actually make the code or logic simpler because the current syntax for distinguishing named parameters is inherently ambiguous. (It probably would have been better to require named parameters to begin with `-` to avoid ambiguity. It could also be better to try to parse *every* argument as JSON and just fall back to passing strings if they are not valid JSON to avoid the need for the conversion table.) I feel like current PR just makes some small tweaks to parsing to make the current syntax work a little better, and it adds good test coverage. If we follow up this PR with b998cc52d51b48db9271fdba0bd69e9aaccb7999 or incorporate those changes here, the client code should be better documented and more maintainable too." - ryanofsky
2
7
10
3,981