Topic: (Ordinals) BRC-20 needs to be removed (Read 7771 times)

Aha. With version "10" of the terminal in Windows 11, because of backward compatibility? Or with preserving the old icons, drop-down menus, the whole EXE format, and a lot of other stuff? Or maybe with WinAPI, where the large part of it is compatible even with Windows 95, and is still written in C?

Oh yes, I see how Microsoft hates backward compatibility, and for that reason, every EXE file has the old DOS header with the famous text "This program cannot be run in DOS mode".

As I said in some older topic, the world is unupgradable. You have to maintain the backward compatibility, unless you want to lose a large part of your customers. Every serious thing makes it compatible. Currently, the C programming language is so compatible, that it is no longer a language, but rather a protocol: https://www.youtube.com/watch?v=gqKyP2hXFoA (and Bitcoin is going to be similar, because a lot of altcoins used the CopyCat strategy, so Bitcoin is becoming a protocol, rather than just a coin).

Yeah, and they created Windows Subsystem for Linux to be less compatible with other systems, right? And they Open Sourced the old MS-DOS code for the same reason, right?

Maybe but bitcoin is not like Windows where you can just not support the older operating system anymore.


All that would be fine but bitcoin is now kind of carrying alot of baggage from legacy things. Not only do we have Script, which was the original "programming language" of bitcoin but now they have Tapscript. Taproot is supposed to give all these extra benefits. If this were Microsoft and a new version of Windows they would do away with backwards compatibility with Script and just go with Tapscript but we can't do that. The longer time goes on and the more "upgrades" that occur, the more excess baggage bitcoin is going to have weighting it down in my opinion. And that can't be good. Alot of inefficiency there...

what are you talking about? the right way is how Microsoft does it and how any reasonable company would do it.

Sure, plenty of fools will still buy stupid images, even when people like us are screaming at them that it's an incredibly stupid thing to do.  Thing is, people can either learn the easy way or the hard way.  The people who buy this shit are eventually going to learn the hard way when they lose their money.  Sooner or later, people will be educated.  It's just better if we can expedite that process.  Maybe save a few victims in the process. 

But the point of the matter is, the tokens backed by Bitcoins in a sidechain are issued, and they can be anything in the sidechain, depending on what the consensus is for that sidechain. It could be 1 minute blocks, private transactions, smart-contracts, anything. Whether you call it an IOU or not, I don't care. I'm merely posting about the differences, and why sidechains will never be in the same category with a payment channels network.

I think you have too much fate in people knowing how to do the right thing. Give them a free McDonalds burger and some fries, and many will agree to do whatever you want.

Have you seen that video of the woman who gave away major clues about her password? A news reporter asked people what kind of passwords they use to protect their online accounts. This woman is on camera saying she uses secure passwords and combinations of the school she graduated from, her street address, and her age (I am not sure about the last thing). The interviewer then proceeds to ask her several questions and she basically tells the audience where she went to school, how old she is, and where she lives. Good luck in your education attempts.   

They are transferred off-chain, if by saying off-chain, you mean "outside the main Bitcoin network". But yes, they are on-chain, if you define on-chain as "on any chain, for example sidechain".

In general, if you imagine a network, where all LN transactions are shared with every node, then you will get my idea of decentralized sidechains. Because, according to the rules "sign your coins to peg them in". And LN closing channel transactions contain valid signatures, so they can be pegged into such sidechain. It is even compatible with hiding internal data from third parties, because penalty transactions are encrypted, and you only share them in encrypted way, so the network can see basic things, like "this UTXO was already used", without having direct access to that data, and without having an option to close the channel, if the creators are not willing to do so.

Which means, that the whole product of LN can be used as an input for the sidechain. And the output would contain just some batched transaction, broadcasted into the main Bitcoin network.

You don't have to "issue" a different token. You can just reuse, what is already there. In the same way, you don't have to invent new signed transactions to peg coins in. You can reuse existing output, produced for example by LN (but it is not limited to this case). And then, if you reuse existing signed transactions, then there are two options: both networks are IOU, or none of them are IOU. Because you can use exactly the same bytes in both, point at the same UTXOs, broadcast the same transactions, and so on.

But, why? It'd be boring and very limited. I can think of Satoshi introducing Script as a way to tell the public that "this is more about peer-to-peer transactions", or "play with it, you may think of something smarter than I have".

It would be better if I quoted him directly:

He really had put the effort to create Bitcoin the right way. 

I imagine a decentralized sidechain to issue tokens which are pegged 1:1 with bitcoin. This sounds pretty much like lightning, with the important difference that the tokens are not transferred off-chain.

Decentralized sidechain or not, it still won't belong in the same category as the Lightning Network. They're fundamentally two different networks with different trade-off,  and different security models. "Bitcoins" in a sidechain are tokens issued, the Bitcoins in Lightning are actual UTXOs that have not been settled in the Bitcoin blockchain yet.

1. It is inefficient, but the alternative approach is to have only P2PK-based system, and go through some complex math every time, when you want to introduce any new feature. Or: to have a huge enum, with every introduced contract, and expand it every time, when needed.
2. It is possible to compress things locally, without doing any kinds of forks. So, you can have a node, which only will store signatures, like OP_CHECKSIGFROMSTACK would do, and have some rules on top of that, to make sure your hashed data is compatible with consensus rules.

I wish there wasn't. Script is pretty much a programming language. Why a payment system would require its own programming language to help construct transactions is kind of something i don't think most people even stop t think about. They just think there is a transaction and dont realize they are actually using a little computer program that may have a template but had to be filled in with particular data relevant to their bitcoin. Imagine that, every single bitcoin transaction has to repeat that same computer program even though in many cases the only thing that changes in that program is the data. The program itself is not changing. But it still has to be stored all of it every single transaction. how inefficient is that? 

OP_DUP OP_HASH160