Revisit tvl subtraction upon unexepected spent of staking output

[gitferry]

(context)
The current implementation considers three events that could affect tvl of the system (staking, unbonding, staking expiry). However, this does not include all the events that could subtract the locked value, e.g. slashing and unexpected withdrawal. We should revisit this issue later and make sure confirmed/unconfired tvl calculation as well as the calculation in the api side aligned.

Related issue #55

[jrwbabylonlab]

e.g. slashing and unexpected withdrawal.

There is no slashing in phase 1, why would it be a concern
What's unexpected withdraw?

[KonradStaniec]

What's unexpected withdraw?

It is actually any spend from staking output which does not conform to protocol rules. There multiple ways it could happen:

• there is bug in covenant signer and it allows invalid transaction
• quorum of signers go rogue and decide to do something unexpected, like: create web page in which they will advertise instant unbonding for small fee for stakers
• malicious entity steal staker key and quorum of covenenant members keys, and will steal stake

And probably many more which are much more creative.

That why in my mind the definition of tvl is bitcoins locked in staking outputs and:

• spends by expected transactions should just reduce this tvl
• spends by unexpected transactions should reduce this tvl and raise some sort of red flag (logging/metrics/new event on queue)

[jrwbabylonlab]

What's unexpected withdraw?

It is actually any spend from staking output which does not conform to protocol rules. There multiple ways it could happen:

• there is bug in covenant signer and it allows invalid transaction
• quorum of signers go rogue and decide to do something unexpected, like: create web page in which they will advertise instant unbonding for small fee for stakers
• malicious entity steal staker key and quorum of covenenant members keys, and will steal stake

And probably many more which are much more creative.

That why in my mind the definition of tvl is bitcoins locked in staking outputs and:

• spends by expected transactions should just reduce this tvl
• spends by unexpected transactions should reduce this tvl and raise some sort of red flag (logging/metrics/new event on queue)

@KonradStaniec Does timelock expire on tx count as "spends"? If I'm interpreting this correctly, you are suggesting the in the normal flow, we shall use withdraw to subtract the tvl?

[KonradStaniec]

I was operating under the assumption that there will be not timelock expirations during the phase-1 stage ie. our global parameter for staking time will be large enough that the only expected way to spend from staking output will be unbodning transaction.

If we want to include expirations to tvl definition, we need to modify it to bitcoin locked in staking outputs, which have at least N amount of block to expire where N is some constant.

If I'm interpreting this correctly, you are suggesting the in the normal flow, we shall use withdraw to subtract the tvl?

My position is simpler (I think 😅 ) and can be reduced to, tvl should be reduced any time the staking output is spent. Whether it is spent by unbonding transaction or by transaction which we do not expect.

If there would be expirations during system operation, tvl would also need to be reduced when staking timelock is about to expire. (as then stake cannot be converted to voting power in phase-2)