[Feature Request] Attach sweep transaction ids to closedchannels list

[alexbosworth]

Background

When looking up the context of chain transactions, I want to relate each chain transaction id to a specific action such as a direct spend, a direct receive, a sweep, a channel open, etc.

For sweep transaction ids, it's difficult to determine given the transaction listed in listchaintxns that the transaction is a a sweep transaction because its id isn't listed in the closedchannels listing.

As a rough workaround, the sweep transaction can be fetched and its inputs evaluated to trace back to a closing_tx_hash

[carlaKC]

Going to pick this up as part of better on chain accounting.

Working plan as it stands:

• Accounting mode flag that opts into not deleting data
• Keep channel resolutions (in chanArbLog) on disk after they have been resolved, will need to update state machine so that it doesn't continuously try to resume these resolutions
• Relate sweep txid to each resolution (you can lookup the sweep tx + match the resolution's outpoint to determine what portion of the fees it is responsible for)
• Add resolutions to the CloseSummary rpc:

message ChannelResolutions{
    enum ResolutionState{
        UNKNOWN =0;
        UNRESOLVED =1;
        RESOLVING = 2;
        RESOLVED = 3;
    }

    // The current state that we are in for resolving the channel. This may
    // be unresolved if we have not started to resolve the channel yet,
    // resolving if we are in the process of resolving and resolved if all
    // outputs are fully resolved.
    ResolutionState state = 1;

    repeated Resolution resolutions = 2;
}

message Resolution{
    enum ResolutionType{
        UNKNOWN = 0;
        INCOMING_HTLC = 1;
        OUTGOING_HTLC = 2;
        COMMITMENT = 3;
        HTLC_TIMEOUT = 4;
        HTLC_CLAIM = 5;
        ANCHOR =6;
    }

    // Incoming/outgoing if we have not kicked off second stage/ claimed.
    // Commitment for our commit sweep, timeout when we timeout outgoing,
    // rest self explanatory.
    ResolutionType type = 1;

    OutPoint outpoint = 2;

    uint64 amount_sat = 3;

    bytes sweep_txid = 4;
}

[alexbosworth]

Personally for my needs I don't want an accounting mode. I just want every LND to store info about every chain transactions that confirmed that it was involved with financially and make that available through the API. I don't think that's a lot of data to store and in most situations I feel like it would be the baseline requirement to record and clearly present what you have spent

Storing the resolutions is definitely what I want though, and also it would be great to have a fee attribute for closed channels and for resolutions, and have that fee attribute be attributed to the responsible party, meaning I don't care what the other side paid in fees, but I need to know what I paid in fees for each stage of the close transaction.

[carlaKC]

Personally for my needs I don't want an accounting mode.

I think this makes sense for resolutions, as you say it won't be much data. Some other things may need an accounting flag (specifically keeping the revocation log around), but I think this is an acceptable one to default to storing.

and also it would be great to have a fee attribute for closed channels and for resolutions, and have that fee attribute be attributed to the responsible party

Makes sense, per-resolution list the portion of the sweep fee that we attribute to that action.

Do you think it's ok to only have the mapping of resolutions to sweeps in one direction? Ie, you get a close summary which lists your resolutions and their sweep transactions, but there's no list of sweeps that maps to all the resolutions they are involved in? If we want to go from sweep -> resolution we probably need to make changes in the sweeper, which I'd like to avoid if it's not a necessary feature.

[alexbosworth]

Yeah for sure, I don't think there is a need for too much cross referencing, just as long as I can get the timing and see all those amounts that are relevant to my balance