summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorodinn <odinn.cyberguerrilla@riseup.net>2015-08-20 20:22:46 -0700
committerbitcoindev <bitcoindev@gnusha.org>2015-08-21 03:22:48 +0000
commit992e928d2779562c23cd0467ea38ffb07a43564b (patch)
tree50e086dd95d3e0b6671d3650dfa9568b9bac9e79
parentdbc768e229f56a393bcda83291032ec5c2baf503 (diff)
downloadpi-bitcoindev-992e928d2779562c23cd0467ea38ffb07a43564b.tar.gz
pi-bitcoindev-992e928d2779562c23cd0467ea38ffb07a43564b.zip
Re: [bitcoin-dev] Economic majority vote by splitting coins
-rw-r--r--20/8080f89f36f3b1d7e3321d3f0ab37caf70414a159
1 files changed, 159 insertions, 0 deletions
diff --git a/20/8080f89f36f3b1d7e3321d3f0ab37caf70414a b/20/8080f89f36f3b1d7e3321d3f0ab37caf70414a
new file mode 100644
index 000000000..21ae70eb4
--- /dev/null
+++ b/20/8080f89f36f3b1d7e3321d3f0ab37caf70414a
@@ -0,0 +1,159 @@
+Return-Path: <odinn.cyberguerrilla@riseup.net>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id E81078A6
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 21 Aug 2015 03:22:48 +0000 (UTC)
+X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
+Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BE8489
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 21 Aug 2015 03:22:48 +0000 (UTC)
+Received: from piha.riseup.net (unknown [10.0.1.162])
+ (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
+ (Client CN "*.riseup.net",
+ Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
+ by mx1.riseup.net (Postfix) with ESMTPS id DE2CFC15D2;
+ Thu, 20 Aug 2015 20:22:47 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
+ t=1440127367; bh=k/rrv7XriL7bezfcdSKFfAFHEFEpw3EF9U08Zyao5TY=;
+ h=Date:From:To:Subject:References:In-Reply-To:From;
+ b=V/a3K5iQPHMFptrUvPqzqWh/CszoBtiEIPrLaxzBiMmM7lcKGXEI7egv9cOO4nyzR
+ JvQ9n8SrjMFIMeR7EQqwPostyEBmJLSez6IusQMDIRU58D0V+61ikrkN+M++Qrr59X
+ riYCNo0G5UW86LSEtiTghTkM9GlyJhXoUhLQpnYc=
+Received: from [127.0.0.1] (localhost [127.0.0.1])
+ (Authenticated sender: odinn.cyberguerrilla)
+ with ESMTPSA id 8744B140C9F
+Message-ID: <55D69986.3000307@riseup.net>
+Date: Thu, 20 Aug 2015 20:22:46 -0700
+From: odinn <odinn.cyberguerrilla@riseup.net>
+User-Agent: Mozilla/5.0 (X11; Linux x86_64;
+ rv:31.0) Gecko/20100101 Thunderbird/31.7.0
+MIME-Version: 1.0
+To: Tier Nolan <tier.nolan@gmail.com>,
+ Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+References: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com>
+In-Reply-To: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com>
+Content-Type: text/plain; charset=windows-1252
+Content-Transfer-Encoding: 8bit
+X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
+X-Virus-Status: Clean
+X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
+ UNPARSEABLE_RELAY autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Subject: Re: [bitcoin-dev] Economic majority vote by splitting coins
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Fri, 21 Aug 2015 03:22:49 -0000
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+That's interesting. But in all honesty I don't see most users being
+able to pull off what you are describing. If people don't want XT it
+isn't going to get used. If they are convinced that it is needed its
+use will grow but they won't realize how bad they will be misled until
+later, at which point it will be...
+
+.. Too Late
+
+On 08/20/2015 04:16 AM, Tier Nolan via bitcoin-dev wrote:
+> 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.
+>
+>
+> _______________________________________________ bitcoin-dev mailing
+> list bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+- --
+http://abis.io ~
+"a protocol concept to enable decentralization
+and expansion of a giving economy, and a new social good"
+https://keybase.io/odinn
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1
+
+iQEcBAEBAgAGBQJV1pmGAAoJEGxwq/inSG8CH7sH/ik9CE8V97zcALmbRi0w/DFr
+/LxJVUHpl3XhV/2BtQP0Z1qd9OkEhmuG3wOdweCi089ksMbj2BLZ16EgXOnmjXCe
+kB+Wk+nG5DglvQwpV1Tnl7UGfqvtry0sOUH9g5wZxJGIdnin3YQEP+TofJTVkrHw
+MvU/MifsJZlzBHYcjYjGmkyAzhGUcurUAD5q+wz+iq4JsE/Zvtr5mR3ctPoaKx2w
+7wMjSsGRWLYejv+7qYKwEjSV/ELSZCVIPURBUGBzkwWSaXTKdMf17sb44xF5m42i
+5CjsGQxA7pY7EMHbYTz/hfUqElZp5y7MXoxoYkPh9ehyG1HSPSyUnxAPrAhc/+Y=
+=2F2R
+-----END PGP SIGNATURE-----
+