Bitcoin Forum
October 24, 2017, 12:41:08 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Long term Scalability of Bitcoin and the 1 MB block size limit  (Read 8682 times)
geofflosophy
Sr. Member
****
Offline Offline

Activity: 336



View Profile
November 01, 2013, 10:07:00 AM
 #1

This is something that came up in a speculation discussion thread I'm involved in, and I was hoping someone with better knowledge of the technical aspects of bitcoin could clear things up for me.

As I understand it, bitcoin needs to have exponentially greater number of transactions in just a few years in order to keep miners interested as the block reward continues to halve, particularly as the miner fee gets smaller in the face of a rising price of Bitcoin. However, if there is a 1mb block size hard limit, it would seem that something's got to give.

I mostly want to hand wave this away and say oh the devs will work it out, but it's probably better to just reach out and get things clarified. Is this an inevitable doomsday scenario for Bitcoin in a world where bitcoin is the universal payment option internationally representing a $20 trillion market cap?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508805668
Hero Member
*
Offline Offline

Posts: 1508805668

View Profile Personal Message (Offline)

Ignore
1508805668
Reply with quote  #2

1508805668
Report to moderator
1508805668
Hero Member
*
Offline Offline

Posts: 1508805668

View Profile Personal Message (Offline)

Ignore
1508805668
Reply with quote  #2

1508805668
Report to moderator
1508805668
Hero Member
*
Offline Offline

Posts: 1508805668

View Profile Personal Message (Offline)

Ignore
1508805668
Reply with quote  #2

1508805668
Report to moderator
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 01, 2013, 10:17:43 AM
 #2

Consensus is the block size limit will have to rise.

Us geeks were/will/are arguing over how and when, not if...

How often do you get the chance to work on a potentially world-changing project?
Rluner
Full Member
***
Offline Offline

Activity: 126



View Profile
November 01, 2013, 10:28:50 AM
 #3

May I ask if anyone can guess at what time period we may hit this limit?

If we assume the current rate of growth of Bitcoin?

An order of magnitude would be acceptable in such guess work, eg  weeks, months, years, decades.
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 01, 2013, 10:35:03 AM
 #4

See: Average block size chart

Since implementing the "dust rule", block size has been pretty steady; I would guess we won't hit the 1MB hard limit for another two years, but that is just a guess, we could easily hit it sooner or later than that.

How often do you get the chance to work on a potentially world-changing project?
Valerian77
Sr. Member
****
Offline Offline

Activity: 398


View Profile
November 01, 2013, 10:38:53 AM
 #5

Biggest blocks (in bytes)

Quote
Blocks

Hash    Height    Age    Date    ฿TC    #TXN    Bytes
0⋯4319133c6c0    228,538    8 months    2013-03-29 07:38:36Z    17,022    725    998,053
0⋯8f3a4259afa    256,961    2 months    2013-09-09 16:02:21Z    5,168    3,861    905,676
0⋯a3fb6b3be6e    258,355    2 months    2013-09-16 18:47:17Z    4,595    429    901,212
0⋯f65ddaf0d60    258,365    2 months    2013-09-16 20:48:59Z    9,516    619    898,627
0⋯92007e28df0    263,240    3 weeks    2013-10-1 ...

Bitmessage: BM-2cTHvwzzG3cDJxmM7YrYXSaBex4oRobJxu
Cubic Earth
Hero Member
*****
Offline Offline

Activity: 738


HAZZA Token Sale October 3rd


View Profile
November 01, 2013, 10:44:01 AM
 #6

See: Average block size chart

Since implementing the "dust rule", block size has been pretty steady; I would guess we won't hit the 1MB hard limit for another two years, but that is just a guess, we could easily hit it sooner or later than that.

It would be cool to see a version of that chart multiplied by 10/average-block-interval.  If blocks were coming at a rate of one per 10 minutes, the current block size would be about 60% bigger, or about 200KB.

       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀   ▄███████▄    ██▄
 ▄█▀  ▄██████▀▀  ▄▄▄   ██▄
▄█▀  ▄█████▀  ▄██████▄  ██▄
██  ▄████▀  ▄█▀ ██████▄  ██
██  ████▄ ▄█▀ ▄█▀ ▀████  ██
██  ▀██████ ▄█▀  ▄████▀  ██
▀█▄  ▀██████▀  ▄█████▀  ▄█▀
 ▀█▄   ▀▀▀  ▄▄█████▀   ▄█▀
  ▀██▄   ▀███████▀   ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.HAZZA.
█████▀
███▀
██  ▄█
██▄██▀
███▀ 
█▀  ▄█
  ▄███
▄██▀██
█▀  ██
  ▄███
▄█████

█████▀
███▀
██  ▄█
██▄██▀
███▀ 
█▀  ▄█
  ▄███
▄██▀██
█▀  ██
  ▄███
▄█████
.
▬▬▬   Mentioned in   ▬▬▬
[CNBC] [BLOOMBERG]

█████▀
███▀
██  ▄█
██▄██▀
███▀ 
█▀  ▄█
  ▄███
▄██▀██
█▀  ██
  ▄███
▄█████

█████▀
███▀
██  ▄█
██▄██▀
███▀ 
█▀  ▄█
  ▄███
▄██▀██
█▀  ██
  ▄███
▄█████
Birdy
Sr. Member
****
Offline Offline

Activity: 364



View Profile
November 01, 2013, 10:44:13 AM
 #7

Biggest blocks (in bytes)

Quote
Blocks

Hash    Height    Age    Date    ฿TC    #TXN    Bytes
0⋯4319133c6c0    228,538    8 months    2013-03-29 07:38:36Z    17,022    725    998,053
0⋯8f3a4259afa    256,961    2 months    2013-09-09 16:02:21Z    5,168    3,861    905,676
0⋯a3fb6b3be6e    258,355    2 months    2013-09-16 18:47:17Z    4,595    429    901,212
0⋯f65ddaf0d60    258,365    2 months    2013-09-16 20:48:59Z    9,516    619    898,627
0⋯92007e28df0    263,240    3 weeks    2013-10-1 ...

If it hits the 1-MB limit once in a while it's no problem, the problem begins when it starts hitting it several times in a row (and thus delaying transactions more and more).
leemar
Full Member
***
Offline Offline

Activity: 193


View Profile
November 01, 2013, 10:50:35 AM
 #8

In terms of long term space requirements spent transaction deletion and summarisation will drastically reduce this even if you are running a complete but non-archival node.  

The scalability wiki covers a lot of this.

https://en.bitcoin.it/wiki/Scalability

remember also an increasing proportion of transactions are happening off-block


jubalix
Legendary
*
Offline Offline

Activity: 1624


View Profile
November 01, 2013, 11:13:26 AM
 #9

i never quite understood why you need the who block chain and not just last part that is large enough to make it hard enough not to duplicate. All unmoved coins beyond this point could just be complied into a continuous space, sort like defraging a HD.....or is that the size of the bloc chain already?

Admitted Practicing Lawyer::BTC/Crypto Specialist.
B.Engineering/B.Laws
bg002h
Donator
Legendary
*
Offline Offline

Activity: 1358


I outlived my lifetime membership:)


View Profile WWW
November 01, 2013, 11:53:13 AM
 #10

i never quite understood why you need the who block chain and not just last part that is large enough to make it hard enough not to duplicate. All unmoved coins beyond this point could just be complied into a continuous space, sort like defraging a HD.....or is that the size of the bloc chain already?

You only need to keep an entire copy of the Blockchain if you want complete trustlessness (For example, if you cannot trust anyone supply you with the last n number of blocks). This doesn't make a lot of sense given the cost for most users.

The only reason there is a block size limit in the first place is to protect the Blockchain from spam. That's how it was set up originally and that limit will eventually increase. That limit isn't truly part of the Bitcoin protocol per se. There are some who wanted to spam the Blockchain considerably and wanted The block size limit to remain fixed in place so as to drastically increase the transaction fees. I don't think anyone holds that opinion anymore. I think we all, more or less, recognize that a Bitcoin is only as valuable as the size of the transaction network behind it.

Hardfork aren't that hard.
1GCDzqmX2Cf513E8NeThNHxiYEivU1Chhe
Peter Todd
Legendary
*
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:16:49 PM
 #11

This is something that came up in a speculation discussion thread I'm involved in, and I was hoping someone with better knowledge of the technical aspects of bitcoin could clear things up for me.

As I understand it, bitcoin needs to have exponentially greater number of transactions in just a few years in order to keep miners interested as the block reward continues to halve, particularly as the miner fee gets smaller in the face of a rising price of Bitcoin. However, if there is a 1mb block size hard limit, it would seem that something's got to give.

