a little tl;dr on taproot, segwit and ordinals

taproot is a type of HD key scheme where you have the parent key and then a "tweak" value.

a simple taproot key can have no tweak, and its derived private key is the hash of the original private key, and the public key is derived from that.

a taproot key with a tweak is where you concatenate the private key with an arbitrary string of bytes, in a similar way as a HD key derivation, but of course it can be anything, even the binary bytes of a compiled ethereum solidity script.

it is not material to bitcoin what you used in the tweak, it does not interpret it.

it is not material to bitcoin that there is any tweak at all, this is all inside the key generation and derivation process.

it took me a while to wrap my head around it, because in the code it seems like all this derivation is important, but it is not.

the receiver must have the private key and the "tweak" values in order to spend the received sats.

the derived private key that generated the address is not normally stored in the algorithms, but it could be.

TAPROOT IS JUST A SCHNORR SIGNATURE BASED KEY.

segwit, on the other hand, the cryptography of it is not so important to how it works as the fact that it allows you to make transactions with extremely large amounts of arbitrary data, after opcodes like OP_RETURN.

until 2021, nobody really seriously exploited this for anything much larger than about 20kb. then someone dumped a transaction using segwit with over 30kb of data in it, some 999 signatures or something, and lightning was broken temporarily because BTCD code had put a limit, that is not specified in the segwit BIP, as a protection against resource exhaustion attacks.

then the light dawned to the shitcoiner community that they could drive up bitcoain fees and clog the chain by publishing huge transactions, so tehy cooked up scamms like Ordinals, to make their justification for making transactions with ginormous amounts of data in them, and the miners of course were ok with this because during the bear markets tx volumes are thinner and the block rewards are thus lower.

shitcoiners and miners are who benefit from segwit.

segwit was not essential for Lightning. it just made it a bit more secure.

at the time, Schnorr signatures were an option that was discussed, but it was rejected.

this was the wrong decision, obviously.

i don't know how bitcoin is going to recover from the spamfest that ordinals created, but please....

it's not taproot that enabled ordinals, it was segwit.

Reply to this note

Please Login to reply.

Discussion

we need a better narrative as plebs

many of these statements are factually incorrect

i'm waiting for your elaboration.

A few statements to clarify...

The spender of a tweaked public key is the original private key and the tweak. The commitment for the tweak can be revealed without revealing the private key.

Segwit when implemented did have a practical limit on the number of op codes for standard transactions due to script signature limits.

Per BIP342, taproot maximum script size of 10000 bytes does not apply, and thus only bound by block size.

It was October 2022 that the btcd issue caused lnd nodes to fail when Burak broadcast a 998 of 999 taproot transaction.

Ordinal theory for the modern Bitcoin era began sometime in mid 2022, well before the taproot transaction on mainnet, and doesnt require segwit or taproot. It wasn't the first numbering scheme, but will likely be the dominant one henceforth.

The first Inscription, applying ordinal theory, and leveraging Taproot was in December 2022, with the protocol formally launched in January 2023 by Casey Rodarmor.

A change that was made at the time of Segwit that supported Lightning was the fix for the malleability bug. Lightning network needed Segwit to support its smart contracts.

If one's goal was to drive up fees for transactions, there's far more grief attacks that could be performed, such as bitcoin stamps, and creating non spendable outputs. Shitcoiners are incentivized to drive down their creation costs, to allow creating more per sat.

i'm not surprised, considering how complicated the taproot key derivation scheme is that there was more unrelated things brought in with it.

but considering only like 15% of nodes are running taproot code, can you explain how the rest of them are still processing these bloated transactions?

anyhow, this is my last post here, i'm burning my keys. the removal of attribution on NIPs yesterday without proper process is a way of saying, without saying, that NOSTR is just yet another psyop like facebook.