> I never did track down this exact issue but it's an artificial
> slowdown.. meaning compression and whatever else wouldn't help much.
I meant for anyone who wanted to distribute the dataset as a project.
> It has something to do with the database file locking and flushing..
> on some systems I'
A freshly deployed client on an old p4 has been idly crunching away
at building and verifying the initial chain for about a week now. It
should be done in a day or two. This seems rather untenable for
new users. Have any groups published proposals for distributing
a weekly precomputed bootstrap cha
> Do you have an alternative solution to the
> problem of green addresses spamming the blockchain?
Sure, here's one:
Green address provider give a REST-ful API, that provides the
following functionality:
+ Give transaction ID and credentials, request that the transaction be
declared "green"
(s
On Tuesday, February 07, 2012 10:04:36 AM Luke-Jr wrote:
> On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
> > > 769 : Make transactions with extra data in scriptSig non-standard
> >
> > If this affects relaying, it will significantly harm the ability to
> > replace the current spammy "gre
On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
> > 769 : Make transactions with extra data in scriptSig non-standard
>
> If this affects relaying, it will significantly harm the ability to replace
> the current spammy "green address" scheme with a sensible extra signature
> system. On the
On Mon, Feb 6, 2012 at 5:27 PM, Wladimir wrote:
> Change BitcoinAddressValidator::MaxAddressLength to 35
> The addresses are validated with walletmodel->validateAddress which in turn
> calls CBitcoinAddress addressParsed(addr) and then isValid(). Does this work
> for the new addresses?
Should do
6 matches
Mail list logo
