Topic: (Ordinals) BRC-20 needs to be removed - page 4. (Read 7773 times)

The scam market where these junks are being pumped and dumped and the people's greed thinking they can make a lot of money buying garbage advertised it not what people say about it on the internet. In fact I can bet that majority of those newbies who have been buying these don't even read what we're saying about them.

but clearly you believe that banning ordinals would result in a mad rush on using something like bitcoin stamps that's very clear from how you've been talking here.  

you do realize that these people storing data using ordinals are getting a 75% discount on their fees. i disagree with that. if they were paying the full fee that might be different. but even then, obviously it is nice if you limit how much data can be stored per transaction. there's a precedent for doing that you know...

I was careful with my wording. I said incentivize, not force. Besides, are you banning something with the mindset that its supporters won't attempt to bypass your measures? What would be your excuse if they move to UTXO set? "Yo, we banned that tapscript type to stop Ordinals, but it didn't work out, our bad".

If the manner in which they use that OP code is none of our business, then the manner in which they've designed to store trash in the chain is neither our business.

Everyone is still debating whether it should or shouldn't be "banned"? It's too late in my opinion.

Personally, and as everyone has already noticed from my posting history about Ordinals, BRC-20, and Runes, I am agnostic about them and/or what's being built with them. But for those Bitcoiners who continue talking about it because they hate it, I believe they should study the Streisand Effect. Those people actually did all the "marketing" that Ordinals needed to bootstrap the project. If they ignored it, then everyone would have ignored it/it wouldn't have a lot of attention.

i just don't buy your argument that if ordinals were "banned", that would force people to use bitcoin stamps (or something like it) which stores things in the utxo set. that's just a big assumption. i think what you would find is most people would not do it. but those that did should be welcomed with open arms.

https://en.bitcoin.it/wiki/OP_CHECKMULTISIG

and it should be none of our business, what they are using that op code for.



it was just an idea. that's all.  

I think he's talking about SRC-20. Check this technical documentation, https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md.


If Ordinals is banned, those people would use Rune first rather than resorting to UTXO/fake address.

Define "bitcoin stamps". It is completely valid to spend from a 15-of-15 multi-sig.

I still don't understand the point you're making. There is no justification to ban something if it can't be an attack vector for the network, therefore banning Ordinals the way they work, so they switch to being stored at the UTXO, is an unreasonable statement to make.

My friend, you really don't find anything flawed with this? 

It depends, which software you use, and how do you configure it. If you spin 10k independent nodes, each in a separate directory, using Bitcoin Core, then it is hard. But if you only download everything once or twice, and everything else will be related just to some proxies, used to redirect the traffic properly, then it requires not much more effort, than running a single node. In that case, you can have one or two full nodes, and a lot of SPV-like nodes, which are connected into that, and just create a lot of traffic out of thin air, if you can allocate many IPs.

Because note one important thing: nodes validate data, because then they know, if something is correct or not. But if your one or two nodes already know, that transaction X is correct, then 9998 other nodes don't have to repeat that computation. They are all owned by a single entity, so they can trust each other.

1. This is called Proof of Stake, and has its own problems.
2. You have to find a way to distribute that "small reward" efficiently, without creating additional outputs (just like transaction fees are distributed).

There are bigger problems: a single input would then have thousands of signatures, unless you will join them somehow. Or: a single node can easily pretend, that 10 nodes validated something, because there are valid signatures for 10 different public keys.

This makes no sense. Every node has to validate every transaction. If a node earns money from signing, miners will sign everything by themselves and take the money.

well yeah obviously, there's got to be some limits but no one is doing larger than M=N=15 most likely and i doubt people even do anything that big. But there might be 5 of 7 but i think bitcoin stamps only does 2 of 3. so there's not going to be any justification for saying that 2 of 3 multisig transactions even the ones from bitcoin stamps are not welcome on the bitcoin network.  

if actual work is required of a node to validate and process a transaction in some way then i don't think it would be feasible to spin up 10,000 nodes.


for example, say you changed bitcoin transaction format so that there had to be an extra second signature on top of the first signature. the second signature would be from a node that validated the first signature. the node that did the validation would get a small reward if the transaction they signed and validated made it into a block.

if a node didn't want to participate in the signing process they could just broadcast it out to other nodes and let them sign it. so it could be like an opt-in system for nodes who are looking to pick up a small amount of spare cash. 

Mining pool, block explorer, some exchange and service (which offer API to obtain data from blockchain) need to run full node to keep their business running. So scenario you mention is unlikely to happen, unless Bitcoin itself no longer attractive or useful.


Or worse, one or few full node that use multiple IP address/port. See https://reddit.com/r/bitcoinxt/comments/3iao3i/how_to_run_3000_completely_legit_full_nodes_aka/.

We'd get millions of virtual nodes created by the same person to get a larger piece of the pie, and nodes will become as centralized as mining pools are now.

