Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-08 📝 Original message:Pieter, your suggestion ...
📅 Original date posted:2014-04-08
📝 Original message:Pieter,
your suggestion has charm since “Bitcoin seed” would even not need
a global dictionary like the interpretation of the first level, since it would be self describing.
Regards,
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 15:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
> --
> Pieter
>
>
> On Tue, Apr 8, 2014 at 3:43 PM, slush <slush at centrum.cz> wrote:
>> tl;dr;
>>
>> It is dangerous to expect that other seed than "xprv" does not contain
>> bitcoins or that "xprv" contains only bitcoins, because technically are both
>> situations possible. It is still safer to do the lookup; the magic itself is
>> ambiguous.
>>
>> Marek
>>
>> On Tue, Apr 8, 2014 at 3:40 PM, slush <slush at centrum.cz> wrote:
>>>
>>>
>>> Serialization magic of bip32 seed is in my opinion completely unnecessary.
>>> Most of software does not care about it anyway; You can use xprv/xpub pair
>>> for main net, testnet, litecoin, dogecoin, whatevercoin.
>>>
>>> Instead using the same seed (xprv) and then separate the chains *inside*
>>> the bip32 path seems more useful to me.
>>>
>>> Marek
>>
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140408/272c6548/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/272c6548/attachment.sig>;
📝 Original message:Pieter,
your suggestion has charm since “Bitcoin seed” would even not need
a global dictionary like the interpretation of the first level, since it would be self describing.
Regards,
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 15:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
> --
> Pieter
>
>
> On Tue, Apr 8, 2014 at 3:43 PM, slush <slush at centrum.cz> wrote:
>> tl;dr;
>>
>> It is dangerous to expect that other seed than "xprv" does not contain
>> bitcoins or that "xprv" contains only bitcoins, because technically are both
>> situations possible. It is still safer to do the lookup; the magic itself is
>> ambiguous.
>>
>> Marek
>>
>> On Tue, Apr 8, 2014 at 3:40 PM, slush <slush at centrum.cz> wrote:
>>>
>>>
>>> Serialization magic of bip32 seed is in my opinion completely unnecessary.
>>> Most of software does not care about it anyway; You can use xprv/xpub pair
>>> for main net, testnet, litecoin, dogecoin, whatevercoin.
>>>
>>> Instead using the same seed (xprv) and then separate the chains *inside*
>>> the bip32 path seems more useful to me.
>>>
>>> Marek
>>
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140408/272c6548/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/272c6548/attachment.sig>;