From: Tom Harding <tomh@thinlink.com>
To: Bitcoin-Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Proposal: Hard fork opt-out bits
Date: Sun, 31 Jul 2016 11:01:18 -0700 [thread overview]
Message-ID: <26b3141b-1e7b-05fd-317b-e03b28beb4db@thinlink.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1292 bytes --]
Your thoughts are sought on this simple proposal to allow transaction
authors to restrict execution to fewer than all blockchain forks where
the transaction would otherwise be valid.
Proposal
Node implementations select a bit from among the upper 8 bits of the
transaction version space to enforce as a hard fork opt-out bit.
To specify that a transaction NOT be mined by nodes that enforce a
particular bit, authors set that bit in the transaction version.
Opt-out is enforced by consensus among nodes enforcing each bit.
An implementation will relay, process and mine transactions that opt out
of other blockchain forks; just not those that opt out of its own fork.
Notes
Example: Via soft fork, all implementations may begin enforcing hard
fork opt-out bit 30. Post soft fork, setting this bit would make a
transaction invalid, unless a fork emerges that has stopped enforcing
bit 30.
Example: BIP109 implementations may stop enforcing bit 30 and begin
enforcing bit 28 when the BIP109 hard fork is activated for a chain they
are tracking.
Enforcing more than one hard fork opt-out bit would imply that an
implementation is actively participating in building more than one
blockchain fork, and therefore providing a way to opt out of each.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
reply other threads:[~2016-07-31 18:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26b3141b-1e7b-05fd-317b-e03b28beb4db@thinlink.com \
--to=tomh@thinlink.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox