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 in
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes pe...@coinlab.com 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
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
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]
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index 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
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 m...@monetize.io
To: Jeff Garzik
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote:
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index refers
to the first such pair that is not already spent. No?
Yes, that is
7 matches
Mail list logo
