From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Tamas Blummer <tamas.blummer@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain
Date: Sat, 29 Jun 2019 20:25:07 +0000 [thread overview]
Message-ID: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com> (raw)
In-Reply-To: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
Good morning Tamas,
While I think covenants for some kind of debt tool is mildly interesting and 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 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?
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.
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
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.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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 specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
>
> A covenant
>
> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>
> 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]
>
> 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.
>
> 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.
>
> The result is a federated side chain embedded into the Bitcoin block chain.
>
> Bob could purchase some asset guarded by the federation with a transaction:
>
> 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)
> 99.9 pk(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)
> 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)
> 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)
> 99.9 pk(Transfer)
>
> Outputs
> 99.9999 pk(Alice)
>
> Tamas Blummer
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
next prev parent reply other threads:[~2019-06-29 20:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 5:53 Tamas Blummer
2019-06-29 20:25 ` ZmnSCPxj [this message]
2019-06-30 16:57 ` Tamas Blummer
2019-06-30 17:50 ` Tamas Blummer
2019-06-30 22:25 ` Tamas Blummer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tamas.blummer@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox