To: bitcoin-dev@lists.linuxfoundation.org
References: <CAP=-fx5Jgw0OEAGaEYKOLWTMay5XFfpsMVBMGXzQ4N1WSOR47A@mail.gmail.com>
From: vv01f <vv01f@c3d2.de>
Openpgp: id=4B12EFA69166CA8C23FC47E49CD3A46248B660CA
Autocrypt: addr=vv01f@c3d2.de; prefer-encrypt=mutual; keydata=
	xsFNBFQspiUBEADjRDBd1qQHg6DA5DGCp0tHhyQh+eZvmqF7QF14Ow9mdXrh3G5S08+cR+/m
	WWLgPSVtB1cORh99w7l1EKAtCMQepxDE4vgzDatuaAog+nM9PXr6Jg1Tid3k6dG2Y5Mmx+ko
	z/jKOUUC3RkXbwAuxzxUpKOaNvgXYfT8bVBbyas8qHfFs1MT+DI5C64TdLN5O5zSZK9VrCqJ
	onLrk/fvt43oBpHBxpX6vdhwCoPQcY1k+IfuaAwZ0Q6Ziq2Q08O01mp2l0jKCThnv9F3+iMM
	Uq7+hLUTPYrSSocXcg8k5beagR+kGaqurM8ZW0vdelkVbNJVcnqywZcVo6I1Svzxa2BqLe65
	boHEVROK7Cdrq64Fqos2bkYhtq6te56T/jsAyDqKULCTp/lPcitfuvuY79udYhQUa/NyenBs
	IaWwEQ4lOErKbi3v07A5/MaoWlTYlmJ6K7JnkokApjiRNfxPwnePDokQVR47Vj+xYZrbst8R
	GTx7P9pHFnlBIKTdVM3VkufEMEj6lF/E7AtFe13SnqEDeID4QGVncuHSfTijGHIZPQFIR8pD
	amdUb//9iN2sMHyBdWfiCa6Os06DMMxdW0kcIipI1QqmU3c5aDGPs+JB+ACCaFqlzcVwu0Ij
	Mw9y2wYkmFdPsLdShaKjgUgUw7/3W4letLOiIZQgsWu+ZGL04wARAQABzQV2djAxZsLBjgQT
	AQoAOBYhBEsS76aRZsqMI/xH5JzTpGJItmDKBQJaPMBMAhsDBQsJCAcDBRUKCQgLBRYCAwEA
	Ah4BAheAAAoJEJzTpGJItmDKl/cQANMSFDbYxZU5pHUZXhto40nV5P6K1UMAu+Vslv0DPdID
	PCRPwc3e7eth4iffeckkRWQpqlRHGFbv24JwRatJXEb9lp2HOemBab1OM87Qw7SbrxbbM9S5
	X3w4aiHS+ZIpXaSL2p2jpgNZl62hyqpUuMv+WV917Xcl/I/AhpGd4mW2Xipt8lCYvtZRQEcG
	Wh5mmTsig8rQ97ksVSG/EEPnKFjjwUQJczJzGfw4QJ0jLRbJNpux5HTHQRZh7nzNkgkiIgJh
	j6C3pZOWomLeQPQsvfTpbbGyL+rUVCZoDv4c+beejs5iW3t0BLQYVytndeK2gCNE7cu54v0y
	Hvg+SHkid2ObxvptCpuLH5iLdxfGeS6QDMsrBQ49ITAyb8X0Ec6g/A4/RgYmxXKndzTPMbon
	K4Ki/Zvd+X/srsxG1+dP/89iMYCYvEAYf6cMD/pUnxjg5Lzjs7pj53RtALjwFDGT2DV+RuQ6
	wdgPmHzjaYTB74AwHv+d+fArU00QQcUcoywVNFCwV2aDArR2e+dy/bTs5VAbwX06ui3SZaS1
	YosqxTMkrFI67ydkDyveaB7/1psZ4EpDwzyXZFhzZgJiunYqPDThc1g+PBjZoCsyjsQQlqL4
	5UB6eF40TEJOt6Dxa2SCQ/q5hlr/BxNm8HPiEsgjGh1NnFeuBIHdf9KEx1oC47yhzsFNBFQs
	piUBEADmdVtKjw8cxUUOHUdWIgDq+7k4QZTsAMyFOKVP2mUMjz0qjjqxORNenm0zPSrJZ270
	cV3d+Zfbp2vLyIQYvT+jWGLOp0zawUnoJ2zpRkj3ym4thtcw8HjySpqK3pV99RV8yJvO8Z1d
	0qgK9YQz+Px9HNjdWJHQTG+qGWgjJkvdvqVCnZzUEj4BuzU4xDnUVuVjYDAp5JS2jjp5aKIs
	m/g1dMgj/3J9RvQrVKwn4PfuQuuchvqkI7+E/gdc3tjORCuXV5ry4IIJGBTVGQ1vb/rZAbDI
	B7Ieii5BFNR7YDHRmvLKi+18ZbYL0xtZ5DM2+HU+oSL9XdB+WiMfw345xlcrqQoM47ZZuSAW
	Au3/1By8T3Yhf8hh15awX0IDEehU89O4WO+vfJROH3yipG9TjP7KqVImmfdb9/G8/oEx0R/C
	XvP8/46niF5PO4JBtYRjpzyAwfJDqE1TTos2g7evhT0fb6at7cAqjxbH9/SlyoxCYfLyyuKC
	Z/k9dw3TTV6fEL/oB/v9qqPwk+YnNXKZbTI6g5fzUK6DK7HbBnAmdkaD13d5+J/imeZ3W0KD
	+IK+Aul1nlLiaae0Mmq/wqG11M9n2S9DTzDlJ04gjgRHKqsO21QmcYq8BlYu9PiGEvR2D/0+
	ckXVJu4bW6qM5HlqugLSmk2bfTagIioj6MEPRvTTNQARAQABwsFfBBgBAgAJBQJULKYlAhsM
	AAoJEJzTpGJItmDKe3AQAL+dmUZ+2ktpVKj0SOho7v4oQ5tFrxWKJuwpK5/EbN6E5ONcP361
	XHO9gA2CMelB1k1ingWnkSecjuaCcDqmZCcHpVQ/7y77SRJI0qR4JKh8ZaijcRyVtapQIXKM
	qUx3aF6OhRjuszITKBGfjU+aCmhzTlZVOd3UCDpiY0luDAZTxrfaJsSnk82GshFkIB3/f4S9
	W7FF2WRr36U6TorYJh00A4uTbNZNO+JNcHQJsQvK/ym3xAEywEdMMI+WMFdikEfaWF9+OQcF
	2ZS9K2cbI2KODzkmr1/+sTo0ZRa/G9x+dZuxDgkggYJcsSd3djh1HRPrjaYY2q5s62FAWmcp
	WGx2FeRmpXpz/63sIcF9Xd2H2wU3Vf9L8wqMCctE3EOFCZWCqOgnRqWOsr29RjmAHnZsLKfl
	ZR/92hT6jbgz5E4Vb+XncFDvJnNUPFGMuBAJpErSD3aGJE8dpCT9dUcPODK0SobPwE5Uo8t6
	D6HLxbnrh//ZmQj55DrZo4N9F2scF9Fz2htHdoSpP7FmmLkRvwFHaGwdskuOpaKF15f6jX56
	jc0DUfzBJp5Fl4IEdzEmHf6LAweMT7Q3GTA2ZvzjCyyWM/q0G4UuAY216LG5k/B4HZaisrfH
	9hsLr4hVl5iaphAED3aC3bYQ420+s1QqryKipkIzKCiNE9X+Wg3wF0+f
Message-ID: <ca301edb-e845-ad6c-5fc5-956833f6210f@c3d2.de>
Date: Wed, 25 Jul 2018 01:44:35 +0200
Mime-Version: 1.0
In-Reply-To: <CAP=-fx5Jgw0OEAGaEYKOLWTMay5XFfpsMVBMGXzQ4N1WSOR47A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="xwnk03K4UNIqP3yMjCFGJRQzxzECB2Wrz"
Subject: Re: [bitcoin-dev] URI scheme with optional bech32 address
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xwnk03K4UNIqP3yMjCFGJRQzxzECB2Wrz
Content-Type: multipart/mixed; boundary="oPEKMVhMKdhV9J6azKUxdVZtKuHi9IGMT";
 protected-headers="v1"
From: vv01f <vv01f@c3d2.de>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <ca301edb-e845-ad6c-5fc5-956833f6210f@c3d2.de>
Subject: Re: [bitcoin-dev] URI scheme with optional bech32 address
References: <CAP=-fx5Jgw0OEAGaEYKOLWTMay5XFfpsMVBMGXzQ4N1WSOR47A@mail.gmail.com>
In-Reply-To: <CAP=-fx5Jgw0OEAGaEYKOLWTMay5XFfpsMVBMGXzQ4N1WSOR47A@mail.gmail.com>

