Add support for submitting packages of transactions

[t-bast]

I'd like to know if there is a plan to add support for submitting packages of transactions, based on bitcoin core's submitpackage RPC? This will be important when rolling out support for v3 transactions that don't pay any fees, such as lightning's zero-fee commitment txs. Let me know how we can help!

[tnull]

This is already being worked on over at #1

[t-bast]

Awesome, how could I be so lazy that I didn't even look at the open PRs 😅
Sorry for the noise!

[SomberNight]

Let me know how we can help!

Well you can comment on if the RPC as documented looks reasonable. :P

One thing we were having doubts about is what the response to the RPC should look like.
The "easy" solution would be to just forward the response from bitcoind's submitpackage, however

• bitcoind docs say "This RPC is experimental and the interface may be unstable."
• and even without that warning not sure if the electrum protocol should commit to the exact structure of the bitcoind response (especially considering how complex that is in this case).

[t-bast]

Well you can comment on if the RPC as documented looks reasonable.

I'll do that today!

bitcoind docs say "This RPC is experimental and the interface may be unstable."

@glozow is submitpackage still considered experimental? Do you know which parts of that RPC we can consider stable enough (starting for example with bitcoind 29) to rely on?

and even without that warning not sure if the electrum protocol should commit to the exact structure of the bitcoind response (especially considering how complex that is in this case).

I agree: bitcoind provides a very detailed per-transaction result which is the reason behind the complexity of the response, but I think that electrum could expose a much simpler result for the whole package, which simplifies the API. The electrum protocol is mostly used to send txs to nodes we don't control, so we shouldn't expose details about the content of their mempool after the API call. IMHO we should only expose the following:

• on success, nothing more than the fact that the package was successfully published
• on failure, maybe a map wtxid -> error message ?

[tnull]

glozow is submitpackage still considered experimental? Do you know which parts of that RPC we can consider stable enough (starting for example with bitcoind 29) to rely on?

Here is probably the wrong place to discuss this, but if there are really still breaking API changes coming, it might be nice to clean up the minor inconsistencies in the current API/result types (stuff like mixing _ and - as delimiters in variable names)?

• on success, nothing more than the fact that the package was successfully published
• on failure, maybe a map wtxid -> error message ?

That's basically what I suggested offline, too, even though we in LDK currently treat broadcasting as a black box, i.e., never actually handle/trust any return values due to its inherently fallible nature. So SGTM.

[t-bast]

in LDK currently treat broadcasting as a black box, i.e., never actually handle/trust any return values due to its inherently fallible nature.

That's how we use it as well! We log the error message because they may be informative, but we'll keep trying to publish until confirmation, and I believe all mobile wallets should have the same behavior, which doesn't require a complex API response.

[glozow]

bitcoind docs say "This RPC is experimental and the interface may be unstable."

@glozow is submitpackage still considered experimental? Do you know which parts of that RPC we can consider stable enough (starting for example with bitcoind 29) to rely on?

The main reason for "experimental / unstable" label is that you cannot expect the package to propagate (we wanted to be extremely clear about that), especially if it is beyond 1-parent-1-child. I expect we'll support more topologies in the future, but there is no guaranteed timeline.

I'm not aware of any plans to change the API, but please open an issue or PR to bitcoin/bitcoin if you think something should be changed or added. Certainly having real users would make me want to keep it more stable.

[t-bast]

Thanks for the clarification! If Electrum provides a very simple API on top of submitpackage (which looks like what we're heading towards) then it should be all good 👍

Real users are coming, you'll get quite a bunch of them all at once when lightning starts using this as the preferred commitment format 🔥

[SomberNight]

This is now part of protocol version 1.6 (#6).