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