URI scheme with optional bech32 address

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

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@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Hi,

I am not sure why this wasn't discussed more but it seemed like a very good idea to me https://www.reddit.com/r/Bitcoin/comments/9iivej/its_been_like_a_year_and_bech32_adoption_remains/

QR code is very important for network wide adoption. The problem is bech32 qr code isn't backward compatible and noone is going to show two QR codes. Everyone is going safe with P2SH address qr code.

Example of proposed URI. I want not sure of technically best encoding, but this is just for ideas

bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?keyhash=a70aa2014fbc2151e0a5da78a8dead358d3af384 bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?amount=0.123&bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy

As merchants/exchanges adopt this QR code, wallets that support bech32 can chose to autopay to bech32 address (for lower tx fee). This can create a network effect as more people start using bech32 and when we reach enough wallet adoption, people can shift to just showing bech32 QR codes