Dave Scotese [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-08 📝 Original message:I think a BIP is a good ...
📅 Original date posted:2016-03-08
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
> <bitcoin-dev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160307/d29951b7/attachment-0001.html>;
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
> <bitcoin-dev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160307/d29951b7/attachment-0001.html>;