Re: [Lightning-dev] Dual Funding Proposal

2018-11-29 Thread ZmnSCPxj via Lightning-dev
> 128-bit seed in > open_channel2 could be added, with sorting by SHA(seed | input> | ) and SHA(seed | )? `open_channel2` contains a good amount of entropy --- temporary channel ID, various basepoints. Would not hashing `open_channel2` to get this `seed` be sufficient? Regards, ZmnSCPxj > >

Re: [Lightning-dev] Base AMP

2018-11-29 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, November 30, 2018 7:46 AM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning all, > > > > > I initially suggested we could just have a 2-byte "number of total >

Re: [Lightning-dev] Dual Funding Proposal

2018-11-29 Thread Rusty Russell
lisa neigut writes: > Hello fellow Lightning devs! > > What follows is a draft for the new dual funding flow. Note that the > `option_will_fund_for_food` specification has been omitted for this draft. Hi! Wow, my mailer really mangled this! I've liberally demangled below as I quote. The

Re: [Lightning-dev] Dual Funding Proposal

2018-11-29 Thread Rusty Russell
lisa neigut writes: >> * [`2`:`scriptlen`] >> >> * [`scriptlen`:`script`] >> >> * [`2`:`max_extra_witness_len`] >> >> * [`2`:`wscriptlen`] >> >> * [`wscriptlen`:`wscript`] >> >> >> `script` here is the `scriptPubKey`? This is needed for `hashPrevouts` in >> BIP143 I believe. >> >> What is

Re: [Lightning-dev] Base AMP

2018-11-29 Thread Rusty Russell
ZmnSCPxj writes: > Good morning all, > >> I initially suggested we could just have a 2-byte "number of total >> pieces", but it turns out there's a use-case where that doesn't work >> well: splitting the bill. There each payer is unrelated, so doesn't >> know how the others are paying. > > This

[Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

2018-11-29 Thread Matt Corallo
(cross-posted to both lists to make lightning-dev folks aware, please take lightning-dev off CC when responding). As I'm sure everyone is aware, Lightning (and other similar systems) work by exchanging pre-signed transactions for future broadcast. Of course in many cases this requires either

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

2018-11-29 Thread Christian Decker
Hi Corne, the HMACs are necessary in order to make sure that a hop cannot modify the packet before forwarding, and the next node not detecting that modification. One potential attack that could facilitate is that an attacker could learn the path length by messing with different per-hop payloads:

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-29 Thread Matt Corallo
For the low low cost of 3 witness bytes, I think the simplification of analysis/separation of concerns is worth it, though I agree it is probably not strictly required. On 11/26/18 3:12 AM, Rusty Russell wrote: Matt Corallo writes: Hmm, are we willing to consider CLTV sufficient? In case

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

2018-11-29 Thread René Pickhardt via Lightning-dev
Hey CJP, I am still not 100% through the SPHINX paper so it would be great if at least another pair of eyes could lookt at this. However from the original SPHINX paper I quote: "Besides extracting the shared key, each mix has to be provided with authentic and confidential routing information to

[Lightning-dev] Reason for having HMACs in Sphinx

2018-11-29 Thread Corné Plooy via Lightning-dev
Hi, Is there a reason why we have HMACs in Sphinx? What could go wrong if we didn't? A receiving node doesn't know anyway what the origin node is; I don't see any attack mode where an attacker wouldn't be able to generate a valid HMAC. A receiving node only knows which peer sent it a Sphinx

Re: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment)

2018-11-29 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > > On another topic, how about: > > > > - type 6: `application_data` > > length: variable > > value: unknown > > > > > > Writer MUST only use for final hop, and only if it knows that the final hop > > has a specific application that it is compatible with. > >