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 1BC122391 for ; Mon, 8 Jul 2019 10:25:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2244487C for ; Mon, 8 Jul 2019 10:25:04 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 1E6EA260051D; Mon, 8 Jul 2019 10:25:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1562581503; bh=AE5Lvr3wltK5jyaOipdS8XGsLIBYR2zpa6S55QmLWdU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=g31UOaP9uaccJad4dOCSKzmaNMpjcmSd0VqEvZx22+V3N4Tu8hQO3oddjnfXdq4jM W/RZwnuCFqNNWfssV+ppbAAxODpyuZtHhmiqc2Tr2kmxLvcsb+AUmKBLVWljUyQ6QT nVApNlyv5PK3XADJInD9wNPi5WKHCObY+FbeZ/40= Date: Mon, 8 Jul 2019 15:26:24 +0500 From: Dmitry Petukhov To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20190708152624.39c33985@simplexum.com> In-Reply-To: References: <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> <20190620220552.metrqaul3iporwma@erisian.com.au> Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 09 Jul 2019 06:03:36 +0000 Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) 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, 08 Jul 2019 10:25:06 -0000 If you make ANYPREVOUTANYSCRIPT signature not the only signature that controls this UTXO, but use it solely for restricting the spending conditions such as the set of outputs, and require another signature that would commit to the whole transaction, you can eliminate malleability, for the price of additional signature, of course. CHECKSIG

CHECKSIG (CHECKMULTISIG/CHECKSIGADD might be used instead) where control-P can even be a pubkey of a key that is publicly known, and the whole purpose of control-sig would be to restrict the outputs (control-sig would be created with flags meaning ANYPREVOUTANYSCRIPT). Because control-sig does not depend on the script and on the current input, there should be no circular dependency, and it can be part of the redeem script. P would be the pubkey of the actual key that is needed to spend this UTXO, and the signature of P can commit to all the inputs and outputs, preventing malleability. I would like to add that it may make sense to just have 2 additional flags for sighash: NOPREVOUT and NOSCRIPT. NOPREVOUT would mean that previous output is not committed to, and when combined with ANYONECANPAY, this will mean ANYPREVOUT/NOINPUT: ANYONECANPAY means exclude all inputs except the current, and NOPREVOUT means exclude the current input. Thus NOPREVOUT|ANYONECANPAY =3D NOINPUT With NOPREVOUT|ANYONECANPAY|NOSCRIPT you would have ANYPREVOUTANYSCRIPT with NOPREVOUT|NOSCRIPT you can commit to "all the inputs beside the current one", which would allow to create a spending restriction like "this UTXO, and also one (or more) other UTXO", which might be useful to retroactively revoke or transfer the rights to spend certain UTXO without actually moving it: think 'vault' UTXO that is controlled by Alice, but requires additional 'control' UTXO to spend. Alice have keys for both 'vault' UTXO, and 'control' UTXO, but Bob have only key for 'control' UTXO. If Bob learnsthat Alice's vault UTXO key is at risk of compromize, he spends the control UTXO, and then Alice's ability to spend vault UTXO vanishes. You can use this mechanism to transfer this right to spend if you prepare a number of taproot branches with different pairs of (vault, control) keys and a chain of transactions that each spend the previous control UTXO such that the newly created UTXO becomes controlled by the control key of the next pair, together with vault key in that pair. =D0=92 Sat, 22 Jun 2019 23:43:22 -0700 Jeremy via bitcoin-dev wrote: > This is insufficient: sequences must be committed to because they > affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN > too. >=20 > Any malleability makes this much less useful. > -- > @JeremyRubin > >=20 >=20 > On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >=20 > > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: =20 > > > So with regards to OP_SECURETHEBAG, I am also "not really seeing > > > any =20 > > reason to =20 > > > complicate the spec to ensure the digest is precommitted as part > > > of the opcode." =20 > > > > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT > > (NOINPUT) sighash (Johnson Lau's mentioned this before, but not > > sure if it's been spelled out anywhere); ie instead of constructing > > > > X =3D Hash_BagHash( version, locktime, [outputs], [sequences], > > num_in ) > > > > and having the script be " OP_SECURETHEBAG" you calculate an > > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL: > > > > Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0, > > amount, sequence) > > > > and calculate a signature sig =3D Schnorr(P,m) for some pubkey P, and > > make your script be "

CHECKSIG". > > > > That loses the ability to commit to the number of inputs or restrict > > the nsequence of other inputs, and requires a bigger script (sig > > and P are ~96 bytes instead of X's 32 bytes), but is otherwise > > pretty much the same as far as I can tell. Both scripts are > > automatically satisfied when revealed (with the correct set of > > outputs), and don't need any additional witness data. > > > > If you wanted to construct "X" via script instead of hardcoding a > > value because it got you generalised covenants or whatever; I think > > you could get the same effect with CAT,LEFT, and RIGHT: you'd > > construct Y in much the same way you construct X, but you'd then > > need to turn that into a signature. You could do so by using pubkey > > P=3DG and nonce R=3DG, which means you need to calculate > > s=3D1+hash(G,G,Y)*1 -- calculating the hash part is easy, multiplying > > it by 1 is easy, and to add 1 you can probably do something along > > the lines of: > > > > OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT > > > > (ie, take the last 4 bytes, increment it using 4-byte arithmetic, > > then cat the first 28 bytes and the result. There's overflow issues, > > but I think they can be worked around either by allowing you to > > choose different locktimes, or by more complicated script) > > > > Cheers, > > aj > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > =20