Date: Sat, 29 Jun 2019 20:25:07 +0000
To: Tamas Blummer <tamas.blummer@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com>
In-Reply-To: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Generalized covenant to implement side chains
	embedded into the bitcoin block chain
Precedence: list

Good morning Tamas,

While I think covenants for some kind of debt tool is mildly interesting an=
d an appropriate solution, I wonder about this particular use-case.

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 e=
nsure that the rules are followed correctly, without requiring that covenan=
ts 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` si=
gners can validate that the output matches the contract expected, without r=
equiring that fullnodes also validate this?

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` signe=
r set, but still requires a covenant.
Otherwise, the `Transfer` signer set could simply impose the rules by thems=
elves.


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 l=
ikely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public key=
s, and ensure that the smart contract is correctly executed.
In that case, it may be useful to consider Smart Contracts Unchained instea=
d: https://zmnscpxj.github.io/bitcoin/unchained.html

It would be possible, under Smart Contracts Unchained, to keep the `Transfe=
r`-signed transactions offchain, until `Exit`-signing.
Then, when this chain of transaction spends is presented to the participant=
s, the participants can be convinced to sign a "cut-through" transaction th=
at cuts through the offchain transactions, with the resulting cut-through b=
eing the one confirmed onchain, and signed only the participants, without t=
he `Transfer` or `Exit` federation signatures appearing onchain.
This hides not only the smart contract being executed, but also the fact th=
at a Smart Contracts Unchained technique was at all used.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =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:

> I introduced you to gerneralized covenants[1] earlier, but in a domain sp=
ecific context that de-routed us from technical discussion. Let me demonstr=
ate the concept in a more generic use:
>
> A covenant=C2=A0
>
> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant dro=
p)=C2=A0
>
> would put a coin under the alternative control of a Transfer and Exit key=
s together with the script in control of the current owner.=C2=A0
> Additional transaction level validations of transactions spending input w=
ith covenants apply as in [1]
>
> Owner of such coins would be able to transfer them to others provided an =
addtional Transfer signature, in which case the coin remains encumbered wit=
h the same covenant.
> If Exit and owner signs the covenant is dropped on the output, it becomes=
 a plain Bitcoin again.
>
> The Thransfer and Exit signatures could be threshold signatures of a fede=
ration, whereby member decide if the proposed transfer transaction complies=
 with whatever unique rules they impose.=C2=A0
>
> The result is a federated side chain embedded into the Bitcoin block chai=
n.
>
> Bob could purchase some asset guarded by the federation with a transactio=
n:
>
> Inputs
> 100.0001 pk(Bob)
>
> 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)=C2=
=A0
> 99.9=C2=A0pk(Transfer)
>
> Transfer to Alice with consent of the transfer validators:
>
> 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)=C2=
=A0
> 100.001 pk(Alice)
>
> 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)=
=C2=A0
> 100 pk(Bob)
>
> Alice might be approved to exit with the exit signature of the federation=
:
>
> 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)=
=C2=A0
> 99.9 pk(Transfer)
>
> Outputs
> 99.9999 pk(Alice)
>
> Tamas Blummer
> [1]=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Jun=
e/017059.html