I do not think one can call a miner fraudulent if prefers a transaction with higher fee/kb above a lower variant. It is their freedom to mine whatever transactions they choose to.
The relay nodes are also free to relay or reject whatever they like. It is however beneficial to the network as a whole if relay nodes do not replace transactions with their double spend of a higher fee.
Nowadays relay nodes are quite homogenous and do not replace transactions, therefore unconfirmed double-spends are usually not making to the miner, this could however change. I guess merchants will feel the pain if so, and adapt.
Topic: When will nodes forward doublespends based on fee? - page 2. (Read 1426 times)
Ghash.io has been caught with their hand in the cookie jar. Other cloud mining operations that are coming online soon have the capability to do this with limited risk to themselves. A further 15% of the network is not identifiable and therefore would be able to do this with plausible deniability.
Thanks for the info. That is interesting. Do you know how I could pass a double-spend to Ghash.io or one of the unknown miners? I'd like to try to double-spend on myself, see how well it works, and report back.
Quote
"Knowingly fraudulent" is not a phrase I would use. There is no way for 3rd parties to know with certainty which transaction came first, and therefore which one is the fraud. It's the nature of the bitcoin consensus system.
There is an important subtlety. To perpetrate a double-spend, the nefarious miner must agree to not broadcast the fraudulent double spend (otherwise the merchant's listening node would detect the attack). If the transaction is legit, why not broadcast it publicly?
Similarly, if the miner receives the transaction long after the non-fraudulent transaction has been accepted by the majority of nodes in the network (and the merchant's node is no longer listening), then the miner would be knowingly complicit in the fraud if he accepts this clear double-spend into his memory pool.
So I think the phrase "knowingly fraudulent" is accurate. Do you still disagree?
It was double-spends / rerolls against BetCoin.
"ghash.io betcoin" in google should get you some results.
"ghash.io betcoin" in google should get you some results.
Ghash.io has been caught with their hand in the cookie jar.
Interesting. I had missed the news on this. I'd certainly be interested in reading up about it. Would you happen to have any links?
EDIT: do you know of any mining pools that control a significant fraction of global hash power that current accept out-of-band knowingly-fraudulent transactions?
Ghash.io has been caught with their hand in the cookie jar. Other cloud mining operations that are coming online soon have the capability to do this with limited risk to themselves. A further 15% of the network is not identifiable and therefore would be able to do this with plausible deniability.
"Knowingly fraudulent" is not a phrase I would use. There is no way for 3rd parties to know with certainty which transaction came first, and therefore which one is the fraud. It's the nature of the bitcoin consensus system.
Remember, the expected loss due to double spending on zero-confirm transactions is:
(% expected loss) = (% of people that will attempt to defraud you) x (% of global hash power controlled by fraudulent miners)
In a retail setting, I expect less than 5% of customers to attempt to defraud the merchant, and I expect less than 10% of global hash power to be nefarious. This gives an expected loss on zero-confirm transactions of less than 0.1 x 0.05 = 0.5%.
(% expected loss) = (% of people that will attempt to defraud you) x (% of global hash power controlled by fraudulent miners)
In a retail setting, I expect less than 5% of customers to attempt to defraud the merchant, and I expect less than 10% of global hash power to be nefarious. This gives an expected loss on zero-confirm transactions of less than 0.1 x 0.05 = 0.5%.
Give your customer a "loyalty card" if they provide some identifying information (so you can send them sales building promotions), and only accept bitcoin payments from members with a "loyalty card", and I'll bet you reduce that to below 0.1%
Zero-confirm transactions are safe1 for low-value purchases provided the transacation has been accepted by a significant fraction of network nodes and no double spends have been detected.
No, zero-confirm transactions should not be considered safe to any degree, because...
Quote
To attempt a double-spend, you'd need to be in cahoots with a nefarious miner and pass your fraudulent transaction over a non-public back channel. You'd only succeed with a probability equal to the nefarious miner's percentage of global hash power.
... this is ridiculously easy to do.
This has been debated endlessly. It comes down to whether the expected losses from double spends are significant to the merchant's bottom line.
Purchasing a latté from Starbucks is almost certainly fine, while purchasing 100 oz of gold will definitely require a few confirmations. Purchasing $300 of groceries (low profit margin business), well, we'll have to see how the double spend statistics look.
Remember, the expected loss due to double spending on zero-confirm transactions is:
(% expected loss) = (% of people that will attempt to defraud you) x (% of global hash power controlled by fraudulent miners)
In a retail setting, I expect less than 5% of customers to attempt to defraud the merchant, and I expect less than 10% of global hash power to be nefarious. This gives an expected loss on zero-confirm transactions of less than 0.1 x 0.05 = 0.5%.
EDIT: do you know of any mining pools that control a significant fraction of global hash power that current accept out-of-band knowingly-fraudulent transactions?
Zero-confirm transactions are safe1 for low-value purchases provided the transacation has been accepted by a significant fraction of network nodes and no double spends have been detected.
No, zero-confirm transactions should not be considered safe to any degree, because...
Quote
To attempt a double-spend, you'd need to be in cahoots with a nefarious miner and pass your fraudulent transaction over a non-public back channel. You'd only succeed with a probability equal to the nefarious miner's percentage of global hash power.
... this is ridiculously easy to do.
Simply knocking out unconfirmed tx from memory pool by another higher fee variant would enable the payor to cancel any payment before included in a block - by double spending to own account. This is a no-go.
The thing about Bitcoin is that you can't rely on good behavior in the nodes. Just like there were griefers who set up tx mutation nodes for the hell of it, there could be nodes that are programmed to make double spending of 0 conf transactions easier.Merchants need a better solution than "hope adversaries decide to play nice".
Maybe something along the lines of pools offering subscription services via which a merchant can obtain assurance the pool will not mine a conflicting transaction.
Zero-confirm transactions are safe1 for low-value purchases provided the transacation has been accepted by a significant fraction of network nodes and no double spends have been detected.
To attempt a double-spend, you'd need to be in cahoots with a nefarious miner and pass your fraudulent transaction over a non-public back channel. You'd only succeed with a probability equal to the nefarious miner's percentage of global hash power.
Why would you want to intentionally make zero-confirm transaction less secure?
1Ignoring the malleability nuance related to accepting zero-confirm transactions built from unconfirmed change outputs that is being resolved.
To attempt a double-spend, you'd need to be in cahoots with a nefarious miner and pass your fraudulent transaction over a non-public back channel. You'd only succeed with a probability equal to the nefarious miner's percentage of global hash power.
Why would you want to intentionally make zero-confirm transaction less secure?
1Ignoring the malleability nuance related to accepting zero-confirm transactions built from unconfirmed change outputs that is being resolved.
Simply knocking out unconfirmed tx from memory pool by another higher fee variant would enable the payor to cancel any payment before included in a block - by double spending to own account. This is a no-go.
I also think that block inclusion would better be simple fee/size order and that memory pool should expire somewhat faster than current 3 days.
I also think that block inclusion would better be simple fee/size order and that memory pool should expire somewhat faster than current 3 days.
We need to move away from the mindset that zero confirmation transactions are safe.
Miners will eventually start to prioritize what to include by the fee it gives them, which is exactly what they should be doing. Even if that were to nullify another unconfirmed transaction, the one which gives the most to the network (miners) is the one that should be included.
Miners will eventually start to prioritize what to include by the fee it gives them, which is exactly what they should be doing. Even if that were to nullify another unconfirmed transaction, the one which gives the most to the network (miners) is the one that should be included.
Jump to: