📅 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) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/f952e072/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:22:57
in reply to nevent1q…xhnp
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:22:57Event JSON
{
"id": "3ea1b60ef4fb944aacda5627f225710d44cc97f0e616436410fcaf400e6bf893",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686151377,
"kind": 1,
"tags": [
[
"e",
"51755e520e5fac5e694b75add8f1aed031a6d31795ec0eb481e5e52e0d57e975",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-06-17\n📝 Original message:For my replace-by-fee implementation(1) I used service bit 26 to let\npreferential peering work so that replace-by-fee nodes could easily find\neach other. Of course, that's a temporary/experimental usage that can be\ndropped after wider adoption, so I included the following comment:\n\n // Reserve 24-31 for temporary experiments\n NODE_REPLACE_BY_FEE = (1 \u003c\u003c 26)\n\nService bits are never a guaranteed thing anyway, so occasional\ncollisions can and should be tolerated by applications using these\nexperimental service bits.\n\n\nAlternately Wladimir J. van der Laan brought up elsewhere(2) the\npossibility for a wider notion of an extension namespace. I'm personally\nnot convinced of the short-term need - we've got 64 service bits yet\nNODE_BLOOM is the first fully fleshed out proposal to use one - but it's\nworth thinking about for the long term.\n\n1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1\n2) https://github.com/bitcoin/bitcoin/pull/4351#issuecomment-46272958\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/f952e072/attachment.sig\u003e",
"sig": "7ead0b91c1ce6d018168a6c1717eac284e4205c0ee68cc5000cc3451896504c7ed6b7e37301dfa25e91d9cf04325fe41cd5099f72fe9b52ecfb1753ccadd1844"
}