59
The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction.
To understand this, first understand the concept of a tree. Consider an 8 ...
50
There are basically four pieces of data that are maintained:
blocks/blk*.dat: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.
blocks/index/*: this is a ...
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 ...
16
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 ...
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 ...
8
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 ...
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 ...
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
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
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
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
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
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 ...
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
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
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
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
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.
3
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 ...
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 ...
3
It's not true that you use just the merkle root (nor does the article say that). Rather, you use just the parts of the merkle tree that relate to your transaction. That includes the root.
3
If an attacker has write access to your database without you noticing immediately, it's pretty much Game Over.
Say you are actually able to secure the payout address field from tampering, then the attacker could still overwrite the password field with his own hash, log in as the user and change the payout address through the "allowed" way.
You should not ...
Only top voted, non community-wiki answers of a minimum length are eligible
