From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UqMZk-0001bZ-UW for bitcoin-development@lists.sourceforge.net; Sat, 22 Jun 2013 12:05:53 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f47.google.com; Received: from mail-la0-f47.google.com ([209.85.215.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UqMZg-0001Zx-HN for bitcoin-development@lists.sourceforge.net; Sat, 22 Jun 2013 12:05:52 +0000 Received: by mail-la0-f47.google.com with SMTP id fe20so8500434lab.34 for ; Sat, 22 Jun 2013 05:05:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.43.52 with SMTP id t20mr7736802lal.62.1371902741771; Sat, 22 Jun 2013 05:05:41 -0700 (PDT) Received: by 10.112.19.226 with HTTP; Sat, 22 Jun 2013 05:05:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 14:05:41 +0200 Message-ID: From: Melvin Carvalho To: John Dillon Content-Type: multipart/alternative; boundary=001a11c242fe96fe7504dfbcff84 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: 1UqMZg-0001Zx-HN Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 12:05:53 -0000 --001a11c242fe96fe7504dfbcff84 Content-Type: text/plain; charset=ISO-8859-1 On 10 June 2013 06:09, John Dillon 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. > Thinking about this a little more, I guess it does not hurt to build some kind of voting system into the clients. But I think it's more useful for straw polls. For example a bug fix 100% of people should agree on. A protocol optimization perhaps 80% would agree on. A protocol change that redistributes wealth or incentives perhaps only 60% will agree on. At this point in time it's far too easy to deliver contentious changes into the hands of the general population. I think that fortunately we're blessed with a very strong dev team, but the fundamental philosophy of bitcoin is to not put too much trust in single point, but rather, to distribute and diversify trust to the edges. > -----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----- > > > ------------------------------------------------------------------------------ > 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 > --001a11c242fe96fe7504dfbcff84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 June 2013 06:09, John Dillon <john.dillon892@goo= glemail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It has been suggested that we leave the decision of what the blocksize to b= e
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 no= t
force miners to increase the blocksize if they choose to decrease it, becau= se
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
force us to accept arbitrarily large blocks even if the will of the majorit= y 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<= br> 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 a= ge
in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old wil= l 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 simpl= y 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:
=A0 =A0 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:

=A0 =A0 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 vo= tes
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 comput= e
the median, rather than the mean, so as to not allow someone to skew the vo= te
by simply setting their value extremely high. Someone who still remembers t= heir
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 stil= l 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 vot= es
with an additional vote_id. For instance the Bitcoin community could vote t= o
increase the inflation subsidy, another example of a situation where the wi= shes
of miners may conflict with the wishes of the broader community.

Users may of course actually create these specially encoded txouts themselv= es
and get them into the blockchain. =A0However doing so is not needed as a gi= ven
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 mecha= nism
by which votes can be broadcast independently of transactions. To prevent D= oS
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
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<= br> blocksize can record these votes and include them in the blocks they mine a= s
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 th= e
blocks in the last year. At the beginning of every year the value considere= d to
be the status quo resets to the mean of the limit at the beginning and end = of
the interval. =A0(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. =A0The rolling median also ensures that for a mi= ner
the act of including a vote is never wasted due to the txout later being sp= ent.

Implementing the voting system can happen prior to an actual hard-fork allo= wing
for an increase and can be an important part of determining if the hard-for= k is
required at all.

Coercion and vote buying is of course possible in this system. A miner coul= d
say that they will only accept transactions accompanied by a vote for a giv= en
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 &quo= t;honest"
way.

A voting process ensures that any increase to the blocksize genuinely
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=
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 lim= it
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 t= hat
outcome may be.

Thinking about this a l= ittle more, I guess it does not hurt to build some kind of voting system in= to the clients.=A0 But I think it's more useful for straw polls.=A0 For= example a bug fix 100% of people should agree on.=A0 A protocol optimizati= on perhaps 80% would agree on.=A0 A protocol change that redistributes weal= th or incentives perhaps only 60% will agree on.=A0

At this point in time it's far too easy to deliver conte= ntious changes into the hands of the general population.=A0 I think that fo= rtunately we're blessed with a very strong dev team, but the fundamenta= l philosophy of bitcoin is to not put too much trust in single point, but r= ather, to distribute and diversify trust to the edges.=A0

=A0
-----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=3D
=3DaKBD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------------= ---
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c242fe96fe7504dfbcff84--