1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Return-Path: <weiwu.zhang@realss.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E6C39FAB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2018 01:23:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 637012F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jan 2018 01:23:25 +0000 (UTC)
Received: by mail-pg0-f51.google.com with SMTP id m136so5890131pga.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 17:23:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=realss-com.20150623.gappssmtp.com; s=20150623;
h=sender:from:date:to:subject:message-id:user-agent:mime-version;
bh=5gFvsho2aLXgUOlGysql0sLXYDlKI8Xbj0tTr2B7o3E=;
b=A4dTqkKqoWmOfYVstvBygdoDGoFZb49m6kL1nKdE3GnQ6yvhThG9231dPcf1F+bLMh
7410vlYXL003N0ZnGCeS1Wye6f9Hsc1WBC7mIkfHktCx6sETUW2llyFqR6oRpfrrb+nr
qk39ElcCGh+dPhpf/dxTgry9zb8+YiESMrvxLNZsEio/rr7b7UjlRa6lnIH2OPXUIQjb
Dp2mOeeO3BBOCSiGhGuTYLJvY3sakUXGP+NdM95D9XKeBoIxvSxHoP67JSGQNL2iFNc4
Lf4Z8X8XBiz/0B73rjzF7mwm3e1JeZY3rQNMgn1rLRTNW6EVsz2D/gLdxNQs/Yk7GmDF
z6jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:from:date:to:subject:message-id
:user-agent:mime-version;
bh=5gFvsho2aLXgUOlGysql0sLXYDlKI8Xbj0tTr2B7o3E=;
b=gVgrk5Mdo7MkZthvhToiMOJFbb/xFWz3nUghhjyWlIRqKXy8pcikJ6iMG39R046O/5
UtFJ7ZcB8Vvo727cQTIyfL9K62fzlZ75UYIijlmRycuBKwkB6C8MsbLYh6CBSWDcRtkl
5sJZyifbIMTqM6ehGCi3g2H1zXeRmEPn9JgvQSAlFZ4sZsNn0UWVU1vq0WOUk/L4jfsd
Hl4R8qCRx9TquqdFAlqUJCk2iO1yOtht/UGRFajXBUwkp56NUEo3BkszrqZJRFkOTgcc
YB38KjIw0CBcDrZAuhrvU2nD3+NQe/D9kfWpoFqKJJQ2w38PxhR/cXerIIwDWZGJBnV2
KjMw==
X-Gm-Message-State: AKwxytd5X81QUhSVww+lup27HleTt9Q6PnYJk906O1Iezim5IG7ahKEt
0q9Wav2kaQ9gtc18qtiIIm8AYg==
X-Google-Smtp-Source: AH8x224xTsUGg/s7P5RwAN5LbBVEN4aq2EDFk7nqX/kezr85BoYgqohy739GSbJfiQj/drHvKPUkUw==
X-Received: by 10.98.190.11 with SMTP id l11mr28823163pff.32.1517275404653;
Mon, 29 Jan 2018 17:23:24 -0800 (PST)
Received: from notCBApc ([66.96.208.58]) by smtp.gmail.com with ESMTPSA id
p25sm31283553pfj.29.2018.01.29.17.23.22
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 29 Jan 2018 17:23:23 -0800 (PST)
Sender: Weiwu Zhang <weiwu.zhang@realss.com>
From: Weiwu Zhang <a@colourful.land>
X-Google-Original-From: Weiwu Zhang <weiwu@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"
X-Spam-Status: No, score=0.5 required=5.0 tests=ADVANCE_FEE_4_NEW,BAYES_00,
DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 30 Jan 2018 03:08:08 +0000
Subject: Re: [bitcoin-dev] 2 step confirmation system
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2018 01:23:26 -0000
--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--
|
