2023 Mar 10
Trying to understand why this comment (how
EcdsaChannelSigner::validate_counterparty_revocationis all that’s needed to allow a watchtower to function for each channel update) makes senseCrucial reading: Keys section of BOLT 3
Watchtower needs to know the commitment_txid to watch for, and it needs to be able to form a penalty tx to revoke. What are the bits and bolts that could let you create these?
Let’s exclude thinking about HTLCs for now because I’m not sure they are included for watchtowers for privacy reasons?
To get the commitment txid, you need to form the commitment tx. What is the structure of a commitment tx?
- (as holder, not watchtower)
Input: funding tx out
Output 0: to remote revocation immediately, OR to local pubkey with (relative) to_self_delay
Output 1: to remote pubkey
- (as holder, not watchtower)
To form a penalty tx, you need the local revocation secret.
How is the
per_commitment_secretgenerated? Randomly generate a 32-byte seed, then start from index 2^48-1 (281474976710655), then run the following algorithm:generate_from_seed(seed, idx): per_commitment_secret = seed for bit in idx (47th -> 0th bit): if bit == 1: flip bit in per_commitment_secret per_commitment_secret = SHA256(per_commitment_secret) return per_commitment_secretAnd for the next seed, decrement the index.
It’s really cool how this works, because it means you can derive secrets. Define a prefix as the numbers leading up to the last 1-bit in a number. If you have an index prefix||trailing zeros, you can derive any secret for indexes with the same prefix. This essentially means you only have to store at most n/2 secrets for n commitments.
EcdsaChannelSigner::validate_counterparty_revocationjust updates the index of the counterparty_last_revoked_commitment (or does nothing in the case of theInMemorySignerwhich I’m sort of confused by.Reviewing once again: CSV vs CLTV is relative versus absolute time. An important distinction: relative timelock is only helpful for spending unconfirmed outputs. A relative timelock on an already confirmed transaction is essentially the same as an absolute timelock (except maybe in a big reorg). Also important: OP_CSV enforces an nSequence of the transaction that spends this output, while nSequence is what actually dictates when the transaction can be mined. Same distinction for nLocktime vs OP_CLTV.
I would probably say I believe the adoption of stratum v2 and the development of lightning are the two most important things to be working on in Bitcoin at the moment. Many more important things but these stand out to me.
Fee sniping is basically MEV, and MEV is an incentive for centralization, as it provides an economic reward for cooperating to reorg. Back in my web3 days I just thought of MEV as having an advantage in trading because you knew what was in the mempool lol, but that’s really not it. It’s that miners are able to extract value by taking advantage of their control over the order of transactions being mined (and that’s especially enhanced when you have something like on-chain trading).