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
