Topic: Proposal: We should vote on the blocksize limit with proof-of-stake voting (Read 6325 times)

Ah a man after my own heart. I couldn't agree more.

You should check out the thread on netcoin which is an ambitious plan to implement some of these principles. I'm pretty sure this is going to be an iterative process (e.g.. think of ppcoin as the first several iterations).

Proof-of-stake voting is a superb idea.

Its potential is much wider than resolving the specific blocksize limit question. However, I don't believe it is right for Bitcoin. Bitcoin can't adopt major changes easily, if at all.

An altcoin supporting proof-of-stake voting could allow continuous voting on the block reward(inflation rate), transaction fee, awarding bounties, hashing algorithm parameters, etc.

The Bitcoin model has been to have a genius choose all these parameters correctly 5 years ago. That's worked well, but it is inflexible. A proof-of-stake voting model would trust the owners of a currency to modify the parameters as the currency and environment evolved. I trust the owners of a currency to vote in a way that strengthens the currency they own. Owner's interests are perfectly aligned with the long-term success of a currency. I'd like to see an altcoin where the owners decide monetary policy through proof-of-stake voting.

Yeah, gmaxwell's comments yesterday were extremely helpful. 
But it's not the first time I saw him talking bullshit, so I'm used to this.

@jdillon, you want to use self-moderated threads so nobody could tell you again that your idea is stupid?
way to go, man - that's how smart people solve problems

I need to get better at not touching that "show/hide" option... But on IRC yesterday most of the developers put piotr_n on ignore for being an idiot who wouldn't listen to people showing why his idea was stupid and wasting everyones' time instead: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/28#l7875194 gmaxwell has the patience of a saint. (or a C++ developer on a slow machine)

Remind me to use the self-moderated threads option more often.


EDIT: I'll also point out how this "one-line-change" DoS attack was something that at least one of the Bitcoin developers knew about but didn't even realize it was an issue: http://sourceforge.net/mailarchive/message.php?msg_id=31074593 Hopefully the other developers were just keeping their mouth shut and immediately understood how serious that issue was, but obviously it took a bit of insight on Peter's part to realize that the problem existed.

Heck, here's a Bitcoin for your efforts. Thank you!


-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQEMA8xUMVQPvvGFAQf/frPPA2CHPDlMz9R28K05T3/wVmGhQ54v803OH8+SImg+
RQ8dGqh5H8Tgar8cuKE8jhikr5bg6NBf369F4h1L4Ir1lnplY2wDJj4tRr97Ea8b
4ADm91Fr0CWT03pa9XIp4LsgIC1oc3l2PUXxCQ/icVUnZk0jhSyp4ZnR0MYsRGqi
GuoVGHP765Xai7I56nLIO4E6LFqnvj5zIGgKYjc4o9ujmOs73gph5eGWEdna3rOG
GKkHrajshLviRgKGa99uG2RxtFltE8BcFkW1D7xweV8TLLH6jAGhIG2XrPol+bLc
RoQQZr3zR1w0ORdXL6GkIerxw4MNBI5hKRm4w93WRIUBDAO4Pc5vOCVNqAEIALeU
FJZZ8BUtgiQ4mMIUrEFXOD5h1BqqIsavUosOR3mVJNWtlnHuasYGn2LvFqJw1SzC
7uB1bGk7xyVNAOGECFDu6r5T9Diur6pr+CSxbRjh19dqNi+noKiD3V1z6yk6USf/
rqlfm13k7Tat6T4b1Kp/4JC8ofarL3ogyCzF3MXFbdnCBuqndklqDakb66iQv4SE
BI7rwWwwtaeI83uUBTQpJkH0wL1boHfjKtpuh4jOETOQ8zKJxWOFm4BJl6TzHmYf
/hnm5Wc7JIsV1GMqQYwNreJ+6RRBpPV5mayomzF9n01yOwV/rKY7bDBAS0LU5LEV
DcSuqJ6FRbihiFibS0HSwN8BhY0LpbmFCGH9NrHYHQW7WQ8tZVbMGvVSEoOwUdEZ
JUV7Uj3nLIGnmZ9vfePcu7zxCwUbrMk3eX1huaBbeCwdv/zkHQtzMTTySOAhbgxx
LcCZuUTUXDdO8oFCJD/3PUlBJgxniVkSGcsbMUo2ev+Lr541iWGmd+J6FlZvgwsz
bE0PkOtIyttYvMBHfqUJ9DN7xLLKu/gJnzcs0UrLauXrbFvV3NsBL6LcuZ62zp4n
Sj+iy+9LOnr2tOjv7uVyujut4moCHteFcD7VIBjr0Lxuzxf/scdPSe73Y9Rgs4yX
n8e+RjgOV6k4hjMKeyQRSutHuUHKY0OTtdEW7dbfnUpFR+n8dDqnS0uueMrCNakM
b0xxdHEZSticRzuv7mY8FVJ2AIMFaIlrGInorYbUBtqiAnkcfCD+LI0Vqz7fX8RP
8s7EK584hzzKvFgIYUQ5h4sNgo19ryvnNoeEJh73z3Bho5e6+nVdyW0M8U8hreio
xFHANgf+s46k2vmj9cVl1sH8tW5NOxTfQa+POmRAnIunLCfR9IDJUWCfiJBeYXJI
=6qYH
-----END PGP MESSAGE-----

That's exactly what I am talking about.

A guy who fixed a bug in the official bitcoin client, by adding one line of code: a hero who saved the network from an extremely dangerous DoS attack.

A guy who dared to suggest that we should extend the net protocol to be able to prevent similar attacks in a future: a troll /ignore

You guys are just pathetic.

Thansk! Waiting however long you feel is required is fine by me.

Ah, that's who you are. Yeah /ignore


jdillon: I'll do a write-up in a week or so if you are interested, but waiting a bit longer isn't a bad idea; the network as a whole is safe right now but there are still a lot of non-upgraded nodes out there.

What? He saved the network? That's the best joke I've heard for days..

First of all, the DoS attack was not on the network, but on a buggy official client, which I don't even use myself, so I couldn't care less.
Moreover, yesterday on IRC I even proposed a simple improvement that would solve this kind of problems once and for all (fetching data length, along with the hash), but nobody did care about it, including the guy, who among others was extremely impolite to me, so I have just adopted myself to his standards.

Now you get it?

The guy who last week saved the Bitcoin network from an extremely serious DoS attack that could have easily taken down a large fraction of the network  goes to the trouble of writing an intelligent and detailed response and you obviously don't even read it? Then you go off on conspiracy crap? Troll.

/ignore


Peter: write up what exactly you did there, I'd love to hear the full story. I didn't realize you had written that patch as the main network was being attacked! I guess it would have had the effect of inoculating the whole network because the truncated messages would propagate faster than the non-truncated ones, clever!

So what?
Rich people, or exchange owners, can also easily "peer with each other".
That's not an argument - I'm all for people peering witch each other.

But I'm still waiting for the answer to my question: what is your business in promoting bitcoin banks to rule the protocol?

The design of Bitcoin only requires a majority of miners to be economically rational for Bitcoin to work correctly; good or evil has nothing to do with it. It's easy to see how if a majority of miners think that it is economically advantageous for them to mine large blocks they have every reason to do so and every reason to do "evil" things like block votes against a blocksize increase. (after all, they're just "protecting" Bitcoin from those who want to "hold it back")



Unfortunately you are quite wrong there. Pools can easily peer with each other with dedicated connections on fast servers to ensure that blocks propagate quickly to other pools and we can expect more of this in the future; the incentives to produce small blocks due to propagation delays and orphans are greatly diminished by peering because your block will reliably get to the majority of hashing power fast, the "little-guys" with the most decentralized hashing power be damned.

FWIW the real reason why pools have mostly switched to a 250KB limit seems to be just a change in the block creation code that makes the 250KB default limit a hard limit, rather than the previous behavior where the hard limit was 500KB and it took transactions with increasingly higher fees to fill up that space. If anything it just shows how little pool operators care about transaction fees right now in favor of the still very high inflation subsidy.

Interestingly the recent DoS attack against Bitcoin - caused by how Bitcoin was allowing messages up to 32MiB in size with no anti-DoS limits - gave me a unique opportunity to observe the speed at which extremely large messages propagated across the network, not unlike extremely large blocks. While successive waves of the attack hit my Amazon EC2 hosted nodes very quickly - seconds - due to their high bandwidth it took multiple minutes for those same messages to even begin to appear at less well connected nodes, such as at my apartment, and especially any node connected via Tor. It would have been nice to actually run some experiments, but unfortunately I was too busy trying to stop the attack and the patch that I wrote which fixed the issue had the useful side-effect of "innoculating" even unpatched nodes to the attack. Oh well.

One more comment, on lifting the max block size, which I myself was bitching about.
Today I am tending to say that I was wrong - it won't matter.
I see it now that most miming pools keep the limit at 250KB and even if you remove the hardcoded 1MB from the client, they will still keep their soft limits at whatever level they want - and it will be rather lower than higher.
Anyone who decides to mine bigger blocks is betting against himself, because bigger blocks need more time to propagate over the net, thus naturally having a bigger chance to get orphaned. Measure a difference between propagating 250KB vs 25MB block and you will not think twice of which one your mining pool prefers.

