pull down to refresh
I think the tension here came from me choosing the term "irrelevant" to straddle two things: on the one hand, the political sense (see the cypherpunk comments), I'm meaning you can avoid the political decisions or power-plays that might be needed. On the other hand, from a systems design level, "irrelevant" isn't a negative, thought, it's a positive one: it's about what you don't have to include in the analysis, making it simpler. "Doesn't need a new op_code" is about both those things.
The thing that is hopefully becoming irrelevant are all these dreams of enhancing the protocol with features.
Probably, yes. And that's part of it: some bitcoiners consider the desire to add features is pernicious, others do not. It's so much better if we can make new things in outer/upper layers, so there's no need to argue about it.
I think the tension here came from me choosing the term "irrelevant"
Agreed.
It's so much better if we can make new things in outer/upper layers, so there's no need to argue about it.
Optionality is the most powerful feature to any protocol. It often ends in disbelief on SN but I know many bitcoiners, some more OG than yours truly, that are of the opinion than LN isn't "it" and stick p2(w)pkh. And that is fine, because even LN is optional. It's what makes it great.
from a systems design level, "irrelevant" isn't a negative, thought, it's a positive one
I disagree with this, as someone that spend a large part of their career in systems design, simply because at some point your system has to work bottom up too. That's maybe not where all these guys that want to change src/script/interpreter.cpp are coming from, but perhaps that's exactly the issue.
I disagree with this, as someone that spend a large part of their career in systems design, simply because at some point your system has to work bottom up too.
I guess we just have to agree to disagree then. "Separation of concerns" is what I'm referring to, and I feel like (correct me if I'm wrong!) it's one of the most powerful ideas in system design.
(btw I've always found it interesting that that concept is in some ways the best argument for the general concept of privacy, much better than any moral arguments, but it's just unfortunate that only engineer-types, or similar, would "get it").
We could agree to disagree but I am not going to concede to "separation of concerns" either, under the assumption that we're not talking about banking protocols: if you're a bank operating under a banking protocol, you can "enforce" your rules upon the L1. This is because you could cough up the discrepancy between the actual truth (which for Bitcoin is always L1) and your upper-layer IOU truth, and make your user base whole.
If however you are not a bank, but a real protocol, you cannot do that, and therefore the truth MUST be the L1 truth. And with that your concerns aren't separable. They are always linked, no exceptions. You cannot, under any circumstance, retain self-sovereignty for a user of your protocol without having an L1 consequence for every action, and therefore you must, under all circumstances, be integrated with L1. This is why LN is an L2, but nothing else is - everything else is, what on SN is often referred to as a "fake L2", which unfortunately has been correct to date no matter how many followers someone has on X.
Thus, you cannot say that it is irrelevant. Ultimately, any Bitcoin must be backed by L1 sats, or it is either a scam pretending to be an L2, or a shitcoin. When I send sats from my private channel with LNBig through Zeus, the risk is all theirs. When I receive, I have an HTLC risk for a set period (or until I spend more), which is 100% based on L1 script and not LN. The reason why I say Zeus is because that gives you a nice alert that transparently shows you this.
I challenge thee, ser, to define to me in which situation sats accumulation on any real L2 (=LN, all the others will fail at their bridge for rug risk) does not carry an explicit L1-based risk and thus, can (or in my opinion cannot) separate.
=LN, all the others will fail at their bridge for rug risk
Not clear what you're claiming there. If you take my recent Lichen, which is just a way to do stuff like bitvm-ish stuff today, you have cryptographic enforcement of whatever the L2 risk is on L1. As per my paper (see v0.5 of my paper from the repo https://github.com/AdamISZ/lichen) the fundamental mass exit risk is exactly the same as the mass exit risk on Lightning, with the difference that the risk is more acute because the L1 transaction space usage is higher. So it takes a smaller number of simultaneous Lichen exits to overwhelm L1's capacity than LN. But that is a quantitative difference, not a qualitative one. Both elevate censorship resistance to a security-of-funds requirement.
On the other hand, things like ecash and a federated sidechain both have risks of a different quality (and also statechain) which is that you're trusting some or other privileged entities not to behave badly. This is simply not true in Glock, BABE, Lichen, BitVM3 and others (I could also say PIPEsv2 but it is too far from practical today): the exit is enforced by cryptography, not trust.
I was mostly pointing to the potentially viable (due to tx size, maybe) sidechain / sequencers that are taking a bridge in (rather than an L1 deposit.) All these are trustmebro on the intake over LN first, and in the case of ecash/fedi, they're also trustmebro on the non-existing (or did this change recently?) unilateral exit.
The way I see BitVM(-ish) solutions today is that these are not products yet. Maybe I missed something new that is important tho - so please do correct me if I am wrong.
Do you use Lichen for production? This morning I bought 3 zucchini, 5kg of potato and half a dozen of Kakifruit using LN. I only ate some of the potato thus far, they were yum tho. Should I use Lichen instead?
Should I use Lichen instead?
I literally invented [1] it a month ago. Give me a chance! lol
I've been testing it on testnet instances with a couple people but it's way too early to firm it up into a solid thing.
[1] caveat: "invented" claims too much: it's actually about practicality, the core tech was already invented, except for a couple of tweak ideas I added, so exactly to your point, as a modification to all these high-falutin' technical ideas like BABE and Glock which I personally perceive as not (yet) being structured so people could use them in everyday life scenarios.
So if you look at it from that point of view, I hope you can see why I find it unfair for you to accuse it of being impractical as an idea! I mean you'd have to actually read the paper and get into it, to develop an opinion, and I 100% understand not doing that as it's too much of a time commitment to a new thing, but yeah.
But you already ceded the important point: the issue with BitVM-ish approaches is just that they're not practical, yet, and who knows when they will be: we agree on that. The core idea of having it be trustless via cryptography, while difficult, is not non-existent.
By irrelevant I don't mean "those rules don't exist". I mean that they are a background fact which doesn't change.
Thus how my L2 plugs into L1 (and I couldn't agree more with your point that how that plug-in works is absolutely crucial - i.e. what are its trust assumptions) is something one designs, implements and then relies on.
Perhaps we can agree on that? We rely on L1 btc just like we rely on TCP. I only mean by "irrelevant" that we no longer think about something, so it's not part of an argument. It may be more accurate to say something like "arguing about L1 is irrelevant" and not "L1 is irrelevant", which in a literal sense, is obviously false.
So if that's the case, I can accept your unhappiness with my choice of words, though I like to think (as people often do!) "it's obvious what I meant!".
There is a deeper point here about "relying on", too: the 'stagnation' of L1 is a benefit: it lets satellite systems rely on it. So yeah I am one of those weird people who think ossification is good :) The jury's out on whether we've already ossified or not (see e.g. quantum).
Perhaps we can agree on that? We rely on L1 btc just like we rely on TCP.
Yes!!! We 100% rely on L1. Which is why that is the thing you spend 99% of your time on. Because if you fuck that up your protocol is a disaster!
And because we rely on it, we test it, we verify it. It is the single point of failure and it must never ever break - if we're not scammers. And that's why L1 script integrity and the correctness of our integration with it is the most important thing for anyone that relies on it. (i.e. is actually using Bitcoin)
I'm sorry to appear and be unhappy with your choice of words - like I said elsewhere too, I am 100% with the conclusion that people should stop proposing addenda to the protocol. The only 2 proposals I was comfortable with was (a) PQC proposals in general (not picking a finalist yet) because it is preventive, and (b) GSR before it went GSR&E (ðŸ˜), because that was a workable restorative proposal that could provide a better baseline than we have today. I guess I am down to 1 now - which sucks fwiw.
In the end, I don't need any new protocol or even cryptography tho. What I need is 6 months of runway so that I can bring the things Bitcoiners need, to Bitcoiners. There's a lot of bridging to be had - I know because I have to buy stupid fiat every time I want something specific.
I wouldn't be hung up about an experiment/demo requiring op_cat. It was showcasing a direction.
Its exactly that same direction, from where I am sitting. Maybe the next question on things like that ought to be: what can we do without op_cat. Not even a tradeoff, but rather a solution to something new.
I think I agree with all of that but not the "irrelevance". The thing that is hopefully becoming irrelevant are all these dreams of enhancing the protocol with features.