On the software wallet side, *two* wallets have already stepped up and merged code that will claim the bounty! Given it was in less than ten days I'll be paying both of them out.
That still leaves the bounty for hardware wallets, however.
If you're a hardware wallet developer, now is a great time to dig into BIP 353. There's a few software wallets that will be including proofs for you, so its time to start validating and get the great UX benefit that comes with it!
nostr:note1z25hnu85495ge5uxm42z9aqa9m40n5eqy7vkyzccx4c3qggkd40s68ac6n
Matt Corallo
matt@bitcoin.ninja
npub185h9...wrdp
10th known contributor to Bitcoin Core. Now Full-Time Open-Source Bitcoin+Lightning Projects at Spiral (Part of Block).
Notes (9)
Underrated fact: if there’s not enough demand for (truly) censorship-money, Bitcoin fails.
Not just people won’t use it and it’ll fade (which is true), but literally someone’s gotta pay the miners, and there’s no indication anything but a real demand for censorship-resistant money will do.
I still think about how one of the very first academic papers ever written about bitcoin predicted it would fail because there’s no incentives to run a node and thus no one would and then transactions wouldn’t relay.
The CLARITY Act passed with section 110 intact. Y’all know what to do….
It’s time to call your senators! saveourwallets.org has the numbers, get to it!
nostr:note1lunpj7cfh2rhftlaur8ufgvk05y5gptg3552xg93cmddd4l5tqzqfm9apu
BIP 353 is a huge leap forward in security and UX for common payments from hardware wallets. Yet, sadly, its stuck in a three-w
ay chicken-and-egg problem between the software wallets that people use, the hardware wallet firmware, and recipients.
No one wants to do the work to be a first-mover when the other two legs don't exist yet.
So, to get off zero, lets try a bounty.
I'm offering $1000 (payable only in Bitcoin to a BIP 353 HRN) each for the first hardware wallet and (on-chain, hardware wallet-supporting) software wallet to support sending to BIP 353 HRNs.
For a hardware wallet, this should be easy, just detect the PSBT field for a DNSSEC proof, validate it, and display the HRN for verification instead of (or in addition to) the actual address. You don't have to use https://docs.rs/dnssec-prover to do the validation, but I imagine it will be easy. The feature has to exist in the released default firmware for the hardware wallet.
For a software wallet, there's only a few more steps, support detecting a BIP 353 HRN in the send-to UI, do the DNS lookup (again, dnssec-prover should make this easy, if you want), build the proof, and include it in the PSBT you provide to hardware wall
ets. Also store the HRN (and maybe DNSSEC proof) so that the transaction history shows it. The default sending methods (GUI/CLI/whatever) have to support accepting HRNs and should handle them just like regular addresses. You don't have to support silent
payments, but of course its good to as well. Support has to be in an official release.
A hardware wallet that also provides a software wallet doesn't get to claim both bounties. Releases which satisfy the bounty must be made before December 31, 2025.
Sheesh, how do I sell my name and get a windfall from a bitcoin treasury company?
Mining centralization is still horrible. Most users prefer non-private custodial wallets. Next gen wallets are lying about their trust model in marketing and people are eating it up.
Things aren’t terrible but if you’re this bullish you aren’t paying attention to anything but price.
nostr:note17aycx39t3dgca022wd5pq0laa0nyv29778l2yhrqyv4wrcclw2vs9eyc2u
This is not an acceptable UX. Too many wallets keep doing it, stop.
nostr:note1v3sz93hjugmmvy8u0qkefgah42sdtxlyvgvgxwugkxexe9u89j5qj6p9uh
I am once again begging wallets to come up with a better user experience than having to select between a list of technologies users have never heard of on the receive screen.
One. QR. Code. Nothing more. You don’t need more, I promise.