Pages:
Author

Topic: Lightning Network fraud possible? (Read 328 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
August 17, 2018, 01:05:08 AM
#23
Ah, Ok.. I also understand this much better now. I think the main problem I have with this, is the total transparency of the transactions. The only tx that will be auditable will be the settlement tx on the Blockchain and the tx when the channel is opened. The 1000s of tx's that are done with the channel is not auditable.  Huh

How will this be handled in a dispute?   Huh

Interesting question. I think asking both parties to share all transaction/HTLC would be fastest way, even though there's anonymity/privacy concern to both parties and anyone who use their channel to route transaction.

No, it is not about anonymity and privacy, remember with on-chain tx's all the tx's are recorded on the Blockchain, so it is easy for someone to audit the tx history. Will the LN add another layer of anonymity to your tx's, acting as some kind of mixer service, where tx's are done off-chain?

How will my auditors be able to audit my books, if I only provided them with a opening tx and a closing tx on the Blockchain?

Sorry i wasn't being specific, what i meant was both parties share all commitment/updated transaction which happen on LN/off-chain. IMO someone can't manipulate the auditor by only show commitment transaction which give him/her advantage since the other would do the opposite or being honest.
But this won't work if both parties cooperate to manipulate the auditor or only one people who want to show the commitment transaction.

Also, as i mentioned before, few users might think about their privacy/anonymity if the auditor decide to use method that i just mentioned. Please CMIIW.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
August 16, 2018, 02:22:46 PM
#21
How will this be handled in a dispute? receiving sending the payment for that content>   Huh

In this case, request the payment before providing the service, it's as simple as that. Large companies can afford running a Lightning Network node 24/7 so they won't even need watchtowers in case someone attempts to cheat by broadcasting an old state of the channel.

even though there's anonymity/privacy concern to both parties and anyone who use their channel to route transaction.

The nodes which route the payment don't know who initiated the transaction and what the destination is (assuming that they are not the first and the last node). Sharing the transaction history would be enough (more specifically - payment preimage is needed for each transaction since it's a proof of successful payment). Why are you so concerned about privacy when anyone can view the details of on-chain transactions? The Lightning Network helps to increase the level of privacy, but don't expect to be completely safe.


I'm not concerned about privacy, but few users surely have privacy concern. Even though they should privacy-focused cryptocurrency.

2. Scalability: I thought more scalability can be achieved by transacting off-chain, but if, when closing the channels, we must broadcast the same amount of on-chain transactions to spending funds from off-chain hash-locked outputs, won't it choke the blockchain all the same when we attempt to close the channels this way?

With the combination of other scaling solution such as Schnorr Signature (aka Signature Aggression), Channel Factories and eltoo, these will reduce total on-chain transaction count/size significantly.

Schnorr Signature basically makes transaction with multiple inputs only require 1 signature (which created from multiple input signature) which reduce TX size.
I barely understand about Channel Factories and eltoo, so i suggest you to check these site if you curious :
https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work/67187
https://blockstream.com/2018/04/30/eltoo-next-lightning.html
legendary
Activity: 3514
Merit: 1963
Leading Crypto Sports Betting & Casino Platform
August 17, 2018, 12:36:47 AM
#20
Ah, Ok.. I also understand this much better now. I think the main problem I have with this, is the total transparency of the transactions. The only tx that will be auditable will be the settlement tx on the Blockchain and the tx when the channel is opened. The 1000s of tx's that are done with the channel is not auditable.  Huh

How will this be handled in a dispute?   Huh

Interesting question. I think asking both parties to share all transaction/HTLC would be fastest way, even though there's anonymity/privacy concern to both parties and anyone who use their channel to route transaction.

No, it is not about anonymity and privacy, remember with on-chain tx's all the tx's are recorded on the Blockchain, so it is easy for someone to audit the tx history. Will the LN add another layer of anonymity to your tx's, acting as some kind of mixer service, where tx's are done off-chain?

