Proposal for blockchain-based "transaction 2FA" / reversible transaction

[fairglu]

One issue with transactions is that they are currently not reversible, even when you realize a few seconds after hitting the send button it's the wrong recipient, or the wrong amount.

Below is a proposal for a mechanism that would allow "2FA" and a grace period for reverting transactions when the recipient is "trustable" (such as a merchant, a reputable payment processor, etc.).
Unlike other proposals, it is very simple, does not require any direct communication channels outside of the blockchain, and is purely voluntary and optional.

Please shoot away criticism *after* reading it  

The idea is to introduce a new type of transactions, preferably alongside a new class of addresses, that could begin with 'R' for instance:

• an output to an R address can be redeemed by the usual means, but also by signing all inputs of the transaction that created this output

This would allow the following online payment scenario:

• 1 - merchant generates an R address, displays it to customer
• 2 - customer scans, copy/pastes, whatever and sends his payment tx
• 3 - merchant notices the new transactions (even with 0 confirmations), checks the amount and displays it alongside a "confirm" button or an "alert" button
• 4a - if customer confirms, merchant issues a transaction, redeeming the R address to its own wallet (even with zero confirmations), then waits for confirmations on that redeeming transaction (waiting for 1 to 3 confirmations as usual)
• 4b - if customer sees no "confirm" button, or realizes he sent to the wrong address or the wrong amount, for whatever reason, he can hit the "revert" button in his wallet, which will send a tx to recover the funds, the only losses are then the tx fees

Step 3 and beyond are currently not possible, at least not without human interaction.

For the reversal to be possible, it requires an "honest" merchant or processor, that will wait for a customer confirmation action before issuing the redeem transaction that will empty the R address. But that should not be a problem for all major merchants and processors, since you already have to trust them to deliver in the real-world.

Alongside with multi-sig, this mechanism would also allow new forms of purely blockchain-based escrow or multi-party contributions to a trusted entity, f.i. several people pooling funds for a cause with a deadline, and those people would still be allowed to individually backtrack, without requiring a human to perform refunds manually.

[TierNolan]

With the new locktime stuff, you could support this.

Code:

OP_IF 
    <current_height + 6> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <hash of receiver's pub key> OP_EQUALVERIFY OP_CHECKSIG 
OP_ELSE
    OP_DUP OP_HASH160 <hash of sender's pub key> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

This means that the sender can spend the output immediately but the receiver can't spend it until 6 blocks have passed.

After 6 blocks, the receiver could send it onward to another address to finalize the transaction.

Within 6 blocks (one hour) the sender could transfer it to another address and reverse the transaction.

[fairglu]

With the new locktime stuff, you could support this.

Locktime by itself does not sound like a very interesting feature for short lock times, as blocks have unpredictable intervals, while long locktimes are predictable, but... too long for interactive scenarios.

Would <current_height + -1> work or an always true? If so that could enable my payment scenario (for the 2FA to be practical, the transactions needs to be confirmable with zero conf, and redeemable with zero conf, so that you only need to wait a few confs total, as currently).

Upside of using a script would be it does not require a new address scheme, downside is it would not make it simple/explicit to users: when presenting a regular address, you could issue any kind of tx to it, scripted or not. The user and its wallet could easily end up sending a non-scripted tx while thinking it sent a scripted one, also the payment recipient needs a bit of extra work, and cannot ensure anything for the client.

Having a distinct address scheme solves the above without requiring complicated (long) scripts.

[TierNolan]

Locktime by itself does not sound like a very interesting feature for short lock times, as blocks have unpredictable intervals, while long locktimes are predictable, but... too long for interactive scenarios.

You can use timestamps, but I there is an assumption that an hour or so difference either way doesn't matter.

Would <current_height + -1> work or an always true? If so that could enable my payment scenario (for the 2FA to be practical, the transactions needs to be confirmable with zero conf, and redeemable with zero conf, so that you only need to wait a few confs total, as currently).

Zero confirm is inherently dangerous for the merchant. 

The confirm stage isn't very clear really, you could just not send the transaction.

I think this achieves what you want.

Code:

OP_IF
    <current block + 6> OP_CHECKLOCKTIMEVERIFY OP_DROP <customer's pub key 1> OP_CHECKSIG
OP_ELSE
    <customer's pub key 2> <merchant's pub key> OP_2 OP_2 OP_CHECKMULTISIG
OP_ENDIF

The process is:

Merchant sends client <merchant's pub key>

Client creates 2 key pairs.

Client sends money to the above output

Merchant sees transaction and requests confirm

Client confirms

Client sends private key for <customer's pub key 2> as confirm message

Merchant spends the OP_CHECKMULTISIG using their own private key and the confirm key.

The merchant must do that within one hour, or the client can spend the output.

Client rejects confirm - Merchant honest

Merchant sends the private key for <merchant's pub key>

Client spends the OP_CHECKMULTISIG using their own private key and the confirm key.

Client rejects confirm - Merchant dishonest

Client must wait 1 hour, and then can spend the output.

[fairglu]

Zero confirm is inherently dangerous for the merchant. 

Zero confirm would only be for issuing the redeem tx from the merchants, then the merchant would wait for confirmations on his redeem transaction, rather than on the customer's.

This means that ideally, customer payment & redeem tx would end up in the same block, and no delay would be added compared to the current situation.

The confirm stage isn't very clear really, you could just not send the transaction.

The customer tx is what enables the confirm button, which thus shows the customer its payment was made to the proper address, and the merchant can confirm the amount as well.
However as long as the merchant as not issued his redeem tx, and this tx as not been confirmed, the customer can issue a tx to recover his funds.

The process is:

My proposal would not involve sending of any private key, or any form of data exchange between customer & merchant beyond the customer clicking on a confirm button.

Rephrased for clarification the scenario:

Merchant displays <merchant's single use payment address>

Client sends money to the above output (tx1)

Merchant sees transaction and requests confirm

Client confirms - Merchant honest

Client clicks confirm button

Merchant spends the tx1 to another private address with tx2

No fragile time limit or requirements, merchant waits for 1-3 confirmations on tx2 (which also means at least 1-3 conf on tx1, since tx2 depends on it)

Client cancels - Merchant honest

Clients does not click confirm, but issues a tx3 that spends tx1 back to his own private wallet.

Merchant has nothing to do, can detect tx3 and show the transaction was canceled.

No time limits or expiration at the blockchain level, only expiration would be in merchant UI.

Client dishonest - Merchant honest

Client clicks confirm, but issues a tx3 while or before merchant issues a tx2.

This is a blockchain race, only one will be accepted, or both will rejected, but merchant is safe as it only waits for tx2 confirmations, which will not happen if tx3 wins.

Client honest - Merchant dishonest

Merchant issues tx2 immediately and gets the funds. This case is not protected, but is not different from the merchant accepting the funds honestly, but not delivering anything.


So to summarize, the main difference between yours and mine is that my approach does not require an exchange of private key or a communication protocol, and customer can recover his funds even in case the merchant UI failed during payment (for whatever reason), as long as the merchant is honest. There is also no time constraint of any sort.
The use of a special address scheme rather scripts would be to make it visually obvious and unambiguous to users.

The lack of blockchain-based time constraint means that it also opens scenarios where multiple people contribute freely to a common fund with a public contribution address, without involving multi sigs or complex private keys exchanges, for instance:

Charles wants to raise fund for project X (kickstarter-style, charity, etc.), to be redeemed on august 30, shows a R address for contribs to that project
- Alice sends 1 BTC to the R address
- Bernard sends 2 BTC to the R address
- Daniel sends x BTC, etc..
- A few days later, Alice changes here mind, and recovers her funds.
- On august 30, Charles transfers all R funds to his own address, and starts work on Project X

Alice did not need anyone to recover her funds, and Charles did not need to issue anything or manage anything to have Alice recover her funds.
OP_RETURN could optionally be used to pass along metadata about the contributions, so that everything could be blockchain-based.