4 upvotes, 1 direct replies (showing 1)
View submission: ⚡ Lightning Network Megathread ⚡
How do you ensure atomicity - that either the value is transfered A->B->C or not at all.
Economics. In order to get the payment from A, B has to pay C. When C collects the payment, it necessarily provides the info B needs to do that.
How do you prevent intermediaries learning information about the payment - in particular the source, the target and the amount.
They know the amount, but the information itself is encrypted in hops. It knows where it came from, and decrypts to find out where it's going, but that's it (plus some magic so the length is padded no to change).
Is it possible for a malicious intermediary to agree to participate in a transaction and then keep the funds. Or conversely could a malicious end point claim that an intermediary was not co-operating when in fact they were?
They can always go down in the middle of a payment and then you have to wait for the blockchain timeouts to get your money unstuck. But they can't keep the funds, no.
Are there DDOS vectors whereby intermediaries say they are willing to participate in multi-hop transactions and then subsequently refuse to do so?
They can slow things down, to the limit of the payment timeout, but if they don't succeed or fail with time to spare, the node adjacent to them will close the channel.
It's possible to disincentivize this further, but it's subtle and didn't make the 1.0 spec...
Hope that helps!
Comment by bitcoind3 at 15/01/2018 at 11:15 UTC
1 upvotes, 1 direct replies
Thanks.
When C collects the payment, it necessarily provides the info B needs to do that.
Ok so when C collects the payment it means B can collect his payment. But what if C never collects? Does that mean the A->B payment is locked up forever?
you have to wait for the blockchain timeouts to get your money unstuck
How so exactly? Does this mean that if a node goes down at the wrong time I need to close the channel and let everything resolve that way?
if they don't succeed or fail with time to spare, the node adjacent to them will close the channel
Hmm - I'm not sure I'd be happy with my channels being closed because some 3rd party payment doesn't get routed. I guess this means that you'd want to take precautions about who you open channels with in the first place. Would this be a centralisation pressure?