tarofreighter: add new ExportLog interface for committing spends #114
Conversation
|
Ok this is ready for review now. |
|
Only the last 3 commits are new. |
|
So I think it makes sense to just add an intermediate table here (described in a TODO). This'll let us retain an internal history for all transfer, which can be used to create a CLI/RPC command to browse the history. The only change needed here is to not apply the update immediately, but instead insert the change/delta, then only apply it once confirmed. We don't need to get down the format 100% rn, but this'll also eventually thread into the CLI output after a send. Brainstorming a bit, minimally we want to output:
|
| // AssetSpendDelta describes the mutation of an asset as part of an outbound | ||
| // parcel (batched send). As we always require script keys to be unique, we | ||
| // simply need to know the old script key, and the new amount. | ||
| type AssetSpendDelta struct { |
There was a problem hiding this comment.
I think with this format, we can't represent complete removal of an asset leaf? Once we resolve #121 this wouldn't be needed for normal spends, but may also be relevant for recording asset burns. Maybe out of scope for this PR.
There was a problem hiding this comment.
Correct, this assumes the happy case of single input, and the asset amount is sized juuust right.
I think to represent a leaf being removed all together, we'd either use a diff delta struct, or add something here that says it can just be deleted.
Roasbeef
force-pushed
the
asset-re-anchor
branch
from
8cd171b
to
8420506
Compare
In this commit, we add a new `ExportLog` interface that'll be used to update the on-disk information related to which assets are spent and how they're spent. When an asset is spent, all assets that were collocated in the same commitment must now be re-anchored in a new commitment. However _some_ assets will also be mutated if they were used to create a split, or mark a complete spend/send to a party (interactive or non-interactive). A spend moves from pending to confirmed once it's sufficiently buried in the chain. At this point, the on-disk information that tracks where the chain_txn is located will be updated. At this time, roll backs aren't supported (re-org or need to undo a spend). As a result, a spend should only be marked as pending once it's certain that the transactions that anchors the new assets will eventually be broadcaster and confirmed.
In this commit, we update the set of on disk asset deltas to only be a delta. Once we confirm the transaction, then we'll actually apply it. This allows us to do things like get the set of unconfirmed deltas to rebroadcast later.
Roasbeef
force-pushed
the
asset-re-anchor
branch
from
8420506
to
874086c
Compare
In this PR, we add a new
ExportLoginterface that'll be used toupdate the on-disk information related to which assets are spent and how
they're spent.
When an asset is spent, all assets that were collocated in the same
commitment must now be re-anchored in a new commitment. However some
assets will also be mutated if they were used to create a split, or mark
a complete spend/send to a party (interactive or non-interactive).
A spend moves from pending to confirmed once it's sufficiently buried in
the chain. At this point, the on-disk information that tracks where the
chain_txn is located will be updated.
At this time, roll backs aren't supported (re-org or need to undo a
spend). As a result, a spend should only be marked as pending once it's
certain that the transactions that anchors the new assets will
eventually be broadcaster and confirmed.
Depends on #113