<unnamed>

Public Key

npub1ag2fg2g28hkp9937ptppmdtm38cl37zmr7w7229g7m75wmgyv73s9avd3v

Profile Code

nprofile1qqsw59y59y9rmmqjjclq4ssak4acnu0clpd3l8099z50dl28d5zx0gcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0pls43l

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-19 17:42:27 UTC

- reply

📅 Original date posted:2023-05-17
🗒️ Summary of this message: The writer suggests implementing an extension for CLN and offers to help with implementation details. They also discuss the possibility of gathering data for lnmetrics.
📝 Original message:
> Re [3]
> > I think with some implementation like cln we can write an extension
> > an deploy in some nodes, I need to go deeper into it but I can help
> > with this. But I would love to discuss how I can help with some
> > implementation details.
>
> An experimental data gathering mechanism for CLN would be great! Seems
> like lnmetrics would be a good home for it - I’ll follow up with you
> when we start working on data collection.
I am also planning to make a ML post regarding lnmetrics, but I
will happy to talk more about the data that we need to get some useful
data from the network.
Cheers.
Vincent.

2023-06-19 17:42:24 UTC

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Gossiping about reputations can lead to unreliable information and attackers can earn positive reputations elsewhere before attacking trusted nodes.
📝 Original message:
Hi all,
> > This gets compounded as soon as we start gossiping about reputations,
> > since now our decisions are no longer based just on information we can
> > witness ourselves, or at least verify its correctness, and as such an
> > attacker can most likely "earn" a positive reputation in some other
> > part of the world, and then turn around and attack the nodes that
> > trusted the reputation shared from those other parts.
> >
>
> Notice that we are not gossiping about our peer's reputation. The only
> thing that a node communicates to its neighbor is whether they see an HTLC
> as endorsed or just neutral, that is, should this HTLC be granted access to
Yeah, this is a good point. If we gossip this information, we may see
different values for the same node, and I'm sure someone will propose a
"proof who is telling the true" for this. I don't want the reputation we
end up with to be gossiped to our peers.
In my last research on this, I noted that some nodes with Tor have a completely
unrealistic vision of the network. They believe that other nodes are
offline, but the problem is actually the overloaded Tor network.
Cheers!
Vincent

2023-06-19 17:42:05 UTC

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: The lightning-dev mailing list may need additional moderators due to the increasing number of emails and discussions on Bitcoin and Lightning.
📝 Original message:
Hi Micheal (and all),
> Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev.
This was discussed yesterday during the open meeting,
now there are two more people that are pretty active
on the list.
So, should be not much delay here anymore.
Cheers!
Vincent.

2023-06-19 17:42:04 UTC

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A public communication platform has become inactive due to off-topic emails and lack of moderation. The author suggests finding a better platform without losing accessibility and history.
📝 Original message:
> Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
>
> Would hate to see this list die but wondering if there's a better place for discussions?
I think currently the list is the most accessible way that we have.
I am not aware of any other tools that are as accessible as the list archive
to search for some history, and also to allow people in 10 years from now to
implement some of the ideas proposed these days.
But I would agree to change communication tools if we do not lose these
two properties.
Cheers.
Vincent.

2023-06-09 13:12:50 UTC

- reply

📅 Original date posted:2023-03-04
🗒️ Summary of this message: The benefits of continuous solutions over binary need to be understood before moving forward. Proposing a practical definition of local reputation and conducting experiments is suggested.
📝 Original message:
Hi all,
Sorry if I jump in the middle of the party!
> Could you explain the benefits of continuous solutions over binary? This is
> something we should definitely understand before going in a more
> complicated direction.
I completly agree! Why we will not propose an practical definition of the local
reputation and we ran some experimentation of how the local metrics is
evaluated in a real environment with a real LN node?
By now we should have the tools to conduct this analysis.
Cheers!
Vincent.

2023-06-09 13:08:49 UTC

- reply

📅 Original date posted:2023-05-11
📝 Original message:
Hi all,
> > This gets compounded as soon as we start gossiping about reputations,
> > since now our decisions are no longer based just on information we can
> > witness ourselves, or at least verify its correctness, and as such an
> > attacker can most likely "earn" a positive reputation in some other
> > part of the world, and then turn around and attack the nodes that
> > trusted the reputation shared from those other parts.
> >
>
> Notice that we are not gossiping about our peer's reputation. The only
> thing that a node communicates to its neighbor is whether they see an HTLC
> as endorsed or just neutral, that is, should this HTLC be granted access to
Yeah, this is a good point. If we gossip this information, we may see
different values for the same node, and I'm sure someone will propose a
"proof who is telling the true" for this. I don't want the reputation we
end up with to be gossiped to our peers.
In my last research on this, I noted that some nodes with Tor have a completely
unrealistic vision of the network. They believe that other nodes are
offline, but the problem is actually the overloaded Tor network.
Cheers!
Vincent

2023-06-09 13:08:18 UTC

- reply

📅 Original date posted:2023-03-04
📝 Original message:
Hi all,
Sorry if I jump in the middle of the party!
> Could you explain the benefits of continuous solutions over binary? This is
> something we should definitely understand before going in a more
> complicated direction.
I completly agree! Why we will not propose an practical definition of the local
reputation and we ran some experimentation of how the local metrics is
evaluated in a real environment with a real LN node?
By now we should have the tools to conduct this analysis.
Cheers!
Vincent.

2023-06-09 13:08:02 UTC

- reply

📅 Original date posted:2023-02-11
📝 Original message:
On Wed Feb 8, 2023 at 9:17 PM CET, Carla Kirk-Cohen wrote:
> Hi list,
>
> Unfortunately we had some technical issues with the recording for
> Monday's call so we're going to have to rely on my memory (a severely
> corrupted data store). Thankfully, Clara jotted down some notes as well,
> but please chime in if you attended and we've missed something out!
>
> Details for next call:
> * Monday 20 February
> * 18:00 UTC (possibly 19:00, be confirmed in a follow up email)
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/3
>
Thanks to write this down, do you think that it is a good idea
to make a public google calendar (or other kind of shared calendar)?
>4. Reputation discussions in LSP Specification
>?Some attendees have been working on a reputation system for the LSP
>specification group [8]. This system is intended to provide standard
>metrics about what makes a node good/bad to connect to in the context
>of a decentralized marketplace. While this work looks at the problem
>from a different perspective, there's a possibility to consolidate
>the efforts. It seems particularly useful in the anti-jamming case
>where a node has newly connected to you, and needs a "start state"
>reputation score. The idea of defining what qualifies as good
>behavior in the Lightning Network is useful across the board. The
>LSP specification group also has bi-weekly calls, and welcomes
>additional participants!
There is also an ongoing attempt to define a kind of standard
for the lightning network metrics started more thatn 1 year
ago, and I also discussed in Oakland (but maybe some people
was scared by the word `server`)
The source code is available here https://github.com/LNOpenMetrics
and for now the basic idea is to collect some data from different
kind of node and analyze them before taking any decision to define
any kind of protocol support via BOLT or BLIPS (I also I'm more inclined
to a BLIPS because I think that different kind of node mobile vs LSP)
can deserve different kind of metrics/reputation.
There are some data already accessible via public API (for now) https://api.lnmetrics.info
where it is possible to see some forwarding payment scoring by channels and node
uptime.
Cheers!
Vincent.