Bitcoin Forum

Just reiterating my prediction so we can see how it plays out. We are currently on #2, a lot of unconfirmed transactions (http://blockchain.info/unconfirmed-transactions) and starting to see #3. We should see transaction fees increase and also more and more blocks larger than 250kb as miners uncap the soft limit.


In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

I suspect that you underestimate the power of a gambling addiction.

Not another disguised post promoting the scam & premined ripple currency after being bribed by OpenCoin Inc again..

You forgot:

15. Looking at profitability of miners every Joe Shmoe buys an asic machine until mining sucks.

Not at all, in fact if you read my post you realize that this is bullish for Bitcoin's value and security.

The network isn't controlled by the miners. A hard fork the miners "refuse to accept" will have new miners that take their place.

11. News articles start appearing in the media pointing our the 7 tps hard transaction limit as a fatal flaw in Bitcoin.
12. At best, fees never exceed 1/10 to 1/5 the block subsidy.
13. Businesses investment drastically slows with regards to all forms of distributed cryptocurrency and more capital is directed towards centralized solutions.
14. Miners realize they killed the goose that laid the golden egg.

Exactly. If the miners want to see Bitcoin scale at all they will have to agree to a hard fork. As long as a good solution is agreed upon, by the dev team at least.

The amount of unconfirmed transactions is not larger than average, over a 24 hour period.

A snapshot of the mempool -- like the blockchain.info link above -- does not fit the thesis for two reasons:

• Never-will-confirm transactions and low priority transactions bloat the mempool
• Some miners sweep far more than 250k worth of transactions, so some miners already sweep large swaths into blocks

This situation has been ongoing for months now.

Is there a place that describes how the reference client deals with the memory pool? Like, what happens when it fills up (which transactions get purged, if any, and after how long)?

The only way transactions are purged is by appearing in a block.  At present it cannot "fill up" except by using all available memory, and getting OOM-killed.  Therefore, you can see how any long-running node will eventually accumulate a lot of dead weight.

The mempool only stores provably spendable transactions, so it is DoS'able, but you must do so with relay-able standard transactions.

Wow...tightrope walking with no net. If blocks are always filled and fees go up, the SatoshiDICE transactions (low fee) will clog the memory pool and I guess eventually there will need to be a patch.


Why aren't mempool transactions purged after some fixed amount of time? This way someone could determine with certainty that their transaction will never make it into a block. Apologies if this has already been asked many times (it probably has).

Because why sell 1000 apples for $0.75 each when you can instead sell 10 for $1.00 each. Especially when your variable cost for additional apples is effectively zero. Makes perfect fucking sense.

Even better, turns out there are enough oranges for everyone to have one, and nobody gives a shit about apples at all anymore.

Correct.  It's not needed right now, thus we are able to avoid the techno-political question of what to delete from the mempool when it becomes necessary to cull.


As a matter of fact, that is my current proposal on the table, with has met with general agreement:

   Purge transactions from the memory pool, if they do not make it into a block within X [blocks | seconds].  

Once this logic is deployed widely, it has several benefits:

• TX behavior is a bit more deterministic.
• Makes it possible (but not 100% certain) that a transaction may be revised or double-spent-to-recover, if it fails to make it into a block.
• mempool is capped by a politically-neutral technological limit

Patches welcome :)  I haven't had time to implement the proposal, and nobody else has stepped up.

Clients should re-broadcast transactions or assume they are lost, if they fail to be included after X * 4 [blocks | seconds]

I would also add a rule that a tx which is the same as a transaction already in the pool, except that it has a tx fee at least double the current version should replace the current version and be relayed.

The client could tell the user the transactions failed to be sent and ask if the user wants to increase the fee.

The current behavior of clients is fine:  rebroadcast continually, when you are not in a block.

Optionally, in the future, clients may elect to not rebroadcast.  That is fine too, and works within the current or future system.

Let's be generous and assume an average 90% probability that each step in the predicted chain of events occurs as described...

Event  Probability
1     100%
2     90%
3     81%
4     73%
5     66%
6     59%
7     53%
8     48%
9     43%
10   39%
11   35%
12   31%
13   28%
14   25%

End result:

25%  Smooth transition.  All: "Hail misterbigg"
75%  Train wreck, emergency block size increase. misterbigg: "Sorry, my next prediction will be better!"

heh...well, remember that the negative consequences for leaving the block size alone are far less severe than if we implement a faulty system for making it adjustable. Because if we do nothing, we can always change it later. The worst that happens is we have a period of time where transaction fees are higher than normal and take longer to confirm. Certainly not the end of the world by any stretch.

Compare this with adjusting the block size and then discovering that well, yeah it seems retep was right about losing some decentralization due to bandwidth.

100% agree with prediction, this can be seen as a major flaw in bitcoin.

maybe it is time to present the btc's little brother to the world, LTC,.

Is there any limit in LTC block size?

if the answer is yes maybe is a good time for the devs of both coins to colaborate.

We can have the gold and the silver like someone said.

better now than when it is to late

I'm sorry, I don't get it.

At step 13, transactions (and the fees they would have paid to miners) are fleeing bitcoin in droves.  And at step 14, the bitcoin miners are *pleased* with this?  Why?

It makes no sense to me at all to impose a permanent hard limit of 1mb.  Whatever reasons are given for keeping it, could be used as reasons to *lower* it.  And no one thinks we should lower it.  I don't agree with this "artificial scarcity" business, unless the point of it is to help level the playing field in terms of hardware requirements.  In that sense, it's not really artificial scarcity, is it?  It's scarcity of real resources:  bandwidth, storage and CPU speed.

I mean, we all agree that if everyone had 10 gigabit ethernet, 256 cores and 100tb of storage, the 1mb limit would seem laughable, right?  Well, soon we'll all have that.  And a few years after that we'll all have it the palm of our hand.

Here's my modest (and likely naive) proposal.

1) See if a scheme to reduce resource consumption in the protocol can be worked out (I think storage requirements are already being addressed, but not sure about bandwidth)
2) Whatever comes of that, plot historical hardware capability progress, project the curve into the future.
3) Hard fork the client to follow the curve projection
4) If hardware doesn't end up matching predictions, fork again as necessary.

I doubt a second fork would be needed for decades. 

I'm not saying that Bitcoin will shrink, I'm saying that it will reach an equilibrium where there is no more growth in terms of new users operating directly on the block chain. Instead, there will be an industry of companies that do things off the block chain and settle up once a day or every few hours. Of course miners would love that, since the fees will be maximized. And anyone using Bitcoin as a store of value will be happy with it as well, since the network hash rate will be maximized.

This.

I'd consider myself a pretty knowledgeable guy about Bitcoin - I've even gotten a few lines of code into the reference client and once found a (minor) bug in code written by Satoshi dating back to almost the very first version.

You wanna know where I keep my coins for day-to-day spending? Easywallet. So it's centralized - so what? If it goes under I'm not going to cry about the $100 I have there, and I do care about how it ensures that every transaction I make it unlinkable, and since I access it over Tor, even Easywallet has a hard time figuring out who I am.

My savings though? Absolutely they're on the blockchain, with rock-solid security that I can trust - I've read most of the source-code myself. Sure, transactions won't be free, or even cheap, but you get what you pay for, and I know I'm getting the hashing security I paid for.

With cryptography we can create ways to audit services like Easywallet and make it impossible for them lie about how many coins back the balances in the ledgers they maintain. Eventually we can even create ways to shutdown those services instantly if they commit fraud. In fact, with some changes to the Bitcoin scripting, I think we can even make it possible for users of those services to automatically get refunds when fraud is proven, although I and others are still working on that idea - don't quote me on that yet. :P

The point is, we have options, and those options don't have to destroy the truly decentralized and censorship-proof blockchain we have now, just so people can make cheap bets on some silly gambling site.

It seems to me the most fair way to decide block size it is to have the block chain size be proportional to the hashing speed of the network.  

1) The more transactions per second then what can fit in the current block size results in more fees paid to miners.  
2) The more fees paid to miners, the more miners exist.  
3) The more miners exist, the higher the hashing speed.  
4) The higher hashing speed results in larger block size (because thats how we determining it).
5) The larger block size results in lower transaction fees.
6) Lower transaction fees result is less fees paid to miners.
7) Less fees to miners results in less miners.
8 ) Less miners results in smaller hashing speed.
9) Smaller hashing speed results in smaller block size.

And So on.  This creates an equilibrium that would basically allow supply and demand to dictate the block size.  

I'm sorry if this has already been discussed.  Thoughts?

Hashing speed is not relevant.

This is a good discussion of the critical factors:

https://bitcointalk.org/index.php?topic=140233.msg1568633#msg1568633

Over Bitcoin's relatively short period, the graph of the hashing speed of the network looks like this:

http://bitcoin.sipa.be/speed-lin-ever.png

...and you want to link block size to that wild roller coaster, when we haven't even seen that ASICS will do?

Even on a log scale the hashing power has been wild, and it still could be if anyone finds a partial shortcut in SHA256:

http://bitcoin.sipa.be/speed-ever.png

That said, since a shortcut is rather unlikely, and probably would break SHA256 entirely anyway, not to mention cause a 51% attack, I could consider supporting a max block size calculated as something like 1MB*log10(hashs/second * k) But really, I'm mostly saying that because log10 of anything doesn't grow very fast...

Well if you think about it,

you could decide in an arbitrary way how many bitcoins a block should try and reward the miners.  for the purpose of this I say we could define it as (50btc - $current_block_reward)  

Then in the same operation that decides the difficulty, you could also adjust the block size using an algorithm that would attempt to keep the fees to that proper level to maintain the 50 btc / block.  The block size could be adjusted on the same schedule as the difficulty.  

You could design the algorithm to inversely increase as the mining reward decreases to try and keep the same balance of fees that we are seeing now.  It just seems like a simple way to keep everything running status quo.

The other cool thing is that it would still allow for free transactions to go through if there happened to be a temporary decrease in the transactional volume.  I'm sure there is something that I'm missing here. I'm sure its not that simple.  But the concept is there.

i like this idea.

yes, clients should be allowed to revise a previous unconfirmed tx.

clear thinking.  the market will seek out a solution.  i think it's too soon to be changing things.

the normal response to those advocating change would be to say, "well go start your own alt chain".  but that would be difficult since no miners would follow you b/c of the higher fee structure of the current Bitcoin system.  higher fees will increase miner participation and thus higher security and encourage more investment.  more miners will be encouraged to mine thus increasing competition and keeping fees under control.

free spamming of the network by gambling tx's have the potential to clog the network.  they should be forced to contribute some fees towards miners costs.  and by forced, i don't mean by any of us; by leaving block size the same the economics of the situation will do the forcing.

That's right, once Bitcoin transaction volume rises sufficiently the gambling transactions will need to pay higher fees to get reasonable confirmation times.

However, the problem with these gambling transactions is not their frequency (since they are not currently crowding out more legitimate transactions) but rather that they produce unspendable outputs. I'm talking specifically about SatoshiDICE's "lose confirmation" transactions which send 1 satoshi back. They can't be pruned from the block chain but also cannot be spent (well, it wouldn't make economic sense to spend them).

I don't understand why the gambling is a problem. I really don't. It's an absolutely valid use of the Blockchain. They pay 0.0005 for every transaction which is not something that even all regular users do. It is QUITE ENOUGH to pay the miners for the END OF TIME.

Have you guys calculated this properly? If SatoshiDice made 1 million transactions per day right now, and payed 0.0005 for each, that is _500_ bitcoins in fees per day by SatoshiDice alone. That would be 3.472 BTC in fees per block. If that is not enough for 1M tx (which is 20 times what we have now), then how about a 0.001 fee (which is still in the limits of being currently acceptable), it is approximately 7 bitcoins per block in fees.

How much do the miners need? We already suffered a very significant drop from 50+fees in reward to 25+fees reward for the miners, and the network is currently seen as extremely secure. What is the amount where we deem it "not secure enough"? Or should we limit our system in purpose and just pay the maximum amount that people are willing to pay (which would lead to 99% of Bitcoin users becoming non-Bitcoin-users).

How about 5 million transactions? Let's check out the numbers. It's approximately the amount PayPal has per day. That is 60 tx/s, someone said Bitcoin is capable of around 7 tx/s. So if we raise the block size to 10MB, which gives Bitcoin PayPal level transaction amount, and each of them involves a 0.0005 BTC to transact.. let's see. That is 2500 BTC in fees PER DAY. Which is 17.36 BTC per block.

So HOW EXACTLY is a 10MB block size, with 5 million transactions per day, at a reward of 17 BTC per block (with our current fee!), a disaster? What exactly does the reward need to be? This is what needs to be thought about.

Edit: It's of course good to remember that we're still going to have some kind of fixed reward for the miners for a very long time, even though it halves every 4 years. Here I looked at the fee reward structure alone.

This is a separate problem, that should be solved in some other way. I wouldn't mix that issue with the issue of the block size in general. We should be able to implement more extreme spamming rules that simply make it impossible to send that kind of transactions, or something like that.

Why the limit is not in some real time proportion with the pending transaction memory size? Then confirmation of found block would have to accept block size witch are not bigger than the peak pending transaction memory size since last found block.

thx

"pending transaction memory size" is going to 1) be different for every node and 2) be vulnerable to manipulation.

Any scheme for adjusting the block size needs to be based purely on the information found in the block chain.

That's totally wrong, the negative consequences for leaving that block size alone are that Bitcoin fails to adequately scale, fees for accepting bitcoins grow prohibitably large (larger than other payment methods because Bitcoin usage becomes dominated by fee insensitive transfers like gambling), merchants stop accepting bitcoins, and it ultimately fails and is replaced.

You act like a switch can just be flipped in the future, it may end up being too late.

i stand corrected.  i wasn't aware SD was paying those kinds of fees. 

This is so fucking naive.

1) The network hashrate will not be maximized in a global context. Restricted number of transactions equals a supply ceiling. A supply ceiling prevents the supply / demand curve from being maximized. A non maximized curve means that total transaction revenue per block will ultimately be lower. This is also ignoring that BTC to local currency rates will be lower, further reducing economic incentive to invest in mining resources

