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 3508FC3A for ; Sun, 30 Jun 2019 16:57:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E508A8 for ; Sun, 30 Jun 2019 16:57:11 +0000 (UTC) Received: by mail-wm1-f49.google.com with SMTP id x15so13513593wmj.3 for ; Sun, 30 Jun 2019 09:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q5erL7tVwL+qczBk3g324dNfiWmJOTRCJkC/uGRlFZw=; b=Jmxj76io31A4vNA2pzaym/4bA9pUK03CwfTUCmalR0Fw1mlwHoXr5whD1tDlj7C0V9 9S6Yu96rl3AgaLReq1aZ947uwl/al4rJ5LYdqKBobCM+fIK589uAa6yeLKwJeRRFYaef XrkLczyMTVt591mzmmi7ie2HK8BqIhpXgJqj4qusGA8beXkZB/iqWDskWKm9aqZnTEWo 4AGYa705tP0oDBr2ZxbjNV5mvd90UEw4eOlcF54d6z3XCDpsS/IzLtuCfE6mADCPSqom I7xPTOp6C3hc0ahaDbxVWhEPLzsZJLzDIfloKak/fdswz6dUW6+v2OKqbLqFNR8XoBSg cw7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q5erL7tVwL+qczBk3g324dNfiWmJOTRCJkC/uGRlFZw=; b=iHVFNVhxPthp6GvCQwoc3JALWo6P27KW+yc0dA1bIfF7QHAfZ33C5gkfaSartimgvM lqW6a2k2+4hsoFL8835bTugomkmvBeGO5T42eF+zaaiVpWFa+XmudjB3cueyEXdaDcSB Y9onVHSkErGvP2ZrKFDN+XLTm0AKSFImWc68D2f73MpDifaX8jfOC5oZvMBDqhAgJcJL mDgk0fI5q/5gBf4WCvYASlDTWdlu0mUyGPAZqSKnwmuqJzSKjeu4YDlgiackuIs8rRmx TpWy7L5/+Ch+WsGgXmYEXv98bOfDbdNGZfmIa/XlUH6UXoV2+y+epaJr2YcN81GKADGj y/Lg== X-Gm-Message-State: APjAAAVv8fexJ4i2+J1zUm4FBI9rafaDPLYpmxZDZxbADUJHMCvktpgl SuUkAXB/6vhBdCoFML2WnbA= X-Google-Smtp-Source: APXvYqw3ciB1x9stpP29sl+w9ipecoSguL/GqvtHqLpxkL0dHP8Fh77Fm1KpmOx9qDXvuvb8JBxE9Q== X-Received: by 2002:a7b:c202:: with SMTP id x2mr13376177wmi.49.1561913829691; Sun, 30 Jun 2019 09:57:09 -0700 (PDT) Received: from p200300dd6712641801d2360ece635895.dip0.t-ipconnect.de (p200300DD6712641801D2360ECE635895.dip0.t-ipconnect.de. [2003:dd:6712:6418:1d2:360e:ce63:5895]) by smtp.gmail.com with ESMTPSA id s10sm9519636wmf.8.2019.06.30.09.57.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 09:57:08 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 30 Jun 2019 18:57:06 +0200 In-Reply-To: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com> To: ZmnSCPxj References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com> <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: Sun, 30 Jun 2019 17:08:59 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 30 Jun 2019 16:57:12 -0000 --Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello ZmnSCPxj, Yes, representation of debt is more interesting here as it requires the = covenant, wheras this example, as you point out, was less convincing = given alternatives. I created this example to avoid discussion of topics not approriate on = this list. Thank you for the suggestion of unchained execution of transfers with = cut-through exit transaction as this made the example much stronger: The most important question for someone who trusts his coins to some = unchained platform is probably the question of how exit is guaranteed if = one is unhappy with what one gets. With the exit covenant exit conditions are set in stone, since validated = on-chain. If the exit key is owned by a trusted arbiter other than the = federation governing the unchained platform then one at least have the option to cut losses at some point by = presenting the arbiter a chain of valid transactions and asking to sign = the exit. Participants in the unchained platform would also be interested to = regularly snapshot the economic effect of offchain transactions with = cut-through transactions as such cut-through shortens the chain of = transactions they would need to get on chain if chosing the exit without consent of = the federation governing the transfers. So the convenant needed is: 'covenant or(_ covenant transitive, = and(pkExit, _) covenant drop)' which gives unrestricted flexibility to = the unchained platform with the exception that it has to maintain the = exit option. Tamas Blummer > On Jun 29, 2019, at 22:25, ZmnSCPxj wrote: >=20 > Good morning Tamas, >=20 > While I think covenants for some kind of debt tool is mildly = interesting and an appropriate solution, I wonder about this particular = use-case. >=20 > 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 ensure that the rules are followed correctly, = without requiring that covenants 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` signers can validate that the output matches the contract = expected, without requiring that fullnodes also validate this? >=20 > 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` signer set, but still requires a covenant. > Otherwise, the `Transfer` signer set could simply impose the rules by = themselves. >=20 >=20 > 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 likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` = public keys, and ensure that the smart contract is correctly executed. > In that case, it may be useful to consider Smart Contracts Unchained = instead: https://zmnscpxj.github.io/bitcoin/unchained.html >=20 > It would be possible, under Smart Contracts Unchained, to keep the = `Transfer`-signed transactions offchain, until `Exit`-signing. > Then, when this chain of transaction spends is presented to the = participants, the participants can be convinced to sign a "cut-through" = transaction that cuts through the offchain transactions, with the = resulting cut-through being the one confirmed onchain, and signed only = the participants, without the `Transfer` or `Exit` federation signatures = appearing onchain. > This hides not only the smart contract being executed, but also the = fact that a Smart Contracts Unchained technique was at all used. >=20 > Regards, > ZmnSCPxj >=20 >=20 > Sent with ProtonMail Secure Email. >=20 > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =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: >=20 >> I introduced you to gerneralized covenants[1] earlier, but in a = domain specific context that de-routed us from technical discussion. Let = me demonstrate the concept in a more generic use: >>=20 >> A covenant >>=20 >> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant = drop) >>=20 >> would put a coin under the alternative control of a Transfer and Exit = keys together with the script in control of the current owner. >> Additional transaction level validations of transactions spending = input with covenants apply as in [1] >>=20 >> Owner of such coins would be able to transfer them to others provided = an addtional Transfer signature, in which case the coin remains = encumbered with the same covenant. >> If Exit and owner signs the covenant is dropped on the output, it = becomes a plain Bitcoin again. >>=20 >> The Thransfer and Exit signatures could be threshold signatures of a = federation, whereby member decide if the proposed transfer transaction = complies with whatever unique rules they impose. >>=20 >> The result is a federated side chain embedded into the Bitcoin block = chain. >>=20 >> Bob could purchase some asset guarded by the federation with a = transaction: >>=20 >> Inputs >> 100.0001 pk(Bob) >>=20 >> 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) >> 99.9 pk(Transfer) >>=20 >> Transfer to Alice with consent of the transfer validators: >>=20 >> 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) >> 100.001 pk(Alice) >>=20 >> 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) >> 100 pk(Bob) >>=20 >> Alice might be approved to exit with the exit signature of the = federation: >>=20 >> 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) >> 99.9 pk(Transfer) >>=20 >> Outputs >> 99.9999 pk(Alice) >>=20 >> Tamas Blummer >> [1] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.h= tml >=20 >=20 --Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0Y6eIACgkQ9nKRxRdx ORwqsgf+OXnIOUlhsuiM3+/oNE4oNPMku5GybhHaTzOYlMYhe0jm9ZySGC3W1qEU igmwWlLBLBBXPIS5eCsqtPaEP0yJg2HooOMjVoiCvJ37qVyq/X+LnWKbt2FzI8Rc ecVd5rA3+9h3dSDOUwJkTYPziKwww3/hVTkOLx7tYVv2PzMxl2wEUsswaciwW4Jv MTLQvs94i3p4jzIDoTen+F/RTdCBRG4JBYcCMXLdqlC7+EbLPpTYqKBSOURXeXuJ qBgTJHUwThiXTdFhP3VZ7UuI7vsoPzO3Cy/RcmlxtF1fEhJuvNuqD264jOfYu9X2 Lft73ink04d0iOxxjRn7k2t0YgYzhQ== =GaXW -----END PGP SIGNATURE----- --Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250--