On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot spending path. I have no strong > reasons why this would be necessary, but I'd like to hear other > people's thoughts.
Thanks everyone who commented so far, but let me clarify the context of this question first a bit more to avoid getting into the weeds too much. If it turns out to be necessary to explicitly commit to permitting Graftroot spending, there are a number of approaches: * Use a different witness version (or other marker directly in the scriptPubKey) to enable Graftroot. * Signal the permission to spend through Graftroot inside the Taproot script as suggested by ZmnSCPxj. * Make "Spend through Graftroot" a special script (possibly indirectly with a Merkle tree in Taproot). * Implement Graftroot as an opcode/feature inside the scripting language (which may be more generically useful as a delegation mechanism). * Postpone Graftroot. All of these are worse in either efficiency or privacy than always permitting Graftroot spends directly. Because of that, I think we should first focus on reasons why a lack of commitment to enabling Graftroot may result in it being incompatible with certain use cases, or other reasons why it could interfere with applications adopting such outputs. @Natanael: all of these concerns only apply to a new hypothetical Taproot/Graftroot output type, which combines pay-to-pubkey and pay-to-script in a single scriptPubKey that just contains a public key. It doesn't apply to existing P2SH like constructions. Also, the concern of making Graftroot optional does not apply to Taproot, as the Taproot spending path's script is committed to (using scriptPubKey = P + H(P,script)*G), allowing the script to be explicitly chosen to be a non-spendable script, which the author could prove is the case (without revealing it to the entire world). It is also always possible to create a "script only" Taproot output (without key that can unconditionally spend), by picking a pubkey that is provably unspendable (hashing onto a curve point, in particular), or through pubkey recovery. Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
