jdillon



Offline



Activity: 70

Merit: 10







MemberActivity: 70Merit: 10 Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 04:09:07 AM #1 (also posted to the -dev email list)



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

Peter Todd





Offline



Activity: 1106

Merit: 1049







LegendaryActivity: 1106Merit: 1049 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 06:29:36 AM #2



Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue.



The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted.



If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants.



Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote.



It's a solid proposal and a democratic way of making a very tough decision. My full reply: http://sourceforge.net/mailarchive/message.php?msg_id=31037850 Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue.The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted.If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants.Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote.It's a solid proposal and a democratic way of making a very tough decision. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 08:36:20 AM

Last edit: June 10, 2013, 05:12:48 PM by piotr_n #3 I like the idea. It would definitely be a step towards democracy, which IMHO is quite needed already.



I have some questions about the specifics of the implementations, though.



1. What is the purpose of setting nLockTime to 500,000,000-1?

Is it to prevent old miners (that do not know about voting txs) from mining such transactions?



2. Is it that older coins would have less voting power - or is it only older votes?

Either way I do not get the part when someone casts a vote, then moves the coins and then votes again using the new ones - repeating this over and over...

How do you do the vote accounting to prevent that?



3. Enough vote-type-txs that voted in favor must be mined into block-chain, in order to allow an increase in the block size (or some other change in the protocol) - correct?

But how are you going to decide about the definition of the majority? I mean, there will surely be coins that wont vote at all and we have no idea whether it will be 20, 50 or 80% of the existing coins. Do you also need to mine the votes that were against the change? If so: why would you want to do that?



4. As you have noticed yourself plenty of coins are kept at exchanges - and I do not know if it's better or worse to move the problem of centralization of voting power from mining pools to bitcoin banks, which will likely hold even more coins in the future, because of the increasing on-chain transactions costs.

I agree that how many bitcoins one holds seems to be a better approach to weighting the votes (from how much hashing power one can control), but I am afraid that it goes against the bitcoin's security design, so it might not work well enough. But maybe I just don't see the whole picture yet, so if you don't mind drawing it a bit further..

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.

PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

cunicula



Offline



Activity: 1064

Merit: 1003







LegendaryActivity: 1064Merit: 1003 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 08:42:40 AM

Last edit: June 11, 2013, 03:07:48 AM by cunicula #4



Sorry in advance if my approval turns people against the idea.



e.g.

Quote from: cunicula on December 07, 2012, 04:07:47 PM The only realistic way to get an acceptable solution to a problem like this is through voting. Probably coin-owners should suggest a fee. And the fee proposed by the median coin should be selected. They could also vote on a block size limit. As far as economics is concerned the two are equivalent. In the blockchain, you could probably instrument this by including votes in each txn and weighting them by output. Probably a vote to move the current fee up by 0.1% or down by 0.1% is sufficient. i.e. this is just one byte of extra info per txn. You could even encode it in a pre-existing piece of information, like include 5 satoshis in the fee to vote up, 6 satoshis in the fee to vote down, and anything else to abstain.

I've suggested this before (many times actually), so naturally I applaud your proposal. I hope you are more persuasive than I am.Sorry in advance if my approval turns people against the idea.e.g.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 02:27:37 PM #5 Quote from: retep on June 10, 2013, 06:29:36 AM



Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue.



The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted.



If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants.



Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote.



It's a solid proposal and a democratic way of making a very tough decision.

My full reply: http://sourceforge.net/mailarchive/message.php?msg_id=31037850 Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue.The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted.If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants.Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote.It's a solid proposal and a democratic way of making a very tough decision.

I think the trick is to make it easy to veto increases.



My proposal was this (to be run during difficulty changes) :



Code: if ( sum_last_2016_blocks > .95*current_block_size_limit*2016 ) {

limit_delta = current_block_size_limit >> 4

new_block_size_limit = current_block_size_limit + limit_delta

}



Note that there is no provision for limit decreases. All increases are permanent.



.95 and 4 are magic numbers. .95 needs to be very high, to allow an easy veto of the next increase. If miners want bigger blocks for some reason, they can certainly pad their blocks. This isn't a big deal, since roughly 6% of the network could execute the veto. Higher values of .95 mean less mining power is needed for the veto. Oh, nifty extra benefit, if the size increase is really warranted, those trying to veto will have to pay for it passing up fees. 4 is just a limit on the rate of growth. A bigger number may be wise here, since the opportunity for limit growth comes up so often.



