Re: [Lightning-dev] Reason for having HMACs in Sphinx

2018-12-04 Thread Rusty Russell
Corné Plooy via Lightning-dev writes: > For instance, the attacking intermediate node might guess that the next > node in the route is the final node; it can test this by completely > replacing the onion packet it sends to the next node with a self-written > onion packet that has the next hop as f

Re: [Lightning-dev] Base AMP

2018-12-04 Thread ZmnSCPxj via Lightning-dev
Except we have invoices with no specified amount (payer dictates how much to pay). Which is why we need to send the total amount to the payee as part of the onion final hop, for the case the invoice has no specified amount. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure

Re: [Lightning-dev] Reason for having HMACs in Sphinx

2018-12-04 Thread ZmnSCPxj via Lightning-dev
Good morning CJP, > > > I think we could stop this type of attack by including some kind of > > > shared secret in the onion message to the final node: > > > I think we get this "for free" if we switch to path decorrelation and > > > points+privkeys instead of hashes+preimages. > > > > Path deco

Re: [Lightning-dev] Colored coins or non-fungible tokens

2018-12-04 Thread René Pickhardt via Lightning-dev
Dear Joao, there are the people from BHB Networks (in Itally) working on colored coins for Bitcoin and Lightning. The main contributor seems to be Alekos Filini. As far as I understand there is quite some progress. You can find more information in their spec repo at: https://github.com/rgb-org/spe

[Lightning-dev] Colored coins or non-fungible tokens

2018-12-04 Thread Joao Joyce
Hi list, Thank you all for the great work. LN is looking amazing! I was wondering if there is any discussion about exchanging colored-coins or non-fungible tokens through the LN. Or even issuance, which I'm not seeing how it would be possible, but recognise that this space is full of surprises

Re: [Lightning-dev] Base AMP

2018-12-04 Thread Christian Decker
Which brings us back to the initial proposal that just signals the awareness of a temporary underpayment with the single "more is coming"-bit. On Sun, Dec 2, 2018 at 11:49 PM Rusty Russell wrote: > ZmnSCPxj writes: > > But what if 2 of those paths fail? > > It would be better to merge them into

Re: [Lightning-dev] Reason for having HMACs in Sphinx

2018-12-04 Thread Corné Plooy via Lightning-dev
>> I think we could stop this type of attack by including some kind of >> shared secret in the onion message to the final node: > I think we get this "for free" if we switch to path decorrelation and > points+privkeys instead of hashes+preimages. > > Path decorrelation means that each hop is giv

Re: [Lightning-dev] Reason for having HMACs in Sphinx

2018-12-04 Thread ZmnSCPxj via Lightning-dev
Good morning CJP, > I think we could stop this type of attack by including some kind of > shared secret in the onion message to the final node: I think we get this "for free" if we switch to path decorrelation and points+privkeys instead of hashes+preimages. Path decorrelation means that each

Re: [Lightning-dev] Reason for having HMACs in Sphinx

2018-12-04 Thread Corné Plooy via Lightning-dev
Thanks Christian, that makes sense. Unfortunately it's not very clear from the BOLT, at least not for me. Now that I think of this type of attack: *in general* the HMAC prevents this kind of attack, but isn't the attack still possible in certain specific cases? For instance, the attacking interm