Title: Proposal for blockchain-based "transaction 2FA" / reversible transaction Post by: fairglu on August 20, 2015, 02:28:38 PM 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 ;D The idea is to introduce a new type of transactions, preferably alongside a new class of addresses, that could begin with 'R' for instance:
This would allow the following online payment scenario:
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. Title: Re: Proposal for blockchain-based "transaction 2FA" / reversible transaction Post by: TierNolan on August 20, 2015, 03:01:39 PM With the new locktime stuff, you could support this.
Code: OP_IF 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. Title: Re: Proposal for blockchain-based "transaction 2FA" / reversible transaction Post by: fairglu on August 20, 2015, 03:22:27 PM 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. Title: Re: Proposal for blockchain-based "transaction 2FA" / reversible transaction Post by: TierNolan on August 20, 2015, 04:36:59 PM 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. Quote 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 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. Title: Re: Proposal for blockchain-based "transaction 2FA" / reversible transaction Post by: fairglu on August 21, 2015, 08:27:52 AM 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. |