pull down to refresh

Matt Carollo offers BIP 353 bountyx.com/TheBlueMatt/status/1945603864666743240
278 sats \ 9 comments \ @Scoresby 9h bitcoin
IP 353 is a huge leap forward in security and UX for common payments from hardware wallets. Yet, sadly, it’s stuck in a three-way 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.
If you are like me and don't know much about BIP 353, you can find a description here. The Bitcoin Design Guide also has some helpful discussion of BIP 353.
BIP 353 proposes using DNS for human-readable bitcoin payment addresses (kind of like how DNS resolves website names to IP addreses).
This proposal only relies on the Domain Name System (DNS) to retrieve payment information. DNS is a decentralized hierarchical naming system used to translate human-friendly domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers use to identify each other on the network. Anytime we type in a domain into a browser, we rely on this system. This use case is very similar to what human-readable addresses try to achieve, making DNS a good fit.
This proposal uses the formats “username@domain.com” and “₿username@domain.com”. It is similar to the email address format, which makes it familiar and easy to use. The ₿ prefix is an important addition for display purposes, to make it distinctly a bitcoin payment address. This provides clarity and trust to users, which is important when it comes to financial transactions.
Users create DNS entries with payment information, which can be one or more addresses of different formats, combined to a BIP 21 URI. Since address reuse is best avoided for privacy reasons, the included addresses should be reusable (like silent payments and BOLT12 offers). Single-use addresses can be used if needed, but a mechanism to rotate them should be in place.
The Bitcoin Design Guide's writeup is really extensive and talks in detail about trust assumptions and privacy implications, as well as further implementation details.
write
preview
related posts
102 sats \ 6 replies \ @optimism 8h
BIP 353 is a huge leap forward in security
From mentioned Bitcoin Design Guide's writeup:

Security & privacy

Every approach requires at least one intermediary that is being contacted to serve the payment information. This creates potential privacy and security risks that users need to understand. Key considerations:
  • Intermediaries can track requests and metadata to build profiles of users and payment patterns
  • DNS queries may leak information about payment relationships
  • Services can potentially serve different payment information than specified
If the domain (website) where the payment information is stored, is not controlled by the user, we will refer to the address as “managed”. To be clear, intermediaries cannot move funds at the user-provided address. They can only prevent payment information retrieval, or re-route funds by returning different payment information.
So what is it? Huge leap forward, or huge leap backward?
reply
100 sats \ 5 replies \ @Scoresby OP 8h
I'd be curious for @bluematt's take on the security improvements. It does seem like there is more benefit for UX than security. But perhaps he is referring to address reuse and privacy when sending to an exchange?
From later in the X thread:
With lightning replacing most of the payments use-cases of bitcoin, on-chain is left often for sending to exchanges to sell, which is a really important thing to switch to 353 for, and also is a case where 353 would let you rotate addresses whereas toast exchanges never do so that people can be confident in where they’re sending.
There’s cases where 353 will make address reuse worse, but I also think there’s cases where it won’t have an impact or could make it better.
reply
102 sats \ 4 replies \ @optimism 8h
That's ok. Matt is the author of the BIP; I'm more interested in what others think. There's definitely a tradeoff going on - as there always is.
This was among the first (if not the first) dev mail list messages after the migration to google groups. I remember thinking the group broken because there were no replies - but the discussion was mostly on the pull req.
Personally I wouldn't use this - invoice/psbt swapping is better imho, but I understand that there's a need for a canonical signature to identify the counterparty, reducing MITM risk (though i could probably still MITM anyone with my supply chain attack into your fav browser extension we shall not name to do s/@coinbase.com/@colnbase.com/)
reply
100 sats \ 3 replies \ @Scoresby OP 6h
I have not really been paying attention to silent payments/reusable addresses discussion -- but I heard some people talking about BIP 353 and it got me curious. Hence posting about it today.
Many of these things quickly get beyond my understanding, technically, and I have to revert to my own root: what do I want, and what am I willing to trade to get it?
I'd love to be able to expose a reusable payment code and receive payments in the context of an online shop. A few years ago I would solve this problem by using BTC Payserver. If there was such a thing as a reusable payment code back then, I probably could have avoided the need to run BTC Pay -- and I certainly would have traded some privacy or MitM risk to get it.
However, this was because I was mostly doing small value payments. I don't even accept onchain payments any more because of lightning. I wonder if the quest for onchain reusable payment codes is a bit misleading. Do I want/need the convenience of human readable reusable payment codes for high-value transactions?
In the current world, I try to get any payment less than 1mm sats on lightning, and for payments over that, I'd be willing to have some kind of interaction (sending an address or qr).
I wonder what the imagined scenario is where someone really wants a reusable payment code and is not willing to use lightning?
reply
102 sats \ 2 replies \ @optimism 6h
If 2 people do a payment at the same time, how do you do order matching if you had 4 orders open for that amount, with reusable payment addresses? Do you accept through LNADDR now instead of a BOLT-11 invoice? How does that work?
reply
100 sats \ 1 reply \ @Scoresby OP 6h
I use Woocommerce to set up the order flow. I just have a plugin that calls up an invoice when the customer is ready to pay. The plugin requires the user to pay a BOLT-11 invoice and click a button that says they've paid the order. I doublecheck to match the invoice on the order and the payment in my wallet, and then it's good to ship. Also, Woocommerce won't see the payment as complete until the customer pays the invoice and clicks the "I've paid" button.
(also I don't have very many customers, so I probably could do it just by matching timestamps/amounts on orders and payments -- Woocommerce is pretty easy on Wordpress, though.)
view all 1 replies
123 sats \ 0 replies \ @DarthCoin 7h
Did he asked for permission before that?
He initiated this bullshit: https://saveourwallets.org/
reply
0 sats \ 0 replies \ @nitter 9h bot
https://xcancel.com/TheBlueMatt/status/1945603864666743240
reply