Thanks for the comments so far! I'm going to respond to some of the comments here. Things which I plan to address with changes in the BIP I'll leave for later.
On Mon, 6 May 2019 at 13:17, Luke Dashjr <l...@dashjr.org> wrote: > Tagged hashes put the tagging at the start of the hash input. This means > implementations can pre-cache SHA2 states, but it also means they can't reuse > states to produce data for different contexts. (I'm not sure if there is a > use for doing so... but maybe as part of further hiding MAST branches?) It's true you can't cache/precompute things across tags, but I also think there is no need. The type of data hashed in a sighash vs a merkle branch/leaf vs a tweak is fundamentally different. I think this is perhaps a good guidance to include about when separate tags are warranted vs. simply making sure the input does not collide: there shouldn't be much or any shared data with things that are expected to be inputs under other tags. > Is there any way to use the Taproot construct here while retaining external > script limitations that the involved party(ies) *cannot* agree to override? > For example, it is conceivable that one might wish to have an unconditional > CLTV enforced in all circumstances. Yes, absolutely - you can use a point with unknown discrete logarithm as internal key. This will result in only script path spends being available. For the specific goal you're stating an alternative may be using a valid known private key, using it to pre-sign a timelocked transaction, and destroying the key. > It may be useful to have a way to add a salt to tap branches. If you don't reuse public keys, effectively every branch is automatically salted (and the position in the tree gets randomized automatically when doing so, providing a small additional privacy benefit). >> Some way to sign an additional script (not committed to by the witness >> program) seems like it could be a trivial addition. > This would be especially useful for things like OP_CHECKBLOCKATHEIGHT: > https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki If you're talking about the ability to sign over the ability to spend to another script ("delegation"), there are lots of interesting applications and ways to implement it. But it overlaps with Graftroot, and doing it efficiently in general has some interesting and non-obvious engineering challenges (for example, signing over to a script that enforces "f(tx)=y" for some f can be done by only storing f and then including y in the sighash). For the specific example of BIP115's functionality, that seems like a reasonable thing that could be dealt with using the annex construction in the proposed BIP. A consensus rule could define a region inside the annex that functions as a height-blockhash assertion. The annex is included in all sighashes, so it can't be removed from the input; later opcodes could include the ability to inspect that assertion even. On Tue, 7 May 2019 at 13:43, Sjors Provoost <sj...@sprovoost.nl> wrote: > One reason why someone would want to avoid a "everone agrees" branch, is > duress (or self-discipline, or limiting powers of a trustee). In particular > with respect to time-locks.> Indeed, though as I suggested above, you can also use timelocked transactions (but using only CLTV branches is more flexible certainly). > Can this "unknown discrete logarithm" be made provably unknown, so all > signers are assured of this property? Bonus points if the outside world can't > tell. The exact mechanism could be outside the scope of the BIP, but knowing > that it's possible is useful. Yes, that's a TODO that's left in the draft, but this is absolutely possible (using a hash-to-curve operation). As ZmnSCPxj already suggested, there can even be a fixed known constant you can use for this. However, you get better privacy by taking this fixed known constant (call it C) and using as internal key a blinded version of it (C+rG, for some random value r, and G the normal secp256k1 generator); as long as the DL between G and C is unknown, this is safe (and does not reveal to the world that in fact no key-path was permitted when spending). > Regarding usage of Schnorr: do I understand correctly that the "everyone > agrees" internal key MUST use Schnorr, and that individual branches MAY use > Schnorr, but only if they're marked as tapscript spend? > > Why is tapscript not mandatory? Spending using the internal key always uses a single Schnorr signature and nothing else. When you spend using a script path, you must reveal both the script and its leaf version. If that leaf version is 0xc0, the script is interpreted as a tapscript (in which only Schnorr opcodes exist). If that leaf version is not 0xc0, the script is undefined, and is unconditionally valid. This is one of the included extension mechanisms, allowing replacing the whole script language with something else, but without revealing it unless a branch using it is actually used (different Merkle tree leaves can have a distinct leaf versions). So the reason that tapscript is not mandatory is because other leaf versions are undefined, and left for future extensions (similar to how future segwit versions at the output level are undefined). Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
