and no ordinals junk does not look like a normal tx.. there are obvious signs its different and code can be made to recognise that.
STAMPCHAIN, not Ordinals (Ordinals can sorta be recognized but they can switch to a worse protocol at any time). Please read the proposed protocol. They are creating fake public keys to store data on them. There are no "obvious signs" which public key is true and which is fake. This is actually not a new method, it was used to store data before OP_RETURN was introduced, and it was the reason for OP_RETURN introduction for these protocols not cluttering the UTXO set. Why? Because you can't tell which things are "arbitrary data".
Please understand: as bad as Ordinals and
BRC-20 are, Stampchain and the 2013/14 pre-OP_RETURN token protocols are MUCH worse for scaling and would lead to much more centralization risks.
(hardening up the soft opcodes(now hundreds) that allow data to pass unchecked). require network readiness if someone wants to use an opcode with new format conditions.. (network security) and checking every byte meets a rule(data security)
- Hardening opcodes, if I interpret correctly what you mean, would imo make future softforks impossible.
- Require network readiness would make creative usage of contracts depend on "Core approval". You would actually increase Core's power, not reduce it. This would lead to a never ending war about details and so creative usage of Bitcoin Script (I don't include Ordinals in that, but things like LN) would be discouraged. You may like that but I don't.
- "checking every byte meets a rule": Actually you even propose to "worse" scaling if you want "every byte" to be checked for a "rule" or "purpose", because that would increase resource usage of validating full nodes. And: How to check for that purpose? For example, if you want each public key to be check if it really corresponds to an existing address, you would forbid to create new addresses, to create a lock-in and a privacy nightmare.
d5000 for someone like you thats been around long enough to have had the time to learn enough, you yet again show you dont know enough, by contradicting yourself and by then saying obsurd notions
first of all i have been talking about the funky junk being able to be added if segwit activated since core proposed segwit back in 2016.. creating new soft(open/un-format required)opcodes that were treated as valid without checking data after opcode.. since 2016..
so no its not about taproot.. i never mentioned EVER taproot starting it all, taproot is just the prime example/demo/effect/result of the previous exploit softening has caused since 2017, where years later taproot is the result/example.. not cause
secondly. stampchain. is not complicated. its just multisig of EG 1of2 where it needs one signer key and the other key is junk data
(funny part is i think it was me that gave them the idea in early ordinals days, to use multisig instead of witness metadata/op_returns)
op_return and stampchain does not create 4mb of memes..
op return is limited to 80 bytes and stamps have 20byte thus leaner then the meme junk
and the great thing about code. code can create rules.. as thats the beauty of it
code to limit arbitrary data to keep bitcoin clean for its main intended purpose.. a purpose you seem to have forgot
(and no dont reply that you think bitcoin should be free to become a junk data library/comic book store of images)
i think you really dont understand why bitcoin was such a great solution to digital money concepts of the early years..
i know you want arbitrary junk data as it makes bitcoin annoying and helps you to promote other networks people should use to get away from the annoyances.. but how about you stop promoting other networks and start to think of what is best for bitcoin.. via fixes to the annoyances. rather then wanting the annoyances to continue just to promote user exits as the only solution you could find
hardening the rules again actually means core devs cant just supplant new stuff which then by default require people to rush into using core as sole reference updated code to stay fairly 'fully' again after they change things.. thus keeping them on power
it stops core from being so lax. instead hardening the rules would require core to be scrutinised more pre feature operation, to then have the community then see there is nothing that could go wrong before core do anything.. as it should be
and it then also requires core to hope what they make meets the standards/benefits the community see as a good thing/to see its merits..
meaning core have to actually explain things and show things rather then throw things in and see what sticks
which another brand could then also publish its own proposals and community can check its merits too and there wont be a REKT campaign fear of 'dont use software as its trojan.." of sily fear campaigns. but instead actual fair adoption due to the activation not happening pre majority thus safe to start allowing different nodes onto the network with different feature offering/proposals with no threat level of any brand instantly changing stuff
as for your willingness to not want core to have network readiness as you think it will hinder cores innovativeness/creativity .. well maybe that will kick them up the ass to motivate them to actually make something network benefit worthy, rather than things sponsorship worth
but i do gotta laugh how you dont want nodes checking everything but then try to refer to nodes not checking everything as "full"
pure comedy
) are to be traded for currencies instead of being traded for goods and services. There is no "rooting" of the Bitcoin price in the real economy. People don't know how much it "has to be worth".
