Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 47EE7CBE for ; Tue, 24 Jul 2018 12:05:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC1C0A8 for ; Tue, 24 Jul 2018 12:05:29 +0000 (UTC) Received: by mail-yw0-f173.google.com with SMTP id k18-v6so1412191ywm.11 for ; Tue, 24 Jul 2018 05:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yxmrekdzPKB2CVFpsMeQqKuAlR7fsgrkVq+RxpwUcZw=; b=tIcgdKN6RUhPYqd5q+r0yqvafit99a+foVSMP39Vk307DvW57eHHQ1J7N1j98NfP0n zKoIGNEivCiPIEQ47f4awI+fCtEad0CW0b3MIqpxE3sYMubaT9i4KQaRdci0E9SmhqVQ Fj7JzRX73yqP0oOSiHXskp7js7irKkZyH3pMjc4R4ap/jJUftRdm/8nw6TSO6HTYG+ws wFWcOQNuWzPtPdkFZsTkLDtc5+xRygKPRBYVpd8ryiPCPRc7grJyi5+tShX7O8XI4ktp 1xjxPE6NGdI/a7pCDeggtOWVxso61kpssnSnnB5M1VuwQfsDBeUzU0FSNMV3bPeF46oW ZVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yxmrekdzPKB2CVFpsMeQqKuAlR7fsgrkVq+RxpwUcZw=; b=jguYltBNJyj9kBQrOQWQ8X4pnwgEN+EIreC7Y9zeklSM5MiMXwGi3LV/kpHsEzcc8h bUbUYcmokHtDg7fa2r1nPSVFi/oVz8JjCtBlAcPF2lLLzPNPaMpf95X63AJcPBrRVwqe 7EzVO5WcJCiTCcPp5wjRyGsVGHyfznJAiOJAa4BOmsT/KBZR9LurdlzgosYZDRmKZPXA Aicr85RNlDWt5jRsC1MPfzozpv/JrHzcd6RpLlsWhsbwwfTLFCLFDaPkqUPlZD7u3J7x ckz58rtPmrUCPWJOZxm+ypUn/wNKt6fdrusx+2eFbbkXN/TfZHCdF7l+mn+dL8rzIjIm x+eA== X-Gm-Message-State: AOUpUlH+SV7U9qt0T9u0vwfCez8AsQTcWFEUY+CkBkufT1UGlz1pR+SW Dk6AM9h+K5DtOy6GU2wFjPg55/G2fRGeXl7JP5tzVDIV X-Google-Smtp-Source: AAOMgpc9qmkiyhU9DLMOL49r7QrKFJ3t+veniS6WJQJGCmcOcHE3pPgwPnRCR2IBun5Dzomb5iF+acBaJBlotMAAFgU= X-Received: by 2002:a81:73c4:: with SMTP id o187-v6mr8461585ywc.260.1532433928468; Tue, 24 Jul 2018 05:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5e0b:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 05:05:27 -0700 (PDT) From: Federico Tenga Date: Tue, 24 Jul 2018 14:05:27 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f2d7e80571bd93cf" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Tue, 24 Jul 2018 12:58:20 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 12:05:30 -0000 --000000000000f2d7e80571bd93cf Content-Type: text/plain; charset="UTF-8" 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
field of the URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g. or ), 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 --000000000000f2d7e80571bd93cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

With my team we are working on a wa= lleting application which ideally will generate a bech32 address when recei= ving from a bech32 compatible wallet, and a P2WPKH-nested-in-P2SH address w= hen receiving for a legacy wallet. However, it is of course impossible for = the payee to know in advance the technological capabilities of the payer, s= o a solution could be to encode in a Bitcoin URI both bech32 and P2SH addre= sses in a way that legacy wallets only see the P2SH address, while new wall= ets can also see the bech32 address and use it to perform the transaction.<= br>
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 n= ew 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 incomin= g transaction both on the P2SH address and on the bech32 address.

I did some research around and I did not find any proposal addressing th= e same issue, so my questions are (i) does anybody already proposed somethi= ng going in the same direction and (ii) do you see any major drawback in th= e BIP21 compatible scheme proposed in this message?

Thanks in advance,

Federico

--000000000000f2d7e80571bd93cf--