Bitcoin Forum

So far it has been "safe enough" to accept zero confirmation transactions for in person deals or deals for low value digital media.

In the near future this might change with new mining protocols stratum (http://mining.bitcoin.cz/stratum-mining) and getblocktemplate (https://en.bitcoin.it/wiki/Getblocktemplate) gaining more and more ground as they are necessary for efficient ASIC mining. These protocols give control about which transactions to include in a block back to the miners (in contrast to pool operators as in the old getwork protocol).

The Bitcoin network does and has always allowed replacement of zero confirmation transactions within a miners system. This means a miner can and always could replace a zero confirmation transaction by another one. If the newer tx has a much higher fee he has a high incentive to do so. With the relatively centralized getwork protocol the power to do so rested mostly with the pool operators. With the new protocols it will not be possible to point a finger at anybody systematically doing double spending transaction replacements. I expect a high percentage of miners to do it as long as it is profitable.

Work in this direction:
https://bitcointalk.org/index.php?topic=179612 Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch

I can see Bitcoin clients coming up that systematically try to double spend every single transaction they make. Pay your drink, walk outside, click the double spend button, profit.

IMHO it would be nice if zero confirmation transactions were still "safe enough" in 2015.

edit: improved solution further below (https://bitcointalk.org/index.php?topic=208167.msg2246118#msg2246118)

There has been a suggestion by unabridged quite a while ago that I think would be a relatively simple yet effective solution:
https://bitcointalk.org/index.php?topic=54746 Penalizing double spends

Basically it goes like this:
If a miner can come up with the same unspent previous output used twice he can claim this previous output as an additional transaction fee ("double spending fee" if you like).
Transactions that only changed the transaction fee must be excluded.
It might be beneficial to give half of the "double spending fee" to the miner of the previous or next block so that the penalty works for the miner himself, too.


There are other ways, but this seems like a good approach. It does not help against the Finney attack but it is a huge improvement. If a merchant listens for 10 secs before accepting a tx he should be relatively safe with this change.


Unfortunately this means a hard fork. Do you think this is realistic? Should this be made a BIP?



Background info: https://en.bitcoin.it/wiki/Double-spending

The problem is that how miners include tx in blocks is not part of the "protocol." What I mean by that is, if these rules were put into place, there is nothing stopping someone from modifying your rules. Whereas if someone modified part of the protocol, such as max block size, other nodes would notice. Nodes would not be able to check how a miner includes tx in a block.

There are no "local" rules like you imply.

I suggested something similar (way later) here: https://bitcointalk.org/index.php?topic=196136

In fact, I think a reasonable solution could be implemented by adding a *single* instruction to the script language: suppose you have "OP_CHECKSIG_VAL val sig pub_key" which checks if sig is a valid signature of val under pub_key. Then you can create e.g. two transactions as follows:

• TX1: Take 1 BTC from TX0out, give 0.2 BTC to Addr1, 0.8 BTC to Addr2
• TX2: If you find a double spend of TX0out, give 0.2 from TX3Out to Addr1 and a fee of 10BTC to the miner

The buyer gives both transactions to a vendor who owns Addr1 who additionally checks that TX3Out really has 10.2 bitcoins and is still open. If at some point the vendor gets a double spend he can plug in the values into TX2 so that it becomes valid. Miners will be happy to mine a transaction with a 10BTC fee.

The suggestion in https://bitcointalk.org/index.php?topic=196136 is somewhat nicer because it increases the chance the vendor gets his money, but more complicated.

Interesting, but as you say it is more complicated. I like to keep things as simple as possible. Also I doubt it will always be possible to determine the vendor. Without an incentive of getting back their double spent coin only very few people will attempt it so it is not necessary to pay the vendor.

How will you enforce miners to follow the double-spend-replace rule? What if say a miner advertises himself as a double-spend specialist, to which people send their tx in hopes that said miner gets the next block?

How will other nodes know that a miner is rightfully claiming a double-spent tx as fees? You would need to prove to other nodes that there are two signed transactions with the same prevout.

Also, if the double-spend tx goes to the miner, the recipient still has no funds. This allows extortion, where someone pays a seller, then says "I will double spend unless you do x" If the seller refuses, the buyer sends the double-spend and miners take the tx as fees. Zero-conf are still unsafe then, unless you use green addresses which work under the current rules and replace-by-fee.

Bitcoin is a consensus-building network.  There cannot be a reliable zero-confirmation system using the Bitcoin network alone, because it can't build consensus that quickly.  The whole point of it is that your confidence in the transaction can grow exponentially as a function of work done (#confirmations), but if it has zero work then there is no confidence in it.  At the end of the day, it's that simple -- you can't be confident until your transaction is buried in proof-of-work, which means it must have confirmations. 

That's not to say that there will never be hope for zero-confirmation transactions:  it just means that they will never be (and never were) suitable for zero-trust exchanges without external services.  There are some cool things you can do with locktime and alternate sighash codes, but they all build off already-confirmed transactions -- they require seeding a contract with an already-confirmed tx!   Third-parties may provide mechanisms to help people transaction instantly, and they may take a fee for it.  But you won't get there with the network rules alone.

We need to get away from this wishful thinking that we can somehow adapt this proof-of-work system to work with transactions that have no proof-of-work.  There's still use for them, just not zero-trust transactions (i.e. if my coworker sends me money to cover the lunch tab, I can be confident with the zero-conf, because I can go to his cubicle and punch him later if he double spends, etc -- this is not a zero-trust situation.).   

Now I get what you mean. Of course it is not a rule but an option. What you are saying is that in the long run it might still be more profitable for a miner to mine double spends building reputation. Damn it. This is a very good hint I need to think about some more.
With this change you would have to trust the ds-miner with your coins, though. Also he would need to somehow advertise his IP address or other means of secure communication.

Yes, both double spent tx would always have to be included.

Yup, but it is much better than now.

I don't think miners will be doing this regularly, for a whole bunch of reasons. It isn't the best way to maximise profit - the value of Bitcoin will be much higher in the long run if it's usable for day to day casual transactions. But regardless, if you look at stratum it doesn't actually let miners control what's in the block. Nor does GBT, as far as I know, it just allows auditing.

The whole reason the block chain exists is to prevent double spends.
If anyone finds  a "safe" way to accept 0-conf transactions, without sacrificing any other major features of bitcoin (pseudonimity, decentralisation), this would render bitcoin obsolete - just through away all the blocks in favour of one big pool of unconfirmed transactions.

If you are willing to forgo some of the advantages of bitcoin in order to accept 0-conf, then it becomes easy, for example:

- no pseudonimity: ask a customer to show his ID. If he doublespends, report to police.
- no decentralization: use "green" (trusted) addresses. This is already implemented on some exchanges, and works.

I don't see how why my proposed solution above doesn't work, and also why it should render the blockchain obsolete.

Maybe I wasn't clear enough; let me try again.

Say I am a customer, and want to buy a product from V for 0.1 BTC, double spend safe. I need to have *two* confirmed transaction for this purpose. Say I know the private keys for TX0out, which has 1 BTC, and for TX1out which has 3 BTC out. Both are deep in the block chain.

I will give a usual transaction to V which pays him 0.1 BTC, giving me 0.9 BTC change. But additionally I give him a transaction which says: "If you find two valid signatures for TX0out, this transaction gives the miner 2 BTC from TX1out, and 0.1 BTC to V".

Anyone care to explain to me why this would not work?

Because after you give the transactions to V you publish further transactions transferring all coins from TX0out and TX1out to another address you own... ?

You can try that. But you risk losing 2 BTC to a miner who mines greedily, for a gain of just 0.1 BTC.

Explain your idea of this 10 BTC fee to the miner. Because Bitcoin is decentralized, you can't forceably withdraw Bitcoin from anybody. If you are suggesting a blacklist propagated by the miners themselves that would force withdraw Bitcoin from every transaction they would send then maybe that would prevent fraud.

The idea is as follows: to pay 1 BTC to V, you need to have an additional 10 BTC on a second address (like a deposit).

You then give V a normal transaction T1, and a second transaction T2. In case T1 is a double spend, V can use T2 to make 10 BTC go to the miner.

In the example you quoted, TX3Out needs to have at least 10.2 BTC in them (which are also owned by the person who wants to pay V).

Does that make the idea clear?

Can you describe the scenario with both Tx laid out? Like:

Tx1:
Inputs
 - [PrevOut1] 10.2 BTC
Outputs
 - [MerchantAddr] 0.2 BTC
 - [ChangeAddr] 10 BTC

Tx2:
etc

OK, I'll try.

Buyer B wants to buy an item with value 0.1 BTC from Merchant M. B has 20.4 BTC in total. These are stored in two transactions outputs B0, B1, both of the buyer.

B0: Transaction Output with 0.4 BTC, private key known to B
B1: Transaction Output with 20 BTC, private key known to B

Now, to buy the item, the buyer sends two transactions Tx2 and Tx3 to the merchant.  The merchant has address <addrM>

Tx2:
  Input B0
  Outputs
    1: 0.1 BTC to <addrM>
    2: 0.3 BTC to <addrB> (another address of B)

Tx3:
  Input B1
  Outputs:
    1: 0.1 BTC to <addrM>
    2: 9.9 BTC to <addrB>
       *only valid with two spends of B0*
 
the transaction Tx3 is special (this would need an extension of the scripting language). In order to use it, one needs to provide two *different* spendings of B0.

The merchant M gets both these transactions, waits 10 seconds, and then gives the item to B. If later another transaction of B0 shows up before transaction Tx2 is in a block, he can broadcast Tx3; and it will be worthwile for a miner to use it (note that it has 10BTC fee included).

It still might be possible to find a solution that is good enough for a lot of purposes. Anyway it is fun to think about it.

A lot of people are very short sighted. Also it might pay quite well.

from http://mining.bitcoin.cz/stratum-mining:

"safe" != "safe enough"

Together with the double spend the bad guy also spends the deposit. Not sure if you are aware that it is possible to communicate directly to the miner and the miner does not have to relay the TXs to others ("double spend specialist miner", "replacer miner"). Orphaned blocks increase the risk for the bad guys, though.

Please take detailed discussion of this concept back to the original thread: https://bitcointalk.org/index.php?topic=196136



What about this box of Pandora: Nodes could delay relaying of blocks including double spends (txs replacing txs the node knows about). 

Side note: could delaying relay of blocks with unknown txs give miners an incentive to relay?

Yes, I am aware of that. My solution is only useful if you don't work with a miner which is very powerful (e.g., I wouldn't know how to do that).

Note also that in my solution, the miner makes much more money if he does not help the guy who double spends.

Your idea makes transactions 100% fraud free, however I don't see how that can be implemented for people who WANT to use the feature instead of everyone. Also, the main discussion point for Bitcoin right now is making Bitcoin very easy for the general population. Thats why you see those new Bitcoincards coming out. Your method also requires that everyone uses two wallets with every purchase. Making something like a Bitcoin card with that kind of anti-fraud system is impossible. Lastly, if V wanted to make T2 go to the miners, how would he force the said payment without having the private key to the wallet? You would need to have some sort of temporary escrow system in place always running ontop of the blockchain. Your ideology is admirable but not practical. Nice thinking though.

There is nothing stopping Tx3 from being broadcast and accepted by the network (assuming input B1 is from standard Tx), so the merchant could extort the buyer under threat of prematurely broadcasting. Scripts are only evaluated when someone tries to spend outputs. Tx3 coins would be sent to an address that is unspendable unless the script conditions were met (presumably, proof of a dbl spend). There is also nothing stopping the buyer from dbl spending B1, making the "safety" Tx invalid.

I am unconvinced there is a way to do what this thread is proposing that isn't exploitable. The proposers have the burden of proof to show otherwise. For instance, you cannot wave your hand and say there is a non-exploitable way to make a Tx valid only when a dbl spend attempt occurs. That is a major change to Tx scripting and will require technical details on your part.

As he said it is a special TX.

The problem with this approach is that the deposit can be spent to another address in the same block as the double spend.

bump:

What about this box of Pandora: Nodes could delay relaying of blocks including potential double spends (txs replacing txs the node knows about). 

This would give miners an incentive to use the first / most popular tx with a certain prev output.

I agree that there is work needed there. It is, however, clear that one could in principle add an instruction to the scripting language which does exactly this. However, this would not be a good solution, and so work is needed to make the approach practical.

No, that's no problem: usually miners will not do this as they can earn more by using Tx3 (or else, the guy who double spends still pays the miner a lot of fees).

Do nodes currently not transmit tx's which are double spends, i.e., only keep the first one?

The problem TalkingAntColony pointed out is that of specialized "double spend miners". These build reputation and make money by helping the double spender. In the long run they can make more money by helping the double spender and not use TX3 but by mining the double spend and moving the deposit.

Sometimes (~1%) the double spend miner's blocks get orphaned, though, which means the TXs from the block become public and other miners will mine TX3.

Yes. Invalid TXs will be silently ignored by the standard client. There were discussions about broadcasting double spend warnings along with the two conflicting TXs but there is only little benefit for a careful merchant.

I feel like this is a grey area with the proposal. You cannot simply assume there exists a feasible extension to scripting which would allow the network to verify that a double spend occurred.

Also, what happens when the payer double-spends to another merchant using this proposal's mechanism? Who's Tx3 would be valid?

I would guess that major miners already are, or will, at some point, communicate directly among each other. After all, you don't want to miss a block.

It is not clear to me if one could not have a convention to under which miners might ignore certain blocks though.

I agree there is work need, but it is clear that there is a way of doing an extension which does what I want: simply introduce an opcode which does exactly what you want (i.e., don't even run the scripts; instead, check whether they have exactly the form required, and if so accept everything). Of course, this would be a bad way of doing it.

I think the main question here is: how can one make the scripting language flexible enough to allow this kind of mechanism?

Whichever is mined. Note that the miner will probably take the one giving him more fee.

This was the idea that lead me to start this thread:
https://bitcointalk.org/index.php?topic=163751 Mining Codex

I would expect the large miners to be well connected, too. Will this still be possible with the new protocols? Will there be mining supernodes with several thousand miners connected to share blocks as fast as possible? Might well be possible.

Like you say, with the existing rule set zero-conf requires trust. As it stands "commitments not to double spend" can themselves be double spent. So they aren't credible.

An altchain could bend the rules and create a simple fix for this. We need "general purpose seeding contracts". These "seeding contracts" would be deposits supporting zero-conf txns to arbitrary payees. The Buyer is the sole party to a "general purpose seeding contract." Buyers precommit to zero-conf payments long in advance, but designate the payee and the amount at the time of sale. The "general purpose seeding contract" enters the blockchain long before the sale occurs, so it is credible. Payees could safely accept anonymous zero-conf payments issued from such contracts.

How could this work?

Suppose there is a new address type. Inputs originating from this address type obey the following txn rules:
1) 4/5 of inputs must be sent to the signing public key (I.e. you can only transfer 20% of any input to a new public key)
2) txn outputs are never spendable until 10 blocks have passed. Provided 3 does not occur, inputs become spendable after 10 blocks.
3) if the signing public key appears twice within a ten block interval, a contract violation is detected. The miner of the second txn receives 1/5 of the inputs as a txn fee. The other inputs are destroyed (i.e. the payee(s) receive nothing at all).

There are just two possible outcomes.
1) Payee receives their money. Buyer does not lose any money.
2) Payee receives nothing. Miner receives buyers payment. Buyer loses at least 4x the value of the payment.

Rational buyers never chose outcome 2, so payment are assured even with 0 confirms. It seems bad that the payee doesn't get paid in outcome 2, but this is unavoidable. You can never know who the legitimate payee is, so all you can do is take money hostage and destroy it.

[Edit: Thieves could try to spend at 6 or more different zero-conf accepting merchants simultaneously, but I bet this is much too difficult and risky to be practical.  If not, you could increase the escrow requirement (e.g. 10-fold instead of 5-fold, so at least 11 simultaneous purchases must occur before theft is profitable).]

Darn, the last two nights I pondered about something I thought was all new and now you are faster than me with this post. ;) 

Anyway, the key seems to be a possibility to impede double spends even after they are in a block because only then they have to be public. See my less sophisticated but also simpler suggestion below.

If a merchant waits for 10 seconds after receiving the TX and then broadcasts it to plenty of nodes this can not happen.

Simpler version of cunicula's suggestion. It spans unabridged's original solution across blocks.

You can only know about a double spend for sure once the TX is in a released block. This means an effective zero confirmation double spend circumvention is only possible if it still works after a TX is in the blockchain.

double spend destructor
If a miner can come up with a new signed TX including an input already used as input in the previous block he can claim the input as an additional transaction fee.
The TX in the previous block becomes invalid!
Transactions that only changed the transaction fee must be excluded.

There are just two possible outcomes:
1) Merchant receives their money. Buyer payed merchant.
2) Merchant receives nothing. Miner receives payment. Buyer payed miner.
There is no penalty for the buyer but also no incentive. I think that should be enough.

This change makes single confirmation TXs less secure than now but removes the incentive to double spend. With the current system I don't see a use case for single confirmation TXs other than preventing double spends anyway. TXs with two or more confirmations are as secure as today.

A problem is that it is necessary to make 100% sure never to broadcast modified TXs (with the exception of increased fees).

That is a risky method due to invalidating a Tx already in a block. Consider if a dbl-spender mines his own block with a Tx that dbl-spends coins, invalidating a zero-conf Tx he sent a Merchant A. He then immediately pays Merchant B from the dbl-spent coin who accepts zero-conf Tx (presumably because of their trust in this proposal). If he pays Merchant B before he hears about Merchant A's invalidated Tx, then Merchant B will have their zero-conf Tx invalidated and the dbl-spender gets away with effectively dbl-spending coins (got same coins accepted by two merchants).

This also sets up the possibility for extortion, where a buyer threatens to dbl-spend coins (making the merchant lose the coins) unless the merchant does something.

No, that can not happen if merchant B does a proper job. Merchants always have to wait and listen for a couple of seconds for previous TX and then broadcast the TX afterwards. Merchant B could even sell the double spending TX to a miner without giving away the goods.

I don't think extortion is a problem at all for the targeted kinds of goods.

The Tx that Merchant A receives may or may not be heard about by Merchant B. It is unwise IMO to make a security feature rely on the assumption that all nodes will know about all unconfirmed Tx. Then, then the buyer mines his own block sending the coins back to himself. Merchant B will accept zero-conf Tx building off that block if he doesn't know about the Tx from Merchant A. The buyer could peer directly with Merchant B so Merchant B is likely to see the new block faster than Merchant A. This gives the buyer more time for his zero-conf Tx to be accepted by Merchant B. Merchant A must "be on the ball" to quickly realize the dbl-spend and make sure all other nodes know this. Naturally or purposefully occurring 1-2 block blockchain forks may make this proposal unreliable as well.

Also, what if there are buyers who always dbl-spend coins, so that merchants will be discouraged from accepting zero-conf Tx using this method? There is no additional cost to buyers who dbl-spend in this scheme anyway.

Merchant A of course rebroadcasts the tx himself to make double spends less likely to succeed. As long as no block was found this is a similar situation to what we have now. Once the first tx is in a block, well, the merchant really should make sure he gets that. I have no info on this but I would expect network permeation to be very high.

It is not a security feature but a "safe enough" feature. This means it does not have to be perfect but just 98% or so, way better than what we have now.

? The sending coins back tx conflicts with the tx to Merchant B so he will never accept it if he has seen the block. Also note that as soon as the block with the malicious "sending coins back" becomes public it is certain a miner will claim the payment - because the first tx is public, too.

Are you talking about a Finney attack? The risk of orphaning the new block would be much too high.

see above

These are so rare they do not matter and do not hurt this proposal in any way.

This is exactly what will happen with the current system. "double spending destruction" removes the incentive to do it so I doubt a lot of people would go through the (maybe very small) trouble. Also most people still have a conscience without financial gains. Cunicula's suggestion even addresses this with a penalty.

I think that schemes like this are doomed to failure.

Right now, a bitcoin transaction has very simple rules.  There are really only two:

A transaction is valid if it satisfies the conditions specified in the inputs it redeems.
A transaction output can only be redeemed once.

That's really all there is to it.  A powerful and useful system defined by just two simple rules.  The pinnacle of engineering and beauty, nothing left to take away.

Now, our computers are really dumb, so things that we take for granted, we have to explain to them in great detail.  So, the software isn't as beautiful as the idea it represents.  We have to tell the computer that you can't have a negative output to balance out a too-large output, and things like that.

Assume that we devise some way to allow the network to take action against double spends.  There are horrifying technical challenges in that task, but we are going to assume that condition, so we don't have to worry about solving them.  Any such scheme is going to destroy the beauty of the system.  There won't be two simple rules that you can explain to literally anyone in 5 minutes, there are going to be three.  And the third one is going to be ugly.  It is going to start out with "Except when..."

The first rule is math.  The second rule is time.  Both of these are necessary, in that you can't have a system like this without math and time.  The third rule will be the mob.  The third rule will be the one that we added to make some particular group of people happy.  The third rule will be the foot in the door for the fourth rule, to make some other group happy.  And then the fifth.  Next thing you know, we'll have a group of people meeting on an island to add a rule that will solve the world's problems.

Fortunately, I think that people see this.  Even if we could distill the problem down to "just a bit of code", it would destroy the beauty of the system.  The software could take the hit, lot of it is already ugly.  But it would be fatal to the idea that the software represents.

I'm not convinced my exploit has been resolved, but it may be a misunderstanding of the proposal here. Either way, you haven't convinced me this proposal is sound, and the burden of proof is on the ones claiming they have found a way to make zero-conf Tx safe. If you are really serious about this idea, program it into an altcoin or testnet and get people to run attacks against it. If you are successful, you might create a valuable altcoin or be responsible for a critical fork to bitcoin. At this point however I'm done examining this proposal which is difficult to discern without code.

@phelix

http://www.reddit.com/r/CryptoCurrency/comments/1evxuk/how_toalt_coin_with_secure_zeroconf_txns/ (http://www.reddit.com/r/CryptoCurrency/comments/1evxuk/how_toalt_coin_with_secure_zeroconf_txns/)
FYI, I posted here for other eyeballs.

There is nothing wrong with my proposal or your modification. Mine is more secure, yours is more convenient. It's just a trade-off.

The bitcoin community is extremely opposed to hard-forks, so don't be discouraged by the lack of enthusiasm. Major changes are only practical in the altcoin community, so consider promoting radical new ideas there.

I like your romantic view of Bitcoin and aesthetics sure are important. Simple solutions that work well is where brilliance of mind shines. If we can improve the system by making some small changes, though, I think we should still to do it. Maybe it will even bring us to an improved simple solution.

Thank you for input. I think the concept in the basic version is simple enough to make thought experiments with it. I invite you and others to make more of these about it.

That's how I see it, too.

Yup, by now there is so much money and politics involved with Bitcoin that a change like this can only be implemented once there is a successful altcoin testing the change. Maybe it even needs to rise to a level of popularity that makes Bitcoin devs uncomfortable before it will be seriously considered.

With the simple variant there still seems to be an incentive for the miner of the second block to do tx replacement. Maybe that was what TalkingAntColony tried to tell me above.

Cunicula's version does not have this problem. Could be that it is necessary to destroy coins.