From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <201311030033.56983.luke@dashjr.org> Date: Sat, 2 Nov 2013 20:19:51 -0500 Message-ID: From: Allen Piscitello To: Luke-Jr 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.


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. =A0I<= br> > originally tried to pass a hash and have the server sign it. =A0Howeve= r, I
> had no way to know that what I was signing wasn't a transaction th= at was
> spending my coins! =A0So I changed the code to require sending the ful= l
> transaction, not just the hash. =A0The other way to mitigate this is t= hrough
> not having any unspent outputs from this key.

Well, there's no use case to sign with an address that has alread= y been sent
coins. The main problem with enforcing this is that you can't exactly s= top
someone from sending to an "identity" address.

Luke

--047d7b624e2aa2761004ea3b981a--