worhiper_-_
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 08:24:41 AM |
|
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/BTCOptimal 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.
|
|
|
|
coinableS
Legendary
Offline
Activity: 1442
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 03:32:44 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 03:35:55 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 157
Merit: 103
Salí para ver
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 04:17:13 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 05:07:58 PM |
|
It's too hard to receive some free coins at here.
|
|
|
|
coinpr0n
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 05:48:50 PM |
|
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
Newbie
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 06:12:34 PM |
|
So the stress test is over and the honey badger of money didn't care! Well done! https://www.youtube.com/watch?v=4r7wHMg5YjgShould 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](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
Gyrsur
Legendary
Offline
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 06:23:47 PM |
|
this guy sounds a bit too gay. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
thebohemian
Newbie
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 06:49:06 PM |
|
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
Legendary
Offline
Activity: 1330
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 06: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.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 07:01:36 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.
|
|
|
|
Lucky7btc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 07:40:47 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"
|
|
|
|
thebohemian
Newbie
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 08:51:46 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://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? ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 09:05: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](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
thebohemian
Newbie
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 09:12:57 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](https://bitcointalk.org/Smileys/default/grin.gif) The it means all your giveaway BTCs are belong to us.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 09:32:54 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
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 10:21:25 PM |
|
... 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
Legendary
Offline
Activity: 1330
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 12, 2015, 10:23:50 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
|
|
|
|
basil00
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 60
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2015, 04:37:02 AM Last edit: September 13, 2015, 05:20:06 AM by 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.
|
|
|
|
|
|