Topic: Are we stress testing again? - page 23. (Read 33192 times)

Look how many unconfirmed transactions there are, this is disgusting to be honest - https://blockchain.info/unconfirmed-transactions

How much longer is this going to continue? People could be sending large amounts of BTC & be panicking, waiting 5-6 hours, maybe more for 1 transaction.

I understand that there was a need for stress testing but it's being taken too far now imo.

Probably not. Bitcoiners are extremely resilient, they don't change their opinions just because of mere facts.  


"Fork" does not mean to increase the blocksize, although changing it would require a fork.  (Luke Dashjr wants a fork to reduce the max block size to 100 kB.)


The larger the block size limit, the more expensive a spam attack would be.  To be effective, a spam attack must generate more transactions per second than the network can confirm (in addition to its normal traffic).  With 1 MB blocks, that would be more than 1.8 transactions per second.  With 8 MB blocks, it would be ~21 tx/s,  With 20 MB blocks, it would be ~53 tx/s.  Only the excess spam above those numbers would accumulate in the queues, creating and feeding the backlog.

More transactions make the attack more expensive.  The average transaction fee now is ~0.01 USD/tx, it seems.  Assuming an attack with twice the traffic numbers above,  the cost would be ~80 USD/h with 1 MB blocks,  ~850 USD/h with 8 MB blocks, and ~2100 USD/h with 20 MB blocks.

Also, the larger the block size limit, the faster a backlog will clear out.  The goal of the current spam test was to reach 250 MB of unconfirmed transactions (but they got about 70 MB maximum, so far).  The backlog will clear at the rate equal to the capacity of the network, minus the current traffic (which is about 30% of the capacity).  So, with 1 MB blocks, minus 300 kB per block,  it would take ~360 blocks (~2.5 days) to clear 250 MB of backlog.  With 8MB blocks, it would take ~33 blocks (~5.5 hours).  With 20 MB blocks, it would take ~13 blocks (~2 hours).

Increasing the block size limit to 8 MB or even 20 MB will not make the risk of a spam attack become negligible, because a determined attacker with deep pockets can afford much more than 2100 USD/hour.  But it would make the attack 10 times more expensive, and clear any backlog almost 10 times faster.

But the main reason to increase the limit is not to ward of spam attacks (which, as said above, are impossible to avoid).  It is only to prevent the network from becoming saturated due to a possible increase in normal traffic.  If the average normal daily traffic gets to about 300'000 tx/day (only 3 times the current value), there will be recurrent "traffic jams" that take several hours to clear.   The delays due to traffic jams will drive more users away from bitcoin, until the traffic stops growing.  Only users who really need bitcoin (like drug users and ransomware victims) will put up with the jams.  

Increasing the block size should have been a no-brainer non-event, a trivial and routine maintenance action to get one possible problem out of the way.  It is what any plumber would try to do when he notices that a rain or sewer pipe is about to become insufficient for the flow it is supposed to carry.  Unfortunately, the business plan of Blockstream requires forcing all individuals who now use bitcoin to use their "overlay network" (Sidechains, Lightning Network, whatever) instead.  To do that, they must keep the block size limited to 1 MB until the network saturates, in order to force all clients to pay much more in return for much longer confirmation times.  All in name of freedom, of course...

I must admit that I have underestimated Bitcoin's resilience. It's doing well, and what's more important - it's functioning as intended. If legitimate users want their transactions confirmed fast, they just raise the fees - Bitcoin Core does a great job suggesting correct amounts.

There might be some shortcomings regarding mempool management, but the network as a whole is robust.

At 20mb blocks the outcome would be far worse - most nodes would struggle to verify them fast enough. Add to that the ballooning UTXO set.

It should be noted that currently there's enough space in blocks for legitimate transactions, and they mostly compete with spam, not with each other. What if such an avalanche of txs happens naturally, by increased usage, not by an attack? I'm not sure what would happen, and this 'stress test' has failed to show that either.

They already identified a problem: if an attack is directed towards the network in the form of tx with no fees, it will certainly clog the network. Also, if we should see a significant increase in transactions in the coming years because of widespread use of bitcoin, then we might know how to deal with it too. But I agree, the testing should stop now. The result is pretty obvious: it clogged the network.

The solution is to stop flooding the network with dust transactions.  I'm not sure what point "they" are trying to make with all of this, but it's not identifying any problem we didn't already know exists, and it's not working toward any solution.

Same here. My transactions went through within an hour with the minimum transaction fees I can put to ensure a faster confirmation. If the transaction is not that urgent, I can probably lower the fee for me to save some satoshis.

In regards with the stress testing, it seems like the testers are pushing the network to its limit. They better come up with a solution with this problem they are testing right now, or they should help the devs to create a solution in case transactions in the future see a rapid growth and spike again.

Id rather not have a client thats forcing me to pay a high fee just because someone is currently burning money on the network. Im perfectly fine to pay the same fee as always and wait a day. If I want something to go fast I can always increase the fee, but its still a decision I want to make myself.

but it doesn't force them. I think that was his proposal. but I'm not sure if that's the final solution

We already have that. Bitcoin core does a pretty good job to determine the fee for a given block the TX should be in.

What are the addresses that are doing the spamming? If we just blacklist them we can remove them from the mempool and their transactions will be ignored by everyone.

It's an attack at this point guys... We need to do something.. increasing the block size is not the right path.  Dynamic fees IMO are the way.

it's still going. check the mempool stats it's gone 10mb up in the last hours https://tradeblock.com/blockchain

is the stress testing still going on ? https://blockchain.info/charts/n-transactions yesterday we had 185k it looks like it has slowed down a bit comparing the day before at 212k peak.

Does this mean they got into the blockchain or just into the mempool? If the latter then its expected. The spammer wants to flood the mempool so legit tx take long time. The only way to counter the attack is to use a higher fee. Paying 3-4 times is not that bad if it gets you in an hour.

If you have already sent it trying a double spend with a higher fee will usually do the trick.

It is still there. If you look in the debug.log, you will see a lot of lines that look like this
This means that dust transactions are being dropped by standard clients. However, some places do not do this, such as tradeblock. They will say that the mempool is much larger than what nodes and miners see because they _do_not_ drop dust transactions.

are you sure about this point? i was thinking that this stress was done to know what the initial MB that should have been used
becuase perhaps 4mb would have been too much to start with, if the network can actually sustain more than 1MB with a little impact on the queue
later we can do 2mb every two year or any other smaller combination

wasn't there a dust threshold that prevented tx spam like this? or did they patch it out?

We can't be hard forking every other month man..

yea most likely is better now to look at the transactions volume before even sending one to make sure you have to adjust the fee manually and pay a little more to have it confirm faster.

The plan can be changed is the hardware doesn't keep up.

It is important to ensure the network keeps up with the transaction volume assuming Bitcoin continues to go mainstream.

If the doubling ins't needed or isn't possible then I am confident it can be delayed.