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
|
Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A06F5B7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 16:43:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com
[209.85.217.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31F1216D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 16:43:53 +0000 (UTC)
Received: by mail-ua0-f173.google.com with SMTP id e28so62846211uah.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 09:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=p5pXEz1iRnQssug0jScRb1eKmjnTnNohBilvlWOSIWs=;
b=KPCpJWo7jHxp6RIwDjcHUJfelBUTFVxgvZ4gvzSVc2BEJfOy4pCZBLoTqJ8jA3+j7B
0199nQCV91JCQxwy1aXZdTFL9L4W3z2hmeJeaGVYPbdUX+/PTm4zrKbOVibK8g1RT/Or
N4hg7QA5t/5J+lkEr+jLTE8N2ZipUs21sV06f8tmPAAQ6Cbvg3MPTgcUCZGBXZEUKrdM
NEDuYH2UWhirDqzBsgV2H+W7JodfBUqlTuI64WdBV2X0VJVF7SygObZTgYmok4zSxdVu
BeRnFztkVzAtqdMLvPLXqP59ZdQ7Va7U1FCo7wa08eIc9ScYXpZwbVnY3mV1FucZHbaj
7XRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=p5pXEz1iRnQssug0jScRb1eKmjnTnNohBilvlWOSIWs=;
b=sFcBfBG9nzbNNti8G5fIC868EW8299KKWoNP0DmjqLoP4FNAr/zHmY6QwzKp5cYUCX
lsRdTPsYA51sDY8Fcf3a0fD9ox27lMgMsHhzLlghfper99j+cnhlHUDaUcU11fB1PJIc
bbHgHHO78577WytpQQ2Gh6qLa1skJa31ELRkLA1H3AC64T4NLOK+nlCheJ0kqO1x3dQV
VwfSjCb9vE1/iXNyaIRElrrmDu4dhZFY0T7y8Fi6I5CNAUynrV2s9pdJqe5lf/4nfDZq
a2x+d2j/T7+MgOfbVyAN6H05Pe7PsD1GIFw2EPWvYdiaFcSM4pnhChUWped8XJR78UYF
USMQ==
X-Gm-Message-State: AODbwcBaViU5Fdkn668BJNQKwU4AZV564JgkW4dYQ6hUySV96s6qtc63
71tN4KgDeOQn39Mrkn+sMHsc3bGlSg==
X-Received: by 10.176.1.146 with SMTP id 18mr12449128ual.128.1495471432330;
Mon, 22 May 2017 09:43:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.204 with HTTP; Mon, 22 May 2017 09:43:11 -0700 (PDT)
In-Reply-To: <20170522161404.GA18885@fedora-23-dvm>
References: <CAK9dXBSg+wzAZw7_xPXRVvx1uZzjAEE8nuvj0vkdSGD-yTfwhQ@mail.gmail.com>
<20170522140919.GA17878@fedora-23-dvm>
<CAEM=y+XbHsCQ__u-oVqp8AjWoR29G45ZRDRDdFAMYJhqtRN0Pg@mail.gmail.com>
<20170522161404.GA18885@fedora-23-dvm>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Mon, 22 May 2017 12:43:11 -0400
Message-ID: <CAEM=y+W5iPLkK3yXnGHG+EhMeL9D2K57kB418nHVD5ihRKKP0A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A proposal to reintroduce the disabled script
opcodes
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: Mon, 22 May 2017 16:43:53 -0000
My OP_CAT usecase only needs to glue together hash outputs, so two 32
Bytes inputs generating a 64 Byte output. However increasing this
would enable additional space savings. I would push for an OP_CAT
which can generate an output of no greater than 512 Bytes. Is there
are maximum byte vectors size for script?
The ideal instruction for this usecase be an instruction that pops N
vectors of the stack, concatenates them together and hashes them.
OP_CATHASH256(N) --> OP_HASH256(v1||v2||..||vN)
where || denotes concatenation. You could do this in a streaming
fashion so that memory usage would never exceed 32 Bytes regardless of
the size of the input vectors.
However I recognize that OP_CAT is more generally useful and it
already in scripts but just disabled.
On Mon, May 22, 2017 at 12:14 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote:
>> >It'd help your case if you gave us some examples of such scripts being
>> used.
>>
>> I want OP_CAT so that I can securely and compactly verify many hashes and
>> hash preimages. This would shrink offchain Tumblebit transactions
>> significantly.
>>
>> For instance if I want a transaction TxA which checks that a transaction
>> TxB releases preimages x1,x2,...,x10 such that
>> y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check
>> that the preimahes hash correctly. With OP_CAT I would only have to store
>> one hash in TxA, yhash
>>
>> ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10)
>>
>> TxA could then just hash all the preimages supplied by TxB and confirm they
>> hash to TxA. This would reduce the size of TxA from approx 10*32B to
>> 32+10*16B. I have a version which improves this further but it is more
>> complex.
>>
>> Most of the math OP codes aren't particularly helpful due to their 32bit
>> nature and their strange overflow behavior.
>
> Great! That's exactly the type of justifying use-case we need for a BIP.
>
> An OP_CAT will have to have limits on maximum output size; how big an output
> does your application need?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
|
