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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1RPH5x-0005mm-Is
for bitcoin-development@lists.sourceforge.net;
Sat, 12 Nov 2011 17:10:21 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=etotheipi@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RPH5w-0001bN-PL
for bitcoin-development@lists.sourceforge.net;
Sat, 12 Nov 2011 17:10:21 +0000
Received: by vcbfl11 with SMTP id fl11so2876288vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 12 Nov 2011 09:10:15 -0800 (PST)
Received: by 10.52.65.78 with SMTP id v14mr20202673vds.89.1321117815390;
Sat, 12 Nov 2011 09:10:15 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net.
[76.111.108.35])
by mx.google.com with ESMTPS id id7sm22397678vdb.21.2011.11.12.09.10.13
(version=SSLv3 cipher=OTHER); Sat, 12 Nov 2011 09:10:14 -0800 (PST)
Message-ID: <4EBEA880.7010608@gmail.com>
Date: Sat, 12 Nov 2011 12:10:24 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com> <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com> <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com> <4EBB3E68.6060402@gmail.com> <CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com> <4EBBCA0D.9060906@gmail.com>
<CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
In-Reply-To: <CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------060806030403030407020405"
X-Spam-Score: -0.7 (/)
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
-0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RPH5w-0001bN-PL
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
op_eval and lock_time/sequence...
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: Sat, 12 Nov 2011 17:10:21 -0000
This is a multi-part message in MIME format.
--------------060806030403030407020405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Maybe I'm new to this, but this doesn't make any sense. I thought the
point of the BIP was to collaborate to come up with a good solution.
That's exactly what I want to do before I implement it in my software.
After all, they are "Bitcoin Improvement *Proposals*." It seems like
EXACTLY what a BIP is for... just no one needs/should use it until it
removes the "draft" marking.
As for the protocol on top of it, my BIP was not intended to address
that. It's only proposing how unsigned transactions can be serialized
and users can collect addresses. Whatever system you want to implement
on top of it to exchange the data is up to the developer. My only
motivation is that if the user clicks "Save this proposal to file", that
any client can use the resulting file, just the same way we serialize
any other blockdata that has a consistent representation.
-Alan
On 11/12/2011 11:58 AM, Mike Hearn wrote:
> Please don't create BIPs that don't have any actual implementation
> behind them. Design discussion is fine but the mailing list works for
> that.
>
> If I were going to implement escrow transactions in BitCoinJ it would
> not matter what was written here. I'd just implement the design I
> thought made sense. If that design was later adopted by others it can
> be documented and agreed upon in a BIP, just like a regular RFC.
>
> For what it's worth I would not attempt to send half-valid escrow
> transactions through the p2p network, not even using the overlay
> networks the protocol already supports. A correct escrow protocol
> requires the seller to challenge the dispute mediator with the public
> key to be sure they actually own it, and the simplest way to do that
> is to leverage the existing DNS/EV-SSL infrastructure with a "sign
> this nonce" HTTP request.
>
> BIPs should not be a place for people to come up with armchair
> designs, because a design with no corresponding implementation is
> likely to be full of problems. Let's revisit this once I can install
> some software on my laptop, my server, and a friends server, and do a
> 3-way mediated transaction between them.
--------------060806030403030407020405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Maybe I'm new to this, but this doesn't make any sense. I thought
the point of the BIP was to collaborate to come up with a good
solution. That's exactly what I want to do before I implement it in
my software. After all, they are "Bitcoin Improvement <b>Proposals</b>."
It seems like EXACTLY what a BIP is for... just no one needs/should
use it until it removes the "draft" marking.<br>
<br>
As for the protocol on top of it, my BIP was not intended to address
that. It's only proposing how unsigned transactions can be
serialized and users can collect addresses. Whatever system you
want to implement on top of it to exchange the data is up to the
developer. My only motivation is that if the user clicks "Save this
proposal to file", that any client can use the resulting file, just
the same way we serialize any other blockdata that has a consistent
representation.<br>
<br>
-Alan<br>
<br>
<br>
<br>
On 11/12/2011 11:58 AM, Mike Hearn wrote:
<blockquote
cite="mid:CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com"
type="cite">Please don't create BIPs that don't have any actual
implementation behind them. Design discussion is fine but the
mailing list works for that.
<div><br>
</div>
<div>If I were going to implement escrow transactions in BitCoinJ
it would not matter what was written here. I'd just implement
the design I thought made sense. If that design was later
adopted by others it can be documented and agreed upon in a BIP,
just like a regular RFC.</div>
<div><br>
</div>
<div>For what it's worth I would not attempt to send half-valid
escrow transactions through the p2p network, not even using the
overlay networks the protocol already supports. A correct escrow
protocol requires the seller to challenge the dispute mediator
with the public key to be sure they actually own it, and the
simplest way to do that is to leverage the existing DNS/EV-SSL
infrastructure with a "sign this nonce" HTTP request. </div>
<div><br>
</div>
<div>BIPs should not be a place for people to come up with
armchair designs, because a design with no corresponding
implementation is likely to be full of problems. Let's revisit
this once I can install some software on my laptop, my server,
and a friends server, and do a 3-way mediated transaction
between them.</div>
</blockquote>
<br>
</body>
</html>
--------------060806030403030407020405--
|
