Post
📅 Original date posted:2014-06-17
📝 Original message:For my replace-by-fee implementation(1) I used service bit 26 to let
preferential peering work so that replace-by-fee nodes could easily find
each other. Of course, that's a temporary/experimental usage that can be
dropped after wider adoption, so I included the following comment:
// Reserve 24-31 for temporary experiments
NODE_REPLACE_BY_FEE = (1 << 26)
Service bits are never a guaranteed thing anyway, so occasional
collisions can and should be tolerated by applications using these
experimental service bits.
Alternately Wladimir J. van der Laan brought up elsewhere(2) the
possibility for a wider notion of an extension namespace. I'm personally
not convinced of the short-term need - we've got 64 service bits yet
NODE_BLOOM is the first fully fleshed out proposal to use one - but it's
worth thinking about for the long term.
1) github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
2) github.com/bitcoin/bitcoin/pull/4351#issuecomment-46272958
--
'peter'[:-1]@petertodd.org
000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/f952e072/attachment.sig>
0
0
0
📅 Original date posted:2014-06-17
📝 Original message:On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd <pete at petertodd.org> wrote:
> Alternately Wladimir J. van der Laan brought up elsewhere(2) the
> possibility for a wider notion of an extension namespace. I'm personally
> not convinced of the short-term need - we've got 64 service bits yet
> NODE_BLOOM is the first fully fleshed out proposal to use one - but it's
> worth thinking about for the long term
Yes, as I said in the github topic
(github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
string-based name space for extensions.
A new network version could add a command 'getextensions' to query the
supported extensions, returning a list of extension strings or
(extension,version) pairs. For BIPs some something like 'BIP0064'
could be defined, but for an experiment for example
'experimental-getutxo'. This would be easy to implement and specify.
Unlike with the 64 service bits it does not require (as much) central
coordination to assign as there is no real danger of collisions. It
takes the political aspect out of P2P network extensions, and gives
more freedom to alternative implementations to experiment with their
own extensions. And no more need for bitcoin core to drive what must
be supported with increasing network versions.
Wladimir
0
0
0