Bitcoin Forum

whaddya think?

If the creator of bitcoin was planning to make it up to the miners to decide then It should stay that way, giving control to developers will do nothing but make things more centralized, not to mention that I don't know how could you consider someone a "developer"? simply because he contributed to the code once?

I think miners and the community...

I wish there was a way for bitcoin users to vote without having to have hashpower. Because not a lot of bitcoin users actually are able to get hashing power on their devices, but if the miners were the only ones that can vote, it would mean that we are leaving out the majority of bitcoin users.

Definitely not the developers though, because that would mean that bitcoin becomes centralised.

nodes=boss
pools=secretary
devs=workers
(listing in rank of importance)

imagine there was 2 pools and the node rule was 1mb
pool A with 500000000 exahash making a 1.000,250 block
and pool B with 4exahash making 0.999,750 block

pool A would lose, all that happens is that the orphan/reject stats would be higher for every block they tried

NODES have to have consensus and accept 1.000,250 block.
and even then thats just to try to keep the over 1mb going because the nodes are just in a orphan drama event.

---

imagine there was 2 dev teams
team A offering a proposal of 1mb rule with 5 developers
team B offering a proposal of 2mb rule with 50000 developers
team C offering a proposal of 2mb rule with 5 developers
team D offering a proposal of 1mb rule with 50000 developers

no one downloads their proposal because they didnt advertise well, or people just wanted to stick to what they had already..

---

imagine there was 2 dev teams
team A offering a proposal of 1mb rule with 5users
team B offering a proposal of 2mb rule with 20user

team A would lose, all that happens is that the orphan/reject stats would be higher cause when the 5 users connect to the network of 25 users. they see there are blocks being made at a higher height. but the 5 users reject the block after download as its not under1mb.. leaving team A rejecting blocks and being left unsynced at a lower height they cant grow from

---

NODES have to have consensus and accept 1.000,250 block.
and even then thats just to try to keep the over 1mb going because the nodes are just in a orphan drama event.

---

the only way to make sure that 1.000,250 blocks are acceptable without drama without fuss and with the pools making the blocks able to spend their rewards, is to have node consensus of majority, merchant/services node acceptance and

if the minority want to grow their lower rule. the minority need to completely ignore the majority to not care about the new rules. and only get blocks/communicate with a pool that is only making old rules

Clearly the OP is trying to get everyone to vote for "miners" and then claim that miners support a larger blocksize, when this is not the case.  Bitmain supposedly supports a larger blocksize, for example, but that doesn't mean that the majority of miners actually do.  Many miners couldn't care less and are just in Antpool, for example, because they just wanted to join a big pool.

I think the group of person that should have control of the bitcoins blocksize are the bitcoin holders and exchanges. Since we are the ones buying bitcoins and places a huge capital on bitcoins then the miners should consider us as their clients or customers. In any business customer is always right and so the bitcoin holders through the UASF should organize all these things and make it possible.

I voted miners, but could have easily voted code based algorithm. But that really depends on what the code based algorithm is.

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.

AI !

 ;D

Your dumb ass poll ignores reality. Nobody can control the block size after the coin has launched and gained significant vested interests. How many years will it take before you finally realize the fact highlighted in yellow below.

The only choice in your poll that makes sense is your 3rd option, if you mean hardcoded into the protocol on launch of the coin.

Its too late to change Bitcoin. You can never do it. Read the yellow below and weep.

I think creators should be allowed to control bitcoin more than anyone, because thanks to them, bitcoin is created, bitcoin is like their child, and they have the right to raise and manage it. However, standing on the stance of society, we are all not allowed to control bitcoin, because at present it is the common property of all. It exists for the benefit of the community, it is allowed to exist independently and not dependent on anyone, the developer is only the one who gives the most benefit to the bitcoin.

Come on guys - we all know that it's Soros and the Rothschilds who control everything to do with money. :)

The problem with voting "Developers" is that miners can (and do) develop their own code.
The problem with voting "Code based algorithm" is that miners get to choose the algorithm.

Adding the choice "Nodes" would make the poll more interesting.

Also, it is easy to say that <insert entity here> should control some aspect of Bitcoin, but it is irrelevant unless it can be shown that <insert entity here> could control that aspect of Bitcoin. Saying that "the community" should decide is meaningless.

when first created bitcoin certainly has had its own calculations. I think the current blocksize is the determination that was created at first bitcoin created.

The technology should change according to the time. The evolution of currency was not easy to anyone. But it was necessary through the time. Similarly I feel that the current block size will not be holding off for more years so it needs to be widen. Developers or an algorithm would be a better option to do that.

Why did you change your avatar? We liked that dude with a fyooked look.

I voted for autocode. I think it would solve the problems we're having right now. But i am against a hardfork too. Bitcoin Corp. should solve the problem by itself. BU's creator is not capable of leading this tech.

if miners could develop their own code why they didn't until now and forked with greater hash their own chain? they know that merchants would not be in agreement

and miners don't have many choice when come to algorithm, they are forced to choose sha256 or all their asic will be useless

The premise is flawed, no one group should be able to drown out the others.  There should be an equilibrium between all parties involved.  Developers are wasting their time without nodes, miners and other users.  Miners are wasting their time and money if there are no users to bring utility to the coin.  Users rely on the security provided by the miners.  There's no coin at all without developers.  All parties are important and need to move forward together.  Although I'd still like to see an algorithmic element involved, provided everyone can agree on what form it should take.

Nodes have spoken:

https://i.redd.it/0j5c3wjy47ny.png

Market also has spoken as it goes higher when segwit gets higher.

Core devs got the best talent in the field.

Activate segwit or you are wasting people's time (and money).

This is a difficult question, I think ideally the developers should be in position to decide on the blocksize but  it is possible for them to be pushing for another selfish agenda. I think what is dragging this blocksize debate is that the miners don't understand how this is going to benefit them going forward knowing fully well the LN is going to cut their transaction fee

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

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

Nodes currently have no power in Bitcoin except relaying.

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.



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.

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.

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.

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

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.

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

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.

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.

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

Or some algorithm maybe

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.

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.

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?

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?

some 40 voters.... Thats all just noise

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.

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.

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.

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