Are we stress testing again?

[turvarya]

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.

So, the assumption that fees will fall, when the max block size increases is our worst Achilles heel?
Seriously, most people are just making a lot of assumption based on what they saw in a Meme.

[1714996691]

1714996691

[1714996691]

1714996691

[1714996691]

1714996691

[Pathi]

20 hours and still no confirmations...


http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

Really frustrating.

[favdesu]

20 hours and still no confirmations...


http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

Really frustrating.

but there's a confirmation at least your transaction cleared.

better add a higher TX fee for the time being

[Pursuer]

this is getting really frustrating now. I had 2 transactions stuck for a whole day during this nonsense.

the normal (standard) fee is no longer enough!

[Pathi]

20 hours and still no confirmations...


http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

Really frustrating.

but there's a confirmation at least your transaction cleared.

better add a higher TX fee for the time being

Yeah I see it now. Unfortunately I am the recipient of this transaction, so no control over fee. I hope Nicehash adjusts their fees today.

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

So, the assumption that fees will fall, when the max block size increases is our worst Achilles heel?
Seriously, most people are just making a lot of assumption based on what they saw in a Meme.

The opposite.. Assuming they won't fall.

[achow101]

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.

Agree to disagree?  

My experience is that an upcoming node will only listen to new incoming tx relayed by the peers - it won't ask for the full outstanding list of standby tx from its peers. If I am incorrect, please provide me with the codebase.

When I restart my node, my "getmempoolinfo" starts with 0, and then grows with time - not because I receive the full list of outstanding tx from my peers, but because it matches the rate of "fresh" incoming transactions.

I have learned to do this by being an Electrum-Server.  I use to restart its Bitcoin daemon once a week, to get rid of the unconfirmed transactions that clogged the RAM  - this week, I am doing it daily.

In a way, it is not bad, if everyone would do that, it would allow payers to resend their coins (which are still not included into a block) with a higher fee, without being discarded by the nodes as a "double spent".  

I'm pretty sure that you will still end up with all of the transactions that are in the mempool anyways, or most of them. When your node receives a transaction, it will check its validity, and in order to do that, it must have its parent. If it doesn't have the parent, then it requests it from other nodes. And so on and so forth. If someone was spamming the network with the transactions go down a chain (e.g. A -> B -> C...) then your node will still get all of those transactions because it requires the parent to validate a transaction. Other spam where 1 parent has multiple children may not cause your mempool to fill up because it does not see all of the child transactions. However, once a transaction that consolidates all of the micro transactions into one address comes out, your node will still have to request all of those micro transactions and still fill up your mempool. So you will pretty much still have to get all of those transactions again from somewhere and fill up your mempool.

[Mikestang]

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.

Is that cost just the tx fees?  Because if you're sending transactions to yourself the only cost would be tx fee.  I didn't see this stated, so just wondering.

[johnyj]

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?

My node has been up without restart for over a week (so up for all these recent tests) and is connected to 60+ peers.

getmempoolinfo

{
"size" : 2178,
"bytes" : 2634223
}

According to task manager Bitcoin Core is using 500MB of RAM (slightly more than my web browser).

Sup? Everyone here knows you can modify your fee rules to ignore transactions that you consider spam, right?

Mine 1-week-uptime node's getmempoolinfo shows 5xxxx for size and 124xxxxxx for bytes, 5 minutes after a restart of the process, size become 1476 and bytes become 3xxxxxx, let's see what it will finally show, I guess after 6 hours it will catch up with the rest of the nodes

[CohibAA]

I temporarily set the following options:

-minrelaytxfee=0.001 -limitfreerelay=0

I'm avoiding transactions on the blockchain at the moment (mostly doing SEPA wires now...)

-limitfreerelay=<n>          Continuously rate-limit free transactions to <n>*1000 bytes per minute (default:15)

minrelaytxfee=0.xxx and mintxfee=0.xxx will help if your node is lagging, for sure.


I've read, but can't find the source right now that limitfreerelay shouldn't be set to 0, but instead to 1.  It's measured in kb allocated to free/high-priority transactions, and the claim was that setting to 0 would actually restore the default value (15 kb).

Can anyone verify, either way?

[zvs]

I temporarily set the following options:

-minrelaytxfee=0.001 -limitfreerelay=0

I'm avoiding transactions on the blockchain at the moment (mostly doing SEPA wires now...)

-limitfreerelay=<n>          Continuously rate-limit free transactions to <n>*1000 bytes per minute (default:15)

minrelaytxfee=0.xxx and mintxfee=0.xxx will help if your node is lagging, for sure.


I've read, but can't find the source right now that limitfreerelay shouldn't be set to 0, but instead to 1.  It's measured in kb allocated to free/high-priority transactions, and the claim was that setting to 0 would actually restore the default value (15 kb).

Can anyone verify, either way?

kind of, yeah.  though if the problem is downstream bandwidth, you'll be out of luck, even with those settings

and I use these:

mintxfee=0.0001
minrelaytxfee=0.0001
limitfreerelay=0
blockminsize=0
blockprioritysize=0

oh, and here is an example of what I mean, re: this is what your peer list looks like when everyone else is flooding you with dust transactions

