Skip to content
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
wants to merge 68 commits into from

Conversation

niftynei
Copy link
Collaborator

@niftynei niftynei commented Oct 8, 2019

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

@niftynei niftynei requested a review from cdecker as a code owner October 8, 2019 23:19
@niftynei 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
@niftynei niftynei added this to the 0.7.3 milestone Oct 10, 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.
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.
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 niftynei modified the milestones: 0.7.3, 0.7.4 Oct 11, 2019
@niftynei niftynei closed this Oct 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant