Added Merkle Tree Payment Proofs to Future-Plans.md.

This commit is contained in:
Simon Sarasova 2024-08-07 09:01:42 +00:00
parent fe754cb6a2
commit 3e56319878
No known key found for this signature in database
GPG key ID: EEDA4103C9C36944
3 changed files with 24 additions and 3 deletions

View file

@ -6,6 +6,7 @@ Small and insignificant changes may not be included in this log.
## Unversioned Changes ## Unversioned Changes
* Added Merkle Tree Payment Proofs to Future-Plans.md. - *Simon Sarasova*
* Added the Height trait to the Create Genetic Models utility. - *Simon Sarasova* * Added the Height trait to the Create Genetic Models utility. - *Simon Sarasova*
* Added LocusIsPhased information to the local user profile creation process. - *Simon Sarasova* * Added LocusIsPhased information to the local user profile creation process. - *Simon Sarasova*
* Added the Height trait the traits package. Migrated locus metadata from json encoding to gob encoding. - *Simon Sarasova* * Added the Height trait the traits package. Migrated locus metadata from json encoding to gob encoding. - *Simon Sarasova*

View file

@ -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 Name | Date Of First Commit | Number Of Commits
--- | --- | --- --- | --- | ---
Simon Sarasova | June 13, 2023 | 271 Simon Sarasova | June 13, 2023 | 272

View file

@ -11,9 +11,29 @@ There are features and changes to be made before Seekia is ready for launch.
Many tasks are not included here, but are instead annotated within the code with the **TODO** keyword. Many tasks are not included here, but are instead annotated within the code with the **TODO** keyword.
### Account Credit Database and Servers ### Replace Account Credit with Merkle Tree Payment Proofs
See `Documentation.md` for the description of how this system should work. 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.
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.
Payment proofs will be created and funded by Payment Proof Providers. These providers will bundle many payments from many users into a single merkle tree.
Payment proof providers can be operated by anyone. They must be trusted not to log the payments made by each user. The Seekia admin(s) will share a list of trusted payment proof providers. Users will purchase cryptocurrency from them, which the providers will keep custody of. Payment proof providers can allow users to purchase custodied cryptocurrency via any payment method they desire, including bank transfers, credit cards, and cryptocurrency.
Payment proof providers may be required to register as exchanges/money transmitters, depending on their jurisdiction. Know Your Customer/Anti-money laundering laws may also be required to be obeyed in certain jurisdictions. A payment proof provider that does not allow any cryptocurrency to be withdrawn or traded may not be subject to these laws, as they are only allowing the user to purchase virtual custodied cryptocurrency. Similarly, online merchants which sell things for cryptocurrency are generally not required to get customer identification information, especially for small payment values. Payment proof providers can also make a profit from users by charging a small fee.
Payment proof providers will operate very similarly to [OpenTimestamps.org](https://www.opentimestamps.org) calendars. The difference is that users must pay to have their content included in the merkle tree. This requires payment proof providers to keep track of each user's balance, and provide a way for users to purchase custodied cryptocurrency.
If any of the payment proof providers are suddenly shut down, the payment proofs they created will still be valid. The users who purchased funds from them will lose any funds they had not already spent. The user's client will be able to switch to a new provider, and the user's balance will reset to 0.
A payment proof is a merkle tree path. The on-chain address for the payment proof is a hash of (Root of the merkle tree + Quantity of merkle tree layers). The cryptocurrency value of each payment proof is calculated by dividing the amount of cryptocurrency initially sent to the merkle tree root's address by the quantity of the tree's leaf nodes. Each leaf node is a hash of an identity hash, a profile hash, or a message hash. A single merkle tree can contain multiple identical leaf nodes, allowing for each merkle tree to provide multiple payment proofs for the same piece of content/identity hash.
The Seekia client will put scheduled user payments in a queue. The payment proof providers will wait for a certain time period to collect as many payments as possible, and then will combine them into a merkle tree and distribute the payment proofs to the users. The payment proofs are then broadcasted to the Seekia network by the users, along with the content that the proofs paid for. A single piece of content can be paid for with any quantity of payment proofs. There must be a minimum amount of cryptocurrency per payment proof to prevent spam.
Payment proofs allow the Seekia network to be fully decentralized, reducing the legal and technological attack surface of the Seekia network. Of course, nothing is "fully" decentralized, but at least there is no single server that the network relies upon.
### Importing Profiles ### Importing Profiles