From 10cfe7b9c2643e4395e739414162823dc95451f3 Mon Sep 17 00:00:00 2001 From: drk Date: Mon, 15 Sep 2025 16:49:46 -0500 Subject: [PATCH 1/2] initial commit of subsidy mining --- qip-0015.md | 441 ++++++++++++++++++++++++++++++++++++++++++++++++++++ qip-0016.md | 377 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 818 insertions(+) create mode 100644 qip-0015.md create mode 100644 qip-0016.md diff --git a/qip-0015.md b/qip-0015.md new file mode 100644 index 0000000..254405b --- /dev/null +++ b/qip-0015.md @@ -0,0 +1,441 @@ +# Merge-Mined Transactions # + +
+  QIP: 15
+  Layer: Protocol
+  Title: Workshares
+  Author: kiltsonfire
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/quainetwork/qips/wiki/Comments:QIP-0015
+  Status: Draft
+  Type: Standards Track
+  Created: 2024-08-15
+  License: BSD-2-Clause
+
+ +## Abstract ## + +This QIP defines the process and protocol changes required to allow the +for workshares. + +## Motivation ## + +Workshares allow for the following: +1) Increase the frequency of hashrate samples to decrease finalization time +2) Paying miners more frequently to lower the incentive to particpate in pools +3) Creates a DDOS resistant mechanism for propagating groups of transactions +4) Creates an incentive for miners to propagate transactions + +## Specification ## + +### Overview ### + +The introduction of workshares creates a single +mechanism which solves a number of problems in the current consensus design. +From an incentive standpoint, it accomplishes three things. First, it makes PoEM +become Nash equilibrium. Second, it creates an incentive for miners to propagate +transactions. Third, it decreases the incentive to join a mining pool because +it allows smaller miners to get paid more frequently. + +From a technical perspective, it accomplishes an additional four things. First, +it allows for faster finalization by sampling the hashrate of the network at a greater +frequency, thus lower the uncertainty in the measurement, and increasing the rate +of statistical finalization. Second, workshares provide a convenient wrapper which +can be used to propagate transactions through the network in a way that is resistant +to distributed denial of service attacks (DDOS). This is done by requiring transactions +to be referenced by a workshare before letting that transaction propagate in the open +network. Third, using workshares to effectively group transactions prior to broad propagation +reduces the number of packets and replication of those packets in the network thus reducing +the overall node processing and bandwidth requirements. Fourth, it creates a more concise +reference object that can be used to represent uncle blocks. + +### Impact on Header ### + +It is proposed that a new object is introduced called the workobject. The workobject is +composed of a workobject header and a body which has references to additional objects. The inclusion +of certain objects within the body will create different workobject views that can +be propagated to various particpants depending on their role in the network. + +The workobject will have the following fields: + +### `WorkObject` Struct: + +| Field | Type | +|-----------|--------------------| +| woHeader | *WorkObjectHeader | +| woBody | *WorkObjectBody | + +### `WorkObjectHeader` Struct: + +| Field | Type | +|----------------------|-----------------| +| headerHash | common.Hash | +| parentHash | common.Hash | +| number | *big.Int | +| difficulty | *big.Int | +| primeTerminusNumber | *big.Int | +| txsHash | common.Hash | +| primaryCoinbase | common.Address | +| location | common.Location | +| mixHash | common.Hash | +| time | uint64 | +| nonce | BlockNonce | +| lock | uint8 | + +### `WorkObjectBody` Struct: + +| Field | Type | +|------------------|----------------------| +| header | *Header | +| transactions | Transactions | +| outboundEtxs | Transactions | +| uncles | []*WorkObjectHeader | +| manifest | BlockManifest | +| interlinkHashes | common.Hashes | + +Note here that the header contained in the body is a subset of what was +classically referred to as the header in Ethereum. This is the object that +has all of the transaction and state commitments. The sealHash for the workObject will +be computed by hashing all of the fields except for the Nonce. Mining of the +workObject will take place by grinding the Nonce field. Once a workObject is found +the producer will be able to determine if it is a workshare or a Block based on the +entropy threshold acheived. This workObject can then be combined with additional data +to create a workshare, block, or another workobject view. + +### Paying Workshares ### + + +### Propagating Transactions ### + +This QIP suggests a base fee for processing, with transaction order determined +by worked ProgPow hashes. Transactions would be merge-mined with blocks, +and the mining work done on a transaction would dictate its order in a block. +The most worked transactions would be prioritized. Algorithmically, this +involves sorting ProgPow hashes within each block based on their values, +with lower hashes processed first. + +#### Sorting Criteria and Algorithmic Application #### + +Let $H = \{ hash_{i,j} \mid 1 \leq i \leq n, 1 \leq j \leq m_i \}$ be a set +of cryptographic hash values, where $n$ is the number of blocks in the chain +and $m_i$ are the transactions in the $i^{th}$ block. + +Given the defined set of hashes $H$, we apply a sorting algorithm to order the hashes +within each block. Specifically, for each $i^{th}$ block, we ensure +the order of the transactions follows the criterion $hash_{i,j} < +hash_{i,j-1}$, with the lowest value of $hash_{i,j}$ being processed first in +the $i^{th}$ block. + +``` +Algorithm 1 Sorting Hashes within Blockchain Blocks +1: H +2: function constructor(H′) +3: H ← H′ ▷ Set of hash values H +4: end function +5: function sortHashes(H) +6: for each block i from 1 to n do +7: for each transaction j from 1 to m_i do +8: Perform insertion sort on H[i] based on the hash order: +9: if hash_{i,j} < hash_{i,j-1} then +10: Swap hash_{i,j} with hash_{i,j-1} +11: end if +12: end for +13: end for +14: end function +``` + +This would mean that to MEV a MMTX, say sandwich or front-run, a MEV bot would +have to mine a transaction with appropriate order around the targeted +transaction. This may seem trivial for transactions which do not have +significant amounts of work, however, sandwiching a tx would require finding a +mined tx which is in front of and behind the target transaction. Moreover, any +MEV bot would have to execute these attacks in real-time. + +## Weighting of MMTXs ## + +In addition to organizing transactions based on their hash values, the protocol +incorporates the work done on each transaction into the overall entropy of the +block. This approach means that blocks containing transactions with a higher +amount of work, and therefore lower entropy, are more likely to be recognized +as the primary block in the chain. This alignment between transaction ordering +and the growth of the longest chain is essential for maintaining network +integrity. + +However, this method requires careful consideration to prevent potential +exploits. If miners can mine transactions independently and include them +arbitrarily in future blocks, they could amass a large number of mined +transactions to dominate block creation. To counter this, the block's hash, +with which a transaction is merged-mined, is used as a reference point. The +contribution of a transaction's weight to a block's weight diminishes based on +the age difference between the transaction and the block. This mechanism +incentivizes miners to include transactions in their blocks as quickly as +possible. + +An additional layer of complexity arises with merge-mined transactions. These +transactions can only be included if they are merged-mined with a canonical +block. By mining on top of an already existing block, the work invested in +merge-mined transactions serves to validate and reinforce the legitimacy of +that block. This process not only enhances the security of the chain through +implicit verification but also contributes to the overall chain entropy. + +The decay in the contribution of a transaction's work to a block's entropy over +time is also an important factor. The further away a transaction is from the +current chain tip, the less it contributes to the block's entropy. Therefore, +it's proposed that the weight of a transaction's work should decrease by half +for each block that passes after it becomes eligible for inclusion. This +approach encourages producers of merge-mined transactions to reference the most +recent block, ensuring their transactions are included promptly. It also +motivates miners to quickly include valid merge-mined transactions in their +blocks, maximizing the total entropy and thereby strengthening the blockchain. + +### Formal Definitions ### + +- Let $Tx_{i,n}$ denote a MMTX, where $i$ is the block index referenced by the +MMTx, $n$ is the current block index, and $j$ is the index for each MMTx +referencing block $i$ included in block $n$. +- Define $S_{int}$ as the bits of entropy achieved from mining a block, and +$S_{target}$ as the entropy target in bits. A block is successfully mined when +the condition $S_{int} > S_{target}$ is met. + +#### Transaction Entropy Computation #### + +The transaction entropy for a set of transactions included in block $i$ is computed as follows: + +$$ x_{tx,i,j} = log(k/hash_{tx,i,j}) $$ + +$$ S_{tx,i} = \sum_{l=i-m}^{i} \frac{1}{2^{l}} \times e^{-S_{int,i}} \sum_{j=0}^{q_i} \frac{x_{tx,i,j}}{e^{-x_{tx,i,j}}} $$ + +In this expression: + +$k$ represents the field size. $q_i$ denotes the number of transactions in +block $i$, and $m$ is the depth of computation for the transactions +contributing to the block entropy. + +#### Total Block Entropy ### + +The total entropy of a block is given by: + +$$ S_{block,i} = S_{tx,i} + S_{int,i} + S_{block,{i-1}} $$ + +Although, the entropy of MMTx could be calculated going all the way back to +genesis, from the view of practical computations the depth of computation, $m$, +should be limited to a practical value. It is proposed that this could be set +to m=16. This would provide a mechanism wherein latent transactions would still +add entropy but would prevent the entropy computation from becoming +impractical. + +Additionally, it should be noted that the expected maximum contribution of +transactions to the block entropy total is the square of the intrinsic +threshold. For example, if $S_{target} = 20$ then $S_{tx,i}$ could be upto +400. + +## MMTX propagation incentives ## + +Counting the work of transactions towards the weight of a block can have +unintended consequences. Specifically, it might motivate miners to hold back +transactions with substantial work to gain an advantage in block mining. This +could negatively impact the network since blocks containing unpropagated +transactions take longer to verify and unpropogated transaction will provide +the miner that includes it an advantage over other miners which is not +proportional to their hashrate. + +This issue is partially mitigated by two factors. First, if the inclusion of +unpropagated transactions significantly delays block validation, the block is +more likely to be rejected (become an uncle block), penalizing the miner +responsible. Second, users who broadcast transactions with a substantial amount +of work are motivated to ensure rapid network propagation of their +transactions, increasing the likelihood of their inclusion in a block with high +priority. + +However, if these incentives aren't enough, the marginal cost of mining an +MMTX can be changed with the demand for interblock ordering. As long as the +marginal cost of MMTX production is not allowed to be zero, there will always +be an incentive to propogate MMTXs. + +### MMTX variable cost ### + +When a MMTX is constructed to allow the work to be counted for both a +transaction and a block, an issue arises due to the zero marginal cost of +reusing the hash to mine a transaction that was going to mine a block. This is +also the origin of potential withholding attacks when mined transactions are +introduced. To eleviate these issues, it is proposed that a new merge mining +scheme is introduced which allows MMTX marginal cost of production to decrease +with increased demand for transaction ordering. Thus a new mechanism is +proposed that will change the percentage of work that can count torwards merge +mined blocks. This will prevent a withholding incentive while also creating a +mechanism that will guarantee that the blockchain remains lively when there is +high demand for ordering. The goal is to make it so that the marginal cost of +mining a transaction is high when demand for ordering is low, and conversley +the marginal cost for mining is low when the demand for ordering is high. It +is important to note, that the marginal cost cannot allowed to be zero else the +withholding incentives will be reintroduced. + +#### Secondary threshold criteria for MMTX block #### + +A secondary threshold can be used to establish a criteria for determining if a +share meets the block criteria and this criteria can be adjusted by what is in +the proposed block dynamically to ensure that the chain always remains lively. +The secondary threshold criteria will be based on the trailing zeros of the +hash. Specifically, the criteria to become an MMTX block will be met if: + +$$ TX_{hash,val} < B_{mmtx,t} $$ + +where $ TX_{hash,val} = TX_{hash}[end-2:] $ or more simply the last two bytes +in the hash, and the $ B_{mmtx,t} $ is the block threshold for the MMTTX to be +valid. The block threshold $ B_{mmtx,t} $ will be adjusted such that the +threshold is high when ordering demand is low and gets lower as ordering demand +increases. This will ensure that blocks remain lively even if there is high +instantaneous changes in demand for mined transactions. The block threshold +will be calculated as follows: + +$$ B_{mmtx, t} = t_{max} * \frac{\Delta S_{tx}}{\Delta S_{int} + \Delta S_{tx}} $$ + +where $t_{max} = 2^{16} - 2^{12}$ to ensure there is always a marginal cost to +an MMTX. The $B_{mmtx,t}$ threshold can be computed instantaniously and adjust +to the changes in ordering demand in real-time. NOTE: That because a MMTX +commits to a block the value of $B_{mmtx,t}$ is deterministic and cannot be +changed without changing the commitment or the work done on that commitment, ie +the workObject. + +It is interesting to note the impact of the block expectation time on the +change in $B_{mmtx,t}$ with the total work included in the block. Specifically, +an empty block has the nominal expectation time. The block time will increase +to maximum of 2 times the expectation time before it logorithmically approaches +the nominal expectation time as the block continues to fill. This will actually +allow blocks to slow down when there is a high change in demand of ordering, +but also gaurantee liveliness as the demand continues to grow. + +## WorkObject ## + +The interesting implication of MMTX is the creation of a new datastructure that +will be referred to as a workedObject. All data that may be inserted or appended +to the blockchain highest abstract form is now a workObject. More specifically, +a MMTX must take the form of a workObject. Depending on the weight of the +workObject, it will become either a header or a MMTX. + +### Impact on Header ### + +The fields that will be needed to compute a workObject's work, or entropy reduction, +need to be removed from the header so that they are not needlessly replicated. + +The fields that will be removed from the header are as follows: + +| Field | Type | +|-------------|---------------| +| ParentHash[2] | common.Hash | +| Number[2] | *big.Int | +| Nonce | uint64 | + +The following fields will be renamed: + +| Old Field | New Field | +|-------------|---------------| +| ParentHash[] | DomParentHash[] | +| Number[] | DomNumber[] | + +### WorkObject Structure ### + +| Field | Type | +|-------------|---------------| +| HeaderHash | common.Hash | +| ParentHash | common.Hash | +| Number | *big.Int | +| TxHash | common.Hash | +| Nonce | uint64 | + +The astute reader will notice that the fields that were deleted from the header +are now included in the workObject structure. The sealHash for the workObject will +be computed by hashing all of the fields except for the Nonce. Mining of the +workObject will take place by grinding the Nonce field. Once a workObject is found +the producer will be able to determine if it is a MMTX or a Block based on the +entropy threshold acheived. This workObject can then be combined with either the +corresponding Header or Transaction body to create either an MMTX or a block. +The MMTX must then be signed by the appropriate private key and the MMTX and +the signature can be transmitted to form a transaction. If a block is achieved, +the workObject can be combined with the header and optionally the block body to +produce a valid header or valid block and transmitted with no further +processing. + +## Effect of MMTX on Adversarial Resiliance ## + +In PoW systems it is shown in {Everything is a Race and Nakamoto Always Wins} +that all attacks on safety of a PoW blockchain can be simplified to a private +mining attack. This means that in a theoretical network a PoW chain has +adversarial resiliance if $(1-\beta) > 0.5$. This is were the classical +statement about being resiliant to a %51 attack originates. However, moving +beyond the simple analysis, accounting for the fact that the honest majority +has a disadvantage due the coordination delay, $\Delta$, it has been shown this +decreases to 33% adversarial resiliance. The interesting thing to note here is +the effect of the delay, $d_{tx,i,j}$, on the private mining attack. +Specifically, if $\max(d_{tx,i,j}) > \Delta$ the network delay can be offset by +the processing delay associated with MMTXs which a private miner will need to +produce in order to create a competitive privately mined chain greater than +length 1. Therefore, it is likely that PoEM with MMTX will create a consensus +mechanism that is resiliant to attackers that control the majority of the +hashrate. + +There is however, a contravening consideration, which is the ability for late +joining clients to join the network. Specifically, will a late joining client +or a non-nefarious network partition be able to catch up to the honest +majority? The answer to this questions depends on the number of threads that a +node has to validate MMTXs relative to the number of MMTXs included in a block +on expectation. + +For example, if a honest node has a modern GPU, it will have > 16,000 threads. +Each on of these could be used to validate the SDF of MMTXs in parallel. Thus +if the average block has 2,000 MMTXs and the average $mean(d_{tx,i,j}) = 1/2 * Block_{time}$ +a late joining client would be able to catch up to the network at +a rate $r$, which is 1/16th of clock-time in this example. This could be +further improved by running a client with a more performant GPU or multiple +GPUs. However, the ability for a client to catch up will only be compressed by +honest nodes to a finite degree. This means that if an attacker is running a +private chain in which they are creating and referencing MMTXs to enable the +creation of a competitive chain, they will suffer a processing delay penalty +for a fork of depth, $f$, of $d_{fork} = f*Block_{time}*\bar{r}$. This offsets +the disadvantage of the honest majority due to the coordination delay and will +incrase the adversarial resiliance of the system to > 51% if +$Block{time}*\bar{r}>\Delta$. + +### Impact of MMTX on MEV ### + +Lets explore what would happen here if there was a transaction that can be +exploited by being front run by a MEV bot. All MEV exploits normally require a +MEV bot to get at least 1 tx in-front of the $tx_{MEV}$ they are trying to +exploit. To front run $tx_{MEV}$ the MEV bots would have the option of mining a +transaction which has a greater workObject than tx_{MEV} or by attempting to mine +an alternate chain tip. Lets assume that there are at least 2 competing MEV +bots, Alice and Bob, which have roughly the same amount of hash power which in +total are both less than 50% of the hash rate. If Alice finds a MMTX with a +workObject greater than the mined $S_{tx,Alice} > S_{tx,MEV}$, Bob will need to +mine his transaction such that $S_{tx,Bob} > S_{tx,Alice}$. This back and forth +competition will proceed until Alice, Bob, or some other miner finds a entropy +of $S_{tx} > S_{int}$ which would lead to the mining of a new block. + +Lets say that at this point in time Alice has managed to order her transaction +in front of Bobs. That means that the block will have a block entropy of at +least $S_{block} >= S_{int} + S_{tx,Alice} + S_{tx,MEV}$. + +If Bob is unsatisfied with this result he can try and mine a new tip which is a +fork with the block that was just mined. Bobs expected entropy for the nth +block will be $S_{block,bob} >= S_{int} + S_{tx,bob} + S_{tx,MEV}$. However, we +can assume that Bob will take some period of time, $\delta$ after Alice +produces her block to produce a workObject that is greater than Alice's as well +as produce a block which meets the intrinsic block entropy threshold. + +That means that for the time $\delta$ Bob is additionally competing against the +honest network hashrate $\gamma * (1-\beta)$ where gamma is the total network +hashrate and Bob's hashrate being the dishonest party is $\beta$. This means +that we can quantify Bob's disadvantage in producing a chain with greater +entropy with his perferred transaction ording he would need to have greater +than 50% of the network hashrate, or would need to achieve a "lucky" result +that is outside the expectation value. + +Moreover, after Bob produces his block $n$, if he decided to continue mining to +try and achieve a win at $n+1$ he would not have any $S_{tx,i}$ to add to the +weight of his next block ensuring that he will lose if the $n+1$ honest block +has any MMTX workObjects included that are not produced directly produced by +Alice. + +## Copyright ## + +This QIP licensed under the BSD 2-clause license. diff --git a/qip-0016.md b/qip-0016.md new file mode 100644 index 0000000..9c62d17 --- /dev/null +++ b/qip-0016.md @@ -0,0 +1,377 @@ +# QIP-16 — SOAP: Subsidy Mining via **Traditional AuxPoW** (no LTC↔DOGE merge mining) + +**Status:** Draft +**Authors:** +**Last updated:** 2025-09-15 +**Scope:** Quai mainnet/testnets +**Audience:** core node implementers, pool/template operators + +--- + +## 0. Abstract + +SOAP (“**S**ubsidized **O**pen-market **A**cquisition **P**rogram”) imports external Proof-of-Work from **Bitcoin-family donors** (BTC, LTC, DOGE, RVN) to fund a **protocol coinbase payout (QADDR)** and to **commit** a Quai WorkObject reference inside donor blocks. Quai continues to produce blocks with **KAWPOW** only. **Auxiliary shares** from other algos (SHA256d, Scrypt, …) may be *included* in Quai blocks for a QUAI payout, governed by a **separate DAA** targeting **3 included shares per block** with a hard cap of **9**. + +Donor participation is verified on Quai using a **traditional AuxPoW-style proof**: donor **header (80B)** + **coinbase tx** + **merkle branch**. We do **not** rely on LTC↔DOGE merged mining; DOGE and LTC are mined independently. + +--- + +## 1. Goals + +- Do not allow any non-KAWPOW algorithm to author Quai blocks. +- Do not require miners to run donor chain state. +- Do not depend on pool code changes beyond standard Stratum v1 job fields. + +--- + +## 2. Terminology + +- **WorkObject (WO):** The unit Quai miners build and commit to in donor blocks. +- **QADDR:** Protocol-specified donor payout scriptPubKey; 100% of donor subsidy+fees must pay QADDR. +- **SOAP push:** A fixed push of `"SOAP" 0x01 || 32B WO_HASH` placed in the **coinbase input scriptSig**. +- **AuxPow (in this spec):** A donor proof object included in a Quai block: `{header, coinbase, merkle branch, index, chain_id, height}`. + +--- + +## 3. On-chain objects (Quai) + +### 3.1 WorkObject (wire) + +```go +type WorkObject struct { + woHeader *WorkObjectHeader + woBody *WorkObjectBody + tx *Transaction + auxpow *AuxPow // optional; donor proof (this spec) +} + +``` + +### 3.2 AuxPow (donor proof) + +> “Traditional AuxPoW structure” = SPV-style: donor header + coinbase + merkle path. No LTC→DOGE merge minining. + +```go +type ChainID uint16 // 1=BTC, 2=LTC, 3=DOGE, 4=RVN (extensible) + +type AuxPow struct { + Version uint8 + Chain ChainID + Height uint32 // donor height (informational/sanity) + Header []byte // 80-byte donor header + Coinbase []byte // raw coinbase transaction + Branch [][]byte // merkle siblings from coinbase txid to merkle root + Index uint32 // coinbase position in its merkle level (0/1 bit ordering) + // Expectations (encoded or implied by network params) + QAddrScript []byte // exact scriptPubKey bytes required for output[0] + // The commitment format we expect in coinbase scriptSig: + // PUSHDATA(height) PUSHDATA("SOAP" 0x01 || 32B WO_HASH) PUSHDATA(extranonce1) PUSHDATA(extranonce2) +} + +``` + +--- + +## 4. Donor coinbase **consensus requirements** + +For a donor block to count: + +1. **Payout rule (MUST):** The coinbase **first spendable output** MUST pay **100% subsidy + fees** to **QADDR** (`QAddrScript` exact bytes). + - (Optional network param: allow additional zero-value OP_RETURN outputs.) +2. **Commitment rule (MUST):** The coinbase **input scriptSig** MUST include a fixed push: + ``` + PUSHDATA("SOAP" 0x01 || 32B WO_HASH) + ``` + placed after the BIP34 **height** push, before or after pool extranonces. + ScriptSig total size MUST be **2..100 bytes** (Bitcoin-family consensus). +3. **Header inclusion (MUST):** The AuxPow proof MUST show `txid(coinbase)` included in `Header.merkleRoot` via `Branch, Index`. +4. **(Optional) Donor PoW check:** Nodes MAY verify donor header PoW under that chain’s rules (policy toggle). +5. **Freshness (RECOMMENDED):** The donor `Height` SHOULD be within **Δ blocks** of a committee-advertised tip (policy; not consensus). + +> **Rationale:** scriptSig is universally available, keeps miners stock, and avoids OP_RETURN size/policy variability across fleets. + +--- + +## 5. Quai consensus changes + +1. **Block PoW algorithm:** **KAWPOW** ONLY for block authoring. +2. **AuxPow binding (MUST):** If `auxpow != nil`, `woHeader.auxCommit = H("QUAI:AUXv1" || serialize(auxpow))` and `auxCommit` MUST be included in the Quai block header preimage. +3. **AuxPow effect (policy → can be elevated later):** + - **Soft mode (RECOMMENDED initial):** Valid AuxPow adds reward/weight bonus (see §7). No liveness coupling. + - **Epoch mode (optional future):** Require ≥1 valid AuxPow per **E** Quai blocks to avoid reward decay. +4. **Shares (MUST):** Non-KAWPOW algos **cannot** produce Quai blocks; they produce **shares** only (§6). + +--- + +## 6. WorkShares (using existing WorkObject) + +### 6.1 Classification & validity + +A **WorkObject** `wo` is classified at validation time as: + +- **Block:** if the KAWPOW seal on `wo` meets the current block target. +- **WorkShare:** if **not Block**, and `wo.auxpow` passes **VerifyAuxPow(wo)** and the donor header PoW satisfies the per‑chain **share target** `T_share[wo.auxpow.Chain]`. +- **Invalid:** otherwise. + +**Tip binding / freshness:** Because `woHeader.parentHash` binds the object to the current Quai tip, separate tip-commit fields are unnecessary. Nodes SHOULD reject WorkShares older than **TTL = 2** Quai blocks (policy). + +### 6.2 Scoring & normalization + +Two options are supported; implementers SHOULD start with **Equal Weight** for simplicity. + +- **Equal Weight (default):** Every valid WorkShare counts as `w_norm = 1`. +- **Difficulty‑proportional (optional):** Let `D_share[chain]` be the difficulty implied by `T_share[chain]`, and `D_sol` be the difficulty implied by the donor solution’s PoW (stateless from `Header`). Score + `w_norm = min(D_sol / D_share[chain], W_max)`. + +### 6.3 Inclusion & ordering + +- Producers MUST include up to **S_max = 9** highest‑`w_norm` WorkShares. +- Tie‑break by arrival time. +- MAY enforce a per‑chain soft cap (e.g., ≤ 3) to avoid dominance. + +### 6.4 Rewards (QUAI-only) + +- **Each included WorkShare:** pays its submitter under Equal‑Weight, or proportionally to `w_norm` under Difficulty‑proportional. +- **Payout address:** the QUAI address is taken from `wo.woHeader.primaryCoinbase` (no extra fields required). + +### 6.5 DAA for WorkShares (per‑chain) + +Maintain a per‑chain target `T_share[chain]` to hit **S_target = 3** WorkShares per block on average (cap `S_max = 9`). + +- Target arrival rate `λ_inc = S_target / τ_b` (Quai block interval). +- Choose desired mix `φ_chain` (Σφ=1) and over‑provision `κ≥1` (e.g., 2.0). + `λ_chain = φ_chain · κ · λ_inc`. +- ASERT‑style controller on `T_share[chain]` from inter‑arrival times of **accepted WorkShares** for that chain: + `T_new = T_old · 2^((Δt − 1/λ_chain)/h)` with half‑life `h ∈ [5,10]·(1/λ_chain)`. +- Slowly adapt normalization β (only if using Difficulty‑proportional scoring) to keep realized mix near `φ_chain`. + +--- + +## 7. Reward & verification pseudocode + +The only layout rule now is: +**SOAP must appear immediately after the BIP34 height push and entirely in the fixed (non-extranonce) part of the coinbase scriptSig.** + +--- + +# 7. Verification + +This defines **consensus** checks when AuxPoW requires a **quorum-signed AuxTemplate** and strict **correspondence** between that template, the donor **header**, and the **coinbase**. SOAP placement is minimal: **height push → SOAP push → (extranonce pushes, if any).** + +## 7.1 Data shapes + +```go +type AuxTemplate struct { + // Enforced correspondence + ChainID ChainID // must match ap.Chain + PrevHash [32]byte // must equal donor_header.hashPrevBlock + PayoutScript []byte // must equal coinbase.outputs[0].scriptPubKey + ScriptSigMaxLen uint16 // ≤100; template may be tighter + + // Advisory (policy/UX; NOT consensus unless elevated) + Extranonce2Size uint8 + NBits uint32 + NTimeMask NTimeMask + + // Quorum signatures over CanonicalEncode(AuxTemplate) WITHOUT Sigs + Sigs []SignerEnvelope // (SignerID, Signature) +} +``` + +> **Signatures:** sign `SHA256d("QUAI:SOAP:AUXTEMPLATEv1" || CanonicalEncode(tmpl_without_Sigs))`. +> No embedded template hash field; nodes recompute the digest for signature checks. + +## 7.2 Top-level verification + +```go +func VerifyWorkObjectAuxPow_WithAuxTemplate(wo *WorkObject, tmpl *AuxTemplate, params Params) error { + ap := wo.auxpow + if ap == nil { return ErrNoAuxPow } + + // (1) SPV: coinbase ∈ donor header’s Merkle root + if !VerifyMerkle(ap.Coinbase, ap.Branch, ap.Index, HeaderMerkleRoot(ap.Header)) { + return ErrBadAuxMerkle + } + + // (2) SOAP: scriptSig must be [BIP34 height][SOAP("SOAP\x01||WO_HASH")][... extranonce pushes ...] + cb := ParseTx(ap.Coinbase) + if !HasSoapImmediatelyAfterHeight(cb.ScriptSig, WOHash(wo)) { + return ErrMissingOrMisplacedSOAP + } + + // (3) Quorum signatures over canonical AuxTemplate (no embedded hash) + digest := AuxTemplateDigest(*tmpl) + if !VerifyQuorumSigs(tmpl.Sigs, digest, params.ActiveSignerSet, params.QuorumThreshold) { + return ErrBadQuorum + } + + // (4) Correspondence: template ↔ donor header & coinbase + if tmpl.ChainID != ap.Chain { return ErrChainMismatch } + + donorPrev := DonorHeaderPrevHash(ap.Header) // hashPrevBlock from 80B header + if !bytes.Equal(tmpl.PrevHash[:], donorPrev[:]) { + return ErrPrevhashMismatch + } + + if len(cb.Outputs) == 0 || !EqualScript(cb.Outputs[0].Script, tmpl.PayoutScript) { + return ErrWrongPayoutScript + } + + // (5) Coinbase scriptSig bound (≤100 consensus; template may be tighter) + if ScriptSigLen(cb) > min(uint16(100), tmpl.ScriptSigMaxLen) { + return ErrScriptSigTooLong + } + + // (Optional policy — NOT consensus unless elevated) + // if params.EnforceShareTarget && !VerifyDonorPoW(ap.Chain, ap.Header, params.Tshare[ap.Chain]) { + // return ErrBelowShareTarget + // } + + return nil +} +``` + +## 7.3 Helpers + +```go +func AuxTemplateDigest(t AuxTemplate) [32]byte { + enc := CanonicalEncode_WithoutSigs(t) + return SHA256d( append([]byte("QUAI:SOAP:AUXTEMPLATEv1"), enc...) ) +} + +func VerifyMerkle(coinbase []byte, branch [][]byte, index uint32, root [32]byte) bool { + h := DblSHA256(coinbase) + for i, sib := range branch { + if (index>>uint(i))&1 == 0 { + h = DblSHA256( append(h[:], sib...) ) + } else { + h = DblSHA256( append(sib, h[:]...) ) + } + } + return bytes.Equal(h[:], root[:]) +} + +// Minimal placement rule: SOAP push must be the SECOND push (right after BIP34 height) +func HasSoapImmediatelyAfterHeight(scriptSig []byte, expectWO [32]byte) bool { + pushes := ParseScriptSigPushes(scriptSig) // returns the sequence of PUSHDATA payloads + if len(pushes) < 2 { return false } + if !IsBIP34HeightPush(pushes[0]) { return false } + return IsSoapPush(pushes[1], expectWO) +} + +// A SOAP push is exactly "SOAP\x01" || 32-byte WO hash (37 bytes total) +func IsSoapPush(b []byte, expectWO [32]byte) bool { + if len(b) != 37 { return false } + if !bytes.Equal(b[0:5], []byte{'S','O','A','P',0x01}) { return false } + return bytes.Equal(b[5:], expectWO[:]) +} +``` + +## 7.4 Notes + +* **Consensus requires:** SPV inclusion, SOAP presence/placement, **quorum-signed AuxTemplate**, and correspondence (`ChainID`, `PrevHash == hashPrevBlock`, `outputs[0] == PayoutScript`, `ScriptSigLen ≤ bound`). +* **No freshness rule** at consensus; a stale template won’t match current `hashPrevBlock` anyway. + +--- + +If you want, I can splice this into your full spec and export a fresh Markdown file. + +--- + +## 8. Donor **coinbase construction** (template/pool) + +**ScriptSig (no LTC↔DOGE AuxPoW header in this spec):** +``` +PUSHDATA(BIP34_height) +PUSHDATA("SOAP" 0x01 || 32B WO_HASH) // fixed by server; miners do NOT change +PUSHDATA(extranonce1) // server +PUSHDATA(extranonce2) // miner, size typically 4–8 bytes +``` +- **Keep total scriptSig ≤ 100 bytes.** +- Leave **witness-reserved 32B** (BTC/LTC segwit) untouched (it lives in the coinbase *witness*, not scriptSig). + +**Outputs:** +1) `value = subsidy+fees` → **QADDR** (exact `QAddrScript`). +2) *(Optional)* zero-value **OP_RETURN** for an audit breadcrumb; not required by consensus. + +**Stratum v1 job fields (unchanged):** +- `coinb1` ends after SOAP push and before miner’s `extranonce2`. +- `coinb2` starts at `extranonce2` placeholder and contains the rest of scriptSig + outputs. +- `extranonce1`, `extranonce2_size` (keep 4–8 for ASIC compatibility), `merkle_branch[]`, `prevhash`, `version`, `nbits`, `ntime`. + +**Miner behavior:** builds coinbase (`coinb1||ex1||ex2||coinb2`), computes txid, folds `merkle_branch` to root, hashes header nonce/time. + +--- +## 9. Parameters + +## 10. Security & liveness + +- **No liveness coupling:** AuxPow is optional (soft mode). Blocks can be mined with zero shares included. +- **ScriptSig bounds:** enforce 2..100-byte consensus window; reject oversize coinbases. +- **DoS control:** bound AuxPow size (~1–2 KB typical), share size (≤~300B), per-block share cap (`S_max`). +- **Replay safety:** WO hash includes a **domain tag**; optionally add an 8-byte Quai tip prefix inside the SOAP push if desired. + +--- + +## 11. Compatibility notes + +- **BTC/LTC:** SegWit witness commitment uses the coinbase **witness reserved value**, not scriptSig; unaffected. +- **DOGE (no LTC merge):** Treat like LTC: its own coinbase scriptSig/outputs; same SOAP push fits. +- **RVN (KAWPOW):** No SegWit; scriptSig ≤100 still applies. KAWPOW-specific fields are irrelevant for donor proof. + +--- + +## 12. Deployment plan + +1. **Phase A:** Ship sharepool, DAA, QUAI payouts; accept AuxPow in soft mode (bonus only). +2. **Phase B:** Provide public donor **template relays** (BTC/LTC/DOGE/RVN) that fix QADDR + SOAP push; miners can point rigs with zero firmware changes. +3. **Phase C (optional):** Make AuxPow participation economically stronger (higher bonus) or add epoch requirement with decay. + +--- + +## 13. Test guidance (devnets/testnets) + +- Stand up a donor regtest/testnet node; generate coinbase-only templates with SOAP push; validate AuxPow in Quai. +- Ensure scriptSig length stays under 100 **with** height + SOAP + ex1 + ex2. +- Verify that modifying only `extranonce2` on the miner recomputes Merkle root correctly via the provided `merkle_branch`. + +--- + +## 14. Reference encodings + +**SOAP scriptSig push (hex):** +``` +25 53 4f 41 50 01 <32-byte WO_HASH> +^^ len=37 "SOAP" 01 +``` + +**OP_RETURN audit (optional)** +``` +6a 25 53 4f 41 50 01 <32-byte WO_HASH> +OP_RETURN len=37 "SOAP" 01 +``` +*(Do not rely on OP_RETURN for consensus in this draft; SOAP-in-scriptSig is normative.)* + +--- + +## 15. Open questions / future work + +- Whether to elevate donor header PoW verification from policy → consensus. +- Optional inclusion of an 8-byte **Quai tip prefix** in SOAP push for tighter replay binding. +- Extending AuxPow to support compact proofs (NiPoPoW/FlyClient) if donor policy limits coinbase sizes. + +--- + +## 16. Appendix — Minimal verifier sketch + +```go +func VerifyAuxPowStrict(ap *AuxPow, expectWO Hash, expectQ Script) error { + if !VerifyMerkle(ap.Coinbase, ap.Branch, ap.Index, HeaderMerkleRoot(ap.Header)) { + return ErrBadAuxMerkle + } + cb := ParseTx(ap.Coinbase) + if !PaysExactly(cb, expectQ) { return ErrWrongPayout } + if !HasSoapScriptSig(cb, expectWO) { return ErrMissingSOAP } + return nil +} +``` From 23503e97a22fb76e0c4e7f07a08bfb25b6d60e25 Mon Sep 17 00:00:00 2001 From: gop Date: Thu, 25 Sep 2025 13:05:50 -0500 Subject: [PATCH 2/2] Updated the subsidy mining spec --- qip-0015.md | 441 ---------------------------------------------------- qip-0016.md | 78 +++++----- 2 files changed, 41 insertions(+), 478 deletions(-) delete mode 100644 qip-0015.md diff --git a/qip-0015.md b/qip-0015.md deleted file mode 100644 index 254405b..0000000 --- a/qip-0015.md +++ /dev/null @@ -1,441 +0,0 @@ -# Merge-Mined Transactions # - -
-  QIP: 15
-  Layer: Protocol
-  Title: Workshares
-  Author: kiltsonfire
-  Comments-Summary: No comments yet.
-  Comments-URI: https://github.com/quainetwork/qips/wiki/Comments:QIP-0015
-  Status: Draft
-  Type: Standards Track
-  Created: 2024-08-15
-  License: BSD-2-Clause
-
- -## Abstract ## - -This QIP defines the process and protocol changes required to allow the -for workshares. - -## Motivation ## - -Workshares allow for the following: -1) Increase the frequency of hashrate samples to decrease finalization time -2) Paying miners more frequently to lower the incentive to particpate in pools -3) Creates a DDOS resistant mechanism for propagating groups of transactions -4) Creates an incentive for miners to propagate transactions - -## Specification ## - -### Overview ### - -The introduction of workshares creates a single -mechanism which solves a number of problems in the current consensus design. -From an incentive standpoint, it accomplishes three things. First, it makes PoEM -become Nash equilibrium. Second, it creates an incentive for miners to propagate -transactions. Third, it decreases the incentive to join a mining pool because -it allows smaller miners to get paid more frequently. - -From a technical perspective, it accomplishes an additional four things. First, -it allows for faster finalization by sampling the hashrate of the network at a greater -frequency, thus lower the uncertainty in the measurement, and increasing the rate -of statistical finalization. Second, workshares provide a convenient wrapper which -can be used to propagate transactions through the network in a way that is resistant -to distributed denial of service attacks (DDOS). This is done by requiring transactions -to be referenced by a workshare before letting that transaction propagate in the open -network. Third, using workshares to effectively group transactions prior to broad propagation -reduces the number of packets and replication of those packets in the network thus reducing -the overall node processing and bandwidth requirements. Fourth, it creates a more concise -reference object that can be used to represent uncle blocks. - -### Impact on Header ### - -It is proposed that a new object is introduced called the workobject. The workobject is -composed of a workobject header and a body which has references to additional objects. The inclusion -of certain objects within the body will create different workobject views that can -be propagated to various particpants depending on their role in the network. - -The workobject will have the following fields: - -### `WorkObject` Struct: - -| Field | Type | -|-----------|--------------------| -| woHeader | *WorkObjectHeader | -| woBody | *WorkObjectBody | - -### `WorkObjectHeader` Struct: - -| Field | Type | -|----------------------|-----------------| -| headerHash | common.Hash | -| parentHash | common.Hash | -| number | *big.Int | -| difficulty | *big.Int | -| primeTerminusNumber | *big.Int | -| txsHash | common.Hash | -| primaryCoinbase | common.Address | -| location | common.Location | -| mixHash | common.Hash | -| time | uint64 | -| nonce | BlockNonce | -| lock | uint8 | - -### `WorkObjectBody` Struct: - -| Field | Type | -|------------------|----------------------| -| header | *Header | -| transactions | Transactions | -| outboundEtxs | Transactions | -| uncles | []*WorkObjectHeader | -| manifest | BlockManifest | -| interlinkHashes | common.Hashes | - -Note here that the header contained in the body is a subset of what was -classically referred to as the header in Ethereum. This is the object that -has all of the transaction and state commitments. The sealHash for the workObject will -be computed by hashing all of the fields except for the Nonce. Mining of the -workObject will take place by grinding the Nonce field. Once a workObject is found -the producer will be able to determine if it is a workshare or a Block based on the -entropy threshold acheived. This workObject can then be combined with additional data -to create a workshare, block, or another workobject view. - -### Paying Workshares ### - - -### Propagating Transactions ### - -This QIP suggests a base fee for processing, with transaction order determined -by worked ProgPow hashes. Transactions would be merge-mined with blocks, -and the mining work done on a transaction would dictate its order in a block. -The most worked transactions would be prioritized. Algorithmically, this -involves sorting ProgPow hashes within each block based on their values, -with lower hashes processed first. - -#### Sorting Criteria and Algorithmic Application #### - -Let $H = \{ hash_{i,j} \mid 1 \leq i \leq n, 1 \leq j \leq m_i \}$ be a set -of cryptographic hash values, where $n$ is the number of blocks in the chain -and $m_i$ are the transactions in the $i^{th}$ block. - -Given the defined set of hashes $H$, we apply a sorting algorithm to order the hashes -within each block. Specifically, for each $i^{th}$ block, we ensure -the order of the transactions follows the criterion $hash_{i,j} < -hash_{i,j-1}$, with the lowest value of $hash_{i,j}$ being processed first in -the $i^{th}$ block. - -``` -Algorithm 1 Sorting Hashes within Blockchain Blocks -1: H -2: function constructor(H′) -3: H ← H′ ▷ Set of hash values H -4: end function -5: function sortHashes(H) -6: for each block i from 1 to n do -7: for each transaction j from 1 to m_i do -8: Perform insertion sort on H[i] based on the hash order: -9: if hash_{i,j} < hash_{i,j-1} then -10: Swap hash_{i,j} with hash_{i,j-1} -11: end if -12: end for -13: end for -14: end function -``` - -This would mean that to MEV a MMTX, say sandwich or front-run, a MEV bot would -have to mine a transaction with appropriate order around the targeted -transaction. This may seem trivial for transactions which do not have -significant amounts of work, however, sandwiching a tx would require finding a -mined tx which is in front of and behind the target transaction. Moreover, any -MEV bot would have to execute these attacks in real-time. - -## Weighting of MMTXs ## - -In addition to organizing transactions based on their hash values, the protocol -incorporates the work done on each transaction into the overall entropy of the -block. This approach means that blocks containing transactions with a higher -amount of work, and therefore lower entropy, are more likely to be recognized -as the primary block in the chain. This alignment between transaction ordering -and the growth of the longest chain is essential for maintaining network -integrity. - -However, this method requires careful consideration to prevent potential -exploits. If miners can mine transactions independently and include them -arbitrarily in future blocks, they could amass a large number of mined -transactions to dominate block creation. To counter this, the block's hash, -with which a transaction is merged-mined, is used as a reference point. The -contribution of a transaction's weight to a block's weight diminishes based on -the age difference between the transaction and the block. This mechanism -incentivizes miners to include transactions in their blocks as quickly as -possible. - -An additional layer of complexity arises with merge-mined transactions. These -transactions can only be included if they are merged-mined with a canonical -block. By mining on top of an already existing block, the work invested in -merge-mined transactions serves to validate and reinforce the legitimacy of -that block. This process not only enhances the security of the chain through -implicit verification but also contributes to the overall chain entropy. - -The decay in the contribution of a transaction's work to a block's entropy over -time is also an important factor. The further away a transaction is from the -current chain tip, the less it contributes to the block's entropy. Therefore, -it's proposed that the weight of a transaction's work should decrease by half -for each block that passes after it becomes eligible for inclusion. This -approach encourages producers of merge-mined transactions to reference the most -recent block, ensuring their transactions are included promptly. It also -motivates miners to quickly include valid merge-mined transactions in their -blocks, maximizing the total entropy and thereby strengthening the blockchain. - -### Formal Definitions ### - -- Let $Tx_{i,n}$ denote a MMTX, where $i$ is the block index referenced by the -MMTx, $n$ is the current block index, and $j$ is the index for each MMTx -referencing block $i$ included in block $n$. -- Define $S_{int}$ as the bits of entropy achieved from mining a block, and -$S_{target}$ as the entropy target in bits. A block is successfully mined when -the condition $S_{int} > S_{target}$ is met. - -#### Transaction Entropy Computation #### - -The transaction entropy for a set of transactions included in block $i$ is computed as follows: - -$$ x_{tx,i,j} = log(k/hash_{tx,i,j}) $$ - -$$ S_{tx,i} = \sum_{l=i-m}^{i} \frac{1}{2^{l}} \times e^{-S_{int,i}} \sum_{j=0}^{q_i} \frac{x_{tx,i,j}}{e^{-x_{tx,i,j}}} $$ - -In this expression: - -$k$ represents the field size. $q_i$ denotes the number of transactions in -block $i$, and $m$ is the depth of computation for the transactions -contributing to the block entropy. - -#### Total Block Entropy ### - -The total entropy of a block is given by: - -$$ S_{block,i} = S_{tx,i} + S_{int,i} + S_{block,{i-1}} $$ - -Although, the entropy of MMTx could be calculated going all the way back to -genesis, from the view of practical computations the depth of computation, $m$, -should be limited to a practical value. It is proposed that this could be set -to m=16. This would provide a mechanism wherein latent transactions would still -add entropy but would prevent the entropy computation from becoming -impractical. - -Additionally, it should be noted that the expected maximum contribution of -transactions to the block entropy total is the square of the intrinsic -threshold. For example, if $S_{target} = 20$ then $S_{tx,i}$ could be upto -400. - -## MMTX propagation incentives ## - -Counting the work of transactions towards the weight of a block can have -unintended consequences. Specifically, it might motivate miners to hold back -transactions with substantial work to gain an advantage in block mining. This -could negatively impact the network since blocks containing unpropagated -transactions take longer to verify and unpropogated transaction will provide -the miner that includes it an advantage over other miners which is not -proportional to their hashrate. - -This issue is partially mitigated by two factors. First, if the inclusion of -unpropagated transactions significantly delays block validation, the block is -more likely to be rejected (become an uncle block), penalizing the miner -responsible. Second, users who broadcast transactions with a substantial amount -of work are motivated to ensure rapid network propagation of their -transactions, increasing the likelihood of their inclusion in a block with high -priority. - -However, if these incentives aren't enough, the marginal cost of mining an -MMTX can be changed with the demand for interblock ordering. As long as the -marginal cost of MMTX production is not allowed to be zero, there will always -be an incentive to propogate MMTXs. - -### MMTX variable cost ### - -When a MMTX is constructed to allow the work to be counted for both a -transaction and a block, an issue arises due to the zero marginal cost of -reusing the hash to mine a transaction that was going to mine a block. This is -also the origin of potential withholding attacks when mined transactions are -introduced. To eleviate these issues, it is proposed that a new merge mining -scheme is introduced which allows MMTX marginal cost of production to decrease -with increased demand for transaction ordering. Thus a new mechanism is -proposed that will change the percentage of work that can count torwards merge -mined blocks. This will prevent a withholding incentive while also creating a -mechanism that will guarantee that the blockchain remains lively when there is -high demand for ordering. The goal is to make it so that the marginal cost of -mining a transaction is high when demand for ordering is low, and conversley -the marginal cost for mining is low when the demand for ordering is high. It -is important to note, that the marginal cost cannot allowed to be zero else the -withholding incentives will be reintroduced. - -#### Secondary threshold criteria for MMTX block #### - -A secondary threshold can be used to establish a criteria for determining if a -share meets the block criteria and this criteria can be adjusted by what is in -the proposed block dynamically to ensure that the chain always remains lively. -The secondary threshold criteria will be based on the trailing zeros of the -hash. Specifically, the criteria to become an MMTX block will be met if: - -$$ TX_{hash,val} < B_{mmtx,t} $$ - -where $ TX_{hash,val} = TX_{hash}[end-2:] $ or more simply the last two bytes -in the hash, and the $ B_{mmtx,t} $ is the block threshold for the MMTTX to be -valid. The block threshold $ B_{mmtx,t} $ will be adjusted such that the -threshold is high when ordering demand is low and gets lower as ordering demand -increases. This will ensure that blocks remain lively even if there is high -instantaneous changes in demand for mined transactions. The block threshold -will be calculated as follows: - -$$ B_{mmtx, t} = t_{max} * \frac{\Delta S_{tx}}{\Delta S_{int} + \Delta S_{tx}} $$ - -where $t_{max} = 2^{16} - 2^{12}$ to ensure there is always a marginal cost to -an MMTX. The $B_{mmtx,t}$ threshold can be computed instantaniously and adjust -to the changes in ordering demand in real-time. NOTE: That because a MMTX -commits to a block the value of $B_{mmtx,t}$ is deterministic and cannot be -changed without changing the commitment or the work done on that commitment, ie -the workObject. - -It is interesting to note the impact of the block expectation time on the -change in $B_{mmtx,t}$ with the total work included in the block. Specifically, -an empty block has the nominal expectation time. The block time will increase -to maximum of 2 times the expectation time before it logorithmically approaches -the nominal expectation time as the block continues to fill. This will actually -allow blocks to slow down when there is a high change in demand of ordering, -but also gaurantee liveliness as the demand continues to grow. - -## WorkObject ## - -The interesting implication of MMTX is the creation of a new datastructure that -will be referred to as a workedObject. All data that may be inserted or appended -to the blockchain highest abstract form is now a workObject. More specifically, -a MMTX must take the form of a workObject. Depending on the weight of the -workObject, it will become either a header or a MMTX. - -### Impact on Header ### - -The fields that will be needed to compute a workObject's work, or entropy reduction, -need to be removed from the header so that they are not needlessly replicated. - -The fields that will be removed from the header are as follows: - -| Field | Type | -|-------------|---------------| -| ParentHash[2] | common.Hash | -| Number[2] | *big.Int | -| Nonce | uint64 | - -The following fields will be renamed: - -| Old Field | New Field | -|-------------|---------------| -| ParentHash[] | DomParentHash[] | -| Number[] | DomNumber[] | - -### WorkObject Structure ### - -| Field | Type | -|-------------|---------------| -| HeaderHash | common.Hash | -| ParentHash | common.Hash | -| Number | *big.Int | -| TxHash | common.Hash | -| Nonce | uint64 | - -The astute reader will notice that the fields that were deleted from the header -are now included in the workObject structure. The sealHash for the workObject will -be computed by hashing all of the fields except for the Nonce. Mining of the -workObject will take place by grinding the Nonce field. Once a workObject is found -the producer will be able to determine if it is a MMTX or a Block based on the -entropy threshold acheived. This workObject can then be combined with either the -corresponding Header or Transaction body to create either an MMTX or a block. -The MMTX must then be signed by the appropriate private key and the MMTX and -the signature can be transmitted to form a transaction. If a block is achieved, -the workObject can be combined with the header and optionally the block body to -produce a valid header or valid block and transmitted with no further -processing. - -## Effect of MMTX on Adversarial Resiliance ## - -In PoW systems it is shown in {Everything is a Race and Nakamoto Always Wins} -that all attacks on safety of a PoW blockchain can be simplified to a private -mining attack. This means that in a theoretical network a PoW chain has -adversarial resiliance if $(1-\beta) > 0.5$. This is were the classical -statement about being resiliant to a %51 attack originates. However, moving -beyond the simple analysis, accounting for the fact that the honest majority -has a disadvantage due the coordination delay, $\Delta$, it has been shown this -decreases to 33% adversarial resiliance. The interesting thing to note here is -the effect of the delay, $d_{tx,i,j}$, on the private mining attack. -Specifically, if $\max(d_{tx,i,j}) > \Delta$ the network delay can be offset by -the processing delay associated with MMTXs which a private miner will need to -produce in order to create a competitive privately mined chain greater than -length 1. Therefore, it is likely that PoEM with MMTX will create a consensus -mechanism that is resiliant to attackers that control the majority of the -hashrate. - -There is however, a contravening consideration, which is the ability for late -joining clients to join the network. Specifically, will a late joining client -or a non-nefarious network partition be able to catch up to the honest -majority? The answer to this questions depends on the number of threads that a -node has to validate MMTXs relative to the number of MMTXs included in a block -on expectation. - -For example, if a honest node has a modern GPU, it will have > 16,000 threads. -Each on of these could be used to validate the SDF of MMTXs in parallel. Thus -if the average block has 2,000 MMTXs and the average $mean(d_{tx,i,j}) = 1/2 * Block_{time}$ -a late joining client would be able to catch up to the network at -a rate $r$, which is 1/16th of clock-time in this example. This could be -further improved by running a client with a more performant GPU or multiple -GPUs. However, the ability for a client to catch up will only be compressed by -honest nodes to a finite degree. This means that if an attacker is running a -private chain in which they are creating and referencing MMTXs to enable the -creation of a competitive chain, they will suffer a processing delay penalty -for a fork of depth, $f$, of $d_{fork} = f*Block_{time}*\bar{r}$. This offsets -the disadvantage of the honest majority due to the coordination delay and will -incrase the adversarial resiliance of the system to > 51% if -$Block{time}*\bar{r}>\Delta$. - -### Impact of MMTX on MEV ### - -Lets explore what would happen here if there was a transaction that can be -exploited by being front run by a MEV bot. All MEV exploits normally require a -MEV bot to get at least 1 tx in-front of the $tx_{MEV}$ they are trying to -exploit. To front run $tx_{MEV}$ the MEV bots would have the option of mining a -transaction which has a greater workObject than tx_{MEV} or by attempting to mine -an alternate chain tip. Lets assume that there are at least 2 competing MEV -bots, Alice and Bob, which have roughly the same amount of hash power which in -total are both less than 50% of the hash rate. If Alice finds a MMTX with a -workObject greater than the mined $S_{tx,Alice} > S_{tx,MEV}$, Bob will need to -mine his transaction such that $S_{tx,Bob} > S_{tx,Alice}$. This back and forth -competition will proceed until Alice, Bob, or some other miner finds a entropy -of $S_{tx} > S_{int}$ which would lead to the mining of a new block. - -Lets say that at this point in time Alice has managed to order her transaction -in front of Bobs. That means that the block will have a block entropy of at -least $S_{block} >= S_{int} + S_{tx,Alice} + S_{tx,MEV}$. - -If Bob is unsatisfied with this result he can try and mine a new tip which is a -fork with the block that was just mined. Bobs expected entropy for the nth -block will be $S_{block,bob} >= S_{int} + S_{tx,bob} + S_{tx,MEV}$. However, we -can assume that Bob will take some period of time, $\delta$ after Alice -produces her block to produce a workObject that is greater than Alice's as well -as produce a block which meets the intrinsic block entropy threshold. - -That means that for the time $\delta$ Bob is additionally competing against the -honest network hashrate $\gamma * (1-\beta)$ where gamma is the total network -hashrate and Bob's hashrate being the dishonest party is $\beta$. This means -that we can quantify Bob's disadvantage in producing a chain with greater -entropy with his perferred transaction ording he would need to have greater -than 50% of the network hashrate, or would need to achieve a "lucky" result -that is outside the expectation value. - -Moreover, after Bob produces his block $n$, if he decided to continue mining to -try and achieve a win at $n+1$ he would not have any $S_{tx,i}$ to add to the -weight of his next block ensuring that he will lose if the $n+1$ honest block -has any MMTX workObjects included that are not produced directly produced by -Alice. - -## Copyright ## - -This QIP licensed under the BSD 2-clause license. diff --git a/qip-0016.md b/qip-0016.md index 9c62d17..0525271 100644 --- a/qip-0016.md +++ b/qip-0016.md @@ -10,7 +10,7 @@ ## 0. Abstract -SOAP (“**S**ubsidized **O**pen-market **A**cquisition **P**rogram”) imports external Proof-of-Work from **Bitcoin-family donors** (BTC, LTC, DOGE, RVN) to fund a **protocol coinbase payout (QADDR)** and to **commit** a Quai WorkObject reference inside donor blocks. Quai continues to produce blocks with **KAWPOW** only. **Auxiliary shares** from other algos (SHA256d, Scrypt, …) may be *included* in Quai blocks for a QUAI payout, governed by a **separate DAA** targeting **3 included shares per block** with a hard cap of **9**. +SOAP (“**S**ubsidized **O**pen-market **A**cquisition **P**rogram”) imports external Proof-of-Work from **Bitcoin-family donors** (BTC, LTC, DOGE, RVN) to fund a **protocol coinbase payout (QADDR)** and to **commit** a Quai WorkObject reference inside donor blocks. Quai will switch from using Progpow to **KAWPOW** which is a slight modification from Progpow and will produce blocks with **KAWPOW** only. **Auxiliary shares** from other algos (SHA256d, Scrypt, …) may be *included* in Quai blocks for a QUAI payout, governed by a **separate DAA** targeting **3 included shares per block** with a hard cap of **9**. Donor participation is verified on Quai using a **traditional AuxPoW-style proof**: donor **header (80B)** + **coinbase tx** + **merkle branch**. We do **not** rely on LTC↔DOGE merged mining; DOGE and LTC are mined independently. @@ -26,7 +26,7 @@ Donor participation is verified on Quai using a **traditional AuxPoW-style proof ## 2. Terminology -- **WorkObject (WO):** The unit Quai miners build and commit to in donor blocks. +- **WorkObjectHeader (WOHeader):** The unit Quai miners build and commit to in donor blocks. - **QADDR:** Protocol-specified donor payout scriptPubKey; 100% of donor subsidy+fees must pay QADDR. - **SOAP push:** A fixed push of `"SOAP" 0x01 || 32B WO_HASH` placed in the **coinbase input scriptSig**. - **AuxPow (in this spec):** A donor proof object included in a Quai block: `{header, coinbase, merkle branch, index, chain_id, height}`. @@ -35,14 +35,24 @@ Donor participation is verified on Quai using a **traditional AuxPoW-style proof ## 3. On-chain objects (Quai) -### 3.1 WorkObject (wire) +### 3.1 WorkObjectHeader (wire) ```go -type WorkObject struct { - woHeader *WorkObjectHeader - woBody *WorkObjectBody - tx *Transaction - auxpow *AuxPow // optional; donor proof (this spec) +type WorkObjectHeader struct { + headerHash common.Hash + parentHash common.Hash + number *big.Int + difficulty *big.Int + primeTerminusNumber *big.Int + txHash common.Hash + primaryCoinbase common.Address + location common.Location + mixHash common.Hash + time uint64 + nonce BlockNonce + data []byte + lock uint8 + auxpow *AuxPow // optional; donor proof (this spec) } ``` @@ -52,24 +62,27 @@ type WorkObject struct { > “Traditional AuxPoW structure” = SPV-style: donor header + coinbase + merkle path. No LTC→DOGE merge minining. ```go -type ChainID uint16 // 1=BTC, 2=LTC, 3=DOGE, 4=RVN (extensible) +type PowID uint16 // 0=ProgPow, 1=KawPow, 2=DOGE, 3=BTC/LTC(extensible) type AuxPow struct { - Version uint8 - Chain ChainID - Height uint32 // donor height (informational/sanity) - Header []byte // 80-byte donor header - Coinbase []byte // raw coinbase transaction - Branch [][]byte // merkle siblings from coinbase txid to merkle root - Index uint32 // coinbase position in its merkle level (0/1 bit ordering) - // Expectations (encoded or implied by network params) - QAddrScript []byte // exact scriptPubKey bytes required for output[0] - // The commitment format we expect in coinbase scriptSig: - // PUSHDATA(height) PUSHDATA("SOAP" 0x01 || 32B WO_HASH) PUSHDATA(extranonce1) PUSHDATA(extranonce2) + powID PowID // PoW algorithm identifier + header []byte // 120B donor header for KAWPOW + signature []byte // Signature proving the work + merkleBranch [][]byte // siblings for coinbase index=0 up to root (little endian 32-byte hashes) + coinbase *wire.MsgTx // Full coinbase transaction (contains value in TxOut[0]) + prevHash []byte // Previous block hash reference + signatureTime uint64 // Timestamp when signature was created } ``` +## coinbase will have a scriptsig commitment +```go +QAddrScript []byte // exact scriptPubKey bytes required for output[0] +// The commitment format we expect in coinbase scriptSig: +// PUSHDATA(height) PUSHDATA("SOAP" 0x01 || 32B WO_HASH) PUSHDATA(extranonce1) PUSHDATA(extranonce2) +``` + --- ## 4. Donor coinbase **consensus requirements** @@ -86,7 +99,7 @@ For a donor block to count: ScriptSig total size MUST be **2..100 bytes** (Bitcoin-family consensus). 3. **Header inclusion (MUST):** The AuxPow proof MUST show `txid(coinbase)` included in `Header.merkleRoot` via `Branch, Index`. 4. **(Optional) Donor PoW check:** Nodes MAY verify donor header PoW under that chain’s rules (policy toggle). -5. **Freshness (RECOMMENDED):** The donor `Height` SHOULD be within **Δ blocks** of a committee-advertised tip (policy; not consensus). +5. **Freshness (RECOMMENDED):** The donor `Height` SHOULD be within **Δ blocks** of a committee-advertised tip (policy; not consensus). This is also acieved by the signature time and prevhash committed in the AuxPow. > **Rationale:** scriptSig is universally available, keeps miners stock, and avoids OP_RETURN size/policy variability across fleets. @@ -100,6 +113,7 @@ For a donor block to count: - **Soft mode (RECOMMENDED initial):** Valid AuxPow adds reward/weight bonus (see §7). No liveness coupling. - **Epoch mode (optional future):** Require ≥1 valid AuxPow per **E** Quai blocks to avoid reward decay. 4. **Shares (MUST):** Non-KAWPOW algos **cannot** produce Quai blocks; they produce **shares** only (§6). +5. **Transition Period** where both progpow and kawpow blocks are accepted, but progpow rewards will slowly be phased out. --- @@ -107,13 +121,13 @@ For a donor block to count: ### 6.1 Classification & validity -A **WorkObject** `wo` is classified at validation time as: +A **WorkObjectHeader** `woHeader` is classified at validation time as: -- **Block:** if the KAWPOW seal on `wo` meets the current block target. +- **Block:** if the KAWPOW seal on `woHeader` meets the current block target. - **WorkShare:** if **not Block**, and `wo.auxpow` passes **VerifyAuxPow(wo)** and the donor header PoW satisfies the per‑chain **share target** `T_share[wo.auxpow.Chain]`. - **Invalid:** otherwise. -**Tip binding / freshness:** Because `woHeader.parentHash` binds the object to the current Quai tip, separate tip-commit fields are unnecessary. Nodes SHOULD reject WorkShares older than **TTL = 2** Quai blocks (policy). +**Tip binding / freshness:** Because `woHeader.parentHash` binds the object to the current Quai tip, separate tip-commit fields are unnecessary. Nodes SHOULD reject WorkShares older than **TTL = 2** Quai blocks (policy). Additional checks based on the signature time is also imposed. ### 6.2 Scoring & normalization @@ -134,16 +148,11 @@ Two options are supported; implementers SHOULD start with **Equal Weight** for s - **Each included WorkShare:** pays its submitter under Equal‑Weight, or proportionally to `w_norm` under Difficulty‑proportional. - **Payout address:** the QUAI address is taken from `wo.woHeader.primaryCoinbase` (no extra fields required). -### 6.5 DAA for WorkShares (per‑chain) +### 6.5 Adjustment of rewards for the additional chains + +- If more than expected shares are found for additional chains, the reward is scaled down relative to the average expectation, indirectly creating an incentive for the miners to adjust hash rate -Maintain a per‑chain target `T_share[chain]` to hit **S_target = 3** WorkShares per block on average (cap `S_max = 9`). -- Target arrival rate `λ_inc = S_target / τ_b` (Quai block interval). -- Choose desired mix `φ_chain` (Σφ=1) and over‑provision `κ≥1` (e.g., 2.0). - `λ_chain = φ_chain · κ · λ_inc`. -- ASERT‑style controller on `T_share[chain]` from inter‑arrival times of **accepted WorkShares** for that chain: - `T_new = T_old · 2^((Δt − 1/λ_chain)/h)` with half‑life `h ∈ [5,10]·(1/λ_chain)`. -- Slowly adapt normalization β (only if using Difficulty‑proportional scoring) to keep realized mix near `φ_chain`. --- @@ -272,11 +281,6 @@ func IsSoapPush(b []byte, expectWO [32]byte) bool { * **Consensus requires:** SPV inclusion, SOAP presence/placement, **quorum-signed AuxTemplate**, and correspondence (`ChainID`, `PrevHash == hashPrevBlock`, `outputs[0] == PayoutScript`, `ScriptSigLen ≤ bound`). * **No freshness rule** at consensus; a stale template won’t match current `hashPrevBlock` anyway. ---- - -If you want, I can splice this into your full spec and export a fresh Markdown file. - ---- ## 8. Donor **coinbase construction** (template/pool)