diff options
author | odinn <odinn.cyberguerrilla@riseup.net> | 2015-08-20 20:22:46 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-21 03:22:48 +0000 |
commit | 992e928d2779562c23cd0467ea38ffb07a43564b (patch) | |
tree | 50e086dd95d3e0b6671d3650dfa9568b9bac9e79 | |
parent | dbc768e229f56a393bcda83291032ec5c2baf503 (diff) | |
download | pi-bitcoindev-992e928d2779562c23cd0467ea38ffb07a43564b.tar.gz pi-bitcoindev-992e928d2779562c23cd0467ea38ffb07a43564b.zip |
Re: [bitcoin-dev] Economic majority vote by splitting coins
-rw-r--r-- | 20/8080f89f36f3b1d7e3321d3f0ab37caf70414a | 159 |
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----- + |