You just can't help but to publicly display your exaggerated ignorance, can you? _I_ use SV. Ergo, your bald blanket assertion is ludicrously false on its surface.


Matter of perspective. In my book, anything that traces its history back to satoshi's genesis block and uses SHA-256 PoW is no mere altcoin.


I've admittedly not been keeping track. I guess you have. Want to list them in the order of creation? Or are you just making shit up again?


By 'farce', do you mean my conviction that SV is the most important implementation of cryptocurrency? I suppose if it ever abandons the principle of being the best possible implementation of the protocol design bequeathed us by satoshi, that might cause me to give up. Though it may just cause me to fight for a return to principles. Exactly as I fight for BTC to return to the principles that initially made it a success.

More anti-jbreher propaganda from the net's #1 jbreher hater. Your personal vendetta is just ... so ... adorable.

We've covered this. You're a slow learner. In no way am I a bitcoin hater.


People are inanimate transitory relationships between people? You don't logic much, do you?


Scathing rebuttal. Not. EyerollCribbedFromJjgPost.png

You just. Don't. Get. It. It is silly to bet your future on a technology which is utterly dependent upon an implementation that has flaws and limitations which you do not only not understand, but you also refuse to learn about. More than silly. DarwinAwardIstic.

Well, that's his title. For all it is worth. Of course, the title is not as important as the content. Do you want to talk about that, or just sling shit?


Quite literally the first time I have come across this assertion. May be true, but I'm not going to just take your word for it. Want to back up your assertion?


It ain't 'shilling', if it is something in which you believe. By definition. Or do you mean to denigrate any advocacy of any position that you personally do not agree with?


Well, he may be trying hard. Though we've known about and discussed these issues with Lightning for years - though perhaps not condensed into five pithy points as he has.


Well, to point out flaws within the Lightning design which seem to be shouted down rather than discussed. If you want to refer to this process as 'discredit', then knock yourself out.


If it is just FUD, it should be easy to provide a convincing rebuttal. None yet in evidence.


Are you lying or just intentionally ignorant? I provided a summary of one of Lightning Labs' important engineer's weaksauce 'rebuttal' just a handful of posts upthread. In case you don't understand the significance, Joost is one of "the actual engineers who's working on LN itself". As just one example which proves how wrong you are. lol, indeed


I don't see how this is relevant to LN, but I'll bite. What 'problems'?


Again, I have responded to this issue upthread. Intentionally ignorant again? Lying again?


Oh, I understand the consequences. By your refusal to engage on the actual issues raised, however, it would seem tacit admission that you have no understanding of the consequences of design decisions behind Lightning.

Well, it provides a workaround, but does not solve it.
Sometimes names are misleading. In this case however, 'Probabilistic Payments' is a very apt description of this mechanism. The payment may or may not happen. Is there something about this that you do not understand?

I also note that the "concern of Rizun's" that you have chosen to 'rebut' is merely one micro-sub-case of one of the listed FFFoLN. Not only is it not a solution (being a mere compromise) to the issue you chose to 'rebut', but the actual one of the FFFoLN of which it is a special case -- namely, that fraction at layer 1 leaks to layer 2 -- has much more damaging consequences. Such as 'persistently full blocks prevent opening of channels, closing of channels, and repudiation of counterparty posting of stale channel state data'.

Bzzt. Try again.

That's your rebuttal? Weak. You don't seem to be openly discussing shit, but rather shouting down reasoned critique with nothing but bluster. I note you've not responded to my observation that you have characterized something you later agreed with as "false rumors and misinformation". Interesting debating strategy. Tell someone they're wrong, the agree with them on the very same point. Of course, you were cornered.


Perhaps you are unaware that Core also relies upon checkpoints? That said, yes. I agree that following core in this bad practice of relying on checkpoints rather than pure PoW was a mistake.


In a limited manner, yes. For everything else, there is SV.

So why do you refer to that point as "false rumors and misinformation"? You contradict yourself.

Bullshit. You can't just point at the entire corpus of material written about LN, and tell me that these concise targeted assertions are disproven therein. Grab one and point me to what you believe is written that disproves it.

If you can, pretender.

Is that so? Do you disagree that -- for example -- friction at layer 1 leaks into layer 2? Or is that assertion an example what you are calling "false rumors and misinformation"?

I keep hearing that. However, nobody ever wants to show their work as to why.


Then why ignore the obvious big hitter?


Schnorr provides a small incremental improvement, yes. Why are they not yet implemented in the Reference Implementation?


Show me a block that has onboarded 4M users?

More handwaving about pie in the sky futures, while LN is fundamentally flawed. In at least five dimensions. And again, as whizbangery, it's a pretty sophisticated mechanism. Unfortunately, however, it brings useful value to only a very limited set of use cases.

But really, as said before, I am looking for cogent rebuttals to Rizun's FFFoLN. Next thing I shoudl look at?

Hmm. That's an awful lot of stuff to dredge through. From a cursory glance, much of which I am already conversant with. Perhaps you'd be so kind as to list which of Rizun's FFFoLN are rebutted by which said articles you have provided?

For the record, the following is my restatement as best I concisely can of Rizun’s ‘Five Fundamental Flaws of LN’:

1) Lightning scales txs not users
2) Friction in layer 1 leaks into layer 2
3) Routing failures are inevitable
4) Much trapped liquidity in the system
5) Running a non-custodial wallet is more cumbersome than onchain

You realize Liqid is a permissioned quasi-sidechain, right?

So I got around to listening to the Stephan Livera podcast featuring Joost Jager. If this is what serves as comprehensive rebuttal to Rizun’s points, you might want to start worrying about the efficacy of LN. Of course, this is just response from a single LN dev, who may not have prepared to discuss Rizun’s ‘Five Fundamental Flaws of LN’. The first half of the interview covered Jager’s work on loop in/out.

For the record, the following is my restatement as best I concisely can of Rizun’s ‘Five Fundamental Flaws of LN’:

1) Lightning scales txs not users
2) Friction in layer 1 leaks into layer 2
3) Routing failures are inevitable
4) Much trapped liquidity in the system
5) Running a non-custodial wallet is more cumbersome than onchain

And the following is my brief capture of the points made by host and guest on these points. These are very brief - I would suggest listening to the podcast yourself to get the full flavor. The numbers on each point correspond to my impression which of Rizun’s FFFoLN are being referred to. YEs, these are sketchy outlines of their discussion. Again, listen to the podcast for in depth info devoid of my spin (which I have tried to avoid). In roughly chronological order:

SL (stating Rizun’s points):
2) variability of fees cause problems at the Lightning layer
5) drive too much custodial wallet use
JJ:
5) very true at the moment - decentralized solutions are hard - just early - lot of work to do
   don’t see why fundamentally it won’t work to automate cumbersome parts
SL:
1) hard to onboard users - LN scales txs, not users - over time, not enough UTXOs for each person to be sovereign; think this can be solved via multiparty txs
JJ:
1) good problem to have
SL:
2) can’t we just wait for fees to come down?
JJ:
2) yes
SL:
2) Friction from layer 1 can cause problems on layer 1
JJ:
2) have no answer - if need to post cancel on chain at $1000 fee, that’s a problem
SL:
2) Stop and Decrypt says that fees only go up in USD value, not BTC
5) Need to be online to receive payment
JJ:
5) who is not always online?
5) permanent uptime at home, mobile client as a remote control to that server
5) maybe create some sort of mailbox which would hold payment until online
SL:
some can be solved by engineering
2) just make the retaliation window sizable
3) problem finding route with sufficient liquidity
JJ:
3) perhaps reputation can inform routing - this would increase success percentage
SL:
3) what about mobile phones needing to route? Does phone require entire graph?
JJ:
3) reputational routing might lead to many channels being private to guard reputation, this will reduce size of routing graph
3) hybrid - whitelisted/blacklisted nodes - weakens decentralization, but may work for mobile
SL:
4) trapped liquidity
4) but loop will help
JJ:
4) yes, loop can help inbound liquidity (seems to misunderstand the issue as only transactional -ed)
4) perhaps inbound liquidity may be provided at no cost
SL:
Rizun skeptical this complexity cannot be abstracted away
I think SPV is overly romanticized - holding onto UX that is infeasible in long term
JJ:
The question may be whether onchain is viable in the long term
LN is inherently complex, onchain is easier
SL:
Last thoughts?
JJ:
In general, it’s pretty early - huge fees are speculative; 4B people to use? LN solves a current problem
Would like to see a killer app that LN uniquely solves. Micro tx space would be likely as unique value.
Would like to improve payment reliability

