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
|
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 <etotheipi@gmail.com>) id 1XYSbR-0001ME-LV
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Sep 2014 04:30:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.42 as permitted sender)
client-ip=209.85.192.42; envelope-from=etotheipi@gmail.com;
helo=mail-qg0-f42.google.com;
Received: from mail-qg0-f42.google.com ([209.85.192.42])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XYSbQ-0001EA-UL
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Sep 2014 04:30:25 +0000
Received: by mail-qg0-f42.google.com with SMTP id z60so10079444qgd.15
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Sep 2014 21:30:19 -0700 (PDT)
X-Received: by 10.140.40.84 with SMTP id w78mr6696265qgw.87.1411965019421;
Sun, 28 Sep 2014 21:30:19 -0700 (PDT)
Received: from [192.168.1.9] (c-69-143-221-64.hsd1.md.comcast.net.
[69.143.221.64])
by mx.google.com with ESMTPSA id l5sm10467806qai.20.2014.09.28.21.30.18
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 28 Sep 2014 21:30:18 -0700 (PDT)
Message-ID: <5428E053.7070601@gmail.com>
Date: Mon, 29 Sep 2014 00:30:11 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com> <20140618001503.GA8360@savin> <CABsx9T2O42pER0b1v9oeU14_K=KVWVqHzcfFmWAhSxoYAn12vg@mail.gmail.com> <20140619100909.GA3544@savin> <CABsx9T1uC9sMzbPJa4MGpBNoQ4S255Tfo66+wwCoND_bQtvT7Q@mail.gmail.com>
<20140929023553.GA11877@savin.petertodd.org>
In-Reply-To: <20140929023553.GA11877@savin.petertodd.org>
Content-Type: text/plain; charset=windows-1252
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
(etotheipi[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: 1XYSbQ-0001EA-UL
Subject: Re: [Bitcoin-development] New opcodes and transaction version
numbers (was 'relax the IsStandard rules for P2SH transactions')
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, 29 Sep 2014 04:30:26 -0000
On 09/28/2014 10:35 PM, Peter Todd wrote:
> This can be solved by upgrading the address format at
> the same time to let senders know they must send the funds in a
> transaction with an increased version number, but obviously needing new=
> addresses for every new opcode defeats the purpose of P2SH.
Can't this be solved with a single update to the address format,
allowing a tx version number to be part of the address serialization?=20
Then the sending software will apply that version to the payment tx. =20
Of course, I'm not sure if allowing nodes to create transactions with
version numbers outside of their programming is safe. It seems like it
should be since we're talking about soft forks anyway, but there's
probably some subtleties I'm overlooking.
|
