* [bitcoin-dev] Services bit for xthin blocks @ 2016-03-07 20:06 G. Andrew Stone 2016-03-07 20:51 ` Gregory Maxwell 2016-03-07 21:09 ` [bitcoin-dev] " Tier Nolan 0 siblings, 2 replies; 10+ messages in thread From: G. Andrew Stone @ 2016-03-07 20:06 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 210 bytes --] The Bitcoin Unlimited client needs a services bit to indicate that the node is capable of communicating thin blocks. We propose to use bit 4 as AFAIK bit 3 is already earmarked for Segregated Witness. Andrew [-- Attachment #2: Type: text/html, Size: 261 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-07 20:06 [bitcoin-dev] Services bit for xthin blocks G. Andrew Stone @ 2016-03-07 20:51 ` Gregory Maxwell 2016-03-07 21:10 ` dagurval 2016-03-08 5:14 ` Dave Scotese 2016-03-07 21:09 ` [bitcoin-dev] " Tier Nolan 1 sibling, 2 replies; 10+ messages in thread From: Gregory Maxwell @ 2016-03-07 20:51 UTC (permalink / raw) To: G. Andrew Stone; +Cc: Bitcoin Dev On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > The Bitcoin Unlimited client needs a services bit to indicate that the node > is capable of communicating thin blocks. We propose to use bit 4 as AFAIK > bit 3 is already earmarked for Segregated Witness. Does this functionality change peer selection? If not, the preferred signaling mechanism is probably the one in BIP 130. Otherwise, I think the standard method for getting numbers has been to write a BIP documenting the usage. I don't know if that is intentional or just how things have previously happened; and I don't have much of an opinion on it. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-07 20:51 ` Gregory Maxwell @ 2016-03-07 21:10 ` dagurval 2016-03-08 2:35 ` G. Andrew Stone 2016-03-08 5:14 ` Dave Scotese 1 sibling, 1 reply; 10+ messages in thread From: dagurval @ 2016-03-07 21:10 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1120 bytes --] Hi, > Does this functionality change peer selection? This bit will be used for selecting outgoing peers in Bitcoin XT. On Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > The Bitcoin Unlimited client needs a services bit to indicate that the > node > > is capable of communicating thin blocks. We propose to use bit 4 as > AFAIK > > bit 3 is already earmarked for Segregated Witness. > > Does this functionality change peer selection? If not, the preferred > signaling mechanism is probably the one in BIP 130. > > Otherwise, I think the standard method for getting numbers has been to > write a BIP documenting the usage. I don't know if that is intentional > or just how things have previously happened; and I don't have much of > an opinion on it. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1959 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-07 21:10 ` dagurval @ 2016-03-08 2:35 ` G. Andrew Stone 2016-03-08 17:19 ` Luke Dashjr 0 siblings, 1 reply; 10+ messages in thread From: G. Andrew Stone @ 2016-03-08 2:35 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3782 bytes --] Included at the bottom of this mail is a BIP concerning our impending use of a particular services bit. I am making a good-faith effort to notify the community of this use and follow the BIP submission rules with a correctly formatted BIP sent to Luke jr. He has informed me that such a BIP should be discussed on the mailing list (which is this thread) and that the BIP should document the extreme thin block protocol. Not an unreasonable request, however while I personally respect the many great accomplishments of individual engineers loosely affiliated with "Core", Bitcoin Unlimited has our own process for documentation and discussion on an uncensored forum located here: https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We would love to have any interested engineer join us there with ideas and criticisms. But since Bitcoin Unlimited already has a process, it would be redundant and time consuming for us to adhere to your process. If a "Core" engineer would like to spend the time to move this BIP through your process I would be eternally grateful and be willing to use a different bit or make other changes that make mutual sense. If not, then it is up to "Core" as a group to decide whether they would like to preserve interoperability as the protocol intended by avoiding use of bit 1<<4 (except to indicate the presence of a compatible Xthin implementation), or whether they will force clients to take the sub-version field into account when determining client capabilities. Regards, Andrew Stone Developer, Bitcoin Unlimited <pre> BIP: XXX Title: Extreme thin block service bit Author: Andrew Stone <g.andrew.stone@gmail•com> Status: Type: Standards Track Created: 2016-03-07 </pre> ==Abstract== Nodes need to communicate to each other whether or not thin block communication messages are supported. ==Motivation== # Ensure Satoshi client interoperability ==Rationale== Clients will use this functionality to choose peers, so a service bit is the most appropriate location. ==Specification== # Bit (1 << 4) of the nServices flags enum located in protocol.h shall indicate the ability to handle thin block communication messages. ==Backward compatibility== All older clients are compatible with this change. Users and merchants should not be impacted. ==Implementation== /** nServices flags */ enum { ... // NODE_XTHIN means the node is capable of and willing to handle Xthin messages. NODE_XTHIN = (1 << 4), ... }; ==Copyright== This document is Public Domain. On Mon, Mar 7, 2016 at 4:10 PM, dagurval <dagurvj+btclist@gmail•com> wrote: > Hi, > > > Does this functionality change peer selection? > > This bit will be used for selecting outgoing peers in Bitcoin XT. > > On Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> > The Bitcoin Unlimited client needs a services bit to indicate that the >> node >> > is capable of communicating thin blocks. We propose to use bit 4 as >> AFAIK >> > bit 3 is already earmarked for Segregated Witness. >> >> Does this functionality change peer selection? If not, the preferred >> signaling mechanism is probably the one in BIP 130. >> >> Otherwise, I think the standard method for getting numbers has been to >> write a BIP documenting the usage. I don't know if that is intentional >> or just how things have previously happened; and I don't have much of >> an opinion on it. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > [-- Attachment #2: Type: text/html, Size: 5471 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-08 2:35 ` G. Andrew Stone @ 2016-03-08 17:19 ` Luke Dashjr 2016-03-09 18:11 ` G. Andrew Stone 0 siblings, 1 reply; 10+ messages in thread From: Luke Dashjr @ 2016-03-08 17:19 UTC (permalink / raw) To: bitcoin-dev, G. Andrew Stone On Tuesday, March 08, 2016 2:35:21 AM G. Andrew Stone via bitcoin-dev wrote: > Not an unreasonable request, however while I personally respect the many > great accomplishments of individual engineers loosely affiliated with > "Core", Bitcoin Unlimited has our own process for documentation and > discussion on an uncensored forum located here: > https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We > would love to have any interested engineer join us there with ideas and > criticisms. Bitcoin-dev and the BIP process are not affiliated with Core at all. In fact, the BIP process was created by Amir Taaki, who was a libbitcoin developer (libbitcoin is not Core). I encourage Bitcoin Unlimited to use the BIP process for cross-implementation standards like this, as do other implementations, so that you can benefit from peer review from the wider Bitcoin development community, as well as have a common repository for these standards. Many BIPs are discussed on reddit in addition to this mailing list, and you would certainly remain free to discuss your own proposals on any forum you like - it isn't restricted to only this mailing list. If this is of interest, I will be happy to try to go over and assign BIP numbers to the current (15?) BUIPs assuming they meet the basic requirements for such assignment (see BIP 1: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there an easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all, for example. Thanks, Luke ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-08 17:19 ` Luke Dashjr @ 2016-03-09 18:11 ` G. Andrew Stone 2016-03-09 21:11 ` Tier Nolan 0 siblings, 1 reply; 10+ messages in thread From: G. Andrew Stone @ 2016-03-09 18:11 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1995 bytes --] Thanks for your offer Luke, but we are happy with our own process and, regardless of historical provenance, see this mailing list and the BIP process as very Core specific for reasons that are too numerous to describe here but should be obvious to anyone who has been aware of the last year of Bitcoin history. Andrew On Tue, Mar 8, 2016 at 12:19 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Tuesday, March 08, 2016 2:35:21 AM G. Andrew Stone via bitcoin-dev > wrote: > > Not an unreasonable request, however while I personally respect the many > > great accomplishments of individual engineers loosely affiliated with > > "Core", Bitcoin Unlimited has our own process for documentation and > > discussion on an uncensored forum located here: > > https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We > > would love to have any interested engineer join us there with ideas and > > criticisms. > > Bitcoin-dev and the BIP process are not affiliated with Core at all. In > fact, > the BIP process was created by Amir Taaki, who was a libbitcoin developer > (libbitcoin is not Core). > > I encourage Bitcoin Unlimited to use the BIP process for > cross-implementation > standards like this, as do other implementations, so that you can benefit > from > peer review from the wider Bitcoin development community, as well as have a > common repository for these standards. > > Many BIPs are discussed on reddit in addition to this mailing list, and you > would certainly remain free to discuss your own proposals on any forum you > like - it isn't restricted to only this mailing list. > > If this is of interest, I will be happy to try to go over and assign BIP > numbers to the current (15?) BUIPs assuming they meet the basic > requirements > for such assignment (see BIP 1: > https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there > an > easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all, > for > example. > > Thanks, > > Luke > > [-- Attachment #2: Type: text/html, Size: 2683 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-09 18:11 ` G. Andrew Stone @ 2016-03-09 21:11 ` Tier Nolan 0 siblings, 0 replies; 10+ messages in thread From: Tier Nolan @ 2016-03-09 21:11 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2982 bytes --] On Wed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Thanks for your offer Luke, but we are happy with our own process and, > regardless of historical provenance, see this mailing list and the BIP > process as very Core specific for reasons that are too numerous to describe > here but should be obvious to anyone who has been aware of the last year of > Bitcoin history. > One of the advantages with the BIP process is that it means that there are hashlocked descriptions of the specs available for people to implement against. The BIP process is not the same as getting a PR accepted into core. It is not a veto based process. If you write the BIP and it doesn't have any serious technical problems, then it will be accepted into the BIP repo. Getting it marked as "final" is harder but I don't think that matters much. I don't think that core would actually use a service bit that was claimed in a BIP, even if the BIP wasn't final. Maybe in 20 years if thin blocks aren't being used, they might recycle it. It would be pretty obviously an aggressive act otherwise. The NODE_GETUTXO bit is a perfect example of that. They don't think it is a good idea, but they still accepted the claim on the bit, because there are nodes actually using it. On the other hand, the BIP git repository is hosted on the /bitcoin github site, so in that context it can be seen as linked with core. I wouldn't be surprised if that specific objection was raised when it was moved from the wiki to github. Luke may be willing to change that if you think that would be worth changing? With regards to the proposal, the description on the forum link isn't sufficient for an alternative client to implement it. I had a look at the thread and I think that this is the implementation? https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b Is the intention here to simply reserve the bit for thin blocks usage or to define the specification for inter-operation with other clients? Perhaps there could be a process for claiming service bits as it can be useful to claim a bit in advance of actually finalizing the feature. - Claim bit with a reasonable justification (good faith intent to implement and the bit is useful for the feature) - Within 3 months have a finalized description of the feature that lets other clients implement it - Within 6 months have working software that deploys the feature - After 6 months of it actually being in active use, the bit is "locked" and stays assigned to that feature There could be an expiry process if it ends up not being used after all. Requiring a public description of the feature seems like a reasonable requirement in exchange for the community assigning the service bit, but we don't want to go to far. There is no point in having lots of free bits that end up never being used. Worst case, the addr message could be updated to add more bits. [-- Attachment #2: Type: text/html, Size: 3751 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-07 20:51 ` Gregory Maxwell 2016-03-07 21:10 ` dagurval @ 2016-03-08 5:14 ` Dave Scotese [not found] ` <CAAS2fgSf_qYaT7ahQTbmRoQpG57qgF26NKVuGGaEzpMZmCOFoA@mail.gmail.com> 1 sibling, 1 reply; 10+ messages in thread From: Dave Scotese @ 2016-03-08 5:14 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2472 bytes --] I think a BIP is a good idea, but rather than making such a specific proposal as "Let's use bit 4 to indicate communication of thin blocks," how about a more general one like "Let's use bit(s?) 4(-5?) as user-agent specific service bits so that if you customize your user-agent string, you can use them for whatever you want"? That way, other clients can choose to follow suit by saying so, or simply recognize the meaning (or lack thereof) of those bits based on the user-agent setting. This relieves future development from the burden of agreeing on where to put what, and allows time and utility to show when such a user-agent-specific service bit should be moved into the protocol section of service bits. PS I am not well versed in the creation of standards, but the reservation of digital real estate for self-identified customization (bits, bytes, or whatever that will never be used by the standard) such as what I'm proposing seems like something that probably has a standard name. "Public provisioning" or something like that? On Mon, Mar 7, 2016 at 12:51 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > The Bitcoin Unlimited client needs a services bit to indicate that the > node > > is capable of communicating thin blocks. We propose to use bit 4 as > AFAIK > > bit 3 is already earmarked for Segregated Witness. > > Does this functionality change peer selection? If not, the preferred > signaling mechanism is probably the one in BIP 130. > > Otherwise, I think the standard method for getting numbers has been to > write a BIP documenting the usage. I don't know if that is intentional > or just how things have previously happened; and I don't have much of > an opinion on it. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 3404 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAAS2fgSf_qYaT7ahQTbmRoQpG57qgF26NKVuGGaEzpMZmCOFoA@mail.gmail.com>]
* [bitcoin-dev] Fwd: Services bit for xthin blocks [not found] ` <CAAS2fgSf_qYaT7ahQTbmRoQpG57qgF26NKVuGGaEzpMZmCOFoA@mail.gmail.com> @ 2016-03-08 6:09 ` Gregory Maxwell 0 siblings, 0 replies; 10+ messages in thread From: Gregory Maxwell @ 2016-03-08 6:09 UTC (permalink / raw) To: Bitcoin Dev On Tue, Mar 8, 2016 at 5:14 AM, Dave Scotese <dscotese@litmocracy•com> wrote: > I think a BIP is a good idea, but rather than making such a specific > proposal as "Let's use bit 4 to indicate communication of thin blocks," how > about a more general one like "Let's use bit(s?) 4(-5?) as user-agent Not communicated in address messages, so useless for discovery. I think any feature which could do this could use the BIP130 approach instead. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Services bit for xthin blocks 2016-03-07 20:06 [bitcoin-dev] Services bit for xthin blocks G. Andrew Stone 2016-03-07 20:51 ` Gregory Maxwell @ 2016-03-07 21:09 ` Tier Nolan 1 sibling, 0 replies; 10+ messages in thread From: Tier Nolan @ 2016-03-07 21:09 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1218 bytes --] These are the relevant info BIPs. NODE_GETUTXO https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki NODE_BLOOM: https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki The relevant code is here: https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L228 The NODE_GETUTXO bit was included even though it is not supported by core. (It is one of XT's features). I think you need to be able to reasonably claim that the bit is useful and will have actual users, before you can claim a bit. You can also claim one of the free for all bits 24 - 31, but that is supposed to be only temporary. Giving a link to "thin blocks" would help promote discussion about its merits. On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > The Bitcoin Unlimited client needs a services bit to indicate that the > node is capable of communicating thin blocks. We propose to use bit 4 as > AFAIK bit 3 is already earmarked for Segregated Witness. > > Andrew > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2318 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-03-09 21:11 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-07 20:06 [bitcoin-dev] Services bit for xthin blocks G. Andrew Stone
2016-03-07 20:51 ` Gregory Maxwell
2016-03-07 21:10 ` dagurval
2016-03-08 2:35 ` G. Andrew Stone
2016-03-08 17:19 ` Luke Dashjr
2016-03-09 18:11 ` G. Andrew Stone
2016-03-09 21:11 ` Tier Nolan
2016-03-08 5:14 ` Dave Scotese
[not found] ` <CAAS2fgSf_qYaT7ahQTbmRoQpG57qgF26NKVuGGaEzpMZmCOFoA@mail.gmail.com>
2016-03-08 6:09 ` [bitcoin-dev] Fwd: " Gregory Maxwell
2016-03-07 21:09 ` [bitcoin-dev] " Tier Nolan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox