Pages:
Author

Topic: A Scalability Roadmap - page 4. (Read 14919 times)

hero member
Activity: 1008
Merit: 531
October 10, 2014, 01:17:48 AM
#52

But I'm curious: why do you think an extremely large block size will mess up the economics of mining?  What do you think would happen?


Limiting block size creates an inefficiency in the bitcoin system.  Inefficiency = profit.  This is a basic law of economics, though it is usually phrased in such a way as to justify profits by pointing out that they eliminate inefficiencies.  I am taking the other position, that if we want mining to be profitable then there needs to be some artificial inefficiency in the system, to support marginal producers.  Of course that profit will attract more hashing power thus reducing/eliminating the profit, but at a higher equilibrium.  However, I am not too worried about this aspect of large block sizes.  It is a fairly minor problem and one that is a century away.


RE: geometric growth cannot go on forever:  true, but Moore's law has been going steady for 40 years now. The most pessimistic prediction I could find said it would last at least another 10-20 years; the most optimistic, 600 years.


Well I found several predictions saying that it was only going to continue for about 7 more years.  However, that was about 12 or so years ago, so obviously those predictions didn't come true.

The problem with Moore's Law predictions is that they don't take into account game theory.  They assume that nearly everyone is either working to make better chips, buying better chips, enjoying better chips, or simply having nothing to do with better chips.

We need to imagine a world where the miners, bankers, and governments work to suppress computing technology.  Not because they want to destroy bitcoin, but because they want to be the dominant players.  If bitcoin is wildly successful, Moore's law will have an opponent.


I'd be happy with "increase block size 40% per year (double every two years) for 20 years, then stop."


That would probably work pretty well.  It would end (hopefully) before bitcoin is too big of a deal.

The goal should be to get to a situation where it is simply socially unacceptable to suggest changes to the bitcoin protocol.  This needs to be the situation before mass acceptance.  Once mass acceptance happens conversations like the one we are having now will be held behind private doors by central banks (central banks will always be with us).
legendary
Activity: 3878
Merit: 1193
October 09, 2014, 10:39:35 PM
#51
If 1 MB blocks give us, say, 3 transactions per second, then 20 years of "double every 2 years" growth starting from 20 MB would leave us with about 60 million transactions per second.  That's about 25 transaction per hour per human (assuming a world population of 8.5 billion in 20 years time).

This sounds a bit excessive to me but then again I've not thought seriously about how such a volume of transactions could be utilised.  https://en.bitcoin.it/wiki/Scalability doesn't speculate beyond a few hundred thousand transactions per second.  I'd certainly appreciate a link if a discussion on the utility of millions of transactions per second exists.

I like this line of thinking. What TPS are we shooting for and when? That's what will determine what size blocks we need and how to grow to that target.

Simple growth rates like "50% increase per year" are guaranteed to end up with blocks that are too large, which will require another hard fork. Hard forks are bad, mkay?
sr. member
Activity: 337
Merit: 252
October 09, 2014, 09:07:41 PM
#50
No, it does not mean that.  It means this:

2015: 1.5MB (block reward = 25)
2016: 2.25MB (block reward = 25)
2017: 2.8125MB (block reward = 12.5)
2018: 3.52...  (block reward = 12.5)
2018: 4.39...  (block reward = 12.5)
2019: 5.49...  (block reward = 12.5)
2020: 6.18...  (block reward = 6.25)
2021: 6.95...  (block reward = 6.25)
2021: 7.82...  (block reward = 6.25)

and so on.  That seems like a schedule that won't kill off too many nodes.

I see. I misunderstood you. But it still amounts to basically the same thing. It will level off to a fixed limit eventually. Besides, it is completely ad hoc. Gavin's formula as I understand it is basically to raise the limit as fast as possible without endangering decentralization too much, which makes sense. Yours seems just taken out of thin air.
Quote
An extremely large block size would mess up the economics of mining eventually.

No it won't.
legendary
Activity: 1246
Merit: 1011
October 09, 2014, 07:09:43 PM
#49
Yeah, 40% of a 250 GB connection works out to about 23 MB depending on how you define month.  May I ask what would happen regarding TOR?

Thanks for checking my math!  I used 31-day months, since I assume that is how ISPs do the bandwidth cap.

Ah, that makes sense.  No problem.

RE: what happens with Tor:

Run a full node (or better, several full nodes) that is connected to the network directly-- not via Tor.

