Are we stress testing again?

[SebastianJu]

Slowly i get angry about these guys. I didnt know that they started a new stresstest and have a transaction stuck since days now. And they really spam all this time as if they never want to stop. Sooo annoying.

What i wonder, why arent there miners that explicitely not confirm these transactions? They could clear up all the normal transactions pretty fast and could prove their point that no bigger blocks are needed. Wouldnt that be easy?

And i have read that certain other coins have protection against being spammed. Is that only done by minimum fees and minimum amounts to send? I think the current fees and amounts are an advantage of bitcoin. I wouldnt like to see the usefulness of bitcoin limited. So is that the only solution these other coins use?

[favdesu]

Slowly i get angry about these guys. I didnt know that they started a new stresstest and have a transaction stuck since days now. And they really spam all this time as if they never want to stop. Sooo annoying.

What i wonder, why arent there miners that explicitely not confirm these transactions? They could clear up all the normal transactions pretty fast and could prove their point that no bigger blocks are needed. Wouldnt that be easy?

And i have read that certain other coins have protection against being spammed. Is that only done by minimum fees and minimum amounts to send? I think the current fees and amounts are an advantage of bitcoin. I wouldnt like to see the usefulness of bitcoin limited. So is that the only solution these other coins use?

it seems the stress test has ended? only 40k in the mempool, it's a huge backlog which will take some time to clear

[jaberwock]

This problem was addressed and fixed with litecoin years ago.

LTD dev, Coblee advised bitcoin devs about this but no one listened.

If this problem persists, there is an alternative coin on standby ready to go.

Litecoin has close to no volume compared to Bitcoin, and I doubt it would do any better than BTC if submitted to such stress tests + daily volume.

And even the LTC devs don't care about LTC

[JorgeStolfi]

What i wonder, why arent there miners that explicitely not confirm these transactions? They could clear up all the normal transactions pretty fast and could prove their point that no bigger blocks are needed. Wouldnt that be easy?

The stress test guys may be identifying their transactions, but in a real hostile attack it would be impossible to distinguish the attacker's transactions from legitimate ones.  But gettng miners to "censor" transactions of "bad guys" would be the end of bitcoin.  The plan was that there would always be a miner willing to send your transactions through, even if some of the miners wanted to block them.

And i have read that certain other coins have protection against being spammed. Is that only done by minimum fees and minimum amounts to send?

Litecoin requires a fee for each small output of the transaction.  Bitcoin considered doing the same but rejected the idea for some reason.

I think the current fees and amounts are an advantage of bitcoin. I wouldnt like to see the usefulness of bitcoin limited.

The current maintaners of the reference implementation want to keep the blocks small so that the fees will go up so that only large entities would be able to use bitcoin directly; other bitcoiners would have to use services like Coinbase or Circle, or some "overlay network" that their company is developing.

[JorgeStolfi]

I was wondering when people refer to the backlog where do you find the chart that measures the amount of data.
Just wanted to check if I was looking at the right place https://blockchain.info/unconfirmed-transactions

Besides Tradeblock (that would be more useful if it showed more information and less decoration), these sites seem useful to monitor the stress test:

http://statoshi.info/dashboard/db/transactions?from=1435853599769&to=1436544799769

https://bitcoinfees.github.io/#3h

The second one shows the (estimated) fees needed to get confirmation in 12 min, 20 min, etc.  A pity that it broke down during the peak of 2 days ago.

it seems the stress test has ended? only 40k in the mempool, it's a huge backlog which will take some time to clear

Don't trust the Blockchain.info statistics.  Or anything else by them.

[LiteCoinGuy]

[Quickseller]

it seems the stress test has ended? only 40k in the mempool, it's a huge backlog which will take some time to clear

Don't trust the Blockchain.info statistics.  Or anything else by them.

Based off of their rejected inventory page, it appears that they have changed their node to not relay a certain criteria for transactions that are generally relayed by other nodes, thus if you want your transaction that meets their criteria to not be relayed to be displayed on blockchain.info then you should wait for such transaction to get confirmed (I may be mistaken about this though).

The best way to get network information, is from your well connected node that uses default settings. The current mempool size is roughly 151 MB and contains roughly 57.5k transactions. (My "relay fee" is currently set to 0.00001000 which I believe is the default, although I was adjusting it a few days ago for some testing but adjusted everything back to what I believe are the default settings).

[favdesu]

I was wondering when people refer to the backlog where do you find the chart that measures the amount of data.
Just wanted to check if I was looking at the right place https://blockchain.info/unconfirmed-transactions

Besides Tradeblock (that would be more useful if it showed more information and less decoration), these sites seem useful to monitor the stress test:

http://statoshi.info/dashboard/db/transactions?from=1435853599769&to=1436544799769

https://bitcoinfees.github.io/#3h

The second one shows the (estimated) fees needed to get confirmation in 12 min, 20 min, etc.  A pity that it broke down during the peak of 2 days ago.

it seems the stress test has ended? only 40k in the mempool, it's a huge backlog which will take some time to clear

Don't trust the Blockchain.info statistics.  Or anything else by them.

I don't use blockchain.info for stats though. here's where I check relevant data https://tradeblock.com/blockchain

[CohibAA]

Based off of their rejected inventory page, it appears that they have changed their node to not relay a certain criteria for transactions that are generally relayed by other nodes, thus if you want your transaction that meets their criteria to not be relayed to be displayed on blockchain.info then you should wait for such transaction to get confirmed (I may be mistaken about this though).

This seems correct in my experience the last few days with blockchain.info also.

The best way to get network information, is from your well connected node that uses default settings. The current mempool size is roughly 151 MB and contains roughly 57.5k transactions. (My "relay fee" is currently set to 0.00001000 which I believe is the default, although I was adjusting it a few days ago for some testing but adjusted everything back to what I believe are the default settings).

For comparison, my btc node is only carrying about 2500 transactions for about 3000 kb in mempool.  My bitcoin.conf settings are currently:

Code:

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

[neurotypical]

I don't think this is going to stop unless active actions are taking against it by the devs. It's someone with an agenda, a rather positive one, to push the devs to come to terms and do something about this. The LTC fix should have been deployed days ago, even if it was an update that only did that alone.

[CohibAA]

I don't think this is going to stop unless active actions are taking against it by the devs. It's someone with an agenda, a rather positive one, to push the devs to come to terms and do something about this. The LTC fix should have been deployed days ago, even if it was an update that only did that alone.

Why should the core devs rush a change to production?  The network is actually working exactly as it is supposed to.  Nothing with bitcoin core is broken from the flood of transactions, except the ability to send free transactions through the network in a timely manner, if at all.  That is by design.

That said... lots of devs that work on applications which rely on low fee and low volume need to re-evaluate their projects.  Many of them have, and lots of changes to those projects have been deployed this week, or are being tested to deploy.  I think that is a good thing.

[favdesu]

I don't think this is going to stop unless active actions are taking against it by the devs. It's someone with an agenda, a rather positive one, to push the devs to come to terms and do something about this. The LTC fix should have been deployed days ago, even if it was an update that only did that alone.

Why should the core devs rush a change to production?  The network is actually working exactly as it is supposed to.  Nothing with bitcoin core is broken from the flood of transactions, except the ability to send free transactions through the network in a timely manner, if at all.  That is by design.

That said... lots of devs that work on applications which rely on low fee and low volume need to re-evaluate their projects.  Many of them have, and lots of changes to those projects have been deployed this week, or are being tested to deploy.  I think that is a good thing.

fully agree. everything works as usual, even during a stress test or attack. no need to rush anything

[Quickseller]

The best way to get network information, is from your well connected node that uses default settings. The current mempool size is roughly 151 MB and contains roughly 57.5k transactions. (My "relay fee" is currently set to 0.00001000 which I believe is the default, although I was adjusting it a few days ago for some testing but adjusted everything back to what I believe are the default settings).

For comparison, my btc node is only carrying about 2500 transactions for about 3000 kb in mempool.  My bitcoin.conf settings are currently:

Code:

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

It appears that node is a p2pool node, I am not 100% sure how p2pool chooses which transactions to include in their found blocks, however I would think that it would have to do with something one of the nodes decides. If you do not want to include low fee transactions in your found blocks then the above would probably be more optimal settings (it would probably also somewhat increase your mining revenue).

It does appear that generally speaking the "standard" minimum tx fees that pools will accept is going to be a minimum of .0001 BTC, although it is up to the individual pools to make this choice, and under normal circumstances, some pools may include additional no/low txfee transactions when their mempool is low. I don't really see any harm in relaying additional low txfee transactions to the network, and it does appear that the default settings on at least previous versions of bitcoin has the minrelaytxfee set to .00001

I think it can be generally agreed upon that overall the current mempool size is greater then 3 MB, and the network would quickly run out of transactions to confirm if they only included transactions with a fee of .0001 attached.

I do think the obvious solution to the spam attack is to accelerate the date when the protocol is hard-forked to allow 8 (or 20) MB blocks, which would make it much more expensive to conduct such an attack in the future, and would make clearing the backlog a much quicker process

[wersaup]

The best way to get network information, is from your well connected node that uses default settings. The current mempool size is roughly 151 MB and contains roughly 57.5k transactions. (My "relay fee" is currently set to 0.00001000 which I believe is the default, although I was adjusting it a few days ago for some testing but adjusted everything back to what I believe are the default settings).

For comparison, my btc node is only carrying about 2500 transactions for about 3000 kb in mempool.  My bitcoin.conf settings are currently:

Code:

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

It appears that node is a p2pool node, I am not 100% sure how p2pool chooses which transactions to include in their found blocks, however I would think that it would have to do with something one of the nodes decides. If you do not want to include low fee transactions in your found blocks then the above would probably be more optimal settings (it would probably also somewhat increase your mining revenue).

It does appear that generally speaking the "standard" minimum tx fees that pools will accept is going to be a minimum of .0001 BTC, although it is up to the individual pools to make this choice, and under normal circumstances, some pools may include additional no/low txfee transactions when their mempool is low. I don't really see any harm in relaying additional low txfee transactions to the network, and it does appear that the default settings on at least previous versions of bitcoin has the minrelaytxfee set to .00001

I think it can be generally agreed upon that overall the current mempool size is greater then 3 MB, and the network would quickly run out of transactions to confirm if they only included transactions with a fee of .0001 attached.

I do think the obvious solution to the spam attack is to accelerate the date when the protocol is hard-forked to allow 8 (or 20) MB blocks, which would make it much more expensive to conduct such an attack in the future, and would make clearing the backlog a much quicker process

and what would that achieve? People would just go over from spamming tx to delay them to carrying out denial of service attacks by bloating the blockchain to a point where bitcoind quits because drive space is up - I mean seriously, we're at 45g currently, its getting ridiculous to run a full node(and unfortunately at least for me bitcoin core is currently the only option to run off) by now, especially on mobile computers which traditionally have limited space. I submitted a patch to bitcoin git over 2 years ago that would create an option for bitcoin core to truncate the blockchain by simply discarding all transactions that had all outputs spent and confirmed by 120 blocks - it got rejected, but especially these days it would save about 95% of the disk space that is currently used by bitcoins block chain

[LFC_Bitcoin]

Any ideas if this rubbish is going to stop soon? How much longer will it go on before they feel they have made their point (regarding increasing block size).

[achow101]

and what would that achieve? People would just go over from spamming tx to delay them to carrying out denial of service attacks by bloating the blockchain to a point where bitcoind quits because drive space is up - I mean seriously, we're at 45g currently, its getting ridiculous to run a full node(and unfortunately at least for me bitcoin core is currently the only option to run off) by now, especially on mobile computers which traditionally have limited space. I submitted a patch to bitcoin git over 2 years ago that would create an option for bitcoin core to truncate the blockchain by simply discarding all transactions that had all outputs spent and confirmed by 120 blocks - it got rejected, but especially these days it would save about 95% of the disk space that is currently used by bitcoins block chain

Although your patch was rejected, Bitcoin Core 0.11 includes new code that does blockchain pruning, similar to what your patch does (I think) but in such a way that has been tested and confirmed to work without breaking anything else.

[Cryddit]

For what it's worth, I'm running a bitcoin full node on a server with 64G RAM memory, at 173.228.13.5, at the usual port.

Because of massive memory, and the fact that I invoked it with maxorphantx=10000, it's not dumping tx out of its mempool. Because I invoked it with maxconnections=500 and at the moment only am connected to 50 peers, there's plenty of room for you if you'd like to connect and "not lose track" of all the transactions.

At this moment I'm showing 184Mbytes of unconfirmed transactions - amounting to 74563 tx.

[Soros Shorts]

For comparison, my btc node is only carrying about 2500 transactions for about 3000 kb in mempool.  My bitcoin.conf settings are currently:

Code:

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

It appears that node is a p2pool node, I am not 100% sure how p2pool chooses which transactions to include in their found blocks, however I would think that it would have to do with something one of the nodes decides. If you do not want to include low fee transactions in your found blocks then the above would probably be more optimal settings (it would probably also somewhat increase your mining revenue).

As a former p2pool miner, I can tell you that one of the motivations behind those settings was to reduce orphaned p2pool shares by reducing the size of the mined blocks. For a low-powered node the it was a difference between getting all your shares orphaned and the resulting 0 income vs. getting at least some income. Since p2pool shares are actually valid low-difficulty Bitcoin blocks that are that are solved once every 30 seconds (instead of 10 minutes), any negative impact of increasing the blocksize limit would be likely felt first by the p2pool network before the actual Bitcoin network.

[JorgeStolfi]

The network is actually working exactly as it is supposed to.  Nothing with bitcoin core is broken from the flood of transactions, except the ability to send free transactions through the network in a timely manner, if at all.  That is by design.

There are tons of posts on reddit by ordinary users complaining about their transaction being delayed for many hours.  They are mostly those who who just let their wallet app choose the transaction fee.  It happens that the stress test is now using standard and maybe above-standard fees.  

Luckily, this is a (pedagogical?) test, not an attack.  Thus, clients who have read the source code of the core implementation (and are aware of the modifications and parameter choices made by the major miners and relay nodes) can easily compute the fee that will let their transaction go through in the next N blocks, provided only that they correctly guess what fees will be paid by the 20'000 x N transactions that will be issued by the testers in the next 10 x N minutes, and also by the 800 x N transactions  that will be issued by ordinary clients who want to get their transactions in front of the queue.

For example, half an hour ago the fee to get into one of the next 12 blocks was 4.5 US cents, but then the testers paused to catch their breath, and now it is only 2.6 cents or so.  Hurry up before they resume, perhaps by raising their fees.

Apparently, the total cost of this stress test so far has been ~30 BTC yesterday, and ~20 BTC today, not counting the "payload" (output amounts) that is ultimately being donated to Wikileaks, charities, and known "public fountain" addresses.  That is ~15'000 USD, which is about three times Coinwallet's originally declared budget (5000 euros).   Their peak transaction issuance rate, according to statoshi.info, was over 100 tx per second (the actual capacity of the network being ~2.7 tx/s).  

Now imagine what a *malicious* spam attack fould do with that sort of budget...

[CohibAA]

I don't think this is going to stop unless active actions are taking against it by the devs. It's someone with an agenda, a rather positive one, to push the devs to come to terms and do something about this. The LTC fix should have been deployed days ago, even if it was an update that only did that alone.

Why should the core devs rush a change to production?  The network is actually working exactly as it is supposed to.  Nothing with bitcoin core is broken from the flood of transactions, except the ability to send free transactions through the network in a timely manner, if at all.  That is by design.

That said... lots of devs that work on applications which rely on low fee and low volume need to re-evaluate their projects.  Many of them have, and lots of changes to those projects have been deployed this week, or are being tested to deploy.  I think that is a good thing.

The network is actually working exactly as it is supposed to.  Nothing with bitcoin core is broken from the flood of transactions, except the ability to send free transactions through the network in a timely manner, if at all.  That is by design.

There are tons of posts on reddit by ordinary users complaining about their transaction being delayed for many hours.  They are mostly those who who just let their wallet app choose the transaction fee.  It happens that the stress test is now using standard and maybe above-standard fees. 

I know it's the internet but if you're going to quote me, use the full context, please.

The core client wallet lets you see estimated fees to get your transaction confirmed within the next Nth block, and adjust the fees above or below the threshold as desired.  The devs of those wallet apps need to adjust their coding, not the core devs, imo.  Maybe you were just restating my point, and I misunderstood.

Luckily, this is a (pedagogical?) test, not an attack.  Thus, clients who have read the source code of the core implementation (and are aware of the modifications and parameter choices made by the major miners and relay nodes) can easily compute the fee that will let their transaction go through in the next N blocks, provided only that they correctly guess what fees will be paid by the 20'000 x N transactions that will be issued by the testers in the next 10 x N minutes, and also by the 800 x N transactions  that will be issued by ordinary clients who want to get their transactions in front of the queue.

For example, half an hour ago the fee to get into one of the next 12 blocks was 4.5 US cents, but then the testers paused to catch their breath, and now it is only 2.6 cents or so.  Hurry up before they resume, perhaps by raising their fees.

Apparently, the total cost of this stress test so far has been ~30 BTC yesterday, and ~20 BTC today, not counting the "payload" (output amounts) that is ultimately being donated to Wikileaks, charities, and known "public fountain" addresses.  That is ~15'000 USD, which is about three times Coinwallet's originally declared budget (5000 euros).   Their peak transaction issuance rate, according to statoshi.info, was over 100 tx per second (the actual capacity of the network being ~2.7 tx/s). 

Now imagine what a *malicious* spam attack fould do with that sort of budget...

Right... they could buy a shit ton of BTC, if they don't already have it and attack with higher transaction fees.  The results would be a) the core client would keep working just like it always does b) miners would be collecting those fees c) anyone else sending transactions has to choose to either wait to send, or send with a higher fee than the attackers.

That means, a) the network keeps chugging along b) miners keep mining and making even higher fees c) users keep being users at the higher transaction cost (which is still relatively inexpensive even at 0.01 BTC per transaction, compared to other options to send money around the world) or choose to be holders.  Miners won't care about the attack because they are making money and the network is still functioning as designed.  Users that keep using may care because of higher cost.  Many will choose to wait because the attacks have the effect of raising the value of a coin versus the dollar.  The attacker, even with "unlimited USD" still has to trade that USD for bitcoins somewhere.  This drives the price up.  If it is an attacker with a large sum of BTC they acquired at a lower exchange rate, this just serves to redistribute that wealth value.

But, my main point was that the core client is working as intended and doesn't need reactionary changes.  Some of the applications that depend on it do need quick changes if they want to satisfy their users.  Is it good for the immediate health of bitcoin to suffer these types of "attacks"?  Not particularly, because application devs were not prepared in some cases, and can't react fast enough to satisfy their users, which might hurt some levels of bitcoin adoption.  For the most part, though, I think it's a great thing, and hope someone keeps spending their money on this kind of thing.  It drives advancement, thought, and prices.