@mikehearn you should mail gmaxwell at gmaxwell@gmail.com to assign a number (that's from BIP 1)

@gmaxwell Please don't assign BIP45 as that's what we're using for the reference implementation of our bip32+bip43 multisig structure in copay. See: https://github.com/maraoz/bips/blob/master/bip-NNNN.mediawiki. BIPs 44 to 50 should be left for particular BIP43 structures, IMO

QED.

That's why we don't want people to use numbers before requesting them (at least you don't have them in the document itself yet...).

Indeed. The standard, documented policy is that you cannot self-assign numbers, for precisely reasons like this.

Seems like a timesink to me - we have a numbers list in the README and a list of pending changes to it in github, that's all we need to avoid numbering conflicts. But whatever. Wherever the global counter is kept is neither here nor there. It's the content that matters.

...and we have just had a numbering conflict, precisely because of this. Just ask @gmaxwell who is the maintainer for a number when it is time.

Additionally, per BIP discussion, automatically assigning (or making up) BIP numbers implies to the general public that the BIP is accepted. We have already had confusion related to that in the past.

The IETF RFC process should work fine here: Create an implementation, create a draft, push to the drafts/ area. Comment feedback comment, get a BIP number.

There is an implementation and I think we had enough feedback on this already in bitcoin/bitcoin#4351 . It was also posted as draft to the mailing list. IMO this should be assigned a number now. One can agree or disagree with the protocol change itself, but I think @mikehearn did a fine job in documenting and implementing it, and there is no need to hold this up further for procedural reasons.

Sure, wasn't intending to. BIP 0064.

It appears to be correct in the implementation, but I believe you meant to use uint32, not uint256, for the height of a "result object".

edit: actually, implementation has an int, and not just for the height, but the version as well. Why is that not a fixed size type? And why does the signed-ness not match the BIP?

Good catch, thanks!

Squashed and fully renamed to BIP 64. All feedback has been incorporated.