Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jun 2015 08:10:39 +0200
From:      Matthias Andree <mandree@FreeBSD.org>
To:        Mathieu Arnold <mat@FreeBSD.org>, marino@freebsd.org,  ports-committers@freebsd.org, svn-ports-all@freebsd.org,  svn-ports-head@freebsd.org
Subject:   Re: svn commit: r389117 - head/databases/db48
Message-ID:  <557A77DF.3060700@FreeBSD.org>
In-Reply-To: <6171E2484BC3B20B03278570@atuin.in.mat.cc>
References:  <201506101808.t5AI8akA072276@svn.freebsd.org> <55788222.2090909@marino.st> <6E26F13BC369E591AB7ED533@atuin.in.mat.cc> <5578927C.9070909@marino.st> <6171E2484BC3B20B03278570@atuin.in.mat.cc>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 10.06.2015 um 21:48 schrieb Mathieu Arnold:
> +--On 10 juin 2015 21:39:40 +0200 John Marino <freebsd.contact@marino.st>
> wrote:
> | something like this taking "years" is pretty scary.  It shouldn't be
> | that hard.  I'll defer to your knowledge and accept that it is.
> 
> The idea is that the canonical wallet format for bitcoin has been a db48
> file for ever.  They have a new format in the works (it may even be there
> already) but they will need to be able to read db48 files for a long time.
> It is the wallet, the thing you have put your money in, the thing you may
> have stored someplace and you almost never access.
> 

The issue is that the *coin deployment scenarios rely on implicit
resource limits of the db48 implementation and its default
configuration, and not the db48 _format_, which can also be processed
with newer db implementations.

This is somehow related to the chain lenghts vs. lock limits in default
configuration, and using implementations with different limits can cause
trouble as in chain splits.  IOW, *coin does not scale properly.

This is a serious design problem in *coin and must be fixed upstream.
When we first discussed this, there was word that they were working on
switching to leveldb, avoiding these implicit Berkeley DB limits, but I
haven't checked the details since.

Perhaps it's time to just pull the plug on such garbage.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557A77DF.3060700>