From: Tamas Blummer <tamas.blummer@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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
Date: Mon, 1 Jul 2019 00:25:03 +0200 [thread overview]
Message-ID: <A124C836-8EEC-49C6-9CF1-35A88170F040@gmail.com> (raw)
In-Reply-To: <E736009F-50EE-4A0E-BD1A-F963A7820FA1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8138 bytes --]
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:
>
> I made an error proposing the new covenant. It should be unchanged as in the original example:
>
> ‘covenant or(and(_, pk(Transfer)) covenant transitive, and(pk(Exit), _) covenant drop)’
>
> 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:
>
> ‘covenant or(and(_, pk(Transfer)) covenant transitive, and(delay(100), _) covenant drop)’
>
> 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:
>>
>> Hello ZmnSCPxj,
>>
>> 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.
>>
>> Thank you for the suggestion of unchained execution of transfers with cut-through exit transaction as this made the example much stronger:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> Tamas Blummer
>>
>>
>>> On Jun 29, 2019, at 22:25, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>>>
>>> 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
>>>
>>>
>>
>
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2019-06-30 22: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
2019-06-30 16:57 ` Tamas Blummer
2019-06-30 17:50 ` Tamas Blummer
2019-06-30 22:25 ` Tamas Blummer [this message]
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=A124C836-8EEC-49C6-9CF1-35A88170F040@gmail.com \
--to=tamas.blummer@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@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