📅 Original date posted:2014-09-25
📝 Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140925/f4b201f1/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:25:57
in reply to nevent1q…99s9
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:25:57Event JSON
{
"id": "824075f25682a4e19f20afc91c3a4b4ae08e006c05451d2b4888e57e331ec50e",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686151557,
"kind": 1,
"tags": [
[
"e",
"90d0eeb8357152ae7cb698c0d329428a0d89251ca7d385a973b0fd5f939b8c7c",
"",
"root"
],
[
"e",
"18877a49b4cfa8a5ee86e88d717a7f700ec75d196bacb65bde8156777c8312c5",
"",
"reply"
],
[
"p",
"b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd"
]
],
"content": "📅 Original date posted:2014-09-25\n📝 Original message:I'm in favor of BIP43.\n\nAdding a \"Purpose\" node can be used as an identifier for what kind of\ntree is in the wallet file we're reading. I can envision a few\ndifferent, common tree structures. Perhaps using a non-hardened\nfirst-layer derivation (we have clients who want this). Similarly, my\nproposal for a \"No-collision mode\" for multisig BIP32 trees\n\u003chttp://sourceforge.net/p/bitcoin/mailman/message/32860512/\u003e is another\nvariant that might get some traction but not everyone will use it. \nThese things could be \"supported\" by simply changing the BIP43 \"Purpose\"\nindex and wallet software could be designed to recognize and react to\nthe Purpose node for any number of different tree structures, and ignore\nany trees that it doesn't recognize (or maybe be able to view the\nbalance across all the leaves of the tree but not expand it)\n\nWe have clients with special use-cases (complex multi-layer trees) that\nare unlikely to be recycled across users. In such cases we might just\nuse a \"random\" Purpose that is recognized by their system, and know that\nother software won't mess with it. Though it would be better if that\nfield was encoded in the root seed, instead.\n\nNonetheless, putting that extra layer between the root and the\n\"important\" tree nodes provides flexibility to BIP32 as a whole.\n-Alan\n\n\nOn 09/25/2014 09:53 PM, Gregory Maxwell wrote:\n\u003e On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier \u003cjustus at monetas.net\u003e wrote:\n\u003e\u003e Two draft information BIPs are attached.\n\u003e I've pinged some people privately but also pinging the list… no\n\u003e commentary on this proposal?\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer\n\u003e Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports\n\u003e Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper\n\u003e Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=154622311\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140925/f4b201f1/attachment.html\u003e",
"sig": "0c7c115badc4c3c1bb7dd8b725183dc35c3291dce7d1fd7bc4be43bb4988031a668ed44b2ef319ee00c1ff9f22ddf15e0b2454ca85203dbc1d09f8087c035cd5"
}