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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YsKhK-0001Xu-CS
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 00:38:54 +0000
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsKhG-0003x8-TU
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 00:38:54 +0000
Received: by wicnf17 with SMTP id nf17so36204150wic.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 May 2015 17:38:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=qu5RIskK7nIcO/u4ySRvldwC9oY1PE5TUvzFba9l9As=;
b=RpH88NY5o1XUAA8E4oqMbmxZCqcazIC1thF4BB9xhT3LRErs+W6hQ+Y4carcamkaR/
8xmjul2jT6X0TLT0BfpZtoZJcWp6VibGIQdula+paN2A1HlwGfQ7Xls0rOslXa0I/7cF
F+iS2LMSvRwdRt2AW53R9Jqi5Vnh/59EnmxcJSVPVdDV12YGG5ZiFh52sgK7R4aItlKW
C/CGpFmbTiBbKawIEYXxjpZGM9mUB2Ol4gbAXGTKnCgcWsMe5WeNS7+QdIL01FhgF4/h
i3kvx748ibDenld9UWso9CiMVrc2hUv3YAbg6BdoXWdxMAfRcy3vZreOwxZuhjSQZsoL
q0UA==
X-Gm-Message-State: ALoCoQkdckuvyXatwVnIDMT4biHh8uyVM8iw57LshTAk6+IhEyVoBUduVrv1uNi1ncqrqqBf0c87
MIME-Version: 1.0
X-Received: by 10.180.188.193 with SMTP id gc1mr34004105wic.7.1431477524868;
Tue, 12 May 2015 17:38:44 -0700 (PDT)
Received: by 10.194.100.38 with HTTP; Tue, 12 May 2015 17:38:44 -0700 (PDT)
In-Reply-To: <20150512210125.GA5902@muck>
References: <20150504050715.GA18856@savin.petertodd.org>
<CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com>
<CADJgMzv1NdoXKDScQ1+OycijzME=W2YSut3GMF=EEuKQf6VeUg@mail.gmail.com>
<201505122038.28831.luke@dashjr.org> <20150512210125.GA5902@muck>
Date: Wed, 13 May 2015 02:38:44 +0200
Message-ID: <CABm2gDrMUJq8RiXw5U0gNnfJEzXG4pNxk5eOw=L7NUtcpj3sPg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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: 1YsKhG-0003x8-TU
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
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, 13 May 2015 00:38:54 -0000
I like the reuse with negative numbers more than the current proposal
because it doesn't imply bigger scripts. If all problems that may
arise can be solved, that is.
If we went that route, we would start with the initial CLTV too.
But I don't see many strong arguments in favor of using the current
trick later when we're actually running out of opcodes, just that
"CLTV and RCLTV/op_maturity are semantically related". How
semantically related depends on the final form of RCLTV/op_maturity,
but I don't think anybody wants to block CLTV until RCLTV is ready.
So we could just deploy the initial CLTV (#6124) now and then decide
whether we want to reuse it with negatives for RCLTV or if we use an
independent op.
Can the people that don't like that plan give stronger arguments in
favor of the parametrized version?
I've missed IRC conversations, so I may be missing something...
On Tue, May 12, 2015 at 11:01 PM, Peter Todd <pete@petertodd.org> wrote:
> On Tue, May 12, 2015 at 08:38:27PM +0000, Luke Dashjr wrote:
>> It should actually be straightforward to softfork RCLTV in as a negative CLTV.
>> All nLockTime are >= any negative number, so a negative number makes CLTV a
>> no-op always. Therefore, it is clean to define negative numbers as relative
>> later. It's also somewhat obvious to developers, since negative numbers often
>> imply an offset (eg, negative list indices in Python).
>
> Doing this makes handling the year 2038 problem a good deal more
> complex.
>
> The CLTV codebase specifically fails on negative arguments to avoid any
> ambiguity or implementation differences here.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
