From d769047de77131a7eef2db116e3208acf5af4719 Mon Sep 17 00:00:00 2001 From: Simon Sarasova Date: Thu, 8 Aug 2024 03:16:00 +0000 Subject: [PATCH] Improved Documentation.md and Future-Plans.md. --- Changelog.md | 1 + Contributors.md | 2 +- documentation/Documentation.md | 182 +++++---------------------------- documentation/Future-Plans.md | 2 +- 4 files changed, 31 insertions(+), 156 deletions(-) diff --git a/Changelog.md b/Changelog.md index 84c71d3..dd2cc85 100644 --- a/Changelog.md +++ b/Changelog.md @@ -6,6 +6,7 @@ Small and insignificant changes may not be included in this log. ## Unversioned Changes +* Improved Documentation.md and Future-Plans.md. - *Simon Sarasova* * Improved Future-Plans.md. - *Simon Sarasova* * Added Merkle Tree Payment Proofs to Future-Plans.md. - *Simon Sarasova* * Added the Height trait to the Create Genetic Models utility. - *Simon Sarasova* diff --git a/Contributors.md b/Contributors.md index 7525409..8a1ce86 100644 --- a/Contributors.md +++ b/Contributors.md @@ -9,4 +9,4 @@ Many other people have written code for modules which are imported by Seekia. Th Name | Date Of First Commit | Number Of Commits --- | --- | --- -Simon Sarasova | June 13, 2023 | 273 \ No newline at end of file +Simon Sarasova | June 13, 2023 | 274 \ No newline at end of file diff --git a/documentation/Documentation.md b/documentation/Documentation.md index 1f2bbcb..3a97f0c 100644 --- a/documentation/Documentation.md +++ b/documentation/Documentation.md @@ -71,7 +71,7 @@ Each network type is described by a single byte. Mainnet == 1, Testnet1 == 2. Multiple networks allow for the testing of new features on a test network before deploying them on the main network. -Each network has its own account credit database, account credit interface servers, network entry seeds, and parameters. Profiles, messages, reviews, reports, and parameters all contain a network type byte. +Each network has its own payment proof providers, network entry seeds, and parameters. Profiles, messages, reviews, reports, and parameters all contain a network type byte. Users can switch their app's network type. Upon switching network types, the Seekia client will interface with the new network and delete downloaded database content from different networks. User data such as messages and chat keys are retained, so users can switch between networks without losing sensitive data. @@ -107,7 +107,7 @@ If hosts are hosting Host/Moderator identities, they must host all of them and t ### Host Identity Balance -Each host identity must be funded with a minimum amount of credit to participate in the network. +Each host identity must be funded with a minimum amount of cryptocurrency to participate in the network. The gold rate/day in cost is defined by the network parameters. @@ -257,112 +257,49 @@ All Seekia messages, mate profiles, and reports must be funded to be hosted by t Identities must be funded to have their profiles hosted by the network. -This is required to prevent network spam and discourage bad behavior. +Funding is required to prevent network spam and discourage bad behavior. Without a financial cost to broadcasting content, a single actor could spam the network with billions of fake profiles/messages, rendering the network useless. By requiring funds, broadcasting spam costs an attacker money. Seekia users can be banned if they engage in malicious behavior, so being a malicious user will cost money. -Users spend enough credit to have their profile hosted for as long as they initially desire. For example, if a Mate user wants to try out Seekia for 60 days, they fund their Mate identity for 60 days. They can extend their identity's balance any time they want. +Users spend enough cryptocurrency to have their profile hosted for as long as they initially desire. For example, if a Mate user wants to try out Seekia for 60 days, they fund their Mate identity for 60 days. They can extend their identity's balance any time they want. -Users must fund their mate/host identity for a minimum number of days. This only needs to be done once per each identity. The account credit servers will not allow a funding below a minimum number of days, if the mate/host identity has not already been funded in the past. Moderator identities are funded via Moderator Scores, which are described later in this document. Anyone can fund another user's identity, which is useful if that user's identity is close to expiring. +Users must initially fund their mate/host identity for a minimum number of days. This only needs to be done once per each identity. This is required to prevent an attacker from funding many identities for a very small amount of time (1 hour), and flooding the network with profiles. Moderator identities are funded via Moderator Scores, which are described later in this document. Anyone can fund another user's identity, which is useful if that user's identity is close to expiring. Each mate profile must be funded individually for a flat fee. Without this, an attacker could replace their identity's mate profile thousands of times, which would spam the moderators with profiles to review. Host and moderator profiles do not have this issue, because these profiles do not need to be approved by the moderators. Host and Moderator profiles can be banned or approved, but they do not need to be approved before being downloaded or viewed by users. -Reports and messages must each be funded individually. Reports use a flat fee, whereas messages are funded based on their size. Larger messages are more expensive. +Reports and messages must each be funded individually. Reports use a flat fee, whereas messages are funded based on their size and network duration. Larger messages are more expensive. The costs to fund identities/profiles/messages/reports are defined in the network parameters. All of the parameter costs must be updated in a way that allows a time period for all clients to update their parameters. Otherwise, some user clients will overpay/underpay because they have outdated costs. If the spam on Seekia started to increase, the network admins would increase the costs. A perfect balance must be achieved which reduces the amount of spam and unrulefulness but keeps the cost low for users to participate. -To determine the funded status of an identity/profile/message/report, hosts and users request the information from the account credit servers. +To determine the funded status of an identity/profile/message/report, hosts and users request the information from hosts who provide blockchain information. -## Account Credit +## Funding Content -Seekia is not a fully decentralized network. +Seekia uses cryptocurrency to fund identities, mate profiles, reports, and messages on the network. -Seekia uses Credit rather than cryptocurrency to fund host/mate identities, reports, and messages on the network. Moderator identity scores do not use Credit, and instead use cryptocurrency. +Non-moderator identities, reports, mate profiles, and messages are all funded using payment proofs. -Account credit is used instead of cryptocurrency for 2 reasons: Privacy and Scalability. +*TODO: Explain merkle tree payment proofs. An explanation currently exists in Future-Plans.md.* -In a fully decentralized model, the funding of messages, reports, mate profiles, and identities would be accomplished with private blockchain transactions. An example of this is a zero knowledge accumulator, where each transaction is unlinkable. +The price of funding content/identities on the network is represented in gold. To calculate the amount of funds sent to a particular address, Seekia multiplies the amount of crypto sent in each payment by the gold exchange rate at the transation time described in the parameters to determine the total amount of gold sent to the address. -Supporting 10,000 messages per second would require a blockchain that can support 10,000 private transactions per second, along with a built-in wallet within the application. +Moderator identity scores are not funded with payment proofs. Moderators use crypto addresses derived from their identity hash. This makes it easier to calculate a moderator's identity score, as downloading payment proofs is not necessary. It also reduces the amount of data that the Seekia network needs to maintain in perpetuity. Moderators should use blockchain privacy tools to fund their identity scores to avoid linking their crypto wallets with their moderator identity. -Due to the scaling limitations of privacy-preserving blockchains, the network relies on a central account credit database to perform accounting privately. +All Seekia clients get their hosted message/profile/report funded statuses from blockchain hosts. All communication between clients and payment proof servers must be encrypted with Nacl and Kyber. -Credit is represented as milligrams (change?) of gold within the account credit database. +Using cryptocurrency for funding content also allows for the timestamping of profiles/reports/messages. The blockchain becomes a source of truth for the earliest time at which a message can be proven to exist. If the sender-alleged message creation time conflicts with the payment proof funding time by more than an hour, a warning could be shown. -Credit can be purchased with cryptocurrency by destroying funds on the blockchain. The account credit interface servers can check an account's quantity of purchased credit by checking the balance of its associated blockchain address. +After a mate-profile/message/report is funded, its funded status is static, and its expiration time cannot be increased. -An advantage of using Credit is that it enables some users to join for free. The administrator of the account credit database can create credit by will. The administrator can send credit to trusted entities whose job is to distribute credit to people to onboard them to Seekia for free. For example, credit could be distributed by a faucet that requires a unique phone number, because phone numbers are costly to attain for spammers. Other examples include sending credit manually to users who have proof of personhood, sending credit to people who have verified social media accounts, etc.. +### Privacy Risks -Credit can be transferred between users. A user shares their Account Identifier to another user, who can send credit to that identifier. +Payment proof providers pose a necessary privacy risk. The servers must be trusted to not keep track or log which account funded each profile/identity/message/report. If the proof provider servers were compromised over a period of time, they could be used to log the profiles/identities/messages/reports funded by each account. This would negate the privacy advantages of secret inboxes, making it easier to tell which users are talking to each other. -### Account Credit Servers - -There is a single central account credit database, along with many account credit interface servers. - -The account credit interface servers are used to load-balance all of the operations and bandwidth that do not need to be centrally performed. They also provide protection against hacks, because some account credit servers are read-only. - -There are 2 types of interface servers: Read Only and Writeable. The read only servers are only able to read from the database. This will suffice for most requests. This will reduce the number of servers that, if compromised, would be able to corrupt the master database with false information. - -The central database keeps track of each account's credit balance and each funded identity/profile/message/report's expiration time. - -The database server is a single point of failure. It can be regularly backed up. - -Each account is an ed25519 public/private key pair. - -Each account public key is used to derive cryptocurrency addresses and an account identifier. See `/internal/network/accountKeys.go` for the implementation. - -Each user can create as many accounts as they need. Cryptocurrency address and account identifier reuse is discouraged because of the privacy implications. - -An account's public key is used to query the servers on the balance of the account. Without the private key, a requestor cannot determine the account credit balance. They must perform a handshake and sign something provided by the account server to verify they are the owner of the account. - -Users can send funds from one account to another by using the account's identifier. - -The interface servers communicate with the account credit database, deducting from the account's balance for each profile/message/report/identity funding transaction they make. - -To buy credit using cryptocurrency, the user sends crypto to the address associated with their public key. - -Any funds sent are destroyed. This is done for multiple reasons: -1. Technical: It is easiest to create a different address for each account this way. -2. Legal: to avoid any claims that Seekia is generating profit or acting as a for-profit entity. -3. Ideological: to keep Seekia as decentralized as possible. No single entity should profit from the users. - -To spend funds, the user contacts an account credit interface server with their public key, their intended amount of credit to spend (in gold), and the message/profile/identity/report to fund. The account credit interface server derives the account public key's crypto addresses and looks up the deposits made to its addresses. The server multiplies the amount of crypto sent in each deposit by the gold exchange rate at deposit time described in the parameters to determine the total amount of credit in gold purchased for the account. The server then tells the database the crypto balance and the amount being spent and the item being funded. - -An account's balance is the total amount of credit received via its identifier minus the total amount of credit spent. A balance can be negative if the user has only received credit to the account by purchasing via crypto. - -The database checks if the amount deducted from the account is greater than or equal to the amount of credit purchased with crypto. If so, the transaction being made is rejected. If not, the amount being spent is subtracted from the account entry in the database, and the message/profile/identity/report funded status is updated within the database. - -Each interface server must have access to: - -1. The blockchain address deposits of each cryptocurrency - * They must be able to get the balance of any address, as well as the time and amount of each transaction - * All deposits in each block are combined into a single deposit for the block - * The servers can retrieve these deposits from different servers -2. The network parameters that determine the amount of gold to fund a message/profile/report/identity -3. The network parameters that determine the exchange rate for each cryptocurrency to gold. - * These rates must be historical and go back to the date of Seekia's launch. - -Moderator identity scores do not rely on the account server. Moderators use crypto addresses derived from their identity hash. This prevents their balances from being lost if the server data is lost, which is much worse for moderators because the amount of money spent is much greater. Moderators should use blockchain privacy tools to fund their identity scores to avoid linking their crypto wallets with their moderator identity. - -All communication between the database, the interface servers, hosts, and clients must be encrypted with Nacl and Kyber. - -Another use of the servers could be timestamping of messages. The servers could be a source of truth for when a message was sent. If the sender-alleged message creation time conflicts with the account credit server by more than 1 minute, a warning could be shown. Otherwise, message creation times could be relied upon. - -Hosts get their hosted message/profile/report funded statuses from the account credit servers. Mate/Moderator users get the message funded statuses from the credit servers, and the profile funded statuses from hosts. This is done to reduce the load on the account credit interface servers, and to enable the network to maintain more functionality if the account credit servers go offline. - -After a profile/message/report is funded, its funded status is static, and its expiration time cannot be increased. - -### Privacy Risk - -The servers pose a necessary privacy risk. The servers must be trusted to not keep track or log which account funded each profile/identity/message/report. If the servers were compromised over a long period of time, they could be used to log the profiles/identities/messages/reports funded by each account. This would negate the privacy advantages of secret inboxes, making it trivial to tell which users are talking to each other. - -If an attacker only obtained a snapshot of the servers, they would only learn the balances of each account. If the attacker could link the accounts to the Seekia users whom they belong to, and a user received all of their credit by purchasing with cryptocurrency, the attacker could tell how much credit the user has spent, and guess roughly how many messages the user sent. This is not possible if the user received credit for free or from another user, in which case, their credit balance would be subtracted from the database as it is spent. The amount of credit which belonged to an account in the past should not be saved or logged by the database, thus, the spent credit would disappear without a trace. - -An attacker could potentially determine which exact messages were sent by a user. If the attacker linked a user's identity to their credit account(s) and balance(s), they could subtract the user's known identity/profile funding transaction amounts and determine which sent message/report costs add up exactly to the amount of funds spent. They could use information about the recipients of the messages to better guess that they had been sent by the suspected user. This becomes more difficult as more users join Seekia. Image messages should often cost the same amount, so this strategy should become impossible with enough users. +If an attacker only obtained a snapshot of the servers, they would only learn the balances of each account. In any server-compromise scenario, the message contents would still be encrypted. @@ -370,80 +307,17 @@ In any server-compromise scenario, the message contents would still be encrypted Another privacy consideration is the ability to link a user's identity hash to their account crypto address(es). -Account addresses will never withdraw funds, and will likely receive funds in the small amounts recommended by the Seekia client, making them easier to identify. +If a user funds their moderator score and payment proof provider account with the same Ethereum/Cardano wallet, then linking these addresses together is trivial. -If a user funds their moderator score and credit account with the same Ethereum/Cardano wallet, then linking these addresses together is trivial. +Another easy way to link identities to cryptocurrency addresses is to correlate the funding of payment proof provider addresses on the blockchain with the funding of new user identities/profiles on the Seekia network. This issue is mitigated by telling users in the GUI to wait a while after purchasing custodied cryptocurrency before broadcasting their profile for the first time. This breaks the link between their custodied cryptocurrency purchase and their identity/profile being funded. -Another easy way to link identities to addresses is to correlate the funding of account addresses on the blockchain with the appearance of new users profiles on the Seekia network. This issue is mitigated by telling users in the GUI to wait a while after purchasing credit before broadcasting their profile for the first time. This breaks the link between the identity being funded and their account crypto address. +Even if users are careful to prevent any links between their payment proof provider cryptocurrency transactions and their Seekia identity, observers may still be able to guess that the funds belong to some user of Seekia, because the addresses owned by payment proof providers will be easy to discover. Using blockchain analytics and user profile metadata, they could learn the wallet owner's real world identity. -Even if they are careful to prevent any links between their account crypto address and their Seekia identity, observers will still be able to guess that the funds belong to some user of Seekia. Using blockchain analytics and user profile metadata, they could learn the wallet owner's real world identity. +An attacker could potentially determine which exact messages were sent by a user. If the attacker observed the amount of cryptocurrency that a particular cryptocurrency address sent to a payment proof provider, they could subtract each user's known identity/profile funding transaction amounts and determine which sent message/report costs add up exactly to the amount of funds spent. They could use information about the recipients of the messages to better guess that they had been sent by the suspected user. This would allow attackers to link Seekia users to their cryptocurrency addresses and messages. -If user identities are linked to account crypto addresses, users who send from crypto wallets with large amounts of money could have their crypto wallet balances revealed to the world. This could cause them to become the victim of crime or be pursued by gold diggers. Users with large amounts of crypto should use privacy preserving technologies such as zero knowlege accumulators when purchasing Seekia credit. This warning is shown within the GUI. +If user identities are linked to account crypto addresses, users who send from crypto wallets with large amounts of money could have their crypto wallet balances revealed to the world. This could cause them to become victims of crime or be pursued by gold diggers. Users with large amounts of crypto should use privacy preserving technologies such as zero knowlege accumulators when increasing moderator identity scores or purchasing Seekia payment proof custodied cryptocurrency. This warning is shown within the GUI. -If a user funds the same account crypto address more than once, an observer can assume that the user has funded enough identities/profiles/messages/reports to drain at least the majority of their credit balance after their first deposit. This would allow the observer to guess that a specific user had sent a certain number of messages, which could be used to aid in other network analysis attacks. This issue is mitigated by discouraging address reuse and presenting the user with fresh crypto addresses whenever they want to purchase more credit. - -As more people use Seekia and the number of Seekia transactions increase, these privacy risks are reduced. - -### Account Credit Database Corruption - -In the event of the database crashing or being hacked, the data could be corrupted. - -The database server should be backed up regularly, but some data will likely be lost. - -If the database is reset to an earlier state: - -1. Any accounts funded with cryptocurrency will have their balances increase or stay the same. -2. Accounts funded via account identifiers will lose any money that was sent after the backup was made - * The account which sent the funds will have its balance restored - -#### Account Credit Database Schema: - -* Account Identifier `[14]byte` -> Balance (in milligrams of gold) - * This amount can be negative, if the account has purchased funds with cryptocurrency - * Sending from 1 account to another requires subtracting from the sender and adding to the recipient -* Message Hash `[26]byte` + MessageSize `int` -> ExpirationTime `int64` (unix) - * We need message size because requestor could lie about size, so each alleged size corresponds to its own entry - * Thus, the size of the message is required to get the isFunded status of a message - * The alternative requires uploading a message to the interface servers to fund it, which increases bandwidth dramatically -* Mate Profile Hash `[28]byte` -> ExpirationTime `int64` (unix) -* Identity Hash `[16]byte` -> ExpirationTime `int64` (unix) -* Identity Hash `[16]byte` -> Initial fund amount has been made `bool` - * This is needed to keep track of which identities have had their initial minimum fund amount satisfied -* Report Hash `[30]byte` -> ExpirationTime `int64` (unix) - -#### Interface Servers Schema: - -* MessageHash `[26]byte` + MessageSize `int` -> ExpirationTime `int64` - * Server only has to retrieve this once after it is funded, because time cannot be increased -* Mate Profile Hash `[28]byte` -> ExpirationTime `int64` - * Server only has to retrieve this once after it is funded, because time cannot be increased -* Report Hash `[30]byte` -> ExpirationTime `int64` - * Server only has to retrieve this once after it is funded, because time cannot be increased -* Identity Hash `[16]byte` -> ExpirationTime `int64` - * This is only needed for mate/host identities - * It must be updated with a background job, because a user may increase their identity expiration time using a different interface server - -### A future without the servers - -Once private cryptocurrency solutions can scale to our needed speed, the Seekia client can have its own crypto wallet that pays for each message/mate profile/report with a private transaction, and the account credit servers can be retired. Each message/mate profile/report/identity hash would have crypto addresses that are derived from its hash. These addresses would be used to burn coins, similarly to how moderator scores are funded. - -It is possible that a more centralized high throughput blockchain could exist sooner that could support the necessary number of private transactions. It would be worth using this kind of system instead of the single-database option because it would be more decentralized. - -Assuming each private transaction is 3KB, and there were 10,000 Seekia transactions per second, 30 MB would be added every second, or ~2.5 terabytes a day. At least some blockchain nodes would also have to verify the zero knowledge proofs, which would be resource intensive. - -The blockchain could have a smart contract such as Tornado Cash Nova or Zcash Orchard that allows users to withdraw arbitrary amounts to addresses privately. Each transaction from the contract would be unlinkable. - -In order for users to be able to create transactions, they would have to download the necessary information required to construct a zero knowledge proof that their coins came from some coin in a shielded pool. This would eventually become an enormous amount of data. There are several ways to reduce the burden of data to download: - -1. Use many shielded pools. This would reduce the anonymity set, but it would be large enough for that to not matter. The Seekia application should choose one randomly for each user, so the user would only have to download changes to a single note tree. -2. Use a single shielded pool, but allow the user to only download a random portion of the shielded pool note tree, and construct a proof from this smaller anonymity set. I'm not sure if this is possible. -3. For a faster but more trusted method, there could be a way for the user to trust the blockchain provider to construct their transaction proof, without allowing the blockchain provider to steal their funds. I'm also not sure if this is possible. This would negate the need to download large amounts of data, but would require the blockchain provider to be trusted to not track which coins the user is spending, as this would reveal the messaging patterns of the user. This level of trust is already required for the account credit interface servers, which are operated by trusted entities. - -To get funded statuses for identities/messages/profiles, hosts would connect to nodes which were hosting the balances of all transparent addresses, get the deposit information for the addresses that belong to the identities/messages/profiles, and use this deposit information and the network parameters to calculate the funded statuses. - -If there were multiple cryptocurrencies, then multiple blockchains wallets would have to be supported within the app. - -To maintain the advantage of onboarding people for free, a token would have to be created, which would require an admin to be able to mint tokens at will. This would create a marketplace for speculation, would be less decentralized, would make coins more difficult to purchase, and would introduce legal risks. I think it would be better to require all coins to be burned in the blockchain's native token. This could also be harmful by encouraging people to purchase a cryptocurrency which is centralized, so a warning must exist to discourage people from investing in the currency. +As more people use Seekia and the quantity of Seekia transactions increases, the anonymity set for each payment proof provider increases, and these privacy risks are reduced. ### Multiple Cryptocurrencies @@ -474,7 +348,7 @@ Outputs would have to be publicly burned, which would create many useless decoys Using Monero in this way would also reduce the privacy of Seekia users. Each burned output's input decoys could more easily be traced to a user's real world identity, aided by the user's profile metadata. -Linking two consecutively burned outputs together would also be quite easy due to the limited number of decoys. An example would be if a user funds their credit account after funding their moderator identity. This is obviously an even greater problem on transparent blockchains like Ethereum, but Monero has an expectation of being private which we do not want to degrade. +Linking two consecutively burned outputs together would also be quite easy due to the limited number of decoys. An example would be if a user funds their payment proof provider account after funding their moderator identity. This is obviously an even greater problem on transparent blockchains like Ethereum, but Monero has an expectation of being private which we do not want to degrade. The blockchain servers would also have to parse all the outputs with a public view key, which would be slower. @@ -564,11 +438,11 @@ Inter-IdentityType communication is forbidden. Mate users can only contact Mate ### Funding Messages -Each message must be funded with credit. The cost depends on the size and duration of the message. +Each message must be funded with cryptocurrency. The cost depends on the size and duration of the message. Each message only has 2 options for duration: 2 days and 2 weeks. This makes all messages look more similar, reducing the possibility of linking a message fund duration to a particular sender. -Once a message is funded, its duration cannot be extended. This allows hosts and users to not have to make any more queries to the credit servers after they have confirmed that a message has been funded and retrieved its expiration time. +Once a message is funded, its duration cannot be extended. This allows hosts and users to not have to download any more of a message's payment proofs or make any more queries to blockchain hosts after they have confirmed that a message has been funded and retrieved its expiration time. ### Message Encryption Keys diff --git a/documentation/Future-Plans.md b/documentation/Future-Plans.md index 1a4c218..99b56c6 100644 --- a/documentation/Future-Plans.md +++ b/documentation/Future-Plans.md @@ -15,7 +15,7 @@ Many tasks are not included here, but are instead annotated within the code with Rather than using a central account credit server to fund content on the network, Seekia should use merkle-tree payment proofs. -A merkle tree payment proof provides a way to burn cryptocurrency funds in a single on-chain transaction for any quantity of identities, messages, and profiles. Payment proof merkle trees enable a way to perform scalable proof-of-sacrifice/proof-of-burn. +A merkle tree payment proof provides a way to burn cryptocurrency funds in a single on-chain transaction for any quantity of identities, messages, reports, and profiles. Payment proof merkle trees enable a way to perform scalable proof-of-sacrifice/proof-of-burn. Merkle tree payment proofs are needed to be able to support tens of thousands of payments per second, because creating an address and transaction to fund each piece of content and each identity would overload the blockchain(s) with too much on-chain data.