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.Quite probably.
Topic: [POLL FINISHED] The block size limit controversy: a proper poll (30 days) (Read 4842 times)
March 11, 2013, 04:46:23 PM
Quite probably.
March 11, 2013, 01:23:02 PM
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. March 11, 2013, 01:21:05 PM
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.
You can't make a new poll everytime somebody changes his opinion.
March 11, 2013, 12:34:56 PM
This poll I think is misleading. Opinions could have now changed, but those votes in whatever category are locked.
March 11, 2013, 10:38:31 AM
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-
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-
OK it seems that poll system on SMF is broken and after i locked voting, viewing results is no longer avaiable...
Unlocked it.
EDIT:
Fixed. Poll is properly locked, but results can be seen.
March 11, 2013, 09:43:58 AM
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-
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-
March 11, 2013, 09:36:26 AM
What results? It isn't showing any is it?
-MarkM-
-MarkM-
Code:
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
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.
Thanks for posting, I can't see it either.
March 11, 2013, 09:34:47 AM
What results? It isn't showing any is it?
-MarkM-
-MarkM-
Code:
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
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.
Edit: I use the standard theme and I voted.
March 11, 2013, 09:28:38 AM
What results? It isn't showing any is it?
-MarkM-
-MarkM-
March 11, 2013, 09:25:55 AM
but maybe you can help me to understand you better.
i believe bitcoin will succeed because everybody can do whatever he wants and just need to follow a few (very basic) rules.
as far as i understand you, you want to add more rules to that: e.g. "nobody is allowed to decide which transactions he dont like" and so on.
i believe bitcoin will succeed because everybody can do whatever he wants and just need to follow a few (very basic) rules.
as far as i understand you, you want to add more rules to that: e.g. "nobody is allowed to decide which transactions he dont like" and so on.
March 11, 2013, 09:23:07 AM
Can "No limit" be added? Thanks.
No it cannot.
Without the limit, Bitcoin network can't function.
why?
Actually that sentence is outdated.
I am no longer sure if the network can function without the limit.
March 11, 2013, 08:33:10 AM
Can "No limit" be added? Thanks.
No it cannot.
Without the limit, Bitcoin network can't function.
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 ?
unlimited block size does not mean that every miner is forced to take any transaction in his blocks.
he is still free to make a policy like "i only put transactions with 0.1btc fee in my blocks".
unlimited just means he has an upper limit which he cannot raise.
March 11, 2013, 08:31:50 AM
Can "No limit" be added? Thanks.
No it cannot.
Without the limit, Bitcoin network can't function.
why?
afaik it would just lead to more centralisation (which is not very good, but it does still work)
March 11, 2013, 08:27:21 AM
It seems that nobody is volting anymore, so it makes sense to lock the poll.
I hope everybody find the results satisfying, I for sure do.
I hope everybody find the results satisfying, I for sure do.
February 23, 2013, 01:18:55 AM
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
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.
I agree. If larger blocks start appearing on the network and become part of the longest chain (i.e., what would be the longest chain if the limit were removed), I will take it as a sign that the major pools have raised or abolished the limit and that bitcoin exchanges, merchants, etc., will follow. I care more about their idea of what a bitcoin is than about what the devs or the average user thinks, or even my own idea of what would be best. I doubt that the major stakeholders will disagree with each other strongly enough to risk a near-even split.
Therefore, I would like the ability to configure my Bitcoin client to ignore the limit. (My client does not generate blocks.) The prospect of my client following the wrong side of a fork because of an oversized block is all risk, no benefit to me. (If the "wrong" side persists due to user sentiment, it will effectively become an alt chain, though some will argue that it is still the true bitcoin.)
February 22, 2013, 06:39:03 PM
Remove the limit completely, so ppl could spam more useless transactions. Let's make HDD producers to produce disks with 100500 PETABYTES capacity!
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.
February 22, 2013, 04:39:05 PM
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...).
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...).
1. They work the same way in that the block would be big, and a big block is less likely to earn anything.
2. Removing the limit, in theory, will allow the block limit to float based on demand. This means that even testnet can act as a mini-Bitcoin.
February 22, 2013, 04:36:39 PM
...
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.
Sorry, that was quite harsh. I removed the statement.
February 22, 2013, 04:36:09 PM
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...).
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...).
February 22, 2013, 04:32:31 PM
Everyone will believe you as long as you make statements without proof.
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.
Jump to: