public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Economic majority vote by splitting coins
Date: Thu, 20 Aug 2015 12:16:30 +0100	[thread overview]
Message-ID: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

The economic majority is defined as the will of those who actually use
Bitcoin as a payment system.

No matter what the miners want, if users and merchants refuse to accept
their fork, then the fork loses and cannot be considered the "true" bitcoin
fork.

The problem is that it is easy to measure a miner vote.  The economic
majority is not so easy.

The relative value of two forks could be compared by adding a system
similar colored coins.

These contracts could be added with a soft fork like the P2SH one.

OP_IF
    <fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1>
OP_EQUAL
OP_ENDIF
OP_IF
     <fork_id3> OP_DROP OP_HASH160 <hash script 2> OP_EQUAL
OP_ENDIF

This works like P2SH and is template matching.  You can have as many
entries as you want.

In the example, the output can be spent on fork 1 and fork 2 by the owner
of <hash script 1> and can be spent on fork 3 by the owner of <hash script
2>.

Until the deadline, the value on each fork must be preserved when spending
the output.  If you provide the key(s), you are allowed to consolidate
entries.  You can also consolidate multiple outputs to the same key even if
you don't have the key.

This means that split outputs are a little more hassle to use and the
transactions are larger.  This doesn't matter much, since measuring the
relative value of the two sub-coins only requires some of them to be traded.

If someone wants to propose a hard fork, they create a new fork id and
deadline and release software that implements the hard fork at the given
deadline (no miner vote needed).

To prevent spam, there could be a cost to create a fork-id (BTC paid to
OP_RETURN) and the deadline could have a max time in the future (say 2
years).

After the deadline, core will allow conversion of outputs that pay to the
core fork-id (probably 1) to be converted into unencumbered outputs by the
person with the core-id script.  Likewise, the fork software will allow
outputs that pay to the fork id to be converted.  Legacy bitcoin that
haven't been "split" will be spendable on both sides equally.

This means that users can convert x legacy bitcoin into x fork-bitcoins and
x core-bitcoins in advance of the fork.

This means that Exchanges could support trading between the two.  The side
that trades with the most value is the one that is supported by the
economic majority.

As it becomes clear which side is going to win, the price of coins on the
losing side should drop.  It is unlikely that the two would stay at exactly
the same value without one side winning.

Users who want to to use the losing rules are free to do so but the
economic majority will have made its decision.

[-- Attachment #2: Type: text/html, Size: 3134 bytes --]

             reply	other threads:[~2015-08-20 11:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 11:16 Tier Nolan [this message]
2015-08-21  3:22 ` odinn
2015-08-21 11:03   ` Tier Nolan

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=CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com \
    --to=tier.nolan@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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