2023 Mar 28

• Review

  • Main things changed:

    • Added optional_vec as a type for the TLV macros because vec_type always expected to read some value even if the vec was empty, and when you want to be backwards compatible and add a field that’s a vector, you can’t expect to read something (as it wouldn’t be there if reading from something persisted with a previous version).

    • Added nondust_htlc_outputs to ChannelMonitorUpdateStep::LastestHolderCommitmentTx and changed the main handler of that event provide_holder_commitment_tx to include some debug logic and also added some test stuff.

  • This is a transitioning PR so no logic was really changed, but seeds were laid to make it easier to transition.

  • General idea from what I understand is that we want to remove htlc_outputs field from LatestHolderCommitmentTx because it’s redundant because channel monitor update persistence holds us back from moving the channel forward in real time so we should focus on making it size efficient.

• Learned about dust HTLCs.

  • I was wondering why the dust limit even exists, and came across this mailing list post. Dust UTXOs increase the size of the current UTXO set without actually being valuable enough for anyone to want to keep there (because they won’t be profitable enough for anyone to spend). The size of the UTXO set is the main scalability concern, and the lower the dust limit, the more this is threatened (and for mostly negligible upside/flexibility added).

  • Dust HTLCs are just HTLCs with value below the dust limit, so they can’t be enforced on-chain, and therefore have no corresponding outputs in commitment transactions. Like any msat denominations, they operate in a semi-trusted way between nodes.

  • This led to me learning about OP_RETURN, which allows people to store arbitrary data in unspendable UTXOs that can be pruned. It was a compromise for people trying to store arbitrary data in other parts of transactions. Drawing this connection myself, I think I’ve heard of people trying to use OP_RETURN to encode more consensus rules (arbitrary data allows for more things to be validated or not, although since it must be unspendable I imagine that limits things).

• Why is utreexo not more popular? Seems like it could basically enable full nodes on a phone (I might imagine bandwidth and processing power(?) might still be constraining, but still)?