This is a brilliantly designed "ecosystem" that is regulating itself - therefore, seeing it at work, I am against any additional regulations.

Sorry, I wasn't talking to you.
It was more of a general comment, because I see it all the time (in other threads, but also outside the forum) that people are complaining about, or just using a term: "evil miners".
There is no such thing!

IMHO, miners are the least who would want this currency to not succeed. And people trying to overthrow the designed "bitcoin government", because they believe they found a more fair solution for the democracy, or whatever - it's just silly, not to use again the wold "stupid". They either don't understand what they are talking about (meaning: they don't know shit about how bitcoin works) - or they are expecting a miracle... I don't see a third option.

Miners are the government of this currency: like it or not, it is the fact and you cannot do anything about it. If they decide to increase or decrease a block size, or whatever else, they can just do it and no developer, nor any other self proclaimed genius, will be able to stop them - face it! If bitcoin users didn't follow any miners' decision - as I said: that would be their suicide.

Moreover "evil" is a religious term, so please if you are people of science, stop using it and start thinking in terms of what is technically possible, instead of what you think you should do in order to go to heaven.

Bitcoin is hopeless if majority of miners are evil. I don't think this will happen. I am just responding to jdillon's accusation:

I'm honestly tired reading all these silly accusations about how miners are evil and how we should resist against them.
It's just so stupid that I cannot even quantify the level of its stupidity.

First of all, miners are not evil - they are the power of the network by design and they should do their job, part of which being: decision making about the protocol.
And second, even if you wanted to, you cannot resist their power, because they are the power of the network by design.

You don't like the miners' ruling the bitcoin - invent your own virtual currency, one that has it designed otherwise.
In the virtual currency invented by Satoshi in 2009, miners are supposed to rule and so they do rule - you can't change it, it's impossible.
And if you don't like this idea, then obviously you have not yet found a digital currency that is suitable enough for you.

Myself, I am going to stick to the miners' ruled currency, because I do find this idea as a proper way to go.

As you assume that miners are evil enough to reject votes they don't like, certainly they are willing to do so.



This doesn't help at all. Evil miners will require people send the votes to them directly, or publish them on a public forum.

One of the more interesting aspects of John Dillon's proposal is that it could give many of those large Bitcoin holders a reason to move their coins so that the txouts will be fresher than 1 year old and can participate in the vote fully; seeing some really early coins vote would be fascinating.

It's almost certain that Satoshi is the richest Bitcoin holder, as well as other early adopters.  By definition these "rich" people are likely to be quite insightful and ideologically pure: they recognized Bitcoin's value and persevered when no one else was interested and the product was going through difficult times.  Personally, I'd trust him and other early adopters to make wiser decisions than any persons (or hashing power) showing up since this year's media explosion.

Rejecting transactions that are not accompanied by votes would be logisticly difficult. When you send a transaction generally only one of the outputs will be owned by you, often none of the outputs at all, so unless miners are willing to make it impossible for you to send funds to someone who is off-line or simply does not wish to vote they will be unable to coerce votes in that way. We can and should further strengthen this protection by having all nodes only relay votes for outputs of confirmed transactions, never unconfirmed ones.

I don't know how you're defining "random" here. Satoshi wrote that he expected blocks with 3,000 transactions/second in them if Bitcoin became successful, even before he released the first client.

When he instated the 1 MB limit, it was unambiguously created as a temporary measure. When Satoshi was active on the forum, there was discussion on options for replacing it, with a clear implication in all of the participants' comments, including Satoshi's, that the 1 MB cap would eventually be removed if the volume of transaction data approached 1 MB:

https://bitcointalksearch.org/topic/patch-increase-block-size-limit-1347
 

That's somewhat better, given the status quo will be described as 'the 1MB limit will be lifted eventually when there is consensus around a viable replacement'.


That's true. The flip side is that this voting method requires support in all major clients to be useful.

Also with regard to this voting concept in general, whether it treats normal transactions as votes or not, it gives e-wallet operators more power over the votes of those who entrust their bitcoins with them than mining pools have now over the votes of those who point their hashes to them.


That's not referring to voting on a protocol change. That's in reference to a protocol change that allows miners to continuously vote on a dynamic block size limit. There's a big difference between miners voting once to change the protocol, and a protocol change that allows miners to actively control the block size limit through regular voting.

All of the protocol changes so far have been voted on through the mining method, so there doesn't appear to be much opposition to this method.