Tsukimarf patch 1#225
Open
Tsukimarf wants to merge 15 commits intoPiNetwork:mainfrom
Open
Conversation
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
What it does: This PR adds a new JavaScript file (PiRC1/4-allocation/pirc_allocation_design2.js) implementing PiRC Allocation Design Option 2 — a model for liquidity pool (LP) formation using participant deposits and swaps on the Pi Network. Key additions: PIRC_ALLOCATION_DB — a static configuration object encoding allocation parameters: token/Pi splits, LP fees, engagement-based discount-to-lockup policy, process steps, and reference price points. PiRCAllocationCalculator — a class that computes listing prices, AMM (constant-product) pool invariants, swap prices, effective blended prices (harmonic mean), discount percentages, and per-participant allocations. A runDemo() function that logs pool summaries and price curves to the console. Issues flagged by automated reviewers (Sourcery & Cubic): Weak input validation in the constructor — T <= 0 || C <= 0 doesn't catch NaN, Infinity, or non-numeric strings. The fix is to use Number.isFinite(T) && Number.isFinite(C). No bounds checking in participantSummary / discountPercent — values of s outside [0, C/2] can produce nonsensical or negative outputs without any error. Redundant pEff(s) call in effectivePriceCurve — it's computed twice per iteration; storing it in a local variable is cleaner and more efficient. runDemo() runs unconditionally on import — this causes side effects (console output) whenever the module is imported. It should be gated with if (require.main === module). The author co-authored follow-up commits with Sourcery's suggestions, so some of these may already be addressed in the latest commit (75d0287). 2. Common Encryption Techniques Encryption is the process of transforming readable data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key. Here are the major categories: Symmetric Encryption uses the same key to both encrypt and decrypt. It's fast and well-suited for large data. Common algorithms include AES (Advanced Encryption Standard, the current gold standard), DES (now obsolete), and 3DES. The main challenge is securely sharing the key between parties. Asymmetric Encryption uses a mathematically linked key pair — a public key to encrypt and a private key to decrypt. This solves the key-distribution problem. RSA is the classic example; Elliptic Curve Cryptography (ECC) achieves similar security with much smaller key sizes, making it popular on mobile devices. Asymmetric encryption is slower than symmetric, so it's typically used to exchange keys rather than encrypt bulk data. Hybrid Encryption combines both: asymmetric encryption is used to securely exchange a symmetric session key, then symmetric encryption handles the actual data. TLS (the "S" in HTTPS) works this way. Hashing is technically a one-way transformation, not reversible encryption, but is closely related. Algorithms like SHA-256 and bcrypt produce a fixed-size digest of data. Hashing is used for password storage, data integrity checks, and digital signatures. It's worth noting that hashing is not encryption — you cannot recover the original data from a hash. End-to-End Encryption (E2EE) is an application of asymmetric + symmetric techniques (like the Signal Protocol) ensuring only the communicating parties can read the messages — not even the service provider. Common use cases by technique: TechniqueExamplesUse CaseSymmetricAES, ChaCha20File encryption, disk encryptionAsymmetricRSA, ECCKey exchange, digital signatures, TLS handshakeHashingSHA-256, bcryptPasswords, integrity checksHybridTLS/HTTPS, PGPSecure communication Let me know if you'd like a deeper dive into any of these, or a more specific review of the PR code itself!
Revert "Create pirc_allocation_design2.js"
|
Global pioneers are calling on the PCT to allow us to define the price of Pi ourselves, rather than letting it drift aimlessly and become a tool for speculation. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Minor wording fixes for clarity and readability.
Changes
Motivation
The existing wording was unclear or imprecise. This patch improves readability without altering the intent or meaning of the original content.