(Ordinals) BRC-20 needs to be removed

[vjudeu]

of course, a signature can only be 74 bytes apparently so i don't know why they would do that since OP_RETURN is 80 bytes.

Again, it is not a consensus rule, but only a standardness rule:

I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.

And the same is true for signatures: they can be much bigger. It is non-standard, but valid. And you can always combine OP_CHECKSIG with OP_NOT to make it spendable, or do other tricks, like 1-of-3 multisig, where only one signature has to be valid.

Also, this post alone, written by Satoshi, can show you exactly, why OP_RETURN was introduced in the first place: because there are other ways to do the same thing, and those other ways can be more abusive, than having a standardized way to ignore a given output.

[DooMAD]

Perhaps the particular spam *encoding* chosen might be different depending on how the capacity limit was constructed, but that's immaterial to anything you care about.   (and fortunately, the weighing scheme has caused the spammers here to encode their bullshit as witness data, which radically lowers the carrying cost of it for the network). 

you're acting like they will always find a loophole.

Having looked at a few of the discussions on GitHub and the mailing list, that's the conclusion some developers have drawn, yes.  Moving the goalposts only gets you so far.  At best, you're causing a temporary inconvenience to people who are financially motivated to create this spam.  The best "cure" to the problem is to educate people that buying this crap is a waste of money and a con.  That would eliminate the incentive to create it in the first place.  

[Wind_FURY]

Perhaps the particular spam *encoding* chosen might be different depending on how the capacity limit was constructed, but that's immaterial to anything you care about.   (and fortunately, the weighing scheme has caused the spammers here to encode their bullshit as witness data, which radically lowers the carrying cost of it for the network).  

you're acting like they will always find a loophole.

Having looked at a few of the discussions on GitHub and the mailing list, that's the conclusion some developers have drawn, yes.  Moving the goalposts only gets you so far.  At best, you're causing a temporary inconvenience to people who are financially motivated to create this spam.  The best "cure" to the problem is to educate people that buying this crap is a waste of money and a con.  That would eliminate the incentive to create it in the first place.  

Plus teach the newbies that there are more efficient, and cheaper ways to do some shitcoinery if they actually want to do it the "right way". The "right way", merely saying that if you can do it for fees that are under 0.01 cents, then that's where you should probably do it.

That's probably why Runes developers should start pushing the shitcoinery to the Lightning Network, or some sidechain/other off-chain network sitting on top of Bitcoin.

[LoyceV]

The best "cure" to the problem is to educate people that buying this crap is a waste of money and a con.

At best, you can reach a very small percentage of them. If gullible people wouldn't fall for scams, there wouldn't be any scammers left.

[Synchronice]

The best "cure" to the problem is to educate people that buying this crap is a waste of money and a con.  That would eliminate the incentive to create it in the first place.  

There is no way that the "cure" will work, not today. When too many people see how the images of pixelated dumb apes are getting sold for millions of dollars, how dumb pepe memecoin gets a huge market capitalization, how out of nowhere dead meme coin overnight turns into a coin with a huge market capitalization, it's hard to make people believe that this crap is a waste of money when potentially it's possible to make tons of money out of thin air.

If gullible people wouldn't fall for scams, there wouldn't be any scammers left.

I think tat NFTs, Memecoins and similar nonsense piece of arts are the place where most of the crypto money gets laundered.

[larry_vw_1955]

That's a standard rule not a consensus rule. Technically your output script with or without OP_RETURN can be so big so that it fills the entire block. In other words there is no limit on its size other than block size.

why would a scriptpubkey need to be unlimited in size for what is supposed to be a "payment system"?

you have to define a strict format for a transaction call it a transaction template and anything that doesn't matchup to that template gets rejected. for a payment system, you only need a template like this:

sending address: receiving address: amount

bitcoin really made a mess of things with its utxo  model and using SCRIPT language and all these different address types. but we're stuck with it. no going back. the only question is "can bitcoin survive as a payment system?"

