The fix for this bug is available in version 0.9.4, just tagged by
upstream: https://github.com/bitcoin/bitcoin/tree/v0.9.4
Scott said:
one more thing: debian is discussion dropping libdb (the db the node,
but not the wallet, uses). That might force our hand as well: either
ship and support upstream's included libdb or drop the node and just
ship the wallet. libdb long-term security maintenance might be
challenging.
What happened with 0.8 was this: rather than keeping an index of every
transaction, with its position in each block, etc, in BDB, a LevelDB is
created, and it's used to maintain what's called the UTXO set, short for
Unspent Transaction Output set. Basically, this contains all unspent
transaction ou
I don't have anything else to say besides the explanation that we already
have re: Bitcoin.
On Wed, Jan 8, 2014 at 4:31 PM, Dmitry Smirnov wrote:
> On Wed, 8 Jan 2014 23:22:37 Micha wrote:
> > It would be better to change Litecoin to use the bundled LevelDB,
> > for the same reason as that is a
And additionally, if you attempt to run a 4.8-built binary with a 5.1
wallet, the error isn't clear about the problem, as it's a BDB failure and
not a Bitcoin one, that can be very confusing to troubleshoot.
On Wed, Dec 11, 2013 at 6:51 PM, Micha Bailey wrote:
> The problem
The problem is not easily worked around by importing/exporting private
keys, as there will potentially be many different keys that need to be
exported and reimported, some of which aren't even exposed to the user due
to the mechanics of change addresses and the keypool. Additionally, users
expect t
Please note that limiting connection bandwidth on a Bitcoin node (either
bitcoind or bitcoin-qt), *especially* while listening to connections (that
is, without setting listen=0 in the configuration file or -listen=0 on the
command line), is in fact, harmful to the Bitcoin network. If you accept
inc
7 matches
Mail list logo
