SegWit is the compromise. It increases the block size to 4MB, for no other reason than that people kept asking for it. But it seems nobody actually wants the block size increase after all, and the big-blockers were all full of hot air. No matter. If SegWit fails to gain support in its current form, it can always be re-proposed without the controversial block size increase.
opposite is true...except for blockstream and bitfury and dcg...no one really wants segwit.
Well,
segwit IS a smarter way of writing the transactions on a chain. Technically, bitcoin's transactions are horribly designed, and do a lot of stupid things. Segwit arranges that up to some point. It is a better digital format of the information. If you look at the technical improvements that Segwit brings over the design flaws in the original bitcoin transactions, I think one can only be in favour of the new format.
...
Smarter doesn't always mean better. If the data goes up due to CT, then more storage is needed per transaction.
In what way?Well, I already wrote a few posts about how bitcoin transactions are wasting space *uselessly* and make verification *uselessly* complicated.
I will quickly indicate what is wrong if one wanted to win room, without modifying anything to the principles, apart maybe one.
A) we keep bitcoin's rules exactly as they are:
Aa)
there is no need to publish the public key. The public key can be derived from the signature and the message (ok, very few signatures could fail, in that case, one should have foreseen it, and modify the nonce of the signature, but it is one chance in 10^36 or something if I remember well). That's 256 (and noncompressed, 512) useless bits.
Ab)
the output transaction hash (256 bits) is much, much too long. The number of the output, on 32 bits, (4 billion outputs !!) is too long too. Note that indicating the transaction hash is not really an element of security, it is a way to help find the right output.
But this brings us to what would have been a very good rule in bitcoin:
->
don't allow address re-usage. This could have been in the protocol !
B) if that applies,
then there is not even any need to specify any output transaction hash: 256 + 32 bits won again ! Because there's only one single output in the whole block chain that has this single input address (found by the hash of the public key, found by looking at the signature).
Moreover, forcing single-address usage would improve the cryptographic security somewhat, because the public key would never be exposed before it was useless, and many other things would be better. There would not be any notion of transaction malleability either.
So we would only need a signature as an input. Nothing else. No referred-to previous transaction and transaction output, nor any public key. And the search would be easier (just a single address).
We would win more than half of the room of an input/output pair that way, if we consider compressed keys, and even almost a factor of 3 of the uncompressed case.
