<unnamed>

Public Key

npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdt

Profile Code

nprofile1qqszprn6g6vhjxszvjsznrl6vpzkc5dv3kyeyzt2rdnn3xt9anxg9lcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswm5fun

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:06:46 CEST

- reply

📅 Original date posted:2022-09-03
📝 Original message:
Hi Alex,
This is quite similar to eclair's cluster mode [1] so I can definitely say
it's a great idea :-)
Our rationale was as much reducing the attack surface (we didn't like our
node being directly accessible from the internet) as improving scalability
(handling the constant flow of connections/disconnections from mobile
wallets, and a ton of gossip).
Some specific points on our implementation:
- there can be N instances of proxy and their number can be adjusted
without downtime
- our proxy also does preprocessing for gossip (they keep an up-to-date
copy of routing table and directly answer queries, and also dedup incoming
announcements before forwarding to the backend, where the announcements are
verified)
- outgoing connections (initiated by an operator from the backend) are also
initiated by the proxy. Even incoming connections from Tor are directed to
the proxy. The backend node handles zero LN connections
- since the front needs the node key for the secure handshake, this led us
to introduce a separate key hierarchy for channel management [2]
- we have considered, but not implemented, a "lockdown mode" where the
front would only allow incoming connections from known peers that already
have a channel
- if your setup has a separate db server (e.g. postgres), and logs are
properly rotated/streamed out, then the resources that typically run out
when scaling up (file descriptors, disk space, etc.) should be really under
control on your main node
Hope that helps,
Pierre
[1] https://github.com/ACINQ/eclair/blob/master/docs/Cluster.md
[2] https://github.com/ACINQ/eclair/pull/1584
Le jeu. 1 sept. 2022 à 19:56, Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220903/3d759580/attachment.html>

2023-06-09 15:04:29 CEST

- reply

📅 Original date posted:2021-11-23
📝 Original message:
> so You propose Acinq / Blockstream / Lightning Labs do not have funds to
run a box or 2 ?
Fwiw we already do that with our main node. It's even better than a demo
one because it has real economic activity, and has a lot of channels to a
variety of nodes implementations and versions.
Sometimes our node is behind eclair master branch, but it's always
up-to-date for critical commits and releases. So we eat our own dog food
and will experience force closes before our users do.
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/fa3738a8/attachment.html>

2023-06-09 14:57:08 CEST

- reply

📅 Original date posted:2019-11-22
📝 Original message:
> The high-level idea would be that the sender must solve a small PoW puzzle
<insert meme: "Yo dawg I heard you like pow systems..." >

2023-06-09 14:54:47 CEST

- reply

📅 Original date posted:2019-04-03
📝 Original message:
Hello ZmnSCPxj,
> Do you refer to the changing from "H"TLC to "P"TLC point-locked timelocked contracts?
> i.e. instead of payment hash / preimage, we use payment point / scalar.
Yes, that is what I meant. Cryptography isn't my strong suit though,
so I'm not able to go into much more details.
Cheers,
Pierre

2023-06-09 14:54:46 CEST

- reply

📅 Original date posted:2019-04-01
📝 Original message:
Hello ZmnSCPxj,
> Unless we propose to massively change the onion packet construction...?
I'm afraid we would have to make some changes. I imagine we would have
two onions:
- one for the adjacent hops (this is the onion we are currently using)
- one for the trampoline hops
The 'trampoline onion' would be contained in the per-hop payload of
the final node of the 'adjacent onion'. So in your example B would:
1) receive the htlc
2) see that it is the last hop in the route, and extract the trampoline payload
3) peel the trampoline onion and see that it should delegate the payment to C
4) find a route to C and set the trampoline onion as payload for C
I haven't studied PR #593 enough to tell how easy that would be
achievable though.
There is another unrelated issue: because trampoline nodes don't know
anything about what happened before they received the onion, they may
unintentionnaly create overlapping routes. So we can't simply use the
payment_hash as we currently do, we would have to use something a bit
more elaborate. (maybe private keys?)
Cheers,
Pierre

2023-06-09 14:51:33 CEST

- reply

📅 Original date posted:2018-10-08
📝 Original message:
> But there's no reason to believe that the invoicer has more knowledge about all but the last hop.
I disagree: there is a good chance that the receiver is a 24/7 running
merchant/website, with a full up-to-date view of the network, whereas
the payer is most likely a mobile wallet with less
accurate/partial/out of date information.
At least this is what we are seeing on the current mainnet. Routing
table sync is hard on mobile clients, and I think that it makes sense
that receivers "help" senders, after all incentives are aligned.
Cheers,
Pierre

2023-06-09 14:51:32 CEST

- reply

📅 Original date posted:2018-10-04
📝 Original message:
Ha! I actually came up with the idea two months ago (but you beat me
to it on the implementation so we're even :-)
https://github.com/ACINQ/eclair-wallet/issues/101#issuecomment-408619207
Le jeu. 20 sept. 2018 à 04:12, Rusty Russell <rusty at blockstream.com> a écrit :
>
> Hi all,
>
> I'm considering a change to c-lightning, where `invoice` would
> automatically append an 'r' field for a channel which has sufficient
> *incoming* capacity for the amount (using a weighted probability across
> our peers).
>
> This isn't quite what 'r' was for, but it would be a useful
> hint for payment routing and also potentially for establishing an
> initial channel. This is an issue for the Blockstream Store which
> deliberately doesn't advertize an address any more to avoid
> centralization.
>
> Thoughts welcome!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:45:08 CEST

- reply

📅 Original date posted:2015-11-19
📝 Original message:
> it will be a talk at Scaling Bitcoin HK.
That's great news! Looking forward to it

2023-06-09 14:45:07 CEST

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Hi guys,
Do you know of any available resources on "segregated witness" ? I
couldn't find any.
Cheers,
Pierre