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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allen.piscitello@gmail.com>) id 1VcmMB-0004eS-VQ
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 01:20:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.170 as permitted sender)
client-ip=74.125.82.170;
envelope-from=allen.piscitello@gmail.com;
helo=mail-we0-f170.google.com;
Received: from mail-we0-f170.google.com ([74.125.82.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VcmM9-0004Yp-PZ
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 01:19:59 +0000
Received: by mail-we0-f170.google.com with SMTP id u57so858138wes.15
for <bitcoin-development@lists.sourceforge.net>;
Sat, 02 Nov 2013 18:19:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.198.5 with SMTP id iy5mr7184598wic.45.1383441591594;
Sat, 02 Nov 2013 18:19:51 -0700 (PDT)
Received: by 10.194.85.112 with HTTP; Sat, 2 Nov 2013 18:19:51 -0700 (PDT)
In-Reply-To: <201311030033.56983.luke@dashjr.org>
References: <20131102050144.5850@gmx.com> <527573DA.7010203@monetize.io>
<CAJfRnm6Jbm+6__zgvodAroDWRugyX_4atHH1k4+U9_1-GLThjw@mail.gmail.com>
<201311030033.56983.luke@dashjr.org>
Date: Sat, 2 Nov 2013 20:19:51 -0500
Message-ID: <CAJfRnm6eRRF1ZxRJ89enPNkaG3-BNyboP9DujmuBgQxNhdhU8g@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7b624e2aa2761004ea3b981a
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
(allen.piscitello[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: dashjr.org]
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: 1VcmM9-0004Yp-PZ
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Message Signing based authentication
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, 03 Nov 2013 01:20:00 -0000
--047d7b624e2aa2761004ea3b981a
Content-Type: text/plain; charset=ISO-8859-1
I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
It was either that or making sure I had no unspent outputs. The use case
of doing it was laziness in just creating a single key.
On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> > This was one of my concerns when implementing a scheme where you sign a
> > refund transaction before the original transaction is broadcast. I
> > originally tried to pass a hash and have the server sign it. However, I
> > had no way to know that what I was signing wasn't a transaction that was
> > spending my coins! So I changed the code to require sending the full
> > transaction, not just the hash. The other way to mitigate this is
> through
> > not having any unspent outputs from this key.
>
> Well, there's no use case to sign with an address that has already been
> sent
> coins. The main problem with enforcing this is that you can't exactly stop
> someone from sending to an "identity" address.
>
> Luke
>
--047d7b624e2aa2761004ea3b981a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I actually had a use case in my case where it was possible=
, and that was the check I used to get around it, just configured it so tha=
t I always generated a new key when I needed to set up a 2 of 2 Multisig Re=
fund Tx. =A0It was either that or making sure I had no unspent outputs. =A0=
The use case of doing it was laziness in just creating a single key.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Nov 2=
, 2013 at 7:33 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke@das=
hjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im">On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello=
wrote:<br>
> This was one of my concerns when implementing a scheme where you sign =
a<br>
> refund transaction before the original transaction is broadcast. =A0I<=
br>
> originally tried to pass a hash and have the server sign it. =A0Howeve=
r, I<br>
> had no way to know that what I was signing wasn't a transaction th=
at was<br>
> spending my coins! =A0So I changed the code to require sending the ful=
l<br>
> transaction, not just the hash. =A0The other way to mitigate this is t=
hrough<br>
> not having any unspent outputs from this key.<br>
<br>
</div>Well, there's no use case to sign with an address that has alread=
y been sent<br>
coins. The main problem with enforcing this is that you can't exactly s=
top<br>
someone from sending to an "identity" address.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>
--047d7b624e2aa2761004ea3b981a--
|
