Topic: SRC-20 vs BRC-20 (Read 274 times)

Yes, according to documentation i mentioned earlier.


AFAIK no full node software offer option to prune only witness data, unless you count old software which doesn't support SegWit. And it's not not expensive compared to BRC-20, since SRC-20 create 1 TX while BRC-20 create 2 TX.


I doubt it. As long as Bitcoin remain popular, there will be nodes which store all blockchain data.

The Bitcoin protocol, the transactions and blocks, is also "arbitrary data"
They only get "value" and "validity" due to a convention followed by a group of people.

More seriously: I think this discussion is more about semantics than anything else. Of course neither SRC-20 nor BTC-20 are part of the Bitcoin protocol. But they can constitute an own protocol, based partly on the Bitcoin protocol (let's call it a "derived protocol"). If someone doesn't follow the rules of this "derived protocol", then their transactions will not be valid for those who do follow them. Just as Litecoin or Ethereum transactions aren't valid in the Bitcoin protocol, even if they're based on the Bitcoin protocol.

Only to be clear: All three, BRC-20, CBRC-20 and SRC-20 are in my opinion very bad and inefficient protocols, but they are protocols.

Just SRC-20 shows what may happen if "they" "fix" the "exploit" in Taproot. The spammers find another way to spam and even profit from the spam. I've often mentioned Doginals, which allows the same "data spam" with ancient Bitcoin code from pre-2017 (without Segwit nor Taproot).

IMO it's education (BRC-20 et al. are trash) what's needed, because unfortunately the only technical fix which would be possible is to make Bitcoin much more inflexible (Monero- or Grin-style) to make data storage much more expensive.

Yes.

Isn't "SRC-20" from Bitcoin Stamps? If it actually is, then the data that uses this protocol is stored in the part of the block where the transactions reside, not in the part where the witness data reside. They can't be pruned, but Bitcoin Stamps is also more expensive to use.

Although, some users/collectors might choose Bitcoin Stamps over Ordinals because of, OP's words, "digital permanence".

Here is the source code for the reference implementation of Bitcoin protocol: https://github.com/bitcoin/bitcoin do you see any consensus rules in it anywhere that is allowing you to create a token? Do you see any Bitcoin full nodes enforce the protocol they refer to as "SRC-20", "BRC-20", etc.?
If you don't, then it is not part of Bitcoin protocol. It is just arbitrary data.

Block capacity has to increase based on adoption and usage increase to answer that.
We don't have that today. What we see as "congestion" is the result of a spam attack. The nature of it is the same as what we experienced in 2017, the only difference is in the method of the attack. And we shouldn't increase the capacity based on congestion caused by an attack. We should "prevent" the attack. Ordinals Attack (which is the reason for the congestion) can only be prevented by fixing the exploit in the protocol they're abusing. The rest can only be prevented by the fee market.

How can they be different while they are using the main chain? Please explain as your reply does not have any significance, if it is promoted by an exchange or any other entity it is still using the main chain. This means another congestion in the making, yesterday there was sudden congestion and it is now becoming a new normal for the community with this garbage and the other.

Again the question that always comes to my mind whenever I see something like this is, why can't the developers increase the block size? They did it in the past and now they are reluctant to do it while they are busy allowing these tokens to congest the network. This is not what anyone expected from Bitcoin as we believed it to be a single unique entity without the influence of another cryptocurrency ecosystem.

But since it's technical board, i'd like to clarify some Bitcoiner don't categorize it as token since it's not part of Bitcoin protocol. It's just arbitrary rule created by certain people or group and hope everyone (e.g. wallet and exchange) follow the rule properly. While Bitcoin node would reject invalid regular Bitcoin transaction, Bitcoin node doesn't reject invalid transaction to create/mint/move that token.

That's true about the nature of this scam but I'd like to clarify for the readers that the bold part is not exactly correct since these things are not tokens. It's just arbitrary data. To simplify a token has a definition and needs a smart contract on a smart contract platform where it is enforced.

Bottom line is that the following code snippet that I placed in my comment on this forum is as much a token as the Ordinals Attack transactions are:
I could even find a stupid person and sell them this exact comment for real money calling it "PRC-20 token" (P stands for Pooya lol) but that wouldn't make it a token. It's just arbitrary data.

Because it has no importance to the Bitcoin network, except just keep bloating it and destroying its primary purpose?
To me, it's just another jargon for a new type of tokens which are targeting newbies who think they will make money if they buy them. This gives me the vibes ICOs ---> ITOs  ---> STO's  ---> IEOs ---> IDOs, if you get what I mean

That's true. I expect patch would be difficult since there's small possibility you create regular P2MS address with same header.


Good point. I was focusing about blockchain/transaction size and didn't notice it create several UTXO which can't be pruned by Bitcoin Core. Although looking at example data shown on the documentation, it has size more than 80 bytes.

It does create bloat in a much worse way because it is creating non-spendable outputs which would remain in the UTXO set until the end of time! Considering the size of the arbitrary data they maliciously injected into the blockchain in the example used in that link, it is a dumb way too since OP_RETURN allows storing 80 bytes in a standard way while not creating a UTXO set bloat.

Interesting. It seems still a bad and inefficient format, as they continue to use JSON to store the parameters, which wastes precious data for the keys of each dictionary, instead of only encode the values with a library like Protobuf and keep the keys in the protocol definition itself. But yeah, the fact that it requires one transaction per transfer is a little bit better than BRC-20 (which is the worst protocol ever designed).

Still, OP_RETURN protocols without JSON seem more efficient to me. Even CBRC-20, another post-"BRC-20" alternative, seems to do it better (not using JSON but the URN format), even if they still require two transactions for transferring.

So in theory the "holy grail" should be a SCBRC-20 which uses CBRC-20's storage format and SRC-20's multisig approach (Or: simply use one of the old token protocols. )

This looks like this is an even more obfuscating way to store the data, as this way they look like "regular" P2MS transactions. It would become difficult to create "patches" to block this kind of tokens ("the LukeJr way"). It's basically what I feared what would happen if these patches get more popular, and why I think this approach is useless.

I have only read the protocol description superficially (I don't know if it's worth it to dedicate more time to investigate it further) but I fear that this kind of protocol, which includes the data in the parts of the transaction which are normally meant for public keys (like also Doginals does), could make it even more difficult to create ways to ignore these data in the Intial Blockchain Download (maybe @vjudeu can confirm this). However, I believe there's a limit how much data can be crammed with this method in a single transaction, so it's unlikely this will lead to images and other media objects to be stored on-chain.

To other reader, i just found SRC-20 technical specification which can be seen on https://github.com/hydren-crypto/stampchain/blob/main/docs/src20.md. Here are some interesting details,
1. They use MessagePack and Zlib to reduce size of the arbitrary data.
2. Rather than exploit witness data, it seems they exploit public key on P2MS (Pay to Multi Signature) address. It also means they don't need to create 2 transaction for single SRC-20 operation.

If i'm right, that means SRC-20 create less bloat compared with BRC-20. Nevertheless, i still believe they should use sidechain or LN for this kind of thing.


That's true. I mentioned sidechain since i don't like people storing arbitary (which usually have relative low importance) to Bitcoin blockchain, while wishing sidechain could be more popular.

It's like Ordinals but tokenized. What's the big deal? Nobody buys that stuff unless they want to make profit from the next fool who will buy them. No essence to talk about, just as with NFTs.

I'm starting to believe that implementing their idea in the wrong way is what this is all about. Injecting arbitrary data is what we all talk about a year now. Their public condemnation is how they advertise themselves.

Are you referring to ZeroSync?  https://bitcoinmagazine.com/technical/zerosync-reduces-bitcoin-node-validation


If you commit to the data to the chain, you still have to keep the data available somewhere else.  Inscribing the raw content directly on the chain solves the data availability problem (at a huge cost).

Why? Bitcoin is a payment network. In the future, it may be possible to perform Initial Blockchain Download, without getting the exact data, and just by stopping on validating signatures. Pushing more data on-chain, brings us only closer to that scenario.

If people want to commit to the data, they could hide that behind their signatures, without revealing data on-chain (and without even telling anyone, if something is committed or not).

Also note that each time, when a coin is turned into fees, the chain of signatures is "resetted", so the new coinbase transaction can be created out of any fees. Which means, that if you want to check, if the whole system is "honest" (and for example that there are not more than 21 million coins in circulation), then you only have to validate the chain of signatures, to the nearest coinbase transaction. Because then, the coinbase amount can be created from the original fees, or from any other fees, and it will still be valid.

Storing the data somewhere else would be self-defeating since the inscriber's objective is to put the data in the most secure, most widely distributed place (which is the Bitcoin blockchain itself).

Both of them have same data permanency when it's transaction included on Bitcoin blockchain. I think you need to clarify your statement further.


Probably because there are so many standard about token/NFT created, although none of them are part of Bitcoin protocol.


I don't know general consensus, but i believe both protocol should use one of Bitcoin sidechain rather than Bitcoin on-chain.

Because it is not a Bitcoin related topic as it is not part of the Bitcoin protocol.
These are arbitrary names that a centralized platform is giving the junk data they inject into the bitcoin blockchain by exploiting the protocol.

Hello everyone, as far as I understand, SRC-20 is better than BRC-20 regarding data permanency. Why are so less people talking about it? What does the Bitcoin community think of this protocol? If you have more community channels to discuss this I will be thankful if you provide them. Thanks for reading.