Topic: The Lightning Network FAQ - page 60. (Read 33463 times)

Definitively. I have also had some thoughts about that. I think it depends mostly on the kind of payment which was made.

The use case I originally had in mind, as I wrote above, is an exchange or web wallet which would allow its users to "withdraw coins to a Lightning channel" with an onchain payment. Of course, if the exchange itself is connected to LN, and the channel of the user who wants this kind of payment is bidirectional, a direct LN payment is a better alternative. But there are cases where an on-chain payment could be preferrable:

- if the user wants to increase his LN capacity
- if he has only an unidirectional channel
- if the service provider (exchange, wallet etc.) isn't connected to LN, for example for regulatory reasons (I read this argument somewhen, but I dunno if it really realistic)

In these cases, for the service provider it doesn't matter to which address he pays, as long as the transaction is under control of the customer. The service provider simply "hands out control" of the used UTXOs to the customer and deducts the amount of them from the user's balance.

So in this case, if I interpret the SIGHASH variants right (according to the above linked article), I could imagine a combination of SIGHASH_ANYONECANPAY with SIGHASH_NONE (if a whole UTXO under control of the service provider is used, the service provider simply "hands it out" to the customer and deducts the amount from his balance once the tx is confirmed - no matter to what address) or SIGHASH_SINGLE (if a part of the coins has to be transferred to a change address of the service provider) could be used for this kind of withdrawals.

What I still not understand is which malleability attack could be arise from that combination. I interpret if the service provider agreed to SIGHASH_ANYONECANPAY and SIGHASH_NONE, then the customer would have complete control over the TXID. He could prepare the funding transaction, exchange commitment transactions with the "channel partner" and then broadcast it. Or am I understanding something wrong?

I don't think so, but i do think that it is an interesting thought because it comes to the blurry limits of what defines a Bitcoin payment. Not the technical mean which is the transaction, but the conceptual action of transferring value.

If you hand me an address, and i do a transaction which pays to another address. Would you accept it as a payment ? No.
If we collaborate to create a transaction to pay you, and i finally broadcast a different transaction, would you accept it as a payment ? You should not. This is not an attack, just an absence of payment.

This is why I think the proof of payment feature of Bitcoin Lightning Network payments is important, and that we *must preserve it*. We can always bikeshed on the definition of an onchain Bitcoin payment, and endlessly argue if there was a transfer of value. If we use the Lightning Network, we just have a proof that the transfer occurred.

Afaik this has the ability to lock funds in some sort of stalemate if you're saying someone double spends the input transaction so the CT becomes invalid itself. Double spending the same funds between two different channels I think wouldn't be possible as the old CT is either already invalid or set to be when the new one is produced - so you'd have to present your new balance as being whatever the last CT said it was.

Also, I think it's generally recommended to leave a wallet open as the CT confirms as I think if you send via mainnet to a CT and something changes while it's unconfirmed - wallets might be coded to. Double spend and return the funds back to you although at the moment only one person funds a ct so I assume the other can't provide funds without both sides agreeing.

The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.

However, I don't know if this attack makes any sense - could the channel partner access these funds or could they only be mobilized again if both channel partners cooperate and provide their signatures to close the channel?

Thanks for the link about dual funding - I will have to read a bit more about sighash ALL and ANYONECANPAY (Edit: for those interested: that seems a pretty good explanation) so I can understand what you meant with the malleability attack vector.

Yeah, i know about commitment transactions however i fail to see the attack.

There's a time lock added to commitment transactions of whatever the dev sets it at but its normally between 24 hours and 2 weeks depending on how active the node is - so this type of attack could be mitigated.

Yes Bitcoin does allow that, and that's what is used by the channel dual funding proposal .
EDIT: (just to be explicit) you would have to have some interaction with the sender though, as they need to know about your input to sign the transaction (with sighash ALL). The other way around would be to use ANYONECANPAY, but it's not possible as it would create a malleability vector (which becomes an attack vector in this case as it would change the txid).

How so ? The sender does not have a key in the multisig.

Ah! I think you're right, I didn't take into account that the receiver of the tx loses control completely over the funds as the sender is the only one signing the transaction which transfer the funds to the channel's "multisig address".

What if we organize the transaction in a different way: if you're the receiver, the sender of the transaction only signs his input, sends this information to you, and you use an additional input controlled by yourself and sign the TX? So you would have the control over the txid. This would result in a bigger transaction (in bytes) but still could have advantages over an approach with two transactions. But I don't know if Bitcoin allows that ...

For the sender this would mean less control over the transaction, but this wouldn't matter for them, for example in the case of the exchange, it would simply reduce your balance in the database.

Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.

The fractional reserve systems are confusing but its better than guineas, pounds, shillings, crowns, pennies....

And yeah I do agree if you have enough tutorials and enough confidence in the concensus then you'll be able to run stuff yourself. And an ln with Central companies isn't much different than what some companies have already tired or do (I think binance has its own token deposit system for currencies).

So is fiat money
But none of that matters to the average person: you don't need to understand the complicated details to be able to use it.

I think bitcoin too was made overly complicated for the average person - but I don't know what the average person wants. Most currency systems could do with a mixture of government banks and private holders imo.

For the general case I tend to agree, but it is too big an assumption here because of how bad it can get.


No! You would loose the complete access to the utxo, as in this case you comitted to a multisig with your channel partner [which you don't trust and] which provided you with a "refund" transaction... Not valid anymore (as it spends a non-existent tx). As this "refund" transaction is actually the first commitment transaction, neither the channel can operate.
The only way out of this is to beg your channel partner to be nice and sign a new refund tx for the real tx.

Both the spender and your channel peer have a leverage on you.

In my post there was an error (because I had changed the wording to be clearer from active to passive but forgot to change a crucial part  ). so I think your post answers the "wrong" question correctly. What I meant was to open a channel for the receiver of the coins, not the sender. Thanks anyway

@darosior: Thanks! So it works a bit like I imagined. But your answer made it clearer for me, above all the part you highlighted about the trust which is necessary for the transaction sender. Incentive-wise, however, in the case the sender is a service like an exchange, which must be profitable and thus "just work", there is no reason for him to "cheat" changing the transaction ID, and you would also not lose anything beyond transaction fees.

Thanks also about the hint about the mailing list discussion, will see if I find it.

I noticed you answered your question yourself after having written the answer, so here it is anyway (TL;DR: you are right).

Yes, but only if the sender effectively cooperates as otherwise your funds would be stuck in limbo.

You need to:

• Start the funding process with your peer (here you get the keys to form the 2of2 Script)
• Get the sender to create a transaction which pays to this Script and hand you the txid
• Complete the funding process with your peer by exchanging the commitment transactions refering to the txid
• Have the sender broadcast the transaction (hence trusting them to not change the transaction, which would change the txid before doing so.

FWIW, it's possible with c-lightning if you want to try this out with the (dangerous) fundchannel_start, fundchannel_complete commands.


It's possible in theory but has not been spec'ed. You can find some discussions about this on the #lightning-dev ML (end of 2018 iirc).


Yes, splice-in / splice-out would be great (and a lot of people are looking forward to it) but is quite complex state-machine-wise.

Gigameg blocks, the miners, the pools, and the data-center-node-operators bear the cost, and also at a cost to the user because he/she cannot verify the transactions him/herself.

I know it's not convenient for most of the people to run a full node, but it shouldn't suggest that the Core developers must make design-decisions that should take away anyone's ability to run one.

The on chain transition to you would need to have two (or more) outputs, 1 the 'on chain' transaction to you and 2 an output that gets 'locked' in a newly opened channel. This would work very similar to someone opening a channel valued less than the value of an input (less tx fees), and the remaining value being sent to one or more change addresses.

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her for me with the same transaction, if the sender cooperates? Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

In theory (if I remember well the funding mechanism of Poon-Dryja channels) at least the first variant (opening a new channel) should not be a problem if you exchange the commitment transactions with your channel counterparty based on the transaction you got from that other person. For this to work, however, the person who has sent the transaction must cooperate and broadcast the transaction to the channel's multisig address only after this exchange took place (which could lead to "logistic" challenges but should be solvable). About the second variant (add the transaction amount to an existing channel), I don't know currently much about splice-ins, but maybe someone here does

I imagine this could be useful if exchanges offered this service. You could withdraw an amount on-chain, and instead to have to do the channel opening transaction yourself additionally, the withdraw amount is added to an existing payment channel or opens another one to a LN node.

---

Ah, and @Khaos77: All altcoins which reach a certain popularity will get the same transaction cost problem as Bitcoin. Even sooner or later with big blocks (if they are not gigabyte-sized ).

Edit: There was an error in the first paragraph, I corrected it.

Providing financial services to third world countries are difficult because of the very small amounts of money involved that will often not result in meaningful profits for anyone for someone in a first world country doing business.

LN may make some inroads into third world countries that are relatively wealthy, but I would see its primary user base to be those in developed world conducting high volume transactions.

Altcoins have been subject to 51%-type attacks with increasing frequency as of recently. This means that for most altcoins, waiting 60 minutes (equivalent to 6 bitcoin confirmations in terms of blocks found), when the altcoin gets the target rate of confirmations, will not give the same level of confidence that it will not be reversed. 

Yeah there's a limit to security with a lot of altcoins for sure and the only two I've looked into that have similar security or theoretically better were litecoin (and decred if the PoS part works).


There's going to be a short answer and a long answer herevand I'll go with the shorter.
So when you receive a transaction the sender signs a receiving transaction identifier of their own in order to spend the funds to you. They then broadcast this transaction to the network so miners can take a look at it and confirm it.

When you want to spend your bitcoin you do the same steps again and sign your input transaction identifier.

The fiat inflation won't be a problem, there still won't be much use for the current equivalent of a penny, even if it's called a dollar by then.
I don't expect Bitcoin deflation due to lost funds to reach an order of magnitude any time soon, so that shouldn't be much of a problem either.