I hate to say it, but it really looks like this is yet another place where reality intervenes to make POS systems unworkable. I think the trick is to make it easy to veto increases.My proposal was this (to be run during difficulty changes) :Note that there is no provision for limit decreases. All increases are permanent..95 and 4 are magic numbers. .95 needs to be very high, to allow an easy veto of the next increase. If miners want bigger blocks for some reason, they can certainly pad their blocks. This isn't a big deal, since roughly 6% of the network could execute the veto. Higher values of .95 mean less mining power is needed for the veto. Oh, nifty extra benefit, if the size increase is really warranted, those trying to veto will have to pay for it passing up fees. 4 is just a limit on the rate of growth. A bigger number may be wise here, since the opportunity for limit growth comes up so often.I hate to say it, but it really looks like this is yet another place where reality intervenes to make POS systems unworkable. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Peter Todd





Offline



Activity: 1106

Merit: 1049







LegendaryActivity: 1106Merit: 1049 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 03:56:29 PM

Last edit: June 10, 2013, 04:08:13 PM by retep #8 Quote from: kjj on June 10, 2013, 03:54:44 PM They could also reject votes. Or do far worse things. Bitcoin is based on the assumption that at least half of the network is honest. Most of it falls apart if that assumption is violated.



That's what's so clever about this proposal: they can't.



Miners can already make the max blocksize smaller by just mining smaller blocks, so the default vote is "the status quo". What they can't do is raise the limit without consent, because they have to prove that the community wants an increased limit by including their votes.



edit: The assumption in Bitcoin isn't that half the hashing power is honest, it's that no more than half of the hashing power is controlled by one entity, and that at least half the hashing power is economically rational. That's a much weaker assumption than the hashing power being "honest" That's what's so clever about this proposal: they can't.Miners can already make the max blocksize smaller by just mining smaller blocks, so the default vote is "the status quo". What they can't do is raise the limit without consent, because they have to prove that the community wants an increased limit by including their votes.edit: The assumption in Bitcoin isn't that half the hashing power is honest, it's that no more than half of the hashing power is controlled by one entity, and that at least half the hashing power is economically rational. That's aweaker assumption than the hashing power being "honest" BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 08:48:42 PM #11 Quote from: retep on June 10, 2013, 03:56:29 PM Quote from: kjj on June 10, 2013, 03:54:44 PM They could also reject votes. Or do far worse things. Bitcoin is based on the assumption that at least half of the network is honest. Most of it falls apart if that assumption is violated.



That's what's so clever about this proposal: they can't.



Miners can already make the max blocksize smaller by just mining smaller blocks, so the default vote is "the status quo". What they can't do is raise the limit without consent, because they have to prove that the community wants an increased limit by including their votes.



edit: The assumption in Bitcoin isn't that half the hashing power is honest, it's that no more than half of the hashing power is controlled by one entity, and that at least half the hashing power is economically rational. That's a much weaker assumption than the hashing power being "honest"

That's what's so clever about this proposal: they can't.Miners can already make the max blocksize smaller by just mining smaller blocks, so the default vote is "the status quo". What they can't do is raise the limit without consent, because they have to prove that the community wants an increased limit by including their votes.edit: The assumption in Bitcoin isn't that half the hashing power is honest, it's that no more than half of the hashing power is controlled by one entity, and that at least half the hashing power is economically rational. That's aweaker assumption than the hashing power being "honest"

Meh. I was using the loose definition of honest.



I get it that the no-vote position is to leave things alone, I'm just saying that a majority of miners can overrule the stakeholders in your system. If the stakeholders want an increase, but the miners don't, the miners can just ignore their votes. And if a majority of miners wants to ignore their votes, they can also ignore blocks from other miners that include them.



Any system that relies on the block chain will necessarily be vulnerable to the 51% problem.



And in this case, the incentives align in funny ways. It might be economically rational* to restrict blocks to a limit lower than the stakeholders would prefer, because one presumes that the stakeholders want a bigger block to reduce space competition.



I prefer that we make small increases when there exists overwhelming approval. I'm willing to accept that a majority of miners can give the appearance of overwhelming support because doing so is like deciding to go first in a nuclear war. No one is sure how it'll end, but we are all pretty sure that it won't be pretty.



* At least for low order effects. Money is a matter of trust. Meddling in the chain reduces that trust, to some extent. How much trust is lost if you meddle a little? How much if you meddle a lot? How big is the effect on the economic value of the bitcoin system overall (and thus, on each coin) per unit of trust lost? What the hell is a unit of trust? These relationships seem to be nonlinear, and mostly involve things that we can't measure. If we need people to estimate them accurately to be safe, we should perhaps have ourselves a little sit down thinking time. Meh. I was using the loose definition of honest.I get it that the no-vote position is to leave things alone, I'm just saying that a majority of miners can overrule the stakeholders in your system. If the stakeholders want an increase, but the miners don't, the miners can just ignore their votes. And if aof miners wants to ignore their votes, they can also ignore blocks from other miners that include them.Any system that relies on the block chain willbe vulnerable to the 51% problem.And in this case, the incentives align in funny ways. It might be economically rational* to restrict blocks to a limit lower than the stakeholders would prefer, because one presumes that the stakeholders want a bigger block to reduce space competition.I prefer that we make small increases when there exists overwhelming approval. I'm willing to accept that a majority of miners can give the appearance of overwhelming support because doing so is like deciding to go first in a nuclear war. No one is sure how it'll end, but we are all pretty sure that it won't be pretty. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Peter Todd





Offline



Activity: 1106

Merit: 1049







LegendaryActivity: 1106Merit: 1049 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 10, 2013, 09:35:13 PM #12 Quote from: kjj on June 10, 2013, 08:48:42 PM I get it that the no-vote position is to leave things alone, I'm just saying that a majority of miners can overrule the stakeholders in your system. If the stakeholders want an increase, but the miners don't, the miners can just ignore their votes. And if a majority of miners wants to ignore their votes, they can also ignore blocks from other miners that include them.



For the record, it's John Dillon's system. I had been thinking about the problem myself, and thinking about various commitment schemes, but he was the one that made the critical realization that vote withholding wasn't an issue in the first place because of the asymmetry involved.



In any case, of course the majority of miners can ignore a vote to increase the blocksize, what they can't do is ignore a vote to keep it steady or decrease it. That is quite unlike recent proposals to just remove the limit and let miners decide. You can always encourage miners to mine larger blocks by paying higher fees.



Quote from: kjj on June 10, 2013, 08:48:42 PM And in this case, the incentives align in funny ways. It might be economically rational* to restrict blocks to a limit lower than the stakeholders would prefer, because one presumes that the stakeholders want a bigger block to reduce space competition.



For sure, and those incentives work differently for different miners. Any large pool, or set of large pools with faster network connections between them, will have a much lower orphan rate for a given blocksize than a smaller pool simply because to get an orphan means someone else has to find a block before yours propagates, so more hashing power reduces that risk, and more hashing power makes it cheaper, relatively speaking, to afford to fast machines and fast network connections to speed up propagation and keep that rate down, while increasing the rate for your competitors and forcing them out of business. (remember that one way to get an orphan is when someone else generates a block, but you don't know about it yet, less of an issue now because you can just mine empty or near empty blocks and collect the large inflation subsidy, but that won't be true for much longer)



Quote from: kjj on June 10, 2013, 08:48:42 PM I prefer that we make small increases when there exists overwhelming approval. I'm willing to accept that a majority of miners can give the appearance of overwhelming support because doing so is like deciding to go first in a nuclear war. No one is sure how it'll end, but we are all pretty sure that it won't be pretty.



Yeah, at least proof-of-stake voting can give us a neutral and objective way of deciding if overwhelming approval actually exists in the community rather than just guessing. For the record, it's John Dillon's system. I had been thinking about the problem myself, and thinking about various commitment schemes, but he was the one that made the critical realization that vote withholding wasn't an issue in the first place because of the asymmetry involved.In any case, of course the majority of miners can ignore a vote to increase the blocksize, what they can't do is ignore a vote to keep it steady or decrease it. That is quite unlike recent proposals to just remove the limit and let miners decide. You can always encourage miners to mine larger blocks by paying higher fees.For sure, and those incentives work differently for different miners. Any large pool, or set of large pools with faster network connections between them, will have a much lower orphan rate for a given blocksize than a smaller pool simply because to get an orphan means someone else has to find a block before yours propagates, so more hashing power reduces that risk, and more hashing power makes it cheaper, relatively speaking, to afford to fast machines and fast network connections to speed up propagation and keep that rate down, while increasing the rate for your competitors and forcing them out of business. (remember that one way to get an orphan is when someone else generates a block, but you don't know about it yet, less of an issue now because you can just mine empty or near empty blocks and collect the large inflation subsidy, but that won't be true for much longer)Yeah, at least proof-of-stake voting can give us a neutral and objective way of deciding if overwhelming approval actually exists in the community rather than just guessing. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

amincd



Offline



Activity: 772

Merit: 500







Hero MemberActivity: 772Merit: 500 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 11, 2013, 03:13:53 AM #13 Quote from: jdillon on June 10, 2013, 04:09:07 AM A txout without a corresponding vote is considered to be a vote for the

status quo.



The status quo should be that the 1 MB block size limit is lifted, as that was the plan when it was first implemented, and there has been no consensus since then to change the plan.



Also, to count txouts without a vote as a vote for a particular choice is to give that choice a massive advantage, as it's a lot more difficult to create new type of transaction than a normal transaction. The status quo should be that the 1 MB block size limit is lifted, as that was the plan when it was first implemented, and there has been no consensus since then to change the plan.Also, to count txouts without a vote as a vote for a particular choice is to give that choice a massive advantage, as it's a lot more difficult to create new type of transaction than a normal transaction.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 11, 2013, 05:43:57 AM #14 Quote from: retep on June 10, 2013, 09:35:13 PM Quote from: kjj on June 10, 2013, 08:48:42 PM I prefer that we make small increases when there exists overwhelming approval. I'm willing to accept that a majority of miners can give the appearance of overwhelming support because doing so is like deciding to go first in a nuclear war. No one is sure how it'll end, but we are all pretty sure that it won't be pretty.



Yeah, at least proof-of-stake voting can give us a neutral and objective way of deciding if overwhelming approval actually exists in the community rather than just guessing.

Yeah, at least proof-of-stake voting can give us a neutral and objective way of deciding if overwhelming approval actually exists in the community rather than just guessing.

I guess I should have said "overwhelming approval by those actually doing the work". Quite frankly, I don't give a fuck what the Winkelvoss twins want, or what Gox wants, or any other entities with big wallets. The guys paying fees right now and the guys mining blocks right now are what really matter, in my view. Hashes and fees are consumed. Stake is not.



I guess our disagreement could come down to one side thinking that neutrality and objectivity can be found, while I'm old and cynical, and do not. I've seen at least a half dozen proposals involving various ways to calculate "stake" in the system. Some or all of them may be objective or neutral, but the choice of which one to use certainly is not.



If you include nonces or sequence identifiers in the votes, then you are biased against cold storage. If you do not include such a mechanism, then you've invented a ratchet that only swings in one direction (also not neutral). Unless I missed something in physics class, then any weighting system to be used will have been invented rather than discovered, which is to say that it will be subjectively chosen.



It goes on and on... Stake systems seem to have a lot of promise, but don't actually seem to deliver, as far as I can tell. I guess I should have said "overwhelming approval by those actually doing the work". Quite frankly, I don't give a fuck what the Winkelvoss twins want, or what Gox wants, or any other entities with big wallets. The guys paying feesand the guys mining blocksare what really matter, in my view. Hashes and fees are consumed. Stake is not.I guess our disagreement could come down to one side thinking that neutrality and objectivity can be found, while I'm old and cynical, and do not. I've seen at least a half dozen proposals involving various ways to calculate "stake" in the system. Some or all of them may be objective or neutral, but the choice of which one to use certainly is not.If you include nonces or sequence identifiers in the votes, then you are biased against cold storage. If you do not include such a mechanism, then you've invented a ratchet that only swings in one direction (also not neutral). Unless I missed something in physics class, then any weighting system to be used will have been invented rather than discovered, which is to say that it will be subjectively chosen.It goes on and on... Stake systems seem to have a lot of promise, but don't actually seem to deliver, as far as I can tell. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

edmundedgar



Offline



Activity: 352

Merit: 250





https://www.realitykeys.com







Sr. MemberActivity: 352Merit: 250https://www.realitykeys.com Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 11, 2013, 06:12:17 AM #15 Quote from: kjj on June 11, 2013, 05:43:57 AM I've seen at least a half dozen proposals involving various ways to calculate "stake" in the system. Some or all of them may be objective or neutral, but the choice of which one to use certainly is not.



If people think we should change the decision-making process to this, maybe they should start by getting a 51% vote by the method they propose, for the method they propose. I'm sure somebody can come up with a way to mark transactions as being in favour of this change without changing the protocol.



It shouldn't be very hard to get that 51%, since the people who will be most empowered by it will obviously want to support it. Unless it turns out that this is not in fact a serious proposal for making decisions, but instead a ludicrously transparent scheme to create a hurdle against any change, including one that has always been planned, by adding an extra step that has to be cleared in addition to the mining consensus, while counting the vast majority of people who aren't following the particular argument in question as "no" votes... If people think we should change the decision-making process to this, maybe they should start by getting a 51% vote by the method they propose, for the method they propose. I'm sure somebody can come up with a way to mark transactions as being in favour of this change without changing the protocol.It shouldn't be very hard to get that 51%, since the people who will be most empowered by it will obviously want to support it. Unless it turns out that this is not in fact a serious proposal for making decisions, but instead a ludicrously transparent scheme to create a hurdle against any change, including one that has always been planned, by adding an extra step that has to be cleared in addition to the mining consensus, while counting the vast majority of people who aren't following the particular argument in question as "no" votes...

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 11, 2013, 04:45:27 PM

Last edit: June 11, 2013, 05:00:34 PM by piotr_n #16 Quote from: kjj on June 11, 2013, 05:43:57 AM Quite frankly, I don't give a fuck what the Winkelvoss twins want, or what Gox wants, or any other entities with big wallets. Yeah, and I am with you here, so after all I do not quite support the idea of moving the power from he miners to the coin holders.



If you guys, whoever you are, but who are smart enough to make whitepapers that I can hardly read, want to do something really useful, I'd modestly suggest you moving the focus from empowering bitcoin banks to empowering individual miners, from behind the pools' interface.



Could you think of any voting system where a miner can vote individually, using his small 300Mh/s miner?

Something that would still allow him to cast a vote of his choice, yet without a need for him to give up his mining pool?

Why do we even want to involve mining pools into politics? I am sure none of them wants that - they are not like the elite of bitcoin

But anyway, it's the people who mine that should decide - just let them to do it, but without forcing mining pools to choose a camp (which can likely start a war of giants).

That should be doable. Yeah, and I am with you here, so after all I do not quite support the idea of moving the power from he miners to the coin holders.If you guys, whoever you are, but who are smart enough to make whitepapers that I can hardly read, want to do something really useful, I'd modestly suggest you moving the focus from empowering bitcoin banks to empowering individual miners, from behind the pools' interface.Could you think of any voting system where a miner can vote individually, using his small 300Mh/s miner?Something that would still allow him to cast a vote of his choice, yet without a need for him to give up his mining pool?Why do we even want to involve mining pools into politics? I am sure none of them wants that - they are not like the elite of bitcoinBut anyway, it's the people who mine that should decide - just let them to do it, but without forcing mining pools to choose a camp (which can likely start a war of giants).That should be doable. Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.

PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

jdillon



Offline



Activity: 70

Merit: 10







MemberActivity: 70Merit: 10 Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 15, 2013, 06:18:16 PM #17 Voting is a simple, automatic process. Your wallet would have a pop-up when you configure it asking what you want your vote to be and giving a bit of education on what the option actually means. After that the process can happen entirely automatically. Submitting a vote doesn't cost you anything in time or money and unlike leaving the decision 100% up to miners it ensures that entities like the Winklevoss twins with the connections required to get access to mining hardware on a level playing field, BTC to BTC, as you are. (Mike Hearn for example has said he expects for mining hardware to be highly regulated in the future)



Frankly what are you guys worried about? Losing? If Bitcoin users really want a large blocksize they'll vote, and it'll be easy to convince them to vote if they see fees going up and want fees to be lower. Voting is an excellent answer to those suggesting that politically powerful members of the community are pulling strings by taking the issue out of their hands entirely.



Gavin Andresen has said repeatedly that he doesn't want to be "the guy" setting the blocksize. Others, including myself, have said repeatedly we don't want the tiny set of large pool owners setting the blocksize. With voting both parties can be made happy.

mmeijeri



Offline



Activity: 714

Merit: 500



Martijn Meijering







Hero MemberActivity: 714Merit: 500Martijn Meijering Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting June 15, 2013, 06:28:30 PM #18 Voting has its own risks. After all, democracy is the original 51% attack, as Erik Voorhees puts it so nicely. Before you know it, we might have Bitcoin taxes. Still, it's possible some less drastic dispute resolution mechanism than forking Bitcoin or switching to a rival currency will emerge. It's certainly interesting to speculate about the possibilities. ROI is not a verb, the term you're looking for is 'to break even'.