--oPEKMVhMKdhV9J6azKUxdVZtKuHi9IGMT
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

When I use the example of HTML forms =E2=80=A6

```test.html
<!DOCTYPE html>
<html><head><title>test for URI schema</title>
<body><form method=3D"get" action=3D"./test.html">
<select multiple name=3D"attr">
<option value=3D"val1" selected>1</option>
<option value=3D"val2" selected>2</option>
<option value=3D"val3">3</option>
</select>
<input type=3D"submit" value=3D"send" />
</form></body></head></html>
```

The resulting URI is:
file:///tmp/test.html?attr=3Dval1&attr=3Dval2

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=E2=80=A6
for URI =3D scheme:path[?query][#fragment]
where query=3D[key1=3Dvalue1[&key2=3Dvalue2]]

=E2=80=A6under the circumstance that path has a newer standard we can imp=
lement
fallback with: query=3D[path=3Dnewerversion[&path=3Devennewerversion]]

=E2=80=A6as our path is the address, resulting in e.g.:
bitcoin:p2pkh?[amount=3Dvalue][&address=3Dp2sh][&address=3Dp2sh-p2wpkh][&=
address=3Dbech32]

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,
>=20
> With my team we are working on a walleting application which ideally wi=
ll
> generate a bech32 address when receiving from a bech32 compatible walle=
t,
> 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 th=
e
> technological capabilities of the payer, so a solution could be to enco=
de
> 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.
>=20
> 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 bo=
th
> on the P2SH address and on the bech32 address.
>=20
> I did some research around and I did not find any proposal addressing t=
he
> same issue, so my questions are (i) does anybody already proposed somet=
hing
> going in the same direction and (ii) do you see any major drawback in t=
he
> BIP21 compatible scheme proposed in this message?
>=20
> Thanks in advance,
>=20
> Federico
>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20


--oPEKMVhMKdhV9J6azKUxdVZtKuHi9IGMT--

--xwnk03K4UNIqP3yMjCFGJRQzxzECB2Wrz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCgAdFiEEhT4uPiMvULfFKVhvAmJaFqwdH/YFAltXueMACgkQAmJaFqwd
H/bHjhAAu8bU4Iqpmt8SvBe+Y+t9qFfZwUcSBmTR1ncZL0VUpKQ2wrabW09geL2X
ev5dgOfshT+OB81pYuLpy+FaLDmnVT+DHJGthJV1DSFzFGimBfXdl2msDgQAaBmz
oI8oCBgMhDX41tmwrDgKsQNAmBTwtYncgEEPd6XyGOCt6wfndQQ7Lkd/0HkzcEi3
RMSsr2vLqP1e0eJJ8ZrZHj2gxrDf0GaD+jlaa9z69KXZt5WUAELkGOH4awBbk5Cy
FRlF3KsLzyXEHADHv+c4znmrt1jGeIfNRp0xcbhK1WsMi98dlIyP/X9l8HJh7mXw
bZK4iFLb5/CpESJCWuWaZZqwaGxdWSCu4Qq7gfG/NRmiWOt2OwRCeuTKIdIiXo9n
YeZ+gSYMU2PHG+xWweLTtZM1xShzmz8Yj6nhddcUVjwGLk5ly5tL71VI9h/LNJMD
/Efc2saBnf5QczKLoGDmx81xS8b/nKERYqxpSJE/1sd/PT5qbl8oce19DgBsYyxT
l0bFYzm0GRM+ShUeSNvvXwACipUWn82HiQrlhxpWjkrVarOpUtYVJ1PSwGvsD0VW
z1YHnQV2lr9VuDTIsoImkijUOKblugw4hZMZ9Jbb2TbejxI10wRP6rRzBy3e0Y4L
PpXDIRzQ/UPtyK5mZAtNWBnvg8n6dOVSGv50Pc/3MRQIu1CCX5E=
=Lcd6
-----END PGP SIGNATURE-----

--xwnk03K4UNIqP3yMjCFGJRQzxzECB2Wrz--