Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Gregory Maxwell
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen wrote: >> But those issues are solvable through other, non-backwards incompatible >> means. For example, mandate that a refers >> to the first such pair that is not already spent. No? > > Yes, that is essentially what BIP 30 did. It's important to n

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Amir Taaki
It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me. From: Mark Friedenbach To: Jeff Garzik Cc: Bitcoin Devel

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Gavin Andresen
> But those issues are solvable through other, non-backwards incompatible > means. For example, mandate that a refers > to the first such pair that is not already spent. No? Yes, that is essentially what BIP 30 did. We want to do this also, partly for "belt and suspenders" security but mostly fo

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Mark Friedenbach
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik wrote: > On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote: > > The proposal is simple, and it's a small change for miners, I imagine. > > > > My question is: why? > > > > I worry about stuffing too many requirements on the coinbase. I suppose > >

Re: [Bitcoin-development] Pruning in the reference client: ultraprune mode

2012-07-06 Thread Gregory Maxwell
Pieter's performance numbers are a bit conservative if anything— profiles on ultraprune[1] show that the reference client's wasting of a lot of time in redundant serialization and hashing operations is the major time sink. Once thats cleared up it should be quite a bit faster [1] https://people.xi

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Peter Vessenes
So, The proposal is simple, and it's a small change for miners, I imagine. My question is: why? I worry about stuffing too many requirements on the coinbase. I suppose the coinbase is easily extendible if we run out of bytes, but I think I'd like to see some more discussion / good / bad type cas

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Peter Vessenes
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik wrote: > On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote: > > The proposal is simple, and it's a small change for miners, I imagine. > > > > My question is: why? > > > > I worry about stuffing too many requirements on the coinbase. I suppose > >

[Bitcoin-development] Pruning in the reference client: ultraprune mode

2012-07-06 Thread Pieter Wuille
Hello all, I've implemented a new block/transaction validation system for the reference client, called "ultraprune". Traditionally, pruning for bitcoin is considered to be the ability to delete full transactions from storage once all their outputs are spent, and they are buried deeply enough i

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Jeff Garzik
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote: > The proposal is simple, and it's a small change for miners, I imagine. > > My question is: why? > > I worry about stuffing too many requirements on the coinbase. I suppose > the coinbase is easily extendible if we run out of bytes, but I thi

[Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Jeff Garzik
Please review and comment... Block v2, Height in Coinbase https://en.bitcoin.it/wiki/BIP_0034 BIP: 34 Title: Block v2, Height in Coinbase Author: Gavin Andresen Status: Draft Type: Standards Track Created: 2012-07-06 Abstract Bitcoin blocks and transactions are versioned binary str