pull down to refresh

144 sats \ 23 replies \ @optimism 8h \ parent \ on: Review of Jimmy Song v. Peter Todd filters debate (Plan ₿ Lugano) bitcoin
Yeah it's been on my mind for a while now.
They wouldn’t take that path. […]
Imagine being wrong in that assessment when dealing with published, signed commits. Or not seeing the full spectrum of potential damage that can be done by concern trolling, predatory litigation and "modern activism" 1. And how that influences politicians, who then direct functionaries and enforcement, who then fuck you up because they hold the guns.
Perhaps, the only feasible path out of this is to break the monopoly deployment in the field of Bitcoin Core. I thought that that's exactly what knots was supposed to be doing? No need for a consensus change, just run knots if you wanna run knots. But the past couple of weeks I've been thinking that maybe the greatest favor we can do to Bitcoin Core maintainers is to fork their software and offer a viable alternative, perhaps optimized for watchtower functionality, which is the opposite of knots. I'm not sold on this yet, but it may be worth the effort if it means they get less shit and can focus on building important features.

Footnotes

  1. I had written 6 paragraphs lamenting the misuse of the wonderful direct borderless communication the internet has given us, where instead of organizing to do things, humanity organizes to tell other people what to do, as if we're all little dictators in our own right... but I'm going to save that one for later. ↩
write
preview
100 sats \ 20 replies \ @ek 8h
But the past couple of weeks I've been thinking that maybe the greatest favor we can do to Bitcoin Core maintainers is to fork their software and offer a viable alternative
I think most of what @justin_shocknet talks about is wrapped in a lot of BS but this is def one of his better ideas
reply
119 sats \ 19 replies \ @optimism 8h
Haha. I'm fearful of labeling what Justin says as bs, even when it feels counter-intuitive, because he's been right in hindsight too often for that; I'm keeping an open mind. In the spirit of not telling other people what to do, I'd not pursue telling someone else to archive their repo though. If that comes, it comes through success of other efforts.
reply
100 sats \ 18 replies \ @ek 6h
I'm fearful of labeling what Justin says as bs
To be clear, I didn't say his ideas are BS, but he wraps them in a lot of BS aka trying to sell them in a disingenuous way so it's hard to listen to him or take him serious.
That's IMO an important difference.
reply
0 sats \ 17 replies \ @justin_shocknet 6h
Example?
reply
0 sats \ 16 replies \ @ek 6h
CLINK, BOLT12, mobile nodes, "routing nodes don't exist"
reply
0 sats \ 15 replies \ @justin_shocknet 6h
What's the BS wrapper?
reply
0 sats \ 12 replies \ @ek 6h
Bxlt12 is effectively a re-implementation of Tor which has proven too unreliable with Lightning
"proven too unreliable" in 2024 when the major lightning implementation did not support and still does not have complete support for BOLT12 yet?
I read this last year, shook my head, and ignored everything else you said, including CLINK as a whole.
reply
100 sats \ 11 replies \ @justin_shocknet 6h
#731289
As @justin_shocknet has always warned, I have found that the onion messaging aspect of bolt12 is very unreliable.
And you're factually wrong, LND did support onion messages, so lack of support has not been a factor in its reliability. It's network engineering 101 that you don't add latency and failure probability, which is exactly what bolt12 does.
I think what you ascribe to being BS are facts that undermine your priors.
Just noticed the stealth edit on routing nodes too, that's derivative from Bosworth himself.
view all 11 replies
0 sats \ 1 reply \ @DarthCoin 6h
reminder: ek is a heavy supporter of Spark... FYI
reply
0 sats \ 0 replies \ @ek 6h
Example?
reply on another page
100 sats \ 1 reply \ @Scoresby 6h
Momentum is such that I would think a competing implementation will need to offer something new or interesting to attract users. Super configurable relay policies is a tough way to go about this because most users don't actually seem to care to configure very much (plug n play is way more attractive). If libbitcoin is able to ship their new version with some kind of really fast IBD, that might be enough to attract new users.
Could a new node implementation compete on development process or review? That might also be attractive, but it's not like Core has a shabby record there. My non dev feeling is that they've done better than most Bitcoin projects in attracting reviewers and contributors.
reply
102 sats \ 0 replies \ @optimism 6h
Momentum is such that I would think a competing implementation will need to offer something new or interesting to attract users.
Yes, this is why I said perhaps optimized for watchtower functionality. Currently this is what you'd use Core for, but is the reference implementation the best place? Should Bitcoin Core be optimized for LN? Can you truly optimize for it if you're supposed to serve all? btcd could be that but it's insufficiently used.
If libbitcoin is able to ship their new version with some kind of really fast IBD, that might be enough to attract new users.
You only do IBD once though. So although that's been Eric's selling point, and it's super useful if you find yourself with some half-custodial wallet that suddenly doesn't work and you need a full chain to recover all your stuff, it's way more interesting for most people to know how this works in day-to-day operation. For this we need a final implementation.
Could a new node implementation compete on development process or review?
No, but it could at least be on-par. Knots isn't.
reply