Gold collapsing. Bitcoin UP.

[Carlton Banks]

The loss of full nodes is due to a delay in the appearance of Bitcoin-native businesses. There's nothing wrong with the demands of running a full node being something that only power users/small businesses and up can handle.

I expect this to gradually become a middle class trapping too, along with running email+SIP from the same home server (after all, they're the section of society that are being squeezed furthest out of their previous position in the relative earnings ranks and also who are reacting with most concern to the state surveillance culture)

[1713574020]

1713574020

[1713574020]

1713574020

[1713574020]

1713574020

[1713574020]

1713574020

[justusranvier]

I think there should be a limit otherwise no-one will pay any meaningful fees ever and people will stop mining. The system will only work when there is a limited amount of space because if it is unlimited it is advantageous for miners to include transactions with any fee, even 1 Satoshi. If that happens Bitcoin will stop to function correctly as the block rewards decrease.

If you believe that markets don't work without externally-imposed production quotas, then you're in the wrong place. Stick to central bank-created currencies.

I signed up for Bitcoin with a 21M unit cap and a 1MB block cap.

That's great. I signed up for a Bitcoin that originally had no explicit cap on the transaction rate.

Rationing transaction throughput was never part of the economic model of Bitcoin, and turning a temporary anti-spam measure into some kind of permanent feature is a form of attack against the currency.

[solex]

I signed up for Bitcoin with a 21M unit cap and a 1MB block cap. Any changes to that will force me to seriously reconsider my investment as the chances of Bitcoin going to zero will increase tremendously.

You are conflating two completely different things. Like debating whether cars should drive on both sides of the road, and also what the speed limit should be.

Importantly. The original version of Bitcoin had an implicit block limit which was effectively 32MB, and Satoshi did a temporary anti-spam hack, seemingly without consultation.

Now you think it is a core principle?  

[Odalv]

If the limit is increased I'm going to seriously consider to reduce my investment in Bitcoin significantly. When the limit is changed once it will be changed in the future as well as this will create a precedent. It's almost as bad as outright increasing the maximum number of Bitcoins from the current 21M maximum.

When the limit is removed, I hope you do sell all your coins.

In fact, why wait?

+1

[wachtwoord]

I think there should be a limit otherwise no-one will pay any meaningful fees ever and people will stop mining. The system will only work when there is a limited amount of space because if it is unlimited it is advantageous for miners to include transactions with any fee, even 1 Satoshi. If that happens Bitcoin will stop to function correctly as the block rewards decrease.

If you believe that markets don't work without externally-imposed production quotas, then you're in the wrong place. Stick to central bank-created currencies.

I signed up for Bitcoin with a 21M unit cap and a 1MB block cap.

That's great. I signed up for a Bitcoin that originally had no explicit cap on the transaction rate.

Rationing transaction throughput was never part of the economic model of Bitcoin, and turning a temporary anti-spam measure into some kind of permanent feature is a form of attack against the currency.

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

[Peter R]

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

I've always found your posts insightful and I know that you are a very intelligent person; I'm interested in your rationale for keeping the blocksize static.  

The argument that "if the blocksize doesn't really matter, then why was a limit added?" seems valid to me.  A smaller blocksize also limits growth of the UTXO database, which is actually the more critical resource.  I'd like to see a healthy fee market develop along with a push towards off-chain transactions (perhaps using m-of-n Oracle sidechains).  A smaller blocksize would incentivize that.  That being said, Solex recently presented a helpful graphic that showed the increase in internet bandwidth since bitcoin's inception, indicating that 3MB blocks now would represent the same % of typically-available BW as 1 MB blocks did in 2009.  So the argument can be made that "we can safely increase the blocksize in parallel with internet speeds."  The Metcalfe value chart also shows a strong correlation between TXs per day and market cap, so an empirically-based argument can be made that limiting bitcoin's TX bandwidth would also limit its value.  

One point you made that I think is not valid is the notion that a 1 MB blocksize is a core part of the coin's definition (i.e., part of the "Satoshi Social Contract" in the same way the 21 M coin limit is).  There's plenty of evidence that indicates the 1 MB limit was never intended to be permanent.  Of course, this doesn't mean that it's necessarily a good idea to increase it without careful thought and debate either.  

[impulse]

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.

Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.

[Adrian-x]

The crunch increased interest in tenders divorced from a single nation’s strength, spurring the International Monetary Fund to boost almost 10-fold the allocation of special drawing rights, a reserve asset whose value is based on a basket of currencies, and fueling demand for so-called virtual currencies, such as bitcoin.

http://www.bloomberg.com/news/2014-08-06/russia-sanctions-accelerate-risk-to-dollar-dominance.html

WTF, am I reading that correctly - in the context of the other posts, banks pay more than double the bitcoin market cap in fines, but IMF's SDR is involved how?

[Chalkbot]

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.

Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.

Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse? I guess this could make bitcoin unfriendly to microtransactions (one of it's finer points) and maybe easy to get around by scripting different origination addresses for each transaction if it were some kind of per-address limitation. Hmmm.

But let me better understand the current situation; Miners are already excluding transactions that are not worth their while? I assume they are doing this on the basis of fees paid? If this is the case, it would seem that removing the limit wouldn't change anything.... right? I mean, spammy transactions can already be assigned low priority and pushed into other blocks, so wouldn't that mitigate the problem all on it's own? Or is the fear that this could be abused by one of these entities spamming high fee transactions to themselves, solving the block making it "free", and thus excluding legitimate transactions? If this were the case, I don't see how a block size limit is doing anything to prevent this....

[Peter R]

Miners still get to decide which transactions that they want to include...

And some miners do stupid things.  "BCPool" created 17,976 single-satoshi dust outputs from that "1Enjoy" address by mining a bunch of spam transactions in block #309657 and again in block #309740.  Assuming each output takes up 50 bytes in the UTXO database, that's 17,976 x 50 B = ~1 MB of garbage that will possibly forever sit in each node's RAM, as ouputs are not prunable if they never get spent (and these ones cost more to spend than they are worth!).  

I'm not saying the limit shouldn't be raised, I'm just trying to present some empirical data that illustrates some things that have gone wrong.  

Code:

BLOCK #309740:  10,486 DUST OUTPUTS 
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS     
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16	749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS     
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651	749

[impulse]

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

Miners still get to decide which transactions that they want to include, and bloating blocks with too many transactions limits propagation times, which is why we even now we are seeing block sizes artificially limited. Even if there were no limit, I don't believe that miners would choose to include every transaction if it were not in their interest or if it in any way imposed a penalty on them. Furthermore, we have only two choices moving forward, both of which are just different versions of the same beast, either a) block size is limited and by necessity most transactions are pushed off the blockchain and managed by large "centralized" transaction processing companies like BitPay and Coinbase; or b) Block limits are raised and transactions of any size can be transmitted to the blockchain directly, at the expense of large "centralized" mining companies like ghash.io. Personally, I prefer the option b.

Mining is a marginal activity and always will be. As the network grows it will be in the best interest of all participants to have a functioning protocol, and large companies in the space will undoubtedly subsidize large mining operations in order to ensure that the network continues to support their other business needs. I am not worried about mining centralization.

Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse? I guess this could make bitcoin unfriendly to microtransactions (one of it's finer points) and maybe easy to get around by scripting different origination addresses for each transaction if it were some kind of per-address limitation. Hmmm.

But let me better understand the current situation; Miners are already excluding transactions that are not worth their while? I assume they are doing this on the basis of fees paid? If this is the case, it would seem that removing the limit wouldn't change anything.... right? I mean, spammy transactions can already be assigned low priority and pushed into other blocks, so wouldn't that mitigate the problem all on it's own? Or is the fear that this could be abused by one of these entities spamming high fee transactions to themselves, solving the block making it "free", and thus excluding legitimate transactions? If this were the case, I don't see how a block size limit is doing anything to prevent this....

Option c is really just option b. I think that what you have outlined is exactly right, miners DO decide what to include, and right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming. The fear is that by raising the limit, you raise the burden of maintaining a "full node", which reduces the number of full nodes and thus the reduces the number of participants enforcing the network rules, and the other consensus mechanisms. Removing the limit would make no difference to the miners really, they make their own rules.

[Adrian-x]

Sorry if some of this escapes me, but is there not some kind of "option c" wherein transaction fees scale dynamically to limit abuse?

ironical the commodity in short supply that we are talking about preserving is space and bandwidth, charging transaction fees to reword miners does nothing to curb the miners from taking advantage of the limited space.

now if miners had to buy a claim to mine from a full node then fees would reflect the available bandwidth and space on the web.  

[impulse]

Miners still get to decide which transactions that they want to include...

And some miners do stupid things.  "BCPool" created 17,976 single-satoshi dust outputs from that "1Enjoy" address by mining a bunch of spam transactions in block #309657 and again in block #309740.  Assuming each output is 50 bytes, that's 17,976 x 50 B = ~1 MB of garbage that will possibly forever sit in each node's RAM, as ouputs are not prunable if they never get spent (and these ones cost more to spend than they are worth!).  

I'm not saying the limit shouldn't be raised, I'm just trying to present some empirical data that illustrates some things that have gone wrong.  

Code:

BLOCK #309740:  10,486 DUST OUTPUTS 
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS     
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16	749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS     
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460	749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z	634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651	749

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

[Peter R]

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs--these TXs can still get mined though.    

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  

[wachtwoord]

If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

I've always found your posts insightful and I know that you are a very intelligent person; I'm interested in your rationale for keeping the blocksize static.  

The argument that "if the blocksize doesn't really matter, then why was a limit added?" seems valid to me.  A smaller blocksize also limits growth of the UTXO database, which is actually the more critical resource.  I'd like to see a healthy fee market develop along with a push towards off-chain transactions (perhaps using m-of-n Oracle sidechains).  A smaller blocksize would incentivize that.  That being said, Solex recently presented a helpful graphic that showed the increase in internet bandwidth since bitcoin's inception, indicating that 3MB blocks now would represent the same % of typically-available BW as 1 MB blocks did in 2009.  So the argument can be made that "we can safely increase the blocksize in parallel with internet speeds."  The Metcalfe value chart also shows a strong correlation between TXs per day and market cap, so an empirically-based argument can be made that limiting bitcoin's TX bandwidth would also limit its value.  

One point you made that I think is not valid is the notion that a 1 MB blocksize is a core part of the coin's definition (i.e., part of the "Satoshi Social Contract" in the same way the 21 M coin limit is).  There's plenty of evidence that indicates the 1 MB limit was never intended to be permanent.  Of course, this doesn't mean that it's necessarily a good idea to increase it without careful thought and debate either.  

Okay sure

For miners, the cost lies not in including transactions. Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*. The cost for a miner lies in hashing the block with a nonce so the hash starts with a certain number of zeros (the difficulty).

Anyway, if I am a miner and I'm hashing away, I'm going to include every single transaction that pays any fee whatsoever in the block I'm hashing (if the block size is unlimited) simply because it costs me nothing to add the transaction and it does increase the amount I'm gaining when I find the right hash. Therefore, considering the situation with no size limit for a block and a set of rational miners all transactions will have a long term transaction fee of 1 Satoshi (or whatever the minimum unit is for the transaction in that time in the future).

Therefore the miners will receive payment of 1 Statoshi*the number of transactions for their job of securing the network and I believe this is insufficient as it would require 25*6*24/1^-8= 3.6*10^11 transactions daily to match the current block rewards. Granted, the exchange rate will increase in that time but not by a factor >10^6 (a factor 10^6 would imply $580M per Bitcoin).

Of course, in today's situation not all transactions are accepted even though we haven't touched the limit yet. This is because miners are not yet acting rationally but merely accepting the default recommended transaction fee guidelines proposed by the devs. This makes sense because the subsidy is still so high in comparison. It's a bit naive to think this situation will continue indefinitely though with an infinitely decreasing block subsidy.

Conclusion: for transaction fees to ever pay for the securing of the network a limit on the block chain is indispensable. Granted, this limit could have been larger than 1MB. However, if we increase it now, this will make it easier to increase it in the future as well because we create a precedent. As such it would continuously increase undermining the whole system. It would be like saying: we'll increase the maximum available Bitcoins to 100M. yes we'll only do it this once. Sure   no-one will believe that.

The actual numbers may be arbitrary. Keeping them static however is far more important than people in this topic seem to realize.

Anyway, please tell me I'm wrong. I love being wrong . Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

*I'm simplifying the situation here for number of transactions to be able to talk about it more naturally. It seems obvious the same holds for number of bytes in the block.

[wachtwoord]

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

If we increase the limit every time we run into it we effectively have no limit.

[impulse]

Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs.  

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  

Yes, a valid correction, and these are the reasons why block limits are still important.

[justusranvier]

Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*.

This situation does not exist.

The cost is very real and not-insubstantial - the increased orphan risk which you completely glossed over above.

The marginal cost can - and should - be brought very low but it will never reach zero.

The amount of transactions a miner can process in a ten minute interval is finite, therefore it is scarce, therefore the service of including transactions in a block will always have a price.

[Peter R]

Anyway, please tell me I'm wrong. I love being wrong . Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

Consider the question "is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?"  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that by including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat me by 15 seconds.  My post had a larger word count and now it gets orphaned

[wachtwoord]

Anyway, please tell me I'm wrong. I love being wrong . Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

For example, is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that be including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat my by 25 seconds

Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.