Tadge Dryja [ARCHIVE] on Nostr: š Original date posted:2015-11-24 š Original message: If I understand your ...
š
Original date posted:2015-11-24
š Original message:
If I understand your question, it's that the both Alice and Bob must revoke
their previous transaction states and share their revocations, but someone
has to go first.
I don't think there's a good way to make this atomic (fair exchange schemes
based on hash functions instead of signatures *sounds* sortof impossible,
but who knows). But in practice there's not really an attack, in that
every update of a channel state has an initiator.
All the payments are "push" payments; if Alice wants to allocate more to
Bob, she initiates, and if Bob wants to allocate more to Alice, he
initiates. With revocations, the user initiating the channel state change
goes first.
In the case where Alice is sending more coin to Bob:
Alice signs new state, sends half signed tx to Bob.
Bob signs new state, sends half signed tx to Alice.
Alice revokes old state by sending preimage to Bob.
Bob revokes old state by sending preimage to Alice.
Done.
If Bob fails to perform the last step, the payment can be considered to not
have gone through. But Bob doesn't have much motivation to fail there. He
can leave the channel in an indeterminate state by failing to revoke with
Alice, but that indeterminate state is worse for him than a fully
determined state where he has more money.
TLDR It's not atomic so payer goes first.
Hope this helps! If not, let me know, say a bit more about what you think
the attack would be.
-Tadge
On Mon, Nov 23, 2015 at 6:36 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I am still learrning about Lightning Network, slowly but surely.
> As I was reviewing bip 112 (
> https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I
> noticed that HLTC seems to have a potential attack.
>
> When both parties want to revoke a commitment, they need to send one to
> another the revocation preimage.
> However, if not done atomically, Alice intentionally not send her
> revocation after receiving Bob's thus preventing Bob to withdraw his funds.
>
> Am I missing something ?
>
> The only way I see of fixing as is, is to require a third party expecting
> he does not collude, but this defeat the whole purpose.
>
> Nicolas,
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151123/fc57500a/attachment.html>;
š Original message:
If I understand your question, it's that the both Alice and Bob must revoke
their previous transaction states and share their revocations, but someone
has to go first.
I don't think there's a good way to make this atomic (fair exchange schemes
based on hash functions instead of signatures *sounds* sortof impossible,
but who knows). But in practice there's not really an attack, in that
every update of a channel state has an initiator.
All the payments are "push" payments; if Alice wants to allocate more to
Bob, she initiates, and if Bob wants to allocate more to Alice, he
initiates. With revocations, the user initiating the channel state change
goes first.
In the case where Alice is sending more coin to Bob:
Alice signs new state, sends half signed tx to Bob.
Bob signs new state, sends half signed tx to Alice.
Alice revokes old state by sending preimage to Bob.
Bob revokes old state by sending preimage to Alice.
Done.
If Bob fails to perform the last step, the payment can be considered to not
have gone through. But Bob doesn't have much motivation to fail there. He
can leave the channel in an indeterminate state by failing to revoke with
Alice, but that indeterminate state is worse for him than a fully
determined state where he has more money.
TLDR It's not atomic so payer goes first.
Hope this helps! If not, let me know, say a bit more about what you think
the attack would be.
-Tadge
On Mon, Nov 23, 2015 at 6:36 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I am still learrning about Lightning Network, slowly but surely.
> As I was reviewing bip 112 (
> https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I
> noticed that HLTC seems to have a potential attack.
>
> When both parties want to revoke a commitment, they need to send one to
> another the revocation preimage.
> However, if not done atomically, Alice intentionally not send her
> revocation after receiving Bob's thus preventing Bob to withdraw his funds.
>
> Am I missing something ?
>
> The only way I see of fixing as is, is to require a third party expecting
> he does not collude, but this defeat the whole purpose.
>
> Nicolas,
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151123/fc57500a/attachment.html>;