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
|
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 1YmLXf-0002Ph-U2
for bitcoin-development@lists.sourceforge.net;
Sun, 26 Apr 2015 12:20:11 +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 1YmLXe-00024e-QA
for bitcoin-development@lists.sourceforge.net;
Sun, 26 Apr 2015 12:20:11 +0000
Received: by wizk4 with SMTP id k4so69662482wiz.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 26 Apr 2015 05:20:04 -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
:content-transfer-encoding;
bh=oIPq6gndlISv/8pEY6dTt8KNk5a6tn86e3Gu2hIupvg=;
b=AaaoN5vmo7gqzWE0eUs+3gceNSFwT8VkYV8cyg0wcRsNmzLg83YEPHG/ThRIUaHreR
GNgCZwQ3J0WtUs/S7fGl3QZv/X3L0IM5pK1TkfEIhl0NeS3CWgSY2qDTEhMidQaA+c+H
aKLUfWQ0pwaYSjfUaOOTNDXjZ4VB2Lpomslwv9WbIsfm/wlvef8Dc5Mbln+rWaIFfJuI
cGZXxg7B5PImxwrP2wqUu0a042gKqainjQEjeBEDUJa0PLYmyI0JOXuWUiydP0sPIGLG
PVU21tOQtr5ZMxJFwr61bupPzFCNWRWjoLU9vskUBmADt5tl3N7uYqzgXwBplEepsB5u
lg+g==
X-Gm-Message-State: ALoCoQmGxO3oEHuiQH8qWhmLBk76Mvqqjq2Jn/xAs4v4oJ1KdMjNbeSAW4oWkcyJG1na8hj07ws3
MIME-Version: 1.0
X-Received: by 10.180.99.166 with SMTP id er6mr12436873wib.58.1430050804626;
Sun, 26 Apr 2015 05:20:04 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Sun, 26 Apr 2015 05:20:04 -0700 (PDT)
In-Reply-To: <CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
<55075795.20904@bluematt.me>
<20150421075912.GA25282@savin.petertodd.org>
<CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com>
Date: Sun, 26 Apr 2015 14:20:04 +0200
Message-ID: <CABm2gDovFzpL_7KFqPXxhu4VohRfcE5S_PLAUgjgo_b84GaYeQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: 1YmLXe-00024e-QA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
proposal)
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: Sun, 26 Apr 2015 12:20:12 -0000
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> There's another possibility that could keep the utxo out of Script verifi=
cation:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nSequence;
> }
>
> could turn into:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nHeight;
> }
>
> And a new softfork rule could enforce that all new CTxIn set nHeight
> to the correct height in which its corresponding prevout got into the
> chain.
> That would remove the need for the TxOutputGetter param in
> bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
> (apart from other ugly implementation details).
Wait, wait, this can be made reorg-safe and more backards compatible.
The new validation rule at the tx validation level (currently in
main::CheckInputs()) would be
for (unsigned int i =3D 0; i < tx.vin.size(); i++) {
// ...
if (tx.vin.nHeight + 100 > tx.nLockTime)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-reorg-unsafe");
if (coins->nHeight > tx.vin.nHeight)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-false");
// ...
}
Existing transactions that have used the deprecated CTxIn::nSequence
for something else will be fine if they've used low nSequences.
The only concern would be breaking some colored coins kernels, but
there's many others implemented that don't rely on CTxIn::nSequence.
Transactions that want to use OP_MATURITY just have to set the
corresponding CTxIn::nHeight and CTransaction::nLockTime properly.
This way op_maturity wouldn't require anything from the utxo and the
final interface could be:
int bitcoinconsensus_verify_script(const unsigned char* scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char* txTo,
unsigned int txToLen,
unsigned int nIn, unsigned int nHei=
ght,
unsigned int flags,
secp256k1_context_t* ctx,
bitcoinconsensus_error* err);
|