Code:

  {
    "id": 37,
    "addr": "ipv6:8333",
    "addrlocal": "gangnam",
    "services": "0000000000000003",
    "lastsend": 1436481618,
    "lastrecv": 1436481618,
    "bytessent": 1785478,
    "bytesrecv": 23670587,
    "conntime": 1436477662,
    "timeoffset": 0,
    "pingtime": 0.06790500,
    "version": 70003,
    "subver": "/Bitcoin XT:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364599,
    "synced_blocks": 364599,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 38,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 2207672,
    "bytesrecv": 14434904,
    "conntime": 1436477663,
    "timeoffset": -2,
    "pingtime": 0.36456500,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 41,
    "addr": "ipv6:8333",
    "addrlocal": "gangnam",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 2000115,
    "bytesrecv": 17358323,
    "conntime": 1436477663,
    "timeoffset": 0,
    "pingtime": 0.11342300,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364607,
    "synced_blocks": 364607,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 42,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 1037411,
    "bytesrecv": 17674962,
    "conntime": 1436477663,
    "timeoffset": 0,
    "pingtime": 0.05954100,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 43,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481618,
    "bytessent": 1033799,
    "bytesrecv": 17991886,
    "conntime": 1436477663,
    "timeoffset": 0,
    "pingtime": 0.11224400,
    "version": 70002,
    "subver": "/Satoshi:0.10.1/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 44,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 3983425,
    "bytesrecv": 16857389,
    "conntime": 1436477663,
    "timeoffset": -1,
    "pingtime": 0.11399700,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 45,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 2155391,
    "bytesrecv": 17652045,
    "conntime": 1436477663,
    "timeoffset": 10,
    "pingtime": 0.36462200,
    "version": 70002,
    "subver": "/Satoshi:0.10.1/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364607,
    "synced_blocks": 364607,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 46,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 2229207,
    "bytesrecv": 17663426,
    "conntime": 1436477664,
    "timeoffset": 7,
    "pingtime": 0.38534900,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 47,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 4674688,
    "bytesrecv": 17627298,
    "conntime": 1436477664,
    "timeoffset": -13,
    "pingtime": 0.83111700,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364601,
    "synced_blocks": 364601,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 48,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481618,
    "bytessent": 2846248,
    "bytesrecv": 18435766,
    "conntime": 1436477664,
    "timeoffset": -4,
    "pingtime": 0.17268700,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364599,
    "synced_blocks": 364599,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 49,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 1014515,
    "bytesrecv": 17733905,
    "conntime": 1436477665,
    "timeoffset": -23,
    "pingtime": 0.16491500,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false
  },
  {
    "id": 51,
    "addr": "ipv4:8333",
    "addrlocal": "style",
    "services": "0000000000000001",
    "lastsend": 1436481618,
    "lastrecv": 1436481619,
    "bytessent": 1059026,
    "bytesrecv": 15543199,
    "conntime": 1436477665,
    "timeoffset": -1,
    "pingtime": 0.09709600,
    "version": 70002,
    "subver": "/Satoshi:0.10.2/",
    "inbound": false,
    "startingheight": 364599,
    "banscore": 0,
    "synced_headers": 364608,
    "synced_blocks": 364608,
    "inflight": [
    ],
    "whitelisted": false

client runtime: about 60-65 minutes

[CohibAA]

0 means 0, only if you don't set it the default setting is 15:

...

Perfect, thank you.

[CohibAA]

kind of, yeah.  though if the problem is downstream bandwidth, you'll be out of luck, even with those settings

Understood.  I am just curious; how would a downstream bandwidth problem present itself?  Wouldn't you just receive less bytes/second, which wouldn't actually slow down the local server?  Maybe you mean something different than ISP level downstream?

[cakir]

I bet first this guy (https://bitcointalk.org/index.php?action=profile;u=154254) (Yes, TKeenan) will come here and post something like that "Hey, let's use bigger blocks, don't you see we need it right now!"

I'm still thinking Gavin is doing such spamming.

Also how the hell is that possible?
This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
It's outputs are lower than the min limit...

[CohibAA]

Also how the hell is that possible?
This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
It's outputs are lower than the min limit...

Relayed By    Slush

They included it in the block...

[sidhujag]

I bet first this guy (https://bitcointalk.org/index.php?action=profile;u=154254) (Yes, TKeenan) will come here and post something like that "Hey, let's use bigger blocks, don't you see we need it right now!"

I'm still thinking Gavin is doing such spamming.

Also how the hell is that possible?
This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
It's outputs are lower than the min limit...

Each block has a FIFO area in size where it accepts tx for free. do you mean DUST got accepted?

[cryptosky]

Does anyone know who is making this stress test?

[Alley]

Back up to 72,000 unconfirmed tx.  I think this is the new normal.

[canth]

Does anyone know who is making this stress test?

Someone call the authorities and track down these transactions.   </endassclown comments>

No, I don't think anyone knows the source of the spam/stress test this time around. Someone with a decent amount of funds and a motivation to force some improvements, I'd say.

[JorgeStolfi]

"If blocks are 8MB, the fees will fall, therefore the cost of getting 1MB of spam on the blockchain will fall.

A Spam attack does not aim to put spam on the blockchain (there is plenty of it already), but to swamp the queues so as to deny service by hours or days.  With 1 MB blocks, the spammer needs to issue only 0.7 tx/s, at a sufficiently high fee, to keep legitimate transactions from being confirmed.  With 8 MB blocks, it would have to issue ~15 tx/s all at the same high fee to keep those same transactions from being confirmed.

Hard to believe that the let-it-saturate-hooray camp can honestly think that SMALLER block sizes will make spam attacks more difficult.  What have they promised to their investors, that they need to resort to lies and ad-hominems to try to prevent any block increase?

To prevent the filling up of the blockchain and the utxo tables with spam, there is a much simpler measure: set a fixed, hard, and significant transaction fee, say 0.2 mBTC (~0.05 USD), for each output, whatever its amount; and a fixed, hard, and significant minimum output value, say 0.1 mBTC (~0.03 USD).  Any existing UTXO smaller than this amount then can be removed from the tables.