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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1Wx1rz-0007Vo-JO
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 22:28:47 +0000
Received: from mail-pb0-f42.google.com ([209.85.160.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wx1rx-0007tp-Sq
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 22:28:47 +0000
Received: by mail-pb0-f42.google.com with SMTP id ma3so15897pbc.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 17 Jun 2014 15:28:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=afMY9C5qGBbingqVMdD0cxOjiq4K8dnJJ+8MGUh4QE0=;
b=J+3NKH7DbjS4KniHbWI2rI0YA9LZ9n+A9Pr8ew1PteY4XGa/dfExbwTBChEx1G2CkO
dAXNrSahXoF54uG6PGGxzONeV6ASRCJXiAv5064CBkbDU1/Phzf3IMAA7K67wLpYtazF
+w+Bqn8PQompicc7YN4a5cCJHVpJN8tpS/Fok/lLSEzlqVdGiIXdudIMmVFbFicPlNps
6nAb7N9KsIRdS6BeaQFk2JdG9yoBCVRanJo7yd8osjT4KMe+SzZruVSdnkcmC5TrPWwv
uHJIP25rLmr+ziaguCww2t4EPznsoYBCZwHhlrIVFCZXii168uR/UphMW1M6aR6v5bw4
05Fg==
X-Gm-Message-State: ALoCoQk1YWI7bEFwXv4wGX8AW7LENBUqniyJtvoXJyfLU0n8Cg5CfOaubVNalufYMmZ8xWa+qmBm
X-Received: by 10.68.254.70 with SMTP id ag6mr35701146pbd.33.1403044119934;
Tue, 17 Jun 2014 15:28:39 -0700 (PDT)
Received: from [192.168.127.194] (50-0-36-179.dsl.dynamic.sonic.net.
[50.0.36.179]) by mx.google.com with ESMTPSA id
qj3sm25657168pbc.91.2014.06.17.15.28.36
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 17 Jun 2014 15:28:39 -0700 (PDT)
Message-ID: <53A0C114.8050904@monetize.io>
Date: Tue, 17 Jun 2014 15:28:36 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
<d46aec$hdccva@ironport9.mayo.edu>
In-Reply-To: <d46aec$hdccva@ironport9.mayo.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Wx1rx-0007tp-Sq
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant
confirmation guarantees
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: Tue, 17 Jun 2014 22:28:47 -0000
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use. For
example, imagine accidentally loading up the same wallet on two machines
or the wallet software crashing after signing and sending the
transaction, and the user recreates & sends on recovery.
It also invalidates reasonably legitimate use cases for repeating
addresses (in the absence of other solutions), and its not really
possible to prevent people from sending multiple coins to the same
address (which could then be stolen).
On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote:
> Can two signed transactions using the same output as an input (ie, a
> double spend) be used to trigger a third transaction?
>
> It would be nice if I could sign a tx that would pay m bitcoins to an
> arbitrary address if and only if someone could present proof that I
> signed more than 1 transaction using the same output. Thus, a
> merchant could trust that I would not attempt a double spend for a
> purchase of n < m bitcoins.
>
> Can this type of transaction be expressed in Bitcoin's scripting
> language?
>
> Chaum had a similar feature in Digicash way back when...a double
> spend would let the second merchant compute the identity of the
> double spender and serve as proof of double spending. It didn't
> automate punishment though!
>
> My apologies if this has been discussed previously.
>
|
