Bitcoin Forum
November 01, 2024, 03:33:48 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 5 6 7 8 9 10 »  All
  Print  
Author Topic: The MAX_BLOCK_SIZE fork  (Read 35591 times)
Akka
Legendary
*
Offline Offline

Activity: 1232
Merit: 1001



View Profile
February 01, 2013, 09:09:57 AM
Last edit: February 01, 2013, 11:52:24 AM by Akka
 #41

I always thought two of the benefits of Bitcoin are:

Fast transactions
Low transaction fees

It seems, that thees points are outright Lies

If the blocksize limit isn't lifted and Bitcoin grows it will at one Point be virtually impossible to make transactions unless a ridiculous high transaction fee is paid.
I can't see how we can ask any merchant to accept Bitcoin, if it is clear that, unless Bitcoin remain a sideline payment system, at some point it will be impossible to accept Bitcoin for small payments.

So learning that changing the blocksize limit would require a hardfork gets me very concerned.

Also, I strongly disagree, that the 1MB blocksize limit is one of the principals of Bitcoin.

IMO it's scarcity of transaction space.

Therefore my Proposal:


Make the max blocksize a mathematical Function.

Lets say for example we set a Target, that the average Blocksize is always 80% of max. Blocksize and adjust the max. Blocksize by max. +-20% all 2016 Blocks to meet this Target.

This would ensure that Blockchain space always remains scarce, therefore ensuring TX fees for fast transaction, by at the same time ensuring that it will always be possible to make a transaction.

I'm looking forward to learn why this wouldn't work.

All previous versions of currency will no longer be supported as of this update
Atruk
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
February 01, 2013, 10:00:38 AM
 #42

Lets say for example we set a Target, that the average Blocksize is always 80% of max. Blocksize and adjust the max. Blocksize by max. +-20% all 2016 Blocks to meet this Target.

This would ensure that Blockchain space always remains scarce, therefore ensuring TX fees for fast transaction, by at the same time ensuring that it will always be possible to make a transaction.

I'm looking forward to learn why this wouldn't work.

The problem with this is that some pools still mine blocks where the only transaction is the one that awards them their subsidy, and that can really poison averages.

As far as using bitcoins in retail on a reasonable timeline goes, a few of the gambling sites have developed very good ways to prevent nasty stuff by identifying the low risk transactions which may as well be accepted immediately. I don't find the interval of time between blocks to be problematic.

Honestly as far as block size goes, I'm pretty comfortable with Gavin making a decision as benevolent dictator and letting everyone know at what point in the future the blocksize increases to its next finite (or formulaic) step.

Akka
Legendary
*
Offline Offline

Activity: 1232
Merit: 1001



View Profile
February 01, 2013, 10:16:27 AM
Last edit: February 01, 2013, 10:34:14 AM by Akka
 #43

Lets say for example we set a Target, that the average Blocksize is always 80% of max. Blocksize and adjust the max. Blocksize by max. +-20% all 2016 Blocks to meet this Target.

This would ensure that Blockchain space always remains scarce, therefore ensuring TX fees for fast transaction, by at the same time ensuring that it will always be possible to make a transaction.

I'm looking forward to learn why this wouldn't work.

The problem with this is that some pools still mine blocks where the only transaction is the one that awards them their subsidy, and that can really poison averages.


Than change it to The average of the biggest 50% of all Blocks mined every 2016 Blocks. That would also mean that at least 50% of all miner would have to agree that a increase of the max. blocksize is necessary and also ensuring no minority can keep an increase from happening.

So (numbers changed a little):

Target: Average Blocksize of the biggest 1008 Blocks is always 90% of max. Blocksize
Adjustment: Max. Blocksize, max. +-20% all 2016 Blocks to meet this Target.


As far as using bitcoins in retail on a reasonable timeline goes, a few of the gambling sites have developed very good ways to prevent nasty stuff by identifying the low risk transactions which may as well be accepted immediately. I don't find the interval of time between blocks to be problematic.

Blocktime all 10 minutes is fine by me. And there is no need to change this in any way IMO. I just ment if there would be say 1 Mil transactions a day, that would mean, that ~400 K each day would never be conformed, solely to the 1Mb limit and this would add up day by day.

Honestly as far as block size goes, I'm pretty comfortable with Gavin making a decision as benevolent dictator and letting everyone know at what point in the future the blocksize increases to its next finite (or formulaic) step.

I agree, but I would be far more comfortable with a solution that would fix this once and for all and would still work for any unforeseen challenges that might come in 50 Years.

All previous versions of currency will no longer be supported as of this update
Atruk
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
February 01, 2013, 10:37:44 AM
 #44

