Bitcoin Forum

Permanently keeping the 1MB (anti-spam) restriction is a great idea, if you are a bank. Those favoring a permanent 1MB cap, whilst asserting that Bitcoin can still be a financial backbone of sorts, don't know how right they are. The problem isn't a limit in general but that 1MB provides so little transaction capacity that, under any meaningful adoption scenario, it will push all individual users off the blockchain to rely on trusted third parties. 1MB is insufficient for end to end direct user access, but it is sufficient for a robust inter-‘bank’ settlement network.

If the cap is not raised to some higher limit; allowing a larger number of users to maintain direct access, then individuals will be priced out of the blockchain. When that happens Bitcoin becomes yet another network with no direct (peer) access; like FedWire, SWIFT, and other private closed transfer networks.  There is no realistic scenario where a network capped permanently at 1MB can have meaningful adoption whilst still maintaining direct access to the blockchain by individuals. To be clear, by ‘direct access’ I mean both parties transacting directly on-chain without relying on an intermediary or trusted third party.

Satoshi Nakamoto - Bitcoin Whitepaper (http://"https://bitcoin.org/bitcoin.pdf")

Finding a balance
If the transaction capacity of a peer to peer network is very low then the resource requirements of running a full node will also be low but the cost of a transactions will be high.  A network that keeps computing requirements low but which has priced direct access to that network out of the hands of individuals doesn't help decentralization. Likewise if the transaction capacity of the network is very high then the cost of transactions will be low but the resource requirements for running a full node will be high.  A network that has sufficient transaction capacity for every possible transaction but which requires resources that put operation of a full node beyond the capabilities of individuals also doesn't help decentralization.

There is no "perfect" transaction rate.  It is a compromise between two different centralization risks.  Lowering the risk of transaction centralization raises the risk of node centralization and the reverse is also true.  A robust network means minimizing overall risk not minimizing one risk at the expense of the other.  This means that neither extreme is optimal.  What level of transaction capacity (in terms of block size) provides the optimum balance will be saved for future discussions. Having a discussion on how to change the network first requires an acceptance that the network needs to change.  So lets start with why the network must change.


Can we stop talking about a cup of coffee please?
If you have been following the discussion you may have heard a claim such as "Every $5 coffee doesn't need to be on the blockchain so there is no need to raise the limit".   The implied meaning is that while the cost of permanently keeping the limit will exclude 'trivial' transactions you will still have direct access to the blockchain for everything else.   This is misleading as the 1MB restriction is so restrictive that larger more meaningful transactions will eventually become uneconomical as well.  

I don't really care if my morning coffee is paid for using a centralized service.  Centralization and trusted third parties aren't always bad. <gasp>.  Context matters so try to read the rest before freaking out.  Have you ever given or received a gift card?   Can't get more centralized than that.  If I put $100 in Bitcoins under the control of a third party say in a ewallet or bitcoin debit card service, the risk and scope of that centralization are limited and manageable.  As long as direct access to the network remains economical I can securely store and transfer my wealth using on-chain transactions and use centralized solutions where the risk is low such as day to day purchases.  On the other hand if the imbalance between transaction demand and capacity makes individual transactions uneconomical I will lose direct access all together and that risk is more severe and the consequences more significant.

Sidechains, payment channels, and cross-chain atomic transactions are decentralized system that can move some of the transaction volume off the primary chain.  In essence like centralized solutions they can act as a multiplier allowing a higher number of total transactions than the number of direct on-chain transactions.   It is important to realize they still rely on the primary chain having sufficient transaction capacity or they aren't trustless.  As an example a payment channel could allow hundreds or even thousands of off chain transactions but it requires periodic on-chain transactions to create, adjust, and takedown.  If the individual user loses direct access to the primary chain they also lose trust free solutions like payment channels.  If direct access becomes prohibitively expensive then only alternative which provides sufficient scale is using trusted third parties.

When demand significantly exceeds capacity it increases the utility and value of centralized solutions
If the transaction demand exceeds capacity by a magnitude or more it will lead to direct users being replaced by trusted third parties acting as aggregators.   There are a lot of disadvantages to centralized services but they are more efficient and if the artificial limit is kept it will play right into the advantages of centralized services.  A third party can facilitate instant off-chain transactions.  If demand outstrips the very limited capacity it will force transactions off-chain using trusted third parties which I will call processors.  

Today these processors would include online wallet providers, exchanges, merchant payment service providers, and services where the user maintains a balance under the control of the merchant (casino, poker room).  In time even traditional financial companies and banks could be processors.  The one thing they all have in common is that customers of these services do not have direct control over private keys and do not directly make transactions on the network.  The processor has control over the private keys, keeps the Bitcoins in reserve and maintains an internal ledger of user transactions and balances.   Processors can trivially facilitate transactions between two customers of their service.   Since they control the private keys they simply update the ledger balances of the two customers and many of them do this today.  

However transactions can still occur off-chain even if they involve customers of different processors.  The process is not trustless but risk can be managed.  Two processors would aggregate all the transactions which occur between their customers and then periodically settle the difference.  When a payment from a customer of one processor is made to a customer of another processor the sending processor will notify the receiving processor.  Both processors will update their internal ledgers.  Over time this will result in an accumulated balanced owed by one processor to the other which can be settled with a single on-chain transaction.  The key thing is that there is a one to many relationship between the settlement transactions and underlying customer transactions.   While the 1MB block limit does not provide sufficient capacity for a large number of direct user transactions, third party processors can facilitate a very large number of off-chain transactions using a smaller number of on-chain settlements.  Blocks of a finite size can support a nearly unlimited amount of off-chain transaction capacity with the limitation that it involves the use of trusted third parties.

You can't competing with a 'bank'
You might be considering the point above but dismissing it because you still 'could' submit a transaction to the network.  The processors described above don't have the ability to close the network but a network that you have technical access to but which is uneconomical is effectively no access at all.  The current block size realistically limits capacity to no more than two to four transactions per second.  Two transactions per second is roughly 64 million transactions per year.  A finite number of transactions can't support an infinite number of direct users.  Say at some point there are ten million users and they wish to make two transactions per month.  That is 240 million transactions but only 64 million will fit in the blocks.  What happens to the excess.  If third party processors are attractive the difference will be handled by them. When you consider a settlement network would allows these third party processors to offer instant, 'no risk' transactions at significantly lower fees than on chain transactions the excess demand will be processed off-chain.   If the network continues to grow the profitability of these companies will grow and that will lead to more third party companies.   Those settlement transactions allow more off-chain transactions but at the same time compete with direct user transactions for the limited on-chain capacity.  In a settlement network the upper limit on the number of settlements required grows exponentially with the number of trusted peers.  Just two hundred trusted peers (crypto banks) performing hourly settlements would fill the blocks, all the blocks perpetually.  There may be billions of 'Bitcoin' transactions but they would be nothing more than updates on centralized ledgers.  The blockchain would just handle the settlement between massive financial service providers.  As these entities are collecting fees, and on chain transactions are a necessity of doing business, they can and will pay far more than you to ensure timely inclusion in a block.   When you as an individual have been reduced to a position where you must outbid a 'bank' for space in the blockchain then you have effectively lost access to the blockchain.

Wait I don't get how off blockchain transactions could occur across entities
Imagine two large financial service providers where thousands of customers make payments to customers of the other entity.  These may not be banks in the traditional sense, they can be any entity which acts as a third party to manage the bitcoins and transactions of customer.  Today it could be major exchanges, payment processors, and ewallet providers but tomorrow it could include traditional financial service companies or even banks.   For this example lets call the two entities Chase and HSBC.   Chase and HSBC can notify each other when one of their customers makes a payment to a customer of the other entity.  Both would update their internal ledgers and the payments would appear to occur instantly.  Most importantly none of them would require an on-chain transaction.  It is just updating numbers in a ledger.  If you are a Coinbase customer and pay another coinbase customer this happens today.  We are only taking it a step further and handling cross entity transactions.  Now the entities have no real cost to perform these payments.  They are just sharing a few bytes of information with their counterparty and updating numbers in a database.  However over time, the net amount of the thousands of transactions will result in one entity accumulating a balanced owed to the other.  This is why settlement networks require some level of trust.   It requires trusted peers to extend mutual lines of credit to each other.  The more they trust each other, the larger the lines of credit and the less frequently they need to settle.  It is also why you will never be a peer on this network.  The entities would enter into a legally binding agreements which set up the conditions of the settlement.  The amount of funds the entities are risking is limited.  The entities will limit the amount of credit they will extend and the terms are usually very short.  These aren't long term loans, in the traditional banking world settlement might occur the next business day.  The efficiency of the blockchain allows for lower capital requirements and lower risk by settling more frequently maybe even hourly.

Imagine that in a particular hour HSBC customers make thousands of payments to Chase customers totalling 10,000 BTC and Chase customers make thousands of payments to HSBC customers totalling 3,000 BTC.  In total transaction volume is worth 13,000 BTC.   As these payments occur Chase and HSBC notify the other party.  This allows both to update their ledgers.  A customer making a payment would see their balance be reduced 'instantly' and the customer receiving a payment would see their balance increase 'instantly'.  The net flows however are not balanced.  Chase has increased their customer balances 10,000 BTC and only reduced their customer balances 3,000 BTC.  On the books both entities have a liability called 'Customer Deposits'.  They keep reserves (hopefully >=100% to cover those liabilities).  However Chase has seen its liability increase by 7,000 BTC and HSBC has seen its liability decrease by the same amount.  To reconcile this HSBC will make a single on-chain transaction to Chase for 7,000 BTC.  This will increase Chase's reserves by 7,000 BTC and decrease HSBC's reserves by 7,000 BTC.  Everything is balanced again.   Yes it did require a limited amount of trust between settlement peers and a single on-chain transaction but it facilitated thousands of off chain transactions.  As soon as the next cross entity transaction happens a balance is owed by one entity and the net amount owed will increase and decrease until the next settlement which balances the books again and the cycle perpetually continues.

Now when demand for transactions exceeds what is possible who do you think can pay more in fees?  You or a bank?  If transaction demand exceeds capacity then some transactions will not make it into a block.  Those paying the highest fee will be the ones who retain access to the blockchain and those unable or unwilling to will be excluded.  It is delusional to think it will be the 'banks' that suffer in a situation like that.

The reported 7tps transaction capacity does not exist.
There is a myth that without raising the limit the network could handle 7tps.  It can't.  The limit is 1MB per block the actual transaction capacity depends on the average transaction size and realistically that provides no more than 2 to 4 tps. To achieve 7 tps using one block of 1 MB every 600 seconds means that the average transaction size must be 240 bytes (1,000,000 bytes / 600 seconds / 7tps = 240 bytes).  If you have a Bitcoin wallet handy take a look at your last dozen transactions and if you don't have a wallet handy use a website to lookup the transactions in the most recent block.  How many of the transactions were under 240 bytes? Not very many.  I am going to say the majority of your transactions were probably between 300 and 700 bytes.  

Can you form a 240 byte transaction?  Sure as long as you only have only a single input.  A transaction input is requires at least 147 bytes so an average of 240 bytes per transaction is not possible unless the average number of inputs is less than 2.  While some transactions may have one input on average they are going to have more.   The total number of inputs in the blockchain will roughly equal the the total number of outputs.  As the number of blocks approaches infinity the ratio of inputs to outputs in a well functioning blockchain will approach 1:1.

Since most outputs will eventually become inputs it makes more sense to look at block capacity using a balanced transactions as a template for transaction size.  A balanced transaction is one where the number of inputs equals the number of outputs.  Single input, single output exceptions are both rare and have limited use.   A 2 input, 2 output transaction using all compressed keys and P2PKH scripts is typical and weighs in at 373 bytes.  At 373 bytes per transaction and 1MB per block the network will not exceed 4.4 tps..  This is already 37% less than claimed but it is still unrealistic as it represents the smallest possible balanced transaction.

Most transactions are going to be larger than 373 bytes due to the use of uncompressed keys being used, more complex scripts, and more inputs and outputs per transaction.  Looking at the last million transactions in the blockchain I found the average txn size was 560 bytes.  At 560 bytes per transaction and 1MB per block the network will not exceed 3.0 tps.  So we have already lost over half of this claimed capacity but this is very likely to decrease over time as transaction sizes creep higher.  Multisig and other more complex scripts are being used more frequently and that trend will continue.  A good estimate for the network throughput when limited to 1MB blocks would be 2 to 4 tps depending on how optimistic you want to be.

Here is a direct comparison of the combined script size for some different types of scripts.  The scriptPubKey is encoded in a transaction output and the scriptSig is encoded in the transaction that "spends" that output.  Since outputs eventually become inputs in new transactions the combined size of the scriptPubKey and scriptSig represents the "roundtrip" script cost of a transaction.


How many transactions are possible per megabyte of block capacity?  Below is a the maximum capacity of the network at various average transaction sizes.  Realistically 2 to 4 tps is all that is supported by a 1MB block and the lower end of that range is a far more likely.

This same metric also applies to larger blocks.  Advocates of larger blocks will often overestimate the capacity of larger blocks.  It is realistic to estimate getting 2 to 4 tps per MB of block space regardless of the block size. If all blocks were 20MB that would provide a realistic throughput of 40 to 80 tps not 140 tps.  Still 40 to 80 tps would be sufficient for 100 million users to make one or two transactions per month.

1MB can not support a sufficient number of direct users even if transaction frequency is very low
One argument made by those favoring the cap is that Bitcoin doesn't need to be used as a transactional currency to be successful.  Users could primarily acquire Bitcoins as a way to secure store of value (savings) and continue to use other currencies for routine purchases.  Bullion and other stores of value have a much lower velocity than transactional currencies.  This means a block of the same size could support more more users.  While the user of a non-transaction currency may not make dozens of transactions a day, meaningful access would at least require access on the order of dozens of transactions per year.  If your savings or brokerage account restricted you to only one deposit per quarter and one withdrawal per year I don't think you would find that acceptable.  Future users of Bitcoin will not find it any more acceptable if they are forced to transaction as infrequently.


As you can see even with an average transaction frequency of just once a week or once a month the network can't support more than a token number of users.  When someone advocates a permanent cap of 1MB what they are saying is I think Bitcoin will be great if it is never used by more than a couple million users making less than one transaction per month.  Such a system will never flourish as a store of value as it is eclipsed by alternatives which are more inclusive.  To support even 100 million direct users making an average of one transaction every two weeks would require a throughput of 82 tps and an average block size of 20 to 40 Megabytes.

1MB doesn't can't even keep up with existing non-retail payment networks.
Going back to that coffee meme, the implied message is that 1MB is fine unless for everything else.  You know substantial stuff like paying your mortgage, business deals, major capital expenditures, or paying a supplier for inventory.  This just isn't the case though.  Do you know anyone who pays for coffee with a bank wire? The FedWire service (run by US federal reserve) processes ~150 million bank wires annually.   The FedWire service only operates in the US.  Internationally the largest clearinghouse is SWIFT and it processes more than 5 billion transfers annually.  The US ACH network is even larger with 19 billion transactions annually (excluding converted checks).  There are also about 2 billion international remittances annually (western union, moneygram, and other networks).  A 1MB restricted Bitcoin network couldn't even keep up with these transfer networks even if you forget about retail sales completely.  The idea keeping the 1MB restriction, only keeps limits the utility of small payments is simply incorrect.


On a transaction fee basis.
Currently the cost of the network is roughly $300 million annually. The users of the network are collectively purchasing $300 mil worth of security each year.  If users paid $400 million the network would be more secure and if they paid $200 million it would be less secure. Today the majority of this cost is paid indirectly (or subsidized) through the creation of new coins but it is important to keep in mind the total unsubsidized security cost.  At 2 tps the network the unsubsidized cost per transaction would be about $5. At 100 tps it would be $0.05.  If Bitcoin was widely adopted, more users purchasing more coins should mean a higher exchange rate and thus the value of potential attacks also rises.  The future cost of the network will need to rise to ensure that attacks are not economical and non-economic attacks are prohibitively expense relative to the benefit for the attacker.   It may not rise linearly but it will need to rise.   If someday one Bitcoin is worth $10,000 and we are still only spending $300 million a year on security we probably are going to have a problem.  Now advocates of keeping the limit may argue that the majority of the network cost won't be paid by fees for many years but the reality is that with a low maximum transaction rate you can choose either much higher fees or much lower security.

Conclusion
Restricting the size of blocks to 1MB permanently is great if you are a major financial services company.   You could co-opt a very robust network, act as a trusted intermediary and force direct users off the chain onto centralized services.  For the same reasons, it is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary.

On edit: fixed some typos.  Cleaned up some poorly worded statements.  Yeah there are a lot more.  It is a work in progress.

I approve this message!

This makes me a bit scared, I had always figured in the future we would be allowed to use the blockchain and create transactions as we take for granted today. If we don't raise the block size, the competitiveness for transactions would be insane, I had always figured this but never had I imagined a scenario that we would never be able to move any coins.

Yes, and it doesn't stop at 20MB either, I just hope people will stop crying about progress.

Did you cry as much about the upgrade from 32bit to 64bit operating systems?

Or from 1.44 MB floppy disks to 200 MB CDs?

I mean you can fit the current blocks on a floppy disk, maybe even two blocks if you're lucky.

If Bitcoin really catches on we will need block sizes of a gigabyte or even more.

20 mb is nice for a start, it will last as a year or two, three maybe, but it will need to be upgraded eventually as well. We are dangerously close to our limit with 1 my and we can't stay at 1 mb.

Miners can choose to include or exclude transactions regardless of block size.

A miner can decide for himself if a no-fee transaction is worth including, or a low-fee transaction for that matter.

If a lot of miners agree a low fee or no fee transaction should be excluded, it will take a long time before a transaction will be picked up by a small mining pool.

Miners also need to consider that excluding low fees will mean that the miner pools that do include the low fees will process more transactions (because all the low fee transactions will stack up) and it could be thousands upon thousands of transactions and thousand times a small fee can become quite a large sum.

It's better to sell 1 billion screws and make 0,01 cent profit on each of them than to sell 1 Lamborghini and make $100000 in profit.

Very nice post, D&T. I think it's the most clear argument I've seen presented in favor of larger block size.

You don't get it, there won't be any Bitcoin to mine if we limit the system to 2tps.

Also, people don't pay for taxis because taxis are limited, people pay for taxis because they need a taxi. And the taxi price is decided by the taxi drivers themselves.

Based on gas prices, wages, wear of the car, etc. it's not so high that competition will eat away their profits by offering the same service cheaper, but not so low that they can't make a living.

Same with miners, their fees (which they can decide themselves) can be very high, but then very few transactions will be solved by that miner because very few people will want to pay a lot to make sure their transaction is included within the next block for 100% certainty. But if you put it too low than you can't make a profit anymore. So each miner and mining poo, should decide for themselves how the a fee should be before they include it in a block.

It's better to make 0,01 Bitcoin per transaction on fees on 5 million transactions per block than to make 1 Bitcoin in fees on 2400 transactions in 10 minutes (because more transactions will not fit)

If you don't even understand this simple fact I'm done arguing with you.

Btw I used to be a miner and I would still be one, except black arrow never delivered. So I am done buying miners becaus they either arrive late or never arrive. And besides the cost of electricity in Europe is ridiculously high so I wouldn't be able to compete anyway.

Thank you for reminding me that there are still a few sane individuals on this forum.

http://www.reactiongifs.us/wp-content/uploads/2013/08/picard_clapping.gif

A great detailed post as usual D&T.

Yes, I think the 7tps was meant as a technical maximum assuming 1 input and 2 outputs (1 to destination, and 1 back for change) for 225 bytes.

I agree 1MB blocks unnecessarily hinder Bitcoin, and although I don't see much difference in the potential for global value between 10tps and 20tps, seeing as VISA alone does 2,000 tps on average, I've revised my signature advertisement down from 7tps ;)

There needs to be a consideration of chilling effects, or otherwise, upon ancillary technological development that is directed towards the current rules, when even merely discussing changing the rules.

I'm still using floppies, I don't know why anyone would think they are obsolete.

But I still need to upgrade my operating system, so I think this will be a long night.

https://i.imgur.com/94GFNGX.jpg

Thanks for this. Bitcoin needs to scale and increasing the block size limit should part of that roadmap.

That is not true, Windows 8.1 is not officially offered on the medium of floppy discs.  Those discs are not genuine.

You must be the toast of every party. :P

Are you telling me I just got scammed? </sarcasm>

Great post D&T. As a miner raising the block limit is the next best thing that can happen after a moonish exchange rate.

Great post.

Perhaps the best way to deal with the transaction limit, so it does not continue to be a problem, is to quadruple the block limit size at each block reward halving every 4 years.  This should put in in line with Moore's Law, such that running a full node won't be out of reach of the average user.

Thank you for expressing what many of us knows intuitively, but lack the technical articulation to bring the argument to full fidelity. Wonderful stuff.

the sad thing is, you're probably not even the most stupid person i have met on these forums.

http://cdn.smosh.com/sites/default/files/bloguploads/meme-yds-20.jpg

I like the simplicity of this strategy and it has grounding in practical limitations for physical hardware.

Although I would suggest to have it at the midway points between halvings so as to smooth out any lumpiness in the response to fees/reward when changing the halving and max_block_size increase together. Analogous to presidential and mid-term election cycles.

So quadruple max_block_size at 315k, 525k, 735k, 945k, thereafter every 210k blocks. But need to begin with a one-off quadruple increase to 4 MByte ASAP (to account for previous increase that would have ideally happened at 315k).

Edit: on further thought maybe doubling every 105k blocks is less disruptive again, instead of banging the limit every so often. So a one-off quadruple to 4 MB ASAP then double to 8 MB at next halving (420k blocks) and double every 105k blocks thereafter, i.e. double approx. every 2 years, more or less, depending on hashrate, which is a rough proxy for network demand via price.

yeah, sounds good.

the actual numbers and frequency could be tweaked, but the idea seems good.

This prevents us from having to hardfork it every time.

Great post obviously.

As for what to replace the 1 MB anti-spam restriction with, I think Gavin's proposal is very good:

http://gavintech.blogspot.ca/2015/01/twenty-megabytes-testing-results.html


Instead of sudden and massive block size limit increases every two or four years, it would increase a little every block.

Excellent post. This was very clear and the best 'pro' argument for the fork. It pretty much squashed any of those ridiculous (no, we have not had a real 'anti-fork arguments) in the other thread.
It's nice to see that we still have a few very intelligent individuals.

my point is: the chain is already pretty big. If it becomes 20 fold as big i will be forced to stop using bitcoin because i don't want a lite-client or rely on 3rd parties with my coins but on the other hand can't afford upgrading harddrive all the time (especially not with these bad btc prices).

If you raise blocklimit 20-fold it will become unaffordable for normal people to store the blockchain on their computers and because of that people loose access.


On a sidenote:
I am not the only one totally annoyed by how bitcoin behaves in an effort to keep the dominant position and be the 'one coin for all' and with this hurts the alt-industry. I think at this point it becomes inevitable to start using more than one chain and stop looking at btc as the only coin worth bothering with.
All the problems dissolve at exactly the moment we accept a multi-coin/chain solution.

according to OP, if i understand right: if we don't raise limit little people loose access (i doubt it)
BUT raising the blocklimit will also ensure little people to loose access.
Conclusion: one blockchain for everyone is no viable idea

With raising the blocklimit and creating a chain as big as 200gb and more as soon as 1 or 2 years down the road bitcoin won't be able to reach the enduser.

Why does everyone believe that raising the block limit will instantly raise the blockchain too? It will not. It will take time until that will happen!

D&T, a very informative OP.

Empirically, ~1MB blocks support 2.7 tps.

https://bitcointalk.org/index.php?topic=941331.msg10360199#msg10360199

Agreed, and thanks for the taking the time to thoroughly explain and hopefully set some people straight on this.

[...but dang, I was scared for a second after reading the post title but before the post content had loaded :) ]

"Conclusion

The blockchain permanently restricted to 1MB is great if you are a major bank looking to co-opt the network for a next generation limited trust settlement network between major banks, financial service providers, and payment processors.   It is a horrible idea if you even want to keep open the possibility that individuals will be able to participate in that network without using a trusted third party as an intermediary."


great post.

yes, my answer is on the other thread. No idea why OP needs to open third thread on the same issue and can't just post his view on the other thread. Probably he feels important enough to open a new thread (he must be extraordinary important) . Maybe i open another one for the same topic with my personal views ... maybe just everyone should open their personal thread for this.

^ I would say this guy doesn't want Bitcoin to succeed


Anyway, it deserves to be said again: great post by D&T. This is basically the definitive counter to arguments from supporters of a permanent 1 MB restriction.

^^^

i would say this guy is a sheep

It's spelled lose.

and you rather wait for 30 years before your transaction gets through? Because that's what will happen when you keep the filesize at 1 MB


Allowing altcoins is opening a can of shit, if we just keep inventing and embracing new altcoins all the time, everyone would just print their own coin and how exactly would that be different from every nation issuing their own fiat currency?

Bitcoin is valuable because it's limited, deal with it. No other coins need to replace bitcoin, and if bitcoin is not suitable, we update it. And that's exactly what will happen, bitcoin will get an update, and it will be updated again and again until it is perfected. Just like every other piece of technology, including the internet.

Technology adapts, technology evolves, technology changes, get used to it. The only constant in the universe is change, you either change with it and adapt, or you get left behind.


little people will lose access to the blockchain if we KEEP the limit at 1 MB because the 4 tps or something will never be enough to cover even a fraction of the transactions. You'd need insane amounts of fees to get included in the blockchain, more than any individual could ever afford.

We are currently siting at an average size of about 0.4 MB (so we are not at our limit yet) and it's not being spammed to be full, which is good. But there's not a lot of room left for growth.

40% may not seem like much, but under exponential growth, it's getting dangerously close. And with things like this you really don't want to wait til the last moment.

Also, it's just the LIMIT that increases, it doesn't suddenly increase the ACTUAL size 20 fold, it just increases the MAXIMUM POSSIBLE size 20 fold. So it gives us a little more breathing room, nothing to be scared of.

and lastly, harddisks are very cheap nowadays, and will only become cheaper.

what does it matter if the blockchain is 30 gb or 500 gb? It's not like 2TB harddisks are expensive or anything. Still cheaper than a safe.

Or do you really trust the banks with all your money? See if they don't run off in the event of the next economic collapse? Think the government will bail them out again? With what money? They can't really raise the taxes any higher you know? Not without civil unrest anyway.


I bet you're one of those guys that keep complaining about phone batteries getting smaller, while in reality they get bigger (capacity-wise anyway), but it's all those extra functions that drain the batteries faster than they can create more powerful batteries.


You had time to post this, but you couldn't just quote yourself here?

I bet you're afraid that we will come up with counter-arguments to it, because you probably realize you are wrong but you're not man enough to admit it.

The OP gives a valid technical argument for raising block size limit, but is neglecting a financial argument against it.

The miners' income has to be greater than the cost of their work. Miners' income is inflation now, but is expected to be replaced by fees,
since inflation halves every four years. Purchasing power of new coins might be sustained for a while but must converge to zero in the limit.

Transaction fees exist only because there is a competition for block space. Eliminating that competition eliminates the fees and with that mining.

Therefore block space has to become and remain a scarce asset.

I guess you were referring to this one.

even though we never reached over 50% of the maximum blocksize yet, the block sizes vary wildly per block, and grow pretty much exponentially.

Also, we are at about 30% consistently right now.

If it keeps growing at the same rate as it has now, it may very well take a little over a year before we really need the upgrade, but what if it doesn't? What if we get another rally next month, or in two months? Another rally will surely come with an increase in transactions, a massive increase, as can be seen from the charts. And since we are already using about 30% another rally will likely need more than 1MB.

It will not need 20MB, but while we are at it we may as well give ourselves some room.

If we keep the 1MB limit, the next rally will kill bitcoin, because the transactions will be too limited, the network will clog, and people will blame the blockchain technology for it.

And we may very well never get a second chance to do it right.

and all those other blockchains are so small because NO ONE USES THEM

growth is a GOOD thing, more size means more transactions means more users means more value.

200GB of hard disk space costs about $10, making it the cheapest upgrade you can possibly get. Though if your system is so cheap that 200GB of hard disk space actually counts as an upgrade, one has to wonder how you ever managed to run a full node on it in the first place.

You must be able to broadcast that huge block to most of the nodes in 10 minutes. I don't see the latest research regarding this area, but there is a paper from 2013

http://photo.mystisland.org/propagation.png
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf

Based on this research, it took 0.25 seconds for each KB transaction to reach 90% of network. In another word, a 1MB block will take 256 seconds to broadcast to majority of nodes and that is 4 minutes

When block size reach 10MB, you will have a broadcast time of 40 minutes, means before your block reach the far end of the network, those nodes have already digged out 3 extra blocks thus your block is always orphaned by them. And the whole network will have disagreement about which segment have the longest chain, thus fork into different chains

Gavin's proposal is to let mining pools and farms connect to high speed nodes on internet backbone. That is reasonable, since the propagation time is only meaningful for miners, your transaction will be picked up by the mining nodes closest to you and if those mining nodes have enough bandwidth, they can keep up with the speed. But anyway, how much bandwidth is really needed to broadcast 10MB message in a couple of minutes between hundreds of high speed nodes need to be tested. And this is the risk that someone worried about the centralization of mining nodes: Only those who have ultra high speed internet connection can act as nodes (I'm afraid that chinese farms will be dropped out since their connection to the outside world is extremely slow, they will just fork to their own chain inside mainland china)

like i have said before in this very thread, it's better to sell 1 billion screws and make 0,01 cent profit from every screw than to sell 1 Lamborghini and make a profit of $100000 from that single sale.

bigger blocks means more transactions which means MORE FEES.

not less fees, MORE fees.

it's a GOOD thing for miners, not a bad thing.

Imagine if you owned a taxi business, but no matter how many taxis and taxi drivers you have, you are only allowed to transfer 500 passengers a day, period. You could own a million cars and a million drivers, but you would still only be allowed 500 passengers. There could be a major sport events like the superbowl or the champions league, 100,000 of people could be waiting for a taxi ready to pay but no, you can not take more than 500, why? because protocol said so.

The blockchain works by supply and demand, and supply is made by the miners themselves, not by some dumb hardcoded limit.

If the miners think 0.001 fee per transaction is too low, they are free to deny those transactions. But they should deny transactions just because 'lol the block is full'

You assume that miner can effectively control supply. This in absence of a block size limit is only the case if they are building cartels, that artificially limit the supply.

Is that you really prefer instead of an algorithmic decision?
Remember Bitcoin's promise is to operate without the need of cartels and authorities.

^ Did you read the entire post? The OP fully addressed the effect on fees:

To clarify... Suppose there are 5 transactions:

#	Fee	Size	Fee per 256 KB
1	0.1	512KB	0.05
2	0.1	512KB	0.05
3	0.05	256KB	0.05
4	0.05	256KB	0.05
5	0.01	256KB	0.01

Now with the 1 MB limit the miner can, at most, earn BTC0.2.
With a 20MB limit the miner can earn BTC0.31. More than 1.5x as much as with the 1MB limit! Did their cost increase 1.5x? I don't see that. I wonder which fork miners would pick...

oh but you can.

the miners decide which transactions are valid and which are not.

you can make your own rules about which fees to accept and which fees not to accept. You can even ban individual transactions or addresses if you want.

I'm pretty sure there's also a way to make your own limits to the size of the block you want to solve, as long as it's not bigger than the hard-coded limit.

As long as your block is considered "valid" by the rest of the network you decide the rules about which transactions you accept and which you dont accept.

If you have sufficient power as a miner, you can have a pretty big influence on the fees. And any miner who's not stupid will ask for at least a small fee. Or like make something like a 250KB limit for 'free transactions' and reserve the rest of the block for transactions with fee, the more fee the more priority, something like that.

be creative...

just because there's the POSSIBILITY of 20MB doesnt mean you HAVE TO use it.

There's not even a need for cartels, but each miner/pool will set their own limits based on some calculations.

Do i really need to do all your thinking for you?

Calculations would be roughly based on

• how much electricity does mining cost for me?
• how much $/kWh in my area?
• how much transactions are in an average block lately?
• how many blocks do i solve (or more likely does your pool solve) per hour
• how much of a % do i influence the pool?
• how much is the block reward if any? (and how much does it cover the cost of mining?)
• how long does this mining equipment stay competive
• how much did my equipment cost and how much will i need to profit to invest in new one
• overhead costs

weight all those factors against each other and you can make a rough estimate on how much fees you should ask for an average transaction.

now let's suppose we're far into the future and we rely mostly on fees as opposed to block rewards.

lets also assume there's (for simplicity sake) 8 large pools controlling a majority of the mining. (not to say this will happen but just to keep the calculations easy).

Pool A asks for a fee of 1 bitcoin minimum. and controls 25% of the network
Pool B asks for a fee of 0.001 bitcoin minimum and controls 5% of the network
Pool C asks for a fee of 0.005 bitcoin and controls 10% of the network
Pool D asks for a fee of 0.003 bitcoin and controls 10% of the network
pool E asks for a fee of 0.5 bitcoin and controls 15% of the network
pool F asks for a fee of 1 satoshi and controls 10% of the network
Pool G asks for a fee of 0.01 bitcoin and controls 15% of the network
Pool H asks for a fee of 0.025 bitcoin and remains the remaining 10%

now if i would want to sent a transaction and be absolutely sure it gets confirmed 6 times within the next 6 blocks (which should take about an hour) I should add a fee of 1 bitcoin.

However, if i'm satisfied with a 75% chance of waiting for a block i just add a fee of 0.5 instead.

If i am satisfied with a chance of 60% to have to wait a block, i'd add a fee of 0.025 and so on.

Of course as the user I don't know exactly what the miners ask in fees, so it's a bit of trial and error. But most users will add a fee that proved to work for them in the past.

Many large transactions or transactions that NEED to be processed fast will likely have a higher fee to ENSURE a fast transaction (some miners only accept large fees) smaller transactions (which will be more plentiful) will add lower fees, risk waiting a little bit longer.

The miners who accept smaller fees will process more transactions and the sheer volume of transactions may actually add up. But the few big transactions that the other pools sometimes pick up may also bring in some large chunks of fees from time to time.

There's no need for a hard-coded limit, fees will come in anyway, and you can make your own rules.

He neglects that there is no reason to pay fees, if there is no limit on supply.


Since there is no marginal cost in including a transaction to the current block, a rational miner will always include a transaction with a non zero fee,
before it is included by any of its competitors.

Therefore a lower bound on fee will not work without a cartel or without a competition for space.

I prefer algorithms over cartels.

I don't know how you come to those assumptions based on that research.




The do not mention the average size of blocks they measured. Let's assume all their blocks were 0KB. 12.6 seconds for that. Add 80 ms per addicition KB.... 80ms * 1024 * 20 is about 27.3 minutes. Add the original 12.6 seconds... Roughly 28 minutes for 20MB.

Of course, 28 minutes is still long. That is based on 2013 data. I assume the nodes now will have improved their verification speed and have more bandwidth. New measurements could / should be made to verify that propagation speed will not become an issue.

let me be more precise:
There is a marginal cost implied by block propagation speed being proportional to size and propagation being proportional to orphan rate. There is also a computation cost of updating the merkle tree and updating miner with it. These marginal costs are today however magnitudes below the lowest non-zero fees paid.

then why does a transaction with a 1 satoshi fee take longer to process even though we are not at our limit yet?

explain me this.

Because majority of miner nowdays use the bitoin core as published by the devs and that compiles blocks following a mix of commercial and alturistic rules.

Majority of miner do not care about this since inflation provides three-four magnitudes higher income than fees at the moment. They will. And this discussion is about the future and the limits.

I see, so rather than doubling the size of the bitcoin chain you'd rather have two chains half the size?  How is that a win?

Since I so often see the argument about, what is good for the miners:
Is there any statement from the large mining pools about this?

well, in the future miners will either adapt and make their own rules, or leave the mining industry because they are too broke to continue. And smarter miners will take over.

judging by your post, you'll be one of the broke ones, because you're too lazy or stupid to make your own rules.

it's the miners that make the rules, not the protocol.

but the protocol should not be a hard limit, because that would just destroy bitcoin.

I'm not going to waste my time thinking of more examples to point this out, i have better things to do.

You know much less about Bitcoin that you think. I hope you have better things to do.

Miner do not make the rules. They have to obey the rules if in minority or can narrow existing rules if organizing a majority cartel.
The later would be needed to impose a non-zero fee in absence of a size limit in the protocol.

It IS in fact a win - coins are easy to convert in many different ways within splitseconds. How is it a loose? From an economic standpoint it's not a loose. Say the coffeeshop accepts 'Bitcoin' but i do use xyz-coin. The conversion is a mere formal act. I can pay the coffeeshop in xyz-coin and the shopowner gets the coin he wants (gavincoin or whatever). Crypto is easy enough to convert for this to have no economic impact. All it takes is an exchange-app, and i think it could already be developed or even exist already (would need to check)

With multiple smaller chains the enduser doesn't loose souvereignity to too high hardware requirements.

You could in fact even merge mine them.

The individual user would not be required to store Terrabytes of data and have extreme bandwidth like he would be with Gavincoin.

How is requiring everyone to potentially store terrabytes a win?

---
This scenario is what will happen most likely anyway once running Gavincoin becomes unaffordable for the enduser.

Your second and third paragraph contradict each other.

Transaction fees don't ONLY exist because there is a competition for block space. They ALSO exist to pay the miners to secure the network, as you clearly understood before you implicitly denied it. Fees are not an either/or thing. It absolutely ISN'T a case of lifting block limit->eliminates fees->eliminates mining.

We have instead a *feedback* process. LOWER fees (not ZERO fees) means LESS mining (not NO mining) which in turn means LONGER confirmation times (not COMPLETE COLLAPSE) which leads to MORE FEES which leads to mining power switching back on. It's what engineers call a negative feedback loop, designed to keep the hashing rate broadly stable, or at least oscillating within a fairly narrow range.

People really must stop thinking of all the causes and effects in the world as being ON/OFF switches. They aren't. They're analogue dials.

[If you're on board with the idea of bitcoin, you've probably had to deal with people saying a deflationary money supply can't work because NOBODY would ever spend ANY MONEY AT ALL. Same problem. "Less" is not the same as "none". Especially when "Less X" induces "Less Y" which induces "More X".]
 

you just assume all miners will allow a low fee, but that simply won't be the case.

because it's not sustainable.

for the same reason taxis do not offer free rides, and shops dont offer free products.

like i explained before, you need to calculate a lot of factors, and then decide a cut-off price. And all the miners who dont do that once the fees start to matter more than the block reward will go bankrupt and will be forced to stop.

just because the transaction itself doesnt cost anything (or barely anything) doesnt mean it's free.

Everyone understands that at some point transaction won't be free, because miners need compensation for their power and other costs.

The thing you refuse to understand is that it's better to spread that cost over 1 million transactions per 10 minutes than on 1620 transactions (which, based on empirical evidence is about the limit of the current blocksize).

Because if you spread the fee over just 1620 transactions, the fee would be ridiculously high and would never be able to support the network, but if you spread it over a million transactions it will be very cheap. But you wont be able to spread the cost over a million transactions because it simply would not fit in 1 MB.

You were talking about the future, so think about the future. If bitcoin still has only 2 transactions per second on average by the time block rewards are insignificant, bitcoin has failed, and this whole discussion is pointless.

Are you really this stupid or are you just trolling?

by the way if miners dont make the rules, who do?

you really dont get it do you?

even if we ignore the legion of premined scamcoins, we still have the following issue:

Suppose we use 4 different altcoins

Acoin has a 10 GB blockchain in this example
Bcoin has a 5 GB blockchain
Ccoin has a 20 GB blockchain
Dcoin has a 15 GB blockchain

now how exactly is that better than having 1 blockchain of 10+5+20+15=50 GB?

If you are going to store them all anyway, it doesnt matter if you have 1 blockchain of 50 GB or many smaller ones adding up to 50.

In fact, having multiple blockchains means you have a lot of extra redundant information and applications running, it's less convenient, less secure, etc. It only brings more problems and it doesnt solve anything.

Why am i even explaining this....

So now that you've moved the goalposts (first it was: "he doesn't address fees"), I need to correct you again. The OP never advocated for there being no limit:


A limit with thousands of tps will undoubtedly produce more fees for miners than a limit capping the network at 3 tps.

Oh another thing: re the concern about a huge blockchain size...

Increasing the block limit isn't the only thing Gavin and co have been giving a lot of thought to. They've also understood the (complementary) problem of blockchain bloat. I'm given to understand that several blockchain pruning schemes are out there. Note these are NOT the same idea as 'lightweight' or SPV clients. They're genuine info compression schemes. I haven't followed for a while, but one scheme I heard basically suggested that *on disk* the blockchain information up to the 'current block #X' should essentially be split into three parts:

1) A chain of block headers only up to block #X-N, where N might be a couple of thousand.
2) A database of UTXOs for all the blocks up to #X-N
3) A complete sequence of the last N blocks

The header-only chain provides the proof of the next block's valid membership of the chain. It grows linearly for ever more, at a rate of ~(640*6*24*365)/(1024^2) = 32 MB a year. Which is peanuts.
The UTXO database grows more unpredictably, but I guess broadly proportionally to global bitcoin usage. It's there so the node knows who's got what and can verify new transactions are valid.
The uncompressed sequence of the last N blocks, where N might vary by individual preference, remains fixed length for a fixed blocksize. The node keeps the last N rolling blocks uncompressed in case there's a fork.
Even if the blocksize grows, so that this tail of blocks grows, it's unlikely to gum up disk space. If it does, the node could choose to reduce N (I pick N=2000 as rather overly cautious).

Anyway TLDR: disk space is NOT a problem. Can't comment much on network propagation issues, except I'm led to believe these can be addressed by an approach such as 'send the header first, then the block info separately'.

How do premined scamcoins even matter? They don't.


Let's go out in the future 5 years from now:

Gavincoin: 1.5 terrabyte storage requirements
Mpcoin: 70GB
Acoin: 10gb
Bcoin: 20gb
Ccoin: 5gb
Dcoin: 1gb


you don't store them all - especially not gavincoin. You store two or three maximum. Those that are most according to your usecase of crypto.
So your assumption everyone would store all chains is wrong of course. Different people use different coins for different purposes and will use different chains according to their preferences.

a,b,c,d,e coin can still be merged mined with the strongest network (which one that will be remains to be seen) - so a,b,c,d coin are almost as secure as the network they merge mine against.

Almost nobody will use a coin that requires such insane hardware as Gavincoin will.
Once this is understood there's going to be a lot developement towards efficency - Gavincoin is a proposal for a waste of systemrecources and therefore it won't be able to compete with more efficient coins in the long run.

If in any case i would be required to use Gavincoin i can still convert my a,b,c,d,e coin in splitseconds to it.

Not the coin that's the biggest bully and has the most vocal support wins but the coin that's most efficient. (not even network effect and merchant adoption are as important as efficency in the long run)

So fork it all up, fools. Do it right now!

Possibly one more ...
"Have you ever thought about the fact that you send a bank wire yourself."
Did you mean to instead write "that you can't send a bank wire yourself."?

That's probably the best argument I've seen.  I think of how today I have many paper wallets, mobile wallets, and hosted (shared) E-Wallet services (i.e., custodial services) where I had a balance of a few millibits or less in them and won't (or can't) withdraw because the Bitcoin network transaction fee is prohibitive for that small amount of bitcoin.    Now as fees rise due to scarcity of empty space in blocks then I'll essentially have permanently abandoned those wallets with the small values (i.e., those funds become economically unspendable, ... worthless!).

I suppose for the paper wallets and mobile wallets where I have the private key I could combine them into a single transaction without incurring a higher fee, but that's possible only today because there's still some low-cost space left and the fee required doesn't rise linearly when the size of the transaction rises.   Without a fork then eventually we are essentially paying a fee for each additionally byte and the resul will likely be that millions of UTXOs with small amounts (e.g., sub-millibit -- less than 0.001 bitcoins) will become worthless.   Hey now,  that's some real money we're talking about discarding!  [Anyone care to crunch the numbers -- what is the sum total of bitcoins that exists in UTXOs under one millibit?)  

It makes me think back ... First they came for the dust, and I didn't speak out because I didn't play SatoshiDICE.    When this day comes (when the 1MB cap is reached, and no-hard fork), maybe a millibit becomes the new dust!   And then let's say the fee required rises even more, maybe UTXOs under 0.01 even become economically unspendable.    That becomes a real problem for most of us!

So what to do?
I'ld like a Bitcoin that can scale and grow with transaction demand.  I'ld also like my car to get 150 MPG.  The latter can't happen simply because a gallon of gasoline doesn't have the energy needed for an internal combustion engine to propel today's car for 150 miles.  Now I'm not entirely convinced the former can happen either.  That's because a hard fork that doesn't have the consent of the Economic Majority ( http://en.bitcoin.it/wiki/Economic_majority ) will fail.

Let's go through the first hours of the hard-fork.  Let's say it happens at block 400,000 (a lttle over a year from now).  Everything was in place -- miners with the right nVersion indicating consent was well above the threshold (e.g., 80% of last 1,000 blocks had nVersion=4).     But ..., I'm not willing to believe that exchanges, merchants, merchant processors, etc. are going to themselves take on the full risk of double spending that would occur if the hard fork eventually fails (maybe a day or three later even).   The only way to prevent the double spending that would result would be to require that a transaction confirms on the block chains on both sides of the fork.  So these entities are going to watch both sides. Well, a transaction that has any taint from a coin generated on the side with the larger block size rule change (I hate calling them "gavincoins", but for the purpose of this argument that name is short and everyone here knows what it means) will not confirm on the other side of the fork where the 1MB limit is still followed.

So the market instantly realizes this difference between a Bitcoin and a GavinCoin.  So the value of a GavinCoin will drop relative to a Bitcoin.   Miners can't convert or spend these newly mined coins nearly anywhere, so all you have is buying from speculators.   Now those mining on the side which still recognizes the 1MB max limit are still mining blocks (albeit at a much slower rate because of the dramatic loss of hashing capacity) and some market for those newly mined coins exists -- again, thanks to speculators.    Things can flip quick.  Maybe a day goes by and all of a sudden a large amount of hashing capacity switches back to the 1MB max side due to the dropping exchange rate of GavinCoin, and it becomes quite possible (if not probable) that the 1MB limit will be with us for some time longer.

The exchanges and merchants that played both sides (i.e., required confirmations on both sides of the fork) lost nothing as either way they have confirmed transactions on what is eventually the sole winner.   If the hard fork fails then the losers are those who had E-Wallets (custodial accounts) and found their pre-fork bitcoins were spent and they only end up with tainted GavinCoins that can now never be spent (at least not anywhere near parity with a bitcoin).   Likely most every custodial service (e.g., exchanges, hosted/shared eWallets, etc.) that didn't require confirmations on both sides of the fork ends up bankrupt as a result of getting dumped on with GavinCoins while allowing withdrawals of untainted bitcoins.

I just don't see how a hard-fork succeeds.   There is risk of accepting GavinCoins.  There is no risk (excluding exchange rate risk) of putting your own pre-fork coins into storage for a (long) while and not letting them become tainted GavinCoins (as they can still be spent a year, two or ten later).

[Edited: A couple small readability changes.]

Really glad to see this stupid conversation laid to rest once and for all.

All trolls/ vested interests now please shut up..

Well said D&T .... Claps hands   ;D

We still have people thinking that increasing the block size limit by a factor of 20 will increase the blockchain size by the same factor.
This is FALSE.
The blockchain will grow slowly over time. It could take us years before we reach this limit. Besides the cost per GB of storage is pretty low these days.
What would be very beneficial is including more options into the fork. If the fork happens, this could be our last one. Once we reach a few million users doing so will be almost impossible (it is hard already).

Free (literally) space will be filled, no worries. Very fast. 

Whilst I am not against raising the 1 MB limit I do think that this idea that their should be "only 1 chain" is actually rather "stupid".

The very point of decentralisation is not to have a single point of failure - yet this is constantly what Bitcoin is trying to do (set itself up as the single point of failure).

I don't see the future as being just Bitcoin but in fact numerous blockchains that you'll use if you want (making this whole storage issue really a pointless argument).

Trying to have Bitcoin solve every single problem is just silly - it will never suit all purposes and this is why we will have many blockchains.

This is why I designed AT: https://bitcointalk.org/index.php?topic=822100.0

(it allows "atomic" trustless transfers to occur across blockchains)

I am not talking about forks but different blockchains.

From the bitcoin dev mailing list quoting Wladimir van der Laan (http://article.gmane.org/gmane.comp.bitcoin.devel/6840)¹:


¹ Bitcoin core maintainer

It turns out that Bitcoin handling a significant percentage of global transactions in a couple of decades isn't that far-fetched:


Combined with the added scalability and functionality that sidechains would provide, we really can have a universal apolitical currency. The market will ultimately decide. I believe the market wants a common apolitical digital currency for international trade and commerce.

I think the ATs could fairly easily be modified to do the sorts of things you want (they are Turing complete after all and are in charge of their own funds).

Miners include transactions without fees right now because there isn't a huge disincentive to leave them out, and some pools include a certain number of free ones just because they want to.
I would imagine that charity would not extend past the fork to 20MB blocks, and miners would stop including no-fee low priority transactions in their blocks as the increased risk of an orphan without a similar increase in reward wouldn't be worth it.

However, if the network did immediately balloon out to 20MB/block with 30,000 transactions paying the minimum 0.1mBTC fee the reference client uses, that would still be 3BTC in fees, which is still more than an order of magnitude more than we are currently seeing.

Unfortunately behaviour that is wrong for the community as a whole can make sense individually and can wreck the entire ecosystem.
Economist call this the "Tragedy of the commons" http://en.wikipedia.org/wiki/Tragedy_of_the_commons

In absence of block size limit individual miner are rational to include every transaction with any greater than zero fee. This however
disables pricing power of miner to the extent that they become unprofitable and go out of business, in effect reducing utility and security for all.


I am not trolling.

You are not neccesarily stupid, but uninformed if you think miner set the rules.

A miner who violates a rule that is enforced by the majority of miner locks himself into an alternate reality (a fork) that no one else cares of.

The majority of miner can enforce new stricter rules than currently in existence, this is called a soft fork. Enforcing a minimal fee by a cartel would be in effect a soft fork.

Not even the majority of miner can introduce a rule that is not a subset of those already in existence, without getting most of ordinary user upgraded.
An increased block size is not subset but extension of the current rule, therefore it falls into this cathegory, also called hard fork.

Bitcoin's value rests on the consensus of its user of the rules. The rules are practically constant as it is very hard to convience all user to upgrade.

In case of block size interest of ordinary user and miner are not aligned. Ordinary user just want lower best zero fee. Miner have to protect pricing power.

^ The OP never advocated for there being no limit so you're criticizing a straw man proposal:


A limit with thousands of tps will undoubtedly produce more fees for miners than a limit capping the network at 3 tps.

This is only true if the per transaction fee is not zero.
In absence of a block size limit, there is no incentive to pay fee. Any positive fee would have to be enforced by a cartel of miner.

This statement is just *wrong* (and is itself a straw-man argument).

With other blockchains that also work trustlessly why on earth is anyone being pushed to rely on trusted 3rd parties?

Of course they are not (OP should fix that IMO).

that needs to occure those txs first

Yes THERE FUCKING IS.

READ, god damn you.

 >:(

There will be lots of services/people that will want to include fees for various reasons.

can someone put on a TL;DR of original post for a lazy and non-technical reader like me  :'(

But the OP is not proposing an absence of a block size limit. This is a straw man argument, and the fact that it's the second time you've made it, means you're being disingenuous.

But there IS a block size limit. It's only going to be bigger, but not infinite.

I'm just doing my part. Also I'm realizing just how limited and stubborn people here can be.
Do not answer to that guy, he is a trolling shill.

You're not just limiting the amount of transactions per block, you're limiting the development of potential services of tomorrow.

Sorry - but that makes *zero* sense (especially as I stated that I am not against raising the 1 MB limit in the first place).

This is not how Bitcoin works.
Instead: Less mining power leads to difficulty adjustment that restores confirmation time.

Lower mining income simply leads to less security that will lead to less use and less fees -> less mining power.
A positive feedback loop wrecking the ecosystem.

I misunderstood your post, sorry.
My post does however make sense, also I was referring to the like of the Lighthouse project.

Increasing the limit to avoid raising fees is in effect asking for no limit, as the reason for the limit is to ensure sufficient fees are paid.

No problem but perhaps it would make more sense if you could expand on what you posted a bit.

the tl,dr - version is here:
https://bitcointalk.org/index.php?topic=941331.msg10364386#msg10364386

What maths are required to prove that 20MB limit = no limit?

This is a valid point. As far as incentivising fees goes, a block limit that is always just a bit bigger than it needs to be, is functionally equivalent to no block limit at all.

And actually, I think I see your point that IF this were the only mechanism in play regarding how much people pay in fees, it could pose a problem. My counter is that it is NOT the only mechanism in play.

ETA: R2D221, hope this clarifies it for you too.

It's not a binary option. Raising the limit at a moderate pace, so that fees don't have to increase a substantial amount with increasing adoption, is a middle ground solution, that will lead to average fees remaining affordable but not-zero.

Well one of the 'anti' arguments is that there is time and that this should be done in the future (if at all according to them). What they do not realize that it's not just the amount of transactions for the users that are limited.

That's taken right from the FAQ of the project itself. This is just 1 example of potential services that won't be able to get developed completely (if at all).

https://www.vinumeris.com/lighthouse

They just haven't designed it right (so the Bitcoin limits are not really an issue).

Although let's not go off-topic my AT project will be launching "crowdfund" very soon and that could actually work on Bitcoin if Bitcoin were to adopt AT (with no limits for the number of pledges).

What else would make people pay a fee? I do not think alturism would pay for an infrastructure of 300 mio USD and increasing.


There are quite a few constants in Bitcoin that one could argue with, that is what we do. It is however important to do it for the right reason.
Avoid paying fees is not a right reason.

Exending on above:

It is rather difficult to substantiate an algorithm that would set course for the future, given the huge amount of unkown parameters a constant we have is preferred by occam's razor.

What else, is that the miners don't mine if it's not profitable. And it's NOT altruism to pay a fee to the miners. You can't use bitcoin without miners, so if you want to use bitcoin, you pay a fee. If you DON'T want to use bitcoin, then surely the question of whether or not you WOULD choose to pay a fee is irrelevant?

There are TWO incentives to pay fees - getting your transaction in a block, and having a bitcoin currency at all. Increasing the blocksize may attenuate the first incentive but doesn't remove the second at all.

Maybe this is an impertinent question, but isn't the main goal of lifting the max block size increasing the # of tx/s? (Avoiding raising fees is a side effect at best, no?)
And more to the point, it seems to me that 1MB limit was introduced as countermeasure against potential network flooding, am I missing something obvious?

before you reach that limit you'll upgrade to 50MB and quantitative ease another 10 million btc into existance to cover miners - that's how it'll end up. (not really because people won't even use the 20MB version)

Guys, these txs you dream up do not occure right now on the network. A large percentage of txs that do occure currently are microtransactions.
The fork proposal can be seen as a proposal to secure microtransactions with btc hashpower for free.  ???  https://forum.zeit-coin.net/images/smilies/facepalm.gif

What plausible reasons can you give for either of those assertions?

Why *wouldn't* people use the 20MB version?

Why *would* the network majority agree to create another 10 million BTC?

-you propose to raise the limit without an immediate need now - you'll do it again (what else)

- why they wouldn't use it has been explained already earlier

- the majority will have to agree on that later because mining becomes unprofitable once the inflation fades out - especially if not the number txs actually do occure what you project (in case your fortune telling skills fail, which they will)

Miners not mining does not force people to pay fee. Difficulty would decrease and transactions would confirm again with less miner.
Most would not even notice.

Some would see that security decreases, but will that make them pay more ? Not neccesarily, since their security preference is different.
Some might think it is still sufficient and continue to free ride, and if no longer, then leave for a better chain.

Again, this is a typical "the tragedy of the commons" scenario.

I don't think he's saying that miners won't mine at all, just that they won't mine no-fee transactions. Already with 1MB blocks, most pools limit the number of no-fee transactions. There is a cost to including a transaction in a block for a miner, and there's no economic incentive to do so without fees. No pool operator in their right mind would allow 20MB worth of no-fee transactions into their blocks; that doesn't mean they won't include every TX with a fee large enough to justify its inclusion.

Bitcoins current inflation rate is 9.98 % that will drop to 4.26% with block 420000, expected on 29th July 2016.

Current inflation hardly covers the cost of current mining infrastructure, as a consequence we see difficulty stalling since several adjustment cycles.

This means some combination of following needs to happen to sustain security level past block 420000 at current level.

a) Bitcoin purchasing power increases at least 2.32 fold, means to more than 506 USD
b) Transaction fees have to supply 17.14 BTC per block

We all hope that the actual outcome will be more of a) than of b)

a) is a bet
b) implies transaction fees of ca. 0.005 BTC with fully packed 1MB blocks or 0.0003 BTC fees with fully packed 20MB blocks.

Note that above would only sustain current security level.

A rational miner mines all non-zero fee transactions he sees until the block is full, since it has virtually no cost to include one. If he would not include any, he would leave it on the table for an other miner.

Imposing lower limit to fee could only be effective if miner build a cartel for that, and this is not the way of regulation I favor.

Virtually no cost to include one, but not no cost. Building a 20MB block full of 1 satoshi fee transactions would not make economic sense as the increased risk of an orphan would outweigh the benefit of the less than 1mBTC in fees.

You keep saying this but the cost is not zero.  The cost of orphaned blocks is very real.   If you increase propagation time by six seconds then the probability that your block will be orphaned increased by 1%.  Those transactions have to be paying more than the estimated loss due to increased propagation delay or the miner takes a net loss.  As margins squeeze and the subsidy declines, miners that are bad at math will quickly become bankrupt miners that will be replaced by miners less bad at math.

Another way to look at it is if you double the size of a block you double the chance of your block being orphaned however since miners include highest fee transactions first doubling the size of the block does not double your gross revenue.  At some point there is that marginal transaction where despite it having a fee it will result in a net loss to include it.  A rational miner will draw the minimum fee policy just above that line.

I stated the same. We might disagree on the magnitude.



Allowing for that rational line being above zero, the question is if that rational limit pays for the security we need to sustain. See my previous calc. on transaction fees needed.

Why not implement maximum block size alongside mining difficulty adjustment using the same mechanism?

Rather than an arbitrary 20MB limit or rolling quadruple/exponential maximum size increases, why not incorporate a self-adjusting maximum block sized based on the number of the last n blocks solved that hit the existing hard limit?

https://gist.github.com/gavinandresen/5044482

I am not sure the numbers are completely sound so I am not saying rely on them like gospel but more as a thought exercise.  I think the underlying study that Gavin relied on has some pretty worst case assumptions backed in and the average miner is probably going to be better connected than the average non-miner.  Still even assuming they estimate is 10x actual cost the idea that there is no cost is simply not supported.   A 1 satoshi fee (or even 100 satoshi fee) for all intents and purposes is a no fee transaction.

As for fees making up the difference of the subsidy cut ... they won't.  However at the current time the network is probably overprotected relative to the actual economic value of the transactions occurring on it.  Subsidies tend to do that in any market.   So over the next five years the difference caused by the two halvings will be compensated by a combination of a) some reduction in overall security, b)the rise in the exchange rate as miners costs are mostly in fiat terms, and c)rise in overall block fees.

the problem is: on gavincoin low fees will lead very fast to reaching the blocklimit again.
If the space is there and it's cheap it will be filled with one crap or another.
So reaching the 20MB limit will likely occure way sooner than most think in case fees are too low.

Gavincoin is basically a proposal for socialist central planning (first on fees and later on moneysupply)

Let me go with his assumptions implying a rational minimum fee of 0.0008 BTC for a 250 Byte transaction.

That would imply a total fee of 3.2 for 1 MB  blocks. We have not even seen that magnitude yet (exceptions were only fucked up transactions).
Means we are not even close to block size limit sqeezing out meaningful fees, so why increase it?

Because the block limit is not creating a fees market. The block reward is too high and masks the theoretical "bidding" process for block space, leaving aside the fact that wallet software does not offer users a way to update a fee on a transaction until it has been dropped from all the mempools.

However 20MB is large enough for a proper fees market to develop. Currently, blocks >900KB are carrying 0.25 BTC in fees. ~5BTC in fees for a full 20MB block and a block reward down to 6.25, means the fees and reward are similar, and the fees market should be healthy.

Turing-completeness is a non-starter.

The Bitcoin scripts were deliberately designed to not be Turing complete.

I have to admit, the 28 minute (https://bitcointalk.org/index.php?topic=946236.msg10364024#msg10364024) (thorough) block propagation time (for 20MB block) mentioned earlier does seem realistic to me. That works out to about 14 hops with each node spending 2 minutes (https://bitcointalk.org/index.php?topic=941331.msg10316299#msg10316299) on block verification. Edit: Forgot to add: Turing completeness, even with cycle limits, will obviously increase block verification time.

This lends credence to LaudaM's contention that the blocks will not fill up immediately. Though, I have seen it argued (https://bitcointalk.org/index.php?topic=144895.0) that the large miners will have an incentive to push smaller miners out with large blocks (filled with garbage if need be).


Because a change like this has to be planned months in advance. During the next bubble it will be too late to meaningfully accommodate the increased transaction volume. I suppose that may be the point: to temper speculation with high fees. The difficulty is that the institutions pushing the next bubble have the ability to print their own money (https://bitcointalk.org/index.php?topic=800330.0).

A statement with nothing to back it up (the reason Bitcoin is designed that way is because it was designed that way).

In response to those claiming that a hard fork to increase the blocksize limit will hurt the miners' ability to collect fee revenue:

The empirical data we have so far does not support the notion that the miners will be starved of fees or that blocks will be full of low fee transactions if the blocksize limit is increased.  If we inspect the fees paid to miners per day in US dollars over the lifetime of the network (avg blocksize << max blocksize), we see that total fee revenue, on average, has grown with increases in the daily transaction volume.

https://i.imgur.com/MgVxfPe.gif

The total daily fees, F, have actually grown as the number of transactions, N, raised to the power of 2.7.  Although I don't expect this F~N^2.7 relationship to hold forever, those suggesting that the total fees would actually decrease with increasing N have little data to support this claim (although, during our present bear market we've seen a reduction in the daily fees paid to miners despite an increase in N.)

Past behaviour is no guarantee of future behaviour, but historically blocks don't get filled with low-fee transactions and historically the total fees paid to miners increases with increased transaction volume.    

Sometimes I debate D&T on some issues, but not this time.  Great post. 

I agree 100%.

There will probably be a role for settlement networks in the future, but even if they do exist those settlement networks should not be artificially subsidized by a block size limit.

Fantastic work, DeathAndTaxes!

Two things really stuck out for me after reading your post:

(1) How ridiculously low the 1 MB limit is if we envision any sort of "success case" for bitcoin. 

(2) How the "don't-increase-the-blocksize-limit-because-centralization" argument is misguided.  You clearly showed that not increasing the blocksize limit could lead to greater centralization by pricing out individuals from trustless access to the blockchain.   

He didn't as he used a "straw-man" argument that people would use centralised authorities when they could just as easily not (again I am not against raising the 1MB limit but using the wrong arguments for that is simply not persuasive).

You are right there is no fees market yet, but not for the reason you state.
The block limit is not currently creating a market because it is not yet tight and bigger blocks will not be tight for yet more time.

Miners' only freedom is the freedom to exclude transactions. Can it be used to press users to pay higher fees?
Only if either

1) the space is scarce
2) supported by a rational lower limit to fee, no sane miner crosses
3) played in cartel

You want to eliminate 1) hoping that 2) holds so we do not fall through to 3)

Gaving quantified a rational lower limit to transaction fee as 0.0032/KB. A miner that includes a transaction paying less is no longer compensated for his increased orhpan cost. Miners currently accept even less, that tells miner are either dumb or the rational limit is lower. I suspect people deploying hundreds of millions in equipment would not act dumb for a prolonged time period.

Misinformation.

Space in a block is always scarce, regardless of whether or not there's a protocol limit.

The only to make space in a block non-scarce is to invent a way of transmitting data that requires zero energy, zero time, and exceeds the shannon limit.

Whether or not space in a block is scare depends on physics, not on software design.

Not.

What you describe is less than rational limit in 2.

I just took the numbers on that chart, their paper says 0.08s/KB but the chart shows 0.25s/KB, no big difference

Ideally, you would like to keep the broadcasting time below 1 minute, to make sure the network does not fork into different chains, and to reduce the orphaned blocks. Currently some connection to china is about 20KB/second, means 1MB data will take 1 minute to just reach their network. Of course china have much less nodes than the rest of the world, but they do have large amount of hashing power

For 10MB block, the bandwidth requirement will be 2Mb, which is quite high if you consider the connection over continent. Hopefully before we reach that stage the network bandwidth has been upgraded

First you start out by grossly misusing economic terms.

Then, when this is pointed out, you reply by making assumptions about theological price levels which you can't possibly calculate because they are not calculable.

what is misused and what can not be calculated?

The regression is dominated by increase of BTC value not that of fees.

A non-scarce good is one that does not require allocation because the available supply at a price of zero exceeds the maximum achievable demand at that price.

No good that requires time or energy to deliver can be non-scarce.

Including transactions in a block will always require both time and energy, therefore the space in a block will be scarce.

Because space in a block is scarce, miners will need to allocate the inclusion of transactions into a block, and there exists a price below which they will not do so.

We can't calculate ahead of time what the equilibrium price of a transaction will be in the future, because that depends on the future actions and preferences of millions of other people.

This is a bit unhinged.  The _inherent_ costs of transactions is roughly   size_of_data * decenteralization_level (actually there is a quadratic component in a decentralized network too, but lets ignore that; good design can make it small).  In a free market for transaction capacity based purely on the inherent cost optimal competition can drive decentralization down to lower costs. With a completely centralized system the cost of almost any imaginable scale is basically nothing (e.g. a single <$2000 host on a sub-gigabit network connection is able to process a hundred thousand transactions per second).

So effectively one can replace the fee market with a market that favors the most centralization as they have the lowest costs (as thats all network income would pay for).  This may be true, but it's not interesting-- since if a highly centralized system were desirable there are more efficient and secure ways to achieve one.

I believe you're making a false comparison. None of the market participants have a way to express their preference for a decentralized network except by defining Bitcoin to be one though the rules of the system. Absent that someone who doesn't care and just wants to maximize their short term income can turn the decentralization knob all the way down (as we've seen with the enormous amount of centralization in mining pools) and maximize their income-- regardless of what the owners of bitcoins or the people making the transactions prefer. You could just as well argue that miners should be able to freely print more Bitcoins without limit and magically, if the invisible-pink-hand decides it doesn't want bitcoin to inflate, "the market" will somehow prevent it (in a way that doesn't involve just defining it out of the system).

This data is massively outdated... it's before signature caching and ultra-prune, each were easily an order of magnitude (or two) improvements in the transaction dependent parts of propagation delay. It's also prior to block relay network, not to mention the further optimizations proposed but not written yet.

I don't actually think hosts are faster, actually I'd take a bet that they were slower on average, since performance improvements have made it possible to run nodes on smaller hosts than were viable before (e.g. crazy people with Bitcoind on rpi). But we've had software improvements which massively eclipsed anything you would have gotten from hardware improvements. Repeating that level of software improvement is likely impossible, though there is still some room to improve.

There are risks around massively increasing orphan rates in the short term with larger blocks (though far far lower than what those numbers suggest), indeed... thats one of the unaddressed things in current larger block advocacy, though block relay network (and the possibility of efficient set reconciliation) more or less shows that the issues there are not very fundamental though maybe practically important.

The plot shows the total daily fees in USD versus the number of transactions per day.  Indeed the correlation between the BTC value and the number of transactions per day is stronger, but that doesn't make the chart I plotted invalid.  In other words, if the network growth in the future is anything like the network growth in the past, the total fees will continue to increase along with the number of transactions per day (and along with the price of a bitcoin). 

Typical central planner hubris.
You're making assumptions about the preferences of current and future Bitcoin users which are not warranted.

If the world wants a system which can conduct transactions at the lowest possible price, then the world will not choose to use Bitcoin, regardless of what you try to shape their behaviour with arbitrary protocol rules.

If, on the other hand, there is any demand for censorship resistance and money with a predictable supply, then that demand will express itself as a willingness to pay some price to obtain it.

If Bitcoin is going to fail because there is not enough demand for what it provides that people are willing to pay what it costs to obtain it, then Bitcoin is going to fail.

If that's what's going to happen, then no amount of tampering with the price discovery process can change that outcome, and indeed will only be counterproductive to any chances at success Bitcoin does have.

Here https://bitcointalk.org/index.php?topic=941331.0;topicseen 215 forum users don't think the same :


https://i.imgur.com/waD2gPv.png

So - they could be all sockpuppet accounts (as this forum supports that).

Any poll on this forum is worth *zero* so posting the result of any such poll has *zero credibility*.

I know, we can never do a valid poll on this forum.
However I agree with the 20 MB limit, I don't think will be a problem for the bitcoiner users.

All you've done here is reinforce the fact that the design of the P2P network is broken and should be fixed, which is indeed an argument I am making, with a side order of red herring regarding the issuance schedule.

The difference between us is that I don't accept a permanently broken P2P network as a given and conclude that we should employ broken economics as a work around.

The broken economics of having a block size limit, and the broken P2P network should both be fixed.

The assertion that a fee market only works if miners act as a cartel is false.  The situation in which miners do not act as a cartel simply presents the consumer with a range of prices which they can choose among, paying a premium if they are willing to pay for high-priority or prompt service or taking a discount for making low-priority or slow transactions.

Imagine a market in which there is no cartel.  To make it simple, suppose that there are ten miners each with ten percent of the hashing power, and that the block size limit is not routinely reached.  Because they are economically rational and facing different prices for bandwidth and electricity in their respective neighborhoods, they all set different minimum-fee policies.

The consumer is faced with ten different price points for a "minimum acceptable" fee, which determines how many of these miners would accept his or her transaction.  

So... paying a minimum fee would get your tx accepted by one miner.  On average you're going to have to wait ten blocks before that miner gets a block, so your expected tx time is about 100 minutes.  Paying a median fee would get your tx accepted by any of five miners.  On average you're going to have to wait two blocks before one of those five gets a block, so 20 minutes.  Paying the highest fee would get your tx into any block regardless of who mines it, so you'll be in the very next block in around 10 minutes.  

The point is that consumers are not faced with a binary "pay enough" or "don't pay anything" choice; they are faced instead with the opportunity to select a level of responsiveness desired and pay for the priority they want or need on a by-transaction basis.  

I was already assuming a perfectly idealized p2p network that had no overhead or sub-linear scaling. I've done as much to explore the space of efficiency gains in this kind of system as any two other people combined here, come on. Please don't try to play off that I don't know how the system works. Decentralization has inherent costs.  You're not saying anything to escape that. It's not good enough to just say "broken broken" when reality doesn't behave like you wish it did.  I also wish there wasn't a tradeoff here, but it doesn't make it so. :(  (And to be clear, I think there is some amount where the costs are insignificant and not a concern and that cutoff changes over time; it's only the unlimited view which I think is clearly at odds with strong decentralization and risks disenfranchising the actual holders and users of bitcoin; people who weren't signing up for a system controlled by and operated at the complete whim of a few large banks ('miners'/pools)).

What I mean is that your perfectly idealized p2p network is still wrong.

A more detained explaination is forthcoming.


That's exactly true, and I'm not trying to escape it.

Everything that any network does has inherent costs, and every one of them in existence of which I am aware either fails to recognize this fact or else does so and does the wrong thing in response.

Looks like were concluding that doing this has also a few (potential) drawbacks. All that was discussed is theoretical as we do not really know.

I'm amazed how the thread took a turn to discussing the issues of p2p networks.

I am almost certain that if Satoshi had originally coded a block limit doubling every 2 years along with block reward halving every 4 years then this would never have been discussed or even pondered in so much questionable detail. People would be like, "Oh yeah, that's the way it works, let's just deal with now".

gmaxwell: thanks for your timely input on the necessary decentralisation quantification.

Do not forget that the hard-coded fees constants fix should be addressed simultaneously with this issue since they are inter-linked .... or we'll be back arguing about that eventually also.

This is a great explanation!
It fits the "unconstrained" block size scenario, which is how Bitcoin has worked for most of its existence, except for a day or so about March 6th, 2013, when the 250KB soft-limit was effective. It does mean that when users create a transaction they have a single-shot at getting the fee right. In the simplified example, if a user pitches their fee so that 2 miners will accept it (out of 10), and then change their mind, deciding that waiting an expected 50 minutes is too long, then they are SOL, the unconfirmed tx can't be changed. Fortunately this is rare.

The "constrained" block size scenario makes necessary the ability for ordinary users to increase the fee. Users will want to update the fee on their unconfirmed tx to manage the instability in confirmation times, otherwise their tx can remain stuck in cyberspace, and they are helpless.

Certainly, protocol block limits should not be hit unless all wallets first support the updating of fees on unconfirmed tx.

We don't have hardcoded fees in Bitcoin Core... except very low ones for relay permission which have been, in practice, below typical. They're kind of ugly, and I'm generally opposed to hardcoded fees, but if they're below behavior in practice they don't cause much harm (and are very very help at preventing resource exhaustion attacks). Bitcoin Core 0.10 has a automatic fee system based on the transactions in the mempool and recent blocks, where you can set a target number of blocks to wait and it will pay based on recent history.

This is relatively straight forward to support. When a new transaction comes into the mempool, if it pays at least $increment more fees per KB than the conflicting already mempooled transaction, replace it and forward on.  Then you just need fairly simple wallet support to revise a transaction. Petertodd (IIRC) already wrote "replace by fee" code that does this.  The catch is that implemented this way it makes zero-confirmed transactions less safe, since you could have a greater success in double spending.   This can be addressed by narrowing the set of allowed replacements (e.g. all outputs must be equal or greater), but AFAIK no one has bothered implementing it.

Chicken and egg. Without fee pressure there is no incentive to work on software to do that. Most non-bitcoin core wallets just set rather high hardcoded fees (even constant ones that don't related the the txsize metric that miners use to prioritize transactions into blocks.).

Unfortunately over-eager increases of the soft-limit have denied us the opportunity to learn from experience under congestion and the motivation to create tools and optimize software to deal with congestion (fee-replacement, micropayment hubs, etc).

Look at the huge abundance of space wasting uncompressed keys (it requires ~ one line of code to compress a bitcoin pubkey) on the network to get an idea of how little pressure there exists to optimize use of the blockchain public-good right now.

With correctly setup software there is no relationship between your bandwidth or electricity costs as a miner and the transactions you accept into your blocks, and any slight residual relation can be divided down to nothing by pooling with other N other miners (centralizing the consensus in the process) in order to have 1/Nth the bandwidth/cpu costs. As a miner you maximize your personal income by accepting all available transactions that fit which pay a fee, it's best for you when other miners reject low fee paying transactions to encourage people to pay high fees, but you dont and instead hoover up all the fees they passed up. They take the cost of encouraging users to pay higher fees, you defect and take the benefit.

Sounds good, but hopefully you can understand that some people are not very comfortable betting Bitcoin's future on not-yet-public theorems (which sounds like they must be at odds with the best understanding available from the active technical community _and_ academia...).  There have been many "bitcoin scaling" ideas that accidentally turned out to have no security or implied extreme centralization once considered more carefully. There are a few ideas which I think will someday help a lot, but they're not practical yet and its not clear when they will be.

The chance of orphan blocks should provide some competition for space.  Miners may find with current network topology a 4MB block is the right size.   As more nodes and faster connections occur size can be adjusted.  Is a hard limit an algorithm?

Centralized miners suffer much lower orphan blocks if the orphan block rate is macroscopic and driven by actual propagation time. If you're in a regime where one would want to do something to lower their orphan rate, the optimal income maximizing strategy is to centralize, not to reduce sizes.

Though at least fundamentally we know there there is no need for the orphan rate to increase proportional to block-size, if miners use more efficient relaying mechanisms that take advantage of the transactions having been already sent in advance.

Probably the best time to let soft-limits persist was in 2011/12 when the ecosystem was smaller, the funds at stake were a lot smaller, users considered the software more experimental than beta, and the world's press wasn't really watching.


My experience of (centralized) financial systems over many years is that ignoring hardware and software constraints as they are approached invariably causes outages. Also, that trying to train a user-base or worse, a market, to behave differently to accommodate IT constraints is a Sisyphean task. There are probably hundreds of IT experts who are concerned about the block size limit, because they can see the risks in it, which they recognize from prior (usually bitter) experience.

And, this is where the role of Core Dev is crucial. If there are major efficiencies to be had, "low-hanging fruit", then it would be wonderful to see them go live and reflected in smaller blocks etc. But right now, we can only project forwards, from what is happening with the average block size.

D&T, I agree with most everything you wrote, many thanks for the interesting research and composition effort.

Polls on bitcointalk:

- if I agree with the outcome, it's undenyable evidence that I am right
- if I don't agree with the outcome, it's just sock puppets.

Why did this forum get so filled with trolls?

Again, a straw man argument. No one has argued that the limit should be raised to "avoid paying fees". I want the blocks to come against the limit but I want that limit to be much higher than it is. I want the limit to put some upward pressure on fees, but not too much, because I don't want mass adoption to be dependent on end users paying "excessive fees" to access the blockchain.


But anyone wanting a permanent 1 MB restriction also needs to substantiate this course being set for the future. The argument for getting rid of the 1 MB restriction is no more speculative than the one for making it permanent.

Given what Peter R has shown:


And given that there is no reason to assume that the demand for space relative to available space will be lower with a higher block size limit, there is no reason not to raise the limit above the current 1 MB in light of DeathAndTaxes' analysis on what this limit will mean for end-user access to the blockchain.

I have never agreed with the use of polls in the forum full stop (and my own forum software does not even have them).

The very idea of putting polls into a forum that "encourages" sockpuppets is ridiculous.

(but let's not go off topic)

http://trilema.com/2015/gerald-davis-is-wrong-heres-why/

Since you content farm lot are all busy copy/pasting the same stuff over and over to each other instead of paying attention.

Why couldn't MAX_BLOCK_SIZE be self-adjusting?

That very vague.... based on what?   The hard rules of the protocol are what protect the users and owners of Bitcoins from miners whos interests are only partially aligned.  Sadly, miners have substantial censoring power for data that goes into the blockchain.  I suppose it's useful to have an in-protocol way of coordinating rather than depending on potentially non-transparent back room dealing; but almost anything in the network would be easily gamable by miners. There are some things that I think are preferable to just having no effective limit (e.g. having a rolling median, and requiring mining at higher diff to move the needle for your own blocks, and requiring difficulty to not be falling over-all for the size to go up) but these don't address half the concerns and potentially add a fair bit of complexity (which has its own risks.). 

Thank you DeathAndTaxes for this excellent post on why the block size limit must increase if bitcoin is to ever reach its potential as (or simply to remain) a decentralized, peer-to-peer means of exchange. A highly restricted blockchain that is impractical for regular people to use is not what bitcoin was ever intended to be, and you did a good job explaining why this is what bitcoin would become with a fixed 1 MB cap (and sooner than most people think). You also did a good job debunking several of the most common objections to lifting the 1 MB cap, and I would further emphasize that an artificial cap on the number of bitcoin transactions is not the best way to maximize mining fees and/or security. This follows from basic economic principles. Hypothetically speaking, if you assume purely self-interested miners and capping blocks at 1 MB happens to be the way to generate the greatest amount of transaction fees, then blocks will be no larger than 1 MB regardless of what the block limit is. Of course if there were no block limit, miners would be able to maximize their transaction fee intake whether that mean 2 MB blocks, 5 MB, whatever... market forces will determine the fee per byte that is needed to get a transaction into the blockchain in a timely fashion. Whether that fee makes it economical to purchase a cup of coffee with bitcoin, that remains to be seen (and may very well vary from person to person).

D&T, you've been one of if not the most consistently reasonable, sincere, and intelligent posters on this forum since I first discovered this forum, and I appreciate you taking the time to write this persuasive argument on a topic that's critical for the long-term success and viability of bitcoin.

What if he's wrong?

I should actually correct myself here since I overlooked the potential tragedy of the commons situation when it comes to miners including transations- a blockchain with no block size limit would not necessarily generate the most fees or be the most secure for that reason. However, it's still entirely possible (and in my opinion quite likely) that increasing the block size limit from 1 MB would increase the total fees per block in the long run.

For the entirety of Bitcoin's history, it has produced blocks smaller than the protocol limit.

Why didn't the average size of blocks shoot up to 1 MB and stay there the instant Satoshi added a block size limit to the protocol?

I'm not sure what you're getting at. Clearly there just hasn't been the demand for 1 MB worth of transactions per block thus far, but that could change relatively soon., and thus the debate over lifting the 1 MB cap before we get to that point. If suddenly the block limit were to drop to 50kb, I think we'd start seeing a whole lot of 50kb blocks, no?

lol,
so someone made a blog-entry about a Forum post to make it look more legitimate?

What does he expect, we're going to cancel the hard fork because he slanders some people with eloquent and expressive prose? Because he declares he can single handedly sabotage the process due to his importance and influence?

Whether the hard fork happens is not going to be determined by one man's ego. If he wants to present his arguments for not doing the hard fork in a diplomatic manner, they will be taken into account, and debated, but there is no debate as long as one man looks down on others, and feels no need to restrain himself and speak to them respectfully.

Absolutely agreed.

I recently talked to some Bitcoin-Users in real life. None of them doubted, that the hard fork will come, none of them had any fear, that something would go wrong(and some of them understood the technology much better than me)
Being active on this forum often clouds your vision from what is going on in the real BTC-World.
That's why I try to stay away from such thread. I think, I already read all the pro and cons on that matter. The rest is just accusation of who is  an idiot or a shill. It reminds me about elementary school.

please stop acting like over-emotive princesses.

lol
those posts are exactly what I meant. It's elementary school all over again :D

I have two older brothers, who will beat the shit out your cousins. So, just try.

I am not generally against increasing block size, but against doing it for the wrong reason or too eagerly.

The pace of increase has to be algorithmic, driven by market forces and advances of technology, not cenral planning or cartels.
The algorithm we have now, that fits above, is that of the difficulty adjustment.

It is plausible to me that difficulty stalls or falls if mining is no longer highly profitable, in which case block size limit should not be increased. This is actualy the line of thought that makes me think an increase of block limit at this time point is not warranted.

Linking block size increase with difficulty adjustment would be technically straightforward since difficulty calculation already drives validatation, size limit could be just one more of it its output and implied checks.

This was also my first preference. I'd add that if it was up to me, the hard limit would be removed altogether, and it would be up to miners to create a soft limit. As long as over 50 percent of the network hashrate enforces a particular rule on the block size, it will be as binding as a protocol rule.

Perhaps the 40% per year hard limit increase can co-exist with a dynamic soft limit that tracks difficulty. That way the hard limit acts as a failsafe, while the soft limit imposes the real size constraints.

What I meant is not a vote by hash rate, that would be a cartel. Difficulty increase is also not a vote but a consequence of market forces and technology.

It is important to preserve the proposed role of fees, that are to two fold: contain spam and replace inflation on the long run.
Eagerly increasing block size would be contrary to both.

Miners cartelizing to create a sensible de facto block size limit doesn't seem like a bad thing to me. Anyway, I don't want to take this discussion too far off-topic so I'll save it for a different thread.

Max block size could be retargeted periodically alongside difficulty adjustments using average block size and the frequency of full blocks in a period with the hard-coded value as a floor.

Imagining the necessity of 20MB blocks relies on the assumption that a massive increase in transaction volume develops, but what if it slows significantly?  Bloated block broadcast delay might temporarily even be useful as a competitive advantage.  When fees outweigh reward, doesn't the mining market encourage bloat?

Also, with a hard limit on size, won't the conversation on manual adjustment resurface indefinitely with increasing political difficulty? ;)

It certainly could be.   The point of the post wasn't to arrogantly state what we must do or even that we must do something now.   I would point out that planning a hard fork is no trivial manner so the discussion needs to start now even if the final switch to new block version won't actually occur for 9-12 months.   The point was just to show that a permanent 1MB cap is simply a non-starter.  It allows roughly 1 million direct users to make less than 1 transaction per month.  That isn't a backbone it is a technological dead end.

For the record I disagree with Gavin on if Bitcoin can (or even should) scale to VISA levels.   It is not optimal that someone in Africa needs transaction data on the daily coffee habit of a guy in San Francisco they will never meet.   I do believe that Bitcoin can be used as a core backbone to link a variety of other more specialized (maybe even localized) systems via the use of sidechains and other technologies.  The point of the post was that whatever the future of Bitcoin ends up being it won't happen with a permanent 1 MB cap.

And this is a point that I have been trying to make (we don't need to put every single transaction in the world into one blockchain).

Probably and it may be infeasible to raise the cap further in the future even if that would be optimal.  However with a 20MB or 33.6 MB* (2^25) block size Bitcoin at least has the potential to exist as a backbone of sorts and it does provide us breathing room.  Once again I am not advocating any particular size limit, timeline, or method to raise the cap just that the idea of permanently keeping a 1MB block size just fails basic math and reasoning.   If the post convinces some people to go from "never raise the limit" to "I have concerns how can be raise the limit in a way which addresses them" then it served its purpose.


* The only "limit" definitively set by Satoshi.

I agree and thats why we will have sidechains.

I agree.  I didn't have the time to respond in your thread but I don't believe there is "one blockchain to rule them all" however even for those who believe Bitcoin can exists as an interchange between a diverse ecosystem of networks the block size will need to be raised.  1MB blocks prevent even infrequent access by users between the Bitcoin network and side networks without "trusted" intermediaries.  If the backbone is centrally controlled then the supporting ecosystem is built on a foundation of sand.

We may see most of the overall transaction data occurring on side networks or way may see sidechains only used in niche applications where they provide a tangible benefit over Bitcoin "core".  I don't know how it is going to play out there are advantages and disadvantages either way.   How, when, by what method, and to what ultimate end the transaction capacity will be increased are all good questions.

Thanks (it is nice to have your response rather than all the trolling I've been getting with people thinking I am trying to flog an alt-coin or whatever).

And I do agree 100% that the current Bitcoin TPS is not going to be very useful in a few years at all (if it stays as that then it could only end up being a "store of value" system practically).

Late to the thread but wanted to lodge my Yes vote for increasing the block size.  Great post D&T.

It seems nonsensical to me to risk adoption itself - and as D&T points out, give up the financial/transactional freedoms Bitcoin provides - simply to test a high scarcity/high fee model.  I can see that the upcoming halving adds some weight to the "miners will leave, threatening the security of Bitcoin, if fees don't compensate" argument, but I think the impact (reduced hashrate, centralisation of same) is being overplayed by some.  I don't buy the doomsday scenario.

Increase the block size and either the numbers work (adoption -> more transactions -> more small fees -> happy miners) or they don't and miners leave/fees rise.

Okay, I'm going to start by saying that in the short run (next four or so years) there is no escaping an increase in maximum block size.  So yes, definitely do that.

However, in the longer term, that's still supralinear scaling and still potentially faces scale problems.  So we need another solution.  We don't need altcoins whatsoever.  It's possible for a single cryptocurrency to exist as multiple blockchains.   There can be a central blockchain that does hardly anything else than mediate automatic exchanges between address spaces managed by dozens of side chains.

Transaction times where you have coins on one side chain and need to pay into an address that's on a different side chain would become longer, because now two transactions that mutually depend on one another must appear in two separate blockchains.   So that's annoying if your wallet can't find coins that are in the same chain as the address you are paying to. 

Within chain A, a cross-chain tx might appear as "Han paid Chain B in tx foo-a" and in chain B it appears as "Chain A paid Chewie in tx foo-b"  And if that result would cause chain A to have a negative balance, it triggers "Chain B paid Chain A half of chain B's positive balance in tx foo-central" in the central blockchain.

Anyway, you'd have to at least temporarily track the central chain, any chain into which you're paying, and any from which you're being paid, like a lightweight client.  Beyond that, you'd have the option of actually having the full download and proof all the way back to an origin block of any subset of chains that interest you.

Excellent post!

There are always altcoins to pay for the coffees, but still there can be no doubt that 1MB is not enough. I cannot believe people seriously oppose the increase! After all it will not make the blockchain 20x bigger, it will only make the blockchain as large as needed to include all transactions, once the 1MB limit is not sufficient anymore.

So people who oppose the change are basically saying, BTC transactions have to be severely limited (at around 7 TPS) forever, just to stick to the 1MB limit forever. That is nuts.

"arguing to ignorance"

the rest of the post was distorted trash based on false assumptions too

Troll and useless post. Bringing nothing to discuss. Move alone.

It actually could be as few as 2 tps, meaning that if there are over 60 million Bitcoin users, each one will only use the blockchain once per year, and with a billion users (1 out of 7 people in the world), each person can use the blockchain less than once a decade:


This is totally unrealistic, and it's not going to work. Running a block-space scarcity experiment on Bitcoin to see what happens when people can no longer use the blockchain for real-world transactions, when the block size can still be significantly increased without making the network centralized, is dangerous and irresponsible. The idea that they'll opt for a Bitcoin micropayment channel hub, rather than just giving up on Bitcoin, is pure speculation, and one that I don't think will be borne out.

How about keeping a main blockchain, housed in several thousand, major repositories around the world, with mirrors and backups. Everything would go into the main blockchain.

There would be a smaller, secondary, "practical," everyday blockchain that would house the first record of every address, and the last two. Yet it would eliminate all the times an address was used between the first and the second last.

This way we would always have the full record when needed, but we would have easy access for everyday use.

:)

Justus is, I believe, pointing out that until very recently bitcoin has effectively had no block size limit, as blocks near the protocol limit were almost non-existent.  More recently we tend to get a few a day, mostly from F2Pool.

Those claiming we'll have massive runaway blocks full of one satoshi / free transactions have never adequately explained why it wasn't true historically when the average block size was 70k, and why people still felt the need to pay fees then.

Anyone trying to send free / very low fee transactions recently will know from having it backfire that they have to think long and hard about taking the risk if they want confirmation in a reasonable time, and that's the way it should be and likely always will be.   Each incremental transaction increases miner risk, and therefore has a cost, and that's natural and good, and enough for an equilibrium to be found.

Heck, were the cap completely removed, and some major pools concerned about spam (aren't we all?) stated that, for their own values of X, Y and Z, that they'd not relay blocks larger than (say) 500KB that pay total fees of less than X satoshis per kilobyte, and would not even build on blocks paying fees of less than Y per kilobyte unless they had managed to become Z blocks deep, would have a huge deterrent effect of making it expensive to try to spam the network.  Not many people are willing to risk 25 BTC to make a point, never mind be willing to continue to do so repeatedly.   X, Y and Z wouldn't need to be uniform across pools, and of course could change with time and technology changes.  An equilibrium would be found and blocks would achieve a natural growth rate than no central planner can properly plan.

Yes, it makes sense to remove/raise the hard limit from the protocol and let individual miners set their own limits since they are the ones most in touch with what the optimal parameters would be for their individual setups. If we went to a 20MB cap tomorrow I'd guess that no pool would even try to build blocks anywhere near that size given the high risk of getting an orphaned block with the current state of the network.

In the end, the whole block of transactions must be present on the blockchain at the most distant end of the network in 3 minutes to allow newly discovered blocks to be added upon it. Ideally, you need to transmit 20MB data in 1-2 minutes. Maybe it is possible to use multi-threaded P2P downloading to accelerate the data transfer

bigger pools already use another block propagation between themself. i am not sure how much it can handle, but obviously its optimized for miners needs

Blocks are just transaction data which has almost all already been relayed through the network. All that one has to send is just a tiny set of indexes to indicate which of the txn in circulation were included and in what order  and there are already alternative transports that do this (or even less-- just a difference between a deterministic idealized list and the real thing).  The data still has to be sent in the network, so it doesn't fundamentally improve scaling to be more efficient here (just a constant factor), but it gets block size pretty much entirely out of the critical path for miners.

So basically a solution should

- increase the block value (~20Mb)
- use high speed super nodes (in order to propagate in 2 minutes interval)
- use some kind of multi-threaded P2P protocol
- increase the reward on miners.

good.

what next ?

Gavins proposal automatically scales 40% per year after the 20mb raise, then stops after 20 years - last time I read up on it.

After 20 years this puts us at ~16.000 mb or 32.000 TX/second. That's more than the VISA network and I think it will last a long time.

I also support Gavin and OP.

+1 At that point we'll have a ton of sidechains (hopefully) that can handle any further growth in demand for peer-to-peer electronic cash transactions.

Great effort in posting. You hit the hammer right on the nail. But i think the title is slightly misleading for me. Perhaps a question mark at the end instead would suffice. I think a decision has to be made immediately because we are really close to reaching the limit with the current 1MB restriction.

I agree, and I never meant to suggest otherwise. Bitcoin still has effectively no block size limit, and if the block limit became 1GB tomorrow it most likely wouldn't result in blocks being any larger in the foreseeable future. I corrected myself because I at first said that no block limit would result in the greatest overall transaction fees being paid, but I don't think that's true. Given the tragedy of the commons issue surrounding blockchain size, the marginal cost of any individual miner including a transaction in his block is only negligibly higher than the risk of an orphaned block. If a miner doesn't include the transactions with fees above that marginal cost, they can be profitably taken by the next miner to create a block. That's not necessarily how it has to work, miners may attempt to employ strategies (like you mentioned) where that wouldn't be the case, but there's no guarantee they would succeed.

Great post Death&Taxes.

However I have never heard anywhere people supporting to keep permanently the max block size to 1MB. So your post is somewhat misleading and is avoiding the most interesting questions. Which are:
1) max block size design : is switching from hard coded max block size 1MB to hard coded 20MB the smartest way to proceed ?
2) timing: is now the best timing to do that? It  appears there is no real argument to rush. Tons of innovation is going on, we are months away from a first side chain implementation. Perhaps in 6 months or a year from now we will have ideas we hadn't thought of.

From the comments here and on reddit, I don't see a real consensus on that subject. So imo it's better to keep discussing about it. We can reasonably expect to see concurrent proposals to Gavin's, with a different MBS design and perhaps a more appropriate timing.

Double the max blocksize every two years which roughly keeps in line with Moore's law.

For what it's worth: 

I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code.  Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea.  Both Satoshi and I objected that it wouldn't scale at 1MB.  Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed.  The 1MB limit was there by the time Bitcoin launched.  But all 3 of us agreed that 1MB had to be temporary because it would never scale.

Several attempted "abuses" of the blockchain under the 1MB limit have proved Hal right about needing the limit at least for launching purposes.  A lot of people wanted to piggyback extraneous information onto the blockchain, and before miners (and the community generally) realized that blockchain space was a valuable resource they would have allowed it.  The blockchain would probably be several times as big a download now if that limit hadn't been in place, because it would have a lot of random 1-satoshi transactions that exist only to encode information for altcoins etc.

At this point I don't think random schmoes who would allow just any transaction are getting a  lot of blocks. The people who have made a major investment in hashing power are doing the math to figure out which tx are worthwhile to include because block propagation time (and therefore the risk of orphan blocks) is proportional to block size. So at this point I think blockchain bloat as such is no longer likely to a problem, and the 1MB limit is no longer necessary.  It has been more-or-less replaced by a profitability limit that motivates people to not waste blockchain bandwidth, and miners are now reliably dropping transactions that don't pay fees. 

Gavin is right, we should do this now before its too late.
Heres a video for noobs that explains it quickly:
https://www.youtube.com/watch?v=U1KNbgoF-ZY

Are you saying that the original plan was to have no limit at all? What would happen if we were just to remove the limit now, instead of making it bigger?

The limit wasn't part of Satoshi's original plan, but keep in mind that the original plan was at that time very much a work in progress.  I was only involved for about a month back then.  When Hal and Satoshi started talking about involving more people, I dropped it.

Thank you for this interesting resumé D&T, always enjoy to read your posts, they were very helpful since the early days to understand the inner workings of the technology better. I am convinced  :) 

How do we decide what level of security is "required" for the network? What amount of hashing, what $$ spent on mining hardware... Is there a knowable, correct, answer?

Available hashing power must provide more reward when used to gain transaction fees than attacking.... right?

How do we know that existing coin minting even does this? (apart from it vaguely seeming like a very large amount, and no attacks really having happened)

Well another grate post of D&T

I am not a big fan of increasing the Blocksize to 20MB

Having said that.

We see a huge concentration in mining environment 4-5 hands control 75%+ of mining power (Pools and Large Ops)

If the Blocksize increase exponentially the numbers or nodes may drop in a significant way just because they require to much disk, actually the network increase but there are not so many full nodes (nodes sharing the blocks)

With centralized mining and few nodes Bitcoin will be weaker.

I understand the reasons of Gavin A. to increase the Blocksize but we need to find a solution for the problem and an analysis that includes all the players in the Bitcoin ecosystem.

Lately I read many times that "The value is in the Blockchain" is true but without truly decentralized mining and a huge nodes constellation in line with the P2P Crypto Decentralized there is no Blockchain or Bitcoin (as currency)

Core Developers are a crucial part of all this, but also miners invest lot of money (more than all the VCs combined) and nodes add really decentralization to the system, we need an improvement that will generate more miners (not pools) more nodes and a healthy Bitcoin Network.

Regards

Juan

The dominance of large mining pools is not due to the cost of running a node. There are thousands of full nodes, and yet the top 4-5 pools direct the majority of the network hashrate, as you note. The reason large pools have high hashrates is that pool size reduces the payout variance to miners, so miners prefer to use large pools.

So you need to be clear what you're trying to solve, and what is the cause of the problem. Because keeping the block size at 1 MB forever is not going to reduce the dominance of mining pools.

Have you read all post from this thread? The "much disk" will not be needed! We have blockchain pruning.

The issue is not whether or not a larger block is technically advantageous, it clearly is.

The issue is that many people will not update or go with the new fork, thus creating mass chaos.

It would be great if Satoshi would chime in.  Maybe if the coin does indeed begin to snap in two?

There is no need for Satoshi to chime in (although if he did reappear I have a list of questions).   The first version of the client had no block size limit.   The second version of the client had no block size limit.  The next 146 commits to the repo had no block size limit.  The source code is the proof.   The block size limit wasn't added as an anti-spam mechanism until more than 21 months after the genesis block.

I am just saying there are some issues to be solved more relevant than the size of the block.

Juang

They can be solved simultaneously. In the mean time, Bitcoin needs to seize the opportunity it has to attain mass adoption, which I believe cannot happen with a limit of 1,800 txs per block, due to the basic constraint it places on access per user.

Well if the size of the block rise the size of blockchain database may rise or the upgrade is useless, bigger size more disk space and in my opinion full nodes are not so many.

Regards

Juan

Ok you are unable to read what people post here. Let me spell it for you:

B-L-O-C-K-C-H-A-I-N  P-R-U-N-I-N-G + cheapening of $/TB

Maybe now you get it!

I think Satoshi was worried about rapid improvements in hashing power giving one rogue miner the ability to bloat the blockchain with a series of large (32MB?) blocks. The first mention of using FPGAs that I can find on Bitcointalk is July 2010, three months before the 1MB change. At the time Bitcoin was gaining traction with a community behind it, and a serious spam attack would have damaged its progress.


(my bold emphasis)

I read and...?

Did I have to agree with the solution?

The main issue for me is we need to promote and secure the decentralization, and now Bitcoin is more centralized than the banking system. A single guy not a company or a group single people controls 1%+ of the system and most of the system is in a very small club of people this is not decentralized at all and that makes us a weak system simple to attack.

Juan

So, Bitcoin is more centralized than the banking system? So, that means I can no longer make a BTC1000 transaction without explaining myself why and how I would do such a thing?

So you are against rasing the block limits because of the space problem and you don't agree with the blockchain pruning solution? Ok. That makes a lot of sense.

Lol at thinking we can live forever with the amazingly shitty 1MB limit. Get a grip boys.

Thank you OP. This perspective is sorely needed.

Those wishing to keep a small block size are in favor of a useless Bitcoin network. Some may be simply being manipulated by some half baked economic theory that says miners will go broke if they process lots of transactions and the protocol gives them the ability to process many more per block...but I suspect there are people who truly wish to try and make raising the limit a real problem for the dev community.

People advocating for a tiny max block size are no friends of Bitcoin.

+1

In agreement here, too.  And the best part is, it doesn't matter what the anti-fork crowd think, because whatever they say, we can go ahead and do it without them.  They can stay on their old, limited chain if they want, but they can't force the rest of us to stay.   

This is the explanation to which I was referring:
http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/

http://38.media.tumblr.com/e4dc584e92e933cb59ac6eef27ff0a09/tumblr_nc393vwDNB1tts3f4o1_500.gif

::) ;D :D

Block size has to be incrassed thats obvious

I've read at least hundreds of posts on this topic, but OP's post is far and away the most convincing of any I've read.

+1

I'm not sure it will be that chaotic.  The last hard fork wasn't that bad. 

Wow! Great article and I think the system you describe seems like the ideal way to price the various services required to keep the bitcoin network running, and could put an end to the block limit debate once and for all. A miner creating a large block could have to pay a premium to the nodes for promptly propagating the block. Users sending transactions may also have to pay for their transaction to be propagated. Both of these would have the effect of disincentivizing spammy transactions that may overburden the network. Did I get that right more or less? This is the first I've heard of such an idea for bitcoin.

I had never heard of micropayment channels, and that's still the piece that I'm having the hardest time grasping. I clicked on the link to read about micropayment channels some more, but it's still hazy to me. I might just need to spend more time reading about it.

At some point 1 MB cap is going to restrict user access to the block chain, yes. It is the same as saying that you can't have a growing economy with limited resources to support that economy.


Smaller transaction amounts are not more important than larger transactions. The block chain does not have this bias currently today nor do I think it ever will be. So the notion that a cup of coffee should be done off chain says one transaction is more important than another. That is something I do not believe Bitcoin was intended to imply, ever.

I wouldn't necessarily say that side chains are a trust free alternative as the security of side chains will vary (from chain to chain) as SCs pop up to offer alternatives. SCs as an "trust free" alternative can be a misspeak. If an SC is less secure, then although they offer some transaction capacity on the primary chain at a certain point in time does not mean it will always be that way. There is a lot of risk in transferring coins from main chain to an SC.

Agreed the 1 MB limit is insufficient concerning moving transactions off the primary chain and onto an SC.

Keeping the idea of having intermediary parties to transact on the block chain at bay will keep Bitcoin's utility as it was created for in tact. Removing that to put in centralized parties (trusted 3rd parties) is a huge mistake. Decentralization to Centralization…pointless.

Using 3rd parties which are not trust less prior to using an alternative crypto currency to transact would be a mistake in my opinion. If the main chain got to a point that the ability to have access to the block chain was limited by the adoption rate of users of the main chain I would see no reason people would not want to use an alternative chain to transact that is not an SC.

Off chain transactions with Chase and HSBC (as the example) would require 3rd party audits of their internal ledgers. From past experience when information is not publicly available (private internal ledgers), shenanigans will occur.

I guess to begin with the fact that people would store their bit coin with a CHASE or an HSBC would require trust from the user level. Currently bit coin allows users to keep their coins in their possession. I suppose having multisig would apply to some extent here if the adoption rate of users exceeded some defining threshold that made it impractical for the average joe to use to transact.

D&T you bring up an interesting dilemma that may come some day concerning being priced out of being able to transact on the chain as a normal user and being forced to use an alternative method to transact. Instead of using a trusted 3rd party, why not use another block chain that is not an SC to transact?

 Of course there are exchange fees to get this done. So perhaps the lesser cost of the two may be the solution. In that case order book depth needs to be taken into account as well and any exchange transaction fees, withdraw fees and network fees. This is very interesting to explore as the ability to transact with less cost may change from time to time. Of course no one knows the future but it is a plausible thought to consider when discussing the topic.

Payment channels

Where did the myth of 7tps limit while using 1 MB cap come from?

The part about showing the limitations based on average txn size of the last million transactions is quite interesting. I guess the idea of 7 tps limit did not take into account the variability of tx sizes. It is always good to over estimate (or under) to make sure your estimations are likely to be within the bounds of the claims being mentioned. Clearly the 7tps claim did not account for that.


BTW, @D&T, great post!  ;D

Check this :  Why would anyone host a 1 MB full node if they can only use the blockchain once per decade?  (http://www.reddit.com/r/Bitcoin/comments/2vec37/why_would_anyone_host_a_1_mb_full_node_if_they/)

I hear such arguments, but it is the +1Billion users postulate that sounds kinda cultish to me.

"Bitcoin for 7billion people", "Bitcoin for Africa", "Bitcoin for unbanked"..
I ear this a lot but think that this is nothing close to reality.

Masses just really dont give a dam about finance, monetary policies or internet of things. They need jobs and food.

Yes of course , bitcoin is for all the world but some people don't have neither the access on internet/smartphone (with 3G). So you are right, for the moment not all the people can use bitcoin but this fork is necessary at least for rise the limit of TX per second.

All im saying is that whatever happens, try not to 'put the cart before the horse' gents.

1 TB cost 120 € retail, and would fill in 3 year and 9 months at least with 20 MB blocks (full).
With pruning, the full nodes could just keep the hashes and be able to verify any data they receive from a server.
But, anyway, many companies would prefer to keep their own copy of the blockchain just to speed up the processing & checking of transactions.
For example, a POS would ask for a transaction and relay it to the network after checking the transaction is correct. It would need an updated local copy of the blockchain.

There is no need to have a fully decentralized network with every node having a full copy of the blockchain. It is just needed the number of copies of the blockchain existing around the network are high enough and in enough different and competing hands. No one will be able to censor 1.000.000 copies around the world, at the same time. If the users are one billion and the copies are one million, it is not centralized.
Centralized is when there is just one copy or few copies under the control of a central authority able to affect them at will.

In the end, if we want Bitcoin to revolutionize the payment systems and the monetary systems, we need a block size in the 1 GB range, at least.
Maybe not tomorrow, or the next year, but surely we want it in future.

I completely agree with DeathAndTaxes (love the handle, BTW!) Limiting the block size to 1 MB is just hard-capping the maximum amount of transactions possible in 10 minutes (approx.) This doesn't make sense!!! There are solutions against orphaned blocks, etc. ready to be implemented well before the problem of >1MB blocks actually arises!

Larger blocks and lower fees means less mining, but not longer confirmation times, since larger blocks will still be mined every 10 minutes.

All it takes for transaction fees to go down to ~zero is a benevolent or a malevolent miner occasionally accepting 0 fee transactions.

The question is, will stakeholders step up to mine "at a loss" to secure their funds?

Increasing the block size limit is a poor implementation of PoS...

...and we know this is true because transaction fees have already gone down to zero.

I mean, if we had objective empirical evidence that transaction fee revenue was positively correlated with transaction volume over a six year period that might be a different story...

One miner accepts 0 fee transactions. Why would the other follow their example?


Bitcoin is not implementing POS. I don't know what gave you that impression.

Individual miners decide absolutely nothing, other than people operating their own P2Pool node, with a tiny chance of finding a block.

Mining pools are the ones who decide what transactions they will accept.  99+% of the miners could care less about this.

"Occasionally" was bad word choice on my part. If "enough" (1 large or many small) miners are willing to fill 20 MB blocks of ~0 fee transactions, then some bitcoin users will send ~0 fee transactions, and some miners that mine for transaction fees will stop mining, which weakens the security of the bitcoin network.

While this has always been a vulnerability, it seems like increasing the block size limit makes this economic sabotage more potent.

There's no need for other miners to follow their example.


Increasing the block size limit reduces transaction fees. Eventually, miners are not mining for transaction fees, but mining as stakeholders to maintain the integrity of the blockchain. Only stakeholders mining doing PoW is like a really inefficient PoS.

Stop saying 'the miners'.  3-4 people decide that.

https://i.imgur.com/PAyqNxW.png

They should implement a dynamic block size based on the transactions for the past two weeks similar to how the difficulty is handled. This still allows for smaller nodes to participate in the short-term but also allows the network to scale in the long-term. This also makes it so miners get rewards as long as the number of transactions is increasing since the block size will always be a little bit smaller than the number of transactions.

was it already argued that not raising the block size leads to fractional reserve banking? - this system then basically becomes the same shit as the banking industry.

Why would they be motivated to do so? If there's no motivation, then the rest of the argument does not stand.


Why would these ones stop mining? They would still be profiting. I don't get it.


What's the logic here? If miners are not mining for transactions fees, they are still mining for the subsidy. Either that or it would be a truly altruistic act. And even if it was, they are not proving their stakes at all. They are still proving they have done some work.

not if you hoard your bitcoins.. all hail the new bankers ;D 8)

VERY good point. Of course only few people decide that. same as exchanges.

the exchanges have behind the SAME shareholders(4-5). The entire BTC is owned by up to 10 people :) Funny !

Or, if they made the blocksize a dynamic size and it is always updated to handle 99.9% of the transactions from the past two weeks so that the .1% that pay the least transaction fees might not get written in the next block.

Today most (all?) miners accept some zero fee transactions.  Yet fees have not gone down to zero.  They is a balance between cost and convenience.  If there wasn't then ATMs, convenience stores, and overnight mail wouldn't exist as services.

If 100% of miners will accept your txn for $0.05 in fees and 10% will accept your txn for free most rational users will still pick $0.05 in fees on many transactions.  Saving $0.05 usually doesn't make sense and in many cases ends up being the more expensive option (due to volatility risk).  We see this dynamic right now in every block.  There are plenty of "high priority" transactions which include a fee despite it not being required by the full nodes.  Unlike low priority transactions which will not be relayed by full nodes unless they include a fee, high priority transactions will be relayed without a fee so they are guaranteed to end up in the memory pool of miners.  At that point it is only a matter of time before they are included in a block.  The amount of space devoted to high priority transactions is however limited and that means transaction times for unpaid transactions are both long and unpredictable.  For many users the short and predictable confirmation times are worth more than the fee.

If someday 10% of the hashrate decided to include free transactions I think the rest of the miners would love that and probably reduce or eliminate the space they currently give away for free to include more paying transactions.

They'd stop mining because they wouldn't be profiting. It would be like if Amazon lowered the price of hot cakes to $0. Some other retailers would stop selling hot cakes.


As the bounty decreases, and if the transaction fees decrease (as a result of block size increasing), then non-stakeholders will have no (or decreasing) incentive to mine. Stakeholders, on the other hand, will need to mine to keep their bitcoins safe. It's no more "truly altruistic" than a bank hiring a security guard to protect its assets.

How much will a stakeholder or saboteurs need to spend on mining to protect / steal $100 in a PoW system? About $99.

How much will a stakeholder need to spend on mining to protect $100 from saboteurs in a PoS system? A lot less than the saboteurs... Right?

tldr; As we move the direct profit incentives for mining, the responsibility for maintaining the integrity of the blockchain will fall on stakeholders. PoW is a great way to distribute the initial coins, but it's a really inefficient way for stakeholders to "vote" on which chain is right.

Right?

That's definitely not how it works. You can't just choose which miner will process your transaction.


This is all based on your assumption that miners will start leaving, which simply isn't true. There's no motivation for them to leave.

The average block size has been increasing for six years.

Has the average transaction fee revenue increased or decreased over the same period?

Is there anyone in favour of small blocks who has the slightest bit of intellectual integrity whatsoever?

http://www.quickmeme.com/img/39/39cd99d531aeccd977a99d03a3e23db2de8b698c537fd7416c629d3ff4ec777e.jpg

gosh rude. why not go and ask them? you know exactly where they are. weird to strut around in this non-place

Yeah, if I want my transaction to be picked up by a miner who doesn't require fees, I can just sit patiently.


Miners leave all the time when they're no longer profitable...

What? A miner that accepts transactions with no fees is not actively blocking transactions with fees. This point makes no sense.


Why are they no longer profitable? Your hypothesis about people not wanting to be with them (which, how will they choose? You CAN'T CHOOSE a miner) is incorrect.

Miners aren't currently mining for transaction fees, because of how insignificant they are, so it's not really a good question.

https://blockchain.info/charts/network-deficit

But is "average transaction fee revenue" increasing or decreasing? It's kind of hard to tell...

https://blockchain.info/charts/transaction-fees

I'm not really in favor of small blocks, because I don't like the idea of incentivizing non-stakeholders to maintain the blockchain. I just think that this is a problem better solved with PoS. Let a stakeholder make a 1 GB block, for all I care.

On the other hand, the thought of letting a rando non-stakeholder (e.g., the government) make 1 GB blocks of ~0 fee transactions (or spam) makes me uneasy.

Blocking transactions? I don't think anyone was talking about that.

If "enough" miners don't require a fee, then some transactors will not send transactions with a fee, and many others will simply send insignificant fees (like now). Some miners that were mining for a profit will no longer be able to make a profit, and they will stop mining.

Despite what someone else claimed, this does not make confirmations take longer, increasing the price of transactions, and incentivizing more miners to mine, because of the fixed time to mine a block.

Either this will reduce the security of the bitcoin network, or stakeholders will mine "at a loss" to avoid losing their bitcoins.

And, it's silly to make stakeholders do PoW.

Add:

LOL, I didn't make that hypothesis. I don't know what you're talking about :-)

Just in case you were curious about mining bitcoin on other planets..

https://i.imgur.com/hl75two.jpg

Don't worry! There will be a SWIFT-a-like sidechain that will regulate interplanetary transfers  8)

Ya, me.  I've been around for years and have been saying the same thing since pretty much day one.  I don't own any alts or have any interest in them.  I don't take a paycheck from some shadowy group of well funded coders who are making noise about taking over Bitcoin with a 'better' software.

I make a lot of noise about 'sidechains' because subordinate chains which derive their value from Bitcoin are a logical and natural scaling method which actually can work and keep Bitcoin healthy.  Possibly the only thing with a hope of doing so in fact.

Speaking of intellectual integrity, when are you going to share your infinite wisdom on the effects of IBLTs on 'natural' blocksizes?  I couldn't help notice that you've ignored my comment when I inserted it into your supposedly coherent argument that blocks should remain small even if the max size is raised 'cuz they always have.  You are not alone among people who want to remain mum on IBLTs though.

I'll be much more satisfied with SWIFT when I can be a full peer with Wells-Fargo using a router-sized server behind my satellite connection, and any of 100 million others can do so at will.

This can happen anytime now. Why would it be any different after the fork?


I still don't get how you go from “Miners are mining at a loss” to “This is proof of stake”.

And this is relevant because...?

(Numbers made up.)

After the fork, the government could regularly post blocks with a million transactions in it. If it happened regularly enough, people would lower their transaction fees, and some profit-seeking miners would leave.

They can try to do the same thing before the fork, but each time they are limited to posting blocks with only 100 transactions in it. There's still scarcity, and fewer miners will leave.

Granted, scarcity is not driving mining at this time. But transaction fees were "supposed to" take over mining bounties (which I think is bad design, see below).


There are four groups of people (a) stakeholders, (b) saboteurs, (c) transactors, and (d) miners. With PoW, stakeholders want to protect their coins from saboteurs, and for some reason transactors pay miners to do so. That's pretty convoluted! Transactors and miners would be just as happy destroying the blockchain, if it enriched them somehow. (We've seen attack vectors along these lines.)

However, if block size is increased, there's really no reason why most miners won't include as many transactions as possible, since it doesn't really cost them anything. Transactors will no longer be required to pay to have their transactions included in the blockchain, and eventually profit-seeking miners will leave. Stakeholders will still need to protect their coins from saboteurs. Suddenly, stakeholders will either have to mine themselves, or send bitcoin to themselves with large fees, in order to keep miners in the game (which is inefficient, because sometimes the fees will go to saboteurs). In this scenario, we've realigned the costs of maintaining the integrity of the blockchain: the transaction fees have dropped, and stakeholders are paying to protect their coins. These are the same incentives as PoS.

However, this is a really inefficient way of determining which ledger is correct. There are at least two ways to do so:

(1) You can ask the stakeholders and the saboteurs to fight it out. The last one standing decides which ledger is correct. This is PoW.

(2) You can just ask the stakeholders which ledger is correct. This is PoS.

Thoughts?

So far I've published about 5000 words regarding the economics of block size and related topics.

You are perfectly free to read what I have written to see if your question is answered or not.

If you're going to demand a concierge answer without even bothering to participate in the public discussion, you should know that you certainly haven't earned that.

This is dumb.  Let us say one miner starts filling 20MB blocks with 0-fee transactions.  Let's say that there are users out there who supply her with 0-fee transactions.  Miners who are mining for fees will just ignore the 0-fee transactions, which means people who do 0-fee transactions just have to wait until the one miner who accepts them happens to get a block.

That means that the user has a choice between an 0-fee transaction that may or may not eventually get onto the blockchain at some unknown time in the distant future, or a fees-paid transaction that will get into the next block.  So, fees-paid transactions will keep happening because people don't want the uncertainty, delay, and hassle of wondering whether and when their tx will go through.

But it gets better.  That miner who is filling giant blocks with 0-fee transactions?  She's competing with miners who are collecting fees.  In that competition she will go broke.  So to the extent a miner can cause a problem by the behavior you describe, it's a self-correcting problem.

There are more logic faults in their post.

Any entity that finds a block could fill it with the transactions they want to include. That includes the government.
Two non sequitors. Why would people lower their transaction fees? And why would it make some miners (I assume all miners seek profit) leave?
Again a non sequitor. Why would miners leave if another miner is filling blocks with 0 fee transaction? Average block size at the moment is (well) under half a megabyte. Blocks are not even half full on average. How is that scarcity?
Profit is driving mining at this time. I don't see that changing anytime soon.
Care to elaborate on how you came to these groups? They are definitely not mutually exclusive.
That's not why people pay a transaction fee. Transaction fees are paid to verify a transaction. That's what it's all about, isn't it? Trustlessly verifying transactions. The transaction fee is supposed to be an incentive for a third party to verify a transaction.
It will cost them in bandwidth, storage space, propagation speed (chance of orphans?). Miners will find a balance that optimizes their profit.
There is no requirement to pay transaction fees right now.
Non sequitor. It doesn't happen now, at least explain why would it happen tomorrow?
What if scenario filled with assumptions. Can't be bothered to disseminate this further.
It seems to be working quite well at the moment.
And the stakeholders will include saboteurs who will confidently tell you their ledger is correct... And the one that managed to get the largest stake gets to decide. The way you put it actually convinced me that it is a good thing to separate the people making transactions / holding an amount of currency and the people verifying their transactions.

TL;DR:
The same thing we do every night, Pinky.

All I was trying to do was to figure out if you were unable to comprehend IBLT's impacts on block size, or whether you were deliberately ignoring them because they (probably completely) nullify the argument you were trying to make and figured your target audience would be ignorant of them.

Not that it matters much...both possibilities suck for you.

Wrong on all counts.

You'd know that if you'd bother to read.

You're just setting yourself up to look even more ridiculous.

According to my data the average transaction size is higher than expected, and slowly growing.

https://i.imgur.com/W7uS5IY.png (https://i.imgur.com/W7uS5IY.png)

Average on the chart equals average of all transactions, where data points are based on the average of 2500 block intervals. The full data table is available here (https://i.imgur.com/URo4ERd.png), though as image and only until block 327500, but it should provide a ballpark: somewhere around 500-600 byte per transaction.

Why can't someone just make a video explaining this concept and idea, for people that aren't techies because i have a few people already ask what is going on.
Because this is only going to lead to wide speculation for those who think or make crap up.

Kinda like the anti vaxors.

I agree doing a 10-20 min video to explain what D&T talked about in the OP would be very helpful in getting more people to understand the real issues with keeping a 1 MB cap going forward.

The profligate nature of your writing and speaking is eclipsed only by the content-less nature of both.  I swear to Christ I've never gotten so little out of a one hour podcast as I did with that thing I listened to the other day.  I'm not going to track down all your spam so pop up a link if you have one.

Speaking of the podcast (https://letstalkbitcoin.com/rss/pod-proxy/666.mp3) (with some fake accent guy who spent the last 10 minutes of his time doing jl777 a solid), what was really funny was that even with 40 minutes or so to burn you still deferred on trying to explain the OT thing because, supposedly, it was to complicated or some such.  Signing an XML is complicated?  Or tracking some sigs with a centralized server system?  Ya, OK.  Occam's razor suggests that you didn't want to try to describe it because it is lame and mostly useless.

I'm going to give you guys a little help understanding what is missing.  OK, so I make a 'contract' and break it.  What are you going to do?  Kick me out of your Ayn Rand fun-fort?  You need some sort of enforcement.  Fiat has it because they have a court system.  Bitcoin has a proof-of-work.  As far as I can see, OT has bunkus unless you somehow major visibility and I don't see that happening.  Maybe you could attach to someone with a user tracking and validation charger (e.g., CoinValidation) but I suspect they'll tell you to piss up a rope and just role their own instead of working with you.  You might offer your solution to Blockstream to try out for their federated kludge.  A proof-of-concept which does something useful probably wouldn't hurt OT any.

Let's not get sidetracked by sidechains and IBLT.

The first was demolished even by cypherdoc in his econ-for-trolls thread, whence half of you came. They wil be decimated by speculators within hours, as with gavincoin.

The second is a blatant move towards conformity and centralisation.
"With today's p2p protocol ..." https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 starts USGavin, preparing our arseholes for "tomorrow's p2usg protocol".

The old bitcoin foundation added and proposed a ton of other such ways to eventually con you out of your money too, such as multisig, timelock.

The new one has halted all such complications and is producing a purer form of the discovery that is bitcoin. Everything that makes sense stays, everything else...

Once the crust is removed, block size and all the other elements of bitcoin can be tested without interference from or reference to Gavin, Blockstream, anyone.

Podcast?

http://bitcoinism.liberty.me/2015/01/21/economic-fallacies-and-the-block-size-limit-part-1-scarcity/
http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/

Cypherdoc couldn't demolish a wet paper bag.  More than half of his bullshit is to absurd to even respond to.

And sidechains will be unlikely to be 'decimated within hours' if it takes days to excersize the peg.  For speculators who have the patience, well, as a BTC hodler, 'please don't throw me in dat der brier patch.'


Don't doubt it, but I've not seen any examples yet.  Nor have I looked real hard.  I was negative about the garbage because I felt it was risky and unneeded, but I've nearly come to the conclusion that I was wrong.  I'm open to being convinced otherwise, and it may be worthwhile if you guys want 5.3 since I'm glad to accept the labor savings of digging the arguments up for myself.


I'm naturally inclined toward Blockstream until someone points me to more credible contributors than Maxwell, Wuille, Back, Frie-whatever, etc.  Todd is up there and I'll carefully parse his input, but after watching things moderately carefully for a number of years now, it's going to take more than witty prose to make any seismic shifts in my orientation.  Especially since what these guys seem to be up to are things which have made sense to me for about forever.

Yes patience would be key.

I'm not one of the guys, or anyone really, but I'd guess they trust ben_vulpes, mod6 and asciilifeform more than most people previously known as core devs.

The whole thing has been tainted, and it's hard to know who in which camp is independent of mind or influence.

thank the good lord satoshi theres an ignore button ............
ahaaaaaaaaaa..........so much better

wuut?? this is a very enlightening video made by Peter Todd already more than a year ago.. guess the issue hasnt evolved pretty much..

BTW his site http://keepbitcoinfree.org/ in which the video was originally posted is now disabled..

no more keeping bitcoin free ???  :'(

source: https://bitcointalk.org/index.php?topic=208200.0

I just wanted to point out that Monetas / Open-Transactions is working on a solution that eliminates the need to trust third parties.

So the bulk of transactions could move off-chain to Monetas notary servers, and a notary would be unable to steal the coins, and would be unable to falsify receipts or change balances without a user's permission.

With the vast majority of transactions occurring safely off-chain on Monetas notaries, any user would still be able to perform on-chain transactions when necessary -- it would just be a lot more rare, and would usually consist of a transfer from one voting pool to another.

So keep your 1mb limit if you want, it will definitely benefit Monetas.

This. This is excellent.
Good work on explaining it this way.

With this post, you have done a great deed to support the Bitcoin long-term.

What? With Bitcoin, you already don't need to trust a third party. Why would this be different?

Sure you do. You need to trust MtGox and Bitstamp when you want to do market trading. And as this thread shows, you will soon need to do off-chain just for normal transactions (as a result of the 1mb limit.)

Well, you eventually need to trust someone. Also, off chain? I will not stop using Bitcoin because of the block changes.

If the block size remains at 1 MB, most of humanity will be forced by necessity to transact off chain.

The rationing is a form of artificially subsidizing off-chain solutions, causing them to see usage that they otherwise would not if people were free to choose between on-chain and off-chain transactions.

OT has many other uses besides financial transactions so it would be fine even if Bitcoin handled all the world's monetary transactions. If Bitcoin is not allowed to step up to the plate, however, OT (and other off-chain systems) would need to take up the slack.

That's not a particular great scenario. It'd hardly be better than the fragmented and high-friction financial system we have now.

I thought the point was to increase the block size limit to avoid having to use off chain transactions.

The block size limit should raised because off-chain transaction systems should not be artificially subsided.

If the limit is not raised, the more transactions will be pushed off chain which otherwise belong on the chain, which won't exactly kill the entire space right away, but as a plan B it's far inferior to allowing the distribution of on-chain vs off-chain transactions to find a natural balance.

dayum , floppies that were the timse man ! didnt know people actually still used them , and now i want to use them : >

I don't even think transactions will be pushed off-chain anymore than what is happening organically today. Yes, it is good that off-chain solutions develop, but they should attract user business on their own merits, not be a refuge for users who are forced there. Forcing users to do something stretches the network effect to its limits. Users will instead transact with a different cryptocurrency, and Bitcoin will hemorrhage market share.

Sounds like the OT technology might be a promising way to manage the internal accounting inside of a sidechain.  I'll be interested to see how it performs in such a capacity and might entrust a small fraction of my stash to a sidechain which employs it.  If they do other interesting things as well of course.

+1 And you will not find a single prominent proponent of a permanent 1 MB limit give a compelling counter-argument to this.

Makes you wonder whether those proponents regard Bitcoin hemorrhaging market share as desirable or as undesirable.

Is Bitcoin 'hemorrhaging market share'?  I hadn't heard.  Whatever the case, losing a lot of the users is a fairly desirable thing to me.  Users who want to use a very powerful technology such as Bitcoin to buy their morning coffee are a distinct liability to the system and are in the process of killing it right now (hence this thread.)

No alt I've seen targets the only use-case that I care deeply about nor seeks to address the main problem that Bitcoin has: too many idiot users.  The reason most alts don't have capacity problems is because they don't have users rather than any particular architectural design that they did right.  That is my sense since I've really not studied any of the alts very closely.  I liked some of the ideas in Litecoin when it first came out, but it was basically a regression from Bitcoin in the ways which were important to me.

In spite of it's rather severe design faults Bitcoin is still the leading contender as a reserve and balancing currency on the basis of it's first mover advantage alone, though it is also still better tuned for this duty than a lot of the alts.  Eventually a solution will emerge that makes use of the very powerful method of one simple layer of abstraction (main chain supporting many tuned, targeted, and non-critical subordinate chains.)  I hope it turns out to be Bitcoin which takes on this role and the core devs who organized under Blockstream seem to be thinking the same thing.  It's probably Bitcoin's only real chance of survival as a robust monetary solution which is independent of government control, and falling into that trap will ultimately kill off Bitcoin's value more than making user's pay what it's worth to use the system.

OP, Weren't you vehemently against raising the limit few years ago? I think I remember a lot of intellectual technical discussion around here involving you, gmaxwell and others regarding this matter. Around v0.0.9?

What changed?

I am personally very much against hard forks of such. However I am all in for new crypto with new parameter that considers how a previous crypto has lagged behind. From my point of view a hard fork with a lot of publicity to adhere to and "update" to keep up with is simply an act of how a few control the mass. Whether it is for a good reason or bad or whatever, It really breaks the original principles of decentralization and fairness. 

What do you think?

Okay, a lot of people appear to be talking without knowledge of how hard forks actually happen. 

The process starts with miners getting mining software that will understand and could produce blocks on the new version.  They start putting the new protocol version number into the blocks.  But they continue to produce blocks that follow the old protocol until the last 1000 blocks are 95% produced by miners that are putting the new protocol version into the blocks.  After that, the hard fork is enforced.  Two things happen;  they start using the new protocol, and they start rejecting any new blocks that have the earlier protocol number.   

Meanwhile, when the number of recently mined blocks showing a higher version number rises above 50%, any client with the old version will warn that it's on the losing side of an upcoming hard fork and a software update is required.

Here is an interesting thing about this split in particular; even when 95% of the miners start rejecting blocks for having too low a version number, there may not be an immediate split.  If this happens while we aren't bumping up against the 1MB limit, then the earlier clients will see nothing in the first few of the new blocks to object to, because all the new blocks (until a >1Mb block actually happens) are still acceptable to the existing clients.  So, until that time all that happens, from the point of view of the original clients, is that blocks bearing the original version number are getting orphaned by blocks bearing the new version number.

So any original-version blocks created during this time wouldn't wind up in their own block chain, they'd just get rejected, by the new clients for having too low a version number and by the original clients for having another perfectly-acceptable block chain get longer.  Even though the hard fork is being "enforced" by the new clients, it hasn't happened yet as long as the new blocks are acceptable to the old clients.  So any original-version blocks mined during this time are a dead loss for miners, regardless of which side of the hard fork they intend to be on.  Rather than mining at a dead loss, I expect that miners who haven't upgraded yet, mostly will. 

But after a while, a >1Mb block arrives, and the new version clients will build on it and the old version won't, so the hard fork actually happens.  Now the miners have a choice.  They could choose to mine on the new version or the old version.  Let's stack this up for a minute and see what the choice looks like.

The old version has already lost 95% of the hashing power before the new-version clients pulled the trigger by starting to reject old-version blocks.  Also probably lost at least 90% of whatever was left because miners don't like mining at a dead loss, so let's say they've got about one half of one percent of the hashing power.  That means they'd get a block about once per 33 hours.  A one-megabyte block every 33 hours.  Meaning, a limit of 1 transaction per 86 seconds.  Your transaction gets into a block in 33 hours, and it takes about ten days to get to the confirmation depth of 6 blocks.  If you get a coinbase transaction, good luck waiting out that 100 block depth until it's spendable.  It'll take over four and a half months.  Oh, but of course there are difficulty adjustments to make everything work right!  There sure are, every 2016 blocks.   Assuming you still have miners for that long, that takes over seven and a half years.  Taking the maximum reduction that the protocol can take, that'll quadruple the rate at which you get blocks. then you get up to 1 transaction per 21 seconds and you get another difficulty adjustment in 2 years, and another one six months after that, and another one just a month and a half later.  So we're up to about ten years later before the original chain gets back up close to one transaction per second.  This does not sound like a winner to me.

Meanwhile the new version takes off with 99.5% of the hashing power, and essentially flicks whatever holdouts and weirdos stick on the old chain off like an elephant shakes off a fly.  They are able to take 40 or so transactions per second, and the old-version chain, with its smaller crop of miners, is limited to less than one transaction per minute.

Seriously?  Seriously, you think staying on the original-version chain is a viable choice?  I invite you to do so; the rest of us will ignore you, except for the ones that care enough about your welfare to stage an intervention and tell you you're crazy and you need to get help.

DeathAndTaxes for president!

Well stated.  

I see a number of questions developing.  Here is one:

1)  Imagine you are a miner (pool operator) in, lets say, 2015.  You have a choice to include more TX to go over 1MB or not.  You know going over 1MB is better for the network, it has to happen, etc.  However, you also know there are some nodes on the network that might reject your block.  Your fiduciary responsibility is to your hashers.  Leaving out a few TX, with minimal fees, lets you stay neutral on the issue as all nodes will accept your block, and increases your chance of getting 25 large coin.  What do you do?  

Ok, so say we go ahead with a hard fork to a > 1MB max block size ... are we also going to see a couple of other hard forking issues put through all at the same time or will this one be done alone?

Could it become like those congressional bills where all the crap legislation gets stuck inside the fine print of the guns 'n drugs 'n terrroists 'n kids cover page?

I like Justus' pay-to-relay idea, but I'm having second thoughts about whether it would actually work.

Consider this thought experiment, there are three otherwise identical cryptocurrency networks. The total cost to do a trustless transaction is the tx fee plus whatever it costs to rent full-node capable hardware long enough to validate the transaction you receive.

A: 1mb block limit, $50 tx fee, validation cost: $0.05
B: 100mb block limit, $0.50 tx fee, validation cost: $0.50
C: 10,000mb block limit, $0.005 tx fee, validation cost $50

Which network do you want to receive payment on, assuming you don't trust the sender or any third party?  B. The reason B is so cheap, is that fees are inversely proportional to block size limit, but bandwidth costs are not linear. They're pretty flat until you get up to exotic speeds.

As Gavin pointed out, the optimal block size limit will scale with commodity bandwidth.

So, in the unlimited "pay to relay" model, what forces cause the price to converge at this optimal level? I'd suggest there aren't any. If nothing else, the block reward ruins it. The cost to relay will be insignificant until the block size is so huge, that it takes one of the world's fastest connections to transmit it. By then bitcoin is sunk, or at least depending solely on its head start rather than competing on features and price.

Miners have no reason not to accept all nonzero fees, no matter how large the resulting block is. They do not care if the large blocks knock commodity full nodes off the network. Users care! They'll just go to the hypothetical competing network that's the same, except much cheaper.

Now you could argue that miners are rational and wouldn't do anything to make bitcoin un-competitive.  I think that ignores the prisoner's dilemma that would come up.

Let's say all miners know that accepting tiny fees creates huge blocks, causing users to flee to cheaper networks. They don't want to harm their own operation, right?

Some miner will defect, and sweep all the tiny fees from the mempool, even though it creates a huge block. One huge block won't kill bitcoin.  Except the miners can't stop at just one. It will happen repeatedly, with no individual miner able to stop it from going down in flames. So they might as well defect themselves and collect every last satoshi while they can.

I think Gavin's got a solid plan. It's got ugly arbitrary constants, but it's simple and there's little doubt it will work.

miners also have an incentive for smaller blocks as they reduces their risk that it get orphaned.

miners also know that if they allow small fee transactions people will only pay a small fee. its still a prisoners dilemma with downward pressure tough.

Yeah, I'm kind of assuming the IBLT feature gets implemented so that nodes will already have all the tx's in the block, and the relaying after the block is found should be roughly the same speed no matter how many txs are in it.

Would we be able to filll enormous 10GB blocks with transactions if it costs $50 to relay and validate them? I think we wouldn't be seeing many bitcoin transactions if they cost $50 a pop, regardless of how many people use it.

If I'm not mistaken, there's also incentive for miners not to include no-fee transactions because they'd have to pay more to have their blocks propagated quickly.

It sounds like those are at least two of the market forces that would prevent 10GB blocks under justus' proposal.

Really? So that's why you are anti raising the block limit. Because you want to use Bitcoin for yourself and you piss on people who want to buy coffee using your powerful technology. It seems like this powerful technology is your new God and peasants aren't even allowed to say its name.

Who are you to decide who should use Bitcoin and who shouldn't? (I know you will not answer to this)

I said it in the other thread and I will say it again here: Bitcoin should be neutral just as the Internet and it should be available for everyone, not just to the highest bidders.

This is why they have to resort to misdirection and false arguments - if they actually told the truth openly it would be very obvious that they are a small minority and the supermajority consensus is against them.

The amount of hysteria being generated by the anti-scaling crowd is in direct proportion to the degree to which the consensus is against them.

I only see hysteria amongst the pro side.. ::)
Its you and his royal clueless roadstress that spreads fud and do nothing but fagocitating the debate with 'future' fear of bitcoin not scaling..

It is you that are actually scared and does not support bitcoin the way it is.

Please go ahead and fork that shit up.

Global consensus?! You wish..

It's interesting that you use this word. A phagocyte (http://en.wikipedia.org/wiki/Phagocyte) is a cell from our immune system that eats bacteria and other harmful creatures. So, you're saying that the pro side is actually defending against those who want to harm Bitcoin.

Proof of fud spread? I'm only advocating for a neutral bitcoin network without any constrains for anyone to use. Nothing else.


Please tell me how do you support bitcoin.


Ok.

The pro-progress crowd are actually supporting bitcoin because the block size cap is and always was temporary.

You haven't thought your comment through properly. :D

While in theory that is the most sensible idea, in practice, adding other changes will only slow down the implementation of what already has proved to be very contentious (yet shouldn't have been).

The hysteria is reached even into the bitcoin-development mailing list.

It's amazing how many high-profile names are extremely interested in forcing as many Bitcoin users as possible into trackable relationships with trusted third parties.

Might be worth a "Meet the Developers Who Want to Destroy Your Privacy" exposé.

could you share some of it here please?

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06992.html

Note the degree to which nobody is even willing to mention solutions to the presented problem other than trusted third parties (micropayment channels, etc)

That unwillingness to discuss alternate solutions is strong evidence that the proposals and supporting comments are agenda-driven, by an agenda that is not being openly stated.

Indeed and this fits with expectation for a couple of reasons.  The first is that P2PkH ("normal") transactions are the most compact.  For a given number of inputs and outputs any other script is going to be larger.  Even a relatively simple 2-of-3 multisig script is about 50% larger than a Pay2PubKeyHash script and there is a lot more potential than just straight multikey transactions.  The good news is that the complex scripts is where all the interesting innovation is going to come from.  Without the scripting Bitcoin wouldn't be programmable money it would just be digital cash.  Now a digital cash system is interesting but scripting is what allows doing interesting things in a trustless manner.  

Adding to that the average number of inputs and outputs per transaction has risen over time.  As the number of users increases the total number of outputs will also increase.  While individual transactions will vary for the overall blockchain the number of inputs and outputs will be roughly the same.  We can think of inputs and outputs as a single roundtrip script.  The other elements of the transaction are relatively small and fixed in size so:

Average txn size = (Script Complexity) * (Number of IO)

The bottom line is both elements of transaction size are increasing slowly over time.  Unless adoption dies off (in which case all this is academic) there is no reason to believe that trend will change anytime soon.  The good news is that average transaction size will probably not go above 800 or so bytes so I think a very conservative estimate of throughput is at least 2.0 tps per MB.

Nice to see other data points which line up with the OP.  500 bytes per txn would equate to 3.3 tps max per MB and 600 bytes would be 2.7 tps per MB.  In the OP I expanded that to cover the likely transaction size growth and to all provide a lower bound for an unrealistic but at least possible txn size.  Rounding it all out that is why most of the arguments revolved around a sustainable 2 to 4 tps (per MB).  If you read anything on the topic about scalability which uses values outside that range I would question the knowledge of the author.  I see lots of good intended articles which cling to the gospel of 7tps.

* As a side note in an optimal world there would have been no scripts in the output portion of the txn.  Output would just contain a 20 byte field to contain the ScriptHash.  All transactions would involve paying to a scriptHash and all addresses would be encoded ScriptHashes.  Even today the most common script would probably be P2PkH but it would "work" the same way as any other arbitrary script.  We probably are never going to change this but it could be done as a hardfork.  In addition to simplicity and consistency it would make the UTXO smaller with compact fixed length records  without any loss of functionality.  Related to that store outputs as a merkle tree and you could have intra-transaction pruning as well.

Heh.  It would be a good idea, for example, to add code that sweeps "dust" more than 8 years old (ie, starting with the very oldest dust, at the beginning of next year) into the miners' pockets.  If something has been sitting there for 8 years and it's too small to pay for the fees that would be needed to spend it, then it's useless to its present owner, burdensome to the whole network to keep track of, and ought to be aggregated and paid to miners for network security. 

But if you think the blocksize discussion is contentious?  Sweeping dust would make the ultraconservatives and ultralibertarians here absolutely foam at the mouth.  I'll not even suggest such a thing because the discussion would go absolutely off the rails.

I'd cheerfully go even further and "sweep" *any* output that's been sitting there for >20 years (ie, lost keys) into a "mining fund," then have the coinbase of each block take 0.001% of the current mining fund balance in addition to the block subsidy.  Anybody whose keys aren't actually lost can avoid the haircut by moving her funds from one pocket to another in a self-to-self transaction.

Hard forks are a thing for the protocol youth stage. HForks will become virtually impossible in the future as too many opinionated developers bash each other. My only hope is that the important scalability changes are made before there are too many dependencies. Ossification is rapidly approaching. 

I don't recall that being the case but I could be wrong (on other issues my opinion has changed over time :) ).  I do recall around that time (I assume you mean v0.9.0 not v0.0.9) the backlog of unconfirmed transactions was growing.  The reason is that while the soft limit had been raised the default value hard coded in the bitcoind was 250KB and most miners never changed that.  The only miners which were targeting a different size were targeting smaller not larger blocks.  Even as the backlog grew they felt no urgency in changing it.  Some uninformed people advocated raising the 1MB cap as a way to "fix" the problem.  I tried (and mostly) failed explaining that miners could already make blocks at least 4x larger and were opting not to.  Changing the max only allows larger blocks if miners decide to make them.  The developers ended up forcing the issue by first raising the default block size so that it didn't remain fixed at 250KB and them removing the default size all together.  Today bitcoind require you to set an explicit block size.  If you don't set one you can't mine.


I have to disagree.  Bitcoin is a protocol and protocols change overtime.  Constantly reinventing the wheel means a lot of wasted effort.  You end up with dozens of half used systems instead of one powerful one.  Look at TCP/IP or even HTML.  Yeah they have a lot of flaws, they also have a lot of early assumptions backed in which produce inefficiency.  Evolution is also hard. Look at the mess of browser standards or how long the migration to IPv6 has taken.  Despite the problems the world is better for having widely deployed protocols in favor on constantly starting over.  

In the crypto space however 'starting over' means a chance at catching lightning in a bottle and becoming insanely rich.  That has lead to a lot of attempts but not much has come from it so far.  Alternates are an option but they shouldn't be the first option.  The first option should be evolution but if a proposal fails and a developer strongly believes that in the long run the network can't be successful without it then it should be explored in an alternate system.  There are some things about Bitcoin which may be impossible to change and for those an alternate might be the only choice.  The block size isn't one of them.

Jumping specifically to the block size.  The original client had no* block size limit. The fork occurred when it was capped down to 1MB.  The 1MB has in some circles become a holy text but there isn't anything which indicates it had any significance at that time.  It was a crude way to limit the damage caused by spam or a malicious attacker.  It is important to understand that the cap doesn't even stop spam (either malicious or just wasteful).  The cost of mining, the dust limit and the min fee to relay low priority txns are what reduced spam by making it less economical.

The cap still allowed the potential for abuse but the scope of that abuse is limited.  If 10% of the early blocks were maxed out it would still have added 5GB per year to the blockchain size.  That would have been bad but it would have been survivable and would have required the consent of 10% of the hashrate.  Without the cap a single malicious entity could have increased the cost of joining the network by a lot more.  Imagine if before you even knew about Bitcoin and the only client was the full node that to join the network would have required downloading 100GB or 500GB.  Would Bitcoin even be here today if that had happened?  

Satoshi stated in the white paper that consensus rules can be changed if needed.  He also directly stated that the block limit was temporary and could be increased in the future and phased in at a higher block.  Now I am not saying everything Satoshi said is right but I have to disagree that the 'original principles of decentralization and fairness' preclude changes to the protocol.  Some people may today believe that any change invalidations the original principles but that was never stated as an original principle. The protocol has always been changeable by an 'economic majority' and the likewise that majority can't prevent the minority from continuing to operate the unmodified protocol.  It is impossible to design an open protocol which can't be changed however as a practical matter a fork (any fork) will only be successful if a supermajority of users, miners, developers, companies, service providers, etc support the change.

There are four universal truths about open source peer to peer networks:
a) It is not possible to prevent a change to the protocol.
b) A change in the protocol will lead to two mutually incompatible networks.
c) These parallel networks will continue to exist until one network is abandoned completely.
d) There is no mechanism to force users to switch networks so integration is only possible through voluntary action.

There is a concept called the tyranny of the minority.  It isn't possible for a protocol to prevent changes without explicit approval of every single user but even if it was that would not be an anti-fragile system.  A bank could purchase a single satoshi, hang on to it, and use that as a way to prevent any improvements to the protocol ensuring it will eventually fail.  The earliest fork fixed a bug which allowed to the creation of billions of coins.  There is no evidence it has universal support.  The person who used it to create additional coins saw the new version erased coins that the prior network declared valid.  Still a fork is best if either a negligible number of people support it or a negligible number of people oppose it.  The worst case scenario would be a roughly 50-50 split and both forks continuing to co-exist.  

The original client did have a 33.5MB constraint on a message length.   It could be viewed as an implicit limit on block sizes as the current protocol transmits complete blocks as a single message.  There is nothing to indicate that Satoshi either intended this to be permanent or that it was a foundational part of the protocol.  It is a simplistic constraint that prevents an attack were a malicious or bugged client sends nodes an incredibly long message which needs to be received before it can be processed and invalidated.  Imagine your client having to download an 80TB message before it could determine that the message was invalid and then doing that a dozen times before banning that node.  Sanity checks are always a good idea to remove edge cases.

He didn't even need to state that, anyone can start an alternative network that forks from the existing one. Whether the majority follows the changed fork or the unchanged fork is immaterial.