——

All in all, as a rebuttal to Rizun’s FFFoLN, I find this unpersuasive in the extreme. While I am already a known LN skeptic, I see nothing in the above that contradicts a single one of Rizun’s points.

Perhaps I should just wait until the next contender arrives to dispel Rizun’s FFFoLN?  Dunno. But as I said earlier, if all my eggs were in the Lightning basket, I be starting to get scared about now.

Ha. We all learned the folly of weak brainwallets back in 2011 or so. Which is a more likely explanation than the 'poor wallet implementation' vector postulated in the article.

Such as Layer 2 solutions? Stated only partly in snark/sarc.

Note that fixing the protocol where it stood at v0.1 would stave off any bloat on the wire.

It is certainly undeniable that the computing infrastructure we have today allows many more use cases than than of a generation ago (or even of a year ago). Accordingly, 'bloatware' as an argument is weaksauce. Yes, as processing power cost drives toward zero, it makes sense to spend more computing cycles for a more enjoyable experience. This I see as positive.

Maybe you're the outlier that wants to watch their porn in glorious Hercules compatible resolution on a monochrome screen at 3 frames per minute. I dunno. But you'd certainly be in the minority.

Like I said. Gordon Moore originally formulated it in regards to number of transistors, this is true. But the principle is of much higher applicability. Which, of course, is only one of the oddities with this. For another, it is not a Law. It is a hypothesis, conjecture, or postulate. Nevertheless, once the 'Law' gained some traction, it was backtested to the birth of mechanical computing. And as I said, found to be very tight correlation well within standard deviation for a century or so.

The point being that the strict limited formulation of Moore's 'Law' is not what is applicable to computing. It is rather a special case of a more general principle that holds tight to exponential growth of computational power per unit cost that shows no signs of slowing. While it is true that transistor count per die surface area sees scaling challenges (BTW, were you aware that TSMC is in the process of working the bugs out of their 5nm process?), that is really just a sideshow. Multidimensional lithography, chip-on-die, chiplets, and most importantly computational macro architecture are all undergoing advances that are delivering on the more generalized promise of computations per dollar. And this is the measure of advances needed for things such as scaling Bitcoin. Transistors per sq mm is an archaic measure with no applicability in the larger question.

Depends upon which form you use. Gordon's original formulation spoke only to number of transistors per dollar. However, the more generalized form speaks to computations per dollar - which can be extended back from microprocessors to gate level logic to discrete transistors to vacuum tubes to relays to purely mechanical computing. And currently extended forward in time to multi-core, non-homogeneous computing systems. Which has shown pretty high fidelity to an exponential growth rate for more than 100 years, and shows no signs of attenuating.

So the solution is to move to ... Svalbard?

That seems frightening.

Oh. Hello, $5400.

NO - may days are invariably full, with interesting things I'll never be able to get to due to time constraints.

Maybe the subtext was not obvious. Are you entrusting the provider with your login credentials or buy/sell API access, or other possible exit scam vector?

Incidentally, purse.io has been providing the ability to use crypto on amazon since years. They also provide a substantial discount off amazon's lowest prices. Interesting business model. They match your order with someone that wants to acquire crypto, and make it a three-way transaction. They take both BTC and BCH.