reply on: Matt Carollo offers BIP 353 bounty \ stacker news ~bitcoin

pull down to refresh

100 sats \ 5 replies \ @Scoresby OP 13h \ parent \ on: Matt Carollo offers BIP 353 bounty bitcoin

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.

102 sats \ 4 replies \ @optimism 12h

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/)

100 sats \ 3 replies \ @Scoresby OP 11h

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?

102 sats \ 2 replies \ @optimism 11h

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?

100 sats \ 1 reply \ @Scoresby OP 11h

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.)

102 sats \ 0 replies \ @optimism 10h

WooCommerce is nice as an order-to-sats system (for digital goods) and yeah, BOLT-11, it's the only thing that makes sense from a "good design" perspective.

What I think that BIP-353 tries to solve is that you can have an authenticated address for on-chain transactions rather than an address that can be easily MITM'd (for example by browser extension malware) whereas with DNSSEC you can authenticate the input (as long as you don't get exploited in fetching the wrong expected key).