Are we stress testing again?

[achow101]

We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.

Wait, I don't understand.  If they are mining empty blocks, then they are not processing ANY transactions, but just taking the generated btc?  This sounds like another flaw in the system.

It could be flaw now, but in the past, it was the only way that Bitcoin could survive. These empty blocks happen because they are usually found within seconds of the previous block, thereby not having enough time to include transactions because of the way that mining works. Empty blocks are not an attack on the network and usually aren't intentional.

[1715032247]

1715032247

[Quantus]

We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.

Soon the weaker full nodes with less memory and storage capability will begin to slow down and some may even crash.
To run a full node you must load the whole mempool when you run out of RAM it will be pushed onto the HDD or SSD but this will slowdown validations
and network propagation. The network could become unsynchronised leading to numerous and repeated forks.

We must act now before it is to late. We must attack all mining pools who mine blind and dumb and any pool who mines empty blocks.

[achow101]

We need to Ddos the mining pools that are mining empty blocks. Even if they are not behind this attack they are contributing to it.

Soon the weaker full nodes with less memory and storage capability will begin to slow down and some may even crash.
To run a full node you must load the whole mempool when you run out of RAM it will be pushed onto the HDD or SSD but this will slowdown validations
network propagation. The network could become unsynchronised leading to numerous and repeated forks.

We must act now before it is to late. We must attack all mining pools who mine blind and dumb and any pool who mines empty blocks.

I don't think you understand how this works. First of all, every mining pool mines empty blocks. It is simply the nature of mining that happens to produce empty blocks randomly. They are not intentionally nor maliciously created. If you were to DDoS every pool that mined an empty block, you would DDoS the entire network. There may be some pools that create more empty blocks than others due to having a higher hashrate thus increasing their probability of finding a block soon after the previous. This does not give the miners time to include transactions into the block.

Here is some recent data on empty blocks

As of block 364125, there are a total of 85,422 empty blocks.

AntPool: 5.16% of their blocks are empty, latest one was today.
Discus Fish: 2.88% of their blocks are empty
KnC: 2.88% of their blocks are empty
Eligius: 2.26% of their blocks are empty

As you can see, AntPool and F2Pool (Discus Fish) are creating the most number of empty blocks. They also consist of about a third of the miners. If you were to DDoS them, then you would lose a third of the hashrate, thereby increasing confirmation times, causing more transactions to fill the mempool and cause a greater backlog. This idea in general is terrible.

[Quantus]

I have watched these pools They mine almost empty blocks all the time. They may decide to take in transactions with really high fees but most of the blocks from the chines pools are 95% empty not 100% empty but almost empty.

The miners will start to include more transactions within a few hours if we hit them hard.

[canth]

I have watched these pools They mine almost empty blocks all the time. They may decide to take in transactions with really high fees but most of the blocks from the chines pools are 95% empty not 100% empty but almost empty.

The miners will start to include more transactions within a few hours if we hit them hard.

Bitcoin is a system based upon aligned incentives, not coercion and punishments. If the system tolerates empty blocks and inefficient transactions then changes need to be made or users need to accept this as part of the design. Attacking those who use Bitcoin in a way that some users don't like makes no more sense than does blacklisting certain addresses.

[Quantus]

I hope I"m wrong but I don't think we have time to find a good solution we must act now before its to late.
Transactions propagation time across the network is growing at a huge rate. Attacking the mining pools will only buy us a little more time. With any luck the devs will figure out a solution.

 https://getaddr.bitnodes.io/dashboard/?days=90

[achow101]

I hope I"m wrong but I don't think we have time to find a good solution we must act now before its to late.
Transactions propagation time across the network is growing at a huge rate. Attacking the mining pools will only buy us a little more time. With any luck the devs will figure out a solution.

 https://getaddr.bitnodes.io/dashboard/?days=90

Why are you so intent on attacking the mining pools? They already are under attack, as well as anyone running a full node. Attacking them with a DDoS is NOT going to help at all. It won't buy you any more time, it will just make this worse.

[Quantus]

I believe they are behind this attack and if not they are contributing to it by spitting out empty blocks and not properly validating incoming blocks.
There is no valid reason for any pool to be propagating out to the network empty (and unverified)  blocks when we have a backlog of over 50k transactions.
We need to put them in their place. We have the power to fuck these guys over if they don't want to follow the rules we set forth.


Edit: we start by targeting one pool and with any luck the other pools will get the message.

[favdesu]

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

[favdesu]

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

RAM.

Restart the node and you delete all pending transactions and start from scratch!

oh it's that easy? thanks, wasn't aware of this. so it's no problem for nodes, at least

[achow101]

I believe they are behind this attack and if not they are contributing to it by spitting out empty blocks and not properly validating incoming blocks.
There is no valid reason for any pool to be propagating out to the network empty (and unverified)  blocks when we have a backlog of over 50k transactions.
We need to put them in their place. We have the power to fuck these guys over if they don't want to follow the rules we set forth.


Edit: we start by targeting one pool and with any luck the other pools will get the message.

They don't have an incentive for this attack. It is a waste of resources. Still, empty blocks are not intentional, they are accidental. Even if you did do this to one pool, you would not see results immediately. They need to rewrite a portion of the code and test it before deploying said code. It will take longer than a few hours, and by the time the code is deployed, the attack will either be over, or the pool will no longer be in operation as all their miners have left. The portion they are rewriting would be for either getwork or getblocktemplate from Bitcoin Core because those are the parts of code that create the block parts and the header. You are just going to waste your time and effort and resources by DDoSing them, and it won't help the network either as it will decrease the hashrate thereby increasing confirmation times. If you want to help them and remove the empty blocks, why don't you go checkout the code for Bitcoin and write a patch that prevents empty blocks yourself. This way, you can actually see results by distributing the code to miners if you DDoS them. Of course, that is also blackmail and frowned upon.

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

RAM.

Restart the node and you delete all pending transactions and start from scratch!

Doesn't work like that. You need everyone to shutdown and boot up at the same time. As long as one node is up, it will send all of the transactions it knows of to everyone.

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

Depends on the computer. Whenever it runs out of memory, processing power, or bandwidth. When that happens, the computer will either crash, the software will crash, or its network will go down.

[canth]

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

RAM.

Restart the node and you delete all pending transactions and start from scratch!

Yep - you don't even have to restart the node - just kill and restart bitcoind. -*yeah, good point- as bitcoind starts up it requests transactions it missed*

As far as the critical number goes, it's hard to say. bitcoind currently takes around 1GB on my linux node - presuming a lot of nodes have only 2GB, perhaps it would take 10X current or around 1m transactions in mempool to start causing serious problems?

[Quantus]

mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?

RAM.

Restart the node and you delete all pending transactions and start from scratch!

Yep - you don't even have to restart the node - just kill and restart bitcoind. -*yeah, good point- as bitcoind starts up it requests transactions it missed*

As far as the critical number goes, it's hard to say. bitcoind currently takes around 1GB on my linux node - presuming a lot of nodes have only 2GB, perhaps it would take 10X current or around 1m transactions in mempool to start causing serious problems?

agreed. The clock is ticking.

[Mikestang]

As far as the critical number goes, it's hard to say. bitcoind currently takes around 1GB on my linux node - presuming a lot of nodes have only 2GB, perhaps it would take 10X current or around 1m transactions in mempool to start causing serious problems?

0.55GB on my windows node, but my computer is old and I've noticed a significant performance decrease the last few days because of this.

[Quantus]

Where can we track the number of active full nodes?
I found a list of 765 on https://blockchain.info/ip-log/0
nvm found https://getaddr.bitnodes.io/

[Quantus]

Where can we track the number of active full nodes?
I found a list of 765 on https://blockchain.info/ip-log/0

https://getaddr.bitnodes.io - but this site only lists the nodes that allow incoming connections with their firewall rules.

The link you posted lists only the peers (nodes) that Blockchain.info website is connected to.

yeah it looks like the network is healthy right now as far as the number of full nodes.

[JorgeStolfi]

What about massive "spam attacks" of no-tx-fee transactions, is that possible?  That wouldn't cost anyone anything.

AFAIK, the priority rules and some other safeguards prevent those attacks from disturbing the transactions that pay the minimum fee.  Only legitimate but no-fee transactions will be delayed.

However, those low- or zero-fee attacks do overload the nodes and other programs that look at the queues.  The last (prematurely aborted) stress test crashed blockchain.info and put all bitcoins ATMs out of service.  It may have caused problems also for BitPay and other services that inspect the queues to accept 0-confirmation payments.  The present test even broke this site that was created precisely to monitor the queue s

The post you quoted also makes the assumption that all miners are producing full blocks when that is not the case.  Many miners produce less-than-full blocks, even empty blocks, and so I'm sure that just compounds the issue even further.

Indeed, someone just computed the average of the actual size of mined blocks, and found that they are only 50% full on average, even though the queues have a huge backlog of fee-paying transactions.  Part of the problem is the "hash stealing" shortcut that many pools use, that allows them to start (and finish) mining an empty block well before they can pull the information needed to fill it.  

Thus the maximum capacity of the network is actually only 180'000 tx/day, or ~2.1 tx/s. The current traffic (excluding the stress test) is already 120'000 tx/day.  So if it grows only 25% (30'000 tx/day more) , there will probably be recurrent traffic jams, during which the wait time for the first confirmation will be hours instead of minutes.

I am of the opinion that the answer to the block size debate is not 1 or 8 or 20 or variable, the ultimate solution will be one that address the issue of block size in a manner that hasn't been conceived yet.

I believe that there will have to be both a hike in the transaction fees and in increase to 8 MB.  That would buy another couple of years, at least before the network saturates.

[JorgeStolfi]

With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

An increase in the blocksize LIMIT does not mean an increase in blocksize.

An increase in block size will not reduce the fees.  The minimum fee is fixed by the relay nodes, and could (should, IMHO) be part of the 'consensus rules' so that the miners cannot raise or undercut it.

A spam attack is effective only if it puts out more transactions per minute than the network can process.  With 1 MB block size limit, an attacker needs to issue 0.7 tx/s to create a backlog. With 1 US cent of fee per transaction, that would cost him only 25 dollars per hour.  If the max block size limit was 8 MB, the attacker would have to issue ~15 tx/s and spend ~500 USD/h.  So a bigger block size will make spam attacks a lot less likely (and will clear the backlog faster if they still were to occur).

[JorgeStolfi]

The solution is elegant, but may not please Satoshi dice, colored coins, OP_RETURN users (Factom and alike), faucets (still required?), as it would would impose a minimum fee on the users of the network. Regular users would not see any difference, but spammers would see the cost of their attacks increase by many folds.

Transactions seem free only because the cost of mining (~1 million USD/day) is currently paid by the new investors who buy the mined coins.  That is not healthy economics; the cost of the system should be paid by the users of the system.  At current traffic levels, the cost would be equivalent to ~2% of the total output value of every transaction (excludng obvious change-backs); or to a flat fee of ~8 dollars per transaction; or any suitable combination of the two.  

Therefore, a flat fee of (say) 0.05 USD per output, and a minimum output value of (say) 0.25, would still be extremely generous.  If SatoshiDice is not viable with such fees, too bad: bitcoin was not created to offload the cost of online gambling on non-gambling investors.  Ditto for the other "opportunistic" applications

[sidhujag]

With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

An increase in the blocksize LIMIT does not mean an increase in blocksize.

An increase in block size will not reduce the fees.  The minimum fee is fixed by the relay nodes, and could (should, IMHO) be part of the 'consensus rules' so that the miners cannot raise or undercut it.

A spam attack is effective only if it puts out more transactions per minute than the network can process.  With 1 MB block size limit, an attacker needs to issue 0.7 tx/s to create a backlog. With 1 US cent of fee per transaction, that would cost him only 25 dollars per hour.  If the max block size limit was 8 MB, the attacker would have to issue ~15 tx/s and spend ~500 USD/h.  So a bigger block size will make spam attacks a lot less likely (and will clear the backlog faster if they still were to occur).

It's not fixed its driven by demand:

"If blocks are 8MB, the fees will fall, therefore the cost of getting 1MB of spam on the blockchain will fall. Moving spam from the memepool (a temporary issue) to the UTXO (a permanent issue) is a bad idea. Increasing the blocksize makes the spam problem worse.
Anyway in the medium run, if the blocksize goes to 8MB, spammers will NOT need to spend 8x more to flood blocks. The necessary fees to outbid normal users will be driven by the economic demand for genuine transactions, increasing the blocksize will not necessarly increase this threshold." Jonny1000

Assumptions are our worsed Achilles heal.