e goes for the
> overpaying
> > and trusting the recipient to only claim the owed amount, there
> is no
> > need for this. Just pay the exact amount, by deriving secrets
> from the
> > main secret and make the derivation reproducible by intermediate
>
Now that you remind me of the wiki: I remember we discussed this before,
so maybe I was just repeating myself (sorry). It is true the wiki should
be more prominent.
CJP
Op 27-08-18 om 15:19 schreef Christian Decker:
> Corné Plooy via Lightning-dev
> writes:
>>> Aside from th
> Aside from that, spontaneous payments is amongst the most request feature
> request I get from users and developers.
A while ago I realized that spontaneous payments (without proof of
payment, mostly for donations only) can be realized quite easily if the
payer generates the preimage and
leties, which can help
> inform your considerations in your proposed BOLT12.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> On March 8, 2018 11:19 PM, Corné Plooy via Lightning-dev
> <lightning-d
If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.
The payer then only has to
Why put everything in bech32? It hurts readability. The only possible
advantage is that data inside the bech32 blob can be digitally signed in
a convenient way. If you don't need that, I'd keep your data ourside the
bech32 blob, in a (expert-)human-readable format.
Why not follow a regular URL
Op 10-04-18 om 20:34 schreef Tyler H:
>
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized
> properties of the technology and the underlying
> It is a public key hash, yes. But what I refer to is that the
> payee-determined route section, which starts from an introduction point,
> protects the payee from being located by the payer, but how did the payer
> contact the payee in the first place anyway? If it was by IP or non-.onion
> I suppose the use-case here is that the payee uses many TOR addresses with
> only one LN node.
Yes. Use different TOR addresses for things you want to keep separated.
Any TOR address you advertise for channel connections is so widely
shared through gossiping that you can in practice consider
>> 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
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
> * layer 0 (to B): decorrelation_secret = k[b]
> * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b]
I would have less trouble understanding that if it were layer 1 (to C)
instead of (to B).
> The total_decorrelation_secrets serves as the payer-generated shared secret
> between
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
The only reasons I see for keeping the global/local distinction is that
you might not want to gossip everything, either to keep the gossip data
small, or for some privacy reasons. Apparently, that's all very
theoretical so far, as current features don't seem to need either.
Ideally you'd like to
ZmnSCPxj,
Without reading your proposed solution, I don't understand the problem
you describe here:
> David solution effectively makes the exchange node (OM in CJP terminology)
> also the RM in the route.
> However, with use of mere preimages and hashes, it is obvious that such a
> "loop"
Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay,
with the added experience of 2019 Lightning with Sphinx routing and AMP.
https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf
(esp. section 2.1.3)
Please forgive the use of the term "Ripple". 2013 was a different
Rusty,
At the recently held Lightning Conference in Berlin you asked for people
to send you use cases / feature requests for the next-generation
Lightning invoicing. I already did some work on this back in 2018; that
work was interrupted when I started working on other ideas. I believe
CDecker
17 matches
Mail list logo
