From: Aaron Voisine <voisine@gmail.com>
To: Daniel Weigl <Daniel.Weigl@mycelium.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Date: Sun, 15 May 2016 10:36:54 -0700 [thread overview]
Message-ID: <CACq0ZD6boG_eFU+2eAiqduYq++E5ofH+VD7Gzvzh3jsemyqw8A@mail.gmail.com> (raw)
In-Reply-To: <573866AE.9070205@mycelium.com>
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]
On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > 0x40000000 would be the next available to specify witness addresses.
> > This is compatible with existing accounts and wallet layouts.
>
> my main concern here is that
> -) every Bip<this-bip>-compatible wallet in the future will have to
> implement all (then probably) legacy derivation and tx schemes.
>
I can see the advantage of a segwit only scheme, but we will need to
support old derivations anyway for many decades if not indefinitely. People
are using it to store value for the long term.
> -) it does not fail in a deterministic way, if I import a seed or
> xPriv/xPub across different capable wallets.
> It is more visible if one account has [no funds/does not show up]
> at all after an import than if something shows up but you need to make sure
> that the balance is what you might expect.
>
This is certainly a downside. It has to be weighed against the benefit of
being able to upgrade existing wallets in place. Asking users to create a
new wallet, and replace their recovery phrase backups is an even bigger
problem in my estimation.
What do you think of doing both? A new BIP43 purpose number for segwit only
wallets, but that also specifies 0x40000000/1 for the change/receive index
so that the scheme is compatible with other schemes for upgrade existing
wallets in place? There will certainly be wallet developers who decide to
upgrade in place, but we can standardized both how to indicate segwit
chains, independent of segwit only schemes or upgrade schemes, and still
have the advantages of a new segwit only BIP43 purpose number.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com/>
[-- Attachment #2: Type: text/html, Size: 2624 bytes --]
next prev parent reply other threads:[~2016-05-15 17:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 13:16 [bitcoin-dev] Bip44 extension for P2SH/P2WSH/ Daniel Weigl
2016-05-13 15:00 ` Pavol Rusnak
2016-05-13 16:03 ` Aaron Voisine
2016-05-13 16:11 ` Pavol Rusnak
2016-05-13 16:59 ` Aaron Voisine
2016-05-13 17:57 ` Pavol Rusnak
2016-05-13 21:42 ` Aaron Voisine
2016-05-14 8:16 ` Jonas Schnelli
2016-05-14 12:26 ` Jochen Hoenicke
2016-05-14 14:07 ` Pavol Rusnak
2016-05-14 16:14 ` Jonas Schnelli
2016-05-14 17:37 ` Kenneth Heutmaker
2016-05-15 8:53 ` Thomas Voegtlin
2016-05-15 10:04 ` Pavol Rusnak
2016-05-15 12:08 ` Daniel Weigl
2016-05-15 17:36 ` Aaron Voisine [this message]
2016-05-14 7:00 ` Andreas Schildbach
2016-05-14 14:08 ` Pavol Rusnak
2016-05-14 17:09 ` Aaron Voisine
2016-05-14 12:15 ` Jochen Hoenicke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACq0ZD6boG_eFU+2eAiqduYq++E5ofH+VD7Gzvzh3jsemyqw8A@mail.gmail.com \
--to=voisine@gmail.com \
--cc=Daniel.Weigl@mycelium.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox