Open alessandro-saglimbeni opened 4 years ago
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?
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
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.
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.
@alessandro-saglimbeni makes sense.
Another thought: We could embed the asset in addresses as well, though that would make confidential addresses absurdly large.
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?
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 VALIDliquidnetwork:<addr>?assetid=<asset>
is VALIDliquidnetwork:<addr>?amount=0.01&assetid=<asset>
is VALIDliquidnetwork:<addr>?amount=0.01
is INVALID, because the assetid
is missingConvenient and makes total sense, ACK from Bull Bitcoin / Cyphernode
Implementation merged into our wallet library, apps should follow soon
https://github.com/Blockstream/gdk/commit/ca9b05ef78826021580e1085fab11667f1cb0c1b
FWIW I just confirmed on Green v.3.3.3 it works
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?
AssetID should be: 6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d
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
For anyone stumbling upon this, the prefix that was finally adopted by liquid players is liquidnetwork:
.
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.
@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
BIP0021 defines the rules for payment requests, we need something similar for Liquid (or other elements instances), thus we should define:
liquid
is proposed as preferred nameprecision
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?