mleku on Nostr: essentially segwit made it possible to stuff large inscriptions on chain where before ...
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.
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.