Yes, certainly an RLE-style compression would work better in this instance,
but I wanted to see how well standard compression algorithms would work
without doing something custom. If there are other standard compression
schemes better suited to this, please let me know.
As far as relevance, I'll c
You compressed something which is truly natively a bitfield using regular
compression algorithms? That is expected to get horrible results. Much
better would be something which handles it natively, say doing run length
encoding on the number of repeated bits and compressing that using elias
omega e
On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev
wrote:
> 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.
My understanding of the question is this:
Are there any useful applications
On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille 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
Hi all,
Jimpo, thanks for looking into those stats! I had always imagined that there
would be a more significant savings in having all filters in one bundle, as
opposed to separate. These results are interesting, to say the least, and
definitely offer us some flexibility in options for filter shar
On Wed, May 23, 2018 at 10:06 PM, Natanael via bitcoin-dev
wrote:
> 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
Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev@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
Hi all,
I'm bringing this up again because since the last time (2014) new papers on
network attacks have been published, and in general I think this is
something that has to be done in one or another form.
### Motivation
It has been shown that revealing the topology of the network may increase
the
On Wed, May 23, 2018 at 01:50:13PM +, Andrew Poelstra via bitcoin-dev wrote:
>
> Graftroot also break blind signature schemes. Consider a protocol such as [1]
> where some party has a bunch of UTXOs all controlled (in part) by the same
> key X. This party produces blind signatures on receipt o
Any chance you could add a graph of input-scripts (instead of input outpoints)?
On Wed, May 23, 2018 at 7:38 AM, Jim Posen via bitcoin-dev
wrote:
> So I checked filter sizes (as a proportion of block size) for each of the
> sub-filters. The graph is attached.
>
> As interpretation, the first ~12
On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote:
>
> 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
Thanks, Jimpo!
This is very encouraging, I think. I sorta assumed that separating the
elements into their own sub-filters would hurt the compression a lot more.
Can the compression ratio/false positive rate be tweaked with the
sub-filters in mind?
With the total size of the separated filters bein
Good morning Pieter and list,
It seems to me, naively, that it would be better to make Graftroot optional,
and to somehow combine Taproot and Graftroot.
So I propose that the Taproot equation be modified to the below:
Q = P + H(P, g, S) * G
Where `g` is the "Graftroot flag", i.e. 0 if disa
13 matches
Mail list logo
