Adapt BIP21 payment requests for Liquid

[alessandro-saglimbeni]

BIP0021 defines the rules for payment requests, we need something similar for Liquid (or other elements instances), thus we should define:

• the name of the network prefix, for Liquid specifically liquid is proposed as preferred name
• additional parameters
  • assetid, to refer to the user desired asset
  • amount, amounts should probably follow BIP21 guidelines and be specified in the URI as decimal BTC, irrespectively of the issuer defined precision (examples). Though the clients – both when generating and parsing the URI – should keep in consideration the precision specified by the asset issuers, as that is the amount that issuers ultimately inted to be displayed to users.

I wonder if this is compatible with elements-qt, especially the assetid part, as the amount would be treated the same as Bitcoin already does.

Anyone have different ideas/objections to this?

[Kukks]

ACK from the BTCPay end. We're currently generating with a uri scheme of liquidnetwork but liquid makes more sense.

I am wondering if liquidv1 would make more sense in terms of elementsd since it would be easier to reuse the chain name?

[afilini]

one more thing we need to define is the behavior in case the assetid field is missing (i.e. if it's considered "required" or not).

we could either fallback to L-BTC or reject the address as invalid

[greenaddress]

The reason liquidnetwork was picked is because as a uri handler liquid could have more easily clashes. In any case given liquidnetwork is already deployed and given the url is mostly in qrcodes and links and machine processed i don't see a reason to change it from liquidnetwork to liquid.

[alessandro-saglimbeni]

define is the behavior in case the assetid field is missing (i.e. if it's considered "required" or not).

We've had some discussion, better to have this parameter being a required one, for any asset, reason being that it's better to fail hard, than result in the wrong asset being sent accidentally.

[instagibbs]

@alessandro-saglimbeni makes sense.

Another thought: We could embed the asset in addresses as well, though that would make confidential addresses absurdly large.

[alessandro-saglimbeni]

embed the asset in addresses as well, though that would make confidential addresses absurdly large.

mmh I think confidential addresses are already quite large, absurdely so sounds a bit extreme. After all payment requests are already widespread and understood enough, maybe better to stick to BIP0021 with the above mentioned adjustments?

Is there any other relevant adjustment needed?

[afilini]

just a minor correction: the assetid parameter is always required if an amount has been specified. It's important to highlight that, otherwise the spec would make liquidnetwork:<address> an invalid URI, which doesn't sound right to me.

So, to recap:

• liquidnetwork:<addr> is VALID
• liquidnetwork:<addr>?assetid=<asset> is VALID
• liquidnetwork:<addr>?amount=0.01&assetid=<asset> is VALID
• liquidnetwork:<addr>?amount=0.01 is INVALID, because the assetid is missing

[FrancisPouliot]

Convenient and makes total sense, ACK from Bull Bitcoin / Cyphernode

[afilini]

Implementation merged into our wallet library, apps should follow soon

https://github.com/Blockstream/gdk/commit/ca9b05ef78826021580e1085fab11667f1cb0c1b

[FrancisPouliot]

FWIW I just confirmed on Green v.3.3.3 it works

[bogdyak]

Hello Can't open liquid link with Android Green wallet There is my URL: liquidnetwork:1GoKVEAysuPwb2DDFctHvoC4shcD7H6Afz?amount=0.01&assetid=BTC Am I doing something wrong?

[FrancisPouliot]

AssetID should be: 6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d

[alessandro-saglimbeni]

Coming back on how amounts should be represented:

amounts should probably follow BIP21 guidelines and be specified in the URI as decimal BTC, irrespectively of the issuer defined precision (examples). Though the clients – both when generating and parsing the URI – should keep in consideration the precision specified by the asset issuers

I wanted to re-post here a few examples of what that means, based on some real Asset Registry assets:

• if a merchant asks 10.00000000 USDt they're asking amount=10.00000000 because precision=8 for assetID=ce091c998b83c78bb71a632313ba3760f1763d9cfcffae02258ffa9865a37bd2

• if a merchant asks 10 SCAM they're asking amount=0.00000010 because precision=0 for assetID=123465c803ae336c62180e52d94ee80d80828db54df9bedbb9860060f49de2eb

• if a merchant asks 10.00 IPA they're asking amount=0.00001000 because precision=2 for assetID=beebee1a548fbb20280e539b697de076d87859a25c2983ebc55f2d8bec40abc3

[kilrau]

For anyone stumbling upon this, the prefix that was finally adopted by liquid players is liquidnetwork:.

[whitslack]

Also for anyone stumbling upon this: the URI scheme that Green requires for Liquid Testnet addresses is liquidtestnet:, and it is unfortunately case-sensitive despite that IETF RFC 3986 § 3.1 specifies that URI schemes are case-insensitive, meaning that QR Codes must encode it in byte mode rather than the more compact alphanumeric mode. The amount and assetid parameter names are also case-sensitive. A minor win is that the asset ID (hexadecimal string) may be specified in uppercase, so it can be encoded in alphanumeric mode.

[RCasatta]

@whitslack about the case-sensitiveness of the schema, I uppercased the schema in rust-bitcoin because of the RFC you mention, however I had to revert it back, because Android fails to recognize uppercase schema. Luckily most qr codes library use mixed mode, so they switch to alphanumeric mode if it is more efficient. I would also add that blech32 addresses should be uppercased to leverage the alphanumeric mode, this should be supported around as far as i know