diff options
| author | Melvin Carvalho <melvincarvalho@gmail.com> | 2013-06-10 10:14:01 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-10 08:14:10 +0000 |
| commit | dc29f59ce381d42795824599e60a1aec87e2af61 (patch) | |
| tree | d833507e373db6df725f864c1f09c9c33e227e3c | |
| parent | b3d4539518c2126d7090ec6fa4471bb0d52adf89 (diff) | |
| download | pi-bitcoindev-dc29f59ce381d42795824599e60a1aec87e2af61.tar.gz pi-bitcoindev-dc29f59ce381d42795824599e60a1aec87e2af61.zip | |
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
| -rw-r--r-- | 0c/3f341b071a509ed22f2ec4fc231748e8a54923 | 484 |
1 files changed, 484 insertions, 0 deletions
diff --git a/0c/3f341b071a509ed22f2ec4fc231748e8a54923 b/0c/3f341b071a509ed22f2ec4fc231748e8a54923 new file mode 100644 index 000000000..1ff729de7 --- /dev/null +++ b/0c/3f341b071a509ed22f2ec4fc231748e8a54923 @@ -0,0 +1,484 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <melvincarvalho@gmail.com>) id 1UlxEw-0003Br-E8 + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Jun 2013 08:14:10 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.215.49 as permitted sender) + client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com; + helo=mail-la0-f49.google.com; +Received: from mail-la0-f49.google.com ([209.85.215.49]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UlxEu-00048M-K1 + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Jun 2013 08:14:10 +0000 +Received: by mail-la0-f49.google.com with SMTP id ea20so1873983lab.8 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 10 Jun 2013 01:14:01 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.112.61.199 with SMTP id s7mr162590lbr.53.1370852041831; Mon, + 10 Jun 2013 01:14:01 -0700 (PDT) +Received: by 10.112.2.8 with HTTP; Mon, 10 Jun 2013 01:14:01 -0700 (PDT) +In-Reply-To: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com> +References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com> +Date: Mon, 10 Jun 2013 10:14:01 +0200 +Message-ID: <CAKaEYhLsSm6KTr3YV+GxQGiBBNX0psxxOYkgwR1pm4ZpBY0Ymw@mail.gmail.com> +From: Melvin Carvalho <melvincarvalho@gmail.com> +To: John Dillon <john.dillon892@googlemail.com> +Content-Type: multipart/alternative; boundary=001a1133d17afe3b8704dec85cd5 +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (melvincarvalho[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1UlxEu-00048M-K1 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit + with proof-of-stake voting +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 10 Jun 2013 08:14:10 -0000 + +--001a1133d17afe3b8704dec85cd5 +Content-Type: text/plain; charset=ISO-8859-1 + +On 10 June 2013 06:09, John Dillon <john.dillon892@googlemail.com> wrote: + +> -----BEGIN PGP SIGNED MESSAGE----- +> Hash: SHA256 +> +> It has been suggested that we leave the decision of what the blocksize to +> be +> entirely up to miners. However this leaves a parameter that affects every +> Bitcoin participant in the control of a small minority. Of course we can +> not +> force miners to increase the blocksize if they choose to decrease it, +> because +> the contents of the blocks they make are their decision and their decision +> only. However proposals to leave the maximum size unlimited to allow +> miners to +> force us to accept arbitrarily large blocks even if the will of the +> majority of +> Bitcoin participants is that they wish to remain able to validate the +> blockchain. +> +> What we need is a way to balance this asymetrical power relationship. +> +> Proof-of-stake voting gives us a way of achieving that balance. +> Essentially for +> a miner to prove that the majority will of the poeple is to accept a larger +> blocksize they must prove that the majority has in fact voted for that +> increase. The upper limit on the blocksize is then determined by the +> median of +> all votes, where each txout in the UTXO set is one vote, weighted by txout +> value. A txout without a corresponding vote is considered to be a vote for +> the +> status quo. To allow the voting process to continue even if coins are +> "lost" +> votes, including default votes, are weighted inversely according to their +> age +> in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old +> will be +> recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day +> old +> and 6 months old UTXO are treated equivalently. The 1 year minimum is +> simply to +> make voting required no more than once per year. (of course, a real +> implementation should do all of these figures by block height, IE after +> 52,560 +> blocks instead of after 1 year) +> +> A vote will consist of a txout with a scriptPubKey of the following form: +> +> OP_RETURN magic vote_id txid vout vote scriptSig +> +> Where scriptSig is a valid signature for a transaction with nLockTime +> 500,000,000-1 spending txid:vout to scriptPubKey: +> +> OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL +> +> vote_id is the ID of the specific vote being made, and magic is included to +> allow UTXO proof implementations a as yet unspecified way of identifying +> votes +> and including the weighted median as part of the UTXO tree sums. (it also +> allows SPV clients to verify the vote if the UTXO set is a Patricia tree of +> scriptPubKeys) vote is just the numerical vote itself. The vote must +> compute +> the median, rather than the mean, so as to not allow someone to skew the +> vote +> by simply setting their value extremely high. Someone who still remembers +> their +> statistics classes should chime in on the right way to compute a median in +> a +> merkle-sum-tree. +> +> The slightly unusual construction of votes makes implementation by wallet +> software as simple as possible within existing code-paths. Votes could +> still be +> constructed even in wallets lacking specific voting capability provided the +> wallet software does have the ability to set nLockTime. +> +> Of course in the future the voting mechanism can be used for additional +> votes +> with an additional vote_id. For instance the Bitcoin community could vote +> to +> increase the inflation subsidy, another example of a situation where the +> wishes +> of miners may conflict with the wishes of the broader community. +> +> Users may of course actually create these specially encoded txouts +> themselves +> and get them into the blockchain. However doing so is not needed as a +> given +> vote is only required to actually be in the chain by a miner wishing to +> increase the blocksize. Thus we should extend the P2P protocol with a +> mechanism +> by which votes can be broadcast independently of transactions. To prevent +> DoS +> attacks only votes with known vote_id's will be accepted, and only for +> txid:vout's already in the blockchain, and a record of txouts for whom +> votes +> have already broadcast will be kept. (this record need not be +> authoritative as +> its purpose is only to prevent DoS attacks) Miners wishing to increase the +> blocksize can record these votes and include them in the blocks they mine +> as +> required. To reduce the cost of including votes in blocks 5% of every block +> should be assigned to voting only. (this can be implemented by a soft-fork) +> +> For any given block actual limit in effect is then the rolling median of +> the +> blocks in the last year. At the beginning of every year the value +> considered to +> be the status quo resets to the mean of the limit at the beginning and end +> of +> the interval. (again, by "year" we really mean 52,560 blocks) The rolling +> median and periodic reset process ensures that the limit changes gradually +> and +> is not influenced by temporary events such as hacks to large exchanges or +> malicious wallet software. The rolling median also ensures that for a +> miner +> the act of including a vote is never wasted due to the txout later being +> spent. +> +> Implementing the voting system can happen prior to an actual hard-fork +> allowing +> for an increase and can be an important part of determining if the +> hard-fork is +> required at all. +> +> Coercion and vote buying is of course possible in this system. A miner +> could +> say that they will only accept transactions accompanied by a vote for a +> given +> limit. However in a decentralized system completely preventing vote buying +> is +> of course impossble, and the design of Bitcoin itself has a fundemental +> assumption that a majority of miners will behave in a specific kind of +> "honest" +> way. +> +> A voting process ensures that any increase to the blocksize genuinely +> represents the desires of the Bitcoin community, and the process described +> above ensures that any changes happen at a rate that gives all participants +> time to react. The process also gives a mechanism for the community to +> vote to +> decrease the limit if it turns out that the new one was in fact too high. +> (note +> how the way the status quo is set ensures the default action is for the +> limit +> to gradually decrease even if everyone stops voting) +> +> As many of you know I have been quite vocal that the 1MB limit should +> stay. But +> I would be happy to support the outcome of a vote done properly, whatever +> that +> outcome may be. +> -----BEGIN PGP SIGNATURE----- +> Version: GnuPG v1.4.11 (GNU/Linux) +> +> iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH +> Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H +> gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS +> ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj +> gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6 +> Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM= +> =aKBD +> -----END PGP SIGNATURE----- +> + +-1 + +Firstly I appreciate the ingenious thought that went into this post. + +However, Bitcoin's fundamental philosophy was one CPU one vote. + +Voting is easily gamed. While this may work in one particular case, it is +perhaps a bad precedent to set. Establishing methods of voting can lead to +single points of failure. + +The asymmetry lies in psychological terms, in that new defaults tend to be +adopted 80% of the time, so core devs have disproportionate amount of power +as things stand. + +Unless there's a very good reason not to, e.g. miners are clearly abusing +the system, we should stick with 1 CPU one vote. + + +> +> +> ------------------------------------------------------------------------------ +> How ServiceNow helps IT people transform IT departments: +> 1. A cloud service to automate IT design, transition and operations +> 2. Dashboards that offer high-level views of enterprise services +> 3. A single system of record for all IT processes +> http://p.sf.net/sfu/servicenow-d2d-j +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +--001a1133d17afe3b8704dec85cd5 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= +_quote">On 10 June 2013 06:09, John Dillon <span dir=3D"ltr"><<a href=3D= +"mailto:john.dillon892@googlemail.com" target=3D"_blank">john.dillon892@goo= +glemail.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left:1px solid rgb(204,204,204);padding-left:1ex">-----BEGIN PGP SIGNED MES= +SAGE-----<br> +Hash: SHA256<br> +<br> +It has been suggested that we leave the decision of what the blocksize to b= +e<br> +entirely up to miners. However this leaves a parameter that affects every<b= +r> +Bitcoin participant in the control of a small minority. Of course we can no= +t<br> +force miners to increase the blocksize if they choose to decrease it, becau= +se<br> +the contents of the blocks they make are their decision and their decision<= +br> +only. However proposals to leave the maximum size unlimited to allow miners= + to<br> +force us to accept arbitrarily large blocks even if the will of the majorit= +y of<br> +Bitcoin participants is that they wish to remain able to validate the<br> +blockchain.<br> +<br> +What we need is a way to balance this asymetrical power relationship.<br> +<br> +Proof-of-stake voting gives us a way of achieving that balance. Essentially= + for<br> +a miner to prove that the majority will of the poeple is to accept a larger= +<br> +blocksize they must prove that the majority has in fact voted for that<br> +increase. The upper limit on the blocksize is then determined by the median= + of<br> +all votes, where each txout in the UTXO set is one vote, weighted by txout<= +br> +value. A txout without a corresponding vote is considered to be a vote for = +the<br> +status quo. To allow the voting process to continue even if coins are "= +;lost"<br> +votes, including default votes, are weighted inversely according to their a= +ge<br> +in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old wil= +l be<br> +recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day= + old<br> +and 6 months old UTXO are treated equivalently. The 1 year minimum is simpl= +y to<br> +make voting required no more than once per year. (of course, a real<br> +implementation should do all of these figures by block height, IE after 52,= +560<br> +blocks instead of after 1 year)<br> +<br> +A vote will consist of a txout with a scriptPubKey of the following form:<b= +r> +<br> +=A0 =A0 OP_RETURN magic vote_id txid vout vote scriptSig<br> +<br> +Where scriptSig is a valid signature for a transaction with nLockTime<br> +500,000,000-1 spending txid:vout to scriptPubKey:<br> +<br> +=A0 =A0 OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL<br> +<br> +vote_id is the ID of the specific vote being made, and magic is included to= +<br> +allow UTXO proof implementations a as yet unspecified way of identifying vo= +tes<br> +and including the weighted median as part of the UTXO tree sums. (it also<b= +r> +allows SPV clients to verify the vote if the UTXO set is a Patricia tree of= +<br> +scriptPubKeys) vote is just the numerical vote itself. The vote must comput= +e<br> +the median, rather than the mean, so as to not allow someone to skew the vo= +te<br> +by simply setting their value extremely high. Someone who still remembers t= +heir<br> +statistics classes should chime in on the right way to compute a median in = +a<br> +merkle-sum-tree.<br> +<br> +The slightly unusual construction of votes makes implementation by wallet<b= +r> +software as simple as possible within existing code-paths. Votes could stil= +l be<br> +constructed even in wallets lacking specific voting capability provided the= +<br> +wallet software does have the ability to set nLockTime.<br> +<br> +Of course in the future the voting mechanism can be used for additional vot= +es<br> +with an additional vote_id. For instance the Bitcoin community could vote t= +o<br> +increase the inflation subsidy, another example of a situation where the wi= +shes<br> +of miners may conflict with the wishes of the broader community.<br> +<br> +Users may of course actually create these specially encoded txouts themselv= +es<br> +and get them into the blockchain. =A0However doing so is not needed as a gi= +ven<br> +vote is only required to actually be in the chain by a miner wishing to<br> +increase the blocksize. Thus we should extend the P2P protocol with a mecha= +nism<br> +by which votes can be broadcast independently of transactions. To prevent D= +oS<br> +attacks only votes with known vote_id's will be accepted, and only for<= +br> +txid:vout's already in the blockchain, and a record of txouts for whom = +votes<br> +have already broadcast will be kept. (this record need not be authoritative= + as<br> +its purpose is only to prevent DoS attacks) Miners wishing to increase the<= +br> +blocksize can record these votes and include them in the blocks they mine a= +s<br> +required. To reduce the cost of including votes in blocks 5% of every block= +<br> +should be assigned to voting only. (this can be implemented by a soft-fork)= +<br> +<br> +For any given block actual limit in effect is then the rolling median of th= +e<br> +blocks in the last year. At the beginning of every year the value considere= +d to<br> +be the status quo resets to the mean of the limit at the beginning and end = +of<br> +the interval. =A0(again, by "year" we really mean 52,560 blocks) = +The rolling<br> +median and periodic reset process ensures that the limit changes gradually = +and<br> +is not influenced by temporary events such as hacks to large exchanges or<b= +r> +malicious wallet software. =A0The rolling median also ensures that for a mi= +ner<br> +the act of including a vote is never wasted due to the txout later being sp= +ent.<br> +<br> +Implementing the voting system can happen prior to an actual hard-fork allo= +wing<br> +for an increase and can be an important part of determining if the hard-for= +k is<br> +required at all.<br> +<br> +Coercion and vote buying is of course possible in this system. A miner coul= +d<br> +say that they will only accept transactions accompanied by a vote for a giv= +en<br> +limit. However in a decentralized system completely preventing vote buying = +is<br> +of course impossble, and the design of Bitcoin itself has a fundemental<br> +assumption that a majority of miners will behave in a specific kind of &quo= +t;honest"<br> +way.<br> +<br> +A voting process ensures that any increase to the blocksize genuinely<br> +represents the desires of the Bitcoin community, and the process described<= +br> +above ensures that any changes happen at a rate that gives all participants= +<br> +time to react. The process also gives a mechanism for the community to vote= + to<br> +decrease the limit if it turns out that the new one was in fact too high. (= +note<br> +how the way the status quo is set ensures the default action is for the lim= +it<br> +to gradually decrease even if everyone stops voting)<br> +<br> +As many of you know I have been quite vocal that the 1MB limit should stay.= + But<br> +I would be happy to support the outcome of a vote done properly, whatever t= +hat<br> +outcome may be.<br> +-----BEGIN PGP SIGNATURE-----<br> +Version: GnuPG v1.4.11 (GNU/Linux)<br> +<br> +iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH<br> +Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H<br> +gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS<br> +ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj<br> +gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6<br> +Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=3D<br> +=3DaKBD<br> +-----END PGP SIGNATURE-----<br></blockquote><div><br></div><div>-1<br><br><= +/div><div>Firstly I appreciate the ingenious thought that went into this po= +st.<br></div><div><br></div><div>However, Bitcoin's fundamental philoso= +phy was one CPU one vote.<br> +<br>Voting is easily gamed.=A0 While this may work in one particular case, = +it is perhaps a bad precedent to set.=A0 Establishing methods of voting can= + lead to single points of failure.<br><br></div><div>The asymmetry lies in = +psychological terms, in that new defaults tend to be adopted 80% of the tim= +e, so core devs have disproportionate amount of power as things stand.=A0 <= +br> +<br></div><div>Unless there's a very good reason not to, e.g. miners ar= +e clearly abusing the system, we should stick with 1 CPU one vote.<br></div= +><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= +x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> + +<br> +---------------------------------------------------------------------------= +---<br> +How ServiceNow helps IT people transform IT departments:<br> +1. A cloud service to automate IT design, transition and operations<br> +2. Dashboards that offer high-level views of enterprise services<br> +3. A single system of record for all IT processes<br> +<a href=3D"http://p.sf.net/sfu/servicenow-d2d-j" target=3D"_blank">http://p= +.sf.net/sfu/servicenow-d2d-j</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</blockquote></div><br></div></div> + +--001a1133d17afe3b8704dec85cd5-- + + |