Closed b-g-goodell closed 5 years ago
I'm finalizing a technical note on a signature scheme that could be used for non-interactive refund transactions, a component of the payment channel infrastructure.
I am also finishing up reading on multisig. High priority.
One question that was brought up once upon a time to me by @fluffypony is a network-activity-dependent time series model for transaction fees so that we can avoid hard-coding magic numbers for fees when the technology evolves and as exchange rates evolve over time.
Added time-space tradeoff technical note. The idea is to quantify the trade-off between space of a cryptographic scheme with respect to the verification time of that scheme; this leads to a practical trade-off comparison between security and speed/efficiency, a way of learning network characteristics required to support primitives with sufficiently large security parameters. Thing is: many crypto papers talk about the efficiency of their schemes... while they always discuss space requirements and comparisons, they sometimes avoid initial computation time comparisons and almost always avoid verification time comparisons. In our application, verification time is our bottleneck. Want to describe how "efficient" schemes described in the literature can be terribly bad in our set-up.
Finished multisig (link here), updated the roadmap. I used strikethrough for things that have been accomplished since I last checked this list:
I'm closing this issue because I have split each individual road map item up into its own issue, so that project-ifying all this is a bit easier, and contributors other than @SarangNoether and I have some place to begin. See issues 32 through 43.
This issue to discuss the MRL roadmap as discussed in our meeting on 21 May 2018 (meeting notes can be seen here). We hope that the community can help us discuss, amend and modify the following as needed.
Technical notes and documentation: We intend on completing some discussions of the following and publishing technical notes on the results of those discussions. Presented in no particular order:
Bulletproof Fee Model.Multisignatures: Recent papers have come out regarding musig's security proofs, so we are reviewing our current material for correctness before seeking publication. See here.dual output addresses(see here) for payment channel infrastructure (see below)."Zero to Monero", see here for the current version and for the RingCT report that inspired the expanded version above, see hereCurve optimizations and the importance of verification times in cryptocurrencyUpdate: @SarangNoether and @moneromooo-monero have been killing it with group operation optimizations. We are seeing >= 90% improvement in speed over OpenSSL, and we are removing dependencies on third party libraries as a consequenceOff-chain improvements: We are looking into requisite payment channel infrastructure for Monero. We have also become aware of some advances that enable the following "new technology" investigations at MRL.
Literature reviews: This is an always-happening sort of thing, as Sarang and I read more papers, we are going to include short summaries of each and eventually just publish these notes.
Multisignature schemes, common pitfalls, recent advancements in multisignature unforgeability proofs.This is included in the "related works" section of the new multisig paper (see above)Libraries for general use: Call this "research infrastructure." It's a lot easier to look into churn if we can easily measure statistics from the Monero blockchain, and it's wiser to model an attack, a PoW change, or a novel consensus mechanism like SPECTRE with a simulation than doing it live.