Bitcoin Forum

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.

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.

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?

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

Why miner-voted as opposed to stakeholder-voted?

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.

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

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.

Why miner-voted as opposed to stakeholder-voted?

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.

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


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.

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

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?

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.

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.

Where is the option: /24 ban the two mofos (or one and his socky buddies) that keep posting these stupid useless threads about a non issue.

Can "No limit" be added?  Thanks.

In time, the block size may need to change. But there's absolutely no rush.

Let the block size stay at the current size until the limit is hit; then let us run with that for a while. Let us see how easy or hard people find it to work within the limit; let us see what effect it has on transaction fees and confirmation times.

Eventually, a strong consensus might form around an appropriate change. Then, only then, is it worth working out how to implement the change. Equally, we may find that some other solution arises which negates the need for any hard change.

No it cannot.

Without the limit, Bitcoin network can't function.

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

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.

There has been no proof of this.

1. After the last Bitcoin will be minted, there will be no incentive for miners to mine, except for transaction fees. When block can be of any size, then any number of transactions can make it into every block, therefore theoretically no transaction fees need to be paid.

2. How do you protect the network from dust spam & DDoS without block size limit ?

Your theory is wrong. Miners have no obligation to include free transactions

Correct, however if any number of transactions can and should theoretically make it into the block, won't the miners conspire and create their own limits anyway in order to save their profits ?

So won't theoretical "no limit" result in practical "miners decide what the limit is" ?

There has been no proof of this. A possible system is one where the client limits the download speed for any particular block, but not the actual block size. If there is a tie between two blocks, the smaller one wins. Miners will not intentionally create small blocks because there is no income when the subsidy falls, and they will not intentionally create large blocks because they waste their own bandwidth and the block will never get in.

So far, nobody has refuted this system.

1. After the last Bitcoin will be minted, there will be no incentive for miners to mine, except for transaction fees. When block can be of any size, then any number of transactions can make it into every block, therefore theoretically no transaction fees need to be paid.

2. How do you protect the network from dust spam & DDoS without block size limit ?

Neither of these is a problem if large blocks are orphaned by small ones. It makes mining more of a skill, as they must make the largest block that is not too large such that other miners will receive it fast enough.

Neither of these is a problem if large blocks are orphaned by small ones. It makes mining more of a skill, as they must make the largest block that is not too large such that other miners will receive it fast enough.

Please stop asking for a hard fork, people doing this are destroing Bitcoin image and credibility. No one of you are entitled to make a poll in the name of the comunity, a few people on these forums don't represent the whole comunity.

¿Do you realice how many people have invested their live savings here? We are speaking at the moment of 318,709,754$, you are all playing with fire and people lives.

Do you expect, all of us selling our Bitcoins and switch to Bitcoin 2 at no loss? People will lose money, a lot o money if a panic sell occurs. Bitcoin will lose credibility for YEARS and investors will flee for ever.

If you want a hard fork, no one is stoping you taking the source code and doing an alt currency but don't name it Bitcoin.

What gives Bitcoin it's value are the rules. Protocol rules must be set in stone, unalterable for ever.

There are good alternatives around there if anyone whant instant transactions like VISA/Mastercard and Ripple.

Sorry to be rought, no offence, but these are my feelings.

Regards.

Can miners pad the block they mined with useless data to fill it up to the limit?

No, because they need to calculate a valid hash value for all the data in the block, which would include the useless data plus the reference to a previous block on the chain.

Edit: Well, to phrase it a bit better, it's not that it would be impossible to do that, of course. You could in theory fill the block to the limit with useless data and start incrementing the nonce until a valid hash value is found. But I fail to see how that would be better than actually including transactions.

Not, economy is not an exact science (if you even call it a science). All in all, it is impossible to predict how a complex system will respond.

In time, the block size may need to change. But there's absolutely no rush.

Let the block size stay at the current size until the limit is hit; then let us run with that for a while. Let us see how easy or hard people find it to work within the limit; let us see what effect it has on transaction fees and confirmation times.

Eventually, a strong consensus might form around an appropriate change. Then, only then, is it worth working out how to implement the change. Equally, we may find that some other solution arises which negates the need for any hard change.

I am surprised how most of people here seem to have already formed a firm opinion on the issue of block size limit, when obviously the issue is extremely complex, and it involves technological but also economic aspects. Not, economy is not an exact science (if you even call it a science). All in all, it is impossible to predict how a complex system will respond.  Bitcoin is an experiment anyway. We need to decide carefully what the next step will be, but unfortunately there is more rhetorics than dialectics in this forum.

I voted "I don't know," but changed my mind after reading - can you edit the poll so we can change our vote (not sure if forum software lets you do that)?

<sarcasm>
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
</sarcasm>

<sarcasm>
Everyone will believe you as long as you make statements without proof.
</sarcasm>

Proof? Have u ever heard about common sense? U seem to be kidding if u believe it's possible to prove anything in Bitcoin land.

Two thoughts:
1. We should distinguish between "spam" transactions, and any padding miners themselves might decide to add for one reason or another.

2. Trying things out on testnet would not be very informative, due to lack of real-world (dis)incentives and non-existing various groups of stakeholders (merchants, miners, consumers, hoarders...).

Removing the limit does not imply useless transactions. It simply means the market will decide what is a useless transaction. So long as clients prefer smaller blocks over larger ones, the miners will decide among themselves what a suitable block size is. If it's too high, small-block miners will earn more and blocks will get smaller. If it's too low, large-block miners will earn more and blocks will get larger.

Isn't this what Bitcoin's about? All we need to do is make sure the system cannot be exploited, test it on testnet, and then not need to worry about block sizes ever again.

Appendix:
1. What changes are needed?
A: The "longest chain" code needs to increase the length of shorter blocks and decrease the length of longer ones. Clients also need to set a bandwidth quota so that they download and propagate the best currently-downloaded chain.
2. Couldn't a miner just spam the network with a huge block?
A: No. Like transactions, blocks need "confirmations". If other miners think the block is too big, they will refuse to confirm it and a smaller block will replace it (as they orphan large blocks).
3. Wouldn't blocks be too big?
A: No. Miners will take an unacceptable risk if they mine large blocks, as they are likely to get orphaned. Higher demand and higher transaction fees will make taking that risk more attractive, so block size can scale with usage.
4. Wouldn't miners just mine empty blocks?
A: Eventually, no. This is a concern in the short term, but as soon as transaction fees overtake subsidies empty blocks will no longer be attractive.
5. Wouldn't this allow DOS attacks?
A: Yes. However, DOS attack prevention code can be written to give up downloading a particularly large block if a competing chain is running at not far below network hashrate.
6. Isn't this a hard fork?
A: Done properly, not any more than raising the block limit. The length code only acts as a tiebreaker, which we already have in "first block wins".

I have to say Dree12 is making the most logical sense here.

No it cannot.

Without the limit, Bitcoin network can't function.

1. After the last Bitcoin will be minted, there will be no incentive for miners to mine, except for transaction fees. When block can be of any size, then any number of transactions can make it into every block, therefore theoretically no transaction fees need to be paid.

2. How do you protect the network from dust spam & DDoS without block size limit ?

why?

What results? It isn't showing any is it?

-MarkM-

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

Works well for me.

Akka, are you using some "theme" other than the plain old default shades-of-blue?

As maybe some "themes" act differently on details like that.

Or maybe it is that voted and I didn't, or even vice versa. (I don't remember voting but also am not positive I didn't.)

-MarkM-

This poll I think is misleading. Opinions could have now changed, but those votes in whatever category are locked.

In some time in the future, a new poll will be made.

The next poll will be how many people upgrade to a new version that contains the change.