Content-Type: text/plain;
	charset=gb2312
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <201709302323.33004.luke@dashjr.org>
Date: Sat, 30 Sep 2017 16:51:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <921EB5CF-B472-4BD6-9493-1A681586FB51@friedenbach.org>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
	<201709302323.33004.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call semantics
	for generalized MAST
Precedence: list

10s of seconds if no further restrictions are placed. It would be trivial to=
 include a new per input rule that reduces it to ~1s without cutting off any=
 non-attack script (require sigops per input to be limited to witness/sig si=
ze). secp256k1 is now fast enough that we don=A1=AFt need a separate sigop l=
imit.

> On Sep 30, 2017, at 4:23 PM, Luke Dashjr <luke@dashjr.org> wrote:
>=20
> On Thursday 07 September 2017 12:38:55 AM Mark Friedenbach via bitcoin-dev=
=20
> wrote:
>> Tail-call execution semantics
>> BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
>> Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics
>=20
> Just noticed this doesn't count sigops toward the block sigop limit.
> Is that really safe? How long would it take, to verify a malicious block w=
ith=20
> only inputs such that there is nearly 4 MB of sigops?
>=20
> (I do already understand the difficulty in supporting the sigop limit.)
>=20
> Luke