26
"Figure 7-2. Calculating the nodes in a merkle tree" from Mastering Bitcoin shows the Merkle Root (HABCD) of a list of four transactions: Tx A, Tx B, Tx C, and Tx D:
To verify that a transaction—for example, that with hash HK—is a valid transaction (i.e., part of a list of, in this example, 16 transactions with hashes HA, HB, …
HP), one need only perform ...
17
As someone who was involved in doing that migration at the time, I believe it was the right decision. LevelDB is far from perfect, but I wouldn't know what else to use.
In particular:
BDB is much slower for our usage (large atomic batch writes, small random reads).
There were reports of database corruption as well with BDB, at a time when it was used far ...
10
reindex doesn't also re-validate blocks, does it?
It does, but signature verification (the slowest bit) is skipped on most of the early blockchain. The command attempts to sync with the network by reusing as many blocks as possible that are already written to the disk, which may very well include damaged or partially written ones.
Any experience with ...
10
Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.
Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.
We don't need a server/client architecture, as we can't have multiple applications accessing ...
9
It depends on what you mean by "private". The word private is not really associated with Eris as far as I can tell. Rather, the word "permissioned" is used instead, and therein lies all the difference and your answer.
A "private" blockchain might imply a blockchain that is not shared with anyone. Such blockchains would effectively amount to slow databases ...
9
Signed commitments with immutable history are all that’s required for proof of integrity. Moreover, assuming commitments are immutable (transactions can only be reversed by adding a new commitment that reverses the actions of the previous commitment), you only need to keep track of the most recent commitment.
If the commitment signer is a known entity, a ...
9
The introduction of descriptor wallets presents an opportunity to introduce a new database backend as descriptor wallets are backwards incompatible. The following is taken from Andrew Chow's blog post on what's coming to the Bitcoin Core wallet in 0.21. (There was also discussion on this GitHub Issue.)
Why move from Berkeley DB?
Not designed to be used as ...
7
Private blockchains can be seen as a new method for ensuring consistency in a distributed database, even if that database is an environment of perfect trust. There is an equivalence between how a blockchain prevents two transactions spending the same prior transaction output, and how multiversion concurrency control (MVCC) in a relational database prevents ...
7
The fork serves two purposes:
Local modifications that are hard to bring upstream:
Windows support (which is partially based on the existing Windows port, but needed changes for building in MinGW)
Removal of compression support, as it doesn't help, and complicates the build.
Strict control over changes. Given the previous experience with the BDB to ...
7
The constant is called MAX_BLOCKFILE_SIZE and is set in src/validation.h. It is currently set to 0x8000000 which is 128 MiB (134,217,728 bytes).
You can see where it is checked in FindBlockPos() in src/validation.cpp.
There isn't any indication of why this specific size was chosen and it may be arbitrary. It is desirable to have some limit because some ...
6
A signature check failed for a valid transaction. This likely indicates a CPU or RAM problem with the system you're running on (even though you don't see regular errors in normal operation, Bitcoin does so many computations during validation that it's likely to see them more).
The result of this is that bitcoind marked the chain this transaction was in as ...
6
A bitcoin is not a piece of data, and therefore does not have a length. A bitcoin, the unit of currency, is just like any other unit of measurement. It wouldn't make sense to ask "how much data is a meter?", and likewise it doesn't make sense to ask how long a bitcoin is.
That said, the amount of bitcoin that is stored by an individual is the sum of all ...
6
Each entry in the new 0.15 format is defined as outpoint:coin, and has the following structure:
Outpoint is formed by: key | tx_hash | index.
Where the key corresponds to b'C', or 43 in hex. The transaction hash in encoded in Little endian, and the index
is a base128 varint. The corresponding Bitcoin Core source code can be found here.
On the other ...
6
You can use a self-hosted (but low-burden!) instance of Esplora.
Blockstream is also exposing an instance for free (at the moment) at blockstream.info.
Disclaimer: if you take part of Bitcoin as an economic actor (as an application providing account balances may imply), you should really consider using your own source of truth and self-host the instance. It'...
5
It's not really clear what your use case is.
If you need to retrieve the addresses later, you can store each address as a string. That's only ~34MB, which easily fits in memory.
To save space, you can convert each address to hash160 format, which is only 20 bytes. In total, that's 20 MB.
If you're merely trying to test whether a Bitcoin address is ...
5
Since it's unclear what context you are asking in:
The blockchain is stored, distributed, on every machine in the Bitcoin network being used to mine Bitcoin.
This network is self-regulating and peer-to-peer. There is majority rule, meaning that if one node on the network no longer agrees with the other nodes (on, say, what the hash of the last block was), ...
5
Researcher Arvind Narayanan stated his opinion on this matter in his post “Private blockchain” is just a confusing name for a shared database:
It is true that adding signatures and hash pointers makes a shared database a bit more secure. However, it’s qualitatively different from the level of security, irreversibility, and censorship-resistance you get ...
5
It depends on the implementation. The network itself does not have a database engine. Bitcoin Core and software derived from it (most altcoin software is derived from Core) uses LevelDB to index the blockchain and store the chainstate data (UTXO set, current best block, etc.). It uses BerkeleyDB for the wallet.
However different implementations can use ...
4
The ripple server uses SQLite for structured data and a configurable "back end" for unstructured "bulk" storage.
The structured data consists of things like transactions indexed by which accounts they affected. The unstructured data consists of "chunks" of data indexed by hash that constitute portions of network history.
The preferred back end for bulk ...
4
To the best of my understanding, it's just that the blocks are stored in a different order. Headers first synchronization makes use of parallel downloads and the blocks are downloaded (and then stored) out of order. It used to be the case in older versions that blocks were downloaded and then stored in order, so that's whey they added the comment to the ...
4
If you settle for a relational DB you can try BitcoinDatabaseGenerator.
https://github.com/ladimolnar/BitcoinDatabaseGenerator/releases
Sources and wiki: https://github.com/ladimolnar/BitcoinDatabaseGenerator
It may take you a few hours (it takes me 90 minutes but that will vary depending on your hardware and configuration) to transfer the blockchain files ...
4
There was a recent presentation by Portia Burton going over some of the basic steps in creating your own custom blockchain based on Ethereum, however it is in Node not Python as you are requesting.
It's not incredibly detailed, but still it could be useful: https://youtu.be/QWHjp_nzxaY?t=14m11s
There's also this guide on bitcointalk using C++ and the ...
4
Ok, I think I got it.
Here is a short guide based on this bitcoin wiki article.
Notes:
This does not concern backing up your keys. If you lost your wallet, or your keys, and you made the backup discussed here beforehand, this backup will not help you recover your lost coins. This will only save you some bandwidth/time/storage.
Don't load a database to your ...
4
Sometimes LevelDB has bugs and those bugs sometimes are not fixed in a timely manner in the upstream LevelDB project. These bugs can be problematic for Bitcoin Core so a fork of LevelDB was created to handle these bugs specifically.
Additionally, to ensure security, we want to use a specific version of LevelDB at a specific commit. By having our own fork of ...
4
Storing private keys in an online server is not best practices (even if you quickly transfer to an offline wallet). Generally, you should not store private keys on an online device
Instead, if you use a BIP32 HD wallet architecture, you can just store an extended public key on your online server. This will allow you to generate receiving addresses on the ...
4
There simply is none. There's a key value store in LevelDB for the UTXO, and for miscellaneous things like the locations of block files on disk. Relational databses are far too slow for the task, and unnecessary given the type of information being stored.
4
You are allocating far too much dbcache. If you allocate 4000 MB to the dbcache, you will use up all of your RAM and it will crash. Your operating system needs RAM, Bitcoin Core itself needs RAM outside of the dbcache. I would highly recommend that you do not set a dbcache at all as 4 GB is really not enough RAM to handle a larger dbcache, Bitcoin Core's ...
4
Most likely this is due to a mismatch between the sqlite3 version that c-lightining was compiled with and the version your OS currently has installed. With the recently release v0.10
2, c-lightining now accepts a far wider range of library versions, so upgrading should address the issue.
3
Blockchain is a mere chain of blocks and this respect is worse than every database on earth. What makes the public blockchain unique is the proof-of-work that ensures that thousands of copies of the blockchain are probabilistically identical all across the globe and with no discrete authority trusted to manage them. A private blockchain is a ledger managed ...
3
If it were not this way, transaction generation would be slow and fragile. First, you couldn't form a transaction unless you knew which block all its outputs were in, which would mean you'd have to wait until they get in a block. Worse, if there were a blockchain reorganization, it would be impossible to recover many transactions because recovering their ...
Only top voted, non community-wiki answers of a minimum length are eligible