Topic: A scaled up spam experiment : #SpamTheBlockchain As A Service - page 2. (Read 11044 times)

I am also in progress of writing such tool.
I prefer Qt/C++ , so I am rewriting now Peter Todd's  tool
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py

UPDATE:
The stored data is bitcoin core developers chatlog. It is visible here:
http://bitcoinstrings.com/blk00281.txt
I am too lazy to read it

not me, but would have helped if he asked me.
This is 0.012 BTC for fulling a block, or 1.728BTC for a fully day, a goal of 30 day is "only" 51 BTC.
The spam website I want to do, funded by anybody who wants to spam, may reach such goal.

And I don't even want to reach full blocks, only keep a rate superior to 7tx/s, so would cost probably around 25 BTC.

wow!  

Somebody sent a large amount of spam transactions ~2 hours ago
All of them are here: https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T as incoming txs
(this is well-known chbs-address)

Note: the spamer spent very small amount for fee.
for example this tx https://blockchain.info/tx/e7bf1079255f6defe23ff2c87aad1a9302183bf8f7db10d07567ff535eeeb8f2
contains ~15 kb of data and costs him only 0.00019843 BTC (as fees)

You underestimate the capacity of bc.i to have creative bugs.

Haha - probably unrelated. Do they have a testnet explorer?

I pinged a few testnet faucets for coins to see how long they take, with all this going on. If there's a huge difference in priority maybe they'll be scattered over the following few blocks?

you broke blockchain info ? https://twitter.com/blockchain/status/607227102639865856?s=09

The way I'm traversing it should mean tt pops a parent, and adds 5 new ones to the end. 'The end' gets further away each time. I am also saving all transactions to a file, so I rebroadcast that every once in a while.

At this point I think there's about 42 blocks worth of transactions in there (90k). Bitcoin's 7tx per second rate is essentially the maximum rate it can clear the mempool (assuming all blocks are full). I can produce transactions at roughly this rate, so the mempool should at least stay fixed in size.

However, most of the blocks on testnet have no transactions in them, reducing the rate of mempool clearance, so the mempool should continue to increase in size.

It might be worth noting that regardless of the transaction size, I have attached a default fee of 100,000 satoshis for each transaction. This seems to be sufficient for most of the tree, and I've had very few with insufficient priority.

https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg
Well, actually you crashed my firefox when I browsed https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg/transactions
I also see the mempool peak in RAM of my bitcoind (to 150MB but it then dropped to 50MB and stopped moving) and my block explorer (tapi.qbit.ninja) holding.
I thought the mempool was keeping transactions in memory. (must go back to the source code to check how implemented)
The problem of a tree of transaction is that if a node transaction in the tree is missed, the bitcoind willl reject further transactions to go in the pool.

The deeper the tree, the higher the odds of one of its parent not having reached the mempool before one of the child, and thus preventing the hierarchy to further spam nodes.

I am also curious about keeping the rate just at more than 7 tx per sec for months.

I'll make the website, and provide a way for the spammer to choose whether he wants testnet or mainnet, as well as spamming in volume or in duration.

I will not be using RPC at all, so should not have a bottleneck.

Nicholas: I've been playing with this over the past few days on testnet. I reckon the most effective way is to take a txid and private key (which can spend an output of that txid) from the user, grow it into a tree of dependent transactions, and then broadcast all at once.

The value of the output limits how many subsequent transactions you can get. I'm using a redis queue and a bash loop to call something to pop, split into $split new transactions, and push new ones to the end for further splitting.

I've launched it a few times, normally in batches of 700 tx's. Broadcasting is a very fast step, and the mempool fills up quickly. Block explorers seem to hold their ground, though are can be slow to make all transactions in a block available in the UI. In fact, many seem to rush to publishing the block on their website, despite the transactions not being fully imported to their database. I wonder what fast, full blocks would do to these services. If they can't keep up with 1Mb blocks ("full" or otherwise) we'll learn something from this.

Full blocks blocks max out at 750kb, or about 2111 transactions. There is still a miner who is not including transactions.. I wonder if he's sympathetic to this experiment.. They appear to to have about 50% of the hashrate at times, so this makes the spamming more effective, as the rate the mempool is purged is effectively halved.

What way do you plan on doing it? I found using the RPC quite slow, and since new change keys/addresses are generated you run into a bottleneck.

Sorry, I got a bit busy this week, so here my responses


I will not, since their code would have broken anyway later on. We can contact me so I stop the website (btw, the code will be open source so other people might host it)

Knowing generally what will happen if tx/s is above 14, mempool continually growing. (well, this is what I want to see, other people would be more interested into economic impact on fees, machine spec for nodes, decentralization impact)

You are right for testing a mempool attack, (so I will provide a testnet mode) but we can't test the economical impact with fake money.

Not me, I have not yet started coding it.

The spam is no different from what will happen for real when blocks will be full.
The goal is to learn what we can about that before we hit the real wall.

If the attack can't work because fees are too high, then it would also proves something valuable.

Why don't you try this on some Altcoins. After all thats their purpose
Lets use those as the guinea pig, if not testnet. As far as I know I have been able to send tx with 0 fee without any problem in most altcoins.

FYI, I don't like your experiment. I don't like spam.

Do it elsewhere, not on mainnet.

spam is among the worst thing on the internet. everyone always looking to spam something

I was responding to his queries about the antminer blocks.

I did get it running. 2 nights ago I did 2000tx/hr using the RPC. This time I can turn a single 4BTC output into 781 transactions, and repeat this until I have enough to really stress things (by precomputing many in advance). Unfortunately my laptop runs out of memory when I try to split outputs of over 10BTC..

This is the address I'm using: https://www.blocktrail.com/tBTC/address/mvoh3Jwirz6YLdSdpp1558uHWdJ9Qpijjg

Testnet is testnet. Bitcoin is bitcoin.

Did you deploy?  And are the issues these guys are eperiencing related to you? https://bitcointalk.org/index.php?topic=1079182.0;topicseen

Just curious.

FWIW I can mine testnet coin very easily. In a few hours I mined about 18,000, more than enough to fund this experiment for a month.

In fact, I've been giving it a go - https://www.blocktrail.com/tBTC/address/n2GcwNsdybZrr6mbLakrwgQoWSurABHU3a I've broadcast about 30,000 transactions on testnet in the past 12 hours. It currently leaves about 4000 tx's in the mempool with and none of the blocks exceeding 750kb.

Some numbers: I moved 30testnet coins in 30,000 transactions, for a fee of 0.51 (dynamically calculated by the client). I have 18,000 testnet coins. So we can deploy this on testnet today, and see exactly what will happen.

This sounds like something I'm in the works of developing! I wonder what the outcome will be long term, hoping for the best.

Salut Nicolas,

I feel uncomfortable with your "experiment" as from what I understood, it is not more not less than a real attack towards the Bitcoin network.

TestNet appears to me like a better suited environnement for this kind of experiment.

It should be noticed that "estimatefee", a Bitcoin Core command to estimate fees to pay, seems a bit high, when it suggests to pay 0.00044247 BTC/kB to get a confirmation within 3 blocks.

And further, 14 tx/s is about 10x the transaction volume we currently see, assuming those transactions make it (which they wouldn't).

But either way, I agree, even with some magnitudes cheaper costs, this seems expensive.

NB: what is your goal anyway? Disturb the network and delay legit transactions? I'd would feel more comfortable, if those experiments use rather low fees instead, so that regular transactions are mostly unaffected, or require only a small fee bump.

He wouldn't.
There are several categories in car racings: pilots, mechanics and spectators. Pilots do not repair broken cars. Spectators also.