now, there is no such thing as utxos anymore. it will be account based. that way there's no extra overhead for people sending things to burn addresses other than adjusting its balance. 

[Wind_FURY]

The best "cure" to the problem is to educate people that buying this crap is a waste of money and a con.

At best, you can reach a very small percentage of them. If gullible people wouldn't fall for scams, there wouldn't be any scammers left.

A large percentage of them might actually NOT be gullible, but merely people who want to gamble on the next narrative, OR who has found there new usage for Bitcoin - a on-chain casino for dick pics and fart sounds.

But depending on their timing, probably there will be some community members who might actually get it right/buy low then sell high. Although the larger percentage of them, usually 90% according to some study, will lose because of holding too long.

[vjudeu]

why would a scriptpubkey need to be unlimited in size for what is supposed to be a "payment system"?

Because it is called "Script" for a reason. The first version, created at a time of the whitepaper, used only public keys, and nothing else. There was no OP_CHECKSIG or anything like that. Also, the field "scriptPubKey" is called that for a reason. I guess in the older version, it could be named just as "pubKey", and could contain just some 65 bytes for some uncompressed public key. In that case, no limit was needed, because public keys had just their default sizes, expressed as PUBLIC_KEY_SIZE constant in "key.h" file, with value 65 (bytes).

And then, imagine you have some working code, which works fine with public keys and signatures. Imagine there is no Script. And imagine you want to add one. Then, why would you put any limit on top of that? Satoshi added limits only in places, where there was a need to do so. Initially, there was nothing like "the block size limit" either. However, there was an implicit limit of 32 MiB for a P2P message, which means, that even if a bigger block was compatible with consensus rules, then you had no way of sending that block, without constructing some P2P message, and sticking with limits for network messages.

you have to define a strict format for a transaction call it a transaction template and anything that doesn't matchup to that template gets rejected.

Guess what: in the old version, it was not a thing, to even reject a non-standard transaction! It was added later:

Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little

Note that it was added in version 0.3.18, not 0.1.0.

now, there is no such thing as utxos anymore. it will be account based.

If you have an account-based system, instead of having coin-based system, then it is bad for privacy. It encourages address reuse, and in account-based model, it is much cheaper to reuse an address. Which means, that anyone visiting your address, can learn a lot about all of your payments.

uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.

The data is mostly hashes and keys and signatures that are uncompressible.

The speed of initial download is not a reflection of the bulk data transfer rate of the protocol.  The gating factor is the indexing while it downloads.

[garlonicon]

Also, the field "scriptPubKey" is called that for a reason. I guess in the older version, it could be named just as "pubKey", and could contain just some 65 bytes for some uncompressed public key.

Sounds reasonable, if you also consider, that we have "scriptSig", which could be named just "sig" in the previous code.

[ABCbits]

That's a standard rule not a consensus rule. Technically your output script with or without OP_RETURN can be so big so that it fills the entire block. In other words there is no limit on its size other than block size.

why would a scriptpubkey need to be unlimited in size for what is supposed to be a "payment system"?

you have to define a strict format for a transaction call it a transaction template and anything that doesn't matchup to that template gets rejected. for a payment system, you only need a template like this:

sending address: receiving address: amount

bitcoin really made a mess of things with its utxo  model and using SCRIPT language and all these different address types. but we're stuck with it. no going back. the only question is "can bitcoin survive as a payment system?"

now, there is no such thing as utxos anymore. it will be account based. that way there's no extra overhead for people sending things to burn addresses other than adjusting its balance. 

Some of your question/thought could be answered by the fact satoshi wanted to support all kinds of transaction.

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

--snip--

And FYI, you could add script directly on scriptpubkey, rather than using P2SH, P2WSH or P2TR. Such transaction which do that would be considered as non-standard though.

[Wind_FURY]

I believe the answer to "If it's Bitcoin?", that's where everything starts to be more complicated

The basic rules are simple: you sign your coins to peg them in, and move them to peg them out. And of course, it is Bitcoin, because every signature is compatible with Bitcoin. And if you have something new, then it is expressed as a combination of existing rules. If you think that it is not Bitcoin, then it applies to LN as well (because the main difference is that you don't have to open a channel, if you already have some shared output, and you can reuse existing LN transactions on such sidechain).

Going back to this discussion, and to make things absolutely clear - "Bitcoin" in sidechains are locked in a multisig, then with tokens issued in the sidechain representing the locked Bitcoins. But "Bitcoin" in the Lightning Network are locked in a multisig, but with the actual UTXOs being sent back back and forth between two people in the channel, correct?

Wouldn't that mean one is technically an "IOU", and the other are actual Bitcoins in a "suspended state", like in a mempool?

[vjudeu]

Wouldn't that mean one is technically an "IOU", and the other are actual Bitcoins in a "suspended state", like in a mempool?

I think both are in a similar category, just different ends are off-chain or on-chain. In the first case, you have off-chain channel opening transaction (signed coins to peg them in), and on-chain channel closing transaction (moved coins to peg them out). In the second case, you have on-chain channel opening transaction (moved coins to form a channel), and off-chain channel closing transaction (constantly replaced "signed coins", and published only the latest one).

In the former, you can "cheat" by convincing someone to accept your signature, which could be already shared with someone else. In the latter, you can "cheat" by publishing some earlier state of the channel. In both networks, it is possible to set up some penalty transactions. In the latter, you have to be online to execute this penalty transaction. In the former, you have to just share it in encrypted form with the majority of the "honest" nodes, and it will be automatically broadcasted by some random node.

"Bitcoin" in sidechains are locked in a multisig

Well, multisig is a basic building block, which is used by default. But you can use any contract you want, see: https://bitcointalk.org/index.php?topic=5231460.msg61778369#msg61778369. If you need to form just a test network, then you can use just OP_TRUE as well. And out of OP_CHECKSIGs, you can build many different kinds of contracts, for example: https://groups.google.com/g/bitcoindev/c/mR53go5gHIk

But yes, by default, you have N people behind a given coin, so you have N-of-N multisig, conveniently compressed into a single Schnorr signature.

But "Bitcoin" in the Lightning Network are locked in a multisig, but with the actual UTXOs being sent back back and forth between two people in the channel, correct?

Yes, and forcing people to first move their on-chain coins is a quite serious limitation. The whole change of "what is on-chain" and "what is off-chain" is a small difference, but it completely changes the outcome. Because then, you can move your coins between anyone, without worrying about your "channel capacity". If you have 1 BTC, then you can send 1 BTC, and not "only 0.5 BTC, because of the routing".

And then, the only danger is about accepting some signature, or refusing it, because of the locking conditions. But that kind of flexibility is needed, to quickly upgrade your contracts into anything (including features, which are not available in the Script, like "if SHA-3 of this data matches that hash, then unlock this coin").

[Wind_FURY]

Wouldn't that mean one is technically an "IOU", and the other are actual Bitcoins in a "suspended state", like in a mempool?

I think both are in a similar category, just different ends are off-chain or on-chain. In the first case, you have off-chain channel opening transaction (signed coins to peg them in), and on-chain channel closing transaction (moved coins to peg them out). In the second case, you have on-chain channel opening transaction (moved coins to form a channel), and off-chain channel closing transaction (constantly replaced "signed coins", and published only the latest one).

In the former, you can "cheat" by convincing someone to accept your signature, which could be already shared with someone else. In the latter, you can "cheat" by publishing some earlier state of the channel. In both networks, it is possible to set up some penalty transactions. In the latter, you have to be online to execute this penalty transaction. In the former, you have to just share it in encrypted form with the majority of the "honest" nodes, and it will be automatically broadcasted by some random node.

I believe not because they have different trade-offs, different pros and cons, different security models, and they're just fundamentally different. Liquid Sidechain can't be placed in the same category with the Lightning Network, no? 

Plus I don't think either is bad, or that the one should be used over the other one. It merely depends on what the person needs/wants, and whether he/she accepts the trade-off.

[vjudeu]

Liquid Sidechain can't be placed in the same category with the Lightning Network, no?

Of course, because current sidechains like Liquid are centralized. But I think it is possible to make a decentralized one.

[pooya87]

why would a scriptpubkey need to be unlimited in size for what is supposed to be a "payment system"?

Only Satoshi can say the exact reason. We can speculate. Logic suggests the reason is for scalability and forward compatibility. Putting restrictions on output scripts as part of the consensus rules could introduce complications for future work without breaking backward compatibility.

you have to define a strict format for a transaction call it a transaction template and anything that doesn't matchup to that template gets rejected.

We have something like that called standard rules.

bitcoin really made a mess of things with its utxo  model and using SCRIPT language and all these different address types.

Not at all. The smart contracts (the script) is the way that Bitcoin can work decentrally and the alternative ways (like account based instead of coin based) has its own complications and disadvantages as well.

used only public keys, and nothing else. There was no OP_CHECKSIG or anything like that.

Actually P2PK has a OP_CHECKSIG at the end, without it anybody could spend those outputs! Remember that every time you send your coins you are actually locking them up in a smart contract that can only be unlocked if the correct unlocking script is provided and executed automatically by the machine using the Bitcoin script language. So the "machine" has to be told to "check [the] sig[nature]" otherwise it won't do it therefore anybody could spend an output script with pubkey and without OP_CHECKSIG.

BTW even though initial outputs were all using P2PK pretty much all other OP codes existed and P2PKH, P2MS, etc. outputs were also possible to create.

[vjudeu]

Actually P2PK has a OP_CHECKSIG at the end, without it anybody could spend those outputs!

I know. But the whitepaper has no Script described anywhere. And I guess, in the previous version, long before the Genesis Block, instead of "scriptPubKey" and "scriptSig", there was just "pubKey" and "sig", and P2PK was the only supported option. And then, the whole Script support was added into that.

Note that before the Genesis Block, some changes could be backward-incompatible, because when they are in the hands of the creator, then changing things is easy. And for example in November 2008 version, we can see, that the block headers had no versioning, and the difficulty was just expressed as a number of zero bits (exactly as described in the whitepaper).

So, obviously, the only person knowing the truth is Satoshi, but there are many traces to make some conclusions. And I guess that the "P2PK-only" system was there first, and then scripting was added into already working code. Maybe in the middle there was even some code, related to "predefine each Script type separately", and maybe Satoshi even tried this "explosion of special cases", somewhere between the "P2PK-only", and the version with the Script.

BTW even though initial outputs were all using P2PK pretty much all other OP codes existed and P2PKH, P2MS, etc. outputs were also possible to create.

Yes, but there is more to discover. We have a lot of history in GitHub, but there is still quite huge and unexplored area of starting from the empty main() function, and reaching 0.01 version. And maybe there are enough traces to reproduce that process in a more detailed way.

[pooya87]

I know. But the whitepaper has no Script described anywhere. And I guess, in the previous version, long before the Genesis Block, instead of "scriptPubKey" and "scriptSig", there was just "pubKey" and "sig", and P2PK was the only supported option. And then, the whole Script support was added into that.

Whitepaper doesn't need to explain every detail in my opinion. It is just an abstract of the much bigger innovation giving the reader a general idea about how Bitcoin works.

And of course during the development phase when Satoshi is "inventing" Bitcoin, a lot of things could have been different. But what matters here is what was released after Genesis block.

[larry_vw_1955]

And then, imagine you have some working code, which works fine with public keys and signatures. Imagine there is no Script.

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 <script> OP_EQUALVERIFY OP_CHECKSIG

none of that changes just the <script> part but EVERYTHING has to be stored every single time. waste of disc space. just an example of the inefficiencies at play with bitcoin...

[vjudeu]

how inefficient is that?

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.

[Wind_FURY]

Liquid Sidechain can't be placed in the same category with the Lightning Network, no?

Of course, because current sidechains like Liquid are centralized. But I think it is possible to make a decentralized one.

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.