How will my auditors be able to audit my books, if I only provided them with a opening tx and a closing tx on the Blockchain?
copper member
Activity: 85
Merit: 122
August 16, 2018, 08:56:54 AM
#19
But since all off-chain transactions (via HTLCs) are being summarized to one transaction (last state is being published), this is not an issue.
Right, you beat me to it; by summarizing you probably meant something like this:

Quote from: Kallisteiros
Upd: actually, having thought about it, something like this would be neat: if someone sends me the correct preimage, I'll just replace my puzzle output of this amount with a simple output giving him the funds, since I know he can take them anyway, since he knows the preimage. But this would clean up the outputs and consolidate them, so that when the channel closes, it's just one clean transaction signed by me and him without any hash puzzles.

Anyway, this is really really fun. LN seems to be going places.
legendary
Activity: 1624
Merit: 2481
August 16, 2018, 08:52:01 AM
#18
Hmm, now I have a question. If all transactions eventually need to be settled on the blockchain anyway, how does it affect the fees and the scalability?

There are only 2 transactions to be broadcasted: 1 when opening a channel and 1 then closing the channel.
You can do multiple (off-chain) transactions between those 2 (on-chain) transactions. You will have to pay a negligible fee (which is way smaller than the on-chain fee) for routing the payment.

This allows you to do X transactions (depending on the other party and capacity of the channel/route) for the fee of 2 * on-chain fee + X * off-chain fee (very small; currently 0)
The bigger the amount of transactions, the cheaper each tx is (on average).



1. [... ]But my understanding is that HTLC requires a separate transaction output, does it not?

No. When someone decides to close the channel there will be 1 transactions (combining all previously made LN transactions) settled on chain.
The TX mostly will only have 1 output (the address you withdraw to)



2. Scalability: I thought more scalability can be achieved by transacting off-chain, but if, when closing the channels, we must broadcast the same amount of on-chain transactions to spending funds from off-chain hash-locked outputs, won't it choke the blockchain all the same when we attempt to close the channels this way?

If this would be the case, yes.
But since all off-chain transactions (via HTLCs) are being summarized to one transaction (last state is being published), this is not an issue.

copper member
Activity: 85
Merit: 122
August 16, 2018, 08:39:32 AM
#17
Hmm, now I have a question. If all transactions eventually need to be settled on the blockchain anyway, how does it affect the fees and the scalability? Usually, LN is positioned as a way to send a lot more transactions than the current blockchain capacity, and send them cheaper. And I kinda understood why, but now with the introduction of HTLCs I'm not that certain anymore:

1. Fees: I thought that one can save on fees by sending several payments to the same hub that will distribute the payments further. Since it's all happening inside the channel, it will be registered as one big transaction to this hub rather than several. But my understanding is that HTLC requires a separate transaction output, does it not? The end result would be a transaction with one input and a lot of outputs with hash locks. And since it's different hash/preimage for each LN payment, it would require a separate spending transaction per each payment, right? Then the fees must add to the same amount anyway?

2. Scalability: I thought more scalability can be achieved by transacting off-chain, but if, when closing the channels, we must broadcast the same amount of on-chain transactions to spending funds from off-chain hash-locked outputs, won't it choke the blockchain all the same when we attempt to close the channels this way?

Sorry if the questions are invalid, I've learned about the use of HTLCs in LN just now, so I'm pretty much saying things off the top of my head at this point. But maybe someone already knows the answer.

Upd: actually, having thought about it, something like this would be neat: if someone sends me the correct preimage, I'll just replace my puzzle output of this amount with a simple output giving him the funds, since I know he can take them anyway, since he knows the preimage. But this would clean up the outputs and consolidate them, so that when the channel closes, it's just one clean transaction signed by me and him without any hash puzzles.
copper member
Activity: 85
Merit: 122
August 16, 2018, 08:23:49 AM
#16
How will this be handled in a dispute? receiving sending the payment for that content>   Huh
You can wait until the channels close (they eventually will, and maybe even faster than their expiration date), and then you'll see your transaction broadcasted on the blockchain, since it's the only way for them to get your funds.
Or in the case of "pay-per-minute streaming content", you stop streaming to them and ban the peer if they don't send the micropayment in time.
legendary
Activity: 1876
Merit: 3132
August 16, 2018, 08:13:13 AM
#15
How will this be handled in a dispute? receiving sending the payment for that content>   Huh

In this case, request the payment before providing the service, it's as simple as that. Large companies can afford running a Lightning Network node 24/7 so they won't even need watchtowers in case someone attempts to cheat by broadcasting an old state of the channel.

even though there's anonymity/privacy concern to both parties and anyone who use their channel to route transaction.

The nodes which route the payment don't know who initiated the transaction and what the destination is (assuming that they are not the first and the last node). Sharing the transaction history would be enough (more specifically - payment preimage is needed for each transaction since it's a proof of successful payment). Why are you so concerned about privacy when anyone can view the details of on-chain transactions? The Lightning Network helps to increase the level of privacy, but don't expect to be completely safe.
legendary
Activity: 3514
Merit: 1963
Leading Crypto Sports Betting & Casino Platform
August 16, 2018, 07:47:31 AM
#14
Ah, Ok.. I also understand this much better now. I think the main problem I have with this, is the total transparency of the transactions. The only tx that will be auditable will be the settlement tx on the Blockchain and the tx when the channel is opened. The 1000s of tx's that are done with the channel is not auditable.  Huh

How will this be handled in a dispute?    Huh
copper member
Activity: 85
Merit: 122
August 16, 2018, 06:50:00 AM
#13
Alice can easily circumvent being defrauded by choosing a timelock (between Alice and Bob) < timelock between You and Alice.

As i have mentioned in my example:
Then, based on this you are going to create a HTLC with a timelock. This basically says 'I (you) pay X btc to Alice if she finds the secret R during the next Y blocks. If not, the funds return to me'.

Afterwards Alice (using the same hash) creates a HTLC with Bob where she pays Bob X (- fee) btc. The HTLC basically says 'I (Alice) pay X btc to Bob if he finds the secret R during the next Y-1 blocks. If not, the funds return to me'.
Ah, that's spot on! Haven't noticed this part. Very cool.
legendary
Activity: 1624
Merit: 2481
August 16, 2018, 06:47:56 AM
#12
Understood this part, using HTLCs is a brilliant idea. Just can't figure out this one edge case in my head:

Now Bob is able to retrieve the X BTC using the secret R. And as soon as he does, the secret will become available to Alice as well.

What if Bob doesn't share the secret right away, but waits until Alice's channel with me expires (our channel with him is set up for a longer period of time), I take away all the funds in the channel with Alice (she can't do anything, because she doesn't know R), and then Bob publishes tx with R when it's too late for her but not too late for him, thus he also takes away funds from Alice in his channel? We've successfully defrauded Alice, haven't we?


Alice can easily circumvent being defrauded by choosing a timelock (between Alice and Bob) < timelock between You and Alice.


As i have mentioned in my example:
Then, based on this you are going to create a HTLC with a timelock. This basically says 'I (you) pay X btc to Alice if she finds the secret R during the next Y blocks. If not, the funds return to me'.

Afterwards Alice (using the same hash) creates a HTLC with Bob where she pays Bob X (- fee) btc. The HTLC basically says 'I (Alice) pay X btc to Bob if he finds the secret R during the next Y-1 blocks. If not, the funds return to me'.


Your approach of defrauding alice would not have worked here.
Since we are talking about bi-directional channels, the locktime is going to be decreased each 'hop'.



Edit:
Hopefully, this is already included in the emerging LN standards.

From the whitepaper of the LN (source: https://lightning.network/lightning-network-paper.pdf):
Quote
8.
By having a micropayment channel with contracts encumbered by hashlocks and timelocks, it is possible to clear transactions over a multi-hop payment network using a series of decrementing timelocks without additional central clearinghouses.
copper member
Activity: 85
Merit: 122
August 16, 2018, 06:44:58 AM
#11
Figured out the solution: to subvert the attack, each node must make sure that the channel towards the sender side expires later than the one towards the recipient side. Since the channels in question are opened on both sides of that node, it always knows the exact transaction scripts and is always able to verify this condition.

Hopefully, this is already included in the emerging LN standards.

Thanks for helping me figure out how it all works.
copper member
Activity: 85
Merit: 122
August 16, 2018, 06:13:27 AM
#10
Understood this part, using HTLCs is a brilliant idea. Just can't figure out this one edge case in my head:

Now Bob is able to retrieve the X BTC using the secret R. And as soon as he does, the secret will become available to Alice as well.

What if Bob doesn't share the secret right away, but waits until Alice's channel with me expires (our channel with him is set up for a longer period of time), I take away all the funds in the channel with Alice (she can't do anything, because she doesn't know R), and then Bob publishes tx with R when it's too late for her but not too late for him, thus he also takes away funds from Alice in his channel? We've successfully defrauded Alice, haven't we?

Quote
The 'Broken channel'- and 'Rerouting'-part should clear your concerns.
Also very clever, thanks for the reference, doesn't address this case though, if I understood correctly.
In 'Broken channel' paragraph there's an assumption that the secret has been voluntarily given up by the last participant.
In 'Rerouting', it is assumed that the immediate neighbor cooperates and creates a negating transaction, rebalancing the channels.
legendary
Activity: 1624
Merit: 2481
August 16, 2018, 06:08:04 AM
#9
Well, I've signed the money over to her, and I signed it with my key. Now if she signs it and broadcasts it, 2-of-2 multisig is unlocked.

You didn't create a signed transaction and sent to her.

The whole process starts with the recipient (Bob) creating a secret R and sharing its hash with the sender (you).
Then, based on this you are going to create a HTLC with a timelock. This basically says 'I (you) pay X btc to Alice if she finds the secret R during the next Y blocks. If not, the funds return to me'.

Afterwards Alice (using the same hash) creates a HTLC with Bob where she pays Bob X (- fee) btc. The HTLC basically says 'I (Alice) pay X btc to Bob if he finds the secret R during the next Y-1 blocks. If not, the funds return to me'.

Now Bob is able to retrieve the X BTC using the secret R. And as soon as he does, the secret will become available to Alice as well.



Now the only concern is that if Alice-Bob channel expires earlier than Bob-Charlie's, Charlie can maliciously withhold the preimage until A-B channel expires (and Bob can't take Alice's funds, because he can't provide the correct preimage to form the unlocking script, and Alice takes them all because the timelock expired), while Charlie publishes the preimage in time after that to grab Bob's payment;


You might want to read this: https://softblocks.co/lightning-network-in-depth-part-2-htlc-and-payment-routing/

The 'Broken channel'- and 'Rerouting'-part should clear your concerns.
copper member
Activity: 85
Merit: 122
August 16, 2018, 05:59:30 AM
#8
That's why Hashed Timelock Contracts are used in the payment channels.

Quote
Example

    Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
    Alice wants to buy something from Charlie for 1000 satoshis.
    Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
    Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
    Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
    Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
    Bob uses the pre-image to finalize his payment from Alice
Oh, that's smart, I get it now. And I've read bob123's link, same thing. Thank you folks, just what I needed.

Now the only concern is that if Alice-Bob channel expires earlier than Bob-Charlie's, Charlie can maliciously withhold the preimage until A-B channel expires (and Bob can't take Alice's funds, because he can't provide the correct preimage to form the unlocking script, and Alice takes them all because the timelock expired), while Charlie publishes the preimage in time after that to grab Bob's payment; but that 1) requires conspiracy between Alice and Charlie, and 2) we can probably check this condition somehow, by requiring access to and validating all channels in the chain.

