CoinWallet.eu Stress Test Cancelled + Bitcoin Giveaway - page 7.

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: basil00 on September 13, 2015, 02:24:48 AM

What exactly is the K-value required (kinv for ECDSA_sign_ex)?

Code:

static const MyKey32 k ( QByteArray::fromHex ( "7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0" ));

BN_bin2bn ( k.constPtr ( ), 32, bn_kinv );              // convert bytearray to openSSL bignumber object
EC_POINT_mul ( group, tmp_point, bn_kinv, 0, 0, ctx );
EC_POINT_get_affine_coordinates_GFp ( group, tmp_point, bn_x, 0, ctx );

BN_nnmod ( retr, bn_x, bn_order, ctx );                 // retr is R-part of signature
BN_mod_inverse ( bn_kinv, bn_kinv, bn_order, ctx );     // todo: seems to me that this should be performed once!
BN_mod_mul ( tmp, ecprivkey, retr, bn_order, ctx );     // ecprivkey is my privkey as openSSL bignumber object
BN_mod_add_quick ( rets, tmp, BN_bin2bn ( dgst.constPtr ( ), 32, m ), bn_order ); 
BN_mod_mul ( rets, rets, bn_kinv, bn_order, ctx );      // rets is S-part of signature

// now encode pair of  to DER

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

This message was too old and has been purged

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: basil00 on September 13, 2015, 02:24:48 AM

I tried but no luck so far, still get big sigs. What exactly is the K-value required (kinv for ECDSA_sign_ex)?

My code is very dirty and I do not understand it myself

Code:

static BIGNUM* bn_kinv = BN_new ( );
...
static const MyKey32 k ( QByteArray::fromHex ( "7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0" ));
BN_bin2bn ( k.constPtr ( ), 32, bn_kinv );
...
EC_POINT_mul ( group, tmp_point, bn_kinv, 0, 0, ctx );
EC_POINT_get_affine_coordinates_GFp ( group, tmp_point, bn_x, 0, ctx );
...

Quote from: basil00 on September 13, 2015, 02:24:48 AM

Does it depend on the priv key?

no

basil00

member

Activity: 60

Merit: 10

Quote

@basil00, you can use predefined 'k' for signing ECDSA. This saves some space in blockchain.

I tried but no luck so far, still get big sigs. What exactly is the K-value required (kinv for ECDSA_sign_ex)? Does it depend on the priv key?

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: basil00 on September 13, 2015, 01:15:20 AM

Note that if the replacement transaction is bigger the miner may prefer the original anyway (better fee rate).

You can vary the number of inputs of your tx.
Take several inputs from one tx and several from another, and doublespend two transactions! Grin

In fact miners do not use replace-by-fee today.

basil00

member

Activity: 60

Merit: 10

Quote

@basil00, you can use predefined 'k' for signing ECDSA. This saves some space in blockchain.

Thanks for the tip -- was not aware of this. I have to figure out how do this with cbitcoin though.

Note that if the replacement transaction is bigger the miner may prefer the original anyway (better fee rate).

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: basil00 on September 13, 2015, 12:37:02 AM

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 Grin

@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://bitcointalksearch.org/topic/the-most-repeated-r-value-on-the-blockchain-1118704

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

basil00

member

Activity: 60

Merit: 10

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.

rz20

legendary

Activity: 1330

Merit: 1001

Quote from: thebohemian on September 12, 2015, 06:21:25 PM

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

thebohemian

newbie

Activity: 13

Merit: 0

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

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: thebohemian on September 12, 2015, 05:12:57 PM

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

newbie

Activity: 13

Merit: 0

Quote from: amaclin on September 12, 2015, 05:05:46 PM

Quote from: thebohemian on September 12, 2015, 04:51:46 PM

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? Grin

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

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: thebohemian on September 12, 2015, 04:51:46 PM

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? Grin

thebohemian

newbie

Activity: 13

Merit: 0

Quote from: rz20 on September 12, 2015, 02:56:57 PM

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://bitcointalksearch.org/user/coinwalleteu-553487 . 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? Cheesy

Lucky7btc

hero member

Activity: 1299

Merit: 502

Quote from: rz20 on September 12, 2015, 02:56:57 PM

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"

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: thebohemian on September 12, 2015, 02:49:06 PM

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.

rz20

legendary

Activity: 1330

Merit: 1001

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

thebohemian

newbie

Activity: 13

Merit: 0

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.

Gyrsur

legendary

Activity: 2856

Merit: 1518

Bitcoin Legal Tender Countries: 2 of 206

Quote from: thebohemian on September 12, 2015, 02:12:34 PM

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

this guy sounds a bit too gay. Grin

thebohemian

newbie

Activity: 13

Merit: 0

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

Topic: CoinWallet.eu Stress Test Cancelled + Bitcoin Giveaway - page 7. (Read 98836 times)