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

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

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.

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.

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.

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

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

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

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

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.

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.

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


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

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

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

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.


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

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.


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


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.

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

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

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?

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.