pull down to refresh
Isn't that what Andrew Poelstra was aiming towards with cat+schorr tricks?
it looks like it, but requires op_cat. I took waxwing's meaning here to be "maybe you can figure out how to build the thing you want using weird math, rather than trying to change bitcoin -- stop waiting for permission."
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.
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.
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).
In my perhaps simplistic view, I understood the approach to be: make it so you can do whatever it is that you want to do without waiting for the underlying protocol to change. Sure, you still need to use bitcoin script, but if you can do fancy dancy things with cryptography maybe you don't need to wait for new opcodes to do the things you want.
I'm not sure if this is a reasonable approach, but it sounds interesting.