diff options
| author | vv01f <vv01f@c3d2.de> | 2018-07-25 01:44:35 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-07-24 23:44:40 +0000 |
| commit | 565541c2dd29159058b7190bc5e8447755232e3b (patch) | |
| tree | 401f1d782775205544421789bd3785553c0cb702 | |
| parent | f22cb9a5ab168952c71641484deaa8465e993c97 (diff) | |
| download | pi-bitcoindev-565541c2dd29159058b7190bc5e8447755232e3b.tar.gz pi-bitcoindev-565541c2dd29159058b7190bc5e8447755232e3b.zip | |
Re: [bitcoin-dev] URI scheme with optional bech32 address
| -rw-r--r-- | 8e/892b453fecc05bac394f30cb70d36c7db4d244 | 236 |
1 files changed, 236 insertions, 0 deletions
diff --git a/8e/892b453fecc05bac394f30cb70d36c7db4d244 b/8e/892b453fecc05bac394f30cb70d36c7db4d244 new file mode 100644 index 000000000..4c3102df4 --- /dev/null +++ b/8e/892b453fecc05bac394f30cb70d36c7db4d244 @@ -0,0 +1,236 @@ +Return-Path: <vv01f@c3d2.de> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id DC76FAF8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Jul 2018 23:44:40 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail.c3d2.de (c3d2-50.in-berlin.de [217.197.84.50]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8671FA8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Jul 2018 23:44:39 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by mail.c3d2.de (Postfix) with ESMTP id C1AAB22CF7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Jul 2018 01:44:36 +0200 (CEST) +Received: from mail.c3d2.de ([127.0.0.1]) + by localhost (mail.c3d2.de [127.0.0.1]) (amavisd-new, port 10026) + with ESMTP id XmNND8ZO5m5Q + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Jul 2018 01:44:36 +0200 (CEST) +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" +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 25 Jul 2018 00:14:54 +0000 +Subject: Re: [bitcoin-dev] URI scheme with optional bech32 address +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 24 Jul 2018 23:44:41 -0000 + +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-- + |