I hereby would like to open the discussion on a bounty for implement MultiSig in Grin
The first steps will be to collect information on the different technical steps/components that are required to implement MultiSig. These steps will be used to come up with milestones as well as a realistic estimates for what a bounty should look like for each milestone. I will update this post by the feedback provided in the discussion below.
Although the initial objective is to make a bounty, we always will prefer and welcome developers who are willing to commit long term to Grin as project. For interested developers, it should be noted that we are looking for a real implementation in grin-wallet in Rust, proper d implementation of test functions as well as sufficient documentation in the code and outside the code to implement these functionalities in other wallets such as Grin++.
I will tag some community members who might be more suitable than myself to provide feedback and come to a realistic estimate for the time needed to implement MultiSig in Grin: @tromp@gene@Yeastplume@oryhp@scilio
Step 1: Identifying the components needed for MultiSig Design
Step 3: Identifying milestones and bounty amounts for reach milestone
Based on feedback from Kay Strania
a simple, stack-based scripting language (is this even needed)
extending MW for MultiSig
wallet support to produce them
chain support to consume them
Step 3: Finding an interested developer and converting this proposal to a real bounty
Previous Research and discussions
TariLabs on Multiparty bulletproofs [Link]
Safe Slate, potential problems [Link]
Are MultiSigs possible in Grin [Link]
MultiSig outputs, Gene Ferneau RFC85 Link
Atomic Swap using Adapter SignaturesGene Ferneau [Link]
Old vault713 MultiSig design [Link]
Beam SBBS, for slatepacks 2.0 [linkk]
Here are some of my musings (not musigs:-) on this topic:
I think the most important milestone, at this point, would be to create an RFC for Multisig. Past experience suggests that implementations not closely following an RFC are much harder to review and leave questions about whether the choices made are really optimal for Grin.
I do not think we should pay anyone for creating an RFC. But once consensus is reached on an RFC and it gets accepted, then we can consider compensating its creators. And move forward with seeking ways to get the RFC reviewed by cryptographers and ultimately implemented.
Commenting on some of the above points:
There is no desire nor need for a scripting language in the consensus model. But some language for making wallets more
programmable could be useful.
I see no need for extending the MW protocol. Use of multisig should be invisible to full nodes. I expect the implementation will be mostly if not entirely within the wallet. And will likely require a new slatepack RFC as well.
Adaptor signatures are not strictly needed, but support for their use will be beneficial for applications like Atomic Swap and possible payment channels.
Note that Grin already uses multisig in the sense of sender and receiver both signing for txs. The distinguishing feature of this proposal is having outputs owned by multiple parties. Either n-of-n or more generally m-of-n. This necessitates multiple parties not only constructing a signature together (a mostly solved problem), but also constructing a range proof together.
Would it make sense for us to start putting the word out there? A simple campaign where we target Reddit, Hacker News, etc. There could be capable individuals out there that would love to work on this but are unaware of it. Could it be a task for the groundskeeper @Cobragrin ?
As Tromp suggested, I don’t think that we can create a bounty amount or milestones without an RFC. I think we’d need a high level explanation to start with, perhaps with some links to any previous technical discussions from the forum or even just using some of what has been discussed above.
Would like to comment on the subject, if you don’t mind.
We at Beam have an extensive experience in all this, and implemented it in various combinations.
We took the approach where nodes don’t need to be aware of the mutlisig, and everything should be done in the wallets and negotiated off-chain (as @tromp mentioned).
Worth to note that Beam has a built-in encrypted messaging system that allows wallets to communicate (so-called SBBS). I think it’ll be benificial for Grin to implement some sort of an off-chain communication mechanism for wallets too. Especially if you intend to implement sophisitcated rituals, where multiple rounds of communication are necessary.
Part of the multisig functionality was implemented in the core wallet code. This includes creating multi-signed UTXO (i.e. creating a rangeproof via sort of MPC), and aggregate signatures for atomic swaps. We also experimented with payment (lightning) channels.
But later we switched to “programmable” wallets, where arbitrary cryptographic schemes can be implemented in terms custom programs.
At first we experimented with some sort of a low-level language (a pseudo-assembler), but realized it’d be too difficult to write programs more complex then typical “hello world”.
Also considered some scripting languages. But at the end we choose to go with WebAssembly. Because this allows to write programs in various languages (including hi-level).
If you decide to go this way, I’d suggest the following milestones.
Implement some sort of a communication channel for wallets.
Implement a VM in the wallet to be able to run custom programs.
Think carefully about the API for the custom programs. It should be powerful enough to enable all kinds of sophisticated cryptographic schemes. Yet it should protect the user against potentially malicious or flawed programs.
In particular, the program should NOT usually have access to raw keys, or blinding factors of owned UTXOs. I can elaborate on this.
Overall it’s a decent amount of work. But it’s also well-defined. Once implemented, this opens a wide range of options.
@Vlad Don’t you want to take up this key task? Maybe you will have greater community acceptance and support for the resulting work. The shared investment of time and resources from Grin and Beam will be valuable, as the improvements derived from this task will directly contribute to the growth of both projects, I think.
Thanks for your input , we should absolute use the experience that Beam has on this topic.
The scripting language supported by Beam is it stack based or Turing complete?
Personally I think Grin should go the conservative road like Bitcoin and only implement a minimal stack based language. More limited, but more minimal and secure. For more advanced scripting possibilities people should use Beam. I think this also a nice way to distinguish the two projects.
It is an option to implement a Secure Bulletin Board Systems (SBBS) for Grin, but for now we can examine and learn from the data fields Beam has added to its SBBS messages and use it to upgrade our slatepack messages to support advanced use cases such as MultiSig and simple scripts (even if we only later implement this language). I will add some links to Beams SBBS and MultiSig documentation to the first post of this discussion. If you have other relevant links, those are appreciated.
There’s an off-chain part, where a custom program can be executed by a wallet, optionally communicate with other wallets, and build and send a transaction.
There’s also on on-chain part. Implemented in terms of smart contracts, with a similar WebAssembly VM (with different API functions, relevant to on-chain logic).
The smart contract part is indeed turing-complete. It has the pros that one can implement an arbitrary logic. The cons - it’s on chain, and it’s absolutely transparent to the outer world.
The off-chain part is not turing-complete. I mean, the program is, but at the end it’s all about building a standard MW tx, that is executed on-chain according to the existing logic. In addition to building a tx, peers can exchange information to build deferred (time-locked) txs, aggregate signatures, and all kinds of such stunts.
I believe the conservative approach you suggested is a good strategy. It’s a major change, which bears a reasonable risk.
, we should absolute use the experience that Beam has on this topic.