But to keep your transactions private, you broadcast them through a Tor-connected SPV (not full) node. If you are mining, broadcast new blocks the same way.

That gives you fully-validating-node security plus transaction/block privacy. You could run both the full node and the SPV-Tor-connected node on a machine at home; to the rest of the network your home IP address would look like a relay node that never generated any transactions or blocks.

If you live in a country where even just connecting to the Bitcoin network is illegal (or would draw unwelcome attention to yourself), then you'd need to pay for a server somewhere else and administer it via Tor.

Thank you, this clears things up for me.  All I don't understand here is the notion of broadcasting newly generated blocks through a Tor-connected SPV node but I imagine I can look this up.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
October 09, 2014, 05:14:22 PM
#48
Yeah, 40% of a 250 GB connection works out to about 23 MB depending on how you define month.  May I ask what would happen regarding TOR?

Thanks for checking my math!  I used 31-day months, since I assume that is how ISPs do the bandwidth cap.

RE: what happens with Tor:

Run a full node (or better, several full nodes) that is connected to the network directly-- not via Tor.

But to keep your transactions private, you broadcast them through a Tor-connected SPV (not full) node. If you are mining, broadcast new blocks the same way.

That gives you fully-validating-node security plus transaction/block privacy. You could run both the full node and the SPV-Tor-connected node on a machine at home; to the rest of the network your home IP address would look like a relay node that never generated any transactions or blocks.

If you live in a country where even just connecting to the Bitcoin network is illegal (or would draw unwelcome attention to yourself), then you'd need to pay for a server somewhere else and administer it via Tor.
legendary
Activity: 1400
Merit: 1013
October 09, 2014, 04:54:34 PM
#47
I agree the current supply curve may look like S2 on http://econpage.com/301/practice/mt1-s.htm.

However the perhaps the reason fees are not that low now is the following:
1.   Mining is not currently perfectly competitive and thus miners are not lowering their offer prices of their services to the marginal cost
2.   The orphan risk is currently a large risk and the marginal cost of including a transaction is actually high

The problems I am talking about do not apply now when there is a large block reward, but could occur in the future when the block reward is low and miners need to be incentivised by the transaction fee.

In a competitive market price should equal marginal cost, in that environment mining profit should fall to zero and there will be limited incentives to mine.  I propose that the system needs arbitrary limits on the blocksize to “manipulate” the transaction fee market, so that there are high enough mining incentives.  

In the current network a corollary situation occurs with respect to the difficulty and the Bitcoin price.  For example, at any given Bitcoin price, miners enter or leave the market and profit margins tend to zero and the system self-adjusts.  This is not a problem, if the Bitcoin price falls, miners exit, the difficulty falls, mining profits increase and we are fine.

Let’s consider the situation when the block reward is low and transaction fees compensate miners, then the dynamics are different.
1. Miners are not pricing transaction very well because of the huge block subsidy. Like all subsidies, it adversely affects the market. Our only recourse is to wait until it diminishes.
2. Orphan risk affects the slope of the curve, not its basic shape. That adding transactions to a block creates costs for the miner in the form of orphan risk is an argument for why no quota is necessary to keep the block size reasonable.

Price discovery for transaction inclusion will get better with there is no subsidy and all miner revenue is derived from via transaction fees. At that point there's nothing "special" about that industry compared to every other service industry which does a fine job of using price discovery to match supply and demand.

If supply is not constrained, transaction fees fall to the marginal cost, mining profit falls and then miners exit and the difficulty falls.  The remaining miners can then find blocks more easily, but they don’t necessarily get compensated more for this, because the fees would still be low.
If there are fewer miners competing for the same amount of transaction fees, then each miner's revenue has increased. The process you describe will continue until the oversupply of miners is corrected and equilibrium is restored.

For example, let’s consider the music industry, improvements in technology are reducing the cost of distributing music and this is a good thing, it means more people get more music at a lower price.  If the marginal cost of distributing music is zero then in a competitive market the price should be zero and the consumer wins.  The record industry or CD production industry may suffer and shrink, which many people may argue is fine, that’s just market forces at work.  With respect to miners, it is different, users need miners to be around.  Improvements in technology which reduced the cost of processing transactions to zero, could damage network security.

Markets that never could have existed in the first place except for government-granted monopoly rights are not appropriate as models of what we should do.
legendary
Activity: 1246
Merit: 1011
October 09, 2014, 04:46:18 PM
#46
An extremely large block size would mess up the economics of mining eventually.

I'm working on a follow-up blog post that talks about economics of the block size, but want to get it reviewed by some real economists to make sure my thinking is reasonably correct. But I'm curious: why do you think an extremely large block size will mess up the economics of mining?  What do you think would happen?

RE: geometric growth cannot go on forever:  true, but Moore's law has been going steady for 40 years now. The most pessimistic prediction I could find said it would last at least another 10-20 years; the most optimistic, 600 years.

I'd be happy with "increase block size 40% per year (double every two years) for 20 years, then stop."

Because if Bitcoin is going gangbusters 15 years from now, and CPU and bandwidth growth is still going strong, then either the "X%" or the "then stop date" can be changed to continue growing.

I did some research, and the average "good" broadband Internet connection in the US is 10Mbps speed. But ISPs are putting caps on home users' total bandwidth usage per month, typically 250 or 300GB/month. If I recall correctly, 300GB per month was the limit for my ISP in Australia, too.

Do the math, and 40% of a 250GB connection works out to 21MB dedicated to Bitcoin every ten minutes. Leave a generous megabyte for overhead, that would work out to a starting point of maximum-size-20MB blocks.

(somebody check my math, I'm really good at dropping zeroes)

Yeah, 40% of a 250 GB connection works out to about 23 MB depending on how you define month.  May I ask what would happen regarding TOR?

If 1 MB blocks give us, say, 3 transactions per second, then 20 years of "double every 2 years" growth starting from 20 MB would leave us with about 60 million transactions per second.  That's about 25 transaction per hour per human (assuming a world population of 8.5 billion in 20 years time).

This sounds a bit excessive to me but then again I've not thought seriously about how such a volume of transactions could be utilised.  https://en.bitcoin.it/wiki/Scalability doesn't speculate beyond a few hundred thousand transactions per second.  I'd certainly appreciate a link if a discussion on the utility of millions of transactions per second exists.


Edit: Oops.  I miscalculated "double every year for 20 years".  Starting from 1 MB blocks worth, say, 3 transactions per second, then 20 years of "double every 2 years" growth starting from 20 MB will yield about 60 000 transactions per second.  That's about 4 transactions per week per human (assuming a world population of 8.5 billion in 20 years time).

Looking forward to the block-size economics blog post.
member
Activity: 129
Merit: 14
October 09, 2014, 03:58:53 PM
#45
I agree the current supply curve may look like S2 on http://econpage.com/301/practice/mt1-s.htm.

However the perhaps the reason fees are not that low now is the following:
1.   Mining is not currently perfectly competitive and thus miners are not lowering their offer prices of their services to the marginal cost
2.   The orphan risk is currently a large risk and the marginal cost of including a transaction is actually high

The problems I am talking about do not apply now when there is a large block reward, but could occur in the future when the block reward is low and miners need to be incentivised by the transaction fee.

In a competitive market price should equal marginal cost, in that environment mining profit should fall to zero and there will be limited incentives to mine.  I propose that the system needs arbitrary limits on the blocksize to “manipulate” the transaction fee market, so that there are high enough mining incentives.  

In the current network a corollary situation occurs with respect to the difficulty and the Bitcoin price.  For example, at any given Bitcoin price, miners enter or leave the market and profit margins tend to zero and the system self-adjusts.  This is not a problem, if the Bitcoin price falls, miners exit, the difficulty falls, mining profits increase and we are fine.

Let’s consider the situation when the block reward is low and transaction fees compensate miners, then the dynamics are different.  If supply is not constrained, transaction fees fall to the marginal cost, mining profit falls and then miners exit and the difficulty falls.  The remaining miners can then find blocks more easily, but they don’t necessarily get compensated more for this, because the fees would still be low.

If the cost of processing transactions drops due to improvements in technology this is a good thing - it means that Bitcoin users get more transactions at a lower price.

Yes in a normal market this is true.  Bitcoin users getting more transactions at a lower price seems good.  However the market for Bitcoin transactions is not a normal market.  The system requires a large number of miners to be around to provide a large hashrate for security purposes.

For example, let’s consider the music industry, improvements in technology are reducing the cost of distributing music and this is a good thing, it means more people get more music at a lower price.  If the marginal cost of distributing music is zero then in a competitive market the price should be zero and the consumer wins.  The record industry or CD production industry may suffer and shrink, which many people may argue is fine, that’s just market forces at work.  With respect to miners, it is different, users need miners to be around.  Improvements in technology which reduced the cost of processing transactions to zero, could damage network security.
legendary
Activity: 4466
Merit: 3391
October 09, 2014, 03:22:39 PM
#44
There are only two costs I can think of:
1. The very small amount of processing required to verify the transaction and include a hash of the transaction in the block header,
2. The cost associated with the higher blocksize increasing the probability of orphan.

I believe that these per transaction costs are real and they will eventually determine the minimum transaction fee, assuming there is no artificial limit to the block size. Even if these costs are very low they are not 0, and the increased block size will allow more transactions and more income from fees.
legendary
Activity: 1400
Merit: 1013
October 09, 2014, 03:00:47 PM
#43
The supply curve I made was assuming successful IBLT O(1) block propagation, which should reduce the marginal increase in orphan risk to alomst zero, this will leave only the small amount of computer processing as the marginal cost of including a transaction in a block.  This small cost is why the supply curve looks the way it does.  Miners include as many transactions as they can because there cost of doing so is limited and therefore the market driven transaction fee will be very low.  Then if demand increases such that there is insufficient space in blocks, supply is constrained by the limit and the price increases.  This is the area on the curve the network may need to be at to ensure mining revenue is sufficient.
Markets don't need quotas in order to prevent producers from operating at a loss.

If the cost of processing transactions drops due to improvements in technology this is a good thing - it means that Bitcoin users get more transactions at a lower price.

You don't have to worry about miners going out of business because they aren't going to add transactions to a block if doing so results in a net loss for them.

By the way: the curves you are looking for are here:

http://econpage.com/301/practice/mt1-s.htm

Right now, the supply curve for Bitcoin transaction processing is like S2 on that graph, except that at the moment the equilibrium point is to the left of the quota, so the quota isn't yet affecting the price.

Without the block size limit, the curve would look like S1.

Technologies which lower the cost of producing and transmitting blocks moves the supply curve to the right (except the quota does not move).
legendary
Activity: 1652
Merit: 2301
Chief Scientist
October 09, 2014, 02:51:30 PM
#42
An extremely large block size would mess up the economics of mining eventually.

I'm working on a follow-up blog post that talks about economics of the block size, but want to get it reviewed by some real economists to make sure my thinking is reasonably correct. But I'm curious: why do you think an extremely large block size will mess up the economics of mining?  What do you think would happen?

RE: geometric growth cannot go on forever:  true, but Moore's law has been going steady for 40 years now. The most pessimistic prediction I could find said it would last at least another 10-20 years; the most optimistic, 600 years.

I'd be happy with "increase block size 40% per year (double every two years) for 20 years, then stop."

Because if Bitcoin is going gangbusters 15 years from now, and CPU and bandwidth growth is still going strong, then either the "X%" or the "then stop date" can be changed to continue growing.

I did some research, and the average "good" broadband Internet connection in the US is 10Mbps speed. But ISPs are putting caps on home users' total bandwidth usage per month, typically 250 or 300GB/month. If I recall correctly, 300GB per month was the limit for my ISP in Australia, too.

Do the math, and 40% of a 250GB connection works out to 21MB dedicated to Bitcoin every ten minutes. Leave a generous megabyte for overhead, that would work out to a starting point of maximum-size-20MB blocks.

(somebody check my math, I'm really good at dropping zeroes)

member
Activity: 129
Merit: 14
October 09, 2014, 02:36:49 PM
#41
Sorry to be blunt, but your supply and demand curves are nonsense.

Miners will not automatically create the largest possible block they can regardless of their revenue.

The supply curve has no relationship with the maximum block size allowed by the protocol - it's determined by the costs involved with producing larger blocks.

Dear justusranvier

Thank you for you comments about the supply and demand curves.  They may well be nonsense as this is an emergent field and I may not have strong knowledge in this area, the curves are also just theoretical and in practice the situation may be different.  I merely propose they could provide a useful framework to analyse the dynamic between transaction fees and the blocksize limit.

I agree that the supply curve is "determined by the costs involved with producing larger blocks", although of course the limit still matters in the sense that supply cannot go above the limit.  The point I was trying to make is the costs "involved with producing larger blocks" are very low.  I think of it in terms of the marginal cost to a miner of including one more transaction in the block. There are only two costs I can think of:
1. The very small amount of processing required to verify the transaction and include a hash of the transaction in the block header,
2. The cost associated with the higher blocksize increasing the probability of orphan.

The supply curve I made was assuming successful IBLT O(1) block propagation, which should reduce the marginal increase in orphan risk to alomst zero, this will leave only the small amount of computer processing as the marginal cost of including a transaction in a block.  This small cost is why the supply curve looks the way it does.  Miners include as many transactions as they can because there cost of doing so is limited and therefore the market driven transaction fee will be very low.  Then if demand increases such that there is insufficient space in blocks, supply is constrained by the limit and the price increases.  This is the area on the curve the network may need to be at to ensure mining revenue is sufficient.
 
Many thanks
sr. member
Activity: 254
Merit: 1258
October 09, 2014, 01:31:03 PM
#40
hero member
Activity: 1008
Merit: 531
October 09, 2014, 02:12:37 PM
#40
Quote
So putting these three principles together here is what I see:

increase the block size by 2X% per year, where X is the block reward.  So we'd have a couple more years at 50%, then four at 25%, then four at 12.5%, and so on.  This is still an astounding growth rate.

... cute and simple, but isn't that what I just said?

It is an interesting solution too, in that it locks the two scarce resources bitcoin provides (block space and coins) into the same release schedule. In this way, the decrease of block reward to miners might be replaced by a commensurate increase in fees from more competition for blockspace.

Just to clarify. This means a doubling from today's 1MB to eventually 2MB, and it will take decades to get there. Seems pointless to me. This will still not solve the problem (if there is one).


No, it does not mean that.  It means this:

2015: 1.5MB (block reward = 25)
2016: 2.25MB (block reward = 25)
2017: 2.8125MB (block reward = 12.5)
2018: 3.52...  (block reward = 12.5)
2018: 4.39...  (block reward = 12.5)
2019: 5.49...  (block reward = 12.5)
2020: 6.18...  (block reward = 6.25)
2021: 6.95...  (block reward = 6.25)
2021: 7.82...  (block reward = 6.25)

and so on.  That seems like a schedule that won't kill off too many nodes.

An extremely large block size would mess up the economics of mining eventually.
legendary
Activity: 1400
Merit: 1013
October 09, 2014, 02:00:52 PM
#39
My Opinion:
Larger blocks means more transactions.
The fee per transaction stays low, but the net fee can grow along with block size.

Coindate, you could well be correct, larger blocks could mean more transactions and therefore if the fees fall then miners can be compensated by higher transaction volumes.

However, let’s make some assumptions about how the network may operate in the future:

1.      IBLT O(1) block propagation has been successfully implemented, and therefore the marginal costs to miners of including additional transactions is close to zero.

2.      Bitcoin mining is competitive such that there are many miners driving down transaction fees to the point where marginal cost is close the marginal revenue

These are both reasonable and desirable assumptions.  Now let’s consider the implications for transaction fees.  I propose this would result in a scenario in which fees are very low and then suddenly sharply increase as we approach the blocksize limit. For example in the following two illustrative charts the supply curve should be very close to the x-axis and then sharply increase at a tipping point, before being very close to the blocksize limit line.  In the charts the orange area represents mining revenue.

Healthy supply and demand curve for space in blocks

 
Scenario in which the blocksize limit has increased too fast


Demand for Bitcoin transactions is unchanged in both scenarios, however in the first chart mining revenue is far higher than in the 2nd chart as the orange boxes demonstrate.  This is because despite the fact that volume has increased, the transaction fees are too low because the blocksize limit has increased too fast, resulting in almost zero transaction fees.  Therefore it is important to keep in mind that the blocksize needs to be small enough to generate fees that compensate miners when the block reward becomes too small.  Reducing the rate of growth in the blocksize when the reward falls may be a good idea for this reason.  Somebody must pay for miners, distributed consensus is not free, I hope the cost per transaction is very low, however it needs to be sufficient.
Sorry to be blunt, but your supply and demand curves are nonsense.

Miners will not automatically create the largest possible block they can regardless of their revenue.

The supply curve has no relationship with the maximum block size allowed by the protocol - it's determined by the costs involved with producing larger blocks.
full member
Activity: 153
Merit: 100
October 09, 2014, 05:33:39 AM
#38
...Hurray, we just reinvented the SWIFT or ACH systems.

SWIFT doesn't work like this at all...

I think what he meant was that it would be like SWIFT in that it would mostly be for large international transfers...

No I got that. What I'm saying, is that it is a false comparison, and that "reinventing" SWIFT, the gold standard, or - as Jon Matonis put it (comments) - a 'wholesale' instrument for global settlement, might not necessarily need to be a bad thing.
member
Activity: 129
Merit: 14
October 09, 2014, 05:10:59 AM
#37
My Opinion:
Larger blocks means more transactions.
The fee per transaction stays low, but the net fee can grow along with block size.

Coindate, you could well be correct, larger blocks could mean more transactions and therefore if the fees fall then miners can be compensated by higher transaction volumes.

However, let’s make some assumptions about how the network may operate in the future:

1.      IBLT O(1) block propagation has been successfully implemented, and therefore the marginal costs to miners of including additional transactions is close to zero.

2.      Bitcoin mining is competitive such that there are many miners driving down transaction fees to the point where marginal cost is close the marginal revenue

These are both reasonable and desirable assumptions.  Now let’s consider the implications for transaction fees.  I propose this would result in a scenario in which fees are very low and then suddenly sharply increase as we approach the blocksize limit. For example in the following two illustrative charts the supply curve should be very close to the x-axis and then sharply increase at a tipping point, before being very close to the blocksize limit line.  In the charts the orange area represents mining revenue.

Healthy supply and demand curve for space in blocks

 
Scenario in which the blocksize limit has increased too fast


Demand for Bitcoin transactions is unchanged in both scenarios, however in the first chart mining revenue is far higher than in the 2nd chart as the orange boxes demonstrate.  This is because despite the fact that volume has increased, the transaction fees are too low because the blocksize limit has increased too fast, resulting in almost zero transaction fees.  Therefore it is important to keep in mind that the blocksize needs to be small enough to generate fees that compensate miners when the block reward becomes too small.  Reducing the rate of growth in the blocksize when the reward falls may be a good idea for this reason.  Somebody must pay for miners, distributed consensus is not free, I hope the cost per transaction is very low, however it needs to be sufficient.
sr. member
Activity: 337
Merit: 252
October 09, 2014, 04:11:33 AM
#36
Quote
So putting these three principles together here is what I see:

increase the block size by 2X% per year, where X is the block reward.  So we'd have a couple more years at 50%, then four at 25%, then four at 12.5%, and so on.  This is still an astounding growth rate.

... cute and simple, but isn't that what I just said?

It is an interesting solution too, in that it locks the two scarce resources bitcoin provides (block space and coins) into the same release schedule. In this way, the decrease of block reward to miners might be replaced by a commensurate increase in fees from more competition for blockspace.

Just to clarify. This means a doubling from today's 1MB to eventually 2MB, and it will take decades to get there. Seems pointless to me. This will still not solve the problem (if there is one).

Are there economic reasons for keeping the block size limited to keep it artificially scarce?
member
Activity: 81
Merit: 10
October 08, 2014, 11:34:30 PM
#35
I agree that we need to increase the block size to prevent transactions getting stuck without a confirmation, but I strongly disagree with the rate that it would be increased. I would support any of the following:

  • 1MB increase per year. - Simple to implement and doesn't lead to exponential growth.
I don't think this would be an option. It may work well in the first few years, however over time this will be less effective as the number of TXs per unit of time will increase at an exponential rate (most likely).
  • 10% increase per year. - Exponential, but with a much smaller constant than has been discussed in this post.
I think this is too slow, especially at first as this is less then the rate of TX growth that we are seeing.
  • Based on fullness of last years blocks (Max 20% increase). - Exponential, but more tightly tied to actual usage. Allows for block size decreases. Miners essentially get to vote on blocksize.
I am not sure about this one. A better solution might be to use your second option (but with a higher increase per year) up to a certain year and the issue can be later revisited.
Basically, my hope is that it gets easier to run a full node over time. The total number of transactions that the worlds population is making is not increasing exponentially so (IMO), the blocksize shouldn't either.
I don't think this will happen. We will likely see less nodes run in households and more nodes run by corporations and on VPS (or hosted servers). The fact is that there is no financial benefit to running a node, and over time people will be less inclined to have one running in their home[/list]
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
October 08, 2014, 11:33:51 PM
#34
Quote
So putting these three principles together here is what I see:

increase the block size by 2X% per year, where X is the block reward.  So we'd have a couple more years at 50%, then four at 25%, then four at 12.5%, and so on.  This is still an astounding growth rate.

... cute and simple, but isn't that what I just said?

It is an interesting solution too, in that it locks the two scarce resources bitcoin provides (block space and coins) into the same release schedule. In this way, the decrease of block reward to miners might be replaced by a commensurate increase in fees from more competition for blockspace.
Pages:
Jump to: