From: Raph Frank <raphfrk@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Tue, 12 Feb 2013 13:49:56 +0000 [thread overview]
Message-ID: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com> (raw)
Has this been considered?
If made sufficiently general, older clients could support any
extension of the rules.
Various "hard" parameters within the protocol are defined in main.h of
the official client.
In BIP-34, there is a suggested way to make changes, based on consensus.
https://en.bitcoin.it/wiki/BIP_0034
These could be made into a rule for changing the parameters directly.
The process for updating could be handled by adding a new field to the
coinbase transaction, in the same way the height was added in BIP-34.
Something like
- miner proposed a change by by including proposal in a block (name of
parameter and new value)
- seconded by at least 6 of the next 10 blocks (proposal dies otherwise)
- active if 750 of the last 1000 blocks voted yes, or 950 of any
successive 1000 previous blocks voted yes (with reduced thresholds on
testnet)
- dies if more than 500 of the previous 1000 voted No
- blocks which don't reference the proposal are considered to abstain
This could also be used to update NOPs. Complex signing algorithms
could be incorporated. However, that would require a more complex
scripting language for defining opcode functions. The proposal would
have opcode number + script description of algorithm. This would also
allow methods <method name> + <script code>. Once of the NOPs could
be "call method".
The rule would require that the script is valid under the current
rules (NOPs as nops) and under the latest rules. This prevents
needing to try all possible permutations. However, it reduces
security.
An compromise would be to have each new opcode change could as a
version and scripts must be valid under all versions in the chain, so
far.
Once an op-code is accepted, new clients implementations would
probably create dedicated functions for performing the calculation.
Older clients would have to perform the calculations using the
scripting language.
next reply other threads:[~2013-02-12 13:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 Raph Frank [this message]
2013-02-12 15:49 ` Gregory Maxwell
2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
2013-02-14 0:28 ` Gregory Maxwell
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 5:36 ` Stephen Pair
2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` Peter Todd
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=CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com \
--to=raphfrk@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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