Pages:
Author

Topic: Are we stress testing again? - page 18. (Read 33190 times)

hero member
Activity: 910
Merit: 1003
July 11, 2015, 06:29:58 PM
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...
donator
Activity: 1617
Merit: 1012
July 11, 2015, 06:17:33 PM

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.
legendary
Activity: 924
Merit: 1132
July 11, 2015, 05:48:02 PM
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.
staff
Activity: 3458
Merit: 6793
Just writing some code
July 11, 2015, 05:38:01 PM
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.
legendary
Activity: 3556
Merit: 9709
#1 VIP Crypto Casino
July 11, 2015, 05:34:16 PM
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).
member
Activity: 82
Merit: 10
July 11, 2015, 05:22:11 PM
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
copper member
Activity: 2996
Merit: 2371
July 11, 2015, 03:35:23 PM
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
legendary
Activity: 1764
Merit: 1000
July 11, 2015, 02:59:28 PM
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
full member
Activity: 223
Merit: 132
July 11, 2015, 02:04:48 PM
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.
hero member
Activity: 672
Merit: 503
July 11, 2015, 01:53:55 PM
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.
full member
Activity: 223
Merit: 132
July 11, 2015, 01:22:12 PM
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
legendary
Activity: 1764
Merit: 1000
July 11, 2015, 12:04:30 PM
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
copper member
Activity: 2996
Merit: 2371
July 11, 2015, 12:01:12 PM
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).
legendary
Activity: 1148
Merit: 1014
In Satoshi I Trust
July 11, 2015, 11:26:29 AM
hero member
Activity: 910
Merit: 1003
July 11, 2015, 07:16:22 AM
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.
hero member
Activity: 910
Merit: 1003
July 11, 2015, 07:15:27 AM
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.

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

Quote
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.
legendary
Activity: 2660
Merit: 1074
July 11, 2015, 07:11:26 AM
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
legendary
Activity: 1764
Merit: 1000
July 11, 2015, 06:32:42 AM
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
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
July 11, 2015, 06:03:33 AM
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?
legendary
Activity: 929
Merit: 1000
July 11, 2015, 04:36:22 AM
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.


This must be their promised retry.  Their goal is to get 250 MB of unconfirmed transactions in the queues.  They got already over 100 MB and the backlog is still growing.  The network could theoretically process 1 MB (~2500 tx) every 10 minutes, but the miners have been processing only ~0.5 MB (~1300 tx) of transactions per block, on average, even when the queues are fulll; and the normal traffic has been using ~0.32 MB (~800 tx) lately.  Therefore, once the test traffic ends, it will take ~1400 blocks (~10 days) to clear the backlog.

Not all the extra traffic is theirs.  Many of their transactions send many very small amounts to Wikileaks, charitable organizations, or addresses with well-known private keys.  As the recipients of those micro-donations collect them, their transactions add to the test traffic.

Well the transactions are going to charity although it seems to be causing a mess
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

You can see the number of unconfirmed transactions at blockchain.info but if you also want to check the size of the mempool then click this link.

https://tradeblock.com/blockchain/

After clicking the link select the table button to get this view.



It shows the mempool is 77.789309 MB in size as of today. That's about a third of the 250 MB size the stress testers want to push it to.
Pages:
Jump to: