Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack

2020-06-05 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack

2020-05-30 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack

2020-05-29 Thread Subhra Mazumdar
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

[Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack

2020-05-19 Thread Subhra Mazumdar
-->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

[Lightning-dev] Force close of channel with unresolved htlc

2020-05-05 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-16 Thread Subhra Mazumdar
> > > > > > > > > > > > > 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 HTLC from B, C can simply

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-15 Thread Subhra Mazumdar
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 co

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-12 Thread Subhra Mazumdar
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 > machine, increasing the number of communicati

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-12 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-12 Thread Subhra Mazumdar
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,

Re: [Lightning-dev] Blind paths revisited

2020-04-02 Thread Subhra Mazumdar
r 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 harder for the sender to attack the rece

Re: [Lightning-dev] Blind paths revisited

2020-04-02 Thread Subhra Mazumdar
pse 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 sender to have path privacy, it is s

Re: [Lightning-dev] Blind paths revisited

2020-04-01 Thread Subhra Mazumdar
oint/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 partial route is no diff

Re: [Lightning-dev] Blind paths revisited

2020-04-01 Thread Subhra Mazumdar
>> 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

Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND

2020-03-24 Thread Subhra Mazumdar
t; > 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 mimic the situation where r

Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND

2020-03-24 Thread Subhra Mazumdar
;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 if you have

Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND

2020-03-24 Thread Subhra Mazumdar
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

[Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND

2020-03-24 Thread Subhra Mazumdar
sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Subhra Mazumdar
le 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, >>

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Subhra Mazumdar
he 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 was readi

[Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network

2020-01-27 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

2020-01-27 Thread Subhra Mazumdar
hort_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.

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

2020-01-27 Thread Subhra Mazumdar
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-

[Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

2020-01-26 Thread Subhra Mazumdar
e pros 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

Re: [Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network

2020-01-26 Thread Subhra Mazumdar
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

[Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network

2020-01-25 Thread Subhra Mazumdar
subchannel ? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
> > > > > 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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
P to 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 &

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
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 faster t

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
ly 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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-20 Thread Subhra Mazumdar
or 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 microtransactions going on. &g

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2020-01-15 Thread Subhra Mazumdar
tps://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

[Lightning-dev] Byzantine nodes in Lightning network

2020-01-05 Thread Subhra Mazumdar
through this channel ? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Doubt regarding payment channel capacity

2019-11-14 Thread Subhra Mazumdar
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