From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets
Date: Thu, 25 Sep 2014 22:31:15 -0400 [thread overview]
Message-ID: <5424CFF3.50404@gmail.com> (raw)
In-Reply-To: <CAAS2fgT7eUDUHqwtuMF9cj0LvzHdZXxyan+c2ep1dQ8dQGOrHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]
I'm in favor of BIP43.
Adding a "Purpose" node can be used as an identifier for what kind of
tree is in the wallet file we're reading. I can envision a few
different, common tree structures. Perhaps using a non-hardened
first-layer derivation (we have clients who want this). Similarly, my
proposal for a "No-collision mode" for multisig BIP32 trees
<http://sourceforge.net/p/bitcoin/mailman/message/32860512/> is another
variant that might get some traction but not everyone will use it.
These things could be "supported" by simply changing the BIP43 "Purpose"
index and wallet software could be designed to recognize and react to
the Purpose node for any number of different tree structures, and ignore
any trees that it doesn't recognize (or maybe be able to view the
balance across all the leaves of the tree but not expand it)
We have clients with special use-cases (complex multi-layer trees) that
are unlikely to be recycled across users. In such cases we might just
use a "random" Purpose that is recognized by their system, and know that
other software won't mess with it. Though it would be better if that
field was encoded in the root seed, instead.
Nonetheless, putting that extra layer between the root and the
"important" tree nodes provides flexibility to BIP32 as a whole.
-Alan
On 09/25/2014 09:53 PM, Gregory Maxwell wrote:
> On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier <justus@monetas•net> wrote:
>> Two draft information BIPs are attached.
> I've pinged some people privately but also pinging the list… no
> commentary on this proposal?
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3253 bytes --]
next prev parent reply other threads:[~2014-09-26 2:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 17:11 Justus Ranvier
2014-09-26 1:53 ` Gregory Maxwell
2014-09-26 2:09 ` Justus Ranvier
2014-09-26 2:31 ` Alan Reiner [this message]
2014-09-26 2:32 ` Bryan Bishop
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=5424CFF3.50404@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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