2) Bitcoin will be less valuable as a store of value. Less total transaction revenue per block, fewer users, less overall commerce done using bitcoins, smaller economy represented in bitcoins, BTC to [your currency here] rate is lower, fewer mining resources, LOWER TOTAL HASH RATE. Lower total hash rate equals a less secure store of value

Now pay attention to this last one

3) A declining BTC to other currency price means a terrible long term store of value. Declining types of potential use cases (resulting from more expensive INDIVIDUAL transactions), means smaller total economy represented in bitcoins, which then means a stagnant or declining BTC price. A bitcoin never grows into the $1000s without Bitcoin representing a significant portion of the global economy. A transaction limit never allows Bitcoin to do that.  

how can be block 224711 more than 250kB?

http://blockchain.info/it/block-index/355118/000000000000003a49c4828ebf1b042f48058f4bbec461b5e3648a30e9e30d4d

The 250KB "limit" is simply the default maximum block size created by the reference implementation that most miners use. Nodes will still accept up to the hard maximum block size, which is 1MB.

For instance, on testnet there have been two 1MB blocks created: 00000000476781c04b82b3ea91af1a86f3a863e1c9312b50302ffa01b7bdf960 (https://blockexplorer.com/testnet/block/00000000476781c04b82b3ea91af1a86f3a863e1c9312b50302ffa01b7bdf960) and 0000000010bf4453b170a6756d911e207734ae181af6c8c02b42787d5885b333 (https://blockexplorer.com/testnet/block/0000000010bf4453b170a6756d911e207734ae181af6c8c02b42787d5885b333)

I'm not sure if that's true. In some cases I'm more inclined to believe malice to be more likely than ignorance.

Some people don't want Bitcoin to be successful.

thanks for the explanation

I agree, I don't give a shit about anyone else's alt chains, bonded banking startup, or ripple investments. I love Bitcoin. Fuck anyone who doesn't.

Simply leaving the max blocksize limit at 1mb and walking away is such a huge mistake, I really can't believe so many people don't see it.

If the bitcoin community doesn't deliver on small transactions, someone else will.  You know who that someone else will be?  Paypal.  Banks.  Government.   By leaving the blocksize limit in place, you're handing the power right back to the corporate and government interests that you just pulled off a fucking miracle taking it away from.  All this nonsense about "a market will emerge" is just bullshit, Paypal is what happens when you just sit back and let someone else do it.  People have no idea what's possible until you show them.  If you just let the market handle it, the people will just get what they expect.

Bitcoin has gotten as far as it has precisely because it's not controlled by corporate or government interests.  Don't stop now, the finish line is still a ways away.  

I'm not saying the blockchain necessarily needs to store all these tiny transactions.  But the solution needs to come from right here.  

+10 internets verify

Some people might be interested in some analysis of recent blocks.

There seems to be a substantial rise in high fee transactions (fees as high at 0.005 BTC/KB) out-competing other transactions.  I've been calling these transaction dead-puppies due to a incomprehensible made on IRC. In any case, running a script to identify the DP-involved transactions on the recent blocks show. A transaction is considered DP involved if it pays to an identified DP address or if any of its inputs paid to an identified DP address.

Height  Size    Amount of DP-involved.
224737 163012 82.0755%
224736 498888 94.9111%
224735 163124 27.1875%
224734 249140 93.4021%
224733 351883  6.77507%
224732 498991 85.5789%
224731 249033 67.8657%
224730 169849 55.9459%
224729 487840 76.87%
224728 249091 80.2395%
224727 249204 64.2512%
224726 187733 69.8947%
224725 121400 49.0196%
224724 248878 69.899%
224723 248923 72.5989%

The couple blocks with lower than typical DP concentrations appear to be miners that have also noticed these transactions an are apparently depriortizing them, though they don't get all of them because they appear to identify them only on the basis of output addresses rather than the transaction history.

Of note, the concentration was similar to somewhat lower 24 hours ago when there were fewer >250KB blocks.  Because the supply of these transactions seems to be basically unbounded it seems likely that adjustments to block target sizes are unlikely to produce faster confirmations at this time.

This is interesting, but can you just clarify the term again, please?

Dead puppies aren't much fun.

Compare the following case:
1. News articles start appearing in the media pointing 7tps hard transaction limit of bitcoin blockchain
2. News articles start appearing in the media pointing a hard fork happened inside bitcoin which created two different bitcoin network: Bitcoin legacy and Bitcoin 2.0, and there will be 3 types of coin: Pre-fork coin, after-fork coin 2.0 and after-fork coin legacy. And possibly in the future there will be another new type of coin together with another fork... with each fork another 11 million of coin were created immediately

Which one do you think will more likely to cause people abandon bitcoin  ;)