BIP43 Purpose code for voting pool HD wallets
5 messages, 19 Aug to 26 Sep 2014. Started by Justus Ranvier.
Justus Ranvier (2), Greg Maxwell, Alan Reiner, Bryan Bishop
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
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier <justus@monetas•net> wrote:
Quoted text (1 line)
> Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no commentary on this proposal?
On 09/26/2014 01:53 AM, Gregory Maxwell wrote:
Quoted text (7 lines)
> 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? >
Regarding the BIP process itself, I rather think it's broken in the case of informational BIPs.
Proposals that require explicit action on the part of others do not logically belong in the same process as purely information proposals that do not require any explicit action by others are going to be carried out regardless.
The only reason we proposed these as BIPs at all was to support the intent of BIP43.
- -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
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:
Quoted text (15 lines)
> 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
On Thu, Sep 25, 2014 at 8:53 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (2 lines)
> 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