Pages:
Author

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

sr. member
Activity: 279
Merit: 435
August 24, 2020, 08:38:37 AM
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?
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.
copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
August 23, 2020, 06:37:33 PM

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.


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.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
August 23, 2020, 06:21:40 PM
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.
How so ? The sender does not have a key in the multisig.
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. Smiley
sr. member
Activity: 279
Merit: 435
August 23, 2020, 11:06:53 AM
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.
Yeah, i know about commitment transactions however i fail to see the attack.
copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
August 23, 2020, 10:46:39 AM

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.
How so ? The sender does not have a key in the multisig.

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.
sr. member
Activity: 279
Merit: 435
August 23, 2020, 07:53:35 AM
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 ...
Yes Bitcoin does allow that, and that's what is used by the channel dual funding proposal Smiley.
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).

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.
How so ? The sender does not have a key in the multisig.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
August 20, 2020, 12:57:05 PM
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.
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.
copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
August 20, 2020, 05:28:01 AM
I think bitcoin too was made overly complicated for the average person
So is fiat money Wink
But none of that matters to the average person: you don't need to understand the complicated details to be able to use it.

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).
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
August 20, 2020, 05:12:20 AM
I think bitcoin too was made overly complicated for the average person
So is fiat money Wink
But none of that matters to the average person: you don't need to understand the complicated details to be able to use it.
copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
August 20, 2020, 05:07:01 AM
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.
sr. member
Activity: 279
Merit: 435
August 20, 2020, 04:11:39 AM
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,

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

and you would also not lose anything beyond transaction fees.

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.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
August 19, 2020, 04:21:52 PM
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.
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  Embarrassed). 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 Smiley

@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.

sr. member
Activity: 279
Merit: 435
August 19, 2020, 09:10:38 AM
I noticed you answered your question yourself after having written the answer, so here it is anyway (TL;DR: you are right).

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?
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.

Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

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).

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.

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.
legendary
Activity: 2898
Merit: 1823
August 19, 2020, 08:54:01 AM
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 Smiley

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 Grin ).

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


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.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
August 18, 2020, 10:45:35 PM
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 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)?
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.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
August 18, 2020, 03:35:34 PM
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 Smiley

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 Grin ).

Edit: There was an error in the first paragraph, I corrected it.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
August 18, 2020, 08:54:55 AM

People in 3rd world countries will use alts not LN.
Because LN still has the deposit and withdrawal transaction fees of BTC, which for some of those people $5 is a month's wages.

Altcoins offer faster confirmations and overall lower costs of usage than BTC's LN combo service.

 
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. 

copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
August 18, 2020, 02:15:50 AM
I believe the problem with using altcoins is they're not as secure, not as robust, and not as valuable as Bitcoin. They can use it as a MOE, but most of the time, convert back to Bitcoin for safe-keeping. How much would the costs of conversion be?

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).

Hey, nice to see this, but can any one elaborate the on chain bitcoin?? am a newbie didnt know about them.

thanks..

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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
August 15, 2020, 07:35:45 AM

Afaik the idea Satoshi had was 1 Satoshi being $1.
I'm pretty sure the idea was that 1 satoshi would never be worth more than a penny
This is considering inflation of the fiat currency doesn't exist and deflation of bitcoin due to lost funds also doesn't exist.
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.
legendary
Activity: 2898
Merit: 1823
August 15, 2020, 06:30:02 AM
The other issue is we are talking USD and such. There are some currencies out there that are worth a lot less then that. And people might need to send what is a fraction of a US penny to someone because where they are that is all they need to do in the local fiat.

-Dave


People in 3rd world countries will use alts not LN.
Because LN still has the deposit and withdrawal transaction fees of BTC, which for some of those people $5 is a month's wages.

Altcoins offer faster confirmations and overall lower costs of usage than BTC's LN combo service.

 



Afaik the idea Satoshi had was 1 Satoshi being $1.

Already you need 2 significant figures to handle cents. Then what if someone from Sweden wants the more accuracy down to a hundredth of a króna? 1 Swedish króna = 0.12 us dollar. So thats already 0.001 Satoshi?

Then there's rupees which need even more sf.

Edit: by sf and significant figures I mean the numbers after the decimal point.


I believe the problem with using altcoins is they're not as secure, not as robust, and not as valuable as Bitcoin. They can use it as a MOE, but most of the time, convert back to Bitcoin for safe-keeping. How much would the costs of conversion be?
Pages:
Jump to: