I decided to take this thread back on-list because I beleive that the
'revocation utxo' feature enabled by OP_CTV commiting to scriptSig may
have wider implications that can slightly change the behavior of Bitcoin
as a system, and some might not expect such changes or might not find
them desireable
Hi Dmitry,
I don't think that this is fundamentally introducing new behavior, but
let's take a closer look.
We can talk about the issue you bring up purely in terms of a hypothetical
"OP_CHECKINPUTOUTPOINTVERIFY" and "OP_CHECKINPUTSCRIPTVERIFY" (CIOV, CISV)
with obvious implied by name semantics,
Dave,
I think your point:
*When schnorr and taproot are done together, all of the following
transaction types can be part of the same set: - single-sig spends
(similar to current use of P2PKH and P2WPKH) - n-of-n spends with musig
or equivalent (similar to current use of
I am working on CTV, which has cases where it's plausible you'd want a
taproot tree with a NUMS point.
The need for NUMS points is a little bit annoying. There are a few reasons
you would want to use them instead of multisig:
1) Cheaper to verify/create.
If I have a protocol with 1000 people in i
On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
> I'm missing something in one of the cases?
That's fair. However, it's only true if everyone constructs their
merkle tree in the same way, with a
Good morning Dmitry, and Jeremy,
> There is a principle that some find valuable: "During reorgs of depth
> less than 100, it is always possible to eventually replay transactions
> from the old branch into the new branch as long as no double spends are
> attempted" (quoted from Russel O'Connor fro
