Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE198102A for ; Tue, 9 Jan 2018 12:40:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 659D1A3 for ; Tue, 9 Jan 2018 12:40:36 +0000 (UTC) Received: by mail-pg0-f50.google.com with SMTP id z20so5621965pgv.6 for ; Tue, 09 Jan 2018 04:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U3bD0coz2LWr7GuQTb9pdDHQpBBYQn8YNn39DIKQejU=; b=P+Pss+Pq0mcf+pncjRr28WZ3BuFcEv86INI/GzxtbxmfidpS6ld4voJFnm9qnvpD9R CQagCHBQMxf/V+kxSivj+o4FewQZzzMGmjuBIw4iPWeqeyidG5wZo9gzOp8XUwh/Eua6 dTWsOfX08VIVGpJ76TQeqlMqZ9knMKXSvqcZMaRNiOv/sqXmroyauVPKM1HIdG23XaR3 zrrrV491QahGX3hWAz1oKRT4rnI1+ZAco3fczLjAXHkXdThaBl0RSLsii8gk6Y9rCMuJ 1Gm9+apeb2JP3bWPHFh8zpBrg5tsXQhwEv/RfWMjH22VtckEWOFfJGN0Xk0yrdrCDj3+ p0eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U3bD0coz2LWr7GuQTb9pdDHQpBBYQn8YNn39DIKQejU=; b=i+KQ++MdxIdk67kOHNbWzYKHvV5TIzKABOd7dJZXgKI4QR8er8YIqCR3FQtJ/YDyJw 0quWgxl1tZV4c+zNpc9ZzdSSlZJE6zXgaog1S4DZmH3wb6LP+aWpPXrzvlFwkDv7Jsbd 523OTTlDZg3SmanwfUoNkxahJglmxSw4QeshIuHh+Rl48T/gydl5/3PPPVdlehkWPbvC z8ZwG4X8TXKg1dSx85246XFOTubFbWeD0f1vkgoPO491LdW3AeWgERv18RryeLOY+zLo BDMJ9JwFYIL3tVqdnbQZvGigC83x1IbG9vmdJhs4aokhhwC9F2pyEcvfHmWAk0L0X7Pl JkPw== X-Gm-Message-State: AKGB3mLtOW6Y0WJvUpMskRkwQ2xGf/jdn+U57j4Hv48f9gjvarZM8yh/ 1RWJilqjY0F9+V9s+CMZ9S9LrA== X-Google-Smtp-Source: ACJfBosIe/qo4go4OD++F2EMpwgRwFvC5TnG9tgk0RL67XGfyC1BTFJBz/QcuguYh6zEUgZVciWm0w== X-Received: by 10.99.126.86 with SMTP id o22mr8261910pgn.364.1515501635920; Tue, 09 Jan 2018 04:40:35 -0800 (PST) Received: from [26.253.30.111] (mf42736d0.tmodns.net. [208.54.39.244]) by smtp.gmail.com with ESMTPSA id g2sm11033347pfh.62.2018.01.09.04.40.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 04:40:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Mark Friedenbach X-Mailer: iPhone Mail (15C153) In-Reply-To: <87608btgyd.fsf@rustcorp.com.au> Date: Tue, 9 Jan 2018 21:40:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87608btgyd.fsf@rustcorp.com.au> To: Rusty Russell X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion , Russell O'Connor , Kalle Alm Subject: Re: [bitcoin-dev] BIP 117 Feedback 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: Tue, 09 Jan 2018 12:40:38 -0000 The use of the alt stack is a hack for segwit script version 0 which has the= clean stack rule. Anticipated future improvements here are to switch to a w= itness script version, and a new segwit output version which supports native= MAST to save an additional 40 or so witness bytes. Either approach would al= low getting rid of the alt stack hack. They are not part of the proposal now= because it is better to do things incrementally, and because we anticipate u= sage of MAST to better inform these less generic changes. Your suggestion of =E2=80=9Csingle blob on the stack=E2=80=9D seems to be ex= actly this proposal afaict? Note the witness data needs to be passed separat= ely because signatures can=E2=80=99t be included in that single blob if that= blob is hashed and compared against something in the scriptPubKey. The sigop and opcode limit drop can be justified with some back of the envel= ope calculations. Non-scriptPubKey scripts are fundamentally limited by bloc= ksize/weight and the most damage you can do, as an adversary, is limited by s= pace. The most expensive thing you can do check a signature. Our assumptions= about block size safety are basically due to how much computation you can s= tuff in a block with checksigs =E2=80=94 all the analysis there applies. My suggestion is to limit the number of checksigs allowed in a script to siz= e(script+witness)/64, but I wanted this to come up in review rather than com= plicate the code right off the bat. I will make a strong assertion: static analyzing the number of opcodes and s= igops gets us absolutely nothing. It is cargo cult safety engineering. No ne= ed to perpetuate it when it is now in the way. Sent from my iPhone > On Jan 9, 2018, at 8:22 PM, Rusty Russell wrote: >=20 > I've just re-read BIP 117, and I'm concerned about its flexibility. It > seems to be doing too much. >=20 > The use of altstack is awkward, and makes me query this entire approach. > I understand that CLEANSTACK painted us into a corner here :( >=20 > The simplest implementation of tail recursion would be a single blob: if > a single element is left on the altstack, pop and execute it. That > seems trivial to specify. The treatment of concatenation seems like > trying to run before we can walk. >=20 > Note that if we restrict this for a specific tx version, we can gain > experience first and get fancier later. >=20 > BIP 117 also drops SIGOP and opcode limits. This requires more > justification, in particular, measurements and bounds on execution > times. If this analysis has been done, I'm not aware of it. >=20 > We could restore statically analyzability by rules like so: > 1. Only applied for tx version 3 segwit txs. > 2. For version 3, top element of stack is counted for limits (perhaps > with discount). > 3. The blob popped off for tail recursion must be identical to that top > element of the stack (ie. the one counted above). >=20 > Again, future tx versions could drop such restrictions. >=20 > Cheers, > Rusty.