Sender: Weiwu Zhang <weiwu.zhang@realss.com>
From: Weiwu Zhang <a@colourful.land>
Date: Tue, 30 Jan 2018 09:23:13 +0800 (+08)
To: rmcc4444 <rmcc4444@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <alpine.DEB.2.20.1801300801330.27227@notCBApc>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1635907999-1517275403=:27227"
Subject: Re: [bitcoin-dev] 2 step confirmation system
Precedence: list

--8323329-1635907999-1517275403=:27227
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT


On Wed, 24 Jan 2018, rmcc4444 via bitcoin-dev wrote:

> I know from speaking to my friends not involved with Bitcoin that two of
> their major concerns are as follows: 
> 1. They are afraid if they fat finger the address there is nothing they can
> do about it and not get their Bitcoin back.

I can empathize with this. A friend of mine, an artificial intelligence
expert of the biggest bank in our country with a degree in math and IQ
of 150, copied his merchant's Bitcoin address as his and sent to a
colleague to ask for a repayment. As a result, the merchant got paid
twice. That was back a few years ago when Bitcoin could be used for
purchasing goods.

There are a few ways to address this issue.

For starter, the beneficiary's wallet can generate a signed payment
request instead of just an address. The AI expert, in his case,
wouldn't be able to generate a payment request for the merchant
because he doesn't have the merchant's key. The payment request can
have a timestamp for the sender to spot the reuse of old request. There
are advanced methods to go down this route, e.g. in the cases where
there is an invoice, or buyer's public key is known, these can be
associated with the payment request or be used in some homomorphic
magic to generate very special addresses to receive the money.

Then, there is the option of sending the transaction (in a private
channel) to the beneficiary instead of broadcasting the
transaction. The beneficiary, we trust, will not broadcast the
transaction if he would not receive money as a result of it or he sees
the transaction wasn't constructed correctly to his wish. In fact, he
may not be able to even see the transaction without the right private
key to generate a decoding session key. This method solves another
use-case: deniable payment. It's not unusual for a WeChat user to deny
another WeChat user's Red Packt ("I don't take bribes, sir!"). If it is
with Bitcoin, the beneficiary certainly does not want to pay the
transaction fee again just to nullify the previous payment to him. In
a more illustrative example, I like to give away free Bitcoins after
my lectures, but many of the students won't redeem their share because
money isn't the only motivation for their studies. I admit that money
is my motivation after all and I wish to reclaim the money that was
not redeemed by students. (I stopped this practise when giving away
Bitcoin costs more than the amount given.)

Finally, there is multi-sig. I'll cover that in answering the 2nd
section of your email.

> 2. They would like to at least have the option to use some sort of 2 step
> confirmation system when dealing ith people they do not know. For example,
> after sending the Bitcoin to a seller they would like to be able to do a
> final approval of the tm transaction. If the 2 people involved in the
> transaction approve of it within X hours, the coin returns to the original
> person. This system would basically act as an escrow.

There is the case of escrow with an arbitrator and escrow without an
arbitrator. We know that the beneficiary can always send the money
back by looking up the input address. Given that he alone has this
power, whether or not the other person agrees, to reimburse, it is a
moot point to require two people to co-sign anything. Therefore, the
case without arbitrageur is usually depended on time or revealing an x
to a known hash. This can go complicated so I'll turn around
and talk about the case with arbitrageur.

The case with an arbitrator was explained by Rhavar. It can be
elaborately built in a sheltered model, where a compromised arbitrator
can only revert transactions, not to steal. You can build fine-tuned
features with Rhavar's model, like setting a 90-day grace period where
the beneficiary cannot claim the money, in order to leave ample time
for the arbitrator to revert the transaction should he need to do so.

As Rhavar pointed out, it's too costly to be practical for daily
transactions. Back in 2012 when I learned about multi-sig, I hopped
multi-sig grew popular before the blockchain gets full so that people
have the opportunity to witness the power of Bitcoin. It unfortunately
didn't happen.

All of the methods I mentioned does not require any change to the
Bitcoin network or Bitcoin Blockchain. The wallet is the weakest link
in this chain. A wallet developer can go ahead and implement all these
without negotiating with Bitcoin developers.

P.S. I remark that I consistently use the word beneficiary because the
other choices like "receiver" or "recipient" are often meant for the
receiving of messages (e.g. in a private channel), who doesn't have to
be the beneficiary (e.g. an arbitrator receives a lot of
messages).

I check mail lists weekly so, sorry for the late reply.
--8323329-1635907999-1517275403=:27227--