From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <E736009F-50EE-4A0E-BD1A-F963A7820FA1@gmail.com>
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: <A048BAB4-9166-40BD-BC70-7FCE47F00D72@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>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalized covenant to implement side chains
 embedded into the bitcoin block chain
Precedence: list


--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 <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


--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--