Re: [bitcoin-dev] Responsible disclosure of bugs

2017-09-13 Thread Anthony Towns via bitcoin-dev
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

Re: [bitcoin-dev] 2 softforks to cut the blockchain and IBD time

2017-09-13 Thread Tier Nolan via bitcoin-dev
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

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

2017-09-13 Thread Karl Johan Alm via bitcoin-dev
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

[bitcoin-dev] 2 softforks to cut the blockchain and IBD time

2017-09-13 Thread michele terzi via bitcoin-dev
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

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-13 Thread Peter Todd via bitcoin-dev
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

[bitcoin-dev] Minutia in CT for Bitcoin. Was: SF proposal: prohibit unspendable outputs with amount=0

2017-09-13 Thread Gregory Maxwell via bitcoin-dev
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

[bitcoin-dev] SigOps limit.

2017-09-13 Thread Russell O'Connor via bitcoin-dev
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

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-13 Thread Gregory Maxwell via bitcoin-dev
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

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

2017-09-13 Thread Peter Todd via bitcoin-dev
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