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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <snow.paul@gmail.com>) id 1Y2rJE-00086d-Ri
for bitcoin-development@lists.sourceforge.net;
Mon, 22 Dec 2014 00:57:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.172 as permitted sender)
client-ip=209.85.217.172; envelope-from=snow.paul@gmail.com;
helo=mail-lb0-f172.google.com;
Received: from mail-lb0-f172.google.com ([209.85.217.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y2rJC-0006pP-G4
for bitcoin-development@lists.sourceforge.net;
Mon, 22 Dec 2014 00:57:16 +0000
Received: by mail-lb0-f172.google.com with SMTP id u10so3209625lbd.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Dec 2014 16:57:08 -0800 (PST)
X-Received: by 10.112.150.102 with SMTP id uh6mr7818458lbb.66.1419209828152;
Sun, 21 Dec 2014 16:57:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 16:56:28 -0800 (PST)
In-Reply-To: <20141221185126.GC18711@savin.petertodd.org>
References: <CALqxMTFK_sxdFjVi0qAC0JMdXa=tVBBNp0VrveRUfwa3b1UYhw@mail.gmail.com>
<20141221185126.GC18711@savin.petertodd.org>
From: paul snow <snow.paul@gmail.com>
Date: Sun, 21 Dec 2014 18:56:28 -0600
Message-ID: <CAMU7uiu_wmsZRf6tXdE--rXLb6DSwJHs2YnspQ-cCoN_dw62JA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7b34318aab3e0d050ac38988
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
(snow.paul[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Y2rJC-0006pP-G4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] one-show signatures (Re: The relationship
between Proof-of-Publication and Anti-Replay Oracles)
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: Mon, 22 Dec 2014 00:57:17 -0000
--047d7b34318aab3e0d050ac38988
Content-Type: text/plain; charset=UTF-8
On Sun, Dec 21, 2014 at 12:51 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sun, Dec 21, 2014 at 06:10:47PM +0000, Adam Back wrote:
> > Yes you could for example define a new rule that two signatures
> > (double-spend) authorises something - eg miners to take funds. (And
> > this would work with existing ECDSA addresses & unrestricted R-value
> > choices).
> >
> > I wasnt really making a point other than an aside that it maybe is
> > sort-of possible to do with math what you said was not possible where
> > you said "This [preventing signing more than one message] is
> > impossible to implement with math alone".
>
> Introducing a bunch of clever ECDSA math doesn't change the fact that
> the clever math isn't what is preventing double-spending, clever
> economics is. Just like Bitcoin itself.
>
> No sense getting people potentially confused by a bunch of complex
> equations that aren't relevant to the more fundemental and much more
> important principle that math alone can't prevent double-spending.
Math alone describes all of Bitcoin's structure; as math is a way to model
reality, it has no limits. Saying Math can't prevent double-spending is
near equivalent to saying it cannot be done.
--047d7b34318aab3e0d050ac38988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 21, 2014 at 12:51 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Dec 21, 2014 at 0=
6:10:47PM +0000, Adam Back wrote:<br>
> Yes you could for example define a new rule that two signatures<br>
> (double-spend) authorises something - eg miners to take funds. (And<br=
>
> this would work with existing ECDSA addresses & unrestricted R-val=
ue<br>
> choices).<br>
><br>
> I wasnt really making a point other than an aside that it maybe is<br>
> sort-of possible to do with math what you said was not possible where<=
br>
> you said "This [preventing signing more than one message] is<br>
> impossible to implement with math alone".<br>
<br>
</span>Introducing a bunch of clever ECDSA math doesn't change the fact=
that<br>
the clever math isn't what is preventing double-spending, clever<br>
economics is. Just like Bitcoin itself.<br>
<br>
No sense getting people potentially confused by a bunch of complex<br>
equations that aren't relevant to the more fundemental and much more<br=
>
important principle that math alone can't prevent double-spending.</blo=
ckquote><div><br></div><div>Math alone describes all of Bitcoin's struc=
ture; as math is a way to model reality, it has no limits. Saying Math can&=
#39;t prevent double-spending is near equivalent to saying it cannot be don=
e. =C2=A0</div></div></div></div>
--047d7b34318aab3e0d050ac38988--
|
