search

sipa / bitcoin

Bitcoin integration/staging tree
http://www.bitcoin.org
MIT License
88 stars 21 forks source link

Policy: limit witness stack size #52

Closed jl2012 closed 8 years ago

jl2012 commented 8 years ago

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

briefly tested

maaku commented 8 years ago

... why?

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

sipa commented 8 years ago

@maaku Can you give an example?

jl2012 commented 8 years ago

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

maaku commented 8 years ago

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

sipa commented 8 years ago

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

jl2012 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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?