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
|
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 <gmaxwell@gmail.com>) id 1WGEKN-0003Q8-5u
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 21:05:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.51 as permitted sender)
client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f51.google.com;
Received: from mail-la0-f51.google.com ([209.85.215.51])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGEKM-0005oO-7J
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 21:05:11 +0000
Received: by mail-la0-f51.google.com with SMTP id c6so703046lan.24
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Feb 2014 13:05:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.153.11.129 with SMTP id ei1mr1648885lad.78.1392843903525;
Wed, 19 Feb 2014 13:05:03 -0800 (PST)
Received: by 10.112.189.164 with HTTP; Wed, 19 Feb 2014 13:05:03 -0800 (PST)
In-Reply-To: <ec7ad616-1596-420f-8101-6f1d86429638@email.android.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
<52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org>
<CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
<CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
<EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@mac.com>
<CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
<601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
<ec7ad616-1596-420f-8101-6f1d86429638@email.android.com>
Date: Wed, 19 Feb 2014 13:05:03 -0800
Message-ID: <CAAS2fgSRbsaxDr_w0HL2zGwcQtG96XMaqeE5QXLo3tz0+OydUg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1WGEKM-0005oO-7J
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
malleability
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: Wed, 19 Feb 2014 21:05:11 -0000
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd <pete@petertodd.org> wrote:
> While we might be able to get away with a retroactive change in meaning r=
ight now in the future that won't be so easy. There are lots if proposed ap=
plications for nLockTime-using protocols that depend on transactions (or pa=
rts of transactions) being possible to mine as is. Making existing transact=
ions impossible to mine in the future will break those types of application=
s. We might as well use this as a learning experience for what a version bu=
mp would look like infrastructures wise.
For some reason it took me a couple reads to get this so I thought I'd
restate it in a more blunt form.
There may exist people today who have send funds to addresses,
authored nlocktime releases, and destroyed the key the funds are at
now in order to achieve a timelock. This might be a foolish thing to
do, but it's the kind of thing that you have to worry about when
potentially breaking existing transactions.
(This kind of us is, fwiw, another example of why ANYONE_CAN_PAY is useful)=
.
|
