From 124059cebea6c254b1c1cdbe406f326906176125 Mon Sep 17 00:00:00 2001 From: Simon Sarasova Date: Thu, 8 Aug 2024 00:15:27 +0000 Subject: [PATCH] Improved Future-Plans.md. --- Changelog.md | 1 + Contributors.md | 2 +- documentation/Future-Plans.md | 4 ++-- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Changelog.md b/Changelog.md index 683f811..84c71d3 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 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* * Added LocusIsPhased information to the local user profile creation process. - *Simon Sarasova* diff --git a/Contributors.md b/Contributors.md index 5477ecc..7525409 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 | 272 \ No newline at end of file +Simon Sarasova | June 13, 2023 | 273 \ No newline at end of file diff --git a/documentation/Future-Plans.md b/documentation/Future-Plans.md index 3d7234e..1a4c218 100644 --- a/documentation/Future-Plans.md +++ b/documentation/Future-Plans.md @@ -25,11 +25,11 @@ Payment proof providers can be operated by anyone. They must be trusted not to l 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. +Payment proof providers will operate very similarly to [OpenTimestamps.org](https://www.opentimestamps.org) calendars. The major difference between them is that when using payment proof providers, 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. +A payment proof is a merkle tree path. The on-chain address for the payment proof is a hash of (The root of the merkle tree + A byte to represent the cryptocurrency). The cryptocurrency byte is included so that address is entirely different on each blockchain. 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 number of layers between the root and the content's tree leaf node. 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. A payment proof merkle tree can also be unbalanced, meaning that some leaves are closer to the root, and thus get to spend a larger portion of the total amount. For example, a 1 ETH merkle tree could distribute 0.5ETH to a top-level single leaf, 0.25ETH to a second-layer leaf, and 0.125 ETH to 2 third-level leaves. 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.