tapchannel: add new AuxChanCloser to enable co-op close for asset channels #919
Conversation
guggero
force-pushed
the
custom-channels-integration-invoice
branch
8 times, most recently
from
13f4f29 to
d6d9dc9
Compare
guggero
force-pushed
the
custom-channels-poc-coop-close
branch
2 times, most recently
from
90243a9 to
f2f4d6a
Compare
guggero
force-pushed
the
custom-channels-poc-coop-close
branch
2 times, most recently
from
9e1986d to
f02e269
Compare
guggero
force-pushed
the
custom-channels-poc-coop-close
branch
from
f02e269 to
96e2951
Compare
Adds a new RPC method that allows RPC users to easily encode payment related records into the required TLV custom record format required by the payment RPCs of lnd.
This commit fixes an issue where an error is bubbled up too far when it should instead have been handled in the HasProof method of the proof archive itself. This lead to proofs not being imported when they should've been.
We'll want to be able to detect that a script key is explicitly declared as being known to a software that operates on the local node. This is useful for example when the script key uses an internal key that is not local (e.g. it cannot be derived by the local wallet, for example a NUMS key), but the Tapscript spend paths are known to the software operating on the tapd RPCs. So funds on such script keys should still show up in the balances.
To be able to distinguish between locally known and potentially script-encumbered script keys, we add two new methods on the script key that help us to do that.
To recognize the funding output as belonging to the wallet, we now also insert it as a declared key into the wallet. And to make sure the asset is created in the asset DB, we also don't skip any transfer outputs that are marked as declared keys.
guggero
force-pushed
the
custom-channels-poc-coop-close
branch
from
96e2951 to
c5e4352
Compare
There isn't an easy way yet, at least not without knowing some internals. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
| // payment or other channel related RPCs. This RPC is completely stateless and | ||
| // does not perform any checks on the data provided, other than pure format | ||
| // validation. | ||
| func (r *rpcServer) EncodeCustomRecords(_ context.Context, |
There was a problem hiding this comment.
Do we still this as something that's temp? As in we'd just wrap the payment specific stuff in an entirely new RPC?
There was a problem hiding this comment.
I think so, yes. Or maybe not, given that with this it should be pretty easy to do the RPC calls in any language. I guess the question is: how much effort is it for the app devs to call 3 RPCs (buy/sell order, encode records, send payment) with the correct values vs. us threading all the payment and channel flags through some new RPC methods in tapd...
In this Pr, we add a new
AuxChanCloserthat allows co-op close for asset channels. As we haven't fully unified the wallet yet, a "fully loaded" coop close transaction will have 4 output: 2 for the BTC balance, and 2 for the asset amounts. We use a new interface added inlndto allow the aux chan closer to add additional outputs, and also ensure that sorting works out the same on both sides.Along the way, we also modify the chan funder to push the funding proof to a Universe if the proof courier addr is specified. This sets us up to ensure that the receiver can properly handle a proof discovery.
For the initiator, we rely on the porter to push out the proofs for our coop close with the specified proof courier addr (currently global, should allow a side to modify). As the non-initiator, since all our asset outputs will be the result of a split (we force a split for full value sends), we simply import the asset output as an addr into the custodian. This way, the custodian is able to watch for on-chain confirmation, then handle obtaining all the proofs we need to be able to send again.