vv01f [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-24 📝 Original message:When I use the example of ...
📅 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>;
📝 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>;