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.blum...@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.blum...@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 <zmnsc...@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 >>> >>> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
