←back to thread

Signal adds a payments feature with a privacy-focused cryptocurrency

(www.wired.com)
544 points josh2600 | 1 comments | 06 Apr 21 16:23 UTC | HN request time: 0.238s | source
Show context
leifg ◴[06 Apr 21 16:41 UTC] No.26714074[source]▶
What's the consensus function you use on the mobile coin blockchain. Couldn't see if it's proof of work or proof of stake.
replies(1): >>26714124 #
josh2600 ◴[06 Apr 21 16:44 UTC] No.26714124[source]▶
We use a modified version of the Stellar Consensus Protocol that we reimplemented from scratch using Rust.

https://github.com/UkoeHB/Mechanics-of-MobileCoin/blob/maste... << Page 81 is where you want to go.

replies(3): >>26714459 #>>26714837 #>>26715172 #
crazypython ◴[06 Apr 21 17:32 UTC] No.26714837[source]▶
How does Stellar Consensus prevent double-spends?

Imagine I have a private key to an address with 10 coins. Imagine I spend the same amount of money (10 coins) on Mars and Earth at the same time. There is a 10-lightminute gap between Mars and Earth. Assume Mars and Earth have a similar number of Stellar nodes. What happens in Stellar Consensus?

replies(1): >>26714955 #
josh2600 ◴[06 Apr 21 17:41 UTC] No.26714955[source]▶
Stellar actually does nothing to prevent double-spends as it is the consensus layer and not the ledger. The ledger prevents double spends in mobilecoin by using a proof called a "key image" which is part of CryptoNote (https://bytecoin.org/old/whitepaper.pdf). Essentially, a ring signature is produced by the user which says "one of these N transactions belong to me" and the key image proves that one of the members of the set is a valid transaction without revealing which transaction was valid (and preventing future reuse of the valid input).
replies(2): >>26715158 #>>26717054 #
fourstar ◴[06 Apr 21 17:57 UTC] No.26715158[source]▶
So essentially, this is a mashup between XMR (ring sigs) and XLM (consensus protocol)? Why not use zk-proofs?
replies(1): >>26715271 #
josh2600 ◴[06 Apr 21 18:07 UTC] No.26715271[source]▶
If you can find a way to do ZK-proofs that work in the time constraints that we have (1-3 seconds end to end transaction completion and finality), then we'll switch to them. Right now this is the only way we could get the performance we wanted.
replies(1): >>26735633 #
1. dlubarov ◴[08 Apr 21 06:14 UTC] No.26735633[source]▶
As someone who works on ZKPs, that's very doable :)

In a Zcash-style spend circuit, the bottleneck is typically the Merkle inclusion proof, which takes say 32 hashes (assuming a limit of 2^32 note commitments). If we're comfortable with using one of the newer arithmetic hashes like Poseidon, that's about 10k constraints. Any of the modern argument systems (Groth16, Plonk, STARKs, etc.) can give proof times well under a second with a circuit of that size. If we want to optimize further, we can get proof times down to around 10-20ms (single-threaded) by using an arithmetization that's carefully tailored to our circuit's bottlenecks.

If we stick with traditional primitives like SHA-256, the circuit becomes substantially larger, but with modern techniques we can at least get proof times under a second. Happy to talk through the options if it would be useful.