in a participant does not respond after a
> particular step in the protocol.
> By adding more steps, you simply add more places where a participant can
> stop responding after some step in the protocol, and thus add even more
> attack surface.
>
>
> Regards,
> ZmnSCPxj
>
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
der and the receiver can be the same node, making it appear
> twice in the path.
> >
> > Our assumption that at most one party is corrupted under adversarial
> model holds true for self-payment. Please refer to Corollary 1 of our
> Security Anal
loses 0.24 msat. When B cancels contract with A, it will settle
> by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is
> not desired as B was not involved in mounting the attack. As per the
> objective, even B should earn a remuneration as it got affected by gr
-->B>C
(griefs)
(A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 msat)
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfounda
Hi,
I am having a doubt regarding force closure of channel. Suppose A->B
there is an htlc which has been established for transfering fund. Now
suppose for some unfortunate reason B doesnt have the witness to resolve
htlc and the mean time A suffers crash fault. Then can B close the channel
giv
update transaction.
> > > > > > >
> > > > > > > Prior to step 5, C can simply fail the incoming HTLC from B in
> case its own soft timeout is near.
> > > > > > > Even if E performs step 5 after C has already failed the
> incoming
to provide a
> proof-of-closure after step 2, and before step 2, C can safely return a
> failure with `update_fail_htlc` (and refuse to proceed beyond step 2, thus
> ensuring it can still use the previous commitment that still has no HTLC).
> > >
oof-of-closure after step 2, and before step 2, C can safely return a
> failure with `update_fail_htlc` (and refuse to proceed beyond step 2, thus
> ensuring it can still use the previous commitment that still has no HTLC).
> > > > >
> > > > > Of course, this change will require redesigning the update state
> machi
Ok. But this is a worse situation where C pays money to D but bound to keep
its resource locked for a longer duration, unlike D not responding and C
being able to unlock after the elapse of lock time.
On Mon, Apr 13, 2020, 08:21 ZmnSCPxj wrote:
> Good morning Subhra,
>
> > Hello,
> > So ba
Hello,
So based on what you have stated as possible scenario of griefing
attack, does delay in providing the preimage also counted as a form of
griefing in htlc? Like given the path A->B->C->D, what if C and D has a
lock time of 144 blocks and D responds after 142 block time elapses,
claiming
it is one of a possible number of nodes within some number of hops
> from a particular node, but does not know if it is that exact node, one of
> its neighbors, or one of its neighbor neighbors (etc.) is the actual
> receiver.
> > > > > This should make it harde
empting to locate its node and eclipse it at the Bitcoin layer, or other
> blockchain-layer shenanigans.
> > >
> > > Now, the argument I make is that while the blinding factors in a
> decorrelated PTLC-based payment may be generated by the sender in order for
> the s
added to the
> final point/scalar at the ultimate recipient, and the final point/scalar
> pair is completely controlled by the recipient anyway, so it should not be
> an issue here: the point that the sender will target at the first node in
> the receiver-provided
ly be placed inside the onion rather than passed alongside.
>>
>> Cheers,
>> Rusty.
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
iefing attack further.
>
> Of course, if either B or C is offline at the time, then the new state
> where the HTLC is removed out-of-contract is not possible to sign with both
> parties.
>
> > I know this is not the definition of griefing attack but then can this
> possibly mi
t;continue"}` immediately to other incoming `htlc_accepted` as
> normal, if you implement the plugin in Python the Python C-Lightning plugin
> library should "just work" as far as I know as it transforms the Python
> into an async language, but ask cdecker for that; but i
brary should "just work" as far as I know as it transforms the Python
> into an async language, but ask cdecker for that; but if you have a
> sufficiently monadic framework for asynchronicity (a la Javascript
> `Promise`/Haskell `IO`) it should work like that.)
>
> Regards,
> ZmnSCPxj
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
So that means if we follow a right to left approach for establishing HTLC
i.e. from B to C first then A to B, is there a chance? But I guess that's
doesn't sound logical. Also the point raised by you is valid. B can never
be punished if it is not possessing the secret at the point of
establishment
t; multiple hops but only for the final hop. This penalty idea is the basis
> for doing atomc swaps fairly:
> https://coblox.tech/docs/financial_crypto19.pdf
>
> LL
> On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar <
> subhra.mazumdar1...@gmail.com> wrote:
>
>> Hi,
only for the final hop. This penalty idea is the basis
> for doing atomc swaps fairly:
> https://coblox.tech/docs/financial_crypto19.pdf
>
> LL
> On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar <
> subhra.mazumdar1...@gmail.com> wrote:
>
>> Hi,
>> I
ries to enforce a penalty on the counterparty?
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
er
> one is set with the
> > remaining coins, which can then be freely spent. In the illustrative
> example shown in Figure 4.2, the setup phase starts with the user A
> collaborating with user B to create the transaction Tx A
> > setup , where they split the 10 coins they have
gt; the `short_channel_id` field which includes the block number,
> > transaction number and vout. Since Bitcoin does not allow confidential
> > transactions, we can query the blockchain and find out the channel
> > capacity even when the amounts are never explicitly mentioned
k number, transaction
> number and vout. Since Bitcoin does not allow confidential transactions, we
> can query the blockchain and find out the channel capacity even when the
> amounts are never explicitly mentioned.
>
>
>
>
>
> Ugam
>
>
>
> *From:* Lightning-
os and cons ?
I think that revealing channel capacity make the channels susceptible to
channel exhaustion attack or a particular node might be targeted for node
isolation attack ?
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightni
ction is signed by both users so that it can be eventually enforced
on-chain if required. The rest of the users behave analogously. Note that
operations at each channel in this phase of the protocol can be carried out
in parallel." Does this sound good ?
On Mon, Jan 27, 2020 at 9:4
pens during closing of subchannel ?
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > > Don’t and data in lighting payments unless you have to. It’s super
> DoS-y and rude to your peers. If you’re just transferring a file, you can
> use ZKCP to send an encrypted copy of the file with the encryption key
> being the payment_preim
o send an encrypted copy of the file with the encryption key being
> the payment_preimage, making the whole thing one big atomic action.
>
> On Jan 20, 2020, at 13:33, Subhra Mazumdar
> wrote:
>
>
> Sounds good. But how do I provide a correctness for the entire asset to be
&
gt; using them is very doable.
>
> On Jan 20, 2020, at 13:23, Subhra Mazumdar
> wrote:
>
>
> But isn't it that the use of ZK proof will render the system slow and
> hence defy the very purpose of lightning network which intends to make
> things scalable as well as fas
miss nearly all relevant context,
> sadly).
>
> Matt
>
> On 1/20/20 6:10 PM, Subhra Mazumdar wrote:
> > Are you referring to the paper Zero knowledge contingent payment
> > revisited ? I will look into the construction. Thanks for the
> > information! :)
> &g
Are you referring to the paper Zero knowledge contingent payment revisited
? I will look into the construction. Thanks for the information! :)
On Mon, Jan 20, 2020, 23:31 Matt Corallo wrote:
> On 11/9/19 4:31 AM, Takaya Imai wrote:
> > [What I do not describe]
> > * A way to detect that data is
stable.
>
> For DOS attack, OG AMP has the same problem. It might that recipient needs
> a limit how many split blocks the recipient accept
>
> > So may be you need several iteration and I presume thats what lightning
> network will pitch in where we have several such microtrans
gt; [2] https://twitter.com/roasbeef/status/964608261830750208
> [3] https://eprint.iacr.org/2016/575
> [4] https://github.com/storm-org/storm-spec
> [5] https://twitter.com/joostjgr/status/1190714028626251779
> [6] https://github.com/lightningnetwork/lightning-rfc/pull/619
> [7]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
>
>
> document on github:
> https://github.com/takaya-imai/data_lightning_atomic_swap
>
> Best regards,
> Takaya Imai
> Email: takaya.i...@frontier-ptnrs.com, takaya.i...@unitedbitcoiners.com
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
through this channel ?
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
resort to such a
strategy opening a low value channel but still accepting multiple
transactions where the total payment value of all transaction exceeds
channel capacity. Please correct me if I am wrong.
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning
37 matches
Mail list logo
