Topic: On Ordinals: Where do you stand? - page 38. (Read 9235 times)

get a dictionary then
"not lacking or omitting anything; complete."

if a node is not storing the full blockchain. its not FULL
if a node is not fully verifying all of the data it receives its not FULL
if its not offering the full services available its not FULL

its common sense. stuff you can learn by actually understanding what FULL means in any scenario/product/service aka real life

heck go to a masseuse and ask for a full body massage.
if they only rub your toe.. that is not a full body massage

You are just giving your personal interpretation of "Full Nodes".

Satoshi didn't invent Bitcoin to see what it turns into in the future and say "what the heck, it turned into a cloud storage that died afterwards". We also didn't adopt bitcoin thinking it can turn into a shitcoin by letting people who don't even run full nodes themselves upload garbage to other people's computers!

seems the propaganda machine is on full tilt

"censor the network"
sorry idiots but the network is made of rules. it pretend people from throwing in:
already spent UTXO transactions
other network tx formats such as litecoin, ethereum, blah blah blah
random data of no format at all
coin spends more then source utxo had
transactions that try to include 20trillion btc
transactions that.. [insert a billion possibilities]
it DID used to stop putting stupid memes in

sliding in a new format without majority readiness(soft) is a risky thing to play with
then saying "we cant remove, undo, stop it due to politics" is another risk

we actually can stop data thats not deemed as bitcoin payment data. without a re-org, without affecting existing immutable blocks. by just making a certain format conform to its promise of "one signature length" and thus no more future bloat memes

IMO NFTs suck. They're useless garbage that people are pumping to save high price sales in their history and cheat others. A great example of useless crap is Jack's first tweet.
That said, we can't stop ordinals because we'd have to censor the network, make it more centralized. Ultimately people decide what they want bitcoin to be and if the majority wants to upload their stuff to the network, that's what's going to happen. Trying to stop them would be worse. We don't need another drama like the one Roger Ver was inciting in 2018.

then if you are worried about bandwidth. there are features to change how many peers you connect to (adjust bandwidth usage). and lots of other features too..  but accept that you by changing settings are reducing the services your node offers. meaning that the "full" aspect is reduced.. (pretty common sense really)
and the more features you switch off, which affect the availability of peer- 2 peer networking of certain things. the less you are a full node

nothing wrong with wanting to use the software just for personal use with certain things switched off. but just accept thats what you chose to do and not be pretending you remain a full node

EG if you choose headers only. then you are a lite node
nothing wrong with it. but just know that your not then part of the network security structure and simply just a network user

there is reasons why nodes announce their 'service bits'

that was the intention is to share and give out for free but you can only do that for so long until they eat up your bandwidth. seems to me that at some point bitcoin is going to need some fee mechanism to compensate people that share that data. 

understand the word FULL
then understand when you turn off services you are less than full

its that simple.

oh and you do realise that the whole point of blockchains is about a distributed ledger, a decentralised network. a peer to peer network.. all meaning sharing and giving out data to others

its that simple

you are confusing yourself with a centralised closed system.. which is not what the bitcoin network is about.

Being a full node has never been about "supplying" the data to others, it has always been about fully verifying everything for yourself. Although since the P2P protocol is a two way street they do also provide the fully verified data to others.

maybe full nodes need some type of financial incentive to serve data. miners require one for their services. 

nodes that prune are declared as fool nodes not full nodes
because the full blockchain data and verification system are for full nodes. emphasis on the full

other nodes that switch off services like archiving full data and ignoring certain tx formats by just saying they are valid(unchecked) thus not going to cause a block rejection if included, are the fool nodes

there is no point having this bypass system yet again, where a true full node has to keep the data so that it can seed it to leachers
where the "ignore" / bypass is just for individuals fool node to decide about putting their node into limp/fool mode of not being part of the network security(of decentralising the full data set and supplying full verified data to others) and instead used just for that persons own individual wallet features

..
in short. it still ends up true full nodes dont ignore op return and still maintain and contain it

Of course this is only one possible solution to the "data spam" problem, there may be many others. I'd only thought a bit about this and technically it should be possible, and it was funny that the Wired article proposed that too.

According to recent discussions about Ordinals in the bitcoin-dev mailing list, there seems to be some support to make OP_RETURN more attractive to discourage the "misuse" of the Taproot data storage features. So it is possible such a BIP could get support.

The "make OP_RETURN completely ignorable" feature would not need any centralized elements. Not even a hypothetical "notify and take down" system would need that, although of course those who do the "notifications" need to be trusted from the full node operators.

Why? I guess node operators located in countries with strict legislation on illegal content, fearing legal action, would like to use that.

It would be a protocol change, because currently OP_RETURN messages cannot (afaik) be completely ignored, they can only be pruned once validation of the block where they're located has been done. So it would need a BIP. Bitcoin Core as the reference implementation would be the first to have to support it. (Don't really get what you mean here.)

