From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A06F5B7F for ; 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 ; Mon, 22 May 2017 16:43:53 +0000 (UTC) Received: by mail-ua0-f173.google.com with SMTP id e28so62846211uah.0 for ; 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: <20170522140919.GA17878@fedora-23-dvm> <20170522161404.GA18885@fedora-23-dvm> From: Ethan Heilman Date: Mon, 22 May 2017 12:43:11 -0400 Message-ID: To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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