diff options
| author | Alan Reiner <etotheipi@gmail.com> | 2013-06-10 13:25:05 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-10 17:25:15 +0000 |
| commit | e40d7e29b7eadcf57b5e5e5309eb03d98d3cf51f (patch) | |
| tree | b3e24cdbc6d4c626c237c65f2e219059945e9113 | |
| parent | ff4612ecca54fd1ee496c53aa608e7dcfa95ddca (diff) | |
| download | pi-bitcoindev-e40d7e29b7eadcf57b5e5e5309eb03d98d3cf51f.tar.gz pi-bitcoindev-e40d7e29b7eadcf57b5e5e5309eb03d98d3cf51f.zip | |
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
| -rw-r--r-- | 7a/d2b7f9728e27b8c2859f7c6f12ecba53d8e95f | 594 |
1 files changed, 594 insertions, 0 deletions
diff --git a/7a/d2b7f9728e27b8c2859f7c6f12ecba53d8e95f b/7a/d2b7f9728e27b8c2859f7c6f12ecba53d8e95f new file mode 100644 index 000000000..984c6e85b --- /dev/null +++ b/7a/d2b7f9728e27b8c2859f7c6f12ecba53d8e95f @@ -0,0 +1,594 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <etotheipi@gmail.com>) id 1Um5qF-0004Vv-Aw + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Jun 2013 17:25:15 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.172 as permitted sender) + client-ip=209.85.216.172; envelope-from=etotheipi@gmail.com; + helo=mail-qc0-f172.google.com; +Received: from mail-qc0-f172.google.com ([209.85.216.172]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Um5qD-0006ND-MT + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Jun 2013 17:25:15 +0000 +Received: by mail-qc0-f172.google.com with SMTP id j10so3859074qcx.3 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 10 Jun 2013 10:25:08 -0700 (PDT) +X-Received: by 10.49.0.244 with SMTP id 20mr12022393qeh.50.1370885108162; + Mon, 10 Jun 2013 10:25:08 -0700 (PDT) +Received: from [192.168.1.52] (c-76-111-96-126.hsd1.md.comcast.net. + [76.111.96.126]) by mx.google.com with ESMTPSA id + c10sm14999392qao.10.2013.06.10.10.25.07 + for <bitcoin-development@lists.sourceforge.net> + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Mon, 10 Jun 2013 10:25:07 -0700 (PDT) +Message-ID: <51B60BF1.3020701@gmail.com> +Date: Mon, 10 Jun 2013 13:25:05 -0400 +From: Alan Reiner <etotheipi@gmail.com> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:17.0) Gecko/20130510 Thunderbird/17.0.6 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com> + <51B602D8.5030706@monetize.io> +In-Reply-To: <51B602D8.5030706@monetize.io> +X-Enigmail-Version: 1.5.1 +Content-Type: multipart/alternative; + boundary="------------030609060502040605000400" +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 + (etotheipi[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: 1Um5qD-0006ND-MT +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 17:25:15 -0000 + +This is a multi-part message in MIME format. +--------------030609060502040605000400 +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + +One major problem I see with this, no matter how well-thought-out it is, +it's unlikely that those with money will participate. Those with the +most stake, likely have their private keys behind super-secure +accessibility barriers, and are not likely to go through the effort just +to sign votes. Not only that, but it would require them to reveal their +public key, which while isn't technically so terrible, large amounts of +money intended to be kept in storage for 10+ years will prefer to avoid +any exposure at all, in the oft-chance that QCs come around a lot +earlier than we expected. Sure, the actual risk should be pretty much +non-existent, but some of the most paranoid folks are probably the same +ones who have a lot of funds and want 100.00% of the security that is +possible. They will see this as wildly inconvenient. + +I think this a great thought experiment, and I'd like to see where this +idea goes, in terms of designing ways for a decentralized community to +find consensus for important decisions, but I don't think that any idea +that requires users to dig up their private keys is going to be feasible +(or possibly reconstruct them from pieces and/or get multiple +signatures). Especially if the system requires some kind of persistent +voting. + +-Alan + + +On 06/10/2013 12:46 PM, Mark Friedenbach wrote: +> +> John, +> +> What you are recommending is a drastic change that the conservative +> bitcoin developers probably wouldn't get behind (but let's see). +> However proof-of-stake voting on protocol soft-forks has vast +> implications even beyond the block size limit. Within Freicoin, we +> have looked at is as a possibility for determining how to distribute +> the demurrage, a proposal we are calling 'Republicoin' due to the fact +> that with proxy voting we expect a system to emerge similar to the +> government budgeting in parliamentary republics. Distributed, +> non-coersive government by protocol, if you will. +> +> So anyway, even if you get shot down, please continue to pursue this +> proposal. It very likely has uses that you haven't thought of yet. +> +> Cheers, +> Mark +> +> On 6/9/13 9:09 PM, John Dillon wrote: +> > 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. +> +> > +> ------------------------------------------------------------------------------ +> > 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 +> > . +> +> +> +> +> +> +------------------------------------------------------------------------------ +> This SF.net email is sponsored by Windows: +> +> Build for Windows Store. +> +> http://p.sf.net/sfu/windows-dev2dev +> +> +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development + + + +--------------030609060502040605000400 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + +<html> + <head> + <meta content="text/html; charset=ISO-8859-1" + http-equiv="Content-Type"> + </head> + <body bgcolor="#FFFFFF" text="#000000"> + One major problem I see with this, no matter how well-thought-out it + is, it's unlikely that those with money will participate. Those + with the most stake, likely have their private keys behind + super-secure accessibility barriers, and are not likely to go + through the effort just to sign votes. Not only that, but it would + require them to reveal their public key, which while isn't + technically so terrible, large amounts of money intended to be kept + in storage for 10+ years will prefer to avoid any exposure at all, + in the oft-chance that QCs come around a lot earlier than we + expected. Sure, the actual risk should be pretty much non-existent, + but some of the most paranoid folks are probably the same ones who + have a lot of funds and want 100.00% of the security that is + possible. They will see this as wildly inconvenient.<br> + <br> + I think this a great thought experiment, and I'd like to see where + this idea goes, in terms of designing ways for a decentralized + community to find consensus for important decisions, but I don't + think that any idea that requires users to dig up their private keys + is going to be feasible (or possibly reconstruct them from pieces + and/or get multiple signatures). Especially if the system requires + some kind of persistent voting.<br> + <br> + -Alan<br> + <br> + <br> + On 06/10/2013 12:46 PM, Mark Friedenbach wrote:<br> + <span style="white-space: pre;">></span><br> + <blockquote type="cite">John,<br> + <br> + What you are recommending is a drastic change that the + conservative bitcoin developers probably wouldn't get behind (but + let's see). However proof-of-stake voting on protocol soft-forks + has vast implications even beyond the block size limit. Within + Freicoin, we have looked at is as a possibility for determining + how to distribute the demurrage, a proposal we are calling + 'Republicoin' due to the fact that with proxy voting we expect a + system to emerge similar to the government budgeting in + parliamentary republics. Distributed, non-coersive government by + protocol, if you will.<br> + <br> + So anyway, even if you get shot down, please continue to pursue + this proposal. It very likely has uses that you haven't thought of + yet.<br> + <br> + Cheers,<br> + Mark<br> + <br> + On 6/9/13 9:09 PM, John Dillon wrote:<br> + > It has been suggested that we leave the decision of what the + blocksize to be<br> + > entirely up to miners. However this leaves a parameter that + affects every<br> + > Bitcoin participant in the control of a small minority. Of + course we can not<br> + > force miners to increase the blocksize if they choose to + decrease it, because<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 majority 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 age<br> + > in years after 1 year. IE a vote with weight 1BTC that is 1.5 + years old will 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 simply 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:<br> + <br> + > 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> + > 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 votes<br> + > and including the weighted median as part of the UTXO tree + sums. (it also<br> + > 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 compute<br> + > the median, rather than the mean, so as to not allow someone + to skew the vote<br> + > by simply setting their value extremely high. Someone who + still remembers their<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<br> + > software as simple as possible within existing code-paths. + Votes could still 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 votes<br> + > with an additional vote_id. For instance the Bitcoin + community could vote to<br> + > increase the inflation subsidy, another example of a + situation where the wishes<br> + > of miners may conflict with the wishes of the broader + community.<br> + <br> + > Users may of course actually create these specially encoded + txouts themselves<br> + > and get them into the blockchain. However doing so is not + needed as a given<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 mechanism<br> + > by which votes can be broadcast independently of + transactions. To prevent DoS<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 as<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 the<br> + > blocks in the last year. At the beginning of every year the + value considered to<br> + > be the status quo resets to the mean of the limit at the + beginning and end of<br> + > the interval. (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<br> + > malicious wallet software. The rolling median also ensures + that for a miner<br> + > the act of including a vote is never wasted due to the txout + later being spent.<br> + <br> + > Implementing the voting system can happen prior to an actual + hard-fork allowing<br> + > for an increase and can be an important part of determining + if the hard-fork is<br> + > required at all.<br> + <br> + > Coercion and vote buying is of course possible in this + system. A miner could<br> + > say that they will only accept transactions accompanied by a + vote for a given<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 "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 limit<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 that<br> + > outcome may be.<br> + <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 class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a><br> + > _______________________________________________<br> + > Bitcoin-development mailing list<br> + > <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br> + > + <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br> + > .<br> + <br> + <br> + </blockquote> + <span style="white-space: pre;">><br> + ><br> + ><br> + > +------------------------------------------------------------------------------<br> + > This SF.net email is sponsored by Windows:<br> + ><br> + > Build for Windows Store.<br> + ><br> + > <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sfu/windows-dev2dev</a><br> + ><br> + ><br> + > _______________________________________________<br> + > Bitcoin-development mailing list<br> + > <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br> + > + <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><br> + <br> + <br> + </body> +</html> + +--------------030609060502040605000400-- + + |