Add ironwood migration draft zip - #1299
Conversation
There was a problem hiding this comment.
Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| This section is non-normative. It summarizes the Ironwood network upgrade | ||
| consensus-rule context within which this migration procedure operates. | ||
|
|
||
| The relevant orgs and protocol developers have agreed on the consensus-rule |
There was a problem hiding this comment.
explicitly name the organizations involved
| There are two main aspects to the strategy: | ||
|
|
||
| - the amount sent in each transaction (amount selection); | ||
| - how many transactions are sent, and when (the schedule). |
There was a problem hiding this comment.
these seem two different aspects to me
There was a problem hiding this comment.
Yeah, you're right. It's debatable whether there's three aspects, or if the middle aspect belongs with the first or the second. I'll clarify this to mention "quantisation" and "schedule".
| - exactly one Ironwood output, whose value is a single canonical denomination; | ||
| - no transparent inputs or outputs; | ||
| - no spends from any pool other than Orchard; | ||
| - the canonical fee (provisionally the ZIP 317 minimum fee) [^zip-0317]; |
There was a problem hiding this comment.
ZIP-308 says:
This fee is taken from the funds to be migrated.
Does something like this applies to this migration?
| is next active at or after a boundary. This produces organic dispersion of a | ||
| wallet's parts over time (potentially days or weeks), which is a privacy | ||
| feature. | ||
| - A wallet MAY broadcast **multiple parts into the same cohort** (multiplicity |
There was a problem hiding this comment.
when sending multiple parts, the wallet may choose to send each one of them to different light-client servers.
| [On multiplicity and cohorts]). This is a deliberate departure from a strict | ||
| one-part-per-boundary rule and is what allows good UX (few signing sessions) | ||
| without sacrificing per-cohort ambiguity. | ||
| - A wallet SHOULD choose $k$ to target a small total number of signing sessions |
There was a problem hiding this comment.
59.3 ZEC is not a small amout but not precisely a fortune and it would involve [10, 10, 10, 10, 10, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0.1, 0.1, 0.1] transactions. Which seems too many transactions to me.
There was a problem hiding this comment.
Yeah, that makes sense.
This would be all the quantisations needed to migrate the wallet, each in its own transaction, but sent in chunks in each "cohort" - as per the multiplicity selected by k.
So in this example there are (if I'm counting correctly) 17 transactions, but the wallet could select a k that aims to get those through in 6 or so signing sessions (or less). That has been our goal (about 6 transmissions).
But if your reservation is about the cost of fees, that's different, and yes, we're paying 17 fees here. Other methods like a 5-2-1 per digit quantisation reduce the number of transactions but split the anonymity set into 3, so that's not ideal, and I'm making the choice that fees are acceptable for privacy (the user can always decide to forgo privacy entirely and sendmax in one transaction).
Just some quick example fee price math - if your migration takes 20 transactions and the current ZEC price is $USD 500.0, that's $USD 1.00 in fees. I think that's acceptable, but that's just like, my opinion, man ;)
| | Random partition into high-entropy pieces | Pieces sum to the balance (subset-sum) and are self-fingerprinting. | | ||
| | 4-bucket whole-ZEC parts + sub-1-ZEC remainder | The rare remainder is a discriminator that makes co-location dangerous and is itself near-unique. Superseded by canonical-only quantization. | | ||
| | Randomized per-wallet multiplicity $k$ | Adds behavioral entropy (a fingerprint) without dispersing co-located parts; dominated by a deterministic, cohort-size-governed $k$. | | ||
| | Pre-signing all parts up front | Freezes anchors early, reintroducing the anchor-staleness leak. | |
There was a problem hiding this comment.
I think this was fixed with AuthSig changes wasn't it?
There was a problem hiding this comment.
Yes, this is already a bit out of date because of the AuthSig change. I'm not entirely convinced that it changes the quantisation or timing for mobile wallets, though. It would make the UX nicer, for sure.
Co-authored-by: Pacu <francisco.gindre@gmail.com>
|
Closing in favor of: |
Over the weekend I took our notes on the ironwood migration and red teamed various quantization and transaction timing strategies and then synthesized it together in this zip draft.
It may be a good starting point, but it does not take into account the proposed anchor height/auth data changes.
The short of it is this:
Adds a draft ZIP: Orchard → Ironwood Migration (
zips/draft-schell-ironwood-migration.md, Status: Draft, Category: Wallet).Specifies a privacy-preserving procedure for moving funds from the Orchard pool into the new Ironwood pool introduced by the Ironwood network upgrade. Because cross-pool transfers publicly reveal their net value, a naive migration would leak each wallet's balance and make migrations linkable. Modeled on ZIP 308, this draft mitigates that by:
DENOM_CAP), so migrated amounts collide across wallets instead of fingerprinting them.height ≡ 0 mod M), forming cohorts that mix many wallets' parts; a wallet may emit multiple parts per cohort (multiplicityk) safely because canonical values are unattributable.Includes threat model, privacy analysis (collision, subset-sum, accepted residual leaks, whale handling), rejected alternatives, and an Open Issues list of provisional parameters (
M,DENOM_CAP,DUST_FLOOR, target sessions,K_MAX) pending ratification and simulation.All numeric parameters are provisional; this is a pre-proposal working draft for discussion.
AI disclosure
This is the culmination of lots of discussions with Opus 4.8 through OpenCode, and I also used it to synthesize the first zip draft (to ensure it conforms to contribution guidelines) before editing by hand.
Resolves COR-1376