Pages:
Author

Topic: Defence against double spending, even 0-confirmation (Read 3058 times)

donator
Activity: 1218
Merit: 1079
Gerald Davis
Precisely because of the same logic etotheipi outlined escrow where both parties have monetary incentive  to complete transaction.

  • If Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.

Then there's your solution. The transaction must have some change the payer will lose if he double spends.


Payer would lose the change if tx was either destroyed or given to miner.
newbie
Activity: 36
Merit: 0
Precisely because of the same logic etotheipi outlined escrow where both parties have monetary incentive  to complete transaction.

  • If Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.

Then there's your solution. The transaction must have some change the payer will lose if he double spends.
sr. member
Activity: 269
Merit: 250
I would love to see secure solution for 0-confirmation transaction, but yours is not. People will do it just because they can or to screw a merchant, put yourself into the merchant position, there is no way he would tolerate that kind of risk to accept 0-confirmation transactions.

By your logic multi-sig escrow is also useless because all buyers will always screw over the merchant just ... because? despite having no financial gain (and lose of reputation) from the attack.


Precisely because of the same logic etotheipi outlined escrow where both parties have monetary incentive  to complete transaction.

  • If Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Yes, that's the current situation, but the whole thread is about trying to make 0-confirmation transactions safe even for high value irreversible exchanges.  There COULD be a demand for those if it was safe to do.

I'm just saying it doesn't work because it's still vulnerable to essentially the same attacks.

I don't recall anyone saying 0-confirm would be immune to all attacks.

It would make double spends even on 0-confirms less economical. 

I mean there isn't blank and white.  Either you can transfer $1B anonymously via 0-confirm or the incremental value is worthless.

Finney attack is just one method of a double spend and require significant resources to achieve.
hero member
Activity: 728
Merit: 500
165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
But as you indicated that attack ALREADY exists.  0-confirm irreversible tx which are anonymous and available on demand that also  have high enough value to make Finney attack worthwhile are essentially non-existent.

Yes, that's the current situation, but the whole thread is about trying to make 0-confirmation transactions safe even for high value irreversible exchanges.  There COULD be a demand for those if it was safe to do.

I'm just saying it doesn't work because it's still vulnerable to essentially the same attacks.
donator
Activity: 1218
Merit: 1079
Gerald Davis
I would love to see secure solution for 0-confirmation transaction, but yours is not. People will do it just because they can or to screw a merchant, put yourself into the merchant position, there is no way he would tolerate that kind of risk to accept 0-confirmation transactions.

Reputation matters and will always matter.

By your logic multi-sig escrow is also useless because all buyers will always screw over the merchant just ... because? despite having no financial gain (and lose of reputation) from the attack.

Generally speaking 0-confirm tx will be either low value, traceable, or reversible.

Say a porn site accepted 0-confirm tx.  You double spend they detect it immediately and cut off your access.  You lose full purchase price, merchant loses 1-10 minute of website access.  The same thing would apply for essentially any "service over time" (advertising, webhosting, VPN access, etc).

0-confirm will never be used to transfer $1B in bearer bonds via tor network.

sr. member
Activity: 269
Merit: 250

I think the proposal have a flaw, consider next scenario.

1. Transaction 1 is broadcasted
2. Merchant accepts Transaction 1 with 0-confirmations and release the purchase
3. Transaction 2, which is double spend of Transaction 1, is broadcasted
4. Miner gets all the coins from Transaction 1
5. Merchant eats the loss.

The customer doesn't get anything back by doing that. There's no incentive.


I would love to see secure solution for 0-confirmation transaction, but yours is not. People will perform the attack just because they can or to screw a merchant, put yourself into the merchant position, there is no way he would tolerate that kind of risk to accept 0-confirmation transactions.
donator
Activity: 1218
Merit: 1079
Gerald Davis
He can if he's also the miner: Purchase goods with zero confirmations; try to mine a double-spend; usually end up getting the goods for a fair price, but occasionally successfully solve the next block and get the entire forfeited amount back as fees.

This is also still open to Finney attacks: mine until he solves a block (including the conflicting transaction); purchase goods with zero confirmations; then release the block.  This succeeds unless someone else solves a block between making the payment and the delivery of goods.

But as you indicated that attack ALREADY exists.  0-confirm irreversible tx which are anonymous and available on demand that also  have high enough value to make Finney attack worthwhile are essentially non-existent. 

Hopefully in time the cost to have even 1% of network hashing power makes that even less of an academical risk.
hero member
Activity: 728
Merit: 500
165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
He can if he's also the miner: Purchase goods with zero confirmations; try to mine a double-spend; usually end up getting the goods for a fair price, but occasionally successfully solve the next block and get the entire forfeited amount back as fees.

This is also still open to Finney attacks: mine until he solves a block (including the conflicting transaction); purchase goods with zero confirmations; then release the block.  This succeeds unless someone else solves a block between making the payment and the delivery of goods.
newbie
Activity: 36
Merit: 0
"Double spend = same input, different outputs."

You would still need to reconsider the changed tx fee. That would require you to change the amount of the "change" adress, and/or add new inputs and/or outputs to the transaction (if the too-low-fee transaction also included inputs with too low value to be able to increase the fee) so the new fee add up correctly in equation.

Its hard to check in a safe way. I think a tx expiration feature would be better then.
We could allow the amount of only one output to change. The only thing they can do with that is change the fee, they can't take any money back.

I prefer a cleaner way to increase the fee that doesn't require messy double spending and can be done by either side: The recipient can spend the low fee txn with a larger fee so miners have to include both transactions to get the larger fee. The payer can also do that by spending the change.

Unfortunately, Theymos is right, tx expiration is not possible.

I think the proposal have a flaw, consider next scenario.

1. Transaction 1 is broadcasted
2. Merchant accepts Transaction 1 with 0-confirmations and release the purchase
3. Transaction 2, which is double spend of Transaction 1, is broadcasted
4. Miner gets all the coins from Transaction 1
5. Merchant eats the loss.
The customer doesn't get anything back by doing that. There's no incentive.

If you believe as some do that miners can be bribed with fees, then that's already possible. The customer could double spend it all to fee.

The double-spend-becomes-fee model is strictly superior to the fee bribe model. Under fee bribe, part of the payment can be taken back by increasing the fee.

Under this new model, any attempt to steal a payment back becomes proof the miner can use to take the whole amount. Under both models, they can give the entire amount to fee, but under this model, that's the only thing the double spender can do. He can't benefit from double spending.
sr. member
Activity: 269
Merit: 250
I think the proposal have a flaw, consider next scenario.

1. Transaction 1 is broadcasted
2. Merchant accepts Transaction 1 with 0-confirmations and release the purchase
3. Transaction 2, which is double spend of Transaction 1, is broadcasted
4. Miner gets all the coins from Transaction 1
5. Merchant eats the loss.
full member
Activity: 129
Merit: 119
"Double spend = same input, different outputs."

You would still need to reconsider the changed tx fee. That would require you to change the amount of the "change" adress, and/or add new inputs and/or outputs to the transaction (if the too-low-fee transaction also included inputs with too low value to be able to increase the fee) so the new fee add up correctly in equation.

Its hard to check in a safe way. I think a tx expiration feature would be better then.
newbie
Activity: 36
Merit: 0
I misread - I thought you wanted to include it as secondary inputs to the coinbase transaction. Still, the coinbase is limited to 100 bytes. It will be very hard to put two full transactions plus an extra output in there...
Ooooh, you're right.

The extension data would have to be shoehorned in somewhere else, like an extra 0BTC output on the coinbase to a deadend scriptPubKey that contains the extension data in a push-drop. I think that would be about 15 bytes overhead, and only when there's a double spend to kill.

It is possible for people create non-fraudulent double-spends.  A common case: if they forgot to include a sufficient fee and the transaction goes into limbo, they can resend it with a fee.  Under this proposal there's a small chance they could lose the entire balance if a miner who considers the no-fee transaction to be valid and then mines them both.  Evil miners could even hoard such transactions hoping for the opportunity to confiscate a large fee.
To preserve this option, don't consider it a double spend if it goes to the same outputs.

Double spend = same input, different outputs.
legendary
Activity: 1072
Merit: 1189
This is not correct. Old nodes will not accept a block whose coinbase has more than one, or non-empty inputs.
The scriptSig of a coinbase is a scratch area that is ignored that can be used for extension data.

I misread - I thought you wanted to include it as secondary inputs to the coinbase transaction. Still, the coinbase is limited to 100 bytes. It will be very hard to put two full transactions plus an extra output in there...
newbie
Activity: 36
Merit: 0
This is not correct. Old nodes will not accept a block whose coinbase has more than one, or non-empty inputs.
The scriptSig of a coinbase is a scratch area that is ignored that can be used for extension data.
legendary
Activity: 1072
Merit: 1189
Interesting but likely impossible to implement.  Old node (not just miners) would be incompatible.   So it would require a 100% upgrade of every single node on the network to avoid disruptions.
I edited the first post. Now it only needs 51% of miner support, and old clients don't need to upgrade. Blocks are fully backward compatible.

This is not correct. Old nodes will not accept a block whose coinbase has more than one, or non-empty inputs.
donator
Activity: 1218
Merit: 1079
Gerald Davis
You are assuming that the miner and the double-spender are not the same person. I send payment to a merchant; I make a double-spend transaction and keep it to myself; I try to mine a block (using my own or rented hashrate) with both transactions. If I'm not the first to find a block I end up paying normally, but if I am, I get to keep the sent amount.

That risk always exists. Thankfully the cost to have even 1% of the network is generally prohibitive as most 0-confirm tx would be low value or easily reversed.    Double spend fraud doesn't have to be 0% just lower than other payment systems.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Theymos said (and I'm sure he didn't make that up) that it is impossible to make transactions that are only valid if included up to block x, because this is not invariant to reorgs. A transaction can be included and the receiver thinks his payment is secure, then there is a reorg where this transaction doesn't appear, and it can't be added to a new block because it's too late.

Wouldn't the risk be the same as any other tx.

i.e. if hypothetically the default option in client was to create tx w/ a void "x" 30 blocks in the future.  Under most scenarios that tx would be included in the next block (b: 1).  If the merchant then waits 6 confirms (b: 7) by the time the kill or fill passes (b:30) it would require a 30 block re-org to void that tx.  If someone is doing a 30 block re-org we likely are facing a massive and well planned 51% attack anyways.

Right?

This is mostly academic because I am under no illusions that such drastic changes to protocol will ever happen.  However Bitcoin may not be the crypto-currency that goes mainstream so it may be useful to some "real" alt-chain (all alts so far w/ exception of namecoin as worthless as they haven't attempted any improvements on Bitcoin).
donator
Activity: 2058
Merit: 1054
You are assuming that the miner and the double-spender are not the same person. I send payment to a merchant; I make a double-spend transaction and keep it to myself; I try to mine a block (using my own or rented hashrate) with both transactions. If I'm not the first to find a block I end up paying normally, but if I am, I get to keep the sent amount.

This exploit can be used in conjunction with the Finney attack (waiting until I have a block before sending payment).

Even if the idea has merit, it is a fundamental change to the design principles of Bitcoin.

A potential solution for "limbo" tx in general is a kill or fill value.  If not included by block x, the tx is void.
Theymos said (and I'm sure he didn't make that up) that it is impossible to make transactions that are only valid if included up to block x, because this is not invariant to reorgs. A transaction can be included and the receiver thinks his payment is secure, then there is a reorg where this transaction doesn't appear, and it can't be added to a new block because it's too late.
donator
Activity: 1218
Merit: 1079
Gerald Davis
I edited the first post. Now it only needs 51% of miner support, and old clients don't need to upgrade. Blocks are fully backward compatible.

It still requires 100% of nodes to upgrade.  Existing nodes would see those outputs as valid.  Your modifications is less effective.  If either or both of tx have fees it would require miners to intentionally choose less fees as opposed to just including the tx with highers fees.

No miners is going to do that so the complexity and risk is for nothing.  Worse any miners that does (say both tx have no fees or they are a non-profit miner) will still leaving existing nodes vulnerable to deception from the "dead" outputs that the existing nodes don't see as dead.
Pages:
Jump to: