Bitcoin Forum
April 26, 2019, 05:08:27 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: What to do about the block size limit ?  (Voting closed: March 23, 2013, 02:48:59 PM)
Leave it at 1 MB - 48 (22.5%)
Increase it - 28 (13.1%)
Decrease it - 2 (0.9%)
Make it dynamic, recalculated every X blocks or Y time - 61 (28.6%)
I don't know, let the devs decide - 61 (28.6%)
Other option (describe below) - 13 (6.1%)
Total Voters: 213

Pages: [1] 2 3 4 »  All
  Print  
Author Topic: [POLL FINISHED] The block size limit controversy: a proper poll (30 days)  (Read 4586 times)
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


Bringing Legendary Har® to you since 1952


View Profile
February 21, 2013, 02:48:59 PM
Last edit: March 11, 2013, 01:30:53 PM by ShadowOfHarbringer
 #1

Because the previous poll sucked hard, i made a new, proper one.

Choose wisely, your future may depend on it.


PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1556298507
Hero Member
*
Offline Offline

Posts: 1556298507

View Profile Personal Message (Offline)

Ignore
1556298507
Reply with quote  #2

1556298507
Report to moderator
1556298507
Hero Member
*
Offline Offline

Posts: 1556298507

View Profile Personal Message (Offline)

Ignore
1556298507
Reply with quote  #2

1556298507
Report to moderator
1556298507
Hero Member
*
Offline Offline

Posts: 1556298507

View Profile Personal Message (Offline)

Ignore
1556298507
Reply with quote  #2

1556298507
Report to moderator
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


Bringing Legendary Har® to you since 1952


View Profile
February 21, 2013, 02:52:51 PM
Last edit: March 11, 2013, 01:29:19 PM by ShadowOfHarbringer
 #2

2012-03-11:
It seems that nobody is voting anymore, so it makes sense to lock the poll.
I hope everybody find the results satisfying, I for sure do.

Akka
Legendary
*
Offline Offline

Activity: 1204
Merit: 1001



View Profile
February 21, 2013, 03:00:17 PM
 #3

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.

All previous versions of currency will no longer be supported as of this update
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
February 21, 2013, 03:07:35 PM
 #4

what do you mean?  change it right now or eventually long term if it becomes clear we need to?
Jutarul
Donator
Legendary
*
Offline Offline

Activity: 994
Merit: 1000



View Profile
February 21, 2013, 03:12:44 PM
 #5

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.
Difficulty adjustment is to make hashing competitive. If you allow for bandwidth adjustment you make that competitive as well. All adjustment methods are exploitable. Do you want people to compete on bandwidth?

The ASICMINER Project https://bitcointalk.org/index.php?topic=99497.0
"The way you solve things is by making it politically profitable for the wrong people to do the right thing.", Milton Friedman
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


Bringing Legendary Har® to you since 1952


View Profile
February 21, 2013, 03:29:38 PM
 #6

Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.

+1

Timo Y
Legendary
*
Offline Offline

Activity: 938
Merit: 1001


bitcoin - the aerogel of money


View Profile
February 21, 2013, 03:42:44 PM
 #7

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both. 

It must not depend on number of transactions or size of transactions.

GPG ID: FA868D77   bitcoin-otc:forever-d
Jutarul
Donator
Legendary
*
Offline Offline

Activity: 994
Merit: 1000



View Profile
February 21, 2013, 03:53:28 PM
 #8

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both. 

It must not depend on number of transactions or size of transactions.
transaction fees paid and difficulty based is exploitable by large mining cartels. You don't want cartels right?

The ASICMINER Project https://bitcointalk.org/index.php?topic=99497.0
"The way you solve things is by making it politically profitable for the wrong people to do the right thing.", Milton Friedman
SimonL
Member
**
Offline Offline

Activity: 113
Merit: 10


View Profile
February 21, 2013, 04:01:35 PM
 #9

I've actually suggested (in two different threads already) a very rough metric that could be used in conjunction with difficulty to regulate the max block size based on how efficiently blocks propagate across the network. It is hardly the best metric, but I think the tying in with difficulty is feasible.

https://bitcointalk.org/index.php?topic=144895.msg1538386#msg1538386
mccorvic
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
February 21, 2013, 04:26:59 PM
 #10

It's a tough call for sure and it will be nigh impossible to really know if we've struck the right balance or not until it's to late.  It's very clear that we need to have more transactions per second possible than we have right now if we want BTC to become what we all want it to become.  The concerns about giving too much power to only those with infinite storage space/super computers are legitimate as well.

Offering Video/Audio Editing Services since 2011 - https://bitcointalk.org/index.php?topic=77932.0
Timo Y
Legendary
*
Offline Offline

Activity: 938
Merit: 1001


bitcoin - the aerogel of money


View Profile
February 21, 2013, 04:30:15 PM
Last edit: February 21, 2013, 05:36:05 PM by Timo Y
 #11

If it's dynamic, it must depend on total transaction fees paid, or difficulty, or both.  

It must not depend on number of transactions or size of transactions.
transaction fees paid and difficulty based is exploitable by large mining cartels. You don't want cartels right?

Ideally there should be something like a storage fee in addition to the transaction fee. The storage fee should not go to the miners.  Ideally, it should be paid out to people who donate bandwidth, CPU and hard disk space by running a full node.  However this might not be practicable since there is no simple, objective proof-of-propagation and proof-of-storage like there is proof-of-work.  Alternatively, the storage fee could be paid to the stakeholders according to proof-of-stake, which is objective. For this to work, the only important thing is that the fee doesn't go to the miners.

This would require major changes to the protocol, so it's not going to happen fast.  In the short and medium term, we need a stopgap solution.

GPG ID: FA868D77   bitcoin-otc:forever-d
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
February 21, 2013, 04:46:28 PM
Last edit: February 21, 2013, 06:07:22 PM by 2112
 #12

Please update the poll to include one more option:

x) redefine "block" to mean only header, Merkle tree & coninbase transaction. All normal transactions need to be propagated before the block in which they are included.

This proposal has been floating around at least since the Microsoft's "red balloons" paper. Currently "block" is pretty much an artefact of the weak architecture of the original implementation. The various "UTXO" proposals are in effect proposing the same change, just a different implementation of the transaction storage.

Thanks.

Edit1: Changed "fix" to "update". I forgot that in English "fix" could mean "conspire to preselect the winner".

Edit2: This "block size" discussion should really decouple the "bandwidth & time to verify" from the "storage size" discussion. They aren't really coupled, the coupling is just an artefact of implementation.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
mp420
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
February 21, 2013, 04:49:53 PM
 #13

I support misterbigg's idea of miner-voted limit changes, calculated at each difficulty adjustment, preferably with the options "decrease" and "disregard my vote" in addition to "increase" and "keep". I chose "other" since this is a specific proposal.

If this is somehow less feasible than other options, I need someone to explain me why it's so. Maybe 90% is too high a threshold though. With "decrease" option available, a simple majority might be sufficient. Although this would make the fork less smooth, or require an additional forking condition (90% for the first change and simple majority for the rest?)
Timo Y
Legendary
*
Offline Offline

Activity: 938
Merit: 1001


bitcoin - the aerogel of money


View Profile
February 21, 2013, 05:46:32 PM
 #14

I support misterbigg's idea of miner-voted limit changes [...]

Why miner-voted as opposed to stakeholder-voted?

GPG ID: FA868D77   bitcoin-otc:forever-d
misterbigg
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001



View Profile
February 21, 2013, 05:55:56 PM
 #15

Why miner-voted as opposed to stakeholder-voted?

Two reasons. First, it is very easy to modify Bitcoin to allow miners to vote (since they produce the blocks). Allowing stake holders to vote is much more difficult. Second, it is the miners that are the most affected by the change in the block size. Increasing the block size results in less transaction fees. It also makes mining less profitable for nodes with the least amount of bandwidth. Some miners will become unable to participate. That's why the miners should be the ones to vote.

Here is my proposal for adjusting the block size:

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.


If this was implemented, most likely the vote would be an automated function of bandwidth measurements performed by mining software. A miner would vote yes if their time to transfer a block is below some threshold.

Here's Nagato's explanation of how increasing the block limit also increases the minimum bandwidth requirements:

If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Here are my proposed guidelines for making block size adjustments:

Any change in maximum block size should
1) React to scarcity, to preserve fees
2) Not force out small miners

Here is my answer to Gavin's question about predicting the soft limit's future effects:

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.
mp420
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
February 21, 2013, 06:12:59 PM
 #16

I support misterbigg's idea of miner-voted limit changes [...]

Why miner-voted as opposed to stakeholder-voted?

Because "stakeholder-voted" is not technically or politically feasible. After all, what is included in a block is up to miners. Also, I think in the long term what's good for miners is good for the network, and good for anyone with Bitcoins.

When the hard limit starts to constrain Bitcoin's usefulness, this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.
misterbigg
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001



View Profile
February 21, 2013, 06:30:25 PM
 #17

When the hard limit starts to constrain Bitcoin's usefulness

The hard limit on block size is what gives Bitcoin its most important attribute: The blockchain with the largest amount of hashing power. Increasing the block size reduces total hashing power (because it drives fees down).

Quote
this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees. The only miners who benefit from an increase in the block size are the ones with the most bandwidth, since a limit increase will kill off the smallest competitors.
Piper67
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001



View Profile
February 21, 2013, 06:40:10 PM
 #18

When the hard limit starts to constrain Bitcoin's usefulness

The hard limit on block size is what gives Bitcoin its most important attribute: The blockchain with the largest amount of hashing power. Increasing the block size reduces total hashing power (because it drives fees down).

Quote
this will tend to cause a decrease in Bitcoin's value, and thus, a decrease in miners' real profit. So, eventually, miners are going to want to increase the limit.

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees. The only miners who benefit from an increase in the block size are the ones with the most bandwidth, since a limit increase will kill off the smallest competitors.


Yeah, well, it is also in miners' best interest to maintain the reward at 50. Or to keep the difficulty at 1000. But they can't have that, can they? Why? Because that's not how it works.

If the block size can adapt variably and in a self-regulating way, similar to how difficulty works, then it will just be part of how the business of bitcoin is done. It will also have a certain elegance and symmetry, which is very appealing.
Akka
Legendary
*
Offline Offline

Activity: 1204
Merit: 1001



View Profile
February 21, 2013, 06:40:18 PM
 #19

Wrong on all counts. Its in the miners' best interests to NOT raise the limit since the limit is what drives fees.

That's only true to a certain point. Every BTC User has a point where he isn't willing to pay even more fees to get a transaction processed. Once this point is reached it will be more providable to allow more transactions.

Also mining will at some point (very soon) become a zero sum game. As long as mining is profitable additional Hash power will be added until it equals out. The total amount of money made with each Block only specifies how much money will be spend to secure the network.

That's just how a free marked works.

All previous versions of currency will no longer be supported as of this update
acoindr
Legendary
*
Offline Offline

Activity: 1050
Merit: 1001


View Profile
February 21, 2013, 07:00:32 PM
 #20

Any polls should also be re-done at a later date since opinions can change. It can take time for people to digest information.
Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!