Are we stress testing again? - page 20.

canth

legendary

Activity: 1442

Merit: 1001

Quote from: cryptosky on July 09, 2015, 06:35:23 PM

Does anyone know who is making this stress test?

Someone call the authorities and track down these transactions. Tongue

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.

Alley

legendary

Activity: 910

Merit: 1000

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

cryptosky

newbie

Activity: 20

Merit: 0

Does anyone know who is making this stress test?

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: cakir on July 09, 2015, 06:04:40 PM

I bet first this guy (https://bitcointalksearch.org/user/tkeenan-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?

CohibAA

full member

Activity: 223

Merit: 132

Quote from: cakir on July 09, 2015, 06:04:40 PM

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

Quote

Relayed By Slush

They included it in the block...

cakir

legendary

Activity: 1274

Merit: 1000

★ BitClave ICO: 15/09/17 ★

I bet first this guy (https://bitcointalksearch.org/user/tkeenan-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

full member

Activity: 223

Merit: 132

Quote from: zvs on July 09, 2015, 05:37:20 PM

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?

CohibAA

full member

Activity: 223

Merit: 132

Quote from: ?? on ??

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

...

Perfect, thank you.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: CohibAA on July 09, 2015, 05:33:58 PM

Quote from: ?? on ??

I temporarily set the following options:

Quote

-minrelaytxfee=0.001 -limitfreerelay=0

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

Quote

-limitfreerelay= Continuously rate-limit free transactions to *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

full member

Activity: 223

Merit: 132

Quote from: ?? on ??

I temporarily set the following options:

Quote

-minrelaytxfee=0.001 -limitfreerelay=0

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

Quote

-limitfreerelay= Continuously rate-limit free transactions to *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?

johnyj

legendary

Activity: 1988

Merit: 1012

Beyond Imagination

Quote from: ?? on ??

Quote from: canth on July 08, 2015, 10:48:10 PM

Quote from: ?? on ??

Quote from: favdesu on July 08, 2015, 10:37:53 PM

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

Mikestang

legendary

Activity: 1274

Merit: 1000

Quote from: JorgeStolfi on July 08, 2015, 02:37:34 PM

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: ?? on ??

Quote from: achow101 on July 08, 2015, 10:45:21 PM

Quote from: ?? on ??

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.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: turvarya on July 09, 2015, 05:01:27 AM

Quote from: sidhujag on July 09, 2015, 02:39:11 AM

Quote from: JorgeStolfi on July 09, 2015, 01:16:15 AM

Quote from: sidhujag on July 08, 2015, 06:30:31 PM

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.

Pathi

sr. member

Activity: 244

Merit: 250

Quote from: favdesu on July 09, 2015, 07:38:19 AM

Quote from: Pathi on July 09, 2015, 07:06:55 AM

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.

Pursuer

legendary

Activity: 1638

Merit: 1163

Where is my ring of blades...

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!

favdesu

legendary

Activity: 1764

Merit: 1000

Quote from: Pathi on July 09, 2015, 07:06:55 AM

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

Pathi

sr. member

Activity: 244

Merit: 250

20 hours and still no confirmations...

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

Really frustrating.

turvarya

hero member

Activity: 714

Merit: 500

Quote from: sidhujag on July 09, 2015, 02:39:11 AM

Quote from: JorgeStolfi on July 09, 2015, 01:16:15 AM

Quote from: sidhujag on July 08, 2015, 06:30:31 PM

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.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: JorgeStolfi on July 09, 2015, 01:16:15 AM

Quote from: sidhujag on July 08, 2015, 06:30:31 PM

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.

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