question about segregated witness

[Christoph Bergmann]

Hello everyone, I finally motivated myself to get deeper in touch with segregated witness.

As I understand it:
- first you build a tx with an output that looks for older nodes as "anyonecanspent", but for new nodes as "look in the sw to learn how to spend me".
- Since the output is "anyonecanspent" it doesn't need signatures when it is used as an input.
- Since the signature is carried out in the segregated witness, new nodes know this an can validate them
- and as we take the signatures from the block and add the segregated witness as a not officual part of the block the real size of the block can be increased.

Am I right?

I don't completely get it why this is so great.

But i have a question:

If SW is carried as a soft fork, and if not every miners takes it, and only a minority of nodes (which should be given, as only ~25% of the nodes run the newest version of core) - than would it be possible to just grab the "anyonecanspend" with your old node, send this transaction out to other old nodes and make sure it finds a miner with an old node?

 

[sickpig]

@Christoph Bergmann

re SegWit's not so great: the thing is that it has been sold has a scalability solution when actually main advantages are related to other things (malleability, fraud proof, script versioning etc etc). the improvement that somewhat increase storage scalabilty is that it let you prune blocks "partially", I.e. once the txs are validated you could drop the signature (witness data).

re SegWit vulnerable if deployed through soft fork: usually SF triggered when 95% of the hashing power start producing blocks with the new version. from that moment blocks produced by not "old" miners are invalid. So as long as activation threshold is that high the probability if successfully perform what you described above is very very low (not 0 thanks to "SPV" mininers)

 

[Christoph Bergmann]

@sickpig

That was helpful! Thanks a lot!

Another idea: it is said, we can't have 2mb blocks now, because you can code a crazy 2mb-transaction nodes will have to compute 10 minutes.

With Segregated Witness you can have 1mb block + 3 mb witness, if it's full of some kind of special multisig transaction. Will it be able to built an apokalyptic multi-sig-transactions of a size of 4 MB?

 

[sickpig]

@Christoph Bergmann

your attack is valid in theory.

In practice as far as I know a lot of developers are working on a solution for this particular problem (O(n^2) sigops validation, I.e. CVE-2013-2292). This issue is shared by all scaling solutions, in fact scaling means among all increasing the number of txs per sec, hence the number of potential signature validations.

In fact a part of a sigops limitation mechanism has been recently comitted to the ongoing SegWit implementation, see:

https://github.com/sipa/bitcoin/commit/e269d81618f2519c2b36d97f3271a5eaf39eafac

if your interested in a more detailed explanation look at this email by Gavin:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009667.html

 

[Christoph Bergmann]

@sickpig

Thanks again. So with this problem we face the first scaling-bottleneck. Before SegWit can be implemented, we need a solution for this.

I heard XT did implement a solution for it.

Do you know if classic is on a solution?

I heard it was discussed by Unlimited Devs, but I don't know if they come to a conclusion.

 

[sickpig]

@Christoph Bergmann

you're right. XT has a solution for this problem, even in the only-bigblocks branch:

https://github.com/bitcoinxt/bitcoinxt/commit/cc1a7b53629b265e1be6e212d64524f709d27022
https://github.com/bitcoinxt/bitcoinxt/commit/6963ce5c3c464364884e47e111f1077262b68615

since Gavin is contributing to classic I think those changes will be "merged" on BC repo.

re BU and sigops: paging @theZerg

 

[Christoph Bergmann]

@sickpig: Thanks again Youir answers are always helpful.

I now got my head throught Segregated Witness, and I think in terms of scaling it's a bit stupid.
Why?

With allday transactions SW makes it possible to send 1.6-2.0MB with an 1MB block. Ok. But with special multi-sig transactions it does 4 MB. So you have to protect the network against 4MB-Attacks (Spam, huge transactions ...), while just enhancing capacity to 2 MB.

In the future, if we want to increase capacity by blocksize, we always need security for the double amount of the used blocksize. If we expand capacity to 8 MB, we need security for 16MB. And so on.