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) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
2) https://github.com/bitcoin/bitcoin/pull/4351#issuecomment-46272958
--
'peter'[:-1]@petertodd.org
000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
