No, I think we’re far from making an RFC. And I’m not planning on carrying out this task by myself. Although I’d be happy to contribute.
Perhaps we should start by taking some simple protocol and pondering what a script for it could look like…
1 Like
What do you mean by this? Like which language? Or what features?
Clarity is pretty cool but that’s like smart contracts
I find the idea of a programmable wallet very interesting and in line with my own ideal of a as simple as possible consensus layer, with add-on functionality using wallet magic. What I like about the proposal is that it would make the smart handling of interactions independent of the implementation since it is defined in its own language.
One good use case example/protocol, would be protocols to handle the interaction between wallets.
e.g of Pseudo-code for returning a slate with back up channels for communication
<SENDING PREFERENCE 1: Send slatepack over tor>
<Wait for up to 5 seconds or until confirmed receipt>
< IF confirmed receipt == TRUE>
<Return/print, successfully shared slate over TOR, stop script>
<ELSE>
<Print/return, sending over TOR failed, Trying now to send slate-pack via Signal>
<SENDING PREFERENCE 2: Share slate over Signal, timeout after 5 seconds >
< IF shared over Signal is success >
<Print/Return, sharing over Signal was successful, end script>
<SENDING PREFERENCE 2 post on Slate-wall, auto remove after 2 weeks >
< IF connection failed>
< Return/print slate-wall is not reachable>
Just some crude pseudo code, nothing interesting right?
Well the interesting part is that the script contains custom fields defined by the sender of the slate-pack. The Sender can program the order of back-up channels to use for returning the slate This allows the receiving wallet to try multiple ways to contact the sender for the return slate. The script is a template with a few custom fields, so the wallet can recognize it as safe to use. The smart script can be encrypted for the receiver as to not leak information such as the Signal user information to any intercepting party.
For me the smart handling of interactions would be the first use cases to look at. Other examples of such protocols would be for, CoinSwap, share fees (to get 2 outputs in and 2 outputs out), or multisig wallets and atomic swaps. So basically anything that might require proper definition of interaction between multiple wallets.
Could we also use such smart scripts to define that what we are sharing is in fact a Grin-Voucher/private-key and not a normal transaction? I think that should be possible as well 
. That would be another interesting protocol example.
3 Likes
How low level would/should the language be? Should it just provide access to ECC primitives (add, mul, etc) and then let the script implement cryptographic protocols (e.g. ECDSA, Bulletproofs, etc) on top of that? Or should the language provide access to common cryptographic protocols, and let scripts create “application protocols” via combinations of those cryptographic protocols?
[edit] the more I think of it, the latter would be necessary. Requiring scripts to implement their own cryptographic protocols would lead to complexity and costly mistakes.
The language should be as high level as possible. So we might try to identify the smallest set of primitives that supports the implementation of all the following protocols:
SRS transfer
RSR transfer
Payjoin
Cancelling Self-spend
CoinSwap Self-spend
Deferred transfers to a Cold Wallet
Funding an n-of-n output
Spending an n-of-n output
Grin side of Atomic Swap
Grin side of Succinct Atomic swap
Discreet Log Contract
Unidirectional Payment Channel
Bidirectional Payment Channel
If we can implement all of these, then our set of primitives must be pretty comprehensive!
Regarding Payment Proofs, it might be nice if they were mandatory; i.e. whenever you’re signing for a tx in which you’re a net receiver, then a memo needs to say what you’re being paid for.
6 Likes
I really like the idea a lot. Maybe it could also enable some automated verification of the scripts so that end-users and script writers can reason about the spending conditions effectively.
1 Like
This is actually aligned with my main interest in grin and MW ever since I saw Andrew Poelstra’s first scriptless scripts talk before the network was live.
As far as I understand it none of the fundamentals have changed, though I haven’t been following grin development very closely as of late, but one could, with a wallet that supports what you’re talking about, build a secondary consensus network that uses self spends and threshold signatures and uses the grin blockchain for finality. You could create permissionless, public consensus networks, permissioned, private networks, you can create networks that nobody even knows exist because of MW’s transaction building scheme. You can create any number of these types of networks with any number of participants, any hierarchy.
An example, suppose you and I want to create an agreement about some state, and we agree to give you two votes and me one vote on changing the state. The state could be a document, and we would sign the document, two for you one for me, and put its hash in a grin 2 of 3 threshhold sig with our three keys signing it. From the outside it would appear to be just a normal grin transaction, but to us it is evidence of the agreement.
Suppose we want to change it to 1 vote each, we can transfer some grin from it to a new 2 of 2 multisig, your signature can even just be the combined keys of your original 2. Update the hash of the changed document, done. We can add new people, do whatever we want.
Such a scheme can control a grin balance, and the document can be anything, it can be as complex as a so-called “side chain”, it could control all manner of things, the document is just the current state of some arrangement or thing.
What do you think? What am I wrong about or not seeing?
3 Likes
I think you are not missing anything. Only upside/downside is that the script itself is not on chain, so all who interact with such a script/scheme/side-chain, do need to maintain a copy of said script/scheme/side-chain or receive it together with the transaction. At least those you interact with have a copy, so that should not be much of an issue since you should be able to receive an encrypted copy in case your wallet state gets lost. Indeed, the main elegance is that in the end it is just a hash that looks like any other transaction no matter what the complexity is behind that commit.
1 Like
Both the slates exchanged by some script and the nonces used for signatures can potentially commit to the script. The former can start with the script hash, while a nonce can be tweaked with a script hash.
3 Likes
Yeah that’s an upside to me. Participants in some system, whatever it is, need to keep the most updated version of the state of the system, none of it is on the blockchain, just proof of finality of the latest state, only detectable to the participants.
There have been attempts to create “smart contract” systems that are private, and I think the approach of having everything on chain is a flawed approach. MW enables us to do something like this, but entirely private if the participants want it to be that way, to the point of undetectability. Its a lot of work, but to enable this we need some type of consensus system that compiles these agreements into complex signature schemes that are compatible with grin. Once the software to build them exists people can build any number of things using grin for finality, and you don’t have the problem of the entire network updating the state of everything it’s being used for, only participants need to keep data on systems they’re a part of and use.
In some ways the commitments to the script will contain a zero knowledge version of the script so if it is rebuilt properly it should match a zero knowledge version which participants could store and distribute off chain at their own discretion. It is possible that the scripts could eventually disappear this way which depending on how you manage it can be a good or a bad thing.