Transaction fees aren't fixed - it's a supply and demand auction for a limited resource. Transactions definitely do not have to increase in number to keep miners interested - it'd be just as easy for fees to increase. An oft-quoted possible future scenario is for Bitcoin to have a trillion dollar market cap, and 0.5% of that market cap going to miners every year in the form of transaction fees - $5 billion a year. That leads to roughly $20/tx, similar to wire orders. (obviously the blockchain will be used for settlement and people's savings in such a scenario) Interestingly, this is almost identical to what transactions currently cost, in terms of inflation. IMO this says a lot about how Bitcoin is used primarily as an investment, rather than as a way to pay people over the internet...

What's good about such a scenario is it's guaranteed that nearly all the money going to transaction fees will go directly to the hashing power that keeps the network secure, and it's guaranteed that mining will be something you can do anonymously and Bitcoin stays decentralized, at the core anyway. You'd need a lot of off-chain stuff, or alt-coins or who knows what else, for low-value transactions, but it's not a model that much different than what people do today. (look at how most Bitcoin users trust central services like blockchain.info and coinbase with their funds %100) If markets demand it, you can get pretty good auditing and fraud prevention and punishment. It's a pretty safe option, but it's not particularly sexy. It's also an option that happens by default: inputs.io, coinbase and others have already popped up with their various solutions and it appears that majority of Bitcoin transactions already happen off-chain anyway. (the figures inputs.io gave me alone a few months ago for example was nearly 50:50 by value, and a clear majority in terms of number of transactions)

One problem with off-chain stuff is it's easy for it to become too good: if the market finds the centralized and decentralized ways of doing them prove secure enough, that'll undercut mining income by shifting more and more transactions off the blockchain entirely.

You can also raise that limit. The problem here is that the higher the limit is, the more money goes to infrastructure like internet connections, and even worse it makes highly centralized pools more profitable than more decentralized mining. (smaller pools, solo, etc) At the extreme is the frankly insane suggestions to just remove the limit at all and let miners decide, which inevitably lead to dirt-cheap transactions, where the majority of the cost goes to infrastructure rather than hashing power. On the other hand, no-one wants to be the guy deciding the limit - the best we've got is suggestions to have all Bitcoin owners vote on the limit.

But raising definitely has advantages too, and given the inflation reward we'd probably get away with it for another 10 or so years before the inherent economic problems catch up with us.

It's worth remembering that with clever cryptography and some backwards-compatible changes to the core protocol we can definitely raise the limit and still be able to effectively audit the blockchain, at least as long as miners co-operate. We may even be able to retrofit the ability to mine in a decentralized, low-bandwidth, low infrastructure manner, although while that's technically possible, it probably needs very controversial economic changes to really work properly. Right now the consensus is we need to do something, beyond that though there isn't much agreement. (there is not consensus to raise the blocksize, at least not in the way the general public thinks, and there also is not consensus that even if the limit should be raised, raising it will be politically possible)

Anyway, look at it this way: long-term Bitcoin will probably fail eventually due to poorly designed incentives for mining, if not due to some other reason. But another, better designed, crypto-coin can take it's place. In the meantime we can learn a lot from Bitcoin, lessons that'll help design the next generation of crypto-coins.

hazek
Legendary
*
Offline Offline

Activity: 1078


View Profile
November 03, 2013, 03:21:01 PM
 #12

See: Average block size chart

Since implementing the "dust rule", block size has been pretty steady; I would guess we won't hit the 1MB hard limit for another two years, but that is just a guess, we could easily hit it sooner or later than that.


How would mass adoption of coinjoin type txs further reduce block size needs? Would it at all?

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
Peter Todd
Legendary
*
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:35:55 PM
 #13

How would mass adoption of coinjoin type txs further reduce block size needs? Would it at all?

It's a very small, single-digit, improvement, about 9 edit: 6 bytes per transaction.

hazek
Legendary
*
Offline Offline

Activity: 1078


View Profile
November 03, 2013, 04:38:54 PM
 #14

How would mass adoption of coinjoin type txs further reduce block size needs? Would it at all?

It's a very small, single-digit, improvement, about 9 bytes per transaction.

Heh was hoping for more, I guess we are waiting for Bitcoin 2.0 to emerge which solves this issue then.

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
Eri
Sr. Member
****
Offline Offline

Activity: 265


View Profile
November 04, 2013, 01:56:15 PM
 #15


As I understand it, bitcoin needs to have exponentially greater number of transactions in just a few years in order to keep miners interested as the block reward continues to halve, particularly as the miner fee gets smaller in the face of a rising price of Bitcoin. However, if there is a 1mb block size hard limit, it would seem that something's got to give.



Ok, So ill try to answer this. It seems like allot of the finer points in bitcoin people have to learn and understand on their own. ive tried explaining this to people before but it seems to be one of those "you either get it or you dont" type of things. None the less.. ill try.

As I understand it, bitcoin needs to have exponentially greater number of transactions in just a few years in order to keep miners interested as the block reward continues to halve.

The whole mining, fees, bitcoins earned, cost of mining hardware etc is all one big multi faceted balancing act. when you tweak one thing there are several things that can happen to balance it out. the theory that you and (last i knew) quite a few people had... was that 'when the mining reward is cut in half the transaction count must increase for them to keep their earnings the same'. There is another possibility, rather then the number of transactions increasing, you can simply account for this with an increase in value for bitcoins.

i guess the simplest way to illustrate this is.. if the block reward is cut in half, then either the value of bitcoin needs to double to make up for it or the number of transactions being processed needs to increase. A quick look on any site that tracks the historical value of bitcoin and assuming you know the dates (i dont know them but i remember tracking it at the time) and youd notice that bitcoins were 15$ each at the time. within a week or a month bitcoins value started to go up on a nice curve... then a boom.. a bust.. an oscillation.. and here we are at.. 240$ each. the value of bitcoin has since more then doubled which more then makes up for the decrease in reward.

(Ex. with simple made up numbers)
lets say the block reward is 50BTC  and that each BTC is worth 1$. (ignoring fees for simplicity) that would be 50$.
50BTC * 1$ each = 50$

If you drop the block reward to 25BTC and your profit stays the same at 50$, then some quick math and you find out that you would need a BTC value of 2$ each to maintain the balance. The value would have to double.
50$ / 25BTC = 2$ each


Anyway... thats about the best i can explain it and dont take offense if its overly simple ^^;

in regards to the blocksize limit, its going to go up and there is nothing wrong with that, though we do need blockchain pruning which will keep the blockchain allot smaller. in regards to mining profitability, the way it works is that its always just bearly profitable while the variables are stable. but as you well know, with ASICs emerging the entire system is anything but stable atm.

I Hope this helped.
jubalix
Legendary
*
Offline Offline

Activity: 1624


View Profile
November 04, 2013, 07:58:43 PM
 #16

doesn't PPC answer all of these mining problems....?

Admitted Practicing Lawyer::BTC/Crypto Specialist.
B.Engineering/B.Laws
Melbustus
Legendary
*
Offline Offline

Activity: 1638



View Profile
November 04, 2013, 08:02:05 PM
 #17


It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.


Bitcoin is the first monetary system to credibly offer perfect information to all economic participants.
Cryptoasset rankings and metrics for investors: http://onchainfx.com
revans
Sr. Member
****
Offline Offline

Activity: 336


View Profile
November 04, 2013, 08:29:21 PM
 #18

Consensus is the block size limit will have to rise.

Us geeks were/will/are arguing over how and when, not if...


And despite what Bitcoin cultists (this includes the core dev team) there are massive issues involved in doing so
gollum
Sr. Member
****
Offline Offline

Activity: 434


In Hashrate We Trust!


View Profile
November 04, 2013, 08:44:32 PM
 #19

Im very skeptic about the scalability of the current architecture.
Imagine 1 billion people using bitcoin 5 times/day = 5 billion transactions / day = 1825 billion transactions per year

Is the bitcoin client able to handle 58,000 transactions per second and a blockchain terrabytes or maybe even petabytes in size?
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 05, 2013, 12:22:39 AM
 #20

Is the bitcoin client able to handle 58,000 transactions per second and a blockchain terrabytes or maybe even petabytes in size?

Which "bitcoin client" ?

The client-side of Multibit and electrum should have no problem handling that transaction volume.  Only the transactions relevant to your wallet are sent to your machine when you are running those clients.

The reference implementation can't handle that transaction volume today, but I 100% guarantee that version 11.11 which I 100% guarantee will be released on November 11'th, 2022 will be able to handle that transaction volume.

I feel obliged to insert my standard disclaimer:  Bitcoin is an experiment in progress.  Only invest time or money that you can afford to lose, there is still a chance the experiment may fail for some reason we don't forsee.  Past results are no guarantee blah blah blah.

That said, I'm more confident than ever that the network will be able to scale up and remain decentralized.

How often do you get the chance to work on a potentially world-changing project?
Pages: [1] 2 »  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!