Post
Topic
Board Development & Technical Discussion
Re: (Ordinals) BRC-20 needs to be removed
by
ABCbits
on 01/05/2024, 10:43:47 UTC
Quote from: ABCbits
You talk as if OP_RETURN, segwit and taproot bring no advantage. Should we remind you to few of these facts?
leave "memos" (aka OP_RETURN) to yellow sticky notes on your refrigerator. i wouldn't have it my crypto system.
Yes SegWit did solve the transaction malleability issue and improved signature verification time but i don't have an issue with those bug fixes. i don't think an entirely new address type was needed though. we need to keep things SIMPLE.
I don't find Taproot to be a compelling argument. or necessity.
but thanks for your insights.

But on long term, witness version on Bech32m address format makes it's easier to deploy new feature or technology. Legacy address doesn't offer such thing, where you're forced to "wrap stuff" inside P2SH address which is less simple than using Bech32m. I also forget to mention Taproot upgrade also bring aggregated signature feature which also reduce TX size.

Quote from: vjudeu
2. Why not restrict it to only valid public key coordinates, to have all existing UTXOs always "mathematically spendable"?
This is interesting and I have thought also about a related idea, but can it be proven that a private key exists for a given public key?

My related idea was a kind of "invitation-only" coin: that you have to derive a key always from another key and announce this derivation with a mathematic proof that it is spendable before you can transact value to them (i.e. create a challenge based on that PK). This would allow that only "spendable" keys could be created. But first, I'm unsure about the math, and second, that would not be really an "open", "free" cryptocurrency.

Perhaps also a proof that a public key is spendable is possible without deriving the key from an existing one?

However I believe even that can be used for data storage, but it would already make it more difficult (not necessarily more expensive though).

I also wonder whether it could be exploited as new form of DoS attack to SPV client and full node.