Policy: limit witness stack size

[jl2012]

per input total witness stack size limit <= 73 * sigop + 200

briefly tested

[maaku]

... why?

There are use cases for witnesses that do things other than sigops.

[sipa]

@maaku Can you give an example?

[jl2012]

@maaku that's why I left 200byte free space. Actually, the same policy could be applied to non-segwit tx too

[maaku]

@sipa near-term: multiple HLTC. long-term: two-way peg, lamport signatures, script extensions.

[sipa]

All the long term ones require new script functionality first, so this doesn't apply to them. What is HLTC?

[jl2012]

@sipa Hashed Timelock Contract for LN.

@maaku How many extra bytes are needed for each input? It seems only 20-32 bytes?

And this is only a policy rule, not consensus

[NicolasDorier]

I am not fond of it, it complicate the code for no good reason. Can you explain what this is trying to achieve ?
Why limiting the stack size ?

[ajtowns]

Joseph Poon recently proposed supporting escrow with lightning via revealing 2-of-3 hash preimages. http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html

By my rought count, the untested demo scripts come out to about 190 or 240 bytes I think (depending on whether they're 20B hash values or 32B), with two sig operations (in different OP_IF branches), and there would be an additional 113 or 137 bytes of signature data to spend it, for a total of 303 bytes or 377 bytes. I haven't looked at how nAccurateSigOpCount handles if branches, but the formula works out to 273 bytes if it only counts taken branches which isn't enough for either approach, or 346 bytes if it counts both, which would work okay, though only allows for 160 bit security rather than 256 bit.

I don't see why a limit here in addition to the standard transaction size limit is desirable?