docs: accurate input/output linking in grin4bitcoiners.md#3904
Conversation
The previous text overstated Mimblewimble privacy by implying cut-through erases all input↔output association. Align the overview and FAQ with the Privacy Primer: amounts and addresses remain strong properties, while relay-time linking and taint analysis are residual risks. Closes mimblewimble#2427
|
|
||
| As explained in the previous section, thanks to the Mimblewimble transaction and block format we can merge transactions when an output is directly spent by the input of another. It's as if when Alice gives money to Bob, and then Bob gives it all to Carol, Bob was never involved and his transaction is actually never even seen on the blockchain. | ||
| - While a transaction is **relayed** (before or while it is mined), observers can still see which commitments are spent and which new ones appear. That is a real information channel. | ||
| - **Taint / hop analysis** can follow known “marked” outputs across spends if an adversary can introduce or learn those outputs (for example by paying you, or by watching the network closely). Aggregation and Dandelion make this harder, but they are not perfect anonymity. |
There was a problem hiding this comment.
Worth to mention payjoins, they are in contracts branch
| ### Wait, what!? No address? | ||
|
|
||
| Nope, no address. All outputs in Grin are unique and have no common data with any previous output. Instead of relying on a known address to send money, transactions have to be built interactively, with two (or more) wallets exchanging data with one another. This interaction **does not require both parties to be online at the same time**. Practically speaking, there are many ways for two programs to interact privately and securely. This interaction could even take place over email or Signal (or carrier pigeons). | ||
| Correct—no reusable addresses. Outputs are unique and do not share an address field with earlier outputs. Wallets build transactions **interactively** (or via a slate/exchange of messages). Both parties do not need to be online at the same instant; the handshake can happen over any private channel (including offline media). |
There was a problem hiding this comment.
What do you mean "address field" here? Public key of account can be used for interaction as "address"
| ### If I listen to transaction relay, can’t I just figure out who they belong to before cut-through? | ||
|
|
||
| ### If I listen to transaction relay, can't I just figure out who they belong to before being cut-through? | ||
| You can observe **which** outputs are spent and **which** new outputs appear in a given transaction or stem. You generally **cannot** read amounts or reuse addresses to label “who paid whom” the way you can on Bitcoin. |
There was a problem hiding this comment.
still not sure whats addresses you mean here
There was a problem hiding this comment.
also need to explain stem (mention Dandelion once + link will be enough)
|
|
||
| ### What about the quantum computaggedon? | ||
| ### What about quantum computers? | ||
|
|
There was a problem hiding this comment.
Worth to mention that while the obfuscation can be removed by a quantum attacker, the attacker has no way of knowing whether the transactions that they are attempting to view are of significant enough value to warrant performing a quantum attack.
| - After cut-through, the **kernel** of a transaction remains as a permanent ~100-byte footprint. The chain still records that “some” balanced state change occurred, even when the intermediate UTXOs are gone. | ||
|
|
||
| Pushing that further, between blocks, most outputs end up being spent sooner or later by another input. So *all spent outputs can be safely removed*. And the whole blockchain can be stored, downloaded and fully verified in just a few gigabytes or less (assuming a number of transactions similar to bitcoin). | ||
| So: Grin hides amounts and addresses strongly; it **weakens but does not eliminate** graph-style analysis of which outputs feed which later spends. That matches the Privacy Primer’s view that addresses and amounts are checked off as strong wins, while **input/output linking** remains an area of residual leakage and ongoing research. |
There was a problem hiding this comment.
What do you mean "addresses" here?
| 1. There are no amounts. | ||
| 1. 2 transactions, one spending the other, can be merged in a block to form only one, removing all intermediary information. | ||
| 1. **No addresses.** Outputs are one-shot curve points. There is no reusable “payment address” that links payments over time. | ||
| 2. **No amounts.** Every transaction uses confidential transactions (CT). Amounts sit inside Pedersen commitments with range proofs, so outsiders cannot read transfer values. |
There was a problem hiding this comment.
Links to explain Pedersen commitments and Range proofs can be added
| This means that the Grin blockchain scales with the number of users (unspent outputs), not the number of transactions. At the moment, there is one caveat to that: a small piece of data (called a *kernel*, about 100 bytes) needs to stay around for each transaction. But we're working on optimizing that as well. | ||
| Because spent outputs can be removed from the active UTXO set, a Grin node’s long-term storage grows primarily with **unspent outputs** (users holding coins), not with every historical payment. Full verification still needs kernels and headers; kernels are the main “per-transaction” residue that remains after cut-through. | ||
|
|
||
| In practice the chain stays far smaller than a transparent UTXO chain with the same activity, but it is not free—range proofs and kernels have a cost, and sync still requires downloading state (for example via PIBD or a txhashset snapshot). |
There was a problem hiding this comment.
PIBD is term that requires a link https://github.com/mimblewimble/grin-rfcs/blob/master/text/0022-pibd-deployment.md, txhashset is a term too
Clarify on-chain vs interaction “addresses,” link Pedersen/range proofs, mention payjoins for residual linking, and note quantum attackers cannot prioritize targets by value while amounts remain hidden.
| 1. There are no addresses. | ||
| 1. There are no amounts. | ||
| 1. 2 transactions, one spending the other, can be merged in a block to form only one, removing all intermediary information. | ||
| 1. **No on-chain addresses.** Outputs are one-shot curve points. There is no reusable on-chain “payment address” (no Bitcoin-style address or scriptPubKey reuse) that links payments over time. Wallets may still use an *off-chain* contact handle for interaction—for example a slatepack address, Tor onion, or account public key—but that identifier never appears on the chain as a field tying outputs together. |
There was a problem hiding this comment.
I would remove "Outputs are one-shot curve points.", probably to complicated for an average reader.
Simplify:
There are no on-chain "payment address" and as such no address reuse that links payments over time.
Rephrase:
Wallets may still use an off-chain contact handle for interaction between users, such as a slatepack address, but that identifier never appears on the chain.
| 1. There are no amounts. | ||
| 1. 2 transactions, one spending the other, can be merged in a block to form only one, removing all intermediary information. | ||
| 1. **No on-chain addresses.** Outputs are one-shot curve points. There is no reusable on-chain “payment address” (no Bitcoin-style address or scriptPubKey reuse) that links payments over time. Wallets may still use an *off-chain* contact handle for interaction—for example a slatepack address, Tor onion, or account public key—but that identifier never appears on the chain as a field tying outputs together. | ||
| 2. **No amounts.** Every transaction uses confidential transactions (CT). Amounts sit inside [Pedersen commitments](intro.md#balance) with [range proofs](intro.md#range-proofs) (Grin uses [Bulletproofs](https://eprint.iacr.org/2017/1066.pdf)), so outsiders cannot read transfer values. |
There was a problem hiding this comment.
No amounts. Mimblewimble builds on the concept of Confidential Transactions. Amounts are hidden inside Pedersen commitments, so outsiders cannot read transfer values.
I think the part about rangeproofs should not be put here since they have nothing to do with hiding the amounts, they are only used to proof no negative values are used. Best to avoid too much details that complicates reading.
| 1. 2 transactions, one spending the other, can be merged in a block to form only one, removing all intermediary information. | ||
| 1. **No on-chain addresses.** Outputs are one-shot curve points. There is no reusable on-chain “payment address” (no Bitcoin-style address or scriptPubKey reuse) that links payments over time. Wallets may still use an *off-chain* contact handle for interaction—for example a slatepack address, Tor onion, or account public key—but that identifier never appears on the chain as a field tying outputs together. | ||
| 2. **No amounts.** Every transaction uses confidential transactions (CT). Amounts sit inside [Pedersen commitments](intro.md#balance) with [range proofs](intro.md#range-proofs) (Grin uses [Bulletproofs](https://eprint.iacr.org/2017/1066.pdf)), so outsiders cannot read transfer values. | ||
| 3. **Cut-through and aggregation.** When an output is spent, Mimblewimble can remove the spent input/output pair from the long-term chain state. Inside a block, many transactions are merged into one aggregate set of inputs, outputs, and kernels, so a confirmed block does not look like a list of labeled payments. |
There was a problem hiding this comment.
In your writing style, try to combine the minimalism of the original with being complete like in your suggested changes (this feedback can be applied to all changes you propose).
I would rewrite slightly:
Cut-through and aggregation. When an output is spent, Mimblewimble can freely forget (remove) the spent output from the blockchain. Transactions inside a block are merged into one aggregate set of inputs, outputs, and kernels. Therefore, block information does does not look like a list of labeled payments but like one large transaction.
| 3. **Cut-through and aggregation.** When an output is spent, Mimblewimble can remove the spent input/output pair from the long-term chain state. Inside a block, many transactions are merged into one aggregate set of inputs, outputs, and kernels, so a confirmed block does not look like a list of labeled payments. | ||
|
|
||
| The 2 first properties mean that all transactions are indistinguishable from one another. Unless you directly participated in the transaction, all inputs and outputs look like random pieces of data (in lingo, they're all random curve points). | ||
| Because of (1) and (2), unspent outputs and kernels all look like random-looking data unless you participated in building them. Nodes can still verify that no money was created out of thin air by checking that commitments balance (homomorphic structure) and that range proofs and signatures are valid. |
There was a problem hiding this comment.
I merged the original and your version based on which parts I found best:
Because of properties (1) and (2), transactions are indistinguishable from one another. Unless you directly participated in the transaction, all inputs and outputs look like random pieces of data (in lingo, they're all random curve points). Nodes can still verify that no money was created out of thin air by checking that commitments balance (homomorphic structure) and that range proofs and signatures are valid.
Moreover, there are no more transactions in a block. A Grin block looks just like one giant transaction and all original association between inputs and outputs is lost.
|
|
||
| So: Grin hides amounts and *on-chain* addresses strongly; it **weakens but does not eliminate** graph-style analysis of which outputs feed which later spends. That matches the Privacy Primer’s view that addresses and amounts are checked off as strong wins, while **input/output linking** remains an area of residual leakage and ongoing research. | ||
|
|
||
| As explained in the previous section, thanks to the Mimblewimble transaction and block format we can merge transactions when an output is directly spent by the input of another. It's as if when Alice gives money to Bob, and then Bob gives it all to Carol, Bob was never involved and his transaction is actually never even seen on the blockchain. |
There was a problem hiding this comment.
Why remove this? I think it is best to simply keep these parts.
| As explained in the previous section, thanks to the Mimblewimble transaction and block format we can merge transactions when an output is directly spent by the input of another. It's as if when Alice gives money to Bob, and then Bob gives it all to Carol, Bob was never involved and his transaction is actually never even seen on the blockchain. | ||
| ## Scalability | ||
|
|
||
| Pushing that further, between blocks, most outputs end up being spent sooner or later by another input. So *all spent outputs can be safely removed*. And the whole blockchain can be stored, downloaded and fully verified in just a few gigabytes or less (assuming a number of transactions similar to bitcoin). |
There was a problem hiding this comment.
Again, why remove this part, it is good and true, right?
| Because spent outputs can be removed from the active UTXO set, a Grin node’s long-term storage grows primarily with **unspent outputs** (users holding coins), not with every historical payment. Full verification still needs kernels and headers; kernels are the main “per-transaction” residue that remains after cut-through. | ||
|
|
||
| This means that the Grin blockchain scales with the number of users (unspent outputs), not the number of transactions. At the moment, there is one caveat to that: a small piece of data (called a *kernel*, about 100 bytes) needs to stay around for each transaction. But we're working on optimizing that as well. | ||
| In practice the chain stays far smaller than a transparent UTXO chain with the same activity, but it is not free—range proofs and kernels have a cost, and sync still requires downloading state (for example via PIBD or a txhashset snapshot). |
There was a problem hiding this comment.
Again, I would keep the original, mimblewimble has mostly benfits at hardly any costs. I mean do you have to say "range proofs and kernels have a cost, and sync still requires downloading state (for example via PIBD or a txhashset snapshot)."
Obviously any blockchain involves downloading data, that is not a cost just the obvious, especially if the whole blockchain is only a few gigabytes. I understand you do not want to write overtly optimistic, but neither should downsides be exaggerated.
| ## Emission Rate | ||
|
|
||
| Bitcoin's 10 minute block time has its initial 50 btc reward cut in half every 4 years until there are 21 million bitcoin in circulation. Grin's emission rate is linear, meaning it never drops. The block reward is currently set at 60 grin with a block goal of 60 seconds. This still works because 1) dilution trends toward zero and 2) a non-negligible amount of coins gets lost or destroyed every year. | ||
| Bitcoin’s block subsidy halves over time toward a fixed supply. Grin’s base emission is **linear** (a constant block reward), so supply grows without a hard cap. Dilution trends toward zero as the monetary base grows, and coins are also lost over time. The block target is on the order of one minute (see current consensus parameters for the exact reward). |
There was a problem hiding this comment.
I mixed and matched your version and the original:
Bitcoin's 10-minute block time starts with an initial 50 BTC reward that cuts in half roughly every four years until 21 million bitcoin reaches circulation. Grin's emission rate is linear, meaning the block reward stays fixed and supply grows without a hard cap. The reward is currently set at 60 GRIN with a block goal of 60 seconds. This still works because: 1) dilution trends toward zero as the monetary base expands, and 2) a non-negligible amount of coins gets lost or destroyed every year.
|
|
||
| No, and this is where Mimblewimble and Grin shine. Confidential transactions are a form of [homomorphic encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption). Without revealing any amount, Grin can verify that the sum of all transaction inputs equal the sum of transaction outputs, plus the fee. Going even further, comparing the sum of all money created by mining with the total sum of money that's being held, Grin nodes can check the correctness of the total money supply. | ||
| No. Confidential transactions are designed so nodes can check that the sum of inputs equals the sum of outputs plus the fee **without** learning the amounts. Across the whole chain, nodes also check consistency of total supply against coinbase issuance. Cut-through removes spent UTXOs; it does not remove the need for those balance checks. | ||
|
|
There was a problem hiding this comment.
Again, hard to see which is better, the original, or the new version of this section. I think I might prefer the original 🤔
| ### What about quantum computers? | ||
|
|
||
| In every Grin output, we also include a bit of hashed data, which is quantum safe. If quantum computing was to become a reality, we can safely introduce additional verification that would protect existing coins from being hacked. | ||
| Commitments and signatures used today are not quantum-safe in the usual sense. Outputs also carry hash material that can support future migration plans if quantum threats become practical. Even if a quantum attacker could strip the cryptographic hiding of historical commitments, amounts are not known in advance—so there is no reliable way to pick “high-value” transactions to attack first. Treat long-range quantum risk like other cryptocurrencies: monitor standards and upgrades; do not assume current crypto is forever. |
There was a problem hiding this comment.
Mmmm. I get your point. My problem is that many of these "subtle changes" changes the tone or sentiment of the document as well as change emphasis. For example your version contains a scent of fear, .... oooooo... be afraid "Treat long-range quantum risk like other cryptocurrencies: monitor standards and upgrades; do not assume current crypto is forever."
I would suggest removing that part in any case. Probably that part is AI generated. AI's are trained to overstate the risk of quantageddon and essentially create FUD. I know, mine did after which I completely flipped its reasoning by pointing out all the fallacies and assumptions it made.
Anynomouss
left a comment
Anynomouss
left a comment
There was a problem hiding this comment.
I found this pull hard to review. At some points, there are improvements, at others I feel perhaps too much details is use, while in some places I simply prefer the original text.
In quite a few cases I found myself mixing parts of the original and the new to get the best of both worlds.
I think that 1) feedback needs to be incorporated2) I would propose others might review this PR as well since the original documents was also quite good and minimal. In some case I do not like the change of emphasis/tone, see comments.
3 participants
Summary
doc/grin4bitcoiners.mdpreviously suggested that cut-through / block aggregation means all input↔output association is lost. That overstates Mimblewimble privacy relative to the Grin Privacy Primer, which treats input/output linking as residual leakage (taint analysis, relay observation) even while amounts and addresses are strong wins.Closes #2427
Changes
Translations (
grin4bitcoiners_KR.md,ZH-CN) left as-is for native-speaker follow-up.Test plan