Upd: Actually, can we do 2)? I know we're deep into the woods at this point, but I would appreciate if anybody shares their ideas on how this attack can be mitigated.
legendary
Activity: 1876
Merit: 3132
August 16, 2018, 05:48:41 AM
#7
Well, I've signed the money over to her, and I signed it with my key. Now if she signs it and broadcasts it, 2-of-2 multisig is unlocked.

That's why Hashed Timelock Contracts are used in the payment channels.

Quote
Example

    Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
    Alice wants to buy something from Charlie for 1000 satoshis.
    Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
    Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
    Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
    Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
    Bob uses the pre-image to finalize his payment from Alice
copper member
Activity: 85
Merit: 122
August 16, 2018, 05:44:40 AM
#6
Hi Bob :-)

The funds get locked in a multi-sig. If Alice would 'refuse' to pay Bob she wouldn't gain any advantage since she can't get the funds out of the 2-of-2 multisig.
Well, I've signed the money over to her, and I signed it with my key. Now if she signs it and broadcasts it, 2-of-2 multisig is unlocked.

Quote
If an malicious actor 'breakes the rules', an earlier state is going to be published, which depending on the case, can lead to the attacker losing all of his coins.
If an earlier state could be published by me, can't I then defraud an honest Alice and publish the earlier state after she sends money to Bob? I thought the clever idea of channels was that only the second person can actually finish the multisignature and so he's the only one that can broadcast and publish the final state, the latest with the most funds signed over to him.

Quote
To get a slightly more detailed explanation, visit https://thecoinoffering.com/learn/what-is-the-lightning-network/ and scroll down to the part with 3 people involved.
I'll take a look, thank you.
legendary
Activity: 1876
Merit: 3132
August 16, 2018, 05:40:59 AM
#5
Quote
What if she refuses though after I pay to her? Is there a way to make it atomic and trustless?
What if she refuses after you pay to her on the current protocol (forget about LN)?

The problem is that someone might not want to route your payment because it has an impact on every channel that takes part in routing. You can set the fees really high if you don't want to bother with re-balancing your channel in the future. This should not be a problem if you have only one channel open. I have read it once again, I described a different problem.

What if she refuses though after I pay to her? Is there a way to make it atomic and trustless? If so, can anyone point to the description of low-level protocol implementation of this?

You would have to find another route and you would get your money back. We can't force people to route your payment, we can observe the same thing by looking at Bitcoin mining. Mining pools can choose which transactions they want to include in the block (e.g. the ones with higher fees)
legendary
Activity: 1624
Merit: 2481
August 16, 2018, 05:39:18 AM
#4
If I want to pay Bob, and I have opened a channel with Alice, and she has an open channel with Bob, it seems straightforward: I pay to Alice, she pays to Bob.

What if she refuses though after I pay to her? Is there a way to make it atomic and trustless?

It is not like you are sending Alice the payment and hope that she will send it to Bob.
The funds get locked in a multi-sig. If Alice would 'refuse' to pay Bob she wouldn't gain any advantage since she can't get the funds out of the 2-of-2 multisig.

When a channel is open you are basically sending signed transactions back and forth.
If an malicious actor 'breakes the rules', an earlier state is going to be published, which depending on the case, can lead to the attacker losing all of his coins.
This leads to no trust being required into the 'middlemen' to process the payment.


To get a slightly more detailed explanation, visit https://thecoinoffering.com/learn/what-is-the-lightning-network/ and scroll down to the part with 3 people involved.
copper member
Activity: 85
Merit: 122
August 16, 2018, 05:36:33 AM
#3
What if she refuses after you pay to her on the current protocol (forget about LN)?
Refuses to do what? I ask about LN because only LN tries to link together several channels. But it seems you can be easily defrauded since there's trust involved, unlike on vanilla Bitcoin.

Quote
update: Alice and Bob came from here?  Cheesy
https://youtu.be/rrr_zPmEiME
No, they're much older. Adam and Eve of cryptography :-)
https://en.wikipedia.org/wiki/Alice_and_Bob
Pages:
Jump to: