Topic: Who should be in control of Bitcoin's blocksize (poll) (Read 1959 times)

The whole system is flawed, when you want bitcoin you start mining it by running a full node validating and including transactions at the same time.
But ASIC came to play and people started to mine with 100 (CPUs[mining machines]) pointing them all to one full node, one flaw right there.
If miners were given the freedom to mine empty blocks/ ignoring transactions at will then who the hell were supposed to validates the transactions? it was designed for allowing people to spam, and for fees to increase higher and higher, another flaw.

Why didn't Satoshi make the block size dynamic from the start? as transaction numbers grow block size grow dynamically and since miners could mine empty blocks that means a block with 2MB size shouldn't take the time of 2 blocks with 1MB size or computational power.

So how has bitcoin become unsecure during its time at running at 1 MB for months? Can you provide an example of this collapse of security?

The obvious answer is that the blocksize should be as large as possible while preserving the security requirements of the system. Currently, that is below 1MB as Luke-Jr correctly pointed out.

I don't think I can disagree with that. Miners not voting for segwit are in-fact a default veto position (even if they are not voting for any other proposal). The UASF is indeed an "overrule" to that veto, but certainly should not be done in a careless fashion. Since this is quite a significant protocol change, and is heavily linked with the future direction of the bitcoin protocol (the balance of off-chain versus on-chain solutions economics), I expect this could prove to be a very contentious and pivotal moment if it is followed through. Otherwise we will just plod along with the status quo.

So you don't think what large miners groups are doing with Segwit actually is a kind of veto power? There is the option of an UASF to "overrule" that veto, but it's not a trivial thing, because if miners stay stubborn this would provoke a contentious hard fork.


That's in line with what I wrote actually. Developer groups (be they called "Core" or others) have only the power to influence miners and economic nodes to use their implementation, no formal power granted by Bitcoin's protocol.

The point is that if you don't want a power equilibrium of this kind (devs-miners-economic nodes) then you shouldn't use proof of work for your coin. In Proof of Stake, for example, the power structure is simpler, as validators and economically important nodes are the same people. That can make the development of the currency software more straight-forward, but even there could be stalemates if the largest stakeholders become too powerful and have the intention to conserve status quo.

some 40 voters.... Thats all just noise

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

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?

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

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.

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.

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.

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.

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

Or some algorithm maybe

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.

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.

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.

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

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.