pull down to refresh
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.
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.
So TCP is irrelevant? Despite also your Bitcoin Core AND your {CLN/LND/Eclair/LDK} requiring it? Odd! To me, netbios is irrelevant, because I don't have anything that uses it. So is Windows, because I don't use it and I don't support it. But TCP is very relevant and so is Bitcoin script. Without either of these I can actually not pay my bills, buy food, have a roof over my head, and so on. This makes it very relevant, in fact, it is so relevant that any change to either of these is a threat to me and I will go to some lengths that probably y'alls will shake your head at when it comes to that.
Yet I fully agree with you that ossification of the current state is probably the best assumption, and that a good protocol ought to not need consensus changes.
We didn't make TCP irrelevant tho? We built on top. If right now you configure your firewall on your laptop and your phone to block all TCP traffic, what still works?