From 29866613f872273ef53371a06ae68f398942ee9e Mon Sep 17 00:00:00 2001 From: Christian Blättler Date: Wed, 27 Mar 2024 08:38:31 +0100 Subject: DD46: small improvements --- design-documents/046-mumimo-contracts.rst | 42 +++++++++++++++---------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst index 714b5822..41e659dd 100644 --- a/design-documents/046-mumimo-contracts.rst +++ b/design-documents/046-mumimo-contracts.rst @@ -68,20 +68,18 @@ Proposed Solution Merchants will also blindly sign tokens (not coins) to indicate the eligibility of a user for certain special offers. Contracts will be modified -to allow requiring multiple inputs (to be *provisioned*" to the merchant) and -multiple outputs (to be *yielded* by the merchant). Contracts will also -include multiple options for how a user may pay or what they might want to -purchase. The wallet will then allow the user to select between the choices -that the user could pay for, or possibly make an automatic choice if the -correct choice is obvious. One output option is blindly signed coins from -another exchange, possibly in a different currency. Another output option is -blindly signed donation receipts from a DONation AUthority (DONAU). -Subscriptions can be modeled by requiring the wallet to provision a token of -the same type that is also yielded by the contract. For security, payments -using subscription tokens (and possibly certain other special tokens?) will be -limited to a list of domains explicitly defined as trusted by the token -issuer. When paying for a contract, the wallet must additionally sign over -the selected sub-contract index and a hash committing it to the blinded +to allow requiring multiple inputs (to be *provisioned* to the merchant) and +multiple outputs (to be *yielded* by the merchant). The wallet will then allow +the user to select between the choices that the user could pay for, or possibly +make an automatic choice if the correct choice is obvious. One output option is +blindly signed coins from another exchange, possibly in a different currency. +Another output option is blindly signed donation receipts from a DONation +AUthority (DONAU). Subscriptions can be modeled by requiring the wallet to +provision a token of the same type that is also yielded by the contract. For +security, payments using subscription tokens (and possibly certain other special +tokens?) will be limited to a list of domains explicitly defined as trusted by +the token issuer. When paying for a contract, the wallet must additionally sign +over the selected sub-contract index and a hash committing it to the blinded envelopes (if any). The merchant backend will (probably?) need to be changed to truly support multiple currencies (ugh). @@ -243,8 +241,8 @@ The contract terms v1 will have the following structure: .. ts:def:: ContractInput type ContractInput = - ContractInputRation | - ContractInputToken; + | ContractInputRation + | ContractInputToken; .. ts:def:: ContractInputRation @@ -283,9 +281,9 @@ The contract terms v1 will have the following structure: .. ts:def:: ContractOutput type ContractOutput = - ContractOutputCoin | - ContractOutputTaxReceipt | - ContractOutputToken; + | ContractOutputCoin + | ContractOutputTaxReceipt + | ContractOutputToken; .. ts:def:: ContractOutputCoin @@ -334,7 +332,7 @@ The contract terms v1 will have the following structure: .. ts:def:: TokenClass type TokenClass = - TokenClassSubscription + | TokenClassSubscription | TokenClassDiscount .. ts:def:: TokenClassSubscription @@ -421,8 +419,8 @@ The contract terms v1 will have the following structure: .. ts:def:: TokenSignerPublicKey type TokenSignerPublicKey = - DenomGroupRsa | - DenomGroupCs; + | DenomGroupRsa + | DenomGroupCs; TODO: may want to do a deep copy and rename DenomGroup* to TokenSignerPublicKey* here. -- cgit v1.2.3