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 -> API changes/breakage #5670

Merged
merged 19 commits into from Feb 4, 2023

Conversation

niftynei
Copy link
Collaborator

Built on #5650, updates to latest + greatest dual-funding spec proposal.

Awaiting interop with ACINQ/Eclair, and requires lnprototest updates (so in draft til these are updated).

Biggest change is that anchors aren't assumed for v2 opens now.

Copy link
Member

@cdecker cdecker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice cleanups, looking forward to merging this. All I could find was a slight issue with the ok = chaining used to compute some amount_sat values. It can happen that we clobber an amount with an uninitialized value without noticing if I'm not mistaken.

*/
{ OPT_DUAL_FUND, OPT_ANCHOR_OUTPUTS },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No explicit signalling needed anymore?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've removed the implicit dependence on anchor_outputs, instead we just assume that static_remotekey is required.

state->our_role = TX_INITIATOR;
else
ok = amount_msat_to_sat(&state->tx_state->opener_funding, our_msat);
ok = amount_sat_sub(&state->tx_state->accepter_funding,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably want to have ok &= amount_sat_sub otherwise the assignment on line 3965 is pointless. More importantly amount_msat_to_sat doesn't actually change opener_funding in case of a failure, thus one may fail, and amount_sat_sub would use uninitialized values and may succeed.

state->our_role = TX_ACCEPTER;
ok = amount_msat_to_sat(&state->tx_state->accepter_funding, our_msat);
ok = amount_sat_sub(&state->tx_state->opener_funding,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above.

msg = cryptomsg_encrypt_msg(tmpctx, cs, take(msg));
return io_write(conn, msg, tal_count(msg), io_close_cb, NULL);
msg = cryptomsg_encrypt_msg(NULL, cs, take(msg));
return io_write_wire(conn, take(msg), io_close_cb, NULL);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, just verified that io_write_wire takes data, despite not being annotated as such. It uses tal_dup_talarr which is marked as TAKES

@niftynei niftynei marked this pull request as ready for review December 1, 2022 22:11
@niftynei niftynei force-pushed the nifty/dual-fund-updates branch 2 times, most recently from f3f4018 to 0c82054 Compare January 17, 2023 20:32
@niftynei niftynei force-pushed the nifty/dual-fund-updates branch 2 times, most recently from 4fefc5d to 6969341 Compare January 31, 2023 01:14
@niftynei
Copy link
Collaborator Author

test failure unrelated to changes:

Valgrind error file: valgrind-errors.24405
==24405== Conditional jump or move depends on uninitialised value(s)
==24405==    at 0x49E4B56: __vfprintf_internal (vfprintf-internal.c:1516)
==24405==    by 0x49F6519: __vsnprintf_internal (vsnprintf.c:114)
==24405==    by 0x1EC4CB: do_vfmt (str.c:66)
==24405==    by 0x1EC5D8: tal_vfmt_ (str.c:92)
==24405==    by 0x11A356: paymod_log (libplugin-pay.c:167)
==24405==    by 0x11B4D2: payment_chanhints_apply_route (libplugin-pay.c:534)
==24405==    by 0x11E9B9: payment_compute_onion_payloads (libplugin-pay.c:1707)
==24405==    by 0x11FF6C: payment_continue (libplugin-pay.c:2135)
==24405==    by 0x1245E0: adaptive_splitter_cb (libplugin-pay.c:3800)
==24405==    by 0x11FF13: payment_continue (libplugin-pay.c:2123)
==24405==    by 0x12061E: retry_step_cb (libplugin-pay.c:2301)
==24405==    by 0x11FF13: payment_continue (libplugin-pay.c:2123)
==24405== 

m-schmoock and others added 17 commits February 2, 2023 16:18
You can now pick a different amount during the RBF phase
We're gonna reuse it in dualopend.
There's two anchor flags, we should check both. Also have dualopend
check this as well!
Only add the anchor channel_type if it's negotiated separately!
Otherwise we'd have to update the liquidity ads spec to get this
shipped.
The `tmpctx` is free'd before the error is read out/sent over the wire;
there's a call that will copy the array before sending it, let's use
that instead and take() the object?

------------------------------- Valgrind errors --------------------------------
Valgrind error file: valgrind-errors.2181501
==2181501== Syscall param write(buf) points to unaddressable byte(s)
==2181501==    at 0x49E4077: write (write.c:26)
==2181501==    by 0x1C79A3: do_write (io.c:189)
==2181501==    by 0x1C80AB: do_plan (io.c:394)
==2181501==    by 0x1C81BA: io_ready (io.c:423)
==2181501==    by 0x1CA45B: io_loop (poll.c:453)
==2181501==    by 0x118593: main (connectd.c:2053)
==2181501==  Address 0x4afb158 is 40 bytes inside a block of size 140 free'd
==2181501==    at 0x483F0C3: free (vg_replace_malloc.c:872)
==2181501==    by 0x1D103C: del_tree (tal.c:421)
==2181501==    by 0x1D130A: tal_free (tal.c:486)
==2181501==    by 0x1364B8: clean_tmpctx (utils.c:172)
==2181501==    by 0x1266DD: daemon_poll (daemon.c:87)
==2181501==    by 0x1CA334: io_loop (poll.c:420)
==2181501==    by 0x118593: main (connectd.c:2053)
==2181501==  Block was alloc'd at
==2181501==    at 0x483C855: malloc (vg_replace_malloc.c:381)
==2181501==    by 0x1D0AC5: allocate (tal.c:250)
==2181501==    by 0x1D1086: tal_alloc_ (tal.c:428)
==2181501==    by 0x1D124F: tal_alloc_arr_ (tal.c:471)
==2181501==    by 0x126204: cryptomsg_encrypt_msg (cryptomsg.c:161)
==2181501==    by 0x11335F: peer_connected (connectd.c:318)
==2181501==    by 0x118A8A: peer_init_received (peer_exchange_initmsg.c:135)
==2181501==    by 0x1C751E: next_plan (io.c:59)
==2181501==    by 0x1C8126: do_plan (io.c:407)
==2181501==    by 0x1C8168: io_ready (io.c:417)
==2181501==    by 0x1CA45B: io_loop (poll.c:453)
==2181501==    by 0x118593: main (connectd.c:2053)
==2181501==
{
   <insert_a_suppression_name_here>
   Memcheck:Param
   write(buf)
   fun:write
   fun:do_write
   fun:do_plan
   fun:io_ready
   fun:io_loop
   fun:main
}
--------------------------------------------------------------------------------
we've removed the EXPERIMENTAL_DUAL_FUND requirement
liquidity ads (as proposed) rely on the CSV addition to the to_remote output
that anchors introduced.
There's no reason not to use the channel-types (same as v1s) for v2
opens.

Brings us into compliance with ACINQ's implementation afaict
state isn't kept around for lease amount, so it should fail
Don't forget the requested lease across restarts.
We need to be able to only use non-wrapped inputs for v2/interactive tx
protocol.

Changelog-Added: JSONRPC: `fundpsbt` option `nonwrapped` filters out p2sh wrapped inputs
v2 opens require you to use native segwit inputs

Changelog-Added: JSONRPC: `upgradewallet` command, sweeps all p2sh-wrapped outputs to a native segwit output
@rustyrussell
Copy link
Contributor

Ack 62af76d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants