Yes, those transactions that pay higher fees will go first.

However, the capacity of the network is ~0.8 MB (~1500 trasactions) every 10 minutes.  If there is 1.6 MB of transactions (~3000 tx) in the queue, half of them will miss the next block, even if each of them is paying 1 BTC of fee.  

Fees can only decide which transactions will get served first; no matter how high they are, they cannot reduce the average waiting time -- not even by 1 second.

Moreover, it will not be "a little longer".  If clients (all over the world, independently of each otehr) are issuing 3000 transactions every 10 minutes, at most 1500 of them will be processed in the next block.  The other 1500 will go into the queue, adding to the backlog; and will be confirmed only after the traffic again drops below 1500 tx/block.  Even then, if the demand drops to 1300 tx/block, the the backlog will be cleared only at the rate of 1500 - 1300 = 200 tx/block.  

So, a surge in demand that lasts a couple of hours can take many hours to clear.  A large percentage of the transactions will be delayed until the backlog is clearing. Even if most transactions are paying high fees. The average time to first confirmation, which was ~10 minutes before the jam started, will then jump to several hours.

Even if tools like replace-by-fee (RBF) and child-pays-for-parent (CPFP) are available, they will not reduce the average waiting time by a single second.  If you use RBF to push your transaction to the front of the queue, so that is gets mined in the next block, some other transaction that was expecting to be in that block will be pushed to the second-next one, and another that was to be in the latter will be pushed to the third next block, and so on.  

If your transaction got into the backlog (and there is a significant chance that it will, no matter what fee your smart wallet chose), there will be thousands of other clients, just as impatient and wealthy as you, that will try to get their transactions ahead of yours, using those same smart wallets and fee-adjusting tools too.  So, after you sent your payment for your shuttle flight, or to reserve the last room in that hotel in Paris, you will have to keep checking the queues, increasing the fee of your transaction, maybe for hours -- only to wait until the backlog is clearing, anyway.   With a high probability, you will pay a lot more, only to wait much, much longer.

If the average demand is greater than the capacity, the backlog of unconfirmed transactions will keep growing forever and will never clear.  A fraction of the transactions will fall off the end of the queue, after sitting there for hours or days, and will never be confirmed. The average waiting time will then be infinite.

To summarize:

If the average demand is much less than the capacity, there is no fee market: all transactions that pay minimum fee will be processed in then next 10 minutes.

If the average demand is close to capacity, it will be greater than capacity during peak hours or days; then a growing backlog will form until the demand subsides, and the average waiting time will shoot up from 10 minutes to hours.

If the average demand is greater than the capacity, the backlog of unconfirmed transactions will keep growing forever and will never clear.  The average waiting time will be infinite and some transactions will never confirm.

Any bitcoin developer who wants to see bitcoin develop a "fee market" is either incompetent, or does not care about its users.

Hm, why are people euphoric about BIP100 superseding BIP101?

AFAIK, there is no implementation yet of BIP100, and its details are not even fully specified.  (Is there one?)

Moreover, BIP100 will allow blocks larger than 1 MB, won't it?

Moreover, BitcoinCore does not implement BIP100, and so fat Blockstream has been totally opposed to any increase.  So, if BIP100 gets into effect, it will be by some other implementation, right?.

Am I missing something?

Can you say exactly why the transaction would be valid only on that branch?

Well, sorry, that is religion, not science or engineering...


Big blocks will be rejected only by players running BitcoinCore (or some other small-blockian software).


That is exactly my point: the word "invalid" is meaningless by itself.  Things are valid or invalid only according to some standard, software, person etc.  2 MB blocks are valid for all clients and miners who are running any version of the Bitcoin software that accepts them.


No, Litecoin's blockchain started with its own Genesis block on 13 October 2011.  There is no block that is shared by the two chains.


Yes; just as any transaction that uses utxos tainted by coinbases of blocks in the small-block branch will execute only on the small-block chain. 

But only sophisticated users will know that, and only they would be able to exploit that feature to work with each coin independently.  (How would you get your own pre-fork coins tainted that way?)


Indeed you did, but then you concluded that BIP101 "gives us 8192 MB blocks in 21 years".  It surely will NOT, just as Satoshi's original implementation did not give 32 MB blocks in 2009, and the reformed one did NOT give 1 MB blocks in 2010. 


And why would he do that?  Why didn't miners create 32 MB blocks in 2009, or 1 MB blocks since 2010?

Bigger blocks take longer to propagate and have a slightly higher chance of being orphaned.  There is no advantage for a miner to pad his blocks, and a slight disadvantage.

Moreover, a miner who, for some reason, wished to fill his blocks to the limit cannot broadcast his spam to the network, because some other miner could mine it and take the fees.  But then everybody will realize that those extra 7.5 MB is spam that he created himself.  Then his peers, even without explicit agreement, could decide to ignore his blocks and orphan them.


I do not argue in favor of BIP101.  A substantial increase in the block size limit before the end of the year is obviously necessary to keep bitcoin working, as it has so far, for a few more years.  Any software that does that will do. 

However, it seems that the only way that will happen is through software that is not controlled by Blockstream.  People who care about bitcoin's future should try to become independent from the BitcoinCore version.

That is not "Bitcoin's point of view".  Please admit that there will be two (or more) implementations of bitcoin, each intending to be "the" Bitcoin.  It is not objective or technically productive to decide from the start that the Core version is the right one, and the others are altcoins, no matter how much support each version gets.

Besides, the precise software that miners are running, what formulas they user, how they trigger the changes, what is their schedule for the following year -- all that is irrelevant.  The only thing that matters is how many miners accept blocks greater than 1 MB, and how many reject them.  So, instead of "XT" and "Core", it is better to say "big-blockian" and "small-blockian".  

(Let's assume that there are only two size limits competing, say 8 MB and 1 MB. Things are already complicated enough in that case.  If there are three or more candidates for the limit, then it matters how many miners choose each candidate.)


Of course not; that is the longest valid chain *only for Core*.  For implementations that accept bigger blocks, bigger blocks are (of course) valid, so the longest valid chain may be a different one.



Just as they won't mine "Adam's coin" once they find that no one wants it any more.


Er, um, a mathematician would agree, I guess.  Their blockchains share zero blocks, and zero is a number, too.


In theory perhaps the two coins could survive with separate identites.  In practice, that will be extremely unlikely.

It will not be easy to use the two chains independently, because all transactions are in principle executed on both chains.  (That is another reason why they cannot be called "altcoins".)  Only transactions that spend coins mined after the fork will be executed exclusively on the same branch.  So it will be difficult to find buyers and exchanges for each coin separately.  Rather, just as miners will want to have a common size policy, the exchanges will want to accept the winning version only.


Sigh, it wlll NOT give 8 MB blocks next year, nor 8 GB blocks 21 years from now.  Those are block size LIMITS.  Bitcoin had a 32 MB block size LIMIT for almost 2 years at the beginnig, but teeny weeny block SIZES.  In fact it had a 1 MB size LIMIT since then, and yet the average block SIZE is still 0.45 MB.

It is sickening to see the small-blockians invariably replace LIMIT by SIZE in their arguments.  Who is being disingenuous?

If the block SIZEs ever get close to 8 GB, it means that the traffic is 15'000 times what it is today, which ma mean a user base of hundreds of millions. Then of course the block size LIMIT would HAVE to be greater than 8 GB.

Anyway, 21 years is a long time.  Who would have imagined the Chinese mining farms, a mere 6 years ago?

But I do agree that BIP101's schedule is stupid: it is silly to plan parameter changes several years in advance, when no one knows even whether bitcoin will survive to next year.  The block size limit should be raised to 8 MB (say) as soon as practical, but without any automatic increases thereafter.  If an when the blocks start to get more than 30% full (say) the limit should be raised again by another hard fork, to the appropriate size.  Hopefully there will not be opposition, that time.

IIRC Luke Jr commented approvingly on reddit (but he admitted that, if XT gets the majority, then it is references to Core that should be censored instead.  I haven't seen any Blockstream guy condemn it. 

And it is not "moderation", but plain censorship, and banning users by the dozen.  They even changed the CSS to suppress reddit's "[deleted]" placeholders (so that the comments often do not seem to make sense). 

Not an inch different than what Pravda's editors would do in the good old days of the USSR.  Or the military government did here 1964-1984.


Of course I do. It is the difference between those spreading baseless FUD, and those repeating it without bothering to understand and check it.


Well, you keep your opinion, I'll keep mine, thank you.

Well, can you say more specifically what is wrong with that quote?


Yes, I know that they intend to use congestion to their advantage, and have explained their plans many times.  That is one of the things that determined my view of them.

Just an ordinary professor.  I cannot do miracles.  If students just repeat any bullshit that they read, without thinking critically, I cannot help them...


The "fee market" idea is nonsense in so many levels that I don't know where to begin. I give up.

Bitcoin's story is "nerds and libertarians learning the basics of how the world works, the hard way".  The "fee market" will be another lesson: "how to manage a lemonade stand."

You mean Lightning Network?  I am anxiously waiting for such "refined" proposals.  Hopefully with numbers on them -- which so far seem to be curiously absent from Blockstream plans.


Well, His majesty King Adam just conceded "2 MB now, then 4 MB in 2 years, and 8 MB in 4 years" -- and only then Gavin will be permitted to raise his hand again.  

Except that it would be very difficult for ordinary users to get their trasactions executed in one chain only.  In principle, every transaction that gets issued, with any version of the software, will be seen by both sets of miners, and both will accept it as valida and try to include it in their blocks. 

The common view that the big-blockian branch will be "an altcoin" is incorrect; it is part of the FUD that Blockstream is using against the limit increase.  It will be no more an altcoin than the forks that happen now 2-3 times per day, and end with one block being orphaned.

If the size limit fork starts with at least 75% big-blockians and no more than25% small-blockians, as BIP101 tries to ensure, the small-blockians will be unable to process all the traffic in a timely fashion.  Mst transactions will pile up in the small-blockian queues, where they may remain for up to two months.  Meanwhile, the big-blockian miners will still be able to confirm every transaction with average delay 10-20 minutes.  That is one reason why the small-blockians will want to switch as soon as possible, if they realize that they are a minority.

Amazing generosity... 

Seeing that Blockstream rejected even Jeff's 2 MB attempted compromise proposal, it is undeniable that they don't want ANY incerase in the block size limit at all.  Their concerns about the effect of big blocks on nodes are just excuses.  In fact, they have clearly stated their plan for bitcoin: get the network into congestion so that users are forced to compete for space in the blocks by raising the fees.  Until most peer-to-peer traffic is driven out to off-chain solutions, leaving only high-value traffic on the blockchain -- such as settlements between hubs of some "overlay network".  Some Blocstream devs mumbled about fees in the range 10--100 USD per transaction...

Blockstream's plan makes no sense to me, and neither to Gavin and Mike.  I thought that Blocksream may have some secret agenda that justified wreching bitcoin, but maybe they are just unable to do such quantitative analyses and genuinely believe that their plan will work.  Gavin says that he has tried to convince the Blockstream devs to increase the limit for a long time, byt they refused. 

The 20 MB of Gavin's first proposal, and the automatic increases of BIP101, were clearly motivated by the FUD that Blocksrteam planted about hard forks (which in fact are not technically different from the soft forks that Blockstream likes).  A single increase to 8 MB, that the Chinese pools considered acceptable, would have been good enough; but critics would say that it would require another hard fork, a few years later.

No, sorry to disappoint you, it doesn't threaten my sponsorship at all.  On the contrary, if I were to assimilate into the Borg I could perhaps make some good money on the side by consulting for bitcoin startups, like Antonopoulos at Neo & Bee; or for some cryptocoin "better than bitcoin", like Peter Todd at Viacoin.


I am not pushing for XT.  I am only pointing out that driving the network into congestion will render bitcoin unusable for the only purpose that it was designed for, and vulnerable to relatively cheap spam attacks.

The block size limit must be raised: that is just an obvious technical conclusion.  It doesn't matter which software is used, as long as it allows blocks to grow ahead of the the demand, and leaves enough spare capacity in the network to make spam attacks very expensive for the attacker.

(While I don't have particular admiration for Gavin and Mike, I do think that Blockstream are the bad guys in this war.  They have been using every dirty trick to preserve their control of the protocol -- from FUD, DDoS of XT sites, and censorship of /r/bitcoin, to posting anti-XT messages on /r/buttcoin while pretending to be legitimate buttcoiners.)

(Moreover, Gavin and Mike seem to be competent software engineers, whereas the Blockstream guys may be really unable to understand why congestion is bad, why the fee market will not work, and why LN will not be economically viable.  As Napoleon would say...)


Are you referring to the stock market?  Where did you get the idea that I "champion" derivatives and complicated financial instruments?  I dislike them for the same reason that i dislike bitcoin-as-investment: they are either gambling or swindles, depending on whether the losers understand what is going on or not.


Well, since my salary comes out of the sales tax of the State of São Paulo, I must admit that you got that part right.  


[/quote]

As a comp sci prof, I don need any excuse to take an interest in computer science projects, and debate them in forums and such.  But I also consider part of my job duties to advise the taxpayers who pay my salary about computer-related risks and scams; and surely you must agree that "scam" and "risk" command very big fonts in the bitcoin word cloud.


Like any species or company, bitcoin must be able to evolve, or it will become extinct.  Bitcoin would still be unquestionably bitcoin with 1 MB size limit or with 8 MB limit, just as it was bitcoin with 32 MB limit until late 2010.  That is because bitcoin is not a protocol or an implementation, but is a set of people cooperating with somewhat compatible goals.   Bitcoin will be what those people decide that it is.

Bitcoin is an open source project without any official leadership: not just by Satoshi's choice, but because it must be that way to be decentralized.  Blockstream's pretense to be "the guys who define what bitcoin is"  is totally against that idea.   When they say "changes must be decided by consensus" they clearly mean "consensus among us Blockstream developers", not among the users, miners, or other independent developers...

The important thing is to get a majority of the miners to agree to raise the limit to 8 MB (or some other common value in that ballpark).   Then they need only agree for a date to start doing so, and tell the world about it.

Which software they will use for that is irrelevant, as well as the method that they use to get into agreement, announce their decision, and enable the new limit.  If the Blockstream developers do not cede, the miners can either use another version, or take the Core base and patch it themselves.  All major miners suerly have enough programming expertise to do that.

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.  If there is a 60-seat bus every 10 minuets, and 100 passengers arrive at the bus stop every 10 minutes, some passengers will have to wait until the demand goes down to less than 60 per hour.   If that excess demand lasts for a few hours, many passengers will have to wait for hours.

It is grammar-school-level math.  It does not matter how much the passengers are willing to pay or how cleverly the bus company sets the fees.  

The average waiting time will depend only on the network's capacity and how the incoming traffic will vary over time.  Fiddling with the transaction priorities will not change the average delay by one second.


The average daily traffic now, when there are no "stress tests", is ~120'000 transactions per day, and has grown by 5000 tx/day per month for the last 12 months.  The network's capacity, revealed by the stress tests, is ~200'000 tx/day.  Since the traffic varies during the day and with the day of the week, congestion will begin to occur well before the average demand reaches the capacity; perhaps already when the traffic will be 160'000 or 180'000 tx/day.  Even if the growth is linear rather than exponential, at the curren pace that will happen by mid-2016.  (If the growth is exponential, that may happen in early 2016.)

Most of the transactions pay the minimal fee.  True, if the minimum fees were raised to a significant level (say 0.20 USD/tx, still much less than the cost of the network), a large fraction of the traffic would disappear, and then the block size limit issue would not be urgent for another couple of years.  But neither camp seems willing to do that, for various reasons...

Those were not spam attacks.  They were stress tests.  Rude and inconsiderate, with reproachable motives, but mere stress tests.  A spam attack will be quite different (and worse).


Another inversion of the facts... It was Adam Back, Ph. D.,  who screamed to the world that raising the size limit and/or having an alternative to Core would destroy bitcoin.  Well, it seems that some part of the world believed him...

However, this price drop is still a "minor correction".  Wait until 2016, when the world will realize that bitcoin is useless for e-payments because no one can bear the delays, AND for any sensitive non-payment use too, because it can be easily crippled by a spam attack.


Yes, Gavin actually talked to them, as well as to the other major players.  That is what Adam calls "populist tactics". While the Blockstream devs intended to introduce changes by a different political process: secure commit control of the Core, and buck the community.


Yes, bitcoin still has several design flaws that need to be fixed before it can achieve its design goal.  Like that one. Or the lack of inflation or demurrage, that got it appropriated by a legion of speculators and snake oil salesmen.

Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.  Then adoption will drop, public image will be in sambles, and the price will probably crash.  Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived. 

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size.  (The five largest Chinese miners already did.)

"Big blocks" does not mean unlimited block size.  For practical programming and resource planning reasons, the block size limit must be fairly constant and not too big.  At present, 2 MB would be sufficient to avoid congestion for another year or two, but would offer little protection against spam attacks.  The popular 8 MB limit would be good for several years.

Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time. 

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB.  Until 2018 they will be in agreement, and until then they may change their software again.


Amazing how one can turn the facts so completely upside down. 

The design of bitcoin did not have a significant block size limit.  Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays.   This assumption was so obvious that it did not even have to be stated explicitly.  Only a fool would design a network to be operated in congestion mode.

Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin.  Some transactions would be delayed for hours or more, no matter what fees they pay.

Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years. 


Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.

I understand the differences, but you should make an effort to see through them and really understand how much they matter.

Indeed. Students who are used to uncritically memorize and repeat what the textbooks say often get screwed in my courses.


No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?


No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.


The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.