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.

Sign up for GitHub

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

Jump to bottom

Implement flag to require confirmations for v2 opens #5900

Merged
merged 11 commits into from
Feb 8, 2023
Merged

Implement flag to require confirmations for v2 opens #5900

merged 11 commits into from
Feb 8, 2023

Commits on Feb 7, 2023

  1. v2 open: if flagged, check that all our inputs are confirmed 

    not amazing, since we'll probably call openchannel_update multiple
times per open, but this is the simplest way to confirm that we're
not sending unconfirmed outputs to peer.
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    d44d272 View commit details
    Browse the repository at this point in the history

  2. tx_roles: allow to be serialized btw processes 

    We're going to use this in a bit to pass role type btw
dualopend/lightningd
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    cce1715 View commit details
    Browse the repository at this point in the history

  3. df: persist channel open preference to database 

    technically we don't need this info after the channel opens, but for any
subsequent RBF (and maybe splice?) we need to remember what the
open/accept peer signaled
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    9202d62 View commit details
    Browse the repository at this point in the history

  4. df: wire up peer's "require-confirmed-inputs" 

    We push this info out to the various RPCs/hooks.
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    a7ba19f View commit details
    Browse the repository at this point in the history

  5. df: push back psbt to validate iff peer requests confirmed inputs 

    `openchannel_init` takes a psbt, which we pipe over to dualopend
process.

If the peer requests that they'll only accept confirmed inputs, we need
to go validate those before we continue.

This wires up the harness for this (validation check yet tc)
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    16d7253 View commit details
    Browse the repository at this point in the history

  6. df: for dryruns, inform on requires-confirmation value

    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    560bd3b View commit details
    Browse the repository at this point in the history

  7. df: reuse psbt validation for the psbts incoming from dualopend 

    Add callback methods to extant psbt validator, and expand usage to
include the handling psbt validation requests from dualopend.
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    bb1bf8f View commit details
    Browse the repository at this point in the history

  8. df: add new config option for v2 opens --require_confirmed_inputs 

    If set, require peers to only provide confirmed inputs for any v2 open
(both in accepter + opener role)
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    11397c9 View commit details
    Browse the repository at this point in the history

  9. dualopend: if required, validate inputs rcvd from peer 

    Pass in the "validate inputs confirmed" flag from lightningd; use flag
to determine whether or not to validate the inputs we've recieved from
peer.
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    5b6f618 View commit details
    Browse the repository at this point in the history

  10. df: persist our setting to disk, read back to dualopend at reinit 

    It's not likely but possible that the node's settings will shift btw a
start and an RBF; we persist the setting to the database so we don't
lose it.

Right now holding onto it forever is kind of extra but maybe we'll
reuse the setting for splices? idk.

Should this be a channel type??
    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    444559d View commit details
    Browse the repository at this point in the history

  11. test (df): check 'require-confirmed-inputs' for v2 opens

    @niftynei
    niftynei committed Feb 7, 2023
    Configuration menu
    Copy the full SHA
    8a00ce7 View commit details
    Browse the repository at this point in the history