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 1DBFBAF0 for ; Sun, 30 Jun 2019 22:25:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E55ED782 for ; Sun, 30 Jun 2019 22:25:03 +0000 (UTC) Received: by mail-wm1-f48.google.com with SMTP id s3so13889209wms.2 for ; Sun, 30 Jun 2019 15:25:03 -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=mCqZwAlMVTcT6RgrqPywqE2uVlpj9RpvE9hZz1FDU9c=; b=V/AVL8mlkLrMbmsphsdU3toR+qPYpKuy/abDQZPwO7Sv9vfwPKzvZYlpX0arr/l4bL m9C+us0n9M8qXtRPfBNDtZf4U+hGv3RcvJHcR9y5HtQFXmbKY9EJ5sxtbiSe/lvSvQSu gXR4Sj23xA/eN2GmEEF+lo2xdIYBuPqTNFIKHygYHut3iEojdunh7q2lokDNNnb1ZYNc 0rtJbwe5nb4boNUE/lajG5JJLAbtvK15yCtq2l4WcT2UIIJ2JEtGvaFE/WqmF5dF6sr5 g/OtSiIy3mUXd18NSWG/CO4MG1UnXjY3k2n2G5HDMz5Xx2Pi4z0Yg1HHwdUKs2q9iEDd LO0w== 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=mCqZwAlMVTcT6RgrqPywqE2uVlpj9RpvE9hZz1FDU9c=; b=cegFQO9UJRicPUaQtJFJJcX1ZxRagG+9SWAyorRwtV4wsgL6df0GHxfQMv9aCNMI5e vB0MRHH77irBZBEfQY9lQjE9RkwVt2BYy6sN0TlObZW3Tbj4juAv/Tji7TxxzQ16fiNx yxZ62182kDDAnwcNTRYttzz2f6Aa2raE6enOmYAQEAQdIK1uBrGSywWi4m62mLcX9Fbr YJn7ZIyzuemsVxP67aWQDfPbk2A+LqIoDtgyPwcgMWMDfBF5xhSVBqSHOhUu2wQCFUP9 cMuSb/dC6KocWRiTKS1m2zAGJ4bg/ySVlXRWDadOFTHPCcCC8nvbakUa1skA+/qlkw5G dIeg== X-Gm-Message-State: APjAAAXDLiKRn/D6s3rzbi/sYGAML6TQ95/jkYFovrXoOgQWkOAC31Nz 01OYg5uX0jCDhuO6j9LxNSM= X-Google-Smtp-Source: APXvYqwkwWtBWYqTo28s/pJL/xS0NpS247C6D59dwj9Kmccp8N7U761hCped6+1aQIQv0RK53POP3w== X-Received: by 2002:a05:600c:240e:: with SMTP id 14mr14092343wmp.30.1561933502507; Sun, 30 Jun 2019 15:25:02 -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 y44sm8640252wrd.13.2019.06.30.15.25.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 15:25:01 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AAD7B196-257B-460F-BA15-B58C2758C96A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 1 Jul 2019 00:25:03 +0200 In-Reply-To: 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: Mon, 01 Jul 2019 09:46:03 +0000 Cc: Bitcoin Protocol Discussion , Pieter Wuille 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 22:25:05 -0000 --Apple-Mail=_AAD7B196-257B-460F-BA15-B58C2758C96A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Any meaningful covenant must be one that is reducing control by the = current owner. I can think of countless predicates reducing control, but try to explore = the least invasive first, and see if they unlock a new use. Offering alternate control paths is what taproot was designed for, = therefore a covenant that requires that a control path is inherited seems a fit. That is all = the debt covenant needs. There are other predicates with exciting use, such as one on total work = performed by miner which I tried to explore earlier. Pieter Wuille said it could be a = candidate for the annex. Tamas Blummer > On Jun 30, 2019, at 19:50, Tamas Blummer = wrote: >=20 > I made an error proposing the new covenant. It should be unchanged as = in the original example: >=20 > =E2=80=98covenant or(and(_, pk(Transfer)) covenant transitive, = and(pk(Exit), _) covenant drop)=E2=80=99 >=20 > since the placeholder stays for the control of the rightful owner = without transfer signature on or off chain. >=20 > The exit could be alternatively automatic allowing to exit a stalling = unchained platform: >=20 > =E2=80=98covenant or(and(_, pk(Transfer)) covenant transitive, = and(delay(100), _) covenant drop)=E2=80=99 >=20 > There remains the question why the rightful owner is not enforcing the = covenant instead of having it enforced by on-chain consensus. >=20 > I do not yet have a good answer for that as in contrast to the debt = example, here it is aligned with the interest of the current owner to = have the covenant. >=20 > Tamas Blummer >=20 >> On Jun 30, 2019, at 18:57, Tamas Blummer = wrote: >>=20 >> Hello ZmnSCPxj, >>=20 >> 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. >>=20 >> Thank you for the suggestion of unchained execution of transfers with = cut-through exit transaction as this made the example much stronger: >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> Tamas Blummer >>=20 >>=20 >>> 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 >>=20 >=20 --Apple-Mail=_AAD7B196-257B-460F-BA15-B58C2758C96A 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0ZNr8ACgkQ9nKRxRdx ORz3mQf/SDqHyt7yVPWsbhiIhfpcPQtMChEa7/p4ojs0+8OfjonsQCXW442flHZs tMQTPoR1EndnnivVNzdE/zgc/EaduXN80FjTZyrPaNYWTgF9A8FFz4ftOWSa1kr2 UD166oUndTUlirVN0gdp6gRn9Ec7nd/JkIt8x79Y1YHyQ3XGfNJGylTVHRx/8+jY m1X10SFFLuQsXvvrDpH22dEtxq29OzItCBmLnA6gojLg/sDcSCgkT5uOxJmznLyc 5IzkiXZ1wgihsaTL99k5q1crFKDVv4NUNEwc5WkByGBgCpBgmhmzFXTFaMP70rcA CL8viu3nnxzhlFFlBaiUzjZLzR2khQ== =XzuY -----END PGP SIGNATURE----- --Apple-Mail=_AAD7B196-257B-460F-BA15-B58C2758C96A--