📅 Original date posted:2018-07-24
📝 Original message:When I use the example of HTML forms …
```test.html
<!DOCTYPE html>
<html><head><title>test for URI schema</title>
<body><form method="get" action="./test.html">
<select multiple name="attr">
<option value="val1" selected>1</option>
<option value="val2" selected>2</option>
<option value="val3">3</option>
</select>
<input type="submit" value="send" />
</form></body></head></html>
```
The resulting URI is:
file:///tmp/test.html?attr=val1&attr=val2
That means that a URI attribute is not necessarily singular and can
indeed occur multiple times.
So as we do not have athority in our URI…
for URI = scheme:path[?query][#fragment]
where query=[key1=value1[&key2=value2]]
…under the circumstance that path has a newer standard we can implement
fallback with: query=[path=newerversion[&path=evennewerversion]]
…as our path is the address, resulting in e.g.:
bitcoin:p2pkh?[amount=value][&address=p2sh][&address=p2sh-p2wpkh][&address=bech32]
the effect should be
1. old clients ignore address attribute
2. supporting clients select the address attribute over the address
given in path *if* they support the format
3. future address formats do not need a new attribute
open to me would be:
* the order of the attributes and how this should be recognized/priorized
* is there any precedence for that multiple use of an attribute in URI
schemes?
I think order of attributes should remain irrelevant, thus supporting
clients should check all attributes of the same name and attributes
should be defined for repetitive (like address) or not (amount) in the
BIP. This will still not support sending different amounts to multiple
addresses and be consistent with the older version of the URI scheme.
On 24.07.2018 14:05, Federico Tenga via bitcoin-dev wrote:
> Hello everyone,
>
> With my team we are working on a walleting application which ideally will
> generate a bech32 address when receiving from a bech32 compatible wallet,
> and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.
> However, it is of course impossible for the payee to know in advance the
> technological capabilities of the payer, so a solution could be to encode
> in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy
> wallets only see the P2SH address, while new wallets can also see the
> bech32 address and use it to perform the transaction.
>
> In particular, to keep compatibility with BIP21, the <address> field of the
> URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.
> <segwitaddress> or <bech32address>), which will be ignored by legacy
> wallets, can be used to encode the bech32 address. The assumption here is
> that the wallets using such scheme will monitor incoming transaction both
> on the P2SH address and on the bech32 address.
>
> I did some research around and I did not find any proposal addressing the
> same issue, so my questions are (i) does anybody already proposed something
> going in the same direction and (ii) do you see any major drawback in the
> BIP21 compatible scheme proposed in this message?
>
> Thanks in advance,
>
> Federico
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180725/fdd0fc27/attachment.sig>;
vv01f [ARCHIVE] /
npub16w…ws45h
2023-06-07 18:13:51
in reply to nevent1q…ma7t
Author Public Key
npub16wxlvxa5c25gcawkfcf7v6w8ray5scwm8t8y0qkxpfr3h5c5j0aqhws45hPublished at
2023-06-07 18:13:51Event JSON
{
"id": "a66cc981433b5bc1915ad958c8f218e3bef001307588f20ba90772fc7d4c239b",
"pubkey": "d38df61bb4c2a88c75d64e13e669c71f494861db3ace4782c60a471bd31493fa",
"created_at": 1686161631,
"kind": 1,
"tags": [
[
"e",
"7b72698d99716380f26ad6eea4d3234ee893131a7cc27a95e4bf1f32b809b686",
"",
"root"
],
[
"e",
"505bf523886b84d37a6743feaa0326b9cdee318e81aca54413df57fd4bb7b6ed",
"",
"reply"
],
[
"p",
"fd8c7b18ffe770eb7d313f47cd987b4c6042760ad1a956adaecb978131d46ede"
]
],
"content": "📅 Original date posted:2018-07-24\n📝 Original message:When I use the example of HTML forms …\n\n```test.html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\u003chead\u003e\u003ctitle\u003etest for URI schema\u003c/title\u003e\n\u003cbody\u003e\u003cform method=\"get\" action=\"./test.html\"\u003e\n\u003cselect multiple name=\"attr\"\u003e\n\u003coption value=\"val1\" selected\u003e1\u003c/option\u003e\n\u003coption value=\"val2\" selected\u003e2\u003c/option\u003e\n\u003coption value=\"val3\"\u003e3\u003c/option\u003e\n\u003c/select\u003e\n\u003cinput type=\"submit\" value=\"send\" /\u003e\n\u003c/form\u003e\u003c/body\u003e\u003c/head\u003e\u003c/html\u003e\n```\n\nThe resulting URI is:\nfile:///tmp/test.html?attr=val1\u0026attr=val2\n\nThat means that a URI attribute is not necessarily singular and can\nindeed occur multiple times.\n\nSo as we do not have athority in our URI…\nfor URI = scheme:path[?query][#fragment]\nwhere query=[key1=value1[\u0026key2=value2]]\n\n…under the circumstance that path has a newer standard we can implement\nfallback with: query=[path=newerversion[\u0026path=evennewerversion]]\n\n…as our path is the address, resulting in e.g.:\nbitcoin:p2pkh?[amount=value][\u0026address=p2sh][\u0026address=p2sh-p2wpkh][\u0026address=bech32]\n\nthe effect should be\n\n1. old clients ignore address attribute\n2. supporting clients select the address attribute over the address\ngiven in path *if* they support the format\n3. future address formats do not need a new attribute\n\nopen to me would be:\n* the order of the attributes and how this should be recognized/priorized\n* is there any precedence for that multiple use of an attribute in URI\nschemes?\n\nI think order of attributes should remain irrelevant, thus supporting\nclients should check all attributes of the same name and attributes\nshould be defined for repetitive (like address) or not (amount) in the\nBIP. This will still not support sending different amounts to multiple\naddresses and be consistent with the older version of the URI scheme.\n\nOn 24.07.2018 14:05, Federico Tenga via bitcoin-dev wrote:\n\u003e Hello everyone,\n\u003e \n\u003e With my team we are working on a walleting application which ideally will\n\u003e generate a bech32 address when receiving from a bech32 compatible wallet,\n\u003e and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.\n\u003e However, it is of course impossible for the payee to know in advance the\n\u003e technological capabilities of the payer, so a solution could be to encode\n\u003e in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy\n\u003e wallets only see the P2SH address, while new wallets can also see the\n\u003e bech32 address and use it to perform the transaction.\n\u003e \n\u003e In particular, to keep compatibility with BIP21, the \u003caddress\u003e field of the\n\u003e URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.\n\u003e \u003csegwitaddress\u003e or \u003cbech32address\u003e), which will be ignored by legacy\n\u003e wallets, can be used to encode the bech32 address. The assumption here is\n\u003e that the wallets using such scheme will monitor incoming transaction both\n\u003e on the P2SH address and on the bech32 address.\n\u003e \n\u003e I did some research around and I did not find any proposal addressing the\n\u003e same issue, so my questions are (i) does anybody already proposed something\n\u003e going in the same direction and (ii) do you see any major drawback in the\n\u003e BIP21 compatible scheme proposed in this message?\n\u003e \n\u003e Thanks in advance,\n\u003e \n\u003e Federico\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 898 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180725/fdd0fc27/attachment.sig\u003e",
"sig": "636c11abbc673bf65f43dff4a94b9b585bbd9923eea208f9b71bfec26fec2ab968136138b5e268fd0cfcec1d815fbd5f8706c75fe11bc479df6ee58cdf71808a"
}