blob: 05bc64cd7782c339461c7bae631061406207b90b (
plain)
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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Vcldm-0004Ud-UI
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 00:34:06 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([192.3.11.21])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Vcldk-0000ET-Uq for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 00:34:06 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:222:4dff:fe50:4c49])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 589B51080838;
Sun, 3 Nov 2013 00:34:04 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sun, 3 Nov 2013 00:33:55 +0000
User-Agent: KMail/1.13.7 (Linux/3.10.15-gentoo; KDE/4.10.5; x86_64; ; )
References: <20131102050144.5850@gmx.com> <527573DA.7010203@monetize.io>
<CAJfRnm6Jbm+6__zgvodAroDWRugyX_4atHH1k4+U9_1-GLThjw@mail.gmail.com>
In-Reply-To: <CAJfRnm6Jbm+6__zgvodAroDWRugyX_4atHH1k4+U9_1-GLThjw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201311030033.56983.luke@dashjr.org>
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Vcldk-0000ET-Uq
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 00:34:07 -0000
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
|
