public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: John Dillon <john.dillon892@googlemail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
Date: Sat, 22 Jun 2013 14:05:41 +0200	[thread overview]
Message-ID: <CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com> (raw)
In-Reply-To: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 8246 bytes --]

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.
>

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
>

[-- Attachment #2: Type: text/html, Size: 9325 bytes --]

  parent reply	other threads:[~2013-06-22 12:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10  4:09 [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting John Dillon
     [not found] ` <CAFBxzACPpLd1gmoAzxviU2rLPry=cGNQhEZvYV=q_PLRQQ5wXw@mail.gmail.com>
2013-06-10  4:59   ` John Dillon
2013-06-10  5:30 ` Peter Todd
2013-06-10  6:34   ` Daniel Lidstrom
2013-06-10  8:14 ` Melvin Carvalho
2013-06-10  8:26   ` John Dillon
2013-06-10  8:39     ` Melvin Carvalho
2013-06-10  8:35   ` Pieter Wuille
2013-06-10 12:30     ` Melvin Carvalho
2013-06-10 16:46 ` Mark Friedenbach
2013-06-10 17:25   ` Alan Reiner
2013-06-10 17:43     ` Peter Todd
2013-06-15 18:28       ` John Dillon
2013-06-22 12:05 ` Melvin Carvalho [this message]
2013-06-28 10:25   ` John Dillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com \
    --to=melvincarvalho@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=john.dillon892@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox