Topic: Making 0-conf TXs relatively safe "again" - page 2. (Read 2233 times)

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.

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.

"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://bitcointalksearch.org/topic/making-double-spending-economically-unattractive-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?

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

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

Tx3:
  Input B1
  Outputs:
    1: 0.1 BTC to
    2: 9.9 BTC to
       *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).

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

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?

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.

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

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

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?

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 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.

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.

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.).   

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.

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.

I suggested something similar (way later) here: https://bitcointalksearch.org/topic/making-double-spending-economically-unattractive-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://bitcointalksearch.org/topic/making-double-spending-economically-unattractive-196136 is somewhat nicer because it increases the chance the vendor gets his money, but more complicated.

There are no "local" rules like you imply.

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.

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 and 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://bitcointalksearch.org/topic/reminder-zero-conf-is-not-safe-1000usd-reward-posted-for-replace-by-fee-patch-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

There has been a suggestion by unabridged quite a while ago that I think would be a relatively simple yet effective solution:
https://bitcointalksearch.org/topic/penalizing-double-spends-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