* [Bitcoin-development] Supermajority mining votes for valid->invalid changes.
@ 2011-10-03 4:53 Gregory Maxwell
2011-10-03 5:32 ` Luke-Jr
0 siblings, 1 reply; 3+ messages in thread
From: Gregory Maxwell @ 2011-10-03 4:53 UTC (permalink / raw)
To: Bitcoin Development
It is possible to made changes to the distributed algorithm which make
previously valid txn invalid without necessarily creating any lasting
chain splits. This has been proposed for the addition of the eval
opcode by using one of the existing NOPs.
One challenge is that if transactions are emitted which are invalid
under the new scheme but valid under the old after the block height
that the rule is coded to take effect and a super-majority of miners
are not yet upgraded the upgrade may cause a long reorganization and
serious disruption.
Here I explain one possible way of avoiding this.
Upgraded nodes get the following rules:
(0) Never forward or mine a txn which would be invalid under the new rule.
(1) Apply old behavior before height X unconditionally.
(X set far enough in the future to get reasonable deployment by
large miners)
(2) Begin applying the new rule only after the first point in the chain
after X when none of the last Y blocks have contained an invalid transaction
under the new rules.
After the software has been released members of the bitcoin community then
begin _intentionally_ transmitting transactions which are invalid under
the new rules. (What would have been an attack under simplest deployment plan)
By setting Y high enough that all major miners have a chance to mine
in the window,
this actually becomes an effective vote for the change by miners with
a stochastic
super-majority threshold. All nodes are able to exactly determine at what block
the election has completed because it is an objective fact of the chain.
With this scheme the new encoding will only become active when enough mining
capacity supports it (or at least helpfully refuses to mine the who class
of transactions) so that a large reorganization will not happen due to
incompatible blocks during deployment.
This could be further enhanced with conflicting block discouragement (e.g.
refusing to extend or forward a rules violating block until it is burred)
but I think this scheme is sufficient without that, and that this is generally
superior to discouragement for this purpose.
Cheers.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bitcoin-development] Supermajority mining votes for valid->invalid changes.
2011-10-03 4:53 [Bitcoin-development] Supermajority mining votes for valid->invalid changes Gregory Maxwell
@ 2011-10-03 5:32 ` Luke-Jr
2011-10-03 5:39 ` Gregory Maxwell
0 siblings, 1 reply; 3+ messages in thread
From: Luke-Jr @ 2011-10-03 5:32 UTC (permalink / raw)
To: bitcoin-development
On Monday, October 03, 2011 12:53:51 AM Gregory Maxwell wrote:
> Upgraded nodes get the following rules:
> (0) Never forward or mine a txn which would be invalid under the new rule.
> (1) Apply old behavior before height X unconditionally.
> (X set far enough in the future to get reasonable deployment by
> large miners)
> (2) Begin applying the new rule only after the first point in the chain
> after X when none of the last Y blocks have contained an invalid
> transaction under the new rules.
Perhaps as a safeguard:
(3) Before applying the new rule, require 50% of the last Y blocks contain a
coinbase with a "I am upgraded" code
(4) Until the new rule is active, include an "I am upgraded" code in every
block; after it's active, this can be turned off
> After the software has been released members of the bitcoin community then
> begin _intentionally_ transmitting transactions which are invalid under
> the new rules. (What would have been an attack under simplest deployment
> plan)
Why would legitimate community members ever intentionally transmit an invalid
transaction? ;)
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bitcoin-development] Supermajority mining votes for valid->invalid changes.
2011-10-03 5:32 ` Luke-Jr
@ 2011-10-03 5:39 ` Gregory Maxwell
0 siblings, 0 replies; 3+ messages in thread
From: Gregory Maxwell @ 2011-10-03 5:39 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Mon, Oct 3, 2011 at 1:32 AM, Luke-Jr <luke@dashjr•org> wrote:
> Perhaps as a safeguard:
> (3) Before applying the new rule, require 50% of the last Y blocks contain a
> coinbase with a "I am upgraded" code
> (4) Until the new rule is active, include an "I am upgraded" code in every
> block; after it's active, this can be turned off
(4) is a nice idea.
I was hoping to avoid (3) simply because for any one of these upgrades
hopefully 95% of the network is neutral wrt the change because they
won't mine either form of the transactions.
The active statement has the benefit that it constitutes a proof: You
know with specific confidence (based on the window size) how likely a
fork of length X will be if a newly invalid transaction is announced
at the time of the activation.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-10-03 5:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-03 4:53 [Bitcoin-development] Supermajority mining votes for valid->invalid changes Gregory Maxwell
2011-10-03 5:32 ` Luke-Jr
2011-10-03 5:39 ` Gregory Maxwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox