Double spend against 0 conf transactions with acceptable fee

[The Bitcoin Institute]

Hello, I'm watching the double spend page at https://blockchain.info/double-spends

This transaction: https://blockchain.info/tx/5b48aa5968ac6abeab59bcb0affb3cbc457ac926fcb5da80a8d3a6ef444cfac4

1. As far as I can see, the transaction that funded the double spent inputs was done earlier tonight and was not included in a block until hours later.

2. The attacker then spent many of the inputs immediately after they got into a block with a 0.0001 fee. This fee was as far as I can see acceptable according to https://en.bitcoin.it/wiki/Transaction_fees . Spent coin age = 1, sizes of the double spend transactions all below 300 bytes resulting in 0.0001 fee in order to get relayed. Here, I see no reason why the transactions wouldn't be placed in the queue to be included in the next block on almost most mining pools out there.

3. Roughly 10 mins later he double spend some of the inputs, now with a 0.0005 fee. (If I'm not missing something)

For some reason he succeeded in this, and I can't see why. A transaction that is below 1000 bytes will never "require" a fee larger than 0.0001 in order to be relayed, right? So why wasn't these included in the next block instead of the ones made 10 minutes later? "Dishonest" miner?

[1538089917]

1538089917

[1538089917]

1538089917

[1538089917]

1538089917

[1538089917]

1538089917

[Foxpup]

1. As far as I can see, the transaction that funded the double spent inputs was done earlier tonight and was not included in a block until hours later.

It has insufficient fees. Given its size, it's a wonder it confirmed at all.

2. The attacker then spent many of the inputs immediately after they got into a block with a 0.0001 fee. This fee was as far as I can see acceptable according to https://en.bitcoin.it/wiki/Transaction_fees . Spent coin age = 1, sizes of the double spend transactions all below 300 bytes resulting in 0.0001 fee in order to get relayed. Here, I see no reason why the transactions wouldn't be placed in the queue to be included in the next block on almost most mining pools out there.

Those transactions have dust outputs, and are therefore non-standard.

3. Roughly 10 mins later he double spend some of the inputs, now with a 0.0005 fee. (If I'm not missing something)

True. These transactions also have the benefit of not being non-standard.

There's nothing unusual about this double-spend attempt. Note that a double-spend is only said to "succeed" if the party receiving it is defrauded by believing it to be valid (which isn't the case here, as the payout transactions are invalidated by the double-spends).

[The Bitcoin Institute]

1. As far as I can see, the transaction that funded the double spent inputs was done earlier tonight and was not included in a block until hours later.

It has insufficient fees. Given its size, it's a wonder it confirmed at all.

2. The attacker then spent many of the inputs immediately after they got into a block with a 0.0001 fee. This fee was as far as I can see acceptable according to https://en.bitcoin.it/wiki/Transaction_fees . Spent coin age = 1, sizes of the double spend transactions all below 300 bytes resulting in 0.0001 fee in order to get relayed. Here, I see no reason why the transactions wouldn't be placed in the queue to be included in the next block on almost most mining pools out there.

Those transactions have dust outputs, and are therefore non-standard.

Thanks, I guess this was what I was missing. The dust appears to be 5429 satoshis. So I guess the threshhold is just sums under accepted fees are considered dust? basically anything under 0.0001?

3. Roughly 10 mins later he double spend some of the inputs, now with a 0.0005 fee. (If I'm not missing something)

True. These transactions also have the benefit of not being non-standard.

You mean non-standard by including a higher fee than needed? of by it being very small? A way to increase priority perhaps?

There's nothing unusual about this double-spend attempt. Note that a double-spend is only said to "succeed" if the party receiving it is defrauded by believing it to be valid (which isn't the case here, as the payout transactions are invalidated by the double-spends).

He is in fact defrauding the game by double spending funds that was already spent on loosing wagers. so in effect he evaded the losing wagers by making them jump in before in the blockchain, and the bets he won he just received normally. He managed to get 30 losing bets of 0.25 so 0.25*30= 7.5 BTC "returned". He probably won a similar amount. so He got another ~7.5 BTC so tuble and go at it again...

[The Bitcoin Institute]

So I guess it all boils down to what is considered dust payments by the network. Is it 0.1 as this seems to be the delimiter to enforce a fee for relaying transactions? Or is sums less than the the min fee amount of 0.0001? The guy was using 0.00005429 BTC as dust change, and it worked.

[ondratra]

I have seen some mining pool aiming exactly on what you needed - they give extra fee(which you pay) to miners for "overriding" your transactions. Unfortunately I can't remember the pool's name right now - but I am sure it is announced somewhere in "Service Announcement" forum subsection.

[The Bitcoin Institute]

I have seen some mining pool aiming exactly on what you needed - they give extra fee(which you pay) to miners for "overriding" your transactions. Unfortunately I can't remember the pool's name right now - but I am sure it is announced somewhere in "Service Announcement" forum subsection.

Yes, but wouldn't that be like 0.5% of the hashing power, so it's very unlikely to happen?

[ondratra]

I have seen some mining pool aiming exactly on what you needed - they give extra fee(which you pay) to miners for "overriding" your transactions. Unfortunately I can't remember the pool's name right now - but I am sure it is announced somewhere in "Service Announcement" forum subsection.

Yes, but wouldn't that be like 0.5% of the hashing power, so it's very unlikely to happen?

They are pretty new pool so probably yes But I think it's the best you can get. Well not the best - you could try to "override" it by yourself by reusing some of inputs in transaction with high fee - that will be likely accepted before that old one with regular/no fee.

[jeffersonairplane]

I believe those transactions would have never gone through.

[ondratra]

I believe those transactions would have never gone through.

I am not sure what post you are reacting to, but there is always 1 transaction that will succeed and other's won't - because their inputs will not be valid after beign used in some previous transaction.