CoinWallet.eu Stress Test Cancelled + Bitcoin Giveaway

[worhiper_-_]

That's really a bad time to test those 'smart fees'. The stress test was very successful at increasing the optimal/Kb fee for giving transactions a high priority.

https://www.blocktrail.com/BTC

Optimal Fee / Kb
0.00112178 BTC

And the mempool's size won't go down as well. Maybe this giveaway was just a scapegoat for coinwallet to take the stress test upon themselves.

[1715596778]

1715596778

[1715596778]

1715596778

[1715596778]

1715596778

[1715596778]

1715596778

[coinableS]

Seems to me that the stress test, also known as Bitcoin Giveaway, has failed to harm the Bitcoin transactions in any way.

While Mem pool is quite large and tx back-log has also grown, it seems that the only back-log are the spam transactions them self.

Real transactions are going through as usual

I only made one transaction today. It is unconfirmed after 8 hours.

I sent it using "bitcoin-cli sendtoaddress ...", let bitcoin core select its own fee - I think it's meant to use "smart fees" now - and it decided to use a fee of 300 satoshis. FFS.

The legendary doog even tried!
I think these dust addresses and keys will float around with a balance for a while. It's just not worth the effort to write out a 5 input raw transaction in core just to receive 0.00002 after the 0.00003 in fees. And it's too much work to write out a 100 input raw tx let alone these are filled with 3,000+ inputs.

[Gyrsur]

Seems to me that the stress test, also known as Bitcoin Giveaway, has failed to harm the Bitcoin transactions in any way.

While Mem pool is quite large and tx back-log has also grown, it seems that the only back-log are the spam transactions them self.

Real transactions are going through as usual

I only made one transaction today. It is unconfirmed after 8 hours.

I sent it using "bitcoin-cli sendtoaddress ...", let bitcoin core select its own fee - I think it's meant to use "smart fees" now - and it decided to use a fee of 300 satoshis. FFS.

have my full node online in some days and will also try this out.

in the meantime!

[Delek]

I added 4 more GB to my Node yesterday (memory poll is 1.5GB right now). I will resist every second of this stress test, my node will crash over my dead body.

[vodanh]

It's too hard to receive some free coins at here.

[coinpr0n]

I added 4 more GB to my Node yesterday (memory poll is 1.5GB right now). I will resist every second of this stress test, my node will crash over my dead body.

1.5GB? It's that bad? I don't have my node running right now but on tradeblock it's only showing 31MB mempool.

[thebohemian]

So the stress test is over and the honey badger of money didn't care!

Well done!

https://www.youtube.com/watch?v=4r7wHMg5Yjg

Should we thank coinwallet for having shown the world that the bitcoin network flawlessly handled this attack? ;-)

Now back to the normal proceeding aka to the moon.

[Gyrsur]

https://www.youtube.com/watch?v=4r7wHMg5Yjg

this guy sounds a bit too gay. 

[thebohemian]

I still have one technical question: Some miners started to put the UTXOs from the giveaway into their blocks as 0.0 BTCs transactions. This effectively means the giveaways's BTCs go straight to the miner.

This then means that any pending unconfirmed transaction which mentions the same UTXOs becomes invalid and should be thrown out of the mempool. How is this actually happening? Does each node check all the unconfirmed transactions after a new block is accepted in the chain?

As the private keys are public and as such the UTXOs known. Each node could already proactively throw out those transactions cause miners would always decide in their own favor when confronted with the question: "Should I put this spam transaction into the block so that it benefits someone else or should I direct the coins to my self instead?". Doing so would bring back the mempool size back to normal quickly.

Btw: The people who imported the keys into their normal wallets might be in trouble if the wallet software decides to place incoming BTCs to an address from the giveaway.

[rz20]

Did any transaction confirmed because I didn't receive anything yet and I did it when the op posted the private keys.

[amaclin]

Does each node check all the unconfirmed transactions after a new block is accepted in the chain?

Each node just discards the transactions in mempool which conflict with the transactions in block.
A special case of confilcting transaction is the same tx.

[Lucky7btc]

Did any transaction confirmed because I didn't receive anything yet and I did it when the op posted the private keys.

Nope...As the saying goes "Nothing is for free"

[thebohemian]

Did any transaction confirmed because I didn't receive anything yet and I did it when the op posted the private keys.

Any miner who sees your transaction is confronted with this question: "Should I put this spam transaction into the block so that it benefits someone else or should I direct the coins to my self instead?"

So what would you do if you were a miner?

Scraping the private keys from this thread is dead easy (especially if you use this handy URL: https://bitcointalk.org/index.php?action=profile;u=553487;sa=showPosts . Creating the public keys is part of EC-key math magic and then you can look up the UTXOs. So every miner who has a spare minute can simply write a script that modifies the next best incoming spam transaction, set the output value to zero (incoming value turns into a mining fee) and "bye bye".

Disclaimer: I earned 0.11 mBTC (yes, milli-BTC) from two transactions that happened at the beginning of this stress test and that got confirmed. Participating in this folly made me better understand how all this stuff works. I used bitcoinj which I never touched before. Anyone in need of an IT freelancer with bitcoinj knowledge?

[amaclin]

So every miner who has a spare minute can simply write a script that modifies the next best incoming spam transaction, set the output value to zero (incoming value turns into a mining fee) and "bye bye".

What if all miners implement this patch? 

[thebohemian]

So every miner who has a spare minute can simply write a script that modifies the next best incoming spam transaction, set the output value to zero (incoming value turns into a mining fee) and "bye bye".

What if all miners implement this patch?  

The it means all your giveaway BTCs are belong to us.

[amaclin]

The it means all your giveaway BTCs are belong to us.

Yes, I understand. This is not my giveaway.
I am asking - how much time miners would work only for themselves? A day? A week?

[thebohemian]

... if I were a miner I would just continue filling up the blocks I mine until all UTXOs are spent (by myself or anyone else).

[rz20]

... if I were a miner I would just fill up my blocks until all UTXOs are spent (by myself or anyone else).

If they do this we can expect spam blocks of 1mb with just 0.50 on it, I think it is not worth.

0.005 is 100kb
0.50 is 1mb

[basil00]

I thought this was an interesting experiment, so I tried it: double-spending the 0-conf coinwallet "sweeper" spam. Below is a quick write-up:

You can see the results here:

http://coinsecrets.org/

Each transaction marked "DS", "XX", "XY", "XW", or "R" is a successful double spend. Here are some recent samples: 1, 2, 3, etc. These double spent some transactions that are days old.

Method:

• Intercept a sweeper tx (using a pseudonode).
• Replace the original output with an OP_RETURN with value 0.
• Resign with the coinwallet private keys (used libcbitcoin for this).
• Broadcast the new tx, discard the old tx.

The original sweeper transaction has done most of the hard work for me. I merely modify the output(s). This is possible because the private keys are publicly known.

By using OP_RETURN, I am sending 100% of the coinwallet "giveaway" coins to miner as fees (I'm not getting a single red satoshi out from this). My motivation is:

• Unlike the original, the OP_RETURN does not create a new UTXO, bloating the UTXO set, and needing to be redeemed later (i.e. yet more spam).
  My replacement transactions are smaller, have a higher priority, and have a higher fee. So RBF miners should prefer the replacement over the original transactions.
• My transactions merely replace the original, and therefore do not increase node mempool usage.
• Note that most of the transactions that are been double spent were generated days ago.

Results & Analysis:

Success! In principle this kind of double spending should be difficult for two reasons: (1) the network should not propagate the double spends, and (2) miners should ignore the double spends. However, it seems this method is very effective:

• The transactions seem to propagate OK. I guess it is because of the number of XT nodes that propagate double spends by design?
• It seems like some big miners, e.g. AntPool, BitFury, GHash.IO, 21 Inc., Slush, will happily mine the new transactions with the higher fee. I guess they are implementing some form of /u/petertodd 's RBF patch?

I think however the miner's themselves should get organised to sweep the transactions directly. This will help discourage a flood of transactions being generated for this kind of event. I think F2Pool has done this to some extent.

[amaclin]

I thought this was an interesting experiment, so I tried it:
double-spending the 0-conf coinwallet "sweeper" spam.
Below is a quick write-up:

@elmad, this is an answer how to create the transaction without retrieving utxo from the blockchain  

@basil00, you can use predefined 'k' for signing ECDSA. This saves some space in blockchain.
For example:
https://blockchain.info/tx/22af08a3eb8cf66d118d31af55bbc0862351d34734df03ddfa4ac1e1a9c2eec5
12 inputs, one output to OP_RETURN ----------- 1800 bytes

https://blockchain.info/tx/4d06062bb025886f4d8c2436aecfc4935d7f920b5e610592dc43e4026653912e
12 inputs, one output to p2pk ----------- 1686 bytes

And it would be better to use SIGHASH_NONE | SIGHASH_ANYONECANPAY instead of SIGHASH_SINGLE

See also
https://bitcointalk.org/index.php?topic=1118704

UPD:
And it would be better to use SIGHASH_NONE | SIGHASH_ANYONECANPAY instead of SIGHASH_ALL