Request for funding / Antioch / Jul-Sep 2020

Governance
1

I am currently funded through until the end of June (previous funding request).
I would like to request a further 3 months of funding to cover July through to September.
This would be for the standard yeastunit of €10k/month.

I have been almost exclusively focused on Grin node over the past few months, specifically NRD kernel support and ongoing work on node stability and performance etc.
I am looking to shift my focus a little over the next few months and spend at least a portion of my time with Grin wallet.
There are a few wallet features under discussion that I would like to get involved with and put some time toward.

  1. “mostly” lock free transactions
  2. PayJoin aka Pay-To-EndPoint (P2EP)
  3. multi-party outputs for Succint Atomic Swaps
  4. Payment channel implementation (leveraging NRD relative locks and multi-party outputs)

These all share some commonality, specifically around the interactive transaction building process, fine-grained control over output selection and kernel offset adjustments.

We currently support a relatively limited and “simplified” single-round transaction building protocol, supporting a single sender and a single receiver. (1) and (2) require more flexible output selection and flexibility of kernel offset adjustments. (3) and (4) actually require a different and more complex transaction building protocol. We need support for “three-round” musig with secure communication of random nonce values etc.

We will likely not implement all of these in the next few months but I would like us to be thinking about them collectively and to ensure we do not implement one at the expense of making subsequent changes harder.

So while I was focused on activating NRD kernel support at the node p2p protocol layer (on floonet for testing) for HF3 I suspect my HF4 focus will shift to wallet related support for musig and improved transaction building flexibility.

It will be interesting to see what we can do with the Grin wallet to support this additional complexity while keeping the UI/UX as simple and robust as possible.

Alongside this shift in focus toward wallet I’m also aiming to continue spending time on node itself.
We have one final scheduled hardfork at the end of the year. We want to ensure we are ready for this, both taking advantage of this final hardfork to make any necessary protocol changes and to prepare Grin for what happens beyond HF4.

I am aiming to stay involved in the ongoing “Parallel IBD” work that will add significant improvements to the initial Grin experience, in terms of both stability and performance.

Edit: This post makes the assumption that we require musig support to be able to support multi-party outputs securely. This is not necessarily true and we need to spend time investigating this further. @tromp suggested in keybase that we may be able to continue using “naive Schnorr” and we need to convince ourselves of this. So please treat any reference to musig above as a loose term for Schnorr signatures in general.
We may be able to avoid the additional complexity of musig if we are careful.

13 Likes
2

Keep up the good work ,in favor.

3

Do you want to implement MuSig for kernel signatures, or is it for something else?

Given the individual keys, the aggregated key in the MuSig scheme is not the sum of the keys.
Example, in the case of two individual keys, X_1 and X_2, the aggregated key X is defined by:

X = Hash({X_1,X_2}||X_1).X_1 + Hash({X_1,X_2}||X_2).X_2.

The security proof is dependent upon that formula above, and such a key could make the kernel commitment more difficult to do… but maybe possible by adjusting correctly with the offset… Do you want to use the scheme in cases where more than two people sign the kernel? Why not I guess, and it is indeed one of the unique multisig schemes secure under public key aggregation

Otherwise, don’t you think it would make sense to not be too fast for NRD kernels, for the purpose of Grin long term robustness and sustainability?

4

I fully support funding you again

5

@kurt Hmm yeah maybe I’ve been using the term musig incorrectly when thinking about this.
What we want is a way for multiple parties to produce a signature that is immune from key cancellation and rogue key attacks.

My (somewhat limited) current understanding is that right now our simple tx structure prevents this as all keys involved in the signature map directly to individual outputs (with corresponding rangeproofs), so neither party has an opportunity to introduce a rogue key. The rangeproofs effectively act as proof that all involved keys are legit.

This no longer holds if both parties contribute keys to a single multi-party output (say during an atomic swap) and what we need is a robust way of doing this securely.

I have been referring to this (I guess in loose terms) as musig - but as you say, this may not necessarily be what we want here.

1 Like
6

Currently Grin is immune to key cancellation attacks, but maybe it would not be immune anymore in situations under the settings you are/will be working on (atomic swap, payment chanels,…). I have no clue…will be worth some thinkings…

1 Like
7

I unfortunately do not agree with the security support for the grin wallet and believe that it is better to spend man hours on the implementation of windows wallet. Otherwise, competitors will break out in front.
What good is security if no one uses your wallet?

Create a request to develop a wallet for windows and my vote will be for you.

1 Like
8

I think you mean a GUI Windows wallet (grin-wallet is available for Windows). Grin++ is doing an excellent job there IMO. I think it’s better to focus right now on defining/improving how we transact and all 4 points that were made by antioch work on this

3 Likes
9

I support you in your work. Keep going :muscle:

10

I fully agree with your priority list, especially with objective 1 and 3 (allowing others to potentially sign transactions for you when offline) since this would inprove UX for transactions a lot.
In favor of continued funding.

1 Like
11

I think you may have misunderstood 1. and 3. since they don’t really enable this (or I’m misunderstanding them)

12

@oryhp Well I am hoping they can be used for something like other nodes signing you transactions while you are offline. But maybe that is not the way offline transactions can or will be implemented. What are the use cases of MultiSig for Grin the developers have in mind, anything new? I only know its use for better group managent of funds, use in case the owner disseases etc.

1 Like
13

Good write-up @antioch, I had some questions:

  1. There were questions in the GrinHub Telegram about whether you intended to be working on atomic swaps as part of your funding request. I do not read your request as such, but it would be helpful if you could confirm?

  2. While I think the points above are all important and interesting, and I understand the logic for why it makes sense to investigate them together, I’m also aware of the fact that you’re one of our key node contributors at the moment. How would node progress be affected by this shift in focus to the wallet? As we head into preparations for our last scheduled hard fork, what consensus breaking changes (or changes that makes sense to introduce as part of a fork) have we yet to tackle?

  3. Conversely - the topics you list above that are related to transaction building are not consensus breaking, correct? What’s the rationale for taking them on sooner, rather than later?

4 Likes
14

That’s a good point. I was under the impression we don’t really know whether some consensus changes will take part in the last hard fork. If there are, then it would make sense to also put some focus on these. I’d also like for the community to think how wallet management would look like at scale - I’m particularly interested in seeing if we can find a way to avoid having private keys online and instead just keep a subset of information in the wallet that is enough to finish/create the utxo but not enough to spend the funds (which would allow receive only wallets).

1 Like
15

PIBD, amongst some other things, look like a no-brainer compared to MuSig, which, as per some keybase discussions, doesn’t look useful at all for Grin.
In my opinion we should totally focus on robustness (long term sustainability) and user friendliness, rather than fancy names. We don’t have yet a lot of developers. Private key interaction, as suggested, would be an interesting area of investigation.
Atomic Swaps look an excellent focus to have. This and PIBD could bring a super useful improvement to Grin while not hurting Grin robustness, as NRD does, and even more so since the study of replay attacks.
We must think of Grin as a strong coin to build as a goal, rather than to make personal technical interests take the lead in some important decisions

1 Like
16

I am of the same sentiment. Actually I do not care one bit which tehnology is used to achieve this, I only care about the functionality and the improvement of user experience for transactions.

The reason why I though MutliSig’s would be interesting was that I could think of some possible ways that MultiSigs or something similar can be used to facilitate ofline transactions. Below some examples:

  1. Using MultiSig for offline transactions by e.g. 3 out of 4 keys needed for accepting the transaction (sender key, receiver-key, receiver-key from a node who accepts the transaction for you for a fixed fee). The fourth key being needed to actually transfer the funds. This would require some special type of MultiSig contract, 3 out of 4 for accepting, 4 out of 4 for keys for sending. Publishing this receiver privatekey tto other node owners for offline transactions does not reduce security in any way was far as I can think of since it is unlinked from your primary privatekey. Maybe some smart construction can be thought of to derivate this special receiver privatekey from the primary privatkey in a unreversable wayy.

  2. Another option I can think of would be to use different special receiver-keys that are derive from the main privatekey similar to how BIP32 allows generating multiple keys from the (extended-)privatekey in standardized way. This would greatly improve the privacy.

  3. A third possible way I can think of would be to use the LN once it is setup to allow other node owners to sign receipt of a transaction for you. This again would require MultiSigs or something similar where multiple nodes interact for the transaction.

Again, I do not care about the technology, so these are just some brainstorm thoughts. I leave it here for greater minds to think of what the best implementation is for offline transactions would be.

17

It is hard for me to visualize the output after these 3 months. Could you clarify what do you want to achieve at the end September 2020, please?

Thanks.

18

You are the greater mind, mate :wink:
I do not follow all of the ideas that you have put but do hope and maybe encourage that you learn about mimblewimble in more details so that to participate in technical discussions again more.

Remember that only one people did not have to learn about Mimblewimble in order to understand mimblewimble: Lord voldemort

1 Like
19

I know this has been discussed before, not sure if there was a solid conclusion (likely not unanimous nonetheless). But maybe it’s worth it to consider pushing HF5 back to 6/2021 or maybe even 1/2022. This would give needed time to work out bugs, apply some non-consensus changing things and make sure devs dont burn out. I think there will always feel like there is a rush to get everything in the last HF and simultaneously inevitable that everything wont get in. I dont have a strong opinion on the matter but it seems as if delaying HF5 has more pros than cons, just a thought.

20

I don’t see the point of wasting time and I don’t see that developers are burning out, the code on github is updated every 5 - 7 days and the contributions are very small.

Therefore, we need to hurry the developers on the contrary, otherwise we will be making a wallet for 10 years.

so let’s hurry up guys, hire more people, come up with something.

1 Like