summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Weigl <Daniel.Weigl@mycelium.com>2016-05-13 15:16:20 +0200
committerbitcoindev <bitcoindev@gnusha.org>2016-05-13 13:32:02 +0000
commit40bc0d91bb2e9147bbb446724760ad315c3ec907 (patch)
treea087ee76f18b4bebd22e990011a3e149cfa2f4e2
parent4b2b8a1490b7a6ea42c3dc7a54034bd23ab5e82e (diff)
downloadpi-bitcoindev-40bc0d91bb2e9147bbb446724760ad315c3ec907.tar.gz
pi-bitcoindev-40bc0d91bb2e9147bbb446724760ad315c3ec907.zip
[bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
-rw-r--r--cf/8c050f4aba8bc5ecf5040a100e6e41c57bf55782
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
+
+
+
+
+
+
+