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 ...
49
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 ...
25
"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 ...
15
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
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 ...
7
This is possible in git HEAD, and will be in 0.7.0. You can move the existing blk0001.dat elsewhere, delete blkindex.dat, and then start the client using ./bitcoind -loadblock=blk0001.dat.bak
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
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 ...
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
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 ...
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 ...
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
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 ...
4
Meni's answer is probably correct, but describes a very far future, in my opinion.
In the more near future, I believe we'll see fully-validating nodes that do not keep the entire block chain around. The current reference client implementation uses blockchain + transaction database for validation, which cannot easily support pruning. I'm working on modifying ...
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
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
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
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 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
Some blockchain pruning will be done but it will still be several TB in size. Most Bitcoin users will not run a full node but rather an SPV client, or just an eWallet.
Also, I suspect that most Bitcoin transfers will not be directly on the blockchain.
3
It was details of 61016 user accounts as a CSV file with fields UserID,Username,Email,Password. The passwords are hashed, and most of them salted too, but some (the oldest) are simple md5 hashes.
I just tried searching google for it and was unsuccessful.
I have a copy, and could make it available for download but don't know if that would be legal. I'm ...
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 ...
3
If you only need receiving addresses, then you need only a table for those along with a column that flags to prevent it from from being used a second time.
Keys can be generated in bulk:
- http://bitcointalk.org/index.php?topic=101708.0
Now just because you aren't saving the private key on the web host doesn't mean security can be lax. If a host were ...
3
I've worked with Abe for some time; I'll try to have a run at it... I'm using the latest table list from Database version Abe39 on MySQL.
Utility tables:
abe_lock:
Used for locking while performing DDL
configvar:
Configuration and results of some auto-detected SQL features.
Blockchain tables:
block:
Block hash and related statistic/infos.
block_next:
...
Only top voted, non community-wiki answers of a minimum length are eligible
