#segwit is the spawn of satan.

we didn't need it for lightning, lightning already had all the tools required.

it enabled the current spam scamming ordinals and bitmap theory bullshit.

it was underspecified, it gave no limitations on the size of transaction witnesses.

schnorr signatures and a sane nonce-based signature protocol would have fixed malleability better than segwit. literally could have just been an extra 8 bytes with a fixed 64 byte signature.

it would have obsoleted multisig transactions completely

it would make lightning and other layer 2/3 anchoring transactions indistinguishable from others

it would have made coinjoin and payjoin protocols more private and easy to implement.

all of this is of course wishful thinking. we have got taproot now, which can enable most of that, but we have got a huge problem of miner-beneficial spammy transactions that are diminishing the utility of on chain transactions by inflating fees, and increasing the data size requirement of the chain.

when the bull run comes, it's not gonna matter so much, but the halving is still 3-4 months away and at that point the miner driven pumping of scams to fill blocks will start to slow down until next time.

and maybe someone will come up with ways to defeat the scammy shit.

i personally have my eyes on working on changes in the soft consensus of the mempool, changes that will be compelling and lead to a shift in focus away from the chain and more into the live transaction stream.

Reply to this note

Please Login to reply.

Discussion

I thought taproot allowed for all the ordinals bullshit, or am I mistaken?

essentially segwit made it possible to stuff large inscriptions on chain where before segwit there was major limits on this.

you may recall an incident where a massive transaction blocked up btcd and stalled many LND/BTCD based lightning nodes. this was because the segwit spec does not place a limit on witness size, it can literally fill the full 4mb of a block.

it was my opinion at the time of that incident, that it was just the beginning of a flood of garbage scams exploiting this vulnerability, and i've been thoroughly proven correct in the meantime.

i believe it would be possible to essentially soft fork segwit back off but the miners won't stop running segwit support, because full blocks means more fees for them. it only takes a few full nodes supporting it for the transactions to get to the miners and end up in the blocks.

unfortunately, the pandora's box is open.

taproot is allowing us to potentially write wallet/transaction schemes now that are massively compressed compared to prior protocols, anything involving multiparty can now be greatly shrank because only one signature is needed, 64 bytes, whereas before there had to be a signature for each address involved and this also was bad for opsec.

taproot schnorr signatures allow lightning transactions to be smaller also, and to be indistinguishable from normal transactions and for coinjoin and payjoins to also go under the radar. we are just waiting for this to be supported by applications basically, and for nodes to support it.

it's my opinion that someone should go through the old bitcoin core versions and backport taproot onto them, because it doesn't introduce vulnerabilities, unlike segwit, and encourage old node runners to patch to support taproot.

So, segwitless taproot… 🤔

Thanks for the explanation. Much to think about this morning.