Open tiero opened 3 months ago
ben2077
commented
3 months ago I believe we can introduce more "global conditions“ for encoding here, such as incorporating Assets ID. This would enable support for multiple assets.
And i will write a design to explain how this works. I've been thinking about similar things recently.
tiero
commented
3 months ago Wouldn't be better to use BIP-21 to encode extra data that matters in the context of generating an invoice?
An example can be the Liquid Network:
liquidnetwork:
We could have the same
ark:
The reason is that an address is basically the script policy and any meta-protocol for assets can be used for that address (and also Reused: I am sending to you both BTC and PEPE to same Ark address)
Currently, an "Ark address" is a bech32 encoded address that contains both client and server public key. I do propose to encode the VTXO leaf script instead of the user pubkey, this will be more in line with how Bitcoin on-chain addresses work. This paves the way for going beyond simple payments, and the ability to support more transactions-type in Ark, beyond simple payment.
Why
If I send my address to a recipient, that recipient would need to extrapolate from the address
a) the pubkey b) the URL of the ASP
This works fine if we assume that the sender, recipient, and ASP all agree on the VTXO policy. This works fine if there is only one, but this will likely not scale when more advanced scripts will be introduced by the ASP (HTLC, DLC, escrow etc..)
We would get in an enumeration problem at the sending time, as is not clear without interaction what's the policity the recipient wish to have.
New address format
Trade-offs
Users and ASP needs to share the pubkeys and other PUSHDATA parameters (for complex script) out of band. This is normal with how multi-party bitcoin address work in bitcoin, as the redeem script is either hashed or hidden behing the taproot key.