4 ms·

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)

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?

josh2600 5y ago
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 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).
- fourstar 5y ago
  So essentially, this is a mashup between XMR (ring sigs) and XLM (consensus protocol)? Why not use zk-proofs?
  - josh2600 5y ago
    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.
    - dlubarov 5y ago
      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.
- eMGm4D0zgUAVXc7 5y ago
  I don't understand the "key image" cryptography, but I can't fathom how any cryptography, no matter how smart it is, could prevent the user from: 1) Creating a backup of their wallet on disk. 2) Sending their coins somewhere, but not broadcasting the transaction to the network, instead storing it in a file. 3) Restoring from the backup 4) Sending the coins to a different address = double spending them. 5) Broadcasting the transactions in a very close timespan to conduct the double-spend. The network needs to prevent this by storing, in an non-forge-able fashion such as PoW, which transaction happened first. How does your system guarantee that?
  - comex 5y ago
    The client trusts a list of centralized validator servers, albeit protected by SGX, to resolve conflicts. At least according to: https://github.com/mobilecoinfoundation/mobilecoin/tree/master/consensus/service#mobilecoin-consensus-protocol https://github.com/mobilecoinfoundation/mobilecoin/tree/mast...
    - crazypython 5y ago
      > The MobileCoin Consensus Protocol solves the Byzantine Agreement Problem by requiring each user to specify a set of peers that they trust, called a quorum. Quorums are based on the real-life trust relationships between individuals, businesses, and other organizations that compose the MobileCoin Network. How does this solve network splits or honest disagreements?

josh2600 5y ago

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 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).

fourstar 5y ago
So essentially, this is a mashup between XMR (ring sigs) and XLM (consensus protocol)? Why not use zk-proofs?
- josh2600 5y ago
  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.
  - dlubarov 5y ago
    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.
eMGm4D0zgUAVXc7 5y ago
I don't understand the "key image" cryptography, but I can't fathom how any cryptography, no matter how smart it is, could prevent the user from: 1) Creating a backup of their wallet on disk. 2) Sending their coins somewhere, but not broadcasting the transaction to the network, instead storing it in a file. 3) Restoring from the backup 4) Sending the coins to a different address = double spending them. 5) Broadcasting the transactions in a very close timespan to conduct the double-spend. The network needs to prevent this by storing, in an non-forge-able fashion such as PoW, which transaction happened first. How does your system guarantee that?
- comex 5y ago
  The client trusts a list of centralized validator servers, albeit protected by SGX, to resolve conflicts. At least according to: https://github.com/mobilecoinfoundation/mobilecoin/tree/master/consensus/service#mobilecoin-consensus-protocol https://github.com/mobilecoinfoundation/mobilecoin/tree/mast...
  - crazypython 5y ago
    > The MobileCoin Consensus Protocol solves the Byzantine Agreement Problem by requiring each user to specify a set of peers that they trust, called a quorum. Quorums are based on the real-life trust relationships between individuals, businesses, and other organizations that compose the MobileCoin Network. How does this solve network splits or honest disagreements?