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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1V7BZo-0006Oy-Px
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 21:47:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.48 as permitted sender)
client-ip=209.85.216.48; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f48.google.com;
Received: from mail-qa0-f48.google.com ([209.85.216.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V7BZo-0005nd-1F
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 21:47:28 +0000
Received: by mail-qa0-f48.google.com with SMTP id o19so1356051qap.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 07 Aug 2013 14:47:22 -0700 (PDT)
X-Received: by 10.224.12.81 with SMTP id w17mr2903891qaw.37.1375912042483;
Wed, 07 Aug 2013 14:47:22 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id i1sm14101071qas.10.2013.08.07.14.47.21
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 07 Aug 2013 14:47:21 -0700 (PDT)
Message-ID: <5202C05B.8090509@gmail.com>
Date: Wed, 07 Aug 2013 17:47:07 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
<CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
<CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
In-Reply-To: <CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative;
boundary="------------010800050007040508020100"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V7BZo-0005nd-1F
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2013 21:47:29 -0000
This is a multi-part message in MIME format.
--------------010800050007040508020100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 08/07/2013 05:10 PM, Gavin Andresen wrote:
> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ? The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>
I have avoided any notion of locking inputs in Armory for offline
wallets. The underlying concept of why a seemingly-random amount of
funds are inaccessible at a given time is so non-intuitive and difficult
to explain to a non-expert, that I haven't even tried to deal with it.
Luckily, most users do one operation at a time, so it's not a real a
problem. But as more businesses have started to use Armory, it /will/
become a problem that will need to be addressed /somehow/.
I have considered at least "marking" inputs to indicate to the user that
the transaction they are creating may not be valid unless all previous
transactions have been broadcast. The user will not necessarily
understand why, but they might easily comprehend the solution (and
perhaps a button that says "Forget all previously created transactions
that haven't been broadcast. Press this button if there are no
transactions waiting to be broadcast").
Even if the user somewhat understands the concepts behind locking, you
easily end up with a mess of some coins being locked and rejecting
transaction creation somewhat randomly, especially when they create
transactions that they later decide not to execute. And you have to
give the user a way to manually unlock the outputs which they wouldn't
know to use because it's so non-intuitive. I'd much rather say "either
do one transaction at a time, or bundle payments into a single
multi-output transaction. Or risk invalid transactions that have to be
re-created and signed."
-Alan
--------------010800050007040508020100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 08/07/2013 05:10 PM, Gavin Andresen wrote:<br>
<blockquote
cite="mid:CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com"
type="cite">
<pre wrap="">I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
</pre>
</blockquote>
I have avoided any notion of locking inputs in Armory for offline
wallets. The underlying concept of why a seemingly-random amount of
funds are inaccessible at a given time is so non-intuitive and
difficult to explain to a non-expert, that I haven't even tried to
deal with it. Luckily, most users do one operation at a time, so
it's not a real a problem. But as more businesses have started to
use Armory, it <i>will</i> become a problem that will need to be
addressed <i>somehow</i>. <br>
<br>
I have considered at least "marking" inputs to indicate to the user
that the transaction they are creating may not be valid unless all
previous transactions have been broadcast. The user will not
necessarily understand why, but they might easily comprehend the
solution (and perhaps a button that says "Forget all previously
created transactions that haven't been broadcast. Press this button
if there are no transactions waiting to be broadcast"). <br>
<br>
Even if the user somewhat understands the concepts behind locking,
you easily end up with a mess of some coins being locked and
rejecting transaction creation somewhat randomly, especially when
they create transactions that they later decide not to execute. And
you have to give the user a way to manually unlock the outputs which
they wouldn't know to use because it's so non-intuitive. I'd much
rather say "either do one transaction at a time, or bundle payments
into a single multi-output transaction. Or risk invalid
transactions that have to be re-created and signed."<br>
<br>
-Alan<br>
<br>
<br>
</body>
</html>
--------------010800050007040508020100--
|
