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):
https://github.com/UkoeHB/Mechanics-of-MobileCoin/blob/maste... << Page 81 is where you want to go.
Or did you modify it to fit a different use case?
(thanks for answering questions!)
Finally, we wanted to perform consensus on encrypted values so that the nodes wouldn't be able to censor transactions.
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?
How do you prevent the sybil attack then if there is no scarcity?
I.e. what prevents an individual from spinning up 10 million nodes to get more voting power?
Thanks for clarifying!
So you're expecting people to
- manually add peers to be able to use the network.
- manually monitor the said peers for if they do malicious transactions, and manually ban them if yes.
Right?
How is this supposed to work considering that:
- most users won't care about manually adding peers. They'll just add EVERYONE who offers to be added so they can be done with it and use the system.
- most users probably won't even understand what a malicious transaction is in the first place.
- the few who do will for sure not have the time to monitor a network which does dozens or in the future even thousands of transactions per second.
This seems just humanly impossible, there's by no means sufficient human time available to manually monitor a P2P network's content if the said content is super boring and complex.
If it were a distributed social network you could expect people to e.g. manually flag spam because using a social network implies reading the posts contained in it.
But manually reviewing money which strangers send to each other is boring as hell, who will do this?
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?
https://github.com/mobilecoinfoundation/mobilecoin/tree/mast...
How does this solve network splits or honest disagreements?
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.