#bitcoin-wizards

/

      • Dizzle has quit
      • Dizzle joined the channel
      • Dizzle has quit
      • MaxSan has quit
      • luke-jr
        sipa: confusing >_<
      • sipa: any reason not to be consistent and drop the toward-block-sigop-limit too?
      • sipa
        luke-jr: dropping limits scares me, but there's no reason to not consider it
      • luke-jr
        sipa: well, I'd probably leave it, except it's already dropping it for signature-embedded scripts and tail-call scripts anyway..
      • sipa
        why would you drop it for those?
      • luke-jr
        not practical, since they break static analysis
      • you'd need to count them at execution
      • sipa
        i think you either need a way to count them at execution, or not do it then
      • luke-jr
        maaku was arguing that sigops are now so cheap that the weight limit is sufficient
      • gmaxwell
        only if you can't do 2DUP 2DUP 2DUP 2DUP CHECKSIG CHECKSIG CHECKSIG ...
      • luke-jr
        otoh, the possibility of recursive CHECKSIGs may change that :x
      • hrm
      • gmaxwell
        I think the seperate limit can go away, but you can't stop counting. you need to compute a weight equivilent checksig count or whatnot.
      • luke-jr
        gmaxwell: what need is there to count, if you don't limit it?
      • or you mean add it to the weight? (effectively decreasing block sizes?)
      • gmaxwell
        It's not reasonable to ignore it completely, weight is not sufficient if you can just do the example I just gave, where each operation costs 2 weight.
      • luke-jr
        hmm
      • gmaxwell
        weight needs to only be one dimensional linear on a whole block basis, within a single transaction you can do things like:
      • tx_weight = max(size + stripped_size*3, sigops * constant)
      • luke-jr
        I suspect counting at execution will be painful. :<
      • gmaxwell
        so that ordinary transactions work like now, but sigops abusers get a higher effective weight.
      • It sure shouldn't be. The execution already has to be exactly specified for other reasons. e.g. you need to precisely specify which gets executed so you terminate on invalidity in a consensus consistent way.
      • jb55 joined the channel
      • luke-jr
        well, I need to be absolutely sure the end count comes out the same as the static method
      • sipa
        not if it's the only method
      • luke-jr
        the current consensus rules use the static method
      • sipa
        the current consensus rules don't apply to v1 scripts
      • luke-jr
        right, I was thinking of refactoring sigops everywhere
      • I guess that's unnecessary
      • gmaxwell
        The next question though is it better to do that non-linearity per transaction or per input. Per input would be better for reasoning about fees if inputs are independanly computed.
      • dnaleor has quit
      • maaku
        luke-jr: I think you shouldn't add anything new except for the prefixed script version in witness
      • the only other thing you should do is cut things out, like unnecessary limits
      • (which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
      • gmaxwell: 2DUP 2DUP ... CHECKSIG CHECKSIG ... doesn't do much thanks to the signature cache.
      • gmaxwell
        then you've just made specific caching behavior consensus critcial... and there are similarly short sequences that can't be cached (or at least there are if the opcode set isn't absurdly limited)
      • maaku
        it's not consensus critical, just critical to performance guarantees
      • rusty joined the channel
      • gmaxwell
        it's consensus critical because if you don't implement it you will potentially verify slowly enough that you'll end up on a seperate chain in the presence of it.
      • performance can be consensus critical, that fact that it doesn't form a black and white boundary doesn't make that not the case.
      • maaku
        go benchmark secp256k1 and see how long it will take you to verify a block chock full of CHECKSIGs
      • sipa
        around a minute, on reasonable hardware
      • maaku
        sipa: and that's a single core, I presume, based on my own checks
      • gmaxwell
        two million checksigs are about two minutes, on a fastish i7, verified sequentially.
      • sipa
        maaku: no, quadcore
      • gmaxwell
        and that is more than enough to split the network.
      • maaku
        if that's not acceptable, then limit an input to no more than witness_size / 64 checksigs.
      • now you've reduced it to seconds
      • gmaxwell
        Thats what it appears that you were arguing against above. :)
      • maaku
        > 01:37 < maaku> (which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
      • per-input, not per-block
      • it doesn't enter into transaction selection that way.
      • gmaxwell
        maaku: you should read the backscroll.
      • maaku
        I don
      • I don't see myself saying anything different
      • gmaxwell
        You're repeating what I said above, before you started talking but it sounds like you're disagreeing.
      • sipa
        luke-jr: i don't understand why a separate witness for code would be needed
      • luke-jr: bip114 does not need it
      • gmaxwell, maaku: this discussion is too meta for me to follow
      • please, repeat the statement you saw someone make you agree or disagree with - i think it would help everyone
      • Ylbam has quit
      • Dizzle joined the channel
      • Belkaar has quit
      • Belkaar joined the channel
      • Belkaar has quit
      • Belkaar joined the channel
      • dabura667 joined the channel
      • jb55 joined the channel
      • dnaleor joined the channel
      • dnaleor has quit
      • dnaleor joined the channel
      • jb55 joined the channel
      • maaku
        I'm not sure. I don't think it's relevant. I think we should drop limits where we can and where the worst you can do with them is comparable to what can be accomplished by other means.
      • That means ideally just the size/weight limit, and everything else is naturally limited because we've eliminated anything with greater than linear cost, and the max block weight is picked from the worst thing you can do, extrapolated to fill the block.
      • In this case that means making signature caches a requirement for low latency validation, and maybe some other tweaks, or if that can't be accomplished then have a per-input limit instead of a global one, so transaction selection still deals with a linear metric.
      • Obviously we can't change existing global limits, but at least don't make it worse by continuing to count towards them in new-style scripts.
      • sipa
        thanks, now i understand what you're talking about :)
      • c0rw1n_ has quit
      • c0rw1n_ joined the channel
      • dnaleor has quit
      • luke-jr
        I'm liking the idea of requiring all executable stuff be directly in the witness stack, and having a tag at the start of each element for number of times executed..
      • does that work for all use cases?
      • (this preserves static analysis)
      • sipa
        why would the number of times executed be above 1?
      • gmaxwell
        maaku: but then you end up with patterns like DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR... CHECKSIG CHECKSIG CHECKSIG being phenominal blowups it worst case cost.
      • luke-jr
        sipa: using the same condition script for multiple signatures, for example
      • sipa
        luke-jr: it's either valid or not, no need to evaluate it more than once
      • gmaxwell
        e.g. that has checksig costs about 20 times higher per weight than sane usage, which effectively translates into limits that need to be lower (perhaps under some arguments 20x lower)
      • sipa
        luke-jr: i haven't read about the condition script - it sounds a bit like signature delegatio
      • luke-jr
        sipa: hm, that might be worth giving up the stack copy to guarantee..
      • sipa
        stack copy?
      • luke-jr
        sipa: yes, the signature is currently appended with a script, which is executed with a copy of the current stack
      • dnaleor joined the channel
      • sipa
        luke-jr: giving it a separate stack sounds safer
      • luke-jr
        I haven't thought through if there are any use cases for the stack copy
      • sipa
        or rather, a separate initial stack
      • luke-jr
        but separate stack and cache the answer sounds like a good idea
      • right
      • especially since the condition scripts are most likely to be used for things like CHECKBLOCKATHEIGHT, which are likely to be reused for all sigs
      • sipa
        it sounds a bit premature to include that in a proposal right now, though
      • luke-jr
        it's a pretty annoying thing to have missing in Segwit IMO
      • gmaxwell
        ugh, please. don't propose things inside script that aren't pure functions of the transactions; thats recreating the ethereum non-scalablity disaster.
      • luke-jr
        gmaxwell: ?
      • gmaxwell
        that was a comment to CHECKBLOCKATHEIGHT
      • luke-jr
        we don't have any place to put it outside script..?
      • gmaxwell
        if the validity of a transactions scripts aren't a pure function of the transaction you must reevaluate the scripts every time something changes that could invalidate them, which means you either need tracing execution that extracts the invarients, or no caching at all or...
      • luke-jr
        or cache the additional condition
      • gmaxwell
        So? Life is hard. The fact that it's currently the only way you have to do it doesn't makes it acceptable.
      • Script's purity is a long standing design invarient that we reconized as important, a view which has only been confirmed by the total mess in ethereum.
      • luke-jr
        I don't see why this should be unacceptable. It's more or less the same thing as SigAgg?
      • sipa
        sigagg validity only depends on the txn
      • not on the context in which it is evaluated
      • luke-jr
        sipa: implement CHECKBLOCKATHEIGHT as "always NOP, but log a condition for the transaction to be valid"
      • this way, it's effectively the same as the locktime field
      • gmaxwell
        (the other problem with CHECKBLOCKATHEIGHT is that it causes all outputs of the transaction to be non-equally fungible due to their destruction in reorg, so they need maturity like coinbases)
      • luke-jr
        except you don't need to store it redundantly
      • sipa
        luke-jr: right, so make it actual work like locktime, not as a script feature
      • luke-jr
        sipa: that's insanely more complex, for negative value..
      • (now your transaction needs to specify the information twice, and it doesn't improve anything)
      • sipa
        i don't understand
      • for example, allow a particular witness stack element to encode an extra condition
      • which does not require scriot execution to detect
      • and signatures automatically commit to it
      • as if it were part of the txin
      • luke-jr
        and then in the script, you still need a CLTV-equivalent with a copy of the data, to make sure it's in there..?
      • hmm, I guess that's redundant with the CHECKSIG
      • provided there is a CHECKSIG in the first place (but condition scripts don't help if there aren't anyway)
      • ok, so how would you detect the particular witness stack element? add a type prefix to every element? :/
      • sipa
        fair, but transactions with no checksigs at all are pointless anyway
      • luke-jr: let the bikeshedding begin :)
      • luke-jr
        :<
      • while a possible option, I don't really see how this is *better* than a CLTV-like opcode that implies the locktime on the tx rather than requires a separate commitment. It just adds complexity, but the net result is essentially identical.
      • Chris_Stewart_5 joined the channel
      • I suppose it comes down to the static analysis thing again
      • maaku
        sipa: a hypothetical 2-way SPV peg implemented in an expanded script would have no checksigs but be useful
      • also there's NONE|ANYONECANPAY
      • luke-jr
        maaku: in that hypothetical, I'm not sure there is a use case for replay protection
      • sipa
        luke-jr: it isn't. if the context is visible.to svript execution, you need to invoke the script validation essentially after every block for your whole mempool, for example
      • things that are recognizable external to scripts can be dealt with directly
      • luke-jr: for example, in CLTV, we can just reevaluate the locktimes when a reorg occurs... we know the script validity can't ever change
      • luke-jr
        sipa: no, because the outcome of CHECKBLOCKATHEIGHT (hypothetical, ignore the BIP for now) would be NOP *always*; there is a side effect of copying the expected block hash and height to a transaction variable, which is the same for all executions of that script; the transaction validity depends on compatibility of the context and that variable
      • it's the same as runtime counting of sigops
      • sipa
        define 'transaction variable' ?
      • ah, i see - some tx-wide result of script execution
      • luke-jr
        sipa: we could store it on CTxMemPoolEntry, or even CTransaction (but never serialise it)
      • right