diff options
author | Daniel Weigl <Daniel.Weigl@mycelium.com> | 2016-05-13 15:16:20 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-05-13 13:32:02 +0000 |
commit | 40bc0d91bb2e9147bbb446724760ad315c3ec907 (patch) | |
tree | a087ee76f18b4bebd22e990011a3e149cfa2f4e2 | |
parent | 4b2b8a1490b7a6ea42c3dc7a54034bd23ab5e82e (diff) | |
download | pi-bitcoindev-40bc0d91bb2e9147bbb446724760ad315c3ec907.tar.gz pi-bitcoindev-40bc0d91bb2e9147bbb446724760ad315c3ec907.zip |
[bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
-rw-r--r-- | cf/8c050f4aba8bc5ecf5040a100e6e41c57bf557 | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/cf/8c050f4aba8bc5ecf5040a100e6e41c57bf557 b/cf/8c050f4aba8bc5ecf5040a100e6e41c57bf557 new file mode 100644 index 000000000..19fee4852 --- /dev/null +++ b/cf/8c050f4aba8bc5ecf5040a100e6e41c57bf557 @@ -0,0 +1,82 @@ +Return-Path: <Daniel.Weigl@mycelium.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A99667D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2016 13:32:02 +0000 (UTC) +X-Greylist: delayed 00:15:38 by SQLgrey-1.7.6 +Received: from mx.mycelium.com (mx.mycelium.com [188.40.34.2]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93B851D9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2016 13:32:01 +0000 (UTC) +Received: from 178-189-162-17.adsl.highway.telekom.at ([178.189.162.17] + helo=[10.0.0.77]) + by mx.mycelium.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) + (Exim 4.82) (envelope-from <Daniel.Weigl@mycelium.com>) + id 1b1CxF-0000Nh-HZ for bitcoin-dev@lists.linuxfoundation.org; + Fri, 13 May 2016 15:16:33 +0200 +To: bitcoin-dev@lists.linuxfoundation.org +From: Daniel Weigl <Daniel.Weigl@mycelium.com> +Message-ID: <5735D3A4.7090608@mycelium.com> +Date: Fri, 13 May 2016 15:16:20 +0200 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 + Thunderbird/38.7.2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 8bit +X-Spam-Score: -101.0 (---------------------------------------------------) +X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD + 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: Fri, 13 May 2016 14:02:02 +0000 +Subject: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/... +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: Fri, 13 May 2016 13:32:02 -0000 + +Hello List, + +With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses. +I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first. + +In my opinion there are two(?) different options: + +1) Stay with the current Bip44 account, give the user for each public key the option to show it as a P2PKH-Address or a P2SH address and also scan the blockchain for both representation of each public key. + +) This has the advantage, that the user does not need to decide or have to understand that he needs to migrate to a new account type + -) The downside is that the wallet has to scan/look for ever twice as much addresses. In the future when we have a P2WPKH, it will be three times as much. + -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types + +2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account"). + + m / purpose' / coin_type' / account' / change / address_index + + +) Wallet needs only to take care of 1 address per public key + +) If you use more than one wallet on the same xPub/xPriv it will work or fail completely. You will notice it immediately that there is something wrong + -) User has to understand that (s)he needs to migrate to a new account to get the benefits of SegWit + +) Thus, its easier to make a staged roll-out, only user actively deciding to use SegWit will get it and we can catch bugs earlier. + +3) other ideas? + +My personal favourite is pt2. + +Has any Bip44 compliant wallet already done any integration at this point? + +Thx, +Daniel/Mycelium + + + + + + + |