Lets say for example we set a Target, that the average Blocksize is always 80% of max. Blocksize and adjust the max. Blocksize by max. +-20% all 2016 Blocks to meet this Target.

This would ensure that Blockchain space always remains scarce, therefore ensuring TX fees for fast transaction, by at the same time ensuring that it will always be possible to make a transaction.

I'm looking forward to learn why this wouldn't work.

The problem with this is that some pools still mine blocks where the only transaction is the one that awards them their subsidy, and that can really poison averages.


Than change it to The average of the biggest 50% of all Blocks mined every 2016 Blocks. That would also mean that at least 50% of all miner would have to agree that a increase of the max. blocksize is necessary and also ensuring no minority can keep an increase from happening.

So (numbers changed a little):

Target: Average Blocksize of the biggest 1008 Blocks is always 90% of max. Blocksize
Adjustment: Max. Blocksize, max. +-20% all 2016 Blocks to meet this Target.

Isn't it amazing the difference adding one small caveat makes. This is why I'd default to trusting Gavin's judgement, because everyone is trying to smash all of these ideas in his face and he has to make decisions that protect brialliant ideas from naive attacks. http://www.schneier.com/blog/archives/2011/04/schneiers_law.html

solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1006


100 satoshis -> ISO code


View Profile
February 01, 2013, 11:25:24 AM
 #45

A look at historical stats shows roughly:

   500 transactions occurred per day in Jan/Feb 2011,
 5000 per day in Jan/Feb 2012,
50000 per day in late Jan 2013, with an average block size of about 180Kb today (Feb 1st).

https://blockchain.info/charts/n-transactions?showDataPoints=false&show_header=true&daysAverageString=1&timespan=all&scale=1&address=

There is a logarithmic progression in transaction numbers which, if this continues, will see block saturation at 1Mb well before the end of 2013.

I think it is reasonable to call the max block size limit a "time bomb" within bitcoin. If this limit is reached many transactions will languish for hours or days. People will spread the word that bitcoin is breaking down resulting in negative publicity, panic selling and disinvestment, and websites dropping bitcoin. Perhaps the languishing transactions will then be processed, but great reputational damage will be done to a currency which should be as good as virtual gold.

The moral imperative must be to protect the utility and integrity of bitcoin for the public who are using it, the merchant websites accepting it, and the investors who are buying it to hold as an alternative to central bank fiat.

When I recently purchased some coins as an investment it was despite the block size limit being a negative factor. I thought it was a temporary restriction for sensible reasons like training wheels on a bicycle. 99% of bitcoin holders are unaware of it, and the crippling ramifications of it.
 
Akka's solution sounds very good, and it makes sense to include another important improvement as MatthewLM suggests.  I really hope that something can proceed as it would be a shame for bitcoin to suffer from an internal cause when so many external threats still exist.

mintymark
Sr. Member
****
Offline Offline

Activity: 286
Merit: 251


View Profile
February 01, 2013, 12:37:11 PM
 #46

solex, +1.

[[ All Tips gratefully received!!  ]]
15ta5d1N8mKkgC47SRWmnZABEFyP55RrqD
BradZimdack
Member
**
Offline Offline

Activity: 87
Merit: 12


View Profile
February 01, 2013, 05:44:16 PM
 #47

I always thought two of the benefits of Bitcoin are:

Fast transactions
Low transaction fees

It seems, that thees points are outright Lies

I'm beginning to think you're absolutely right.  That scalability wiki page seems like a big fat lie too if block size can never be increased.  I'd really like someone who knows more than me to provide some reassurance here.  This seems like a very worrisome problem.


Therefore my Proposal:
...
I'm looking forward to learn why this wouldn't work.

With any ideas on what the block size "should be", no matter how good they are, isn't the underlying problem that any change will require a hard fork?  Isn't the idea of a hard fork, especially for something this controversial, at this point in the game, basically impossible?
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1073



View Profile
February 01, 2013, 05:51:13 PM
 #48

This seems like a very worrisome problem.
When you say "this" do you mean:

1) MAX_BLOCK_SIZE problem
2) problem with prevalence of white lies and other errors of omission in the Bitcoin milieu

?

Thanks.

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
MatthewLM
Legendary
*
Offline Offline

Activity: 1190
Merit: 1004


View Profile
February 01, 2013, 06:00:05 PM
 #49

If the transaction fees are changed to algorithmically follow the block space as I expect would be an alternative solution to this, what will happen is that bitcoin will become expensive enough for an alternative crypto-currency to arise. An alternative to bitcoin which is cheaper will succeed and bitcoin will fail. Thus the only way to keep bitcoin alive is to allow for more volume, such that demand can be satisfied.

If it does ever come to bitcoin reaching it's limits, then I would be one to support another crypto-currency, as it would then be needed. I think this could be a good thing as it provides an opportunity to improve upon the many flaws of bitcoin with something new.
Akka
Legendary
*
Offline Offline

Activity: 1232
Merit: 1001



View Profile
February 01, 2013, 06:06:52 PM
 #50

With any ideas on what the block size "should be", no matter how good they are, isn't the underlying problem that any change will require a hard fork?  Isn't the idea of a hard fork, especially for something this controversial, at this point in the game, basically impossible?

I thought I read this proposal here, but I don't find it anymore.

It could be introduces that all Blocks of Miners that use the Hardfork are somehow "marked".
As soon as a overwhelming majority of all Blocks (for Example 85%) is marked, a countdown starts and in 10.000 Blocks the Hardfork is activated.
This way Damage and Chaos could be minimized.

But I see no way how this could be "patched" without creating some damage, chaos and still a majority would have to agree to this in the first place, which also isn't ensured.

I also think there is importance to this, as it gets harder to implement this with each passing day.

Correct me if I'm wrong here, I'm far from being an expert.



If the transaction fees are changed to algorithmically follow the block space as I expect would be an alternative solution to this, what will happen is that bitcoin will become expensive enough for an alternative crypto-currency to arise. An alternative to bitcoin which is cheaper will succeed and bitcoin will fail. Thus the only way to keep bitcoin alive is to allow for more volume, such that demand can be satisfied.

If it does ever come to bitcoin reaching it's limits, then I would be one to support another crypto-currency, as it would then be needed. I think this could be a good thing as it provides an opportunity to improve upon the many flaws of bitcoin with something new.

I think Bitcoin should be "patched" if possible. It would be devastating if we increase Bitcoin business further, finally get some Merchant on board, only to get to a point where it will become virtually impossible for a Merchant to use it.

Then when they are frustrated and dumping BTC we tell them, we now have a "better" cryptocurrency, so just use this instead.

This would mean back to field one for cryptocurrencys.

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

Activity: 1596
Merit: 1100


View Profile
February 01, 2013, 06:09:52 PM
 #51

If the transaction fees are changed to algorithmically follow the block space as I expect would be an alternative solution to this, what will happen is that bitcoin will become expensive enough for an alternative crypto-currency to arise. An alternative to bitcoin which is cheaper will succeed and bitcoin will fail. Thus the only way to keep bitcoin alive is to allow for more volume, such that demand can be satisfied.

Boy that's a shortsighted analysis.

Bitcoin will grow layers above the base layer -- the blockchain -- that will enable instant transactions, microtransactions, and other scalable issues.

Do not think that the blockchain is the only way to transfer bitcoins.

Larger aggregators will easily compensate for current maximum block size in a scalable manner.

All nation-state/fiat currencies are multi-layer.  Too many people look at what bitcoin does now, and assume that those are the only currency services that will ever exist.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
HostFat
Staff
Legendary
*
Offline Offline

Activity: 4270
Merit: 1209


I support freedom of choice


View Profile WWW
February 01, 2013, 07:53:59 PM
 #52

@jgarzik
I haven't a deep knowledge of the core of Bitcoin and the possibilities that cryptography can open, but I hope that these "layers" don't mean to centralize Bitcoin and then open new weaknesses.

The other thing isn't about the bitcoin dev team, but I saw other open source projects that died slowly because of the main team.
They were against many requests of the community, because they were convinced to already know "the best" to do or that they were already archived the best results. They were wrong.
I know that Bitcoin is different, it's really fragile, so every change needs a deep examination.
But I hope that doesn't stop you from see everyday if there are any possibilities to fix things today instead of tomorrow.

NON DO ASSISTENZA PRIVATA - https://t.me/hostfatmind/
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2301


Chief Scientist


View Profile WWW
February 01, 2013, 08:30:52 PM
 #53

For the record:

I'm on the "let there be no fixed maximum block size" side of the debate right now.

I think we should let miners decide on the maximum size of blocks that they'll build on. I'd like to see somebody come up with a model for time-to-transmit-and-receive-and-validate-a-block versus increased-chance-that-block-will-be-an-orphan.

Because that is the tradeoff that will keep miners from producing 1 Terabyte blocks (or, at least, would keep them from producing 1 Terabyte blocks right now-- if we have petabyte thumb-drives and Terabyte/second networks in 10 years maybe 1Terabyte blocks will be just fine).

Right now, miners that use the reference implementation and don't change any settings will produce blocks no larger than 250Kbytes big.

