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 3CD1ACA5 for ; Sun, 30 Jun 2019 17:50:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E597F782 for ; Sun, 30 Jun 2019 17:50:24 +0000 (UTC) Received: by mail-wr1-f53.google.com with SMTP id c27so3572231wrb.2 for ; Sun, 30 Jun 2019 10:50:24 -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=6rBHifTiU1WRpwvXYvbIACbZT9fUbCXJPwEWl0Gxw0Y=; b=bggQqUv7lJ9IWQlTzLtlcvj/GnstnC+dLWdyYqDUqDZusPZXl8XALofqG3TiBjM/IK mxgQp4535f9BQbGAdlWjUZxy/k3T9TdJxyh0B1uUKmD3QdJZ6zMj4R9YmHZL8z8sam/T /hp63G7vm52IL68sozGaF5J7Rz5+0CwQkmevyNxXaNRpO5XszH0zhB21NablShd0TufT LCFGSwpB1lIa4MAEcIBztZsWXfsqCSw52UwId4EwdJr8xYCq0+cwVxiAUgvNWT+2F5x2 9N81vMBQMoiDLd0/oS3bcXwEv00K2vrCnlfzBHIDbYQWxt9eE+BRiU/bK+dxr3HQnLu1 69ug== 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=6rBHifTiU1WRpwvXYvbIACbZT9fUbCXJPwEWl0Gxw0Y=; b=SRB3RuopuzYSt3Lyv8HGh40eE5SXHk6u5MY9XZt+jQBLhsTxW9inNiYWb4ucCxJpMv mjZ6QxaR25WA+Zm48MwVTCLl8GTwsx6asv6P94Hq68sVyBTWpQQLtKbR6bZ6HY1t2jub yHKq4GURtVjxhCl/2VqqshNT02FBXqWXvbl5amtDA9mQVnKLby7l0kqCAb5Nm4KUKSI7 +FO8vyGT6rd4DU/FoqtfB9sn4riXC4eZh0uh2qV+F2rPjVOccwybztI9Wwzpr50wtw7D CNDwzbMgqaqqS917zISr1itmLWLZtQpxwKxVEGIquu+PflTpiFIPFRLWBb6sd/e7NCpf DAaA== X-Gm-Message-State: APjAAAUNiW2KQWZ3bsDSIlsiBWPJCGE9E+z7TkA7wOxGO/mqvj8VC8Ga xwX01ntxVdDQFwt8+MDsitk= X-Google-Smtp-Source: APXvYqxrbcq/XBA6inHMBsyjbVTGywTIH9EPfwI8bfn68WsHvjqikgwke1B/lp32HCokGXh3aKMs1w== X-Received: by 2002:adf:a514:: with SMTP id i20mr11211923wrb.281.1561917023481; Sun, 30 Jun 2019 10:50:23 -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 f7sm10234508wrv.38.2019.06.30.10.50.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 10:50:22 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AD64648E-3A26-48D8-9625-2A270136B00F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 30 Jun 2019 19:50:21 +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: Sun, 30 Jun 2019 17:52:13 +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 17:50:26 -0000 --Apple-Mail=_AD64648E-3A26-48D8-9625-2A270136B00F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I made an error proposing the new covenant. It should be unchanged as in = the original example: =E2=80=98covenant or(and(_, pk(Transfer)) covenant transitive, = and(pk(Exit), _) covenant drop)=E2=80=99 since the placeholder stays for the control of the rightful owner = without transfer signature on or off chain. The exit could be alternatively automatic allowing to exit a stalling = unchained platform: =E2=80=98covenant or(and(_, pk(Transfer)) covenant transitive, = and(delay(100), _) covenant drop)=E2=80=99 There remains the question why the rightful owner is not enforcing the = covenant instead of having it enforced by on-chain consensus. 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. Tamas Blummer > 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 --Apple-Mail=_AD64648E-3A26-48D8-9625-2A270136B00F 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0Y9l0ACgkQ9nKRxRdx ORyHsAf+K81nerySgdgF/r5VZjLfYjMIORRLOAIKA+7bgJdy+KhFrQblbuB5TCEt ujjX0sZ0yWm3g78zDYZ/A7jQq1nAwOerOHDujz//ciG5REJQo2a7lz7REnITZSrs cGdd7d0fcmPNcpQD83pLSTQ1ye7tod8ZR2iXGxXqfekzKBarMzf1hNxhGTyvNdFf THxiekJYjEdImPwO6VrHLJEKwvRYdx+eEeJEWi66irFT/5wtmLY2qvzPzcjNuBbL tU82OUj6xP90D5oOpKAJfME6TBRyk1ZnVEAPMuQXjr81p7ycS3ZgNCZR5HRCsJw1 f9PbHMkSq1Xv3WMUOmK9nsIWUAnDTg== =yuLR -----END PGP SIGNATURE----- --Apple-Mail=_AD64648E-3A26-48D8-9625-2A270136B00F--