1) Segwit does not separate signatures from transactions. It shuffles them around slightly, but that's all. (The primary difference is that they are not used in the transaction id calculation.)
Discussion
2) Segwit's block size increase was technically a nice hack to cleanly implement it, and without a hardfork. But it truly did increase the block size limit, and is not any more space-efficient in that regard.
3) Increasing the block size has only limited/reduced access to run Bitcoin full nodes, not ensured it. Node counts have dropped drastically (50%!) since then, and it is clear in retrospect that the block size increase was a huge mistake.
4) The "Bitcoin Independence Day" is only coincidentally related to Segwit. The relevance of it is rejecting control of Bitcoin by miners. Several developers attempted to re-assert miner control over Bitcoin 2 years ago with Taproot (so-called "Speedy Trial"), and it's important to remember what "Bitcoin Independence Day" was all about (and the lessons we supposedly learned) and push back against that to ensure it never happens again.
Thanks for posting on nostr Luke!
I had some threads from you on Twitter in my bookmarks to read later which they don't allow me to read anymore.
Knowing this kind of thing can never happen on nostr is one of the reasons I keep building here.
It can still happen on nostr.
Saving local copies is the only solution for either Twitter, nostr, or anything else
Thank you for the explanation!
In fact, upon further reflection, it's very important to call this out. Bitcoin independence day is about UASF, _NOT_ about segwit. Making it about segwit distracts from the real meaning and we need to ensure UASF mindset remains prevalent in Bitcoin, especially these days.
Was the possibility of doing SegWit without a blocksize increase ever considered?
Yes, it was actually a surprise to me when sipa announced the block size increase addition.
But at the time, we thought it a necessary compromise to appease the (would-become) bcashers
I didn’t know any of this thanks for sharing!
Hard to say without knowing the counter factual, e.g. if SegWit was deployed with no discount and the witness data included in the 1 MB limit.
We don't know what part of that 50℅ was due to slower sync vs. e.g. just more user friendly wallets (that don't use a full node).
Without knowing which of these nodes actually controlled funds vs just astroturfing it's not even clear if the trend is really down.
There's also the UTXO set growth to consider, a problem that takes a bit longer to manifest than block size. SegWit improved the incentive there.
Segwit did improve quite a few things.
That fix doesn't require a block size increase.
Without the discount it would still be cheaper to create a new change output than to spend an existing UTXO.
SegWit was not the only solution proposal for transaction malleability; remember BIP62 with Pieter Wuille’s proposed tweaks to the BIP in July 2014.
SegWit inadvertently prevented covert ASICBoost.
Incentives for UXTO consolidation could exist without SegWit discount; transaction byte size fee payment encourage already UXTO consolidation.
BIP62 is partially implemented, but the remainder is withdrawn. Afaik it wouldn't be enough to be safe for Lightning, but you'd have to ask (Sipa on) the Bitcoin Stack Exchangs.
Fees would be insanely high right now without that Segwit blocksize increase, what are your thoughts on that?