Topic: This guy spams the blockchain by sending 500BTC back and forth (Read 5121 times)

Is this legit? He's mining his own bitcoins?

al about lol whats the big deal about any of this?

This is the classical gambler's ruin problem. He must lose everything eventually

Serves them right, I think we've had enough of them.

And the pathological gambler stopped spamming since he lost 

Gambling at its best

I'm not sure, but that really made my day seeing him flush away 23K USD

hahahha I love that.  I cant imagine how anyone would play with 200 btc at sdice...

He finally lost it all.

https://blockchain.info/address/15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888

The transaction that did him in? Satoshi Dice for 200BTC on 48%

https://blockchain.info/tx/9870e3fa87cb2f74ff3eb6af2364e26a9a0c2c94d90465066ef68901f39a0b92

Makes me lulz a litttle.

Well of course he's not playing with 500btc,
he's emptying his wallet to prevent his smaller SD transaction going thru,
however in the event he mines he will get the win from sd and also his btc back.

oh look his balance:
https://blockchain.info/zh-cn/charts/balance?address=15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888
sometimes he has over 800btc others -500 ...

looks like if he has more than 2% hashing power he could win to satoshi dice more times than lose.
if not, even if successful he will lose in the long run.
but he cannot trick bitcoin, bitcoin will always choose the longer branch.
that's why it's so dangerous to implement that add fee change transaction pach!
https://bitcointalksearch.org/topic/initial-replace-by-fee-implementation-is-now-available-on-testnet-199947

what it looks like whats happening, he's increasing his chance of solving a block.  Any miner that requires a tx's in the block won't get to solve his blocks, thus lowering his difficulty.

This has illustrated an issue however.

When the transactions are being added to the block. Each time one is added, it's dependants are added to the queue. When we've exhausted all the transactions which link directly off the main chain, we're left with these dependant transactions which always have zero priority. If they also have zero fee, then the ordering fails to choose one over another.

Thus the ordering of the priority queue ends up being determined by the order that the transactions were added to it.

When Mr 8's 500BTC transaction is added to the block, it has a very high priority, meaning that it's added early and its dependants are added to the queue first. Once the priority>0 transactions are all added, his next transaction is at the front of the queue. This again puts the next one in the queue early. It wouldn't even matter if the other transactions were of low value and huge. They'd be first in the queue. You could use this to fill the entire block with one transaction with zero fee, simply by making it depend on a high priority transaction (which also has zero fee).


One solution is to amend the ordering. It currently only depends on the priority value and the fee/kB, so it fails to distinguish when they are both equal, falling back to insertion order. If the third element (the tx pointer) of the TxPriority object was used for comparison too, then the zero fee, zero priority transactions would be ordered by where they are in RAM - which is at least not predictable. This does have the downside (?) that it is no longer deterministic. To do that you'd want to order by hash - but that could get expensive.


EDIT: thinking a bit more, ordering by pointer doesn't really work either because the allocation strategy in std::map is (I'm guessing) likely to be to allocate a chunk of memory enough for multiple elements, so the chain of transactions coming in one after another will end up in a chunk of contiguous memory, and we end up falling back to insertion order again.

Ok, I think I solved the mystery.

Firstly, BTC Guild are almost certainly running 2 bitcoind instances, one of which has 'blockprioritysize' set to maximum, meaning that fee/kB is essentially ignored.

Secondly, a few blocks before (234941) was solved by BTC Guild, only a few seconds after the previous block. Because of the short time period, there were very few transactions left in the memory pool which linked directly off the main chain. Instead it was filled with very low priority transactions and chains of transactions (zero priority). This block cleared out most of the low priority transactions, thus all that was left was this guy's chain.

Fast forward a few blocks and BTC Guild solved another block (234946), and again in only a few seconds. This time there were no low priority transactions left, only zero priority transaction chains. So that is what got included in the block.

blockchain.info is even worse than that actually - I've seen them display the coinbase in the middle of a block.

Feel free to look into the possible bug I found and make up a patch if I'm right - I'm happy to be scooped. That said, it's a rare enough issue that fixing it won't be something they'll rush; it should get at least a month or two of testing if not more.

Ah sorry, I didn't look hard enough. Back to the drawing board I guess.

I also just realized that blockchain.info displays the transactions in a block from last to first (except the coinbase tx). Confused the hell out of me trying to follow the chain and seeing inputs from transactions which seemingly didn't exist yet.

You're not looking at the transactions I am.

The end of the chain I'm talking about is a20d26236c45724677fe3f8de380450994342f3107301be67669d700c0fc2d22 which were all included in block 000000000000016779d88a16b6d71ebd53ddf860f466f1f3d906b43a45f50865; note how the last transaction in the chain has no fee, so it's not a child-pays-parent issue either. (well, possibly it's due to buggy child-pays-parent code, but the owner of BTC Guild has said they're running stock bitcoind)

These transactions aren't in the same block. The chain of transactions was broadcast at the same time, but each transaction appeared in consecutive blocks.

The first transaction which links off a confirmed transaction has high priority so gets into the block, and the rest of the chain has zero priority, so doesn't get into the block.



The priority is calculated before the transactions are selected to go into the block. The view is NOT updated while this is happening - in fact, the view is not of the memory pool at all, it is of the previous block. For any chain of transactions in the memory pool, only the first (the one linking off the blockchain) has its nConf calculated.

Is he trying to Finney attack SD?

Somebody described this before:

1. Mine his own block, with his 500BTC sending to himself. He may have a farm of Avalon ---- not surprising, he is a Chinese

2. Using the same 500BTC to make a long chain of transaction and finally send to SD

3. If he wins, let it go

4. If he loses, broadcast the block

(seems not entirely correct since some of his bets are smaller than 25BTC, any idea?)

Seems he's doing around 300 Tx a day since May 4 and also really likes SatoshiDice 48%

I think what's happening is the value is so large that it can reach the priority required for a free transaction in a single block, and due to a bug, that happens multiple times as the block is created.

CTransaction::AllowFree returns true if dPriority > COIN * 144 / 250, and dPriority is calculated as nValueIn * nConf / nTxSize.

So 500BTC * 1conf / 225bytes = 2.2 > 144 / 250 = 0.576; note how you could pull thus stunt with just 95.616BTC using the minimum possible (safe) transaction size of 166bytes.

The problem is how the number of confirmations is calculated: in CreateNewBlock() we have:


Now coins comes from view.GetCoins(txin.prevout.hash, coins). The thing is the coin view is updated as transactions are added to the block - see viewTemp.Flush(); later in the function - which means it looks like the transaction already has one confirmation even though that "confirmation" comes from the block being created right now!

The easiest solution would be to change The nConf calculation to remove the + 1:


...but that's gonna need testing.