Draft of a BIP for getutxos message. #88

mikehearn commented at 2:22 PM on July 10, 2014: contributor

I'm not sure what the process is for picking a number, so I just grabbed one that's free.

Discussion of anything trivial (spelling etc) here please.

Discussions of anything substantial (design etc) on the mailing list please.

Spelling BIP 39 cd8810f1aa

laanwj commented at 2:31 PM on July 10, 2014: member

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

in bip-0045.mediawiki:None in 6058b92f5d outdated

  68 | +|}
  69 | +
  70 | +==Backward compatibility==
  71 | +
  72 | +Nodes indicate support by advertising a protocol version above 70003 and by setting a new
  73 | +NODE_GETUTXO flag in their nServices field, which has a value of 2 (1 << 1).

wozz commented at 2:33 PM on July 10, 2014:

The last part of this line isn't showing up right.

mikehearn renamed this:
~~Draft of BIP 45, getutxos message.~~
Draft of a BIP for getutxos message.
on Jul 10, 2014

maraoz commented at 3:01 PM on July 10, 2014: contributor

@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

sipa commented at 3:18 PM on July 10, 2014: member

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...).

jgarzik commented at 3:27 PM on July 10, 2014: contributor

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

mikehearn commented at 10:05 AM on July 11, 2014: contributor

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.

jgarzik commented at 10:54 AM on July 11, 2014: contributor

...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.

laanwj commented at 9:26 AM on July 14, 2014: member

There is an implementation and I think we had enough feedback on this already in https://github.com/bitcoin/bitcoin/pull/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.

gmaxwell commented at 11:41 AM on July 14, 2014: contributor

Sure, wasn't intending to. BIP 0064.

jrick commented at 12:13 AM on July 16, 2014: none

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?

mikehearn commented at 9:31 AM on July 16, 2014: contributor

Good catch, thanks!

laanwj cross-referenced this on Aug 8, 2014 from issue Add a getutxos command to the p2p protocol by mikehearn

BIP 64: getutxo message 9aa27f0f46

mikehearn commented at 12:05 PM on August 11, 2014: contributor

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

laanwj closed this on Aug 11, 2014

real-or-random referenced this in commit 2d7c5975b0 on Mar 6, 2023