design: Shielded outputs#104
Conversation
| scan_pubkey(33) || hash(spend_pubkey)(20) | ||
| ``` | ||
|
|
||
| The spend pubkey is represented as a 20-byte hash (like a standard P2PKH address). Shorter addresses, but the full spend pubkey is not recoverable from the address alone — it must be obtained from the blockchain (from a prior spend) or out-of-band. |
There was a problem hiding this comment.
but the full spend pubkey is not recoverable from the address alone — it must be obtained from the blockchain (from a prior spend) or out-of-band.
Who must obtain it? The receiver already has it and the sender does not need it, correct?
There was a problem hiding this comment.
The sender. But the previous text was misleading and was updated. Let me explain here: For shielded outputs, the compact address is enough and nothing has to be recovered by the sender. But it imposes a limitation for silent payments.
|
|
||
| ### Rule 4 Compliance | ||
|
|
||
| When all inputs are transparent, the wallet must automatically ensure at least 2 shielded outputs (or include a transparent output). This is typically satisfied naturally (payment + change), but the wallet may need to create a zero-value absorber output in edge cases. |
There was a problem hiding this comment.
or include a transparent output
In this case, won't we still know the amount in the shielded output? In other words, won't we require still 2 shielded outputs?
There was a problem hiding this comment.
Also, this rule will be enforced on the wallet, correct? From the protocol side, should be possible to do it even if it "leaks" information.
There was a problem hiding this comment.
Indeed. I added this rule to open the discussion whether the protocol should require at least two shielded outputs or not.
When there are two or more shielded outputs and all inputs are transparent, observers can determine the total value of the outputs, but not how that value is distributed among them.
If there's at least one shielded input, observers can only infer that sum(outputs) > sum(transparent_inputs).
There was a problem hiding this comment.
Got it. I believe we should not enforce it at the protocol level. We should probably make it standard in the wallet library, though.
msbrogli
force-pushed
the
feat/shielded-outputs
branch
from
f033ceb to
4bb0b7e
Compare
msbrogli
force-pushed
the
feat/shielded-outputs
branch
from
4bb0b7e to
57c7958
Compare
| ### Sending Shielded Payments | ||
|
|
||
| 1. **Choose privacy tier** per output (`AmountShieldedOutput` or `FullShieldedOutput`). | ||
| 2. **Generate ephemeral keypair** `(e, E = e*G)` for each output. |
There was a problem hiding this comment.
How do you generate it? Do you take some info from the output to make it unique?
There was a problem hiding this comment.
No, you generate a random number e and multiply by G.
Extends the shielded outputs RFC with token creation, mint, and melt support via two new headers (MintHeader, MeltHeader) carrying public (token_index, amount) entries that bind into the homomorphic balance equation. Replaces parent Rule 8 and lifts the prohibition on shielded outputs in TokenCreationTransaction. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a Disclosure model subsection clarifying that the token reference is always transparent (authority outputs already leak it; the verifier needs the version for deposit/fee logic) while amount visibility is a pending business decision. Adds worked examples for DEPOSIT-version mint, melt and FEE-version mint with concrete deposit/fee math. Reframes Rule M3 as "one direction per token" and elevates the transparent-vs-shielded amount trade-off into Unresolved Questions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
| ``` | ||
| scan_pubkey(33) || hash(spend_pubkey)(20) | ||
| ``` |
3 participants
Rendered