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; 
MIME-Version: 1.0
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Message Signing based authentication
Precedence: list

--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">&lt;<a href=3D"mailto:luke@das=
hjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</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>
&gt; This was one of my concerns when implementing a scheme where you sign =
a<br>
&gt; refund transaction before the original transaction is broadcast. =A0I<=
br>
&gt; originally tried to pass a hash and have the server sign it. =A0Howeve=
r, I<br>
&gt; had no way to know that what I was signing wasn&#39;t a transaction th=
at was<br>
&gt; spending my coins! =A0So I changed the code to require sending the ful=
l<br>
&gt; transaction, not just the hash. =A0The other way to mitigate this is t=
hrough<br>
&gt; not having any unspent outputs from this key.<br>
<br>
</div>Well, there&#39;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&#39;t exactly s=
top<br>
someone from sending to an &quot;identity&quot; address.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>

--047d7b624e2aa2761004ea3b981a--