Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-09-20 Thread Lloyd Fournier via bitcoin-dev
r is misbehaving. > > But this is the OP thread: > > [bitcoin-dev] Taproot (and graftroot) complexity > Anthony Towns aj at erisian.com.au > Mon Feb 10 00:20:11 UTC 2020 > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017622.html > > href="mailto

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-09-19 Thread Jay Berg via bitcoin-dev
> At the time you create a utxo, provided you don't reuse keys, all taproot > spends are indistinguishable. At the time you spend a taproot utxo, does reusing keys act differently in taproot than with Pay-to-PubKey-Hash? Or is it the same deal.. same pubkey creates same address? Question: does

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-14 Thread David A. Harding via bitcoin-dev
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

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-14 Thread Jeremy via bitcoin-dev
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

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-10 Thread Jonas Nick via bitcoin-dev
I agree with most of the comments so far, but the group brings up an often overlooked point with respect to the privacy benefits of taproot. In the extreme case, if there would be no policies that have both a key and a script spend path, then taproot does not improve anonymity sets compared to the

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread ZmnSCPxj via bitcoin-dev
Good morning The Group, There are already many excellent arguments presented for Taproot, let me present a related one. Notice your example MAST: > >       /\ >      /  \ >     /    \ >    /      \ >   /\      /\ >  /  \    /  \ > /\  /\  /\  /\ > a b c d e f g h Of particular note is that

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread Anthony Towns via bitcoin-dev
On Sun, Feb 09, 2020 at 02:19:55PM -0600, Bryan Bishop via bitcoin-dev wrote: > However, after > our review, we're left perplexed about the development of Taproot (and > Graftroot, to a lesser extent). I think the main cause of the perplexity is not seeing the benefit of taproot. For me, the

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-09 Thread David A. Harding via bitcoin-dev
On Sun, Feb 09, 2020 at 02:47:29PM -0600, Anon via Bryan Bishop via bitcoin-dev wrote: > 1) Is Taproot actually more private than bare MAST and Schnorr separately? Yes. > What are the actual anonymity set benefits compared to doing the separately? When schnorr and taproot are done together,

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread Antoine Riard via bitcoin-dev
> In particular, you care more about privacy when you are contesting a > close of a channel or other script path because then the miners could be more > likely to extract a rent from you as "ransom" for properly closing your channel > (or in other words, in a contested close the value of the

[bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-09 Thread Bryan Bishop via bitcoin-dev
Apologies for my previous attempt at relaying the message- it looks like the emails got mangled on the archive. I am re-sending them in this combined email with what I hope will be better formatting. Again this is from some nym that had trouble posting to this mailing list; I didn't see any emails

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread Matt Corallo via bitcoin-dev
Responding purely to one point as this may be sufficient to clear up lots of discussion: On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote: > Is Taproot just a probability assumption about the frequency and > likelihood of > the signature case over the script case? Is this a good assumption? 

[bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread Bryan Bishop via bitcoin-dev
The following is a message forwarded from an anonymous email that, for whatever reason, couldn't be relayed through the mailing list without my assistance. This email is the first of a collection of sentiments from a group of developers who in aggregate prefer to remain anonymous. These emails