search

TBD54566975 / dap

Decentralized Agnostic Paytag
6 stars 2 forks source link

Money Address scheme for BOLT12 offers (reusable payment codes) #30

Open aparkersquare opened 1 week ago

aparkersquare commented 1 week ago

BOLT12 provides "offers" (reusable payment requests) which are a way to re-use the same address to receive multiple payments. This is well-suited to putting in a DAP registry.

aparkersquare commented 1 week ago

My first thought was to use bolt12 as the scheme. I thought I'd check for any prior art in the bolt12 spec, and on the bolt12.org design page I found a screenshot that shows a payment code, and it uses bitcoin:lno.

Thus two options at the moment

BTC BOLT12 Offer urn:btc:bolt12:LNO12345ABCDE

BTC BOLT12 Offer urn:btc:lno:LNO12345ABCDE

aparkersquare commented 1 week ago

I've also been advised that BIP21 is using lno= for bolt12 lightning offers.

So it seems like the proposal should be

BTC Lightning Offer (BOLT12) urn:btc:lno:LNO12345ABCDE

However there has been a suggestion that we should support BIP-21 in DAP instead of BOLT12 directly.

BIP21 works at a different level, it's less of a protocol and more of a way to share the addresses, like DAP but bitcoin-specific.

If we were to support BIP21, theoretically the btc:addr scheme could be removed and replaced by a bip21 scheme that supported both on-chain and lightning (both BOLT11 and BOLT12).

This would also mean DAP would automatically get any new BIP21 features. But it forces DAP apps to understand BIP21.

Of course, it would be possible to support both the underlying protocols and BIP21.

aparkersquare commented 1 week ago

The other thing this made me realized is that the btc:spaddr could possibly just have been incorporated into the btc:addr scheme. The SP address is not an actual on-chain address, but for DAP purposes might be able to be treated as a valid "receive address".

The question is whether the sending app would need to make a distinction. We don't make a distinction between P2PKH, P2SH and segwit addresses.

I think it might depend on the app. In some cases the app may need to distinguish them, as you need to know the sending UTXO/key details in order to resolve the (unique) on-chain address. This may be a non-trivial change for some apps.

If we merged the schemes, apps could check the prefix if needed. If we keep the schemes separate it shouldn't be hard for apps to treat them the same.

I lean towards keeping them separate.

aparkersquare commented 2 days ago

Supporting BOLT12 directly seems consistent with the current approach in DAP. Adding BIP21 would require clients to pull in another library to support that.

It seems reasonable to add support for BOLT12 now. This doesn't preclude us adding BIP21 in the future.