New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dual-funding: track and clean up shared txs (III of IV) #3144
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
niftynei
changed the title
dual-funding, part III: track and clean up shared txs
dual-funding: track and clean up shared txs (III of IV)
Oct 8, 2019
If we can't broadcast the transaction, we free the utx anyway. You're going to have to start over regardless.
Previously we've used the term 'funder' to refer to the peer paying the fees for a transaction; v2 of openchannel will make this no longer true. Instead we rename this to 'opener', or the peer sending the 'open_channel' message, since this will be universally true in a dual-funding world.
plus tests, with some of the corruption tests taken out, since it crashes. will be re-enabled in the next commit.
Since wires can now have TLVs, we need to change up the truncation check to account for the fact that truncated TLVs are kosher.
niftynei
force-pushed
the
nifty/utxo-mgmt-impr
branch
from
October 10, 2019 19:31
afecc25
to
8c63b1b
Compare
we need a way to tell openingd to use v2 for channel open.
We've now got two amounts we need to keep track of: the opener's funding and the accpeter's. We add a utlity to help keep track of the full funding. Also wires in the calls for open/accept v2 for when we're the opener.
so we can refer to it later when doing 'complete' things
for v2 we need to know the inputs/outputs of the transaction so we look them up. there's more problems here that we need to unwind still: figuring out which the funding output is plus how to handle change.
going to need to re-use this later.
We're not using the change_outnum for withdraw tx's (and the way we were calculating it was broken as of the addition of 'multiple outputs'). This removes the change output knowhow from withdraw_tx entirely, and pushes the responsibility up to the caller to include the change output in the output set if desired. Consequently, we also remove the change output knowhow from hsmd.
Make it such that we can include other inputs on a transaction, sort them, and sign the ones we need. We're going to need this for dual-funded transactions.
pull up output parser into reusable method
Function and helpers for making a dual funded funding tx
Update some assumtions of wallet_commit_channel to better take the dual-funded reality into account
we're going to need them to construct the funding tx
Dual funding means that both the opener (us) and the accepter (the remote peer) have the opportunity to add funds to the funding transaction. This patch implements the protocol set required for the second half of dual-funding; from fundchannel_complete onward.
Only applies for dual funded transactions. Ideally will be obsoleted with a PSBT implementation soon.TM
this number is tentative, will need to be updated when set definitively
We're now passing utxos to openingd, who needs to know what the scriptPubkey is, to relay to our peer.
dual funding needs an output who's value is set to zero in order to correctly specify change for the opener. this modifies txprepare to allow for generating such an output
allows us to use them in wire definitions other than where they are defined.
We'll need it to represent to user in `listpeers`
Allow the utxo object to bear the scriptSig as well; also fixes broken scriptPubkey parsing on utxo
dual funding means that we'll now have utxos that have been shared but not spent (this means they might become spent, but they're not longer eligible to be 'unreserved'). this patch adds the ability to track 'shared' utxos and to record the blockheight that they are 'shared' at. in the future, we can use the shared_at blockheight marker to clean up any outputs that are left in the 'shared' state.
Change is an output too!!
If an output is shared with a peer, but we don't see the transaction broadcast within a day, we should 'burn' those outputs and shut down the channel. This takes care of the first part -- checking for eligible/stranded transactions and consolidating them into a single spend. We run this every 24 blocks (~4 hours).
Add methods to fetch list of channels with utxos that are to be burned. This lets us know who to cancel.
After we've spent the utxos' that were committed to a channel's open_channel request, alert the channel that it's ok to close.
Mark funds as shared so that we will update/spend them as appropriate.
This was doing the wrong check. Now, we actually do check for the redeemscript of a P2SH-wrapped inputs.
otherwise we just go ahead and forget it.
The burner will take care of these separately.
We need a channel owner around in order to send a message to our peer. If they're not here, we just bail.
when we get a channel cancel, we're going to want to burn any utxos associated with that channel, if we're in the awaiting state. this method allows us to do this.
...one that doesn't rely on 'cmd' existing. we split into two methods, one where cmd exists, the other where cmd does not exist. burn_tx calls the non-cmd version, as often times we're burning txs without a burn.
restrict `fundchannel_cancel` to only the opener
fetch back all of the utxos that are burnable and associated with this particular channel.
When a channel is to be forgotten, we should clean up any outstanding utxos
Makes sure that l1 can disconnect while l2 is offline
We're about to enforce some stricter checking in withdraw_tx, which will require inputs to know what their amounts are. Here, we plumb through the input amounts along with the funding_tx, since the serialization process for transactions discards the input amount information.
check that our withdrawal amounts are sane -- no empty outputs, input and output amounts are in sync, we're below a max fee amount
Basic test for checking that burns clean up and that dual funding works (basic)
niftynei
force-pushed
the
nifty/utxo-mgmt-impr
branch
from
October 10, 2019 23:10
8c63b1b
to
92a901c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dual funding introduces a new state for utxos: 'shared'. When we send peers our utxos as part of a dual funding open, we mark them as shared. Shared tx's aren't used for other things. Once the transaction is broadcast, they move to 'spent'.
If the funding transaction doesn't get broadcast within ~22 hours, we take action, 'burning' the shared utxos and attempting to notify our peer of channel closure.
This PR builds on #3122. The first new commit is 9ba77b6