FAQ, first attempt (condensed from gitter chat)

[sesam]

No description provided.

[ignopeverell]

That's very helpful, thanks!

[0xmichalis]

Is there a source I can read about synchronous vs asynchronous mining? Searching around doesn't yield any good result.

[sesam]

@Kargakis Are you looking for benchmarks (minimal advantage possible with 4x 1 process or likely better with 8x 1 process vs current 1 process with many mining threads)
Or to understand the technical difference? Asynch will be needed for GPU mining. GPU mining is guaranteed to be an order of magnitude faster, maybe 10x to 20x than the most optimized CPU mining. This info is from the mailinglist archives, github and gitter chat.

[apoelstra]

The quantum resistant claim is very misleading. grin is not quantum resistant. Switch commitments allow it to become quantum resistant with a minimum amount of disruption but if a QC appeared without warning the entire system would be subject to undetectable inflation. Not to mention coin theft, which switch commitments do nothing to prevent.

[sesam]

@apoelstra Thanks. What would be a realistic, forward looking answer for Q: Quantum safe?

The "just add big enough hashes" seemed nice, but I understand QC can make many supposedly fixed parts come loose and so they can be fiddled with.

[apoelstra]

A realistic, forward looking answer is "Given sufficient warning, a softfork can be done to require all outputs include an unconditionally sound rangeproof, such as Oleg's scheme. This requires extra data which is already included (though hidden behind a hash) in all outputs, and which is currently not validated at all. Much later, a softfork can be done which freezes all coins which have not been moved in this way. This will destroy funds belonging to inattentive users, but also gives users who would rather preserve privacy than value the ability to forfeit their coins. Observe also that the privacy of the pre-first-fork history will be preserved, though post-quantum validators will be unable to convince themselves that no inflation occurred back then. At that point, it will be impossible for quantum computers to inflate the currency, though any inflation that occurred before the freeze would be permanent and undetectable. Further, Oleg's scheme is insufficient to prevent theft of coins, it is only protection against inflation. A more advanced scheme (a la zk-SNARKs) would be needed that internally proved the consistency of the hashed data without actually revealing it."

[sesam]

Thanks!
I'd like to keep a layman-friendly version in the FAQ, and then expand on it elsewhere.

How about:

A: Doable, with some loss of privacy or coins, or by adding more cryptopraphic assumptions. [Read more](range_proofs.md#quantum-safety)

add to doc/range_proofs.md

Quantum safety

Protection against quantum computing attacks is partially doable without adding new cryptographic assumptions:

1. Softfork and require [unconditionally sound rangeproofs](https://github.com/apoelstra/secp256k1-mw/pull/1) preserves historical privacy only. This requires including and also validating extra data. The data is already included in all outputs hidden behind a hash.
2. Users re-spend all coins, or loose them after
3. softfork freeze old coins.

Caveats:

• Validators after (3) any quantum-caused inflation before 2. can't be detected, and no additional inflation is possible after 2.
• Oleg's scheme protects against inflation, not coin theft. Alternatively, we could detect theft but not inflation.

To prevent both theft and inflation, something more advanced is needed. Adding assumptions, something like zk-SNARKs could internally prove the consistency of the hashed data without actually revealing it.

[apoelstra]

There is no way to "detect theft but not inflation". You can always detect theft because your coins are gone. Detecting theft is useless. There is also no way to prevent theft but not inflation, it's hard to even say what that would mean.

[sesam]

Thanks. Sorry, that was pretty daft of me :). Ok, will fix this up and make a Pull Request with the more correct FAQ text ASAP.