Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-05-15 Thread Corné Plooy via Lightning-dev
Hi Christian, ZmnSCPxj , >> - The CSV-encumberance on settlement transactions, which are the ones >> which carry the contracts in the channel, affects all >> absolute-timelocked contracts transported on the channel. Compare to >> Poon-Dryja, where commitment transactions themselves are unencumbe

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-05-15 Thread ZmnSCPxj via Lightning-dev
Good morning Corne, ‐‐‐ Original Message ‐‐‐ On May 15, 2018 9:22 PM, Corné Plooy wrote: > Hi Christian, ZmnSCPxj , > > > > - The CSV-encumberance on settlement transactions, which are the ones > > > > > > which carry the contracts in the channel, affects all > > > > >

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-15 Thread Hiroshi Ueno
Hello ZmnSCPxj, I'm implementing `r` field now to `ptarmigan`. I have more question. `r` field doesn't contain signature like `channel_update`. Do c-lightning check something in the `r` field from payee's invoice? Regards, nayuta-ueno On 2018/05/09 14:17, ZmnSCPxj wrote: Good morning Nayuta-

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-15 Thread ZmnSCPxj via Lightning-dev
Good morning nayuto-ueno, > `r` field doesn't contain signature like `channel_update`. > > Do c-lightning check something in the `r` field from payee's invoice? > No. Invoice has signature for whole invoice. Of course, only payee signature (fee of this channel is fee from the peer of the pay

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

2018-05-15 Thread Christian Decker
Anthony Towns writes: > On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote: >> > The big concern I have with _NOINPUT is that it has a huge failure >> > case: if you use the same key for multiple inputs and sign one of them >> > with _NOINPUT, you've spent all of them. The current prop

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-15 Thread Hiroshi Ueno
Hello ZmnSCPxj, > Payee has incentive to give accurate information about the channel. I understand. Thank you very much. Regards, nayuta-ueno On 2018/05/15 23:23, ZmnSCPxj wrote: Good morning nayuto-ueno, `r` field doesn't contain signature like `channel_update`. Do c-lightning check somet

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-15 Thread Jim Posen
> > You're forgetting the failure cases, where now I can profit. > > If I disconnect from another node, I now have a disincentive to tell > others. At the moment we send an update disabling the channel (though > we should give a few seconds for reconnect first, but whatever). > > Similarly, the re

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-15 Thread ZmnSCPxj via Lightning-dev
Good morning, >> But I can make you look like a delaying node whenever I want. The only >> way to ensure that I lose more reputation than you do is to leak >> information about route length for *everyone*. And even then, it's just >> a matter of numbers. I can make successful payments to myself

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-15 Thread Jim Posen
> > This can still be manipulated if Rusty1 opens a direct channel to Jim. > Then Rusty1 can route payments Rusty1->Jim->Rusty2 that succeed quickly, > then route payments Rusty1->ZmnSCPxj->Jim->Rusty2 that stall. Thus Rusty2 > can have the Jim->Rusty2 reputation boosted, while alternating with >