Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BC20A86D for ; Sat, 29 Jun 2019 20:25:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A486E2C6 for ; Sat, 29 Jun 2019 20:25:15 +0000 (UTC) Date: Sat, 29 Jun 2019 20:25:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1561839912; bh=DtlBAwMc2eOcwMfYtIM/KOYP1wlwZnqsw0/n4vr1zOg=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=Qgij0NXeTwrU8aBOhYhVn3qi2oMs7LKO75axSsrNtXLD0G4e3Fht8MuT63xAJ4u2q ZJn1C6CTEBVzZYJTUCgyu8a+od3woAZU9nl1BKpkeDunxPMmgdjhBrKemw8IrdaTyS Wp3j8XkHPFgnz7tE+o35MKI+OVnINDQh1pwynapA= To: Tamas Blummer , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com> In-Reply-To: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com> References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW, URI_NOVOWEL 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: Sat, 29 Jun 2019 21:07:15 +0000 Subject: Re: [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain 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: Sat, 29 Jun 2019 20:25:16 -0000 Good morning Tamas, While I think covenants for some kind of debt tool is mildly interesting an= d an appropriate solution, I wonder about this particular use-case. It seems to me that, as either the `Transfer` signers or `Exit` signers are= always involved, that the `Transfer` signers can be constrained so as to e= nsure that the rules are followed correctly, without requiring that covenan= ts be used on the Bitcoin layer. After all, the outputs of each transaction signed by the `Transfer` signers= are part of the transaction that is being signed; surely the `Transfer` si= gners can validate that the output matches the contract expected, without r= equiring that fullnodes also validate this? In particular, it seems to me that covenants are only useful if there exist= some alternative that does not involve some kind of fixed `Transfer` signe= r set, but still requires a covenant. Otherwise, the `Transfer` signer set could simply impose the rules by thems= elves. Another thing is that, if my understanding is correct, the "sidechain" here= is not in fact a sidechain; the "sidechain" transaction graph is published= on the Bitcoin blockchain. Instead, the `Transfer` signers simply validate some smart contract, most l= ikely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public key= s, and ensure that the smart contract is correctly executed. In that case, it may be useful to consider Smart Contracts Unchained instea= d: https://zmnscpxj.github.io/bitcoin/unchained.html It would be possible, under Smart Contracts Unchained, to keep the `Transfe= r`-signed transactions offchain, until `Exit`-signing. Then, when this chain of transaction spends is presented to the participant= s, the participants can be convinced to sign a "cut-through" transaction th= at cuts through the offchain transactions, with the resulting cut-through b= eing the one confirmed onchain, and signed only the participants, without t= he `Transfer` or `Exit` federation signatures appearing onchain. This hides not only the smart contract being executed, but also the fact th= at a Smart Contracts Unchained technique was at all used. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev wrote: > I introduced you to gerneralized covenants[1] earlier, but in a domain sp= ecific context that de-routed us from technical discussion. Let me demonstr= ate the concept in a more generic use: > > A covenant=C2=A0 > > or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant dro= p)=C2=A0 > > would put a coin under the alternative control of a Transfer and Exit key= s together with the script in control of the current owner.=C2=A0 > Additional transaction level validations of transactions spending input w= ith covenants apply as in [1] > > Owner of such coins would be able to transfer them to others provided an = addtional Transfer signature, in which case the coin remains encumbered wit= h the same covenant. > If Exit and owner signs the covenant is dropped on the output, it becomes= a plain Bitcoin again. > > The Thransfer and Exit signatures could be threshold signatures of a fede= ration, whereby member decide if the proposed transfer transaction complies= with whatever unique rules they impose.=C2=A0 > > The result is a federated side chain embedded into the Bitcoin block chai= n. > > Bob could purchase some asset guarded by the federation with a transactio= n: > > Inputs > 100.0001 pk(Bob) > > Outputs > 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and= (pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=C2= =A0 > 99.9=C2=A0pk(Transfer) > > Transfer to Alice with consent of the transfer validators: > > Inputs > 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and= (pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=C2= =A0 > 100.001 pk(Alice) > > Outputs > 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or= (and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)= =C2=A0 > 100 pk(Bob) > > Alice might be approved to exit with the exit signature of the federation= : > > Inputs > 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or= (and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)= =C2=A0 > 99.9 pk(Transfer) > > Outputs > 99.9999 pk(Alice) > > Tamas Blummer > [1]=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Jun= e/017059.html