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
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
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,
Good morning M,
> I don't see how the scenario you outline here has anything to do with the
> mechanism I proposed. An empty block doesn't contain any transactions (by
> definition) so it wont contest any transactions in any given node's mempool.
> The aim isn't to prevent empty nodes, it's
> 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
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
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?
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 is message (3/3).
This email is the third of a collection of sentiments from a group of
developers
who in aggregate prefer to remain
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 is message (2/3).
This email is the second of a collection of sentiments from a group of
developers
who in aggregate prefer to remain
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
Hi ZmnSCPxj,
On Sun, Feb 9, 2020 at 12:00 AM ZmnSCPxj wrote:
> Good morning M,
>
> > > > Nodes reject announced blocks that:
> > > >
> > > > * include transactions that are in contest with any in their mempool
> > > > * include transactions that are in contest with any in the contest
> pool
> >
11 matches
Mail list logo
