Replace input commitment by 8 bytes MMR position

[garyyu]

Currently, an Input in a Transaction is expressed by the Commitment:

pub struct Input {
	pub features: OutputFeatures,
	pub commit: Commitment,
}

Inspired by the ideas in #2829, I'm thinking why
we didn't replace this 33 bytes commitment by 8 bytes MMR position?

Obvious benefits:

1. 8 bytes instead of 33 bytes, saving chain space
2. Efficient to find the related UTXO

[antiochp]

We can't do this for all inputs because we do not necessarily know which position the output sits in.
0-conf txs for example (output is not yet in the MMR).
Also reorgs (output could change position in the MMR).

The suggestion in #2829 is limited to only doing this a once we add a block to the chain state. i.e. Once we are confident the output being spent is A) in a know pos and B) that pos is stable.

[DavidBurkett]

0-conf txs for example (output is not yet in the MMR).

That's what cut-through is for.

Also reorgs (output could change position in the MMR).

This would result in a new block, and therefore a new MMR index. You would still sign and verify using the commitment, we could just store and transmit using the MMR index.

[antiochp]

Tx1: spends output A to produce output B
Tx2: spends output B to produce output C

Cut-through allows us to remove the intermediate output B.
But how would you represent Tx2 prior to cut-through in this scenario?

[DavidBurkett]

While broadcasting transactions, you would still broadcast the commitment. While sending blocks, you would just send the MMR index.

[antiochp]

While broadcasting transactions, you would still broadcast the commitment.

Precisely. Which is why I'm suggesting we cannot do what is proposed here.

[DavidBurkett]

Precisely. Which is why I'm suggesting we cannot do what is proposed here.

I don't understand. If you're talking about just blindly replacing commitment in Input with MMR index, I agree. But the concept Gary proposed still seems valid to me. When a peer requests full blocks from you, or when you try to broadcast them, it seems perfectly valid to just give them MMR index instead of commitment.

[DavidBurkett]

It also actually makes it easier to support duplicate commitments in the UTXO set.

[antiochp]

I interpreted it as related to transactions, not blocks.

Currently, an Input in a Transaction is expressed by the Commitment:

Blocks were not mentioned until you mentioned them?

[yeastplume]

Think we're okay to close this?

[antiochp]

I think this can be closed.

We were conflating transactions with blocks.

For transactions we cannot do what is proposed as transactions can spend outputs that do not yet exist in the output PMMR.

For blocks we can do this but the savings are likely not worth the additional complexity around needing to handle multiple serialization strategies.

[DavidBurkett]

I disagree with this conclusion. 25 bytes per input is a huge savings. I suggest reopening.

[antiochp]

25 bytes per input is a huge savings.

For full blocks on the network I agree this is relevant.
But for compact blocks (majority of the block traffic today) this would not apply.
And this is not applicable for transaction related traffic.

But for full blocks I'd argue we are far better off spending available dev resources on a better approach to this. i.e. filling in the missing txs vs. falling back to full blocks.

Local storage is not much of an issue (non-archival nodes only store 1 week of full blocks).

I guess we'd see the benefit during full block download during fast sync (2 days worth of blocks). Is that your main concern here @DavidBurkett?

[DavidBurkett]

For transaction related traffic, they could be serialized in 2 ways, by id for most, and by commit for the few that are unconfirmed. But that's additional complexity.

IBD is indeed the biggest gain at the current time.