Feature Request: open channel directly from bitcoind wallet funds

[Sjors]

If the user already has a bitcoind wallet, this would reduce cost and friction for the initial funding step (cli/lightning-cli newaddr). A generic approach would allow funding a channel from any wallet software that has the prerequisite RPC commands.

[cdecker]

That's a great idea, could be a bit more involved though, due to the inherent interactivity in the channel creation, e.g., the endpoints need to agree on the first commit before the funding tx may be broadcast.

There's two ways of doing this:

• Have lightningd communicate with bitcoind directly to set everything up
• Have the user ferry output and raw transactions back and forth

The latter is more flexible and wouldn't require having a hotwallet be the bitcoind sitting next to lightningd, however it also requires users to have knowledge about how to handle rawtransactions.

[Sjors]

The manual ferry approach might be useful for education purposes, but I don't think many people will go through that much effort to save on fees.

Ideally it would allow for a different RPC connection in case the hot wallet is on a different bitcoind instance.

[jb55]

I would prefer the latter as well. For mainnet I have been sending money from my Trezor, so the former wouldn't be useful for me.

I wonder if bip-174 could be useful here as a standard way to move transactions around? cc @achow101 @saleemrashid

[saleemrashid]

it also requires users to have knowledge about how to handle rawtransactions.

I think that's fine. And a simple Python script could do the communication with bitcoind if necessary.

I wonder if bip-174 could be useful here as a standard way to move transactions around?

ACK. I have an experimental implementation of PSBT for TREZOR and I think this is a great standard for cross-vendor interoperability. Therefore, this would be good for initial hardware wallet usage without compromise for other usage.

[ZmnSCPxj]

i also vote for the second option, as it would allow integration with other wallets indeed.

[cdecker]

Ok, that's exposing quite some internals though, and we might stumble over a few things that we hadn't thought about, so I'm not scheduling this for 0.6 just yet 😉

[ZmnSCPxj]

Rough sketch:

openchannel { "node": "<hexid>", "satoshi": 21E6, "?closing_scriptpubkey": "<hex>" }
=> { "scriptpubkey": "<hex>", "addr": "<bech32>", "tempchannelid": "<hex>" }
# Precondition: must be directly connected to the specified node.
# Sends open_channel to node, and waits for accept_channel.
# If closing_scriptpubkey is specified, then all close attempts will pay
# to the specified scriptpubkey (bilateral close, and forwarding from
# unilateral closes).
# Returns the scriptpubkey and corresponding address to pay to,
# as well as the temporary channel ID.

fundingtransaction { "tempchannelid": "<hex>", "txid": "<bitcoin-txid>" }
=> { "channelid": "<hex>" }
# Sends funding_created to node, and waits for funding_signed.
# Informs daemon to wait for funding_locked.
# Caller is responsible for broadcasting tx!
# Caller should broadcast tx after this call returns with success.

fundingcancelled { "channelid": "<hex>" }
=> { }
# Stops daemon waiting for funding_locked on the channel.
# Errors if funding_locked already transmitted or received.
# Useful for RBF, coinjoin/multi-fundchannel transactions.

[jb55]

I'm going to write a psbt lib in C to learn the bip and to see if integration with lightning/trezor/bitcoin, etc wallets is possible...

[achow101]

@jb55 Before you do, there is some discussion of changes to BIP 174 on the bitcoin-dev mailing list that could drastically change the format itself.

[jb55]

@jb55 Before you do, there is some discussion of changes to BIP 174 on the [bitcoin-dev mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016121.html) that could drastically change the format itself.

I've been following that, I'm keeping it in mind as I go. It shouldn't be too hard to switch to the new format if we decide to go that route.

[ZmnSCPxj]

I describe here the restrictions to the funding transaction:

1. The funding transaction MUST spend only SegWit inputs.
2. The funding transaction MUST NOT be broadcast until after the second step (fundingtransaction / fundchannel_continue) completes with a success. This can be lifted with SIGHASH_ANYPREVOUT but requires a change in spec.
3. The funding transaction MUST provide the exact specified number of satoshis to the given address.

The initial design at #644 (comment) is lacking outnum on the funding transaction.