BIP43 Purpose code for voting pool HD wallets

BIP43 Purpose code for voting pool HD wallets
2014-09-26  1:53 ` Gregory Maxwell
  
From: Justus Ranvier @ 2014-08-19 17:11 UTC (permalink / raw)
  To: Bitcoin Dev;  Muharem Hrnjadovic, Jimmy Song, Chris Odom

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

We'd like to reserve two purpose codes for the HD multisig structure
that will be used for the Bitcoin wallets used for voting pools, so
we've documented the structure in the form of two BIPs. One is used
for the wallets suitable for storing bulk bitcoin deposits, the other
is used for storing colored coin deposits.

The primary difference is that bulk deposit wallets use cold storage
and are allowed to incur significant administrative overhead, where as
colored coin wallets do not use cold storage because they must be
capable of being generated on the fly.

Two draft information BIPs are attached.

- -- 
Justus Ranvier                   | Monetas <http://monetas.net/>
<mailto:justus@monetas•net>      | Public key ID : C3F7BB2638450DB5
                                 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJT84VCAAoJEMP3uyY4RQ21LZcH/RYN5dUc5TjOI6Z72I4aNqDL
cZMzIo1WTK6OHsO2GUo+3L4avf+dCb2om/hDJgoLz/Oh9BMY77vF3UTIPIzGmN9X
2Oeyjg+wJG9z2L/B1f7oo4MX9c2ppUNfp2x5zDaURvME9CLkY7hLCBWp/OxU1HHb
MhLn0ICtpw3FnHddVWFwhvBxcCzJm6t2pBlM8mmTr4t52/08gklY1LVdUW0zmf9W
eFe50Y2KQ+uhVZfAga1wmFwY1pJBUmf6fAVqeK6AGDPkLVHDvN8P+mco+Qks++VZ
mTENKXWAmskGViTjd0pb8EdoSoMsDIa1eRHbpwAbbb2PEoc9pdccgwH6CscgN1I=
=R/HX
-----END PGP SIGNATURE-----

[-- Attachment #2: bip-draft-Hierarchy for Colored Voting Pool Deterministic Multisig Wallets.mediawiki --]
[-- Type: text/html, Size: 2630 bytes --]

[-- Attachment #3: bip-draft-Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets.mediawiki --]
[-- Type: text/html, Size: 2849 bytes --]

[-- Attachment #4: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14046 bytes --]

 permalink raw reply	[|nested]
2014-08-19 17:11 [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets Justus Ranvier

  2014-09-26  2:09   ` Justus Ranvier
                     ` (2 more replies)
  
From: Gregory Maxwell @ 2014-09-26  1:53 UTC (permalink / raw)
  To: Justus Ranvier;  Muharem Hrnjadovic, Bitcoin Dev, Jimmy Song, Chris Odom

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?



 permalink raw reply	[|nested]
2014-08-19 17:11 [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets Justus Ranvier

  2014-09-26  2:09   ` 
                     ` 
  
From: Gregory Maxwell @ 2014-09-26  1:53 UTC (permalink / raw)
  To: Justus Ranvier;  Muharem Hrnjadovic, Bitcoin Dev, Jimmy Song, Chris Odom

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?



 permalink raw reply	[|nested]
2014-09-26  1:53 ` Gregory Maxwell
  2014-09-26  2:09   ` Justus Ranvier

  2014-09-26  2:32   ` Bryan Bishop
  
From: Alan Reiner @ 2014-09-26  2:31 UTC (permalink / raw)
  To: bitcoin-development

[-- 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 --]

 permalink raw reply	[|nested]
2014-09-26  1:53 ` Gregory Maxwell
  2014-09-26  2:09   ` Justus Ranvier
  2014-09-26  2:31   ` Alan Reiner

  
From: Bryan Bishop @ 2014-09-26  2:32 UTC (permalink / raw)
  To: Gregory Maxwell, Bryan Bishop
  Cc: Muharem Hrnjadovic, Bitcoin Dev, Justus Ranvier, Jimmy Song, Chris Odom

On Thu, Sep 25, 2014 at 8:53 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> I've pinged some people privately but also pinging the list… no
> commentary on this proposal?

One possible reason is that non-subscribed users aren't able to access
the file through sourceforge. The attachment through their web
interface is giving back HTTP 500.

see http://sourceforge.net/p/bitcoin/mailman/attachment/53F38542.2000704%40monetas.net/1/

- Bryan
http://heybryan.org/
1 512 203 0507



 permalink raw reply	[|nested]