path: root/62/24a6db9469a0728b1169c030956157f8444809

Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DBFBAF0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Jun 2019 22:25:03 +0000 (UTC)
Received: by mail-wm1-f48.google.com with SMTP id s3so13889209wms.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <tamas.blummer@gmail.com>
Message-Id: <A124C836-8EEC-49C6-9CF1-35A88170F040@gmail.com>
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: <E736009F-50EE-4A0E-BD1A-F963A7820FA1@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
	<_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com>
	<A048BAB4-9166-40BD-BC70-7FCE47F00D72@gmail.com>
	<E736009F-50EE-4A0E-BD1A-F963A7820FA1@gmail.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 <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <tamas.blummer@gmail.com> =
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 <tamas.blummer@gmail.com> =
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 <ZmnSCPxj@protonmail.com> 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 =
<bitcoin-dev@lists.linuxfoundation.org> 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--