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 9897CF74 for ; Mon, 5 Mar 2018 15:28:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04D505D7 for ; Mon, 5 Mar 2018 15:28:31 +0000 (UTC) Received: from [172.29.7.32] (38.140.120.98 [38.140.120.98]) by mx.zohomail.com with SMTPS id 1520263701974334.11387568882833; Mon, 5 Mar 2018 07:28:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Johnson Lau In-Reply-To: <87608btgyd.fsf@rustcorp.com.au> Date: Mon, 5 Mar 2018 10:28:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9A9BCC75-F116-4382-B4DE-2E69E79C1DDB@xbt.hk> References: <87608btgyd.fsf@rustcorp.com.au> To: Rusty Russell , bitcoin-dev , Mark Friedenbach X-Mailer: Apple Mail (2.3445.5.20) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: 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: Mon, 05 Mar 2018 15:28:32 -0000 Altstack in v0 P2WSH should be left untouched. If anyone is already = using altstack, BIP117 would very likely confiscate those UTXOs because = the altstack would unlikely be executable. Even in v1 witness, I think altstack should remain be a temporary data = storage. The =E2=80=9C(many scripts) concatinated together in reverse order to = form a serialized script=E2=80=9D in BIP117 is exactly the same security = hole of Satoshi=E2=80=99s scriptSig + OP_CODESAPARATOR + scriptPubKey . = That means it is possible to skip execution of scriptPubKey by using a = scriptSig with an invalid push operation, so the whole concatenated = script becomes a simple push. For SigOp limit, I think it=E2=80=99d become more and more difficult to = maintain the current statical analyzability model as we try to introduce = more functions. I think we should just migrate to a model of limiting = sigop per weight, and count the actual number of sigop during execution. = ( = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/0157= 64.html ) Actually, this approach is cheaper to analyse, as you only = need to look at the witness size, and don=E2=80=99t need to look at the = script at all. > On 9 Jan 2018, at 6:22 AM, Rusty Russell via bitcoin-dev = 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev