From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.
pieter keep up the great work! we're on your side.
don't worry about the lies, manipulation and misinformation, we're on it. we got it covered.
jl777 joined the dark side, and for all intents and purposes should be considered a troll with agenda.
don't feed the trolls
dark side? I am asking questions I need answered to be able to implement things. The more I find out about segwit, the more it appears to be a LOT of work needed that can be avoided just with a 2MB hardfork. And compared to a 2MB hardfork segwit wastes space as far as I know at this moment and I await to be corrected.
FYI I am on no side other than the side of truth. The other side has politicized the RBF and claims it is the devil's spawn. I keep saying the reason RBF breaks zeroconf is that zeroconf is totally broken when the blocks are full. So adding RBF still leaves zeroconf broken when the blocks are full.
Now, one difference is that the other side doesnt start calling me a troll when I point out that their technical analysis is incorrect.
my agenda is to implement a scalable onchain bitcoin. If I see something that doesnt make sense, I will ask about it. If I get nonsense answers, I will point that out.
If using logic and asking pointed questions makes me a troll, then I guess I am a troll. Convince me with the math, then I will be segwit's strongest advocate. It the math doesnt add up, I will call it what it is