OK, I see. It's still a little unclear, though. If a transaction takes a long time to verify, then it can act as an attack vector. Disabling it is more of an argument in favor of robustness. Multi-sig transactions are allowed, but with M, N limits. For example, AFAIK, you can't spend from a 1000-of-1000 multi-sig.

The work is done by miners, and the pie is split on that work. If you think running a node helps on bandwidth and needs a piece of the pie, then what happens if you spin up 10,000 nodes?

Then you can no longer validate a block that includes one of the pruned UTXOs. That's why I don't think UTXO pruning will ever be a thing. If they're unlikely to be used, they don't need to be in RAM. But in the unlikely case you need one anyway, it's nice if you still have it on disk.
For normal nodes it's 2% of the total blockchain. But I can see a problem for pruned nodes: the UTXO ("chainstate") is already 20 times larger than the blocks stored in the smallest possible pruned node.

You're the epitome of FYIGM.

When you hodl BTC, it's in your best interest to not let it die and give something back (even if it's just a node/blockchain explorer).

ps: That's why the best torrent trackers are private and strictly enforce a 1:1 ratio. So yes, you can tack on such a feature later on, although it would have been much better if game theory was built-in (like PoW does).

For me it's not a big deal... if you generally leave your computer 24/7/365 online, it doesn't hurt to seed a bit more. It's not like I consume more electricity (that's why ASICs are a deal-breaker for regular home usage, unlike RPi nodes).

because you merited this posting. so took that to mean you don't agree with bitcoin multisig being used as the underlying mechanism for bitcoin stamps. if there is some issue about bitcoin multisig then that's the developers fault not people trying to use the feature however they want to. that's kind of my opinion.




which is why once i downloaded some torrent, i immediately shut down the torrent software because i got what i wanted. why am i going to sit there being a server to other people downloading it? i know that's a bad attitude to have but that's the way alot of people are. probably why most torrents eventually dry up and no seeders are left. that could happen to bitcoin too possibly unless people see some kind of benefit from serving up the blockchain to other people for free...

I guess torrent seeding is considered "slavery" too, since there's no monetary benefit...

People forget that back in 2009 nodes & miners were the same thing (due to CPU mining), even though they are decoupled today, because ASICs are quite expensive.

But... It doesn't matter already. What makes you think it does matter?

Ordinals can be moved to the UTXO set. Take an Ordinal, split it in an array of 256 bits, convert these bits to addresses respectively, send 0 sat to each address. You just created another representation of the same ordinal.

Storing and sending/receiving blocks and transactions are not done "for free". This is the only way to be certain that your ledger is intact, pure, true. And it's not that it costs a thousand dollars to do it. You just need a decent Internet connection, any modern computer and a terabyte.

Exactly.

1. Usually, full nodes can see new blocks faster, than they appear on block explorers (because other nodes have a reason to connect to them, and to tell them that information before, and get some other data in exchange). For example: you can see some block in your node, and then, 15 or 30 seconds later, it will appear on mempool.space.
2. Full nodes receive and send transactions all the time. Which means, the whole traffic is not related only to their own transactions, but to the whole flow of new transactions in mempools.
3. People can connect and disconnect at will. As well as switch their mode into pruned, archival, or change their settings. For example: you can allow any fee, and then see the traffic below 1 sat/vB.
4. Full nodes can observe all kind of weird behaviour, related to the network, for example violating sigops limit: https://bitcointalksearch.org/topic/error-connectblock-too-many-sigops-invalidchainfound-invalid-block-5447129
5. If you have a full archival node, then you can observe the chain, without telling block explorers, which transactions are you interested in (and which of them are potentially related to your own payments).

So, it is not a slavery. But: if you verify the whole chain once, then you have all of that data. And there are incentives, to run just some pruned node (and not pay for example for renting additional disks in VPS), instead of running a full, archival node. And that makes it harder to create new nodes, because then you have less peers to get blocks from.

So, if people will abuse the chain by pushing a lot of data, not related to transactions, or even deploy some altcoins on Bitcoin, or do some other weird things, then guess what: some full node operators can decide to just use pruning, and not to care about new nodes. What then? How people would access their Ordinals, if there would be not enough nodes to fetch that data from?

And the same is true for the UTXO set: if it will be abused, then running a node may require also pruning some parts of the UTXO set, and replacing it with some weaker proofs. What then?

But in this instance we're not talking about electricity, but the tradeoff between efficiency of verification and not needing to rely on trust.  That's one of the key pillars it's all built upon.  Something we must never lose sight of.  We accept inefficiency because it means we don't have to trust.  



It can't be slavery if people are offering to do it and have the option to stop at any time.  And people aren't doing it because they expect a monetary reward.  It's again about not needing to rely on trust.  The people running nodes benefit from that.  It's their primary incentive.  SPV users don't gain that benefit.