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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YHuoa-0001xl-7t
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Feb 2015 13:43:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.176 as permitted sender)
client-ip=74.125.82.176; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f176.google.com;
Received: from mail-we0-f176.google.com ([74.125.82.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YHuoZ-0002eR-60
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Feb 2015 13:43:52 +0000
Received: by mail-we0-f176.google.com with SMTP id w62so34619858wes.7
for <bitcoin-development@lists.sourceforge.net>;
Sun, 01 Feb 2015 05:43:45 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.60.77 with SMTP id f13mr32405910wjr.105.1422798225128;
Sun, 01 Feb 2015 05:43:45 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Sun, 1 Feb 2015 05:43:45 -0800 (PST)
In-Reply-To: <CALkkCJahDRBbCeKZYnL16VXugKkJ7vyZmzvfJOHkBbcqKfGcrg@mail.gmail.com>
References: <1422667849.25602.6.camel@TARDIS>
<CANEZrP2V0+M5B0P3T6cUqmSh-0FTP5_VgNcegwQTQQM7XMfMsA@mail.gmail.com>
<CALkkCJav7gQuDuPvWc_SOgVJGyfAorSWGHMvUjUTGZBJcGnNYQ@mail.gmail.com>
<CANEZrP2mv2yNtHN7KWFn6crHT_KhrW-GBB0EmK-BOrJQeEqMrg@mail.gmail.com>
<CABsx9T2d8ahBo7PC9S5UteHXcVLFtXT7NXjtSS+2sLamQYum1w@mail.gmail.com>
<CALkkCJahDRBbCeKZYnL16VXugKkJ7vyZmzvfJOHkBbcqKfGcrg@mail.gmail.com>
Date: Sun, 1 Feb 2015 14:43:45 +0100
X-Google-Sender-Auth: 2i0qgeLvb8UiPW4RYFcUzpQC8TQ
Message-ID: <CANEZrP2xEEO5AzkiBW2PE9SrZ+xmCGHME_-z851Wn1Oqh_DKvw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b86db8acbc468050e070668
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1YHuoZ-0002eR-60
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP: protocol for multisignature
payments
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: Sun, 01 Feb 2015 13:43:52 -0000
--047d7b86db8acbc468050e070668
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If you decide to implement this in an existing or new bitcoinj based
wallet, then I'm happy to give you pointers on how to do it. Making
one-off, cross platform app specific wallets is pretty easy these days. For
2-of-3 dispute mediation transactions they'd start out being kind of
specialist so asking people to move money from their general spending
wallet into dispute mediation app isn't unthinkable. Eventually general
purpose wallets would integrate protocol, UI ideas and maybe code.
At least, that's how I'd do it.
On Sun, Feb 1, 2015 at 12:02 AM, Martin Habov=C5=A1tiak <
martin.habovstiak@gmail.com> wrote:
> I didn't consider that, thank you for feedback! I will try to find
> some time for implementing it. I'll write again then.
>
> 2015-01-31 23:50 GMT+02:00 Gavin Andresen <gavinandresen@gmail.com>:
> > I agree- standards should be descriptive ("here is how this thing I did
> > works") and NOT proscriptive ("here's what I think will work, lets all
> try
> > to do it this way.").
> >
> >
> > On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn <mike@plan99.net> wrote:
> >>>
> >>> I could look at implementing it someday, but now I'd like to receive
> >>> feedback from community.
> >>
> >>
> >> IMO it's better to pair a protocol spec with an implementation.
> >
> >
> > --
> > --
> > Gavin Andresen
>
--047d7b86db8acbc468050e070668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If you decide to implement this in an existing or new bitc=
oinj based wallet, then I'm happy to give you pointers on how to do it.=
Making one-off, cross platform app specific wallets is pretty easy these d=
ays. For 2-of-3 dispute mediation transactions they'd start out being k=
ind of specialist so asking people to move money from their general spendin=
g wallet into dispute mediation app isn't unthinkable. Eventually gener=
al purpose wallets would integrate protocol, UI ideas and maybe code.<div><=
br></div><div>At least, that's how I'd do it.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Feb 1, 2015 at 12:0=
2 AM, Martin Habov=C5=A1tiak <span dir=3D"ltr"><<a href=3D"mailto:martin=
.habovstiak@gmail.com" target=3D"_blank">martin.habovstiak@gmail.com</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">I didn't consider tha=
t, thank you for feedback! I will try to find<br>
some time for implementing it. I'll write again then.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
2015-01-31 23:50 GMT+02:00 Gavin Andresen <<a href=3D"mailto:gavinandres=
en@gmail.com">gavinandresen@gmail.com</a>>:<br>
> I agree- standards should be descriptive ("here is how this thing=
I did<br>
> works") and NOT proscriptive ("here's what I think will =
work, lets all try<br>
> to do it this way.").<br>
><br>
><br>
> On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn <<a href=3D"mailto:mike=
@plan99.net">mike@plan99.net</a>> wrote:<br>
>>><br>
>>> I could look at implementing it someday, but now I'd like =
to receive<br>
>>> feedback from community.<br>
>><br>
>><br>
>> IMO it's better to pair a protocol spec with an implementation=
.<br>
><br>
><br>
> --<br>
> --<br>
> Gavin Andresen<br>
</div></div></blockquote></div><br></div>
--047d7b86db8acbc468050e070668--
|
