Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E9A7F6C for ; Sun, 1 Oct 2017 17:36:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 1D30FA8 for ; Sun, 1 Oct 2017 17:36:33 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 219A938A0C4E; Sun, 1 Oct 2017 17:36:13 +0000 (UTC) X-Hashcash: 1:25:171001:mail@felixweis.com::ZebJzr=wbHlmI4vt:acP4i X-Hashcash: 1:25:171001:mark@friedenbach.org::uBEXdIpHwrjrf4zv:acOOW X-Hashcash: 1:25:171001:bitcoin-dev@lists.linuxfoundation.org::hE2NLB=sKIqTOoB0:4LT2 From: Luke Dashjr To: Felix Weis Date: Sun, 1 Oct 2017 17:36:05 +0000 User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; ) References: <201710010113.30518.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Message-Id: <201710011736.06471.luke@dashjr.org> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) 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: Sun, 01 Oct 2017 17:36:35 -0000 BIP 115 provides fork-independent opt-in replay protection, which can be us= ed=20 in combination with the new signature condition scripts in this proposal. Perhaps the code can have a flag for new altcoins to easily make it mandato= ry=20 (and we can use it on testnet?). Luke On Sunday 01 October 2017 11:22:30 AM Felix Weis wrote: > Just a simple suggestion since the signature format is changed. Can this = be > designed so that possible future hard forks can simply change 1 constant = in > the code and turn on cross chain replay protection? >=20 > On Sun, Oct 1, 2017 at 1:05 PM Mark Friedenbach via bitcoin-dev < >=20 > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Clean stack should be eliminated for other possible future uses, the mo= st > > obvious of which is recursive tail-call for general computation > > capability. I=E2=80=99m not arguing for that at this time, just arguing= that we > > shouldn=E2=80=99t prematurely cut off an easy implementation of such sh= ould we > > want to. Clean stack must still exist as policy for future soft-fork > > safety, but being a consensus requirement was only to avoid witness > > malleability, which committing to the size of the witness also > > accomplishes. > >=20 > > Committing to the number of witness elements is fully sufficient, and > > using the number of elements avoids problems of not knowing the actual > > size in bytes at the time of signing, e.g. because the witness contains > > a merkle proof generated by another party from an unbalanced tree, and > > unbalanced trees are expected to be common (so that elements can be > > placed higher in the tree in accordance with their higher expected > > probability of usage). Other future extensions might also have > > variable-length proofs. > >=20 > > > On Sep 30, 2017, at 7:47 PM, Luke Dashjr wrote: > > >=20 > > > Should it perhaps commit to the length of the serialised witness data > >=20 > > instead > >=20 > > > or additionally? Now that signatures are no longer variable-length, > >=20 > > that'd be > >=20 > > > possible... > > >=20 > > > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been > >=20 > > checked > >=20 > > > until AFTER the tail-call in the first draft. But I suppose eliminati= ng > >=20 > > it for > >=20 > > > other possible future purposes is still useful. > > >=20 > > > Luke > >=20 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev