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
