On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
> It would be a good starting point if the current policy could be
> clarified, so everyone is on the same page, and there is no confusion.
Collecting various commentary from here and reddit, I think current de
facto policy is something li
On Tue, Sep 12, 2017 at 3:57 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 4MB of secp256k1 signatures takes 10s to validate on my 5 year old
> laptop (125,000 signatures, ignoring public keys and other things that
> would consume space). That's much less
On Wed, Sep 13, 2017 at 09:39:28AM +, Gregory Maxwell wrote:
> On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
> wrote:
> > 2) Spending CT-shielded outputs to unshielded outputs
> >
> > Here one or more CT-shielded outputs will be spent. Since their value is
> > zero,
> > we make
On Wed, Sep 13, 2017 at 08:27:36AM +0900, Karl Johan Alm via bitcoin-dev wrote:
> On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
> wrote:
> >> Without the limit I think we would be DoS-ed to dead
> >
> > 4MB of secp256k1 signatures takes 10s to validate on my 5 year old
> > lapt
On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
wrote:
> 2) Spending CT-shielded outputs to unshielded outputs
>
> Here one or more CT-shielded outputs will be spent. Since their value is zero,
> we make up the difference by spending one or more outputs from the CT pool,
> with the cha
On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
wrote:
> Quite simply, I just don't think the cost-benefit tradeoff of what you're
> proposing makes sense.
I agree that dropping zero value outputs is a needless loss of
flexibility. In addition to the CT example, something similar cou
On Sat, Sep 09, 2017 at 11:11:57PM +0200, Jorge Timón wrote:
> Tier Nolan, right, a new tx version would be required.
>
> I have to look deeper into the CT as sf proposal.
>
> What futures upgrades could this conflict with it's precisely the
> question here. So that vague statement without provid
On Tue, Sep 12, 2017 at 11:58 PM, michele terzi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Pros:
>
> you gain a much faster syncing for new nodes.
> full non pruning nodes need a lot less HD space.
> dropping old history results in more difficult future chainanalysis (at
>
the blockchain is 160Gb and this is literally the biggest problem bitcoin has
right now. syncing a new node is a nightmare that discourages a lot of people.
this single aspect is what hurts bitcoin's decentralization the most and it is
getting worse by the day.
to solve this problem i propose 2
On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
wrote:
>> Without the limit I think we would be DoS-ed to dead
>
> 4MB of secp256k1 signatures takes 10s to validate on my 5 year old
> laptop (125,000 signatures, ignoring public keys and other things that
> would consume space). T
10 matches
Mail list logo