https://github.com/PubliusPseudis/pluribit
https://publiuspseudis.github.io/pluribit/
https://x.com/AGInoMETRICS
https://discord.gg/pjpVV8XBsk

```
▓▓▓ ╔══════════════════════════════════════════════════════════╗ ▓▓▓
▓▓  ║                                     ██                   ║  ▓▓
▓   ║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║██║║║║║║║║║║║║║║║║║║║║   ▓
    ║██████╗ ██╗     ██╗   ██╗██████╗ ██╗████║    ██╗████████╗ ║
    ║██╔══██╗██║     ██║   ██║██╔══██╗██║║██ ╚══╗ ██║╚══██╔══╝ ║
    ║██████╔╝██║     ██║   ██║██████╔╝██║║██████║ ██║   ██║    ║
    ║██╔═══╝ ██║     ██║   ██║██╔══██╗██║║██║║║██║║║║║║║║║║║║║║║║║║
    ║██║     ███████╗╚██████╔╝██║  ██║██║║██████║ ██║   ██║    ║
    ║╚═╝     ╚══════╝ ╚═════╝ ╚═╝  ╚═╝╚═╝╚══════╝ ╚═╝   ╚═╝    ║
▓   ║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║║   ▓
▓▓  ║                 Digital cash, native to the web          ║  ▓▓
▓▓▓ ╚══════════════════════════════════════════════════════════╝ ▓▓▓

        ▶ Decentralized • Secure • Private ◀
              [Proof of Time]
```
# pluriƀit

An experimental, privacy-focused cryptocurrency featuring a new consensus mechanism. Pluribit is built as a hybrid system with a Rust core compiled to WASM to handle cryptography and consensus rules, and a Node.js layer for networking and orchestration.

## Core Features

  * **Mandatory Privacy:** Implements **MimbleWimble** for confidential transactions. All amounts and addresses are obscured on-chain.
  * **Non-Interactive Transactions:** Utilizes **Stealth Addresses** to allow payments without requiring the sender and receiver to be online simultaneously.
  * **Novel Consensus Mechanism:** A unique three-stage process ($PoW \rightarrow VDF \rightarrow VRF$) designed for fairness and ASIC resistance.
  * **Decentralized P2P Networking:** Built on **libp2p**, using the public DHT for peer discovery without centralized bootstrap servers.
  * **IP Obfuscation:** Implements **Dandelion** for transaction propagation to obscure the originating IP address of a transaction.

-----

## Architecture

Pluriƀit uses a hybrid architecture to combine performance, security, and development speed.

  * **Rust Core (`pluribit_core`)**: Handles the project's core cryptography and consensus rules, compiled to WebAssembly. It manages all critical consensus logic, state validation, transaction construction, and MimbleWimble primitives.
  * **Node.js Orchestration Layer (`pluribit-node`)**: The main process that runs the node. It manages the libp2p network stack, database interactions (via neon - RocksDB), mining coordination via worker threads, and a JSON RPC server for the block explorer.
  * **Web Block Explorer**: A simple web interface for viewing blockchain statistics, blocks, and mempool status, served directly by the Node.js process.

-----

## Consensus Mechanism

pluriƀit's consensus is a two-part system designed for decentralization and fairness by reducing the hardware advantages of traditional Proof-of-Work.

### Part 1: Block Production (VDF → VRF Lottery)

This is the "lottery" a miner must win to create a block. It is a time-based search, not a hash-based one.

#### 1\. Nonce Search Loop (VDF as "Work")

  * A miner iteratively tests nonces (`nonce = 0, 1, 2...`) in a sequential search.
  * The "work" required for *each attempt* is the computation of a **VDF (Verifiable Delay Function)**. This VDF computation functions as the rate-limiting mechanism for the search.

#### 2\. Verifiable Delay Function (VDF)

  * The current `nonce` is combined with other block data to create a unique input for the VDF.
  * The VDF requires a fixed duration of sequential computation (`vdfIterations`) that cannot be significantly parallelized or sped up with specialized hardware.
  * This enforces a **time cost** per attempt, which makes hardware advantages less significant.

#### 3\. Verifiable Random Function (VRF)

  * The output of the completed VDF (`vdf_proof.y`) is used as the input for a **VRF**.
  * The VRF produces an unpredictable but verifiable random number.
  * If this number is below the current network target (`vrfThreshold`), the miner wins the lottery and can produce the next block.

### Part 2: Fork-Choice Rule (GHOST)

This is the rule nodes use to agree on the "correct" chain if a fork occurs.

  * When a fork is detected, the network does not simply follow the "longest" chain.
  * Instead, nodes use the **GHOST** (Greedy Heaviest Observed Subtree) protocol.
  * The network chooses the chain with the most **total cumulative work** in its entire subtree (the block *plus all* of its known descendants). This ensures the most secure chain is always followed.

-----

## Privacy Model

Privacy is mandatory and enforced at the protocol level.

  * **MimbleWimble**: Transactions consist only of inputs, outputs, and kernels. There are no on-chain addresses or transaction amounts. The protocol validates that no coins are created or destroyed without revealing the values being transacted.
  * **Stealth Addresses**: To enable non-interactive transactions, a sender uses the recipient's public scan key to generate a one-time ephemeral public key (`R`) where the funds are sent. A shared secret, known only to the sender and receiver, is used to encrypt the transaction's value and blinding factor. Only the recipient can use their private scan key to discover and spend these funds.
  * **Block-level Cut-through**: This implementation differs from standard Mimblewimble. Instead of aggregating transactions in the mempool, cut-through is performed at the block level.
    1.  The coinbase transaction is isolated.
    2.  All other transactions selected for the block are scanned. "Internal spends" (outputs created and spent within the same block) are identified.
    3.  If internal spends are found, all non-coinbase transactions are replaced by a single **aggregated transaction**.
    4.  This aggregated transaction contains only the **external inputs** and **unspent outputs**.
    5.  All kernels from all original transactions are concatenated into this single aggregated transaction to maintain cryptographic balance.
  * **Dandelion Propagation**: Transactions are not immediately broadcast to the entire network. They are first passed secretly along a random path of peers (the "stem" phase) before being broadcast widely (the "fluff" phase), making it difficult to trace a transaction back to its source IP.

-----

## Networking

  * **Peer-to-Peer Stack**: The network is built on **libp2p**, handling peer discovery, stream multiplexing, and connection encryption. Nodes use the public Kad-DHT to find each other, eliminating the need for hardcoded bootstrap nodes.
  * **Message Protocol**: All network messages are strictly defined and serialized using **Protocol Buffers (Protobuf)**. This provides a secure, efficient, and unambiguous binary format for communication, preventing a class of parsing-based vulnerabilities.
  * **Peer Verification**: New peers must solve a simple challenge-response PoW before their messages are accepted, mitigating spam and simple DoS attacks.

-----

## How to Run
Updated on discord

hmm

https://github.com/Qeuph/Whitepaper
# Qeuph QUH: A Quantum-Resistant Blockchain Protocol

## Abstract
As quantum computing advances, it poses a significant threat to traditional cryptographic systems, including those used in blockchain technology. Qeuph QUH is a pioneering blockchain protocol designed to address these vulnerabilities. By integrating the FIPS 204 Module-Lattice-Based Digital Signature Standard (ML-DSA-87), SHA3-512 hashing, and Bech32m addresses, Qeuph QUH offers unparalleled security, efficiency, and scalability. Compared to other quantum-resistant protocols, Qeuph QUH introduces innovative mechanisms such as "thirding" for block rewards, robust transaction validation, and quantum-resistant address generation. This whitepaper details the technical underpinnings and unique advantages of Qeuph QUH, setting a new standard for secure decentralized systems in the quantum era.

---

## Executive Summary
Qeuph QUH is a quantum-resistant blockchain protocol addressing the vulnerabilities of current systems against quantum attacks. Key highlights include:

- **Quantum Resistance**: Leveraging ML-DSA-87 and SHA3-512 for robust cryptographic security.
- **Efficient Transactions**: Enhanced with the unique txnonce field for replay prevention and orderly processing.
- **Reward Innovation**: Introducing "thirding," a novel mechanism that adjusts block rewards over time to sustain miner incentives.
- **Scalability and Privacy**: Incorporating advanced hashing and address encoding to balance transparency and user anonymity.

This paper outlines the problem, solution, and potential applications of Qeuph QUH across industries such as finance, healthcare, and supply chain management.

---

## 1. Introduction
Quantum computing presents an existential challenge to the cryptographic algorithms underlying most blockchain protocols. Estimates suggest that quantum computers capable of breaking widely used algorithms like secp256k1 and SHA2-256 may become viable within decades. Existing blockchain systems lack the necessary safeguards to withstand such advancements.

### Gaps in Current Protocols
- Vulnerability to quantum attacks on digital signatures and hashing.
- Inefficiencies in transaction processing and scalability.
- Limited mechanisms for sustaining long-term miner incentives.

### Qeuph QUH Solution
Qeuph QUH integrates:
- **ML-DSA-87**: A lattice-based digital signature standard that resists quantum attacks.
- **SHA3-512**: A robust hash function for enhanced data security.
- **Bech32m Encoding**: An efficient address format minimizing user errors.

### Roadmap of the Paper
1. Transactions
2. Address Generation
3. Blocks and Consensus Mechanism
4. Reward Mechanism
5. Security Considerations
6. Privacy
7. Real-World Use Cases
8. Conclusion

---

## 2. Transactions
### 2.1 Key Features
A Qeuph QUH transaction is defined by its quantum-resistant design and structured validation process. Components include:
- **Inputs and Outputs**: References to previous outputs and designated recipients.
- **txnonce**: Ensures transaction uniqueness by incrementing for each new transaction, preventing replay attacks.
- **Digital Signatures**: Secured using ML-DSA-87.
- **Transaction IDs**: Derived from double SHA3-512 hashing.

### 2.2 Transaction Flow
1. User signs the transaction with their private key (4880 hexadecimal characters).
2. The transaction is broadcast to the network for validation.
3. Nodes verify inputs, outputs, and the txnonce for integrity.
4. Verified transactions are included in a block and hashed into the Merkle tree.

---

## 3. Address Generation
### 3.1 Process
1. **Public Key Derivation**: Generated using ML-DSA-87, resulting in a 2592-character hexadecimal string.
2. **Double Hashing**: The public key is hashed twice using SHA3-512 for added security.
3. **Bech32m Encoding**: The hash is encoded with the prefix `quh`, creating a user-friendly and error-resistant address.

### 3.2 Example
**Input Public Key**: `abcdef...` (2592 hex characters)  
**Double SHA3-512 Hash**: `123456...` (512 bits)  
**Bech32m Address**: `quh1lnt8...`  

### 3.3 Importance of Bech32m
Bech32m improves usability and reduces errors during address entry. Unlike traditional formats, it incorporates a checksum for quick validation, ensuring secure and efficient transactions.

---

## 4. Blocks and Consensus Mechanism
### 4.1 Block Structure
- **Header**: Includes metadata such as previous block hash, Merkle root, and nonce.
- **Block Time**: Fixed at 5 minutes for faster confirmation times.
- **Difficulty Adjustment**: Every 2048 blocks (approximately 7 days).

### 4.2 Consensus Algorithm
Qeuph QUH employs Proof-of-Work (PoW) with SHA3-512 for secure and efficient consensus.

### 4.3 Thirding Mechanism
Block rewards start at 50 QUH and decrease by one-third every 262,144 blocks. This ensures:
- Sustained miner incentives over time.
- A predictable and gradual coin supply distribution.

---

## 5. Security Considerations
### 5.1 Comparison of ML-DSA-87
| Feature                   | ML-DSA-87        | Other Lattice Algorithms |
|------------------------|-------------------|-----------------------------|
| Quantum Resistance | High                 | Variable                         |
| Efficiency                 | Optimized         | Mixed                            |
| Adoption                  | FIPS Compliant | Limited                          |

### 5.2 Attack Mitigations
- **Side-Channel Attacks**: Addressed through secure hardware and implementation practices.
- **Replay Attacks**: Mitigated using txnonce.
- **Quantum Threats**: Neutralized by ML-DSA-87’s lattice-based approach.

### 5.3 Example
Consider a quantum computer attempting to forge a transaction. ML-DSA-87’s lattice-based hardness ensures the computation would take exponential time, rendering the attack infeasible.

---

## 6. Privacy
### 6.1 Features
- **Anonymous Public Keys**: Transactions are unlinkable to real-world identities.
- **Key Pair Rotation**: A new key pair is recommended for each transaction to enhance anonymity.


## 7. Real-World Use Cases
### 7.1 Finance
Qeuph QUH ensures secure and fast cross-border payments resistant to quantum threats.

### 7.2 Healthcare
Protects sensitive medical records stored on a blockchain from unauthorized access.

### 7.3 Supply Chain
Provides immutable and secure tracking of goods, ensuring data integrity across global networks.

---

## 8. Conclusion
Qeuph QUH addresses the pressing need for quantum-resistant blockchain solutions. By integrating cutting-edge cryptography and innovative mechanisms, it ensures long-term security, efficiency, and scalability. Join us in building a future-proof decentralized ecosystem.

---

### References
1. FIPS 204: Lattice-Based Digital Signature Standard ML-DSA-87. Available at: [https://csrc.nist.gov/pubs/fips/204/final](https://csrc.nist.gov/pubs/fips/204/final)
2. SHA3 Standard Documentation. Available at: [https://nvlpubs.nist.gov](https://nvlpubs.nist.gov)
3. Bitcoin Whitepaper: Satoshi Nakamoto, 2008.
4. Bech32m Specification: BIP-350. Available at: [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)

IDK Why but i made this. 😳 obvi ai helped

I found out about it should i buy or not, is it a drainer or not.
https://ico.bitcoinq.xyz/
source code at https://github.com/BitcoinQ/pyBTQ-website/blob/master/ico.html

What of bitcoin?
Read the document here:https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

Q1)When was the Genesis BTC Block mined? What a coincidence its also my date of birth.

Q2)Halving occurs after every _____ Blocks.

Q3)Which curve BTC use for its elliptic curve cryptography. (IN FULL FORM)

Q4)What is the maximum supply of BTC that will ever exist?

Q5)How long does it typically take to mine a new BTC block?

Q6)What hash function does BTC use.

Q7)Which type of BTC address do you use.

Q8)Purpose of "OP_RETURN" opcode.

Q9)What is the best exchange in your opinion.

Q10)Are you a dev?