crypto eli5

Hall A1 livestream:
https://slideslive.com/ethereum/devcon5-stream-hall-a1

Hall A2 livestream:
https://slideslive.com/ethereum/devcon5-stream-hall-a2

Convention room livestream:
https://slideslive.com/ethereum/devcon5-stream-convention

devcon v livestreams

multi-collateral dai to be released on november 18th

https://blog.makerdao.com/breaking-launch-date-of-multi-collateral-dai-announced-at-devcon-5/

crypto code reviews reboot

the original group was deleted, so the community members who miss it have created a new one. feel free to continue the discussion there.

@cryptocodereview

oasis relaunched without mkr

makerdao's own decentralized exchange has been relaunched today. it was shut down in january 2019 with eth2dai.com as a temporary replacement, which since then has become one of the deepest dai markets. the new oasis lists supposed mcd collaterals like eth, rep, bat and zrx against dai and will allow you to borrow and save dai in the future.

one notable omission is mkr, which of course can't be a collateral, but was available in the old oasis. most of the (decentralized) mkr trading is going through uniswap today. i wonder how long it will take for community to fork the frontend and add mkr pair. oasis is built to be completely decentralized, orders are stored on chain, there are no fees and the frontend is open source. there is even a command line interface.

oasis.app

uniswap pools

many have tried understanding uniswap returns and many have fallen trying to do so. the general consensus has been that they are impossible to explain without explaining how the protocol works in detail.

first, pintail came up with a really nice model. then, i did some further research, which i've shared here and in uniswap slack. next, caleb from blocklytics has picked up where i stopped. their team has turned the model into super sleek dashboard which manages to convey this most-seeked data in a very concise manner.

pools.fyi

Pedersen hash weaknesses

Pedersen hash has been popularized by Zcash team as ZK-friendly hash function suitable for Merkle trees. Its simplest version operates on an elliptic curve with two fixed generators G and H with unknown discrete log relation. Then to hash two integers (a,b) one computes

P = aG + bH

and takes some compressed version of P (e.g. x-coordinate) as a result. There are several extensions of this construction to longer messages using multiple generators [1] or just by a recursive Merkle-Damgard calling. In contrast to regular hash functions like Keccak there is a formal security proof for collision resistance as any collision implies a discrete logarithm relation between G and H.

There are several problems with this construction. First, from the implementation perspective it is quite complicated. To hash messages within some field F, one has to define an elliptic curve with the order bigger than |F| but the coordinates being in F. For zero-knowledge proofs one has to convert elliptic curve equations into degree-2 constraints, and also work with the bit representation of (a,b) in order to reduce the scalar multiplication to point addition and doubling. Altogether this makes quite a non-trivial circuit, but it is still doable.

From the cryptographic point of view the situation is worse. Pedersen hash has several properties quite unexpected from a cryptographic hash function. First, it is homomorphic: H(ab,cd) = H(a,b) + H(c,d). This property alone is not problematic and is even common for cryptographic commitments and many other primitives. However, it implies that the function is vulnerable to length-extension attacks: given H(A) it is easy to compute H(A,B) for some integer tuples A and B. This property, being present in SHA-0/1/2 and forbidden in SHA-3, caused many attacks like [2]. It makes a natural MAC construction MAC(M) = H(K || M) insecure, and rules out a common domain separation method of creating many functions from one as Hi(x) = H(i||x).

Finally, the preimage security of Pedersen is weaker than expected. For an n-bit elliptic curve it is not 2^(n/2) as one would hope for. If the hashed message is l-bit long for l
We do not recommend using Pedersen hash in protocols and applications.

[1] https://iden3-docs.readthedocs.io/en/latest/iden3repos/research/publications/zkproof-standards-workshop-2/pedersen-hash/pedersen.html
[2] http://netifera.com/research/flickrapisignature_forgery.pdf