What you mean is, you can't prevent other people from using a different protocol.

They can't change YOUR protocol, but they can leave you all alone with few other people (or none) to talk to.

Still you have a choice. You can accept a smaller consensus. Let's say someone forked bitcoin to change the rules so that instead of 21 million coins, an infinite number would be produced (25 coins per block forever, for example). And let's say 90% of bitcoin users accepted that fork.

If you don't want to accept this change, all it means is, your consensus size shrunk, probably back to 2011 levels. Personally I would accept this before infinite coins.

Just because you lose 90% of the consensus doesn't mean you'll eventually lose 100% of it.

That is why the 1MB limit is the single most important threat to Bitcoin, because ossification is rapidly approaching. The limit can irreparably damage Bitcoin's future growth, its winner-take-all honey-badger image. Its default status as an "electronic gold" store-of value is badly tarnished if it can be allowed to run into a brick wall when there was years of warnings, threads and discussions beforehand. For non-technical supporters and investors the fear will remain that other major problems are latent and ignored.

Some people argue against increasing the limit because they "want Bitcoin the way it is now", that "it is working fine". The reality is counter-intuitive. The way it is now is that it has no effective block limit, and that allowing the average block size to approach 1MB is to introduce a massive untested change into every full node, simultaneously. I say untested because the only comparable event was the 250KB soft-limit which rapidly went wrong, and the major mining pools had to come to the rescue and increase their default block limit. With the 1MB the number of nodes which need to quickly upgrade is several thousand times larger. Chaos.

