> 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
>
>
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
>
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
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
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
(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
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:
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
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
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
10 matches
Mail list logo
