Now that we've reached the 250kb soft limit...

[misterbigg]

At step 13, transactions (and the fees they would have paid to miners) are fleeing bitcoin in droves.

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.

[Peter Todd]

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.

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.

[jhansen858]

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?

[solex]

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.  

Hashing speed is not relevant.

This is a good discussion of the critical factors:

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

[Peter Todd]

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.  

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



...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:



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...

[jhansen858]

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.

[cypherdoc]

...you can see how any long-running node will eventually accumulate a lot of dead weight.

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.

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.

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

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).

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.

i like this idea.

[cypherdoc]

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

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.

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

[cypherdoc]

...
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.

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.

[misterbigg]

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).

[Technomage]

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.

[Technomage]

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).

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.

[matakaonew]

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

[misterbigg]

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.

"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.

[conv3rsion]

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.

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.

[cypherdoc]

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.

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

[conv3rsion]

At step 13, transactions (and the fees they would have paid to miners) are fleeing bitcoin in droves.

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 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.  

[GIANNAT]

how can be block 224711 more than 250kB?

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

[Peter Todd]

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 and 0000000010bf4453b170a6756d911e207734ae181af6c8c02b42787d5885b333

[justusranvier]

This is so fucking naive.

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.