Bitcoin Forum
May 22, 2024, 04:10:20 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Who should be in control of Bitcoin's maximum blocksize?
Developers - 14 (32.6%)
Miners - 10 (23.3%)
Code based algorithm - 19 (44.2%)
Total Voters: 43

Pages: « 1 2 [3]  All
  Print  
Author Topic: Who should be in control of Bitcoin's blocksize (poll)  (Read 1913 times)
hv_
Legendary
*
Offline Offline

Activity: 2506
Merit: 1055

Clean Code and Scale


View Profile WWW
April 11, 2017, 08:45:21 PM
 #41

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?



some 40 voters.... Thats all just noise

Carpe diem  -  understand the White Paper and mine honest.
Fix real world issues: Check out b-vote.com
The simple way is the genius way - Satoshi's Rules: humana veris _
d5000
Legendary
*
Offline Offline

Activity: 3920
Merit: 6348


Decentralization Maximalist


View Profile
April 11, 2017, 08:51:32 PM
 #42

Miners do not have veto power, they vote on protocol changes with their processing power in accordance with bitcoin white paper.

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.

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

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.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 501


View Profile
April 11, 2017, 09:11:10 PM
 #43

Miners do not have veto power, they vote on protocol changes with their processing power in accordance with bitcoin white paper.

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.

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

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.

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
misterbigg
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001



View Profile
April 11, 2017, 09:15:53 PM
 #44

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.
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 501


View Profile
April 11, 2017, 09:19:54 PM
 #45

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?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
ImHash
Hero Member
*****
Offline Offline

Activity: 924
Merit: 506


View Profile
April 11, 2017, 09:42:21 PM
 #46

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.
jonald_fyookball (OP)
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 11, 2017, 10:58:00 PM
 #47

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.



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!