introduce BIP-0064: Hierarchy for Deterministic Wallets #52
Conversation
|
ACK Draft. |
|
A few commnts:
|
|
I do not understand the benefit of putting the cointype inside the derivation. The software needs to know what coin you're talking about any way, and you're dropping the only place where this information is serialized (the 4 byte magic). My suggestion would be to have a BIP32 seed be coin-agnostic, but modify the master node generation algorithm to include the cointype in the HMAC key. That way, each coin can define its own magic, and never risk importing an incompatible chain, while at the same time guaranteeing that no keys will be reused across coins. There's no reason why testnet would be special as the only extra coin. |
|
@sipa We tried to explain this on the mailing list already, there's no need to start the same discussion here again ... |
|
a) changed private -> hardened in the text |
|
@sipa There're actually some reasons mentioned in the BIP text itself. We think that having one master node which allows storing various cryptocurrencies at once (and without privacy issues like reusing pubkeys) is very useful feature. |
|
Continuing the discussion on the mailing list. |
|
Suggestion: add a recommendation that wallet software warns when you're exceeding the gap limit on an external chain. Another suggestion: make it clear that different "purpose"s could have a different derivation structure below it. For example: We propose the following tree structure for BIP32: m / purpose' / * Where the purpose value determines the structure beneath. This BIP defines one purpose (with id 0x40), and associated structure: m / 40' / coin_type' / account' / change / address_index PS: I'm very much in favor of standardizing this further, so don't let my criticism on some details derail this. |
|
Added both suggestions. |
|
Reminder: This is just a PR for the BIPs repository; the BIP itself is Draft status, so there's no reason things cannot be changed after this is merged.. |
| 3) scan addresses of the external chain; respect the gap limit described below | ||
| 4) if no transactions are found on the external chain stop discovery | ||
| 5) if there are some transactions, increase the account index and go to step 1 | ||
|
|
There was a problem hiding this comment.
These steps don't appear on different lines under the markup system.
|
Ok.... anyone here, willing to merge this PR? |
|
The PR has been open for only 8 hours and has sparked some pretty extensive discussion. |
|
Um, @prusnak changed all details what has been requested above. And that discussion on bitcoin-dev, everything has been discussed million times over again and again. This draft is a real consensus of all known consensuses from the whole consensus universum. Even people who discussed the proposal and dislike that specific design of paths for some reason understand that finding universal solution isn't possible, so our m/purpose'/ is win-win for all edge cases and future uses... |
|
I was not making any comment about the proposal, only that 8 hours is generally an unreasonable expected time-frame for merging a non-trivial merge request. |
|
Is there any standard describing how long to wait with pull requests of initial drafts? |
|
No, there hasn't previously needed to be one. Can you help me understand the urgency here? |
|
@gmaxwell It's not like this is proposing to make it final/accepted... it's just a Draft, no reason not to merge it as soon as the author posts it IMO. |
|
There's no urgency as well as there's no need to wait... If there's somebody around with merge capabilities, where's the problem? @luke-jr Thanks, I was going to write the same |
|
@prusnak Can you change this to BIP 0043 and I'll go ahead and merge the draft. |
|
@gmaxwell Is there any particular system in registering numbers for new BIPs? We've choosen "64" because it has nice "geeky" relation to BIP32, on which this BIP is based... |
|
It's the next available down in the block that had formerly been assigned to you. (I also note that you should have obtained a number per BIP1 and could have avoided any needed changes here. :) ) |
|
Oh, BIP1 is not obsolete anymore? ;-) @gmaxwell I don't need my BIPs in one block... no little exception for us with that number? Even if it's damn geeky to have 2x32? We'll be very very happy and as our "thank you" we'll be always talking about you only in very good light! :-) |
|
I don't know that thats appropriate when even the authors of BIP32 have issues with this approach. |
|
@sipa Do you have anything against using BIP64 for this? :-) |
|
To me it feels like this BIP should be split into two. First part about The second part, a proposal for your specific "purpose 64" structure I think should wait until there are (preferably more than one) implementations of it. I suspect a lot of the other wallets will pick a (slightly) different structure. No need to put every proprietary structure into a BIP unless its clear there will be at least a minimal level of interoperability. |
|
@schildbach Great to see you have came up to the same conclusion. Please do share more of your Berlin group findings on the mailinglist. We'd love to see such things before we come up with them. :) About the second part: Unfortunately no, it can't wait. We need to ship TREZOR and need to have this standardized before that. |
|
@gmaxwell Please, let's focus on the fact there is a group that, surprise, surprise, wants something standardized (as opposed to lots of other bitcoin ecosystem developers that just go and do their stuff without thinking about interoperability at all). Your behavior creates unnecessary friction and makes the whole process cumbersome, raising again question if it makes sense at all. To support my stance let me cite from README of this repository: "We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community." and clearly this is not what we saw. Heck, we haven't even got to the point of approving the BIP, we are just stuck even BEFORE Drafting stage. To sum it up: either you merge this request as BIP64 or we'll deal with this in another manner. |
|
@prusnak I understand you have your timeline. On the other hand, I think your timeline should not put any pressure on the standardization process. Even if both parts of the BIP will be merged at the same time, I still think it should be different BIPs. Otherwise, other structure BIPs need to reference to "BIP64 part 1" or something like that. Your BIP feels a bit like you want to put TCP and HTTP into one document. Currently, I think you're the only user of your "purpose 64" structure.
So what are you waiting for? Just release myTrezor and see if someone picks up the structure. We can agree on a BIP once that happens. By the way, I thought Trezor (the hardware) is agnostic of any structure, other than the BIP32 derivation rules itself? Is that no longer true? |
|
Just chiming in for MultiBit HD. It will follow the Bitcoinj implementation and timeline. We want to be interoperable with a wide range of wallets and this seems to be the best way to achieve that goal. We're allowing for multiple accounts, but they won't be present in the first release since the vast majority of our users will never use them. |
|
@schildbach There is no pressure on the standardization process, because currently there is no one going on. There is just unwillingness to merge the draft. |
|
BIP 1 was never obsolete. If you think something is wrong in that BIP feel free to comment (I updated it some time ago, but got hardly any input). @gmaxwell has always assigned numbers for BIPs and I see no reason why this is special and to deviate from that here. |
|
@prusnak The purpose of a standard is to build something together, something which has been at least exposed to public scrutiny and had a fair opportunity to be enhanced as a result of it, and hopefully one that more than one party think they will implement so that they can inter-operate. With BIPs we don't even demand that the ideas be considered "good", though they do need to survive public scrutiny. Here I asked for the most modest of collaboration— to follow the process and take a number assignment— and your response sounds to me like a veiled threat. With this kind of approach I do not think a useful standard can result. I hope you'll reconsider your approach, I think many people here would like to collaborate with you and the result would benefit everyone. If you are unable to take the time to collaborate at all right now no one could blame you for this: collaboration takes time and work and business sometimes makes other demands. But if so, then the BIP process is probably not the right venue for your specification. Wrt other wallets: This isn't the time/place to debate the content in general. But since a list was provided above: I do not believe that Bitcoin-QT would implement the current draft: Tied secrets for multiwallet results in non-ideal key management (including preventing mutual denyability of separate wallets, to use a use-case from a prior bit), because of the lack of multi-factor support, and because of the lack of support for recurring payment chains. (I also consider the chain identifier inelegant, but at least the sort of thing that could be tolerated for interoperability. Not so for the feature constraints). |
|
@prusnak Yes, please go ahead with myTrezor. It's a great service. See if any of the other parties will adopt your structure. I think until then all the standardization that is needed as a BIP is the "m / purpose' / *" part, to make sure no one else gets in your way. I just had the idea that we could change BIP32 in a way so that we rip out all the structural definitions from it (I think it has been proposed before as no one plans to use it). Then move the "m / purpose' / *" part from this PR to BIP32. |
|
@laanwj It was joke/sarcasm about how the standardizing process is non-transparent. Every time I'm trying to push some proposal here, I'm regretting that. Honestly, I really don't need any standard to roll out any of my software to the world. It makes only unnecessary obstacles and delays to me. When I released Stratum and started pushing it to other pools, I have been heavily criticized that I'm not "for community" and I'm not willing to contribute by some nice BIP for other developers, because they need to reverse-engineer my reference code. When I want to "contribute to community" and I discuss things for many months on mailing list, writing down all the specification in advance of using that in real life, to be in compliance with all that burreaucratism, I'm heavily criticized that I'm pushing some draft which isn't used in real life and why I'm such hurry with that. Those people maybe don't realize that I have other things to work than battle for hours because of one non-controversial PR. Discussing the topic in private and public mailing lists, spend hours and hours arguing for my ideas, writing down documents which are completely useless for ME and my team and trying to standardize things in Bitcoin world for better interoperability is then blocked by people who feels like they have some superpower by blocking these proposals in github, even when there's no obvious real reason to do so. Years ago I was able to edit such things in bitcoin.it wiki and nobody really cared. Now every changed line is like win a huge battle. Come on, I'm losing my faith in all this theatre. |
@gmaxwell This PR is the result of MONTHS and MONTHS of discussion, everything has been discussed twice elsewhere. There's no need to open any discussion about this again in this PR. This is just write down of those ideas; some people agree with them, some people don't agree with them. That's life. For those who disagree we proposed at least m/purpose'/ part, to be forward compatible.
@gmaxwell Maybe he's disappointed enough that he does not care anymore. |
|
@gmaxwell Ok, last question - is that "64" really so huge obstacle so I need to rename it and change all apperance in the text? I didn't take it too seriously and I even tried to use humour before. Obviously it didn't work. That joke with 2x32 - I really don't think @sipa care at all, having number "64" doesn't mean that the proposal is any better than "32". That renaming is just... another burreucracy. There's already discussion about "BIP64" in the wild, 64 is free to use, 64 is nice number for given topic..... yet if you say it MUST be 43, it WILL be 43... :-/ |
|
There are just some slight rules to keep everything organized. It would get pretty chaotic if people picked random numbers all over the spectrum for each BIP. Other standards (like Python PIPs, RFCs) also have a process for assigning numbers. You don't have to take all the discussion into account for your draft, it looks to me that people are just trying to be helpful, not flaming your proposal. I don't see anyone mentioning critical flaws. No "fight" at all. ACK after changing the number |
|
I'll split "m / purpose' / *" thingie into BIP43 like @schildbach suggested and the rest of the proposal to BIP44, withdraw this pull request and issue a new one. OK? |
|
I'm fine with making an exception for jokes. But, at least in my eyes, this proposal is not funny enough to classify as a joke, sorry. |
|
I think this statement should be definitely a part of BIP1. |
|
Feel free to add it. |
|
... and then discuss it 3 months on a mailing list AND on a github pull request. |
|
That BIP42 thing felt indeed borderline to me. It was phrased as a joke, so I did not take it serious from the beginning. I was under the impression it would be removed the next day anyway. But I learned it was there to stay. So in a way, it smuggled in a specification "under the radar". I would prefer if such "jokes" would not be repeated in future for something as serious as Bitcoin standardization. |
|
@laanwj You're not serious, right? Gmaxwell gave allocated BIP number for some other BIP just for joke and you're advocating it, although "42" has no special meaning in the context of that BIP? I'm asking for free specific BIP number because it has at least some meaning and it is easy to remember (which btw matters, because potentially it will be something what people will be dealing in wallet software comparsion table) and you all are saying that it is against rules? This is absurd threatre. Ok, back to work, @prusnak is right now editing the text to be in line with all your requirements. |
|
Everyone wants a number that is easy to remember. |
|
Of course, and I don't see any problem with it. It's just a number, why don't allocate it, when somebody ask for it. Or do you reserve it for any other joke? Btw don't skip the fact that BIP42 has been ALREADY ALLOCATED. |
|
FWIW, 43 is easy to remember. It's the 14th smallest prime number. |
|
Btw PR is already closed and I told everything to the topic so I don't need to continue in this discussion. |
Good idea. Maybe one about a distributed system for auctioning desirable BIP numbers in a fair way. |
|
FWIW— Yes, I allocated you numbers per your request over a year ago and you have not done anything with them. When the BIP42 came up it was the next number available without an actual topic assigned and the number worked out nicely (the pull req number was even 42). It did not disrupt any actual assignments as only 40 and 41 were assigned. Reserving space to avoid breaking up a sequence doesn't make a lot of sense when there isn't even a single spec in the sequence. Keep in mind, it's just a number. Making a fuss about a number and steadfastly refusing to alter even this smallest thing in something thats supposted to be a public process? I think thats "absurd theater" if anything is.
Yes, and although it wasn't initially apparent to me not that it's come up it seems to me that it isn't proper to privilege a specification that a more-or-less a single vendor is pushing with a snazzy number like that (it didn't even occur to me that it was a snazzy number at first). The dialog in this discussion make it seem to me that the purpose of this proposal isn't to use the standard process to produce something better, or even something that multiple implementers can agree on, but rather to create a veneer of officiality for a non-negotiable vendor specific specification to use as a competitive bludgeon. I think we do intend the process to be open enough to include single-vendor-specs, but I don't think that extends as far as getting choice of numbers in order to make the existence of the BIP easier to misuse. In any case, I'm happy with the plan to split. I think that fits a lot better with what people have indicated a willingness to implement. |
|
There you have it, 44 is more memorable (for most people) than either 64 or 42. Sometimes good things do come out of long winded discussions! |
|
Obsoleted by #53 |
Add test vectors for messages longer than 32 bytes
This BIP defines logical hierarchy for deterministic wallets based on algorithm described in BIP-0032. It is a particular application of the general idea described there.