Natanael [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-23 📝 Original message:Den tis 22 maj 2018 ...

📅 Original date posted:2018-05-23
📝 Original message:Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> skrev:

> 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.
>

I'm definitely in favor of the suggestion of requiring a flag to allow the
usage of these in a transaction, so that you get to choose in advance if
the script will be static or "editable".

Consider for example a P2SH address for some fund, where you create a
transaction in advance. Even if the parties involved in signing the
transaction would agree (collude), the original intent of this particular
P2SH address may be to hold the fund accountable by enforcing some given
rules by script. To be able to circumvent the rules could break the purpose
of the fund.

The name of the scheme escapes me, but this could include a variety of
proof-requiring committed transactions, like say a transaction that will
pay out if you can provide a proof satisfying some conditions such as
embedding the solution to a given problem. This fund would only be supposed
to pay out of the published conditions are met (which may include an expiry
date).

To then use taproot / graftroot to withdraw the funds despite this
possibility not showing in the published script could be problematic.

I'm simultaneously in favor of being able to have scripts where the usage
of taproot / graftroot isn't visible in advance, but it must simultaneously
be possible to prove a transaction ISN'T using it.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180524/328e93da/attachment.html>;