Who should be in control of Bitcoin's blocksize (poll)

[Kprawn]

I do not want to give full control to a piece of code and neither a bunch of miners with "profits" as their main objective. The developers should

hold the steering wheel, but the car must still be able to drive on it's own. The developers is the safe guards when things goes wrong and some

times things does go wrong. The problem is "who" are these developers and how much power should they have 

[jonald_fyookball]

Nodes should be an option as we have the freedom to vote on various subjects, right? Now it's like OP wants you to choose from his offered options while there is more to choose, but the option is being kept away.

Reality turns out that at this point miners do have the majority of the power. In that regard it would make sense to vote for miners, but I stand behind the nodes option that isn't available.

Nodes are easily faked.  Satoshi never envisioned non-mining full nodes.

Nodes currently have no power in Bitcoin except relaying.

[DooMAD]

I do not want to give full control to a piece of code

Not to argue semantics, but technically, you already have.  You just happen to agree with the code.  The seemingly impossible task would be finding code allowing a flexible cap that enough users would find acceptable, whilst simultaneously acknowledging node resources and not pushing the cap high enough to jeopardise decentralisation.

Nodes currently have no power in Bitcoin except relaying.

I don't even know where to begin with that.  It's just all kinds of wrong.  Nodes form a vital part of the consensus mechanism, giving the average user a voice.  Miners alone should not be in a position to call the shots.

[jonald_fyookball]

I do not want to give full control to a piece of code

Not to argue semantics, but technically, you already have.  You just happen to agree with the code.  The seemingly impossible task would be finding code allowing a flexible cap that enough users would find acceptable, whilst simultaneously acknowledging node resources and not pushing the cap high enough to jeopardise decentralisation.

Nodes currently have no power in Bitcoin except relaying.

I don't even know where to begin with that.  It's just all kinds of wrong.  Nodes form a vital part of the consensus mechanism, giving the average user a voice.  Miners alone should not be in a position to call the shots.

Lets not derail the thread with this but we can talk about it another thread if you want.  maybe i'll learn something.

[XVS]

Well for now, I believe a good solution is to make the block size dynamic. If we can do that in a smart way, we wont have this block size issue ever again.

[andrew24p]

Devlopers hands down. Let the technical people do their job. Its okay to have an opinion, but people like Ver who are Pseudo economists and not even technical shouldnt be able to stir the pot as much as he has. Also the miners would never raise the block size because they get more money by mining 0 mb blocks and pushing up tx fees.

[Pettuh4]

It is better we maintain the developers as the devil you know is better than the Angel you don't know.

[BitHodler]

Nodes can be manipulated by buy/rent lots of cheap server, simply create fake nodes (Reference 1) or use other way that i don't know.
It could work if total nodes was as high as in May 2013 (Reference 2) even though it's not the best option.

Correct, but it could work in both ways. In the same way that the majority of the BU nodes are 'fake', same can be the case with Core nodes.

That being said, nodes can be set up in a way that you can choose what nodes are able to connect with you, and what not. From there you can basically exclude a large number of data center hosted nodes, and thus put a certain party off side.

It's a bit difficult to put this in practice as you need to have pretty much all node hosters to do the same thing, but in potential it could be a very effective measure.

[Xester]

It is better we maintain the developers as the devil you know is better than the Angel you don't know.

Let us promote the UASF so we the bitcoin holders can dictate as to what changes we can implement on bitcoin since it is our investment that is at risk in it. But I dont know when will it come to reality and thus at this moment I will be supporting the core developers since I have no choice due to the following reasons: 1. It is much safer than Hardfork, 2. Our exchange in our country only accepts bitcoin from the core developers..

[zahra4577]

whaddya think?

Honestly no one should control anything in any fully decentralized system.Even block size should not be under any entities contol but unfortunately that might not be possible.
In such a situation I would prefer miners to contol block size.

[Hydrogen]

Blocksize is an extremely overrated issue.

Doubling the blocksize at most will mean maximum theoretical transactions might increase from 7 to 14 transactions per second.

It won't make a difference. It won't solve issues with fees or unconfirmed transactions.

Its not worth it in terms of risk versus reward.

[ahu]

Blocksize is an extremely overrated issue.

Doubling the blocksize at most will mean maximum theoretical transactions might increase from 7 to 14 transactions per second.

It won't make a difference. It won't solve issues with fees or unconfirmed transactions.

Its not worth it in terms of risk versus reward.

Of course it will make a difference. Fees and the number of unconfirmed transactions correlate quite well with block space usage. But a conservative one-time increase of say doubling to 2MB is not enough. Segwit is not enough either.

We need a something like the 3rd option, but don't think Core would endorse anything like that on-chain. Choosing the algorithm for that shouldn't be done by the developers, they aren't the proper stake holders here. Developers shouldn't have any kind of decision power except by way of technical consulting.

[zimmah]

The developers have no reason to decide the blocksize. The miners should decide.

Or some algorithm maybe

[Mometaskers]

I do not want to give full control to a piece of code and neither a bunch of miners with "profits" as their main objective. The developers should

hold the steering wheel, but the car must still be able to drive on it's own. The developers is the safe guards when things goes wrong and some

times things does go wrong. The problem is "who" are these developers and how much power should they have 

I don't know how things actually work but I find my self agreeing to this. Miners would obviously benefit the most from the current situation because of the high transaction fees. As for devs, I don't think anyone would want things to be centralized.

[d5000]

In an utopic cryptocurrency where no sybil attack could occur, I would say "Nodes" (which your poll lacks).

But being realistic it's not that bad the way it is now. There is something like a balance of power, as already pointed out by DooMAD. The problem is that two of the three parties - economic power (nodes weighted by stake) and miners - have a veto power; if important nodes like exchanges don't choose miner's implementations miners will go bankrupt, and if miners don't like economic nodes' decisions, these in case of a hard fork risk to be on a "minority chain" which can be attacked by the miners (that's also why UASF should be done very careful). Developers have a "de facto" power because they have the highest reputation in the community, but they have no "formal" power granted by the Bitcoin algorithm because everyone can design a soft- or hard-forking version like BU.

As the veto power of miners and (economically important) nodes can lead to stalemates like now, if possible without hassle and blockchain bloat, for me the ideal would be a combined vote system where miners and users (economic majority) could vote changes like a new maximal block size, in a vote by majority. That would, however, mean that some form of Proof of Stake must been introduced, and to avoid blockchain bloat, maybe votes could be stored in a temporary sidechain o a kind of extension block.

[AngryDwarf]

In an utopic cryptocurrency where no sybil attack could occur, I would say "Nodes" (which your poll lacks).

But being realistic it's not that bad the way it is now. There is something like a balance of power, as already pointed out by DooMAD. The problem is that two of the three parties - economic power (nodes weighted by stake) and miners - have a veto power; if important nodes like exchanges don't choose miner's implementations miners will go bankrupt, and if miners don't like economic nodes' decisions, these in case of a hard fork risk to be on a "minority chain" which can be attacked by the miners (that's also why UASF should be done very careful). Developers have a "de facto" power because they have the highest reputation in the community, but they have no "formal" power granted by the Bitcoin algorithm because everyone can design a soft- or hard-forking version like BU.

As the veto power of miners and (economically important) nodes can lead to stalemates like now, if possible without hassle and blockchain bloat, for me the ideal would be a combined vote system where miners and users (economic majority) could vote changes like a new maximal block size, in a vote by majority. That would, however, mean that some form of Proof of Stake must been introduced, and to avoid blockchain bloat, maybe votes could be stored in a temporary sidechain o a kind of extension block.

Miners do not have veto power, they vote on protocol changes with their processing power in accordance with bitcoin white paper. It is up to the developers to propose and implement changes that the overwhelming majority of miners will accept. The fact that the developers have gone ahead for years spending money and time on a solution that the miners do not want does not give them credibility. If you want to vote with your node, throw some processing power at it. That is bitcoin. It is protocol, not software.

[n2004al]

As for me in control of bitcoin's blocksize should be the most "savant" bitcoin people. Nor the users or nor the miners. Probably the developers who know very well in which way operate bitcoin and blockchain or probably the system itself if the developers will be able to build a such specific feature within the system.

[hv_]

As for me in control of bitcoin's blocksize should be the most "savant" bitcoin people. Nor the users or nor the miners. Probably the developers who know very well in which way operate bitcoin and blockchain or probably the system itself if the developers will be able to build a such specific feature within the system.

Hmmm, and who would you like to be in charge to declare / vote who is savant enough to?

[jonald_fyookball]

13 to 9 to 19 right now, in favor of code-based-algorithm.

I'm quite pleased with the result. 

I think putting the blocksize out of the hands of humans is a smart move.
Did you know the flexcap already is coded and comes (by defaulted disabled)
with Bitcoin Classic?

[AngryDwarf]

13 to 9 to 19 right now, in favor of code-based-algorithm.

I'm quite pleased with the result. 

I think putting the blocksize out of the hands of humans is a smart move.
Did you know the flexcap already is coded and comes (by defaulted disabled)
with Bitcoin Classic?

Bitcoin Classic seems to full of good innovative features. I wonder if it might make a comeback. Could you link to flexcap please?