Distributed Cryptography for Polkadot Wallets - Milestone 1

[janbormet]

Milestone Delivery Checklist

• The milestone-delivery-template.md has been copied and updated.
• This pull request is being made by the same account as the accepted application.
• I have disclosed any and all sources of reused code in the submitted repositories and have done my due diligence to meet its license requirements.
• In case of acceptance, an invoice must be submitted and the payment will be transferred to the Polkadot/fiat account provided in the application.
• The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application pull request: w3f/Grants-Program#1908

[PieWol]

Hey @janbormet ,
thanks for the delivery. I get that the article is the main outcome of this milestone but please stick to the milestone delivery guidelines and adjust the current delivery.

Generally speaking, the most important part of a delivery is a list of the same deliverables listed in the application with links to their implementation/realisation

Thank you.

[janbormet]

Thank You @PieWol
I have made some changes, such that the deliverables section is according to the guidelines.
As we submitted our proposal according to the research template, we do not have a "Testing Guide" deliverable. I have put the "Article" deliverable instead. I hope this works out, as the entire milestone is really contained within the linked report.

Thanks!

[PieWol]

Thanks for adjusting the layout @janbormet ,
To write up the evalutation I'm waiting for a review by someone from the research team. Hope to be able to get back to you soon.

[tinnendo]

Hi @PieWol, I hope you're doing well! I was just wondering if there are any updates on the review?

[PieWol]

Hey @janbormet ,
I'm really sorry for the delay. I have contacted @burdges already and I hope he gets back to you with an evaluation asap.

[burdges]

Ain't so much here.. https://github.com/perun-network/polkadot-wallet-grant/wiki/Milestone-1 contains

Section 1 - Mostly irelevant chat about common security assumptions, which are a low priority concern, like a single sitation could cover this, unless something later gave reasons for the inclusion of something not discussed elsewhere.
Section 2 - List of scheme, half of which are mostly irrelevant three round schemes, unless something later have reason for three rounds, and then two TODOs.

The table looks kinda useful, but there is no real discussion of the where the information comes from. At minimum, you'd expect \cite[Theorem ??, Page ??]{??} per item here, but actually discussion would be nicer, and maybe required in places. It misses some confusing differences between the FROSTs & kin which I've noticed others discuss.

The underlying goal of the project is "Threshold BIP32 wallets", but nothing much said about that. I suspect the story here is the authors figured out that Schnorr is relatively simple, compared with the pile of stupid garbage that is ECDSA & its tooling.

In other words, this seems like the first delieverable done with the absolute minimum effort, with any actual results in the authors heads.

In future..

1. Let's not give more grants to people who've mostly focussed on ECDSA in the past, because they'll always dramatically overiflate the complexity and in the wrong places
2. We typically only give grants to academics with whome we're working, because this provides the right sort of babysitting. We've limitted bandwidth for babysitting, so that'd never happen here.

I'll approve the milestone payment, but I'm very unhappy..

[burdges]

We noticed the networking collum in the table is wrong. All these protocols are synchronous, using more recent work. It's possible there are more subtle flavors of synchrony, but we didn't look into that.

[burdges]

At a high level I do think how users use "subkeys" broadly interpreted diserved more work, which probably requires exploring specific approaches. These TVRFs derifations were meant to provide more security (or unlinkability?) in some sense, but this was never justified. I think this must be justified by future milestone,

Threshold BIP32 Schnorr is a complete triviallity: In the additive derivation case, combiner tells the signers their public key, which they'll use in computing the challenge. Combiner add the secret key deformation. We could've the signers validate the public key change by recomputing the derivation, but this appears unecessary. We do need the signers to actually know the derivation if one uses the seemingly stronger multiplicattive derivation like Tor does, but blockchains always use the weaker additive derivation.

These TVRFs should be stronger than this scheme, which provides exactly the usual BIP32 Schnorr security.

[semuelle]

@janbormet, would you like to comment?

[sebastianfaust]

Thanks for the feedback and for the approval of the first milestone! Sorry for getting back late, but most of us have been on holiday.

Regarding your general feedback. It is pretty uncommon for basic research grants to define concrete milestones with deliverables. The web3 grant template required these milestones/deliverables, so we wrote some that made sense to us and that could have some added value. We are sorry if you view this as wasted time.

We are totally fine with skipping all (artificial) deliverables in the future and just write the final scheme/definition/proofs. For us, these deliverables are also just overhead that can be avoided. However, if we follow this approach, we would require some upfront payment as is common in grants from public funding agencies, e.g., National Science Foundation (NSF) or European Research Council (ERC) funding.

We noticed the networking collum in the table is wrong. All these protocols are synchronous, using more recent work. It's possible there are more subtle flavors of synchrony, but we didn't look into that.

Could you extend on this or link to the paper to which you’re referring to? In the case of the non-interactive or 1-round schemes, they can be considered as (trivially) achieving the more desirable asynchronous property.

Threshold BIP32 Schnorr is a complete triviallity: In the additive derivation case, combiner tells the signers their public key, which they'll use in computing the challenge. Combiner add the secret key deformation. We could've the signers validate the public key change by recomputing the derivation, but this appears unecessary. We do need the signers to actually know the derivation if one uses the seemingly stronger multiplicattive derivation like Tor does, but blockchains always use the weaker additive derivation.

Indeed, you are right that the non-hardened key derivation as specified by BIP32 is easy to achieve in the threshold setting. The hardened derivation, on the other hand, is quite a bit more challenging since it requires to hash the shared parent secret key. Our idea for this grant was to come up with a hardened derivation mechanism for the threshold setting that (1) is more efficient than a distributed hash function evaluation, (2) achieves the same properties as the original BIP32 hardened derivation, and (3) is compatible with a suitable threshold Schnorr scheme. We believe that this is an interesting direction with several research challenges. But even if this direction turns out not to be sufficiently interesting (for writing a paper), then we have at least a solid basis for doing an implementation, which was somewhat the part that we were mostly interested in anyway.

Please let us know how to proceed.

[github-actions]

🪙 Please fill out the invoice form in order to initiate the payment process. Thank you!

[github-actions]

Congratulations on completing the first milestone of this grant! As part of the Grants Program, we want to help grant recipients acknowledge their grants publicly. To that end, we've created a badge for projects that successfully deliver their first milestone. Please use the badge only in reference to the work that has been completed as part of this grant, so please do not display it on your team or project's homepage unless accompanied by a short description of the grant. Furthermore, you're now welcome to announce the grant publicly. Please remember to observe the foundation's guidelines in doing so. If you haven't already, reach out to [email protected] for feedback on your announcement and cross-promotion.

Thank you for your contribution, and good luck! If you have any remaining milestone, let us know if you encounter any delays by leaving a comment on the application PR or submitting an amendment.

[PieWol]

Hey @sebastianfaust @janbormet ,
Thanks for delivering your first milestone. I'd appreciate a new article version with improved formatting. Looks like right now the table was placed mid sentence. Otherwise best of luck for your next milestones!

[PieWol]

My evaluation is pretty sparse as this one was basically completely handled by Jeff. Just for the sake of formalities you can have a look at my evaluation here.

[RouvenP]

hi @janbormet @sebastianfaust we sent the payment today

[janbormet]

Thanks, we fixed the table placement