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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1TgfwY-0002Vp-KG
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 18:13:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=etotheipi@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TgfwX-0002Hm-On
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 18:13:06 +0000
Received: by mail-ob0-f175.google.com with SMTP id vb8so6832905obc.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Dec 2012 10:13:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.184.102 with SMTP id et6mr1567080obc.102.1354817580433;
Thu, 06 Dec 2012 10:13:00 -0800 (PST)
Received: by 10.76.170.230 with HTTP; Thu, 6 Dec 2012 10:13:00 -0800 (PST)
In-Reply-To: <CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
<20121129170713.GD6368@giles.gnomon.org.uk>
<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
<20121129185330.GE6368@giles.gnomon.org.uk>
<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
<CANEZrP2riPBViBqAOWfY9uSQwoEm=gN108JU988XvouMbai1Ug@mail.gmail.com>
<CABsx9T023aw11cq6iiZhT3cgfNYJXr=qG40Fzc7rYZOimJ=62w@mail.gmail.com>
<50C03BDA.6010600@petersson.at>
<CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
<CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com>
Date: Thu, 6 Dec 2012 13:13:00 -0500
Message-ID: <CALf2ePx5jS__L_2bTtU7duAbDfeinEapzARuGEJ-XCbkK=TxNA@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444e8a59dffc004d0330ce4
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: 1TgfwX-0002Hm-On
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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: Thu, 06 Dec 2012 18:13:06 -0000
--f46d0444e8a59dffc004d0330ce4
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> When I say "pass around" I'm not thinking of users copying and pasting,
> that would be a terrible user experience; all of that communication needs
> to happen automatically behind the scenes. Lets tackle that after we've got
> the simpler customer-pays-merchant flow working nicely
> (funded-escrow-pays-merchant is a subset of that, anyway).
I think that the "pass around" method needs to happen in addition to the
methods of transparent protocols that occur behind the scenes. For one,
there's a lot of CONOPs that need to be worked out by getting knowledgeable
people using it, and providing feedback about how it could/should/will be
used and how it could be improved. The pass-around method is simpler to
implement and still usable by the types of users that will be using it in
the beginning -- experts. Also, I see that for very large, important
multi-sig tx/contracts/escrow, the "manual" method might be preferred --
much the same way many people prefer manual-transmission cars even though
automatics are "easier" -- some people/organizations will want the control.
I'm all for protocols that enable higher-level access to this
functionality, I'm just saying there should be lower-level access, too.
--f46d0444e8a59dffc004d0330ce4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 6, 20=
12 at 11:56 AM, Gavin Andresen <span dir=3D"ltr"><<a href=3D"mailto:gavi=
nandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">When I say "pass around" I'm n=
ot thinking of users copying and pasting, that would be a terrible user exp=
erience; all of that communication needs to happen automatically behind the=
scenes. Lets tackle that after we've got the simpler customer-pays-mer=
chant flow working nicely (funded-escrow-pays-merchant is a subset of that,=
anyway).</blockquote>
</div><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">I think that the "pass around" method needs to happen in add=
ition to the methods of transparent protocols that occur behind the scenes.=
=A0For one, there's a lot of CONOPs that need to be worked out by gett=
ing knowledgeable people using it, and providing feedback about how it coul=
d/should/will be used and how it could be improved. =A0The pass-around meth=
od is simpler to implement and still usable by the types of users that will=
be using it in the beginning -- experts. =A0Also, I see that for very larg=
e, important multi-sig tx/contracts/escrow, the "manual" method m=
ight be preferred -- much the same way many people prefer manual-transmissi=
on cars even though automatics are "easier" -- some people/organi=
zations will want the control. =A0=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I'm all=
for protocols that enable higher-level access to this functionality, I'=
;m just saying there should be lower-level access, too.</div><div class=3D"=
gmail_extra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra"><br></div>
--f46d0444e8a59dffc004d0330ce4--
|
