Hi! I’m so excited about the technology that you’re creating. Could you provide an explanation on how the following scheme could be implemented within the Grin protocol?
In this scheme, Alice signs a permit allowing Bob to decide who can spend 100 tokens from Alice’s wallet.
Such a scheme could easily be implemented with account-based blockchains like Ethereum or Polkadot, but I would prefer to enjoy more privacy with Grin and Mimblewimble. However, I have no idea how to go about it. Could you offer some advice or recommendations on how to research this?
You could spend 100 coins into a 1 of 2 multisig with Bob. Then Bob can spend those 100 coins however he wants, or you can spend them however you want.
[edit] I don’t know of a wallet that supports this feature, but if there’s a usecase, it wouldn’t be hard to build
Am I right that in this way the 100 tokens are bind to the specific UTXO? Imagine the case: Alice have only 100 tokens, signs such a transaction to Bob and in parallel signs the same 100 tokens to David.
Bob spends 100 tokens, then Alice gets 100 tokens from Mary. Am I right that David in such a case will not be able 100 tokens from Alice however she signed the usage right?
Correct, that would not work in the proposal I gave. You would need to get more clever.
Alice could move 100 coins to a 1 of 3 multisig with herself, Bob, and, David, but only one of them could claim those coins. Subsequently, when Alice receives 100 coins from Mary, should receive them to a 1 of 2 multisig with David, so that David immediately has access to those 100 coins.
But, this would become unsafe in the presence of reorgs, where e.g. David may reorg the chain to undo Bob’s TX and claim those 100 coins for himself in the new chain AND claim the 100 coins from Mary.
Perhaps there is a way to use scriptless scripts to atomically lock the different constraints together, but I would need to know more about the actual constraints you’re trying to enforce.
The situation arises from our peer-tutoring software. Alice, a tutor, teaches Bob and provides him insurance for a specific skill. She also tutors David and offers him similar insurance. Both Bob and David can present these insurances to their employers, allowing them to penalize Alice if necessary.
Currently, in the Polkadot parachain, we have programmed it so Alice has a single account (not UTXO based), and employers can receive reimbursements from Alice’s account.
As it stands, Alice can issue as many insurance policies as she wants and doesn’t need to know all of her students’ public keys at the time of her account creation.
We would like to retain the same functionality with Mimblewimble.
What guarantees do these employers have that Alice’s account holds sufficient funds at the time they want to penalize her / receive reimbursement ? Can’t Alice empty her account whenever she likes?
Hmmm, I’m not going to say it isn’t possible, but this sort of system is antithetical to the design goals of a UTXO system. UTXOs fundamentally commit to a certain amount of coins. The system you describe requires Alice to commit to more coins than she actually has available. Trying to make your system work in a UTXO model is probably not easy, if its even possible.
I would second Tromp’s questions too. I have doubts about a system that lets Alice commit to more insurance policies than she can pay out.
This system is just a copy of how real insurance company work: they can bankrupt any time. In terms of insurance companies we believe in them because they are regulated by governments. In terms of Alice and Bob the government is replaced by their personal friendship. Both Alice and Bob know each other and don’t cheat because they don’t want to lose a friendship. We do actually use this system in schools where Alice and Bob are students while employer = teacher.
I agree that UTXO doesn’t fit well for such a case. Can we make a system with both accounts that we have now and a UTXO model with 1:1 conversion of tokens between accounts and UTXO? Like Ethereum/Bitcoin bridge? Will it pose some risk on security due to knowing account identities?
Thinking about how I would achieve this, I think this can be done with a UTXO model and a daemon to rebalance UTXOs. It will work better if you offer standard ‘policy tiers’ instead of insuring each person for a unique amount.
Essentially you can use multisig UTXOs to issue ‘policies’ and the daemon can:
- issue new UTXOs if one of the policy holder claims a UTXO
- rebalance UTXOs as new insurance policies are added/removed
- spread policies across several UTXOs to mitigate risk
The daemon deals with liquidity balancing that would have been done in a smart contract, while the blockchain enforces the spend authorizations of each policy. I think this is actually a sensible tradeoff.
Ok. Thank you very much for your help!
1 Like