Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 13 » PPCryptoCur Exam 2020-10-21
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung | Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 14:54] – Marcel[Inf] | pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 15:02] – Marcel[Inf] | ||
---|---|---|---|
Zeile 17: | Zeile 17: | ||
* I skipped almost all proofs altogether. One of the few proofs I looked at was the one for the binding and hiding properties of the Pedersen commitment scheme. | * I skipped almost all proofs altogether. One of the few proofs I looked at was the one for the binding and hiding properties of the Pedersen commitment scheme. | ||
* Evaluation | * Evaluation | ||
- | * The exam is fair, but notably, also covers a wide range of topics. Some questions are " | + | * The exam is fair, but notably, also covers a wide range of topics. Some questions are " |
- | * The exam is always | + | * Exam by Prof. Schröder |
===== Exam ===== | ===== Exam ===== | ||
Zeile 45: | Zeile 45: | ||
> Use mixing services. Either centralized (centralized mixer, TumbleBit) or decentralized ones (CoinJoin, CoinShuffle). Centralized mixers [note: this does *not* include TumbleBit] inherently need to be a TTP, can steal your coins and/or leak your identity. Decrentralized ones build upon peer-to-peer protocols. But in CoinJoin all participants still learn about the input/ | > Use mixing services. Either centralized (centralized mixer, TumbleBit) or decentralized ones (CoinJoin, CoinShuffle). Centralized mixers [note: this does *not* include TumbleBit] inherently need to be a TTP, can steal your coins and/or leak your identity. Decrentralized ones build upon peer-to-peer protocols. But in CoinJoin all participants still learn about the input/ | ||
- | * In RingCT, | + | * What happens in those decentral mixing protocols if one party just stops responding? |
+ | |||
+ | > Indeed, DoS is a problem found in all privacy-preserving techniques that require active participation by others. By contrast, in ZeroCoin, | ||
+ | > In the decentral protocols, there is no much you can do to avoid DoS. Certainly you can stop interacting with specific BTC addresses. But then, their users just generate tons of fresh ones. Certainly you can stop interacting with specific IP addresses. But then, they might as well possess a botnet with tons of different IP addresses. | ||
+ | |||
+ | * Let's step up to RingCT. Can you elaborate on stealth addresses? | ||
> With SKAccGen you create `(msk, mpk)` and from `mpk` senders can derive a `pk`. If senders do that honestly, `pk` cannot be linked back to `mpk`. But if you possess the `msk`, you can scan the blockchain and for matching `pk`s (that have been derived from `mpk`), you can derive the corresponding `sk` to have the money at your disposal. | > With SKAccGen you create `(msk, mpk)` and from `mpk` senders can derive a `pk`. If senders do that honestly, `pk` cannot be linked back to `mpk`. But if you possess the `msk`, you can scan the blockchain and for matching `pk`s (that have been derived from `mpk`), you can derive the corresponding `sk` to have the money at your disposal. |