Bitcoin Forum
March 29, 2024, 12:33:52 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Proposal: We should vote on the blocksize limit with proof-of-stake voting  (Read 6271 times)
jdillon (OP)
Member
**
Offline Offline

Activity: 70
Merit: 18


View Profile
June 10, 2013, 04:09:07 AM
Merited by ABCbits (1)
 #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-----
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711672432
Hero Member
*
Offline Offline

Posts: 1711672432

View Profile Personal Message (Offline)

Ignore
1711672432
Reply with quote  #2

1711672432
Report to moderator
1711672432
Hero Member
*
Offline Offline

Posts: 1711672432

View Profile Personal Message (Offline)

Ignore
1711672432
Reply with quote  #2

1711672432
Report to moderator
1711672432
Hero Member
*
Offline Offline

Posts: 1711672432

View Profile Personal Message (Offline)

Ignore
1711672432
Reply with quote  #2

1711672432
Report to moderator
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1147


View Profile
June 10, 2013, 06:29:36 AM
Merited by ABCbits (2)
 #2

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.

piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1344


aka tonikt


View Profile WWW
June 10, 2013, 08:36:20 AM
Last edit: June 10, 2013, 05:12:48 PM by piotr_n
Merited by ABCbits (2)
 #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
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 10, 2013, 08:42:40 AM
Last edit: June 11, 2013, 03:07:48 AM by cunicula
 #4

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.
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.  
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
June 10, 2013, 02:27:37 PM
 #5

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1147


View Profile
June 10, 2013, 03:47:40 PM
 #6

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

That's not true; you need 51% of the network to execute the veto because a majority can simply ignore blocks that don't use the full blocksize and thus trigger that rule. If this becomes a "us against the holdout miners destroying Bitcoin for the other miners" that's exactly what will happen.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
June 10, 2013, 03:54:44 PM
 #7

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

That's not true; you need 51% of the network to execute the veto because a majority can simply ignore blocks that don't use the full blocksize and thus trigger that rule. If this becomes a "us against the holdout miners destroying Bitcoin for the other miners" that's exactly what will happen.

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1147


View Profile
June 10, 2013, 03:56:29 PM
Last edit: June 10, 2013, 04:08:13 PM by retep
Merited by ABCbits (1)
 #8

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"

d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
June 10, 2013, 04:55:21 PM
 #9

Question: If votes are intended to be weighted by inverse age, how are the non-votes intended to be weighted, since you can't really say how long ago a non-vote was cast?
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1147


View Profile
June 10, 2013, 05:09:27 PM
 #10

Question: If votes are intended to be weighted by inverse age, how are the non-votes intended to be weighted, since you can't really say how long ago a non-vote was cast?

That one is really easy actually: a defacto vote is dated from when a given unspent output was created.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
June 10, 2013, 08:48:42 PM
 #11

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"

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1147


View Profile
June 10, 2013, 09:35:13 PM
 #12

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.

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)

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.

amincd
Hero Member
*****
Offline Offline

Activity: 772
Merit: 501


View Profile
June 11, 2013, 03:13:53 AM
 #13

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.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
June 11, 2013, 05:43:57 AM
 #14

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.

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
June 11, 2013, 06:12:17 AM
 #15

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...
piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1344


aka tonikt


View Profile WWW
June 11, 2013, 04:45:27 PM
Last edit: June 11, 2013, 05:00:34 PM by piotr_n
Merited by ABCbits (1)
 #16

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

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
jdillon (OP)
Member
**
Offline Offline

Activity: 70
Merit: 18


View Profile
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
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
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'.
jdillon (OP)
Member
**
Offline Offline

Activity: 70
Merit: 18


View Profile
June 15, 2013, 06:47:34 PM
 #19

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.

The thing is we already have one voting mechanism, mining. But that is a mechanism where the right to vote is dependent on your access to highly specialized hardware and in practice has been held in the hands of a very few in Bitcoin's history due to the natural incentives for miners to mine at large pools.

By adding proof-of-stake voting you counter-balance that vote with one where access is determined by a resource that all Bitcoin users have, Bitcoins themselves. Obviously we can't force miners to make larger blocks, but we can make it clear what maximum size we will accept, so the two voting processes go hand-in-hand.

As you say, it's a dispute resolution mechanism.
d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
June 15, 2013, 07:53:10 PM
Merited by ABCbits (1)
 #20

Frankly what are you guys worried about?
The collective wisdom of individual ignorance.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!