Somebody who can expect enormous profits shorting the price down can afford that, even if he had to pay 100 times the Taproot fee.

---

By the way, there seem to be currently significantly less inscriptions than last week. However, the average size has risen a bit, so the impact on block size (while smaller than before) is still quite high.

^
the guy that says he wants to resist censorship is the one that is trying every tactic possible to do censoring

doomad learn about consensus. its where rules are agreed to before changing. not where rules are made and people then have to accept blindly be be left out

YOUR MAIN MISSION is censorship
telling people to shut up and go away.

you slogan of if you dont like the new rules slid in without consent f**k off.. is censorship to the extreme

You sound like the bigots who moan about people being intolerant of intolerance.   

You can resist what you like, but if you want to be a part of this network, then you agree to all our inefficiency.

Go censor yourself if you don't like it.  It's your call.

You can make BIP first, but Bitcoin Core or other full node software doesn't have to implement such feature.


I don't know about NXT, but centralized cryptocurrency might have such feature.


I understand your explanation. But full node operator is unlikely to use such feature and feature specific for Bitcoin Core doesn't need BIP.


That's possible, but don't forget it's more expensive since they doesn't get witness "discount".

sounds like maybe just a config file setting needs to be changed from 4,000,000 to 80   the more nodes that changed that setting the harder it would be for people to upload their nfts I would imagine.

maybe i don't understand how that works. i guess it does depend on miners but miners depend on other nodes to get transactions to fill up their blocks. if those nodes didn't send them transactions that had witnesses larger than 80 bytes, people trying to upload nfts wouldn't be getting many images minted. so it seems to me, this is something each individual node can do if they want to. to make it harder for people to upload nfts. you vote by making that configuration file change. it has to start from the bottom. people runnig nodes have to raise their hand and say "no more". they have the power to do it too. each individual node.

now in all reality, maybe it's more than just a one-liner config file change but if someone posted a "how to" on how to make that change then that's how change can happen. until then nothing happens since the devs seem to don't care as franky pointed out. 

though the fixes are very simple and could have been implemented already,
a rule that allows upto 4mb does not break if rule is changed to upto 80 bytes. becasue 80bytes is still under 4mb. thus no harm to existing node version. it just requires mining pools to consent by consensus to unite and agree to follow the new rule when they make their block templates and only fill them with the new lean rule

and it can be activated at a certain blockheight using the same precedence method they implemented in 2017

devs are avoiding making decisions because if they do so over the next couple years it shows that core "owns" bitcoin(admitting they are the centralised point of failure/decision makers of the masses) and can change code. (they want to play dumb and act like janitors not developers) . its funny how they take the glory in some places and then shy away from responsibility in others by saying it was user caused or miner caused.. (asics dont write code)
(average joe that just downloads software dont write code) bitcoin core devs write the code that allow things to happen.. which then allow others to use the bugs added, to be abused

they want to demote themselves down to janitor instead of developer status because they are getting sued right now to try to change code to the whims of a scammer. so they dont want to be seen as having the ability to change code easily, else they cant then use the defence to prevent altering the code if the scammer wins

i don't follow the bitcoin mailing list religiously but can we assume that this is an active topic of discussion among the devs about how to fix this ordinals or did they just decide they don't care?

there is a big difference between censorship resistance which some are abusing the buzzword to imply let any data be stored. pretending thats how the network always was
vs
decentralised consensus which a diverse distributed peers agreeing to a list of rules they all approve of and verify data against

which this decentralised consensus has been softened to not be a set of strict rules, by instead allowing stupid data to be accepted "asvalid" without verification or ruleset of whatever is inside the data of that trojan horse opcode

well the original point of bitcoin censorship resistance is so people have the freedom to be able to transact (send money) without a 3rd party's approval. 3rd parties are bad. now what unfortunately happened is the bitcoin rules weren't tight enough and they let in a little loophole that allows people to store data too in the same censorship resistant manner. who's fault is that? well of course its the devs! unless of course, that is what they intended all along but that's doubtful...

taproot really screwed things up didn't it franky?  i knew something like this was going to end up happening the more they threw in extra features for bitcoin, something like this was bound to happen. why i always say, do your initial specification, stick to that. don't add extra stuff. just keep it simple. but they couldn't leave well enough alone and this is the end result. bugs to fix, holes to patch...

heres another mind fart to think about

censorship is resistance of something.
resisting resistance..

how do you resist resistance if your not ultimately resisting.

by saying that there should be no rules to limit data. is then censoring those that want efficiency and rules

enjoy the conundrum

..
but with that said. bitcoin is not a censorship resistance network. its a consensus network that relies on consent of the masses to avoid control by the few... until consensus was softened and now there are the few that do control the masses and the few want the masses to not have consent to resist the few