< gmaxwell>
Who do I make suggestions about the optech newsletter to?
< gmaxwell>
"Simple multisig spending using Taproot" in particular mentions the key-aggregation multisig approach, but my discussions with Bitcoin businesses suggest that few will use it as described there, due to accountability.
< gmaxwell>
That subject probably deserves an in-depth look at some point.
< gmaxwell>
I expect that the most common multisig usage we'll see (after sufficient time for software/practices to mature) will be putting the most likely 2o2 key at the root and a tree with tapscripts for the other two satisfactions of the 2of3.
< gwillen>
gmaxwell: I assume the answer is moneyball
< gwillen>
(as to who to bother)
< bitcoin-git>
[bitcoin] achow101 opened pull request #16026: Ensure that uncompressed public keys in a multisig always returns a legacy address (master...dont-sw-ms-uncomp) https://github.com/bitcoin/bitcoin/pull/16026
< jeremyrubin>
sipa: in verifyWitnessProgram, in taproot, can you explain why we are checking control.size() \in {n * 32 : n \in 0..=32}?
< jeremyrubin>
Don't we need to check that control < 520 somewhere?
< jeremyrubin>
Because it is popped from the stack, I don't think the later check catches this?
< jeremyrubin>
e.g. we should be checking witness.stack.at(i).size() > MAX_SCRIPT_ELEMENT_SIZE not stack.at(i).size() > MAX_SCRIPT_ELEMENT_SIZE
< gmaxwell>
jeremyrubin: the scriptwitnesses have no such size limitation.
< jeremyrubin>
Ah I see -- so it's just triggering the DISCOURAGE_UPGRADEABLE branch
< jeremyrubin>
The limitation is flexible per segwit version
< gmaxwell>
Right. The 520 limit was dumb and obnoxious. :)
< gmaxwell>
(I mean, for single objects its fine, but e.g. applied to nested scripts it was a problem)
< jeremyrubin>
Sure. Makes perfect sense and I'm glad that it's flexible.
< jeremyrubin>
I'm just looking at the segwit versions and wondering if the control flow can't be cleaned up before we're stuck with it
< gmaxwell>
Though while talking about that, is a depth limit of 32 really a reasonable constraint? if the hashtree is highly unbalanced that isn't a very large limit.
< jeremyrubin>
yeah I'd prefer to see it be something larger
< jeremyrubin>
aggregate savings would be larger
< jeremyrubin>
If someone's willing to pay for a far fetched branch, may as well put a very big limit
< jeremyrubin>
huffman coded spends should be the default
< jeremyrubin>
(one day, smart contracts will be written `if (likely(x > 0)) {}`...)
< gmaxwell>
jeremyrubin: miniscript has asymmmeric ORs...
< jeremyrubin>
Ah cool!
< jeremyrubin>
Do you pass in a probability
< gmaxwell>
no, at least as it is now it's just assumed to be highly asymmetric. Existing script doesn't provide that many options for asymmetry.
< gmaxwell>
I sent sipa a message suggesting the limit be something like 256 levels... that puts it into the realm of worst case hashing cost that you could hit otherwise.
< gmaxwell>
having a high limit also saves you from having to use a really complicated algorithim for building the huffman tree.
< jeremyrubin>
What's this OP_SUCCESS business?
< jeremyrubin>
ah found a reference
< jeremyrubin>
I think that it doesn't make sense to have OP_SUCCESS not be most opcodes. We should disable a lot more opcodes and then re-soft fork them back with improved semantics or whatever.
< gmaxwell>
meh, it's _really_ hard to decide on semantics for opcodes.
< gmaxwell>
hard enough that it'll be quite difficult to ever enable them
< gmaxwell>
witness how as soon as the bip was published you began shed painting over a single byte that doesn't even get serialized, and is only there so that its straightforward to domain seperate future hashes if thats ever needed. Imagine how much oppturnity there is for shed painting over something that actually does something.
< jeremyrubin>
to be fair there's a difference between shed painting and trying to understand why the shed was painted a particular color.
< jeremyrubin>
I am aware of the ways in which I'm mediocre, but a lot of the design decision isn't presented with justifications that I immediately perceive as the best among options.
< gmaxwell>
yeah, sure, still I think the point remains-- for most opcodes there is a very large design space, the complete implications of which can't be clear without going absurdly deep. At some point you have to terminate the search and just pick something.
< jeremyrubin>
I guess i mean more that we should disable things like OP_1SUB because I've never seen someone use it, so may as well re-reserve it
< jeremyrubin>
But maybe the burden of having a diff interpreter for tapscript is too high
< jeremyrubin>
(although I'd in many ways prefer that as it's easier to not break consensus)
< gmaxwell>
it's not like we're particularly short codes in any case.
< jeremyrubin>
not sure if this is caught elsewhere, but do we check that elements have a nonzero length on the witness stack? otherwise when we index scriptPubKey[0] we cause UB I think
< jeremyrubin>
Why hash the annex? Why not just move it to the ScriptExecutionData?
< jnewbery>
gmaxwell: >Who do I make suggestions about the optech newsletter to?
< jnewbery>
re: key aggregation -vs- taproot tree multisig: yes, I'm sure that's something that we'll cover in future newsletters, and moneyball gave an optech presentation yesterday that went into that in some depth. We'll hopefully have that available online soon
< bitcoin-git>
[bitcoin] dongcarl opened pull request #16029: netbase: Remove "tor" as a network specification (master...2019-05-remove-net-tor) https://github.com/bitcoin/bitcoin/pull/16029
< dongcarl>
Anyone got a good recommendation for real hardware to test i686? Or are people just using compat mode on x86_64?
< dongcarl>
Also, is the only "real hardware" riscv64 option the $999 HiFive Unleashed?!
< jeremyrubin>
sipa: perhaps early but I did some initial code review/refactoring on taproot execution
< jeremyrubin>
One minor bikeshed I have from the spec is that the code which is (pubkey[0] & 1 )+2 is probably lower cognitive load as: (pubkey[0] & 0b01) | 0b010, (pubkey[0] | 0b010) & 0b011
< jeremyrubin>
(I did not suggest changing that in the code so that it matches the spec, and it doesn't matter because it's ultimately equivalent, but if you do a revision might be good to change)
< bitcoin-git>
[bitcoin] dongcarl closed pull request #15586: chainparams: Explicitly use uint16 for nDefaultPort (master...2019-03-uint16-port) https://github.com/bitcoin/bitcoin/pull/15586
< bitcoin-git>
bitcoin/master fad0ce5 MarcoFalke: tests: Fail if RPC has been added without tests
< bitcoin-git>
bitcoin/master 9d266db MarcoFalke: Merge #15943: tests: Fail if RPC has been added without tests
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15943: tests: Fail if RPC has been added without tests (master...1905-testFailNoRpcCov) https://github.com/bitcoin/bitcoin/pull/15943