So we're finding out right now how miners collectively react to bumping up against a block size limit. I'd like to let that experiment run for at least a few months before arguing that we do or do not need to eliminate the 1MB hard limit, and start arguing about what the default rules for acceptable block size should be.

How often do you get the chance to work on a potentially world-changing project?
johnyj
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
February 01, 2013, 08:58:06 PM
 #54

If the transaction fees are changed to algorithmically follow the block space as I expect would be an alternative solution to this, what will happen is that bitcoin will become expensive enough for an alternative crypto-currency to arise. An alternative to bitcoin which is cheaper will succeed and bitcoin will fail. Thus the only way to keep bitcoin alive is to allow for more volume, such that demand can be satisfied.

Boy that's a shortsighted analysis.

Bitcoin will grow layers above the base layer -- the blockchain -- that will enable instant transactions, microtransactions, and other scalable issues.

Do not think that the blockchain is the only way to transfer bitcoins.

Larger aggregators will easily compensate for current maximum block size in a scalable manner.

All nation-state/fiat currencies are multi-layer.  Too many people look at what bitcoin does now, and assume that those are the only currency services that will ever exist.



Highly agreed, I also think all the changes could be done at higher level without modifying the original protocal, to keep the integrity of the blockchain

justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1013



View Profile
February 01, 2013, 10:16:16 PM
 #55

Bitcoin will grow layers above the base layer -- the blockchain -- that will enable instant transactions, microtransactions, and other scalable issues.

Do not think that the blockchain is the only way to transfer bitcoins.

Larger aggregators will easily compensate for current maximum block size in a scalable manner.

All nation-state/fiat currencies are multi-layer.  Too many people look at what bitcoin does now, and assume that those are the only currency services that will ever exist.
These other layers may indeed assume that role someday, but it should happen because they prove to be superior on their own merits, not because the capabilities of blockchain transfers are deliberately crippled.
ildubbioso
Sr. Member
****
Offline Offline

Activity: 389
Merit: 250



View Profile
February 01, 2013, 11:00:14 PM
 #56

For the record:

I'm on the "let there be no fixed maximum block size" side of the debate right now.

I'd like to let that experiment run for at least a few months before arguing that we do or do not need to eliminate the 1MB hard limit, and start arguing about what the default rules for acceptable block size should be.


Isn't waiting dangerous?
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
February 02, 2013, 03:39:05 AM
 #57

For the record:

I'm on the "let there be no fixed maximum block size" side of the debate right now.

I'd like to let that experiment run for at least a few months before arguing that we do or do not need to eliminate the 1MB hard limit, and start arguing about what the default rules for acceptable block size should be.


Isn't waiting dangerous?

If we want to do it, this is the best moment. As ASICs start running, mining becomes less decentralized for a short period, which means we don't need to persuade so many people

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
fornit
Hero Member
*****
Offline Offline

Activity: 991
Merit: 1011


View Profile
February 02, 2013, 04:00:18 AM
 #58

guys, its not THAT urgent. the first thing that happens when the blocks start filling up is that transactions with low or no fees will be delayed so much that they are no longer possible.
right now, transaction fees are 0,011% of the current transaction volume. on average you pay 1/10000 of the transfered amount - or average 1/5 of an us-dollar cent -as a fee. so there is plenty of room before non-micro-transactions are noticably affected by this in any way. satoshi dice however might run into problems much sooner i suppose.
BladeMcCool
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
February 02, 2013, 06:47:09 AM
 #59

could maybe future-date a larger block size allowance by doing something like at block 250000 2MB blocks become allowed .. or something like that. Why not anyway. And for tx fees in blocks, more tx with lower fees vs less tx with higher fees = same amount of fees in a block that took essentially the same resources to compute, so it seems pretty moot. Am I missing something?
mp420
Hero Member
*****
Offline Offline

Activity: 501
Merit: 500


View Profile
February 02, 2013, 10:23:54 AM
 #60


In 10-years, a modern smartphone/computer will be able to run the full processing node if the Max_Block_Size remains 1MB.  This is a clear economic benefit for Bitcoin: Decentralized Bitcoin verification.  In fact in a few years, virtually every computer will be able to process the entire blockchain without issue thus making Bitcoin extremely unique in the realm of payments.

What is the use of having portable devices act as full nodes if you can't (because of fees) use bitcoin for purchasing anything smaller than a house? As I see it, your argument is not valid. With 1MB blocksize limit, even if Bitcoin remains a relatively small niche currency, the limit will act as a hard constraint on the potential utility of the currency. Of course, once we start hitting the limit, it will hurt Bitcoin's public image so much that it's conceivable so many people will move away from Bitcoin that we get few more years of time to fix the issue.
Pages: « 1 2 [3] 4 5 6 7 8 9 10 »  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!