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
|
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 1ROKsu-0003Jq-KD
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Nov 2011 03:01:00 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1ROKss-0005Tq-AV
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Nov 2011 03:01:00 +0000
Received: by vwe42 with SMTP id 42so2720752vwe.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 09 Nov 2011 19:00:52 -0800 (PST)
Received: by 10.52.23.20 with SMTP id i20mr9372436vdf.93.1320894052876;
Wed, 09 Nov 2011 19:00:52 -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 ey9sm10188524vdc.19.2011.11.09.19.00.51
(version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 19:00:51 -0800 (PST)
Message-ID: <4EBB3E68.6060402@gmail.com>
Date: Wed, 09 Nov 2011 22:00:56 -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: bitcoin-development@lists.sourceforge.net
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com> <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
<200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
In-Reply-To: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
Content-Type: multipart/alternative;
boundary="------------090705060302020707080007"
X-Spam-Score: -1.1 (-)
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.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1ROKss-0005Tq-AV
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: Thu, 10 Nov 2011 03:01:00 -0000
This is a multi-part message in MIME format.
--------------090705060302020707080007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
The purpose of creating BIP 0010 now, is to encourage a standard that
developers /want/ to adopt, from the outset. Every developer who is
planning to touch multi-signature transactions, is going to have to
solve the problem of multi-sig tx exchanges, eventually. By offering an
excellent solution before they've started asking the question, there's a
good chance people will use it. Hear me out...
Protocols get fragmented when there's multiple competing ways to do
something, each having some advantages the others don't have. This
leads to developers with differing priorities picking different ones, or
creating their own. However, I believe that the problem BIP 0010 seeks
to solve is a fairly straightforward problem. There's not a lot of
variety in the solutions that could compete against it. People just
need a way to pass this data around, and they want it to be as
convenient to use, and as easy to implement as possible. In that sense,
I think BIP 0010 (or some future variant) is fairly optimal as a
building block for higher-level protocols.
If anyone has ideas for why someone would want to create a competing
idea to BIP 0010 (besides not being aware of it when they start), I'd
like to discuss it. I'm fairly confident that any such ideas could just
be added to BIP 0010 and thus reset the question of why anyone would
need a competing idea.
On 11/09/2011 03:03 PM, Michael Grønager wrote:
> My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the
>
> /M
--------------090705060302020707080007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The purpose of creating BIP 0010 now, is to encourage a standard
that developers <i>want</i> to adopt, from the outset. Every
developer who is planning to touch multi-signature transactions, is
going to have to solve the problem of multi-sig tx exchanges,
eventually. By offering an excellent solution before they've
started asking the question, there's a good chance people will use
it. Hear me out...<br>
<br>
Protocols get fragmented when there's multiple competing ways to do
something, each having some advantages the others don't have. This
leads to developers with differing priorities picking different
ones, or creating their own. However, I believe that the problem
BIP 0010 seeks to solve is a fairly straightforward problem.
There's not a lot of variety in the solutions that could compete
against it. People just need a way to pass this data around, and
they want it to be as convenient to use, and as easy to implement as
possible. In that sense, I think BIP 0010 (or some future variant)
is fairly optimal as a building block for higher-level protocols. <br>
<br>
If anyone has ideas for why someone would want to create a competing
idea to BIP 0010 (besides not being aware of it when they start),
I'd like to discuss it. I'm fairly confident that any such ideas
could just be added to BIP 0010 and thus reset the question of why
anyone would need a competing idea.<br>
<br>
<br>
<br>
On 11/09/2011 03:03 PM, Michael Grønager wrote:
<blockquote
cite="mid:200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com"
type="cite">
<pre wrap="">
My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the
/M
</pre>
</blockquote>
<br>
</body>
</html>
--------------090705060302020707080007--
|
