summaryrefslogtreecommitdiff
path: root/62/9fac743a8c5485d30cd6818245d53dab4a0d5c
blob: fe5bf5865b0093de2e48162bb25b7ef99a8fcedb (plain)
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
Return-Path: <nathan.cook@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F338A7AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Oct 2016 02:15:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78971134
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Oct 2016 02:15:58 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id p138so245706924wmb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 04 Oct 2016 19:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=/wc+9Ij4vMJmEzDUhmag6T3TjydkD/OZhGM1Xnkw96g=;
	b=tlHeRXoT8HHw/e0luYxde/yQeR8MNR3lA1L7QWVN5DM5oq/nB1tYjs5vP//bU3WOLa
	39GEZ9KI7Ao+wEn0ou3nln6CcAqFlM25l9kjnmuya0tOHE5eKKIAleuBYKj3nQ9iuaXg
	okCcTA+HoAOKzddW6RX4xgpjA06zQYmWOiFBtaqN/hWdIimNdt4qKpqi8IImiqsqFYZQ
	NdSS8vonq6W3A3KfukknleYTM3P7yQrdipEg/voaAg4EErzrYvILwdCB/8N0PytkGXto
	VDPEONy9xWw2H4kSC+nsYw5kj3XZ+/6wGfrj5fVm9XNY8DrqsDoClVxhISLxgOpf9PXR
	Vy0A==
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:from:date
	:message-id:subject:to;
	bh=/wc+9Ij4vMJmEzDUhmag6T3TjydkD/OZhGM1Xnkw96g=;
	b=D2YgPvgSf09qph9I2LgeqTKG1JMA1RNkSGTLkA6q/DmeKEc4peZdLOfDOt4CvIQ8sT
	Hnzp1DPu2C9VU30CFtSajaP7UlFJ2vRN1DxghjaefNFWMSBojliYl+2f7BD/AmgRVooM
	oNtp/5ubNFOetqLb6MAzvYZP3cXmDM8lgExuhozfqp03ffO0N7yO1oArxJUJft/5U9+C
	yrT3J6MV801mrlB6iZYHmSGMbVSiW6W7r1LMpW16l/u/WHdP3p2O9EZLcv/rlJ4SdMiS
	ED3Yc8uIc1IEOAPRCwQucm0j0Pd0EguWyJEThrCRenMc3XYeJazwt1w8/KznjZVKVrXF
	ldew==
X-Gm-Message-State: AA6/9RkkNDlOQmMYZSAVh6QR1f0vKc80LqHWKyF7NXObqNa4iS/9RXrWrjDFbb5zvnyD5QaWVrcWsE5sZFjbwg==
X-Received: by 10.28.65.10 with SMTP id o10mr5065503wma.99.1475633757144; Tue,
	04 Oct 2016 19:15:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.236.2 with HTTP; Tue, 4 Oct 2016 19:15:36 -0700 (PDT)
In-Reply-To: <201610010502.09524.luke@dashjr.org>
References: <201609230957.03138.luke@dashjr.org>
	<87oa34d8fz.fsf@rustcorp.com.au>
	<201610010502.09524.luke@dashjr.org>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Wed, 5 Oct 2016 05:15:36 +0300
Message-ID: <CAGNXQMRfCwCcMZavXs87K_cRNjL1_DU3q4Vu-F3w92ncd-Neag@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1148e8cae9d1eb053e14c152
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 05 Oct 2016 02:17:36 +0000
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 02:15:59 -0000

--001a1148e8cae9d1eb053e14c152
Content-Type: text/plain; charset=UTF-8

On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
>
> > - Otherwise <bits> of hash is compared to lower <bits> of blockhash.
>
> Lower in what endian? Why only that endian? Why only lower? I can see a
> possible use case where one wants to look at only the high bits to ensure
> their transaction is only valid in a block with at least a certain
> difficulty...


Why not use segwit versioning for all this stuff? That lets you re-enable
the bitwise operations like OP_AND, permitting arbitrary bit-masks.
Further, the "at least a certain difficulty" problem suggests a solution by
extending the validity of opcodes like OP_LESSTHAN etc. to 256-bit inputs.

--001a1148e8cae9d1eb053e14c152
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On Saturday=
, October 01, 2016 4:01:04 AM Rusty Russell wrote:<br></span><span class=3D=
"gmail-"><br>
&gt; - Otherwise &lt;bits&gt; of hash is compared to lower &lt;bits&gt; of =
blockhash.<br>
<br>
</span>Lower in what endian? Why only that endian? Why only lower? I can se=
e a<br>
possible use case where one wants to look at only the high bits to ensure<b=
r>
their transaction is only valid in a block with at least a certain<br>
difficulty...</blockquote><div><br></div><div>Why not use segwit versioning=
 for all this stuff? That lets you re-enable the bitwise operations like OP=
_AND, permitting arbitrary bit-masks. Further, the &quot;at least a certain=
 difficulty&quot; problem suggests a solution by extending the validity of =
opcodes like OP_LESSTHAN etc. to 256-bit inputs.</div></div></div></div>

--001a1148e8cae9d1eb053e14c152--