People are worried about government action, yet for every government which tries to ban Bitcoin another will give it free rein, for every government that wants to over-regulate it, another will decide upon regulation-lite. The threat is from within, not without.

Off-chain solutions are developing. An Overstock purchase by a Coinbase account holder does not hit the blockchain. There must be many business flows which are taking volume away from the main-chain. But this is not enough to stabilize the average block size.

Challenges are also opportunities. A successful hard fork, executed as Gavin suggests with a block version supermajority, will take many months and allow a smooth transition to a scaling state. Hard forks on the wish list, and ideas like stale dust reverting to the miners, (if there is majority consensus) will be seen as achievable. Ossification might be delayed a little to allow other hard-fork improvements if this first challenge is successfully handled.

The block limit increase may eventually pass as an intentional hard fork for good reasons, but I think it is not relevant for the long term fate of Bitcoin, the digital gold.

It would be naive to assume that the block size limit is the last feature we need to change to ensure eternal prosperity for Bitcoin. We will hit other limits or yet unknown issues and the problem will repeat, but by that time we will have even less, likely zero, chances to orchestrate a hard fork.

The block chain as we know bootstrapped the digitial gold, but is unlikely its final home. We have to restore the ability to innovate and enable individuals to express their opinion by moving their digital gold to a side chain they prefer for whatever reason.

I know it was simpler if one was not forced to compare alternatives but simply HODL, but that is unfortunatelly orthogonal to innovation and diverse needs of a global adoption.

sweep the dust thats too small to transact  but anything substancial should NEVER be swept imo
some people , maybe even satoshi has left the early  blocks in a will to the kids or grandchildren etc

we have to remember that dust today might be a enough to buy a lamborghini in 50 years

others maybe young and keeping cold storage for retirement while working on other projects sway from bitcoin

i dont think wallets should be "reposessed under any circumstances " even if they appear to be abandoned for years

if we did that it would be a matter of time before someones wallet got reposessed then owner  later tried to claim it

What's the problem with that?  You've never heard of Moore's law?  It's the universal faith-based psycho-engineering solution in these parts, and it seems to work fine on a lionshare of the participants.  Normally simply uttering the two words is sufficient to win any argument (hollow though the victory may be.)

You want to point fingers about hostility?  I think you'll find this discussion started because MP accused (http://trilema.com/2015/if-you-go-on-a-bitcoin-fork-irrespective-which-scammer-proposes-it-you-will-lose-your-bitcoins/) Gavin of being a scammer and saying there was no way under any circumstances that he would accept a fork.  If we had set off on a more polite note, something along the lines of "let's weigh up the pros and cons and come to some sort of compromise", then maybe things would have gone a little differently.

(or on another chain)

It costs mining pools nothing *now* to process transactions.  And in fact they are not even required to fill blocks up with transactions, there are empty blocks produced all the time.

Minimum fees can be set regardless of block size.

I don't think, that is true. Looking at the last blocks, they all had transactions in them.
Could you show me one of this recent 0 transaction blocks?

Yeah it does happen occasionally. Though of course they have the 1 transaction, which is the coinbase one.

That is correct.  There are no zero txn blocks because a block is invalid without a coinbase so people saying 'empty' blocks are referring to a block with just the coinbase txn.  This will occur periodically due to the way that blocks are constructed.  To understand why one needs to dig a little bit into what happens when a new block is found.  

A pool server may have thousands of workers working on the current block when a new block is found making that work stale. The server needs to quickly update all its workers to 'new work' and the longer that happens the more revenue that is lost.  If a new block is found on average in 600 seconds and it takes the pool just 6 seconds to update all its workers than its actual revenue will be 0.5% lower than its theoretical revenue.   So pools want to update all their workers as quickly as possible to be as efficient as possible.

To update workers to work on a new block the server must remove all the txn confirmed in the prior block from the memory pool, then organize them into a merkle tree and compute a new merkle root.  Part of that merkle tree is the coinbase txn which is unique for each worker (that is how your pool knows your shares are yours).  A different coinbase means a different merkle tree and root hash for each worker which can be time consuming to compute.  So to save time (and reduce stale losses) the pool server will compute the simplest possible merkle tree for each worker which is a single txn (the coinbase) push that out to all workers.  Compute the full txn set merkle tree and then provide that to workers once they request new work.  However if a worker solves a block with that first work assigned it will produce an 'empty' (technically one txn) block.

This is just one example of how a 1MB limit will never achieve 1MB throughput.  All the numbers in the OP assume an upper limit which is the theoretical situation of 100% of miners producing 1MB blocks with no orphans, inefficiencies, or stale work.  In reality miners targeting less than 1MB, orphans, and inefficiencies in the network will mean real throughput is going to be lower than the limit.  VISA only has an average txn capacity of 2,000 tps but their network can handle a peak traffic of 24,000 tps.  Nobody designs a system with a specific limit and then assumes throughput will be equal to that upper limit.

That is a very valuable observation.  An 'adaptive' block size limit would set a limit of some multiple of the observed transaction rate, but most of its advocates (including me) haven't bothered to look up what the factor ought to be. what you looked up above presents real live information from a functioning payment system. 

The lesson being that an acceptable peak txn rate for a working payment network is about 12x its average txn rate. 

Which, in our case with average blocks being around 300 KB, means we ought to have maximum block sizes in the 3600KB range. 

And that those of us advocating a self-adjusting block size limit ought to be thinking in terms of 12x the observed utilization, not 3x the observed utilization.

The ability to handle a large block is a functional topic; e.g. apparently there is an API limit which will force blocks to be transmitted in fragments instead of one large block.  If we want blocks larger than this limit then we have no choice but to do the code to handle fragmenting and reconstructing such large blocks.  Having an artificial block size maximum at this API limit is necessary until we do that code.  Alternatively I suppose we could look at replacing the API with another one (if there even is one) that can handle larger blocks.

The desire/need for large blocks is driven by the workload.  If the workload is too much for the block size then the backlog https://blockchain.info/unconfirmed-transactions (https://blockchain.info/unconfirmed-transactions) will grow and grow until the workload subsides; this is a trivial/obvious result from queuing theory.  Well, I suppose having some age limit or other arbitrary logic dropping work would avoid the ever-growing queue but folks would just resubmit their transactions.  Granted some would argue the overload condition is ok since it will force some behavior.

I, for one, would recommend avoiding all fancy logic for an adaptive block size; just set the maximum block size to the API maximum and be done with it.  I also recommend hurrying up to figure out the code to fragment/reconstruct blocks bigger than that.

All of this is largely independent of figuring out how to suppress spam transactions.

What is the point of this? The contiguous "block" is just an artifact of the current implementation and will soon be obsoleted.
On the storage side the database schema will change to support pruning. On the network side the protocol will be updated to support more efficient transmission via IBLT and other mechanisms that reduce duplication on the wire. In both cases the "blocks" will never appear anywhere as a contiguous blobs of bytes.

If one wants/needs to transmit a block of transactions that a miner has discovered that meets the required difficulty then one calls an API to do it.  That API has a maximum size.  If the block is larger than that size then the block is chopped into pieces and then reassembled at the receiving end.  Whether the block is held in a single contiguous buffer is irrelevant although almost certainly common.

The point is until the code do the chopping and reconstruction is ready blocks are limited in size to the API maximum.  Given a large enough sustained workload, i.e. incoming transactions, the backlog will grow without bound until there's a failure.  Having Bitcoin fail would not be good.

At this time the software handles blocks up to 4GB and has been extensively tested with blocks up to 20MB.  So there's not really a problem in terms of API, nor a need to chop discovered batches of transactions up into bits.

The problem is sort-of political; there are a bunch of people who keep yelling over and over that an increase in block size will lead to more government control of the bitcoin ecosystem (as though there was ever going to be an economically significant bitcoin ecosystem that didn't have exactly that degree of government control) and that they don't want just any riffraff in a faraway country to be able to use their sacred blockchain for buying a cuppa coffee (as though allowing anybody anywhere to buy anything at any time somehow isn't the point of a digital cash system).

Neither point makes any damn sense; As I read the opposition they fall into three groups, the Trolls, the Suckers, and the Scammers.

The Trolls know the arguments are nonsense and are yelling anyway because it makes them feel important. 

The Suckers don't know nonsense when they hear it and are yelling because they're part of a social group with people who are yelling.

The Scammers have thought of a way to make a profit ripping people off during or after a hard fork, but it won't work unless there are Suckers who think that the coins on the losing side of the fork aren't worthless, so they keep yelling things to try to keep the Suckers confused as to the facts.

Ah, that's plenty big for now; has it been tested?  If blocks that large can reliably be put through consistently then that would easily handle 10k transactions/second.

As I said, 20MB has been extensively tested.  4GB is okay with the software but subject to practical problems like propagation delays taking too long for blocks crossing the network.  4GB blocks would be fine if everybody had enough bandwidth to transmit and receive them before the next block came around, but not everybody does. Right now I wouldn't expect the peer-to-peer network to be stable with blocks much bigger than about 200MB, given current bandwidth limitations on most nodes. 

Are you talking about the legacy peer-to-peer protocol in Bitcoin Core or about the new, sensible implementation from Matt Corallo?

https://bitcointalk.org/index.php?topic=766190.0

lol, so true!

I just wanted to bump this great article for its lucid explanation of why the blockchain needs to grow.

OP Very interesting topic DeathAndTaxes, where are we at the moment, whats the avg number of transactions per second for lets say the last month and what was the avg 6 months ago and a year ago as a comparison ?

The maximum message size of the p2p protocol is 32MB, which caps the block size implicitly in addition to the explicit 1MB limit.

Beyond all other insanity, 4GB blocks would be completely worthless due to the sigops limit.

Very long read OP, but well worth it. As I see some old coins like Litecoins have effectively 4MB limit for 10 minutes, so I dont understand why the 1MB limit for 10 minutes defend so many people (looking at the 20MB Gavin fork pool)

https://blockchain.info/block/00000000000000001672c2c047085db722e577902c48d018cd88f1d46359fa28


Just an example. There is heaps of empty blocks. That's why anyone saying it would be urgent is a douchebag and likely has some other agenda.

That's because the miner chose to not include any transactions in the block, except the coinbase one of course. It doesn't mean there wasn't any waiting in the memory pool.

Ah. Snagged by an MP sockpuppet!

there is no realistic scenario where plastic card with 1960 chip on it can have meaningfull adoption.

Wait ... mmmmmh ?  ::)

We obviously need a bigger block size if we want to challenge the big payment electronic systems. My main concern is that the people running nodes could be severely decreased due the blockchain being bigger than ever.

Exactly. Absolutely correct if the plastic card was stuck with an embarrassing 2.7tps like bitcoin.

Actually the analogy would be to limit the credit card industry to the mainstream data processing technology of the 1940's namely tabulating machines and punch cards. The pre-dates 1) Integrated circuits, 2) Transistors, and 3) The use of vacuum tubes in computers.

Edit: The credit card number would be copied by hand for each transaction.

If we wanted to challenge the big payment electronic systems it would not be decentralised because the multi-node redundancy scales like O(N), N- number of node sites, i.e. it gets expensive rapidly.

Compare with SWIFT or Fedwire for something relevant, at this stage of technological development (one day it may be possible that all google's data is stuffed into the blockchain, not today).

Why don't we simply increase the limit to 2, 3 or 4MB and have a year or so for drama to improve performance?

ever heard of sidechains? not every offchain solution means "evil bank, centralised, regulate-able, monstrosity." In fact, confidential transactions means better privacy than the current way of doing things on-chain.

Therefore

Keep blocks small? 

No, this is literally the first time anyone has mentioned them ever.   ::)

Ever heard of things that actually exist and are proven to work?  Because sidechains aren't ready yet.  Still in development.  Not functional.  Untested.  How many more times are people going to keep saying the same damn thing like it's some sort of fantastic solution no one has considered?  Yes, sidechains would be great if they were an actual thing.  But they aren't.



Keeping blocks small is not an option.  We've never attempted to run the network with full blocks before and clearly you don't understand the implications of doing that.  At present, if you pay a fee, your transaction is pretty much guaranteed to be included in the next block.  If you don't include a fee, you may be left waiting.  This is how the network has operated since inception.  But if blocks are full, even if you pay an average fee, there may be insufficient space to be included, so you're left to guess what fee needs to be paid at any given time.  This amount will not only vary depending on traffic, but will also be difficult (if not impossible) to accurately forecast.  Every transaction would be a guessing game as to whether it is confirmed in the next block or you have to wait.  If you guess incorrectly, keep waiting.  This level of uncertainty and risk is frankly unacceptable and would undoubtedly impact adoption in a negative way.  Not to mention the forums here would be an endless shitstorm of people whining about delays, saying "Bitcoin is slow and broken".  Attempting to run the network at full capacity is not a desirable outcome for anyone.  Keeping a 1MB blocksize is not viable because no one wants to play guessing games when it comes to time and money.

Yes you're right, let's make it 20x larger and break the consent based process we have relied upon until now. /s

I'm fine with increasing it to the 8MB suggested by many. I'm aware that the 1MB limit is arbitrary.

So, you're against 20 MB because not everyone agrees, but you do want 8 MB, even if not everyone agrees? Isn't that a contradiction?

I'm for 8 because it seems that more people can agree on that. Thus less threat of division.

It's not always about what people want now, it's what those people may need in the future. Isn't it better just to go with the 20 MB, rather than having the possibility of having to make another change soon after?
There is far more damage done by arguing about this, than the 20 MB could of caused, imho.
cheers

I agree with it  :D

I should just leave this here:
https://i.imgur.com/CkDJYfu.png

It's quite obvious that 1MB won't be enough pretty soon IMO. However, 20MB might be a bit too much at the moment. Although we might just end up discussing(wasting our time) again.
We are very near to seeing full blocks. It shouldn't take us much longer as we already have an average block size of 0.6MB.

We obviously need to increase block size. Many of them doesn't want to increase maximum size to 20MB is because most nodes will go down due to low space but I doubt we will reach 20MB in the near future. However, a limit was placed to prevent a few problems such as DOS and I think Bitcoin has still not overcome that problem. So I guess increasing block size to 8MB(which is accepted by most) would be good.

This is my issue as well.  If the blockchain.. when the block chain reaches 1 TB.. there will be issues with everyone running a node..

IT would appear the size of the blockchain is out pacing the upgrade in harddrives...

No. No. And just no, stop saying this if you don't want to be seen as a intentionally misinforming.

The size of the blocks is, and has always been, bandwidth limited.

One bitcoin buys about 6 TB of hard drive.

I'm not sure if you are kidding, being disingenuous or just a simple smart-ass trolling. Buying a hard-drive doesn't get you more bandwidth (did I really just need to say that??) .... now would you like to quantify 'about' how much bandwidth 1 bitcoin buys you?

My reply was actually directed at spazzdla but I quoted your post too since I couldn't tell if you were serious or sarcastic.

Here in British Columbia, and according to these numbers (http://www.cbc.ca/news2/interactives/broadband/index.html) from 2013 ($0.45 / GB), 1 bitcoin buys you about half a TB of bandwidth.

Unfortunately not all bitcoin nodes are located in British Columbia, as lovely as it is.

Does anyone know of a comprehensive summary of bandwidth costs across the world, as well as typical upload and download bit rates?

Well that would be the real research that needs to be done wouldn't it ... so probably not, at least I haven't seen it. And you would then need to see how that translates into real bitcoin data being passed around on the real bitcoin network.

I found some excellent data.  Ookla has been empirically measuring upload and download speeds for over a decade and from all over the world, based on its speed test results:

http://explorer.netindex.com/maps

The pricing information is lacking, however.  

Price hasn't changed much over the years once people transitioned from dialup to broadband in many places.

Here is a breakdown I did elsewhere -