Solidity scripts in Bitcoin transactions using Inscriptions

[odolvlobo]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

[1714166242]

1714166242

[1714166242]

1714166242

[1714166242]

1714166242

[pooya87]

You can inject any arbitrary thing into the bitcoin blockchain by exploiting the flaw in the Taproot scripts the same thing Ordinals Attack is doing. But that doesn't mean they will "expand capabilities" since none of them are part of the bitcoin protocol.
Solidity or Jpegs are seen and treated the same, as raw bytes.

[NotATether]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

That will work but the scripts will be modifying a layer 2 network, not bitcoin directly.

And I still believe that 99% of the uses of such a script will unfortunately also be for spam rather than for anything productive.

[odolvlobo]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

Unless Bitcoin node actually execute and verify those solidity scripts, anyone can embed invalid solidity script or perform illegal operation (e.g. mint near unlimited amount of token). If Bitcoiner want turing complete script, they should consider using Bitcoin side-chain instead.

Well the Bitcoin node doesn't have to execute the scripts. The people that care about the scripts would do that and they could easily verify the validity of the scripts. The effect would be something like a side chain, but embedded in the chain itself.

I don't know if it, or something similar, is a good idea or not, but if it valuable and economically viable, it will happen.

[vjudeu]

I don't know if it, or something similar, is a good idea or not, but if it valuable and economically viable, it will happen.

You can always use a tool in a different way than expected. You can also post scripts on this forum, and have some external tool to execute it. Really, it wouldn't be that much different than pushing it on-chain: you also have a lot of tools that trace all posts, including removed ones, so it is very similar case. Or you can use merit system as a currency, it would also work.

Is it a good idea? Of course not, forum is made to write posts, merit system is made to encourage writing good ones, and Bitcoin is made to pay for goods and services. But every system can be always misused, and then there are two options: something will be fixed, or legitimate users will pay for that misuse.

[Wind_FURY]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

Unless Bitcoin node actually execute and verify those solidity scripts, anyone can embed invalid solidity script or perform illegal operation (e.g. mint near unlimited amount of token). If Bitcoiner want turing complete script, they should consider using Bitcoin side-chain instead.

Well the Bitcoin node doesn't have to execute the scripts. The people that care about the scripts would do that and they could easily verify the validity of the scripts. The effect would be something like a side chain, but embedded in the chain itself.

I don't know if it, or something similar, is a good idea or not, but if it valuable and economically viable, it will happen.

If the script needs to be censorship-resistant, and makes a way for it to be more permissionless, then it will definitely be a good idea. I.E. a mixer that reads instructions onchain, then executes them in a sidechain/offchain. I'm not a very technical person, I don't know if that's possible, but something that increases permissionlessness will always be good for Bitcoin.

[pooya87]

Well the Bitcoin node doesn't have to execute the scripts. The people that care about the scripts would do that and they could easily verify the validity of the scripts. The effect would be something like a side chain, but embedded in the chain itself.

I don't know if it, or something similar, is a good idea or not, but if it valuable and economically viable, it will happen.

The point of using a side-chain is to avoid spamming the mainnet with anything that is not a "transfer of money". It also has other benefits such as being able to have a clear and solid consensus rules that is enforced by a clear and solid network instead of some abstract "agreements" (instead of rules) defining an abstract protocol.

Not to mention that history proves that doing such things on bitcoin blockchain using "abstract agreements" would make those things centralized. Example Tether which is the centralized altcoin that grew using bitcoin blockchain.

[Kryptowerk]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

Great idea but why not directly embed a *solid* language in your few transaction-bytes instead, like c++ for example.
Jokes aside, as already pointed out as long as which-ever-language is not part of the Bitcoin protocol, nothing will happen.  

And hopefully onchain program code (aside from the few op-return commands) will never be a thing with Bitcoin. No need for another turing-complete megachain. Just sidechain that shit or use a normal centralized server, which is probably the better solution in 99.9% of cases anyway.

[Wind_FURY]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

Great idea but why not directly embed a *solid* language in your few transaction-bytes instead, like c++ for example.
Jokes aside, as already pointed out as long as which-ever-language is not part of the Bitcoin protocol, nothing will happen.  

And hopefully onchain program code (aside from the few op-return commands) will never be a thing with Bitcoin. No need for another turing-complete megachain. Just sidechain that shit or use a normal centralized server, which is probably the better solution in 99.9% of cases anyway.

It's probably the best time for developers who want to build on Bitcoin to start exploring Blockstream's Liquid Sidechain if they truly want to make something that utilizes BTC at the center and gives more value to it. Inscribing BRC-20 tokens through Ordinals, then using a centralized/trusted indexer for trades/transfers is definitely NOT a good solution. Although, BRC-20 users will spread the narrative that they're moving Bitcoin development forward, and the plebs will believe it.

[odolvlobo]

Bitcoin doesn't need ...
Bitcoin wasn't designed ...
Bitcoin wasn't intended ...

"If God had intended for Man to fly, He would have given him wings." -- Anonymous

Also, keep in mind that those were the same justifications for Bitcoin Cash and Bitcoin SV.

[garlonicon]

If God had intended for Man to fly, He would have given him wings.

And how people can fly today? Do they have biologically attached wings all the time? No, they use vehicles with wings, that can carry many people at the same time, in the same direction. You don't have to put any physical wings on your body, and fly in the same way as birds. Also, releasing a plane does not mean that you have to take down some birds to start your flight.

The same here: the situation is not that such ideas are wrong on principle. What makes them wrong, is trying to put all of them directly on Bitcoin, using on-chain transactions, and using transaction data directly (instead of using for example commitments, that would be sufficient, and would require no additional on-chain data, then your transaction would be indistinguishable from the regular one).

Also, keep in mind that those were the same justifications for Bitcoin Cash and Bitcoin SV.

They made many mistakes, and you can see, where they are today. They lowered difficulty for no reason. They forced big blocks (by rejecting a block smaller than 1 MB at a certain height). They splitted hashrate (instead of using Merged Mining, and tracing the heaviest chain, if needed). They created replay protection, and they used incompatible sighashes (it was possible to split coins without such hard changes, purely on coinbase level, if someone needs that; also replay protection should not be forced, but fully optional: if someone wants to move coins on both chains, it should be possible with the same transaction).

what about embedding solidity scripts?

Technically, you can do that. Even more: you can go far beyond that. I think we are lucky that most people don't know, how many things are possible, because then you would see much more congested mempool than you saw in the last weeks. Of course, it is possible that someone will misuse Bitcoin again, and will release something again, that will cause another wave of transactions. But then, as it was recently, regular users will pay for that.

[Wind_FURY]

If God had intended for Man to fly, He would have given him wings.

And how people can fly today? Do they have biologically attached wings all the time? No, they use vehicles with wings, that can carry many people at the same time, in the same direction. You don't have to put any physical wings on your body, and fly in the same way as birds. Also, releasing a plane does not mean that you have to take down some birds to start your flight.

The same here: the situation is not that such ideas are wrong on principle. What makes them wrong, is trying to put all of them directly on Bitcoin, using on-chain transactions, and using transaction data directly (instead of using for example commitments, that would be sufficient, and would require no additional on-chain data, then your transaction would be indistinguishable from the regular one).

Thanks for posting! The bolded sentence needed to be said, repeatedly again and again. Because, the people from both sides of the debate have turned it into a war of ideology, when the debate should actually be technical and what's the most efficient way to use a limited resource such as block space in the Bitcoin blockchain.

[odolvlobo]

... the situation is not that such ideas are wrong on principle. What makes them wrong, is trying to put all of them directly on Bitcoin, using on-chain transactions, ...

The bolded sentence needed to be said, repeatedly again and again. Because, the people from both sides of the debate have turned it into a war of ideology, when the debate should actually be technical and what's the most efficient way to use a limited resource such as block space in the Bitcoin blockchain.

If there is a better solution, then people will use it. Perhaps the issue now is that there is currently no better solution.

[vjudeu]

If there is a better solution, then people will use it.

The word "better" is subjective in this case. When Ordinals were created, there were some proposals, how to do the same thing in a different way. But people didn't want to use those alternatives, because their goal is not to have "NFT on Bitcoin" or "Turing-complete contracts on Bitcoin". People wanted "cloud storage on Bitcoin", so the whole concept of transferring value was implemented in a way, where ownership is not forced at all.

Also note that nobody wanted to go through the whole soft-fork process to actually enforce things on-chain. People were interested only in storing things, not enforcing them. They don't care that full nodes don't follow the rules of their protocols. Not to mention that many such inventions didn't touch even testnet3, because if they would, then they could see how zero satoshi outputs could break their code. Another thing is that non-standard transactions are easier to perform on testnet3, so it is easier to test edge cases.

Perhaps the issue now is that there is currently no better solution.

1. Sidechains: you can make a separate chain, then you are no longer limited by "4 MB blocks", so you can execute more things than on Bitcoin.
2. Lightning Network: there are use cases, where you don't need a chain, you can have nodes that can execute many contracts completely off-chain, and only enforce the final result on-chain.
3. BIP-322: you can sign any scripts off-chain, and many times by sharing a signature, you can reach the same effect: proving that some data is connected with some on-chain output.
4. Commitments: you don't have to push data on-chain, many times you need to show that you created it, and connected with some address. It is also censorship-resistant, because you commit first, and reveal later, after reaching many confirmations. But it seems that some people want cloud storage more than censorship-resistance.
5. Signet: if some altcoin is a federation, then it can be easily implemented as a signet. More than that: it is possible to create 1:1 peg with Bitcoin, because there are existing sidechains like Liquid or RSK.
6. Torrents: if you need P2P storage, then you can use existing solutions, and even no blockchain is needed to share your files in a P2P way.

So, there are many different solutions. However, note that the main goal is not to bring new features, but to get some attention, and then people skip testnet3, skip sidechains, and skip a lot of alternatives, because they want to put their things on-chain, so everyone will drop other topics and focus on their products.

Another thing is if you create a new protocol, and you don't touch consensus to enforce that, then is it really better? Because I think if you have some altcoin, then at least those altcoin nodes can enforce your rules. But here, nobody enforces them, they are just huge OP_NOPs, and it is an accident waiting to happen, when some Bitcoin user will make a valid Bitcoin transaction, that will break some altcoin, because nobody thought about enforcing things properly.

[Wind_FURY]

... the situation is not that such ideas are wrong on principle. What makes them wrong, is trying to put all of them directly on Bitcoin, using on-chain transactions, ...

The bolded sentence needed to be said, repeatedly again and again. Because, the people from both sides of the debate have turned it into a war of ideology, when the debate should actually be technical and what's the most efficient way to use a limited resource such as block space in the Bitcoin blockchain.

If there is a better solution, then people will use it. Perhaps the issue now is that there is currently no better solution.

"People using something" doesn't entirely mean that the solution is technically better. For the sake of debate, in onchain NFT and token trading/buying/selling, do you actually believe that it's better to do it inefficiently with blockchain + trusted centralized indexer, or do it where they can be built and done more efficiently? Which solution do you believe will not make people lose money faster?

[odolvlobo]

If there is a better solution, then people will use it.

The word "better" is subjective in this case.

Exactly.

Perhaps the issue now is that there is currently no better solution.

1. ... 2. .... 3. ... 4. ... 5. ... 6. ...

If these are better, then why are they not being used?

Perhaps one of those is a better solution but people just aren't aware. What's the best action to take in that case?

"People using something" doesn't entirely mean that the solution is technically better.

People don't prefer things because they are "technically" better. There may be other considerations.

Better alone isn't enough. That's why side-chain/LN based approach isn't popular even when it's already exist/ready to use before Ordinal protocol is created.

If it is better for me, then that alone is enough. If it isn't better for you, then you have your alternative.

[garlonicon]

If these are better, then why are they not being used?

Because they don't bring that much attention. Remember that time, when bitcointalk became one huge Ordinals board for a moment? Remember discussion on mailing list and GitHub? The reason is the same why if you make a video, when you hit a nail with a hammer, it will be less popular than if you use axe. Using hammer is "better", but using axe will give you much more attention.

Also note that breaking Bitcoin will bring even more attention, after many years, people are still going back to things like Value Overflow Incident. The same with transaction puzzle: there are just normal addresses, and the creator could take all funds at any moment. Nothing is enforced, but it is treated as a legitimate puzzle, even if there is no difference between solving the next output, and moving it by the creator.

Perhaps one of those is a better solution but people just aren't aware. What's the best action to take in that case?

The best way is to bring them a working implementation. However, releasing a good product is harder than releasing just anything, without thinking about consequences. For that reason, I didn't release my own altcoin, even if I could. I don't want to release something, when I know how to break it, how to misuse it, and how some legitimate solution can be easily turned into a scam. It takes a lot of time to release the first version, and planning things in advance is important, because once you publish it, then it becomes upgradable only by soft-forks (unless you centralize it).

[pooya87]

If these are better, then why are they not being used?

The real question you should be asking is the purpose of this whole thing.
These options are better if the purpose is to create a decentralized, censorship resistant, strong protocol to run smart contracts on.
But if the purpose is to have a centralized censorable non existent protocol just to be able to create a market to sell satoshis at a much higher value then none of those options are "better" anymore.

To put simply if you try to sell a token created on Omni layer or on any of the existing sidechains like Rootstock you will never be able to sell it for high prices or at all. But if you create a fake thing directly on bitcoin, we now know that you can sell it for a very high price!

Perhaps one of those is a better solution but people just aren't aware. What's the best action to take in that case?

A real developer is aware and they should be building their projects on top of them and then advertise to let others know. Remember that people didn't know Bitcoin existed in 2008 either.

[d5000]

Something very similar was already attempted more than 5 years ago in Counterparty. There's an old FAQ describing the idea. I believe the code is this branch (or this one).

There were even two attempts, the first as early as 2014. But it seems in 2016 everything was abandoned. I don't know if this had to do with transaction fees or with other difficulties emerging.

Of course, if Counterparty or Inscriptions/Ordinals was used for Solidity, only assets/tokens could be manipulated via smart contracts, not BTC itself, as Bitcoin only follows the Bitcoin Script rules. I believe however that at least BRC-20 tokens are so badly designed (2 tx necessary for a simple transfer!) that it would not make sense at all to try to build a smart contract framework around it.

[minersday]

Here's a crazy idea. Rather than embedding stupid jpegs in the witness data, what about embedding solidity scripts? The capabilities of Bitcoin could potentially be expanded tremendously. Opinions?

The idea of embedding Solidity scripts directly into Bitcoin's witness data is intriguing, but it is important to analyze the consequences and practicality of such an approach. The scripting language used by Bitcoin is based on a stack-based language that differs from Solidity, the programming language used in Ethereum smart contracts. Embedding Solidity scripts would require considerable changes to the Bitcoin protocol and difficulty in obtaining consensus among network members. Additionally, Bitcoin was created with simplicity and security in mind, so introducing more extensive scripting capabilities may increase the attack surface and potentially jeopardize Bitcoin network security. To ensure integrity and dependability, extensive audits and testing would be required.