Proposal: Vote on the blocksize limit with proof-of-stake voting
15 messages, 10 to 28 Jun 2013. Started by John Dillon.
John Dillon (5), Melvin Carvalho (4), Peter Todd (2), Daniel Lidstrom, Pieter Wuille, Mark Friedenbach, Alan Reiner
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.
On Mon, Jun 10, 2013 at 4:44 AM, Edmund Broadley <rebroad@gmail•com> wrote:
Quoted text (4 lines)
> I really like this idea. I also like that users with no clue will leave > their vote to the default chosen by the software developers, which hopefully > will be 1MB. I like how coin age is factored in do votes are hopefully > proportional to bitcoin assert ownership.
The default should *not* be set by wallets at all in fact. The default is that by not voting, you accept the status quo, which is defined as the mean of the old and new limits in the past year.
So lets say the limit is 1MB, and through voting it ends up at 2MB in one year. Until that time by not voting you are in effect voting for the limit to be 1MB, but after the next interval you not voting is equivalent to voting for a 1.5MB limit. A subtle issue is then txout age, and at that point a 1.5 year old txout should be like voting for the 1MB limit still, albeit weighted less. What you don't want is your lack of vote to suddenly turn into a 1.5MB vote. This makes sure that at all levels the increases are gradual rather than abrupt, although the rate of increase may still be quite fast if the community votes that way. (first derivative of the limit is a close approximation to a continuous function)
On Mon, Jun 10, 2013 at 04:09:26AM +0000, John Dillon wrote:
My general comments on the idea are that while it's hard to say if a vote by proof-of-stake is really representative, it's likely the closest thing we'll ever get to a fair vote. Proof-of-stake is certainely better than just letting miners choose; as you point out miners can always choose to decrease the blocksize anyway so we only need a vote on allowable increases. Proof-of-stake also clearly favors those who actually have invested in Bitcoin over those who only talk about Bitcoin.
I'll also say that while I know people will complain about putting politics into a technical problem, as I keep saying, is *is* a political issue. The limitations may be technical, but the ultimate issue is a very political decision about what we want Bitcoin to be. Yes, there will be people campaigning left and right to get users to vote for various limits with their coins, deal with it. Democracy is messy.
Voting would take a lot of the nastier politics out of the situation, perhaps somewhat ironically. It would quite clearly take control away from the core development team, and the Bitcoin Foundation, and put it back in the hands of the community; you can't argue conspiracy theories that the Foundation is trying to control Bitcoin when there is a completely transparent voting system in place. People will complain that big Bitcoin players are throwing their weight around, but the blockchain itself is a voting mechanism that is anything but 1 person = 1 vote.
Of course I wouldn't be the slightest bit surprised if users happily vote themselves into something looking like a centralized PayPal replacement in the long run, but at least if that happens the process by which they get there will be transparent and relatively democratic.
Quoted text (8 lines)
> 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
I just wanted to point out how general this mechanism is. Regardless of what the scriptPubKey form is, standard, P2SH, multisig, whatever to vote is to simply prove you could have spent the txout.
Quoted text (5 lines)
> 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.
Ah, you're assuming a direct Patricia tree. Keep in mind that scriptPubKey's can be up to 10,000 bytes long, and an attacker can use that (with 10,000 other txouts) to create some extremely deep trees. I said on IRC a few days ago about how skeptical I am of implementing consensus critical systems with such huge differences in average and worst case, but I'll admit this is a decent use-case.
Having said that, proof to SPV clients leaves open the interesting possibility that a third-party holding Bitcoins on your behalf can prove that they voted according to your wishes, or even prove they voted according to all their users wishes. Basically we'd add a rule for the UTXO tree where a specific OP_RETURN form is included in the UTXO tree, even though it is unspendable, and is removed from the tree if the master txout is spent. Note that in this case by "prove they voted" we mean the service actually taking the step of ensuring their vote was recorded in the blockchain.
Quoted text (5 lines)
> 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.
I think the definition of the median requires knowledge of all the points so it'll have to be a separate sorted tree - kinda complex unfortunately if you really do want to be able to do full proof to SPV clients. Maybe just putting the hash of the overall results in the coinbase is enough for now.
The term to google is "moving median" - looks complex.
Quoted text (4 lines)
> 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.
Good idea on keeping the code general.
Quoted text (8 lines)
> 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.
Good points, although keep in mind you've created a lot of consensus critical code that is easiest to implement with floating point... not a good thing.
One way to mitigate that risk might be to take advantage of the fact that unless the rolling median code itself is buggy, a consensus failure in the calculation is likely to result in different implementations still having a close agreement on the limit. So maybe we write some code where we won't build on top of a block that is larger than, say, 95% of the hard-limit unless another miner does so too?
Quoted text (3 lines)
> 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.
Step #0 would be to think about OP_RETURN actually. FWIW Jeff Garzik has a pull-req (https://github.com/bitcoin/bitcoin/pull/2738) to enable it, although only one txout per tx, and only with a 80-byte payload.
Even just some ad-hoc voting by the "raise-the-limit" crowd would be a good first step to gaging interest.
Quoted text (4 lines)
> 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
Is it really? There might be someone clever with a cryptographic voting protocol, although in the case of Bitcoin we have to let people vote with arbitrary scriptPubKeys, so almost anything less general than full on SCIP just means miners force people to use the protocol where vote-buying is possible.
Quoted text (7 lines)
> 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)
Good idea. So it'd decrease to the mean of the old and new limits basically, and if Bitcoin becomes "too centralized" users can simply do nothing and the process gradually reverses.
Quoted text (3 lines)
> 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.
Same here.
Reserving my judgement until I've though about it more (design by committee scares me, and this voting sounds expensive), I think the SPV-verifiable moving median can be done by binning the space of block size limits, and for each node in the UTXO tree, a value for each bin is stored which is the sum of the corresponding bins of each of the children. The childless nodes - which correspond to the individual UTXOs - increment the appropriate bin of their parents according to the rules you mentioned. The bin values in the root node of the UTXO tree would then be added to those, weighted appropriately, of the previous N blocks.
The hash of a node would be that of the bin values, concatenated with the child nodes' hashes. In this way, any step of the calculation of the median would produce a localized error in the UTXO tree that's easily verified.
The number of bins would have to be kept relatively small in order to keep this from adding too much data to the UTXO tree branches though.
On Mon, Jun 10, 2013 at 2:30 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (196 lines)
> On Mon, Jun 10, 2013 at 04:09:26AM +0000, John Dillon wrote: > > My general comments on the idea are that while it's hard to say if a > vote by proof-of-stake is really representative, it's likely the closest > thing we'll ever get to a fair vote. Proof-of-stake is certainely better > than just letting miners choose; as you point out miners can always > choose to decrease the blocksize anyway so we only need a vote on > allowable increases. Proof-of-stake also clearly favors those who > actually have invested in Bitcoin over those who only talk about > Bitcoin. > > I'll also say that while I know people will complain about putting > politics into a technical problem, as I keep saying, is *is* a political > issue. The limitations may be technical, but the ultimate issue is a > very political decision about what we want Bitcoin to be. Yes, there > will be people campaigning left and right to get users to vote for > various limits with their coins, deal with it. Democracy is messy. > > Voting would take a lot of the nastier politics out of the situation, > perhaps somewhat ironically. It would quite clearly take control away > from the core development team, and the Bitcoin Foundation, and put it > back in the hands of the community; you can't argue conspiracy theories > that the Foundation is trying to control Bitcoin when there is a > completely transparent voting system in place. People will complain that > big Bitcoin players are throwing their weight around, but the blockchain > itself is a voting mechanism that is anything but 1 person = 1 vote. > > Of course I wouldn't be the slightest bit surprised if users happily > vote themselves into something looking like a centralized PayPal > replacement in the long run, but at least if that happens the process by > which they get there will be transparent and relatively democratic. > > > > 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 > > I just wanted to point out how general this mechanism is. Regardless of > what the scriptPubKey form is, standard, P2SH, multisig, whatever to > vote is to simply prove you could have spent the txout. > > > 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. > > Ah, you're assuming a direct Patricia tree. Keep in mind that > scriptPubKey's can be up to 10,000 bytes long, and an attacker can use > that (with 10,000 other txouts) to create some extremely deep trees. I > said on IRC a few days ago about how skeptical I am of implementing > consensus critical systems with such huge differences in average and > worst case, but I'll admit this is a decent use-case. > > Having said that, proof to SPV clients leaves open the interesting > possibility that a third-party holding Bitcoins on your behalf can prove > that they voted according to your wishes, or even prove they voted > according to all their users wishes. Basically we'd add a rule for the > UTXO tree where a specific OP_RETURN form is included in the UTXO tree, > even though it is unspendable, and is removed from the tree if the > master txout is spent. Note that in this case by "prove they voted" we > mean the service actually taking the step of ensuring their vote was > recorded in the blockchain. > > > 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. > > I think the definition of the median requires knowledge of all the points > so > it'll have to be a separate sorted tree - kinda complex unfortunately if > you really do want to be able to do full proof to SPV clients. Maybe > just putting the hash of the overall results in the coinbase is enough > for now. > > The term to google is "moving median" - looks complex. > > > 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. > > Good idea on keeping the code general. > > > 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. > > Good points, although keep in mind you've created a lot of consensus > critical code that is easiest to implement with floating point... not a > good thing. > > One way to mitigate that risk might be to take advantage of the fact > that unless the rolling median code itself is buggy, a consensus failure > in the calculation is likely to result in different implementations > still having a close agreement on the limit. So maybe we write some code > where we won't build on top of a block that is larger than, say, 95% of > the hard-limit unless another miner does so too? > > > 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. > > Step #0 would be to think about OP_RETURN actually. FWIW Jeff Garzik has > a pull-req (https://github.com/bitcoin/bitcoin/pull/2738) to enable it, > although only one txout per tx, and only with a 80-byte payload. > > Even just some ad-hoc voting by the "raise-the-limit" crowd would be a > good first step to gaging interest. > > > 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 > > Is it really? There might be someone clever with a cryptographic voting > protocol, although in the case of Bitcoin we have to let people vote > with arbitrary scriptPubKeys, so almost anything less general than full > on SCIP just means miners force people to use the protocol where > vote-buying is possible. > > > 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) > > Good idea. So it'd decrease to the mean of the old and new limits > basically, and if Bitcoin becomes "too centralized" users can simply do > nothing and the process gradually reverses. > > > 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. > > Same here. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000068a8ad033afa763246fe451e840eae5215eb3a64e8101a46c3 > > > ------------------------------------------------------------------------------ > 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 > >
On 10 June 2013 06:09, John Dillon <john.dillon892@googlemail•com> wrote:
Quoted text (162 lines)
> -----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.
Quoted text (13 lines)
> > > ------------------------------------------------------------------------------ > 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 >
On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho <melvincarvalho@gmail•com> wrote:
Quoted text (5 lines)
> -1 > > Firstly I appreciate the ingenious thought that went into this post. > > However, Bitcoin's fundamental philosophy was one CPU one vote.
Indeed it was. Which is why as GPU's came onto the scene Satoshi was strongly against them. I have to wonder what he thinks of ASICs where just a handful of companies control the supply of Bitcoin hashing power.
Satoshi also never forsaw pools, which are why just 2 or 3 people control the majority of Bitcoin hashing power.
Quoted text (3 lines)
> 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.
That's why I'm very clear that doing nothing is a vote for the status quo. Of course wallet authors can do what they want to try to get users to vote according to their wishes, or for that matter simply steal your vote, but we already must put a lot of faith into wallets to not steal our funds.
Quoted text (2 lines)
> 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.
People are proposing we put control of the blocksize entirely into the hands of miners, yet we all have an interest in auditing the blocks miners produce. There must be balance.
On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho <melvincarvalho@gmail•com> wrote:
Quoted text (1 line)
> However, Bitcoin's fundamental philosophy was one CPU one vote.
This is perhaps the largest misconception that keeps being repeated. Bitcoin is not a democracy; it is a zero-trust system. The rules are set in stone, and every full node verifies all rules and must independently come to the same result as everyone else. Obviously, if everyone changes their software, anything can change, but from within the system there is no way to change which blocks are considered valid, and there is certainly no voting mechanism about that.
What is voted about, is the one single thing that cannot be decided by each node individually: namely the order of otherwise valid and non-conflicting transactions, and that's just because it's a necessity. Because deciding the order includes delaying transaction potentially indefinitely, a majority of miners can indeed choose the enforce an additional rule about which transactions are considered valid, but the rules implemented in full nodes do not change without changing the software. For example, miners cannot decide to raise the block subsidy, even if every single miner out there would want that. They'd just end up being ignored by everyone else.
Quoted text (3 lines)
> 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 problem is that at some point, you have to look at the system from a higher level than just the technical part. And because ultimately the possibility exists where everyone changes their software, and there is an exceedingly high incentive for consensus (a deliberate hard-fork where two groups of users decide to use different and incompatible rules, aware of eachother, is suicide for the system, in my opinion). This results in the fact that proposed changes can indeed become new adopted hard rules in the system, and I don't think there's anything that can be done about it. Bitcoin is a consensus system - at the technical level - but also a consensus of the people using it, and ultimately they decide the rules.
Quoted text (2 lines)
> 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.
So you're saying that instead of a zero-trust system, we should move to a system where miners can decide _everything_ - as opposed to just being in charge of ordering transactions? I don't think you understand the system at all, if that is what you're proposing.
On 10 June 2013 10:26, John Dillon <john.dillon892@googlemail•com> wrote:
Quoted text (17 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho > <melvincarvalho@gmail•com> wrote: > > -1 > > > > Firstly I appreciate the ingenious thought that went into this post. > > > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > Indeed it was. Which is why as GPU's came onto the scene Satoshi was > strongly > against them. I have to wonder what he thinks of ASICs where just a > handful of > companies control the supply of Bitcoin hashing power. >
Thanks for your reply. Do you have a pointer to Satoshi being strongly against GPU? I'd be interested to see that. FWIW, I've read all his forum posts a few times, I just dont recall this one, tho I'm sure it's there...
Quoted text (37 lines)
> > Satoshi also never forsaw pools, which are why just 2 or 3 people control > the > majority of Bitcoin hashing power. > > > 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. > > That's why I'm very clear that doing nothing is a vote for the status quo. > Of > course wallet authors can do what they want to try to get users to vote > according to their wishes, or for that matter simply steal your vote, but > we > already must put a lot of faith into wallets to not steal our funds. > > > 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. > > People are proposing we put control of the blocksize entirely into the > hands of > miners, yet we all have an interest in auditing the blocks miners produce. > There must be balance. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3 > JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC > oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7 > RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i > p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+ > N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA= > =c8iU > -----END PGP SIGNATURE----- >
On 10 June 2013 10:35, Pieter Wuille <pieter.wuille@gmail•com> wrote:
Quoted text (41 lines)
> On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho > <melvincarvalho@gmail•com> wrote: > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > This is perhaps the largest misconception that keeps being repeated. > Bitcoin is not a democracy; it is a zero-trust system. The rules are > set in stone, and every full node verifies all rules and must > independently come to the same result as everyone else. Obviously, if > everyone changes their software, anything can change, but from within > the system there is no way to change which blocks are considered > valid, and there is certainly no voting mechanism about that. > > What is voted about, is the one single thing that cannot be decided by > each node individually: namely the order of otherwise valid and > non-conflicting transactions, and that's just because it's a > necessity. Because deciding the order includes delaying transaction > potentially indefinitely, a majority of miners can indeed choose the > enforce an additional rule about which transactions are considered > valid, but the rules implemented in full nodes do not change without > changing the software. For example, miners cannot decide to raise the > block subsidy, even if every single miner out there would want that. > They'd just end up being ignored by everyone else. > > > 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 problem is that at some point, you have to look at the system from > a higher level than just the technical part. And because ultimately > the possibility exists where everyone changes their software, and > there is an exceedingly high incentive for consensus (a deliberate > hard-fork where two groups of users decide to use different and > incompatible rules, aware of eachother, is suicide for the system, in > my opinion). This results in the fact that proposed changes can indeed > become new adopted hard rules in the system, and I don't think there's > anything that can be done about it. Bitcoin is a consensus system - at > the technical level - but also a consensus of the people using it, and > ultimately they decide the rules. >
OK I accept that the timestamping is one CPU one vote. However rule changes seem rather arbitrary.
Towit if you use a voting/consensus system and want to destroy bitcion it seems quite easy.
Iterate on picking a rule chance that will divide the consensus in such a way as to create ensuing chaos.
I think voting is too easy gamed for it it to be meaningful other than a straw poll.
If there's a bug, and everyone is unanimous that it's a bug, it can be fixed.
If there's a controversial rule change, we should be extremely cautious and not do it unless there's a very good reason. Keeping to satoshi's model as much as possible without introducing human factors, unnecessarily.
Quoted text (13 lines)
> > > > 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. > > So you're saying that instead of a zero-trust system, we should move > to a system where miners can decide _everything_ - as opposed to just > being in charge of ordering transactions? I don't think you understand > the system at all, if that is what you're proposing. > > -- > Pieter >
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:
Quoted text (3 lines)
> 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
Quoted text (1 line)
> force miners to increase the blocksize if they choose to decrease it,
because
Quoted text (2 lines)
> 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
Quoted text (1 line)
> force us to accept arbitrarily large blocks even if the will of the
majority of
Quoted text (6 lines)
> 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
Quoted text (1 line)
> a miner to prove that the majority will of the poeple is to accept a
larger
Quoted text (2 lines)
> 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
Quoted text (2 lines)
> 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
Quoted text (1 line)
> status quo. To allow the voting process to continue even if coins are
"lost"
Quoted text (1 line)
> votes, including default votes, are weighted inversely according to
their age
Quoted text (1 line)
> in years after 1 year. IE a vote with weight 1BTC that is 1.5 years
old will be
Quoted text (1 line)
> recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1
day old
Quoted text (1 line)
> and 6 months old UTXO are treated equivalently. The 1 year minimum is
simply to
Quoted text (2 lines)
> 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
Quoted text (12 lines)
> 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
Quoted text (1 line)
> allow UTXO proof implementations a as yet unspecified way of
identifying votes
Quoted text (2 lines)
> 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
Quoted text (1 line)
> scriptPubKeys) vote is just the numerical vote itself. The vote must
compute
Quoted text (1 line)
> the median, rather than the mean, so as to not allow someone to skew
the vote
Quoted text (1 line)
> by simply setting their value extremely high. Someone who still
remembers their
Quoted text (1 line)
> statistics classes should chime in on the right way to compute a
median in a
Quoted text (4 lines)
> 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
Quoted text (1 line)
> constructed even in wallets lacking specific voting capability
provided the
Quoted text (3 lines)
> wallet software does have the ability to set nLockTime. > > Of course in the future the voting mechanism can be used for
additional votes
Quoted text (1 line)
> with an additional vote_id. For instance the Bitcoin community could
vote to
Quoted text (1 line)
> increase the inflation subsidy, another example of a situation where
the wishes
Quoted text (3 lines)
> of miners may conflict with the wishes of the broader community. > > Users may of course actually create these specially encoded txouts
themselves
Quoted text (1 line)
> and get them into the blockchain. However doing so is not needed as a
given
Quoted text (2 lines)
> 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
Quoted text (1 line)
> by which votes can be broadcast independently of transactions. To
prevent DoS
Quoted text (2 lines)
> 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
Quoted text (1 line)
> have already broadcast will be kept. (this record need not be
authoritative as
Quoted text (2 lines)
> 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
Quoted text (1 line)
> required. To reduce the cost of including votes in blocks 5% of every
block
Quoted text (1 line)
> should be assigned to voting only. (this can be implemented by a
soft-fork)
Quoted text (2 lines)
> > For any given block actual limit in effect is then the rolling median
of the
Quoted text (1 line)
> blocks in the last year. At the beginning of every year the value
considered to
Quoted text (1 line)
> be the status quo resets to the mean of the limit at the beginning and
end of
Quoted text (2 lines)
> 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
Quoted text (2 lines)
> 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
Quoted text (1 line)
> the act of including a vote is never wasted due to the txout later
being spent.
Quoted text (2 lines)
> > Implementing the voting system can happen prior to an actual hard-fork
allowing
Quoted text (1 line)
> for an increase and can be an important part of determining if the
hard-fork is
Quoted text (3 lines)
> required at all. > > Coercion and vote buying is of course possible in this system. A miner
could
Quoted text (1 line)
> say that they will only accept transactions accompanied by a vote for
a given
Quoted text (1 line)
> limit. However in a decentralized system completely preventing vote
buying is
Quoted text (2 lines)
> 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"
Quoted text (5 lines)
> 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
Quoted text (1 line)
> time to react. The process also gives a mechanism for the community to
vote to
Quoted text (1 line)
> decrease the limit if it turns out that the new one was in fact too
high. (note
Quoted text (1 line)
> how the way the status quo is set ensures the default action is for
the limit
Quoted text (3 lines)
> 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
Quoted text (1 line)
> I would be happy to support the outcome of a vote done properly,
whatever that
Quoted text (3 lines)
> outcome may be. > >
------------------------------------------------------------------------------
Quoted text (11 lines)
> 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 > . >
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:
Quoted text (203 lines)
> > 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 > > . > > > > > >
------------------------------------------------------------------------------
Quoted text (11 lines)
> 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
On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote:
Quoted text (8 lines)
> 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.
Solving that problem is pretty easy actually: just add a voting only public key to your outputs. Specifically you would have an opcode called something like "OP_VOTE" and put a code-path in your script that only executes for that specific key.
It'd work best if we implement merklized abstract syntax trees to allow you to reveal only the part of a script that is actually executed rather than the whole script, a feature useful for a lot of other things.
Incidentally remember that we can implement as many new opcodes as we want with a soft-fork by redefining one of the OP_NOP's to be a OP_VERSION opcode that returns false for a given version:
version OP_VERSION OP_IFNOT {new opcodes} OP_ENDIF
Nodes with the existing codebase will think the script always succeeds, because the IFNOT branch isn't taken, leaving the non-false version on the stack, while new nodes will take that branch.
On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (14 lines)
> On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote: >> 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. > > Solving that problem is pretty easy actually: just add a voting only > public key to your outputs. Specifically you would have an opcode called > something like "OP_VOTE" and put a code-path in your script that only > executes for that specific key.
Rather than "OP_VOTE" all you really need is the "spending tx matches a template" functionality that has been proposed for many other things.
On 10 June 2013 06:09, John Dillon <john.dillon892@googlemail•com> wrote:
Quoted text (151 lines)
> -----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.
Quoted text (24 lines)
> -----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 >
Quoted text (11 lines)
> 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.
I disagree entirely. Your example of "straw polls" for bug fixes and features is precisely what the current method of rough consensus and running code, an IETF expression, handles just fine.
What the method does not handle effectively are issues that are fundementally political rather than technical in nature. Blocksize is precisely the latter because while the tradeoffs are technical in nature the fundemental issue at hand is what do we want Bitcoin to be? Who are we going to allow to participate?