BIP153: SENDTEMPLATE
Adds a BIP for SENDTEMPLATE, GETTEMPLATE, TEMPLATE p2p messages. Discussion links:
https://delvingbitcoin.org/t/sharing-block-templates/1906
https://gnusha.org/pi/bitcoindev/[email protected]/T/#u
Post to bitcoindev group hasn't made it through
fixed, published
Updated with post-history in metadata and some rationale
Time to request a bip number then I guess?
Let’s call this BIP 153 then!
@ajtowns: What’s your status on this one? Are you still planning changes or waiting for some people to finish their review of this PR?
I think this is fine to merge as draft, further review/changes can happen in that state as I understand it.
I may have overlooked it, but at first glance it looks like the draft is missing important specification on how to implement the goals set forth in the Motivation section. For instance, which peers to request templates from, when/how often, and how the template data is to be used.
I see those as implementation quality issues, which would be added in the "recommendations" section, once it's more clear what those recommendations should be.
I don't see how this doesn't have major privacy leaks, similar to the mempool message
Could the editors please clarify which of these concerns are blockers for merging this BIP in "Draft" status?
Could the editors please clarify which of these concerns are blockers for merging this BIP in "Draft" status?
I don’t perceive the stated concerns as blockers, but agree that this document should be enhanced in the future with further discussion of privacy implications. I’m gonna wait for a few days to allow time for others to comment.
that this document should be enhanced in the future with further discussion of privacy implications.
That's what the "TBA" in the otherwise empty recommendations section is for (as well as efficiency implications and potentially other things)
Could the editors please clarify which of these concerns are blockers for merging this BIP in "Draft" status?
I've been told some editors are privately blocking merge of this PR despite being unwilling to identify any issues as blockers publicly. I don't think that's appropriate, or in accordance with the BIP 2 process, so I'm instead requesting this PR be merged now as-is, publishing the BIP as a draft so it can be easily referenced for further discussion and exploration.
My understanding is that some fingerprinting concerns and privacy concerns have been raised here and in the Bitcoin Core pull request where this feature is being explored. According to the BIP Process, raised concerns should be addressed in the document. I expect that in the context of the feature being proposed, the frequency at which and the context in which it is used is seen as relevant information to weigh in on the utility, viability, and privacy impact. Therefore it would be helpful for readers and reviewers, if there were at least an initial sketch how often and when it would be used.
This is now published as BIN25-2 so I'll be using that repo to refine the document while it's in draft.