Share database of Bitcoin blocks ?
2010 May 24
See all posts
Share database of Bitcoin blocks ? @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
HostFat
Share database blocks ?
May 24, 2010, 06:43:49 PM
I have a question.
I saw that everyone need to get blocks before starting to get
coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to
generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks
somewhere on the official website?
Xunie
May 24, 2010, 07:49:00 PM
Well, what if the main website gets hacked and the blocks you are
downloading are not the original blocks?
I mean, this makes the network a hell of a lot of insecure.
HostFat
May 24, 2010, 07:55:54 PM
I think that probably they won't be accepted by the majority of the
network, that they have a different database/hash ... is it right?
Dynotor
May 24, 2010, 09:30:39 PM
Quote from: Joozero on May 24, 2010, 06:43:49 PM
I have a question.
I saw that everyone need to get blocks before starting to get
coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to
generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks
somewhere on the official website?
I'll defer to others on whether having a central database is a good
idea, but if you're creating multiple directories with the -datadir
command line option, you can safely bootstrap that directory by copying
"blkindex.dat" and "blk0001.dat" from an already established data
directory into your new one.
molybdenum
May 25, 2010, 03:40:57 AM
While a central database, or at least a partially-completed
centralized copy of a certain number of blocks would speed things up,
but then, so would mass-transfer between clients (requests for 500
blocks or so instead of one blocks at a time) and the latter would
implement it within the confines of the network, without needing web
hosting for a copy of the block database.
Currently, I believe one could grab a copy of someone else's blk*.dat
files and speed the process up that way, but it really shouldn't be
needed when the same thing can be done with a few snippets of code.
A draft standard for the bitcoin wire protocol would possibly be a
help here, in that it would be possible for someone C++-illiterate to
see what actually is possible in the current system ;-)
EDIT: if I understand correctly, a complete false start that wouldn't
disappear as soon as a client connected to the network at large would
require generating as many blocks as were currently in the network, so,
one individual would have to generate 57525 blocks to do major harm to
the network.
It could give someone a head start in forging a block, but not
really. Having a rouge starter set of blocks would be just like having
each new node started from that set of blocks be a rouge node, so it
should be similarly impractical to forge anything.
NewLibertyStandard
May 25, 2010, 04:44:05 AM
Most of the slowness results from the blocks needing to be verified
one at a time in order, not from network delays. At least according to,
if I'm not mistaken, satoshi, the Bitcoin author, in another thread.
There has been some talk about a lightweight client, which doesn't
verify all the blocks, but instead only broadcasts transactions. I'm not
familiar with the algorithm, but if it's possible, I think it would be
best to just alter the regular client so that when it starts up the
first time, it grabs the most current block and verifies blocks in
reverse order while also continuing to verify new blocks. That way
Bitcoin could start generating blocks immediately.
Xunie
May 25, 2010, 07:18:25 AM
Quote from: NewLibertyStandard on May 25, 2010, 04:44:05 AM
I'm not familiar with the algorithm, but if it's possible, I think it
would be best to just alter the regular client so that when it starts up
the first time, it grabs the most current block and verifies blocks in
reverse order while also continuing to verify new blocks. That way
Bitcoin could start generating blocks immediately.
Good idea, but we would need some form of indicator it did that to
the user, and warn the user about the potential hazards.
(Atleast, that's my idea.)
laszlo
May 25, 2010, 12:14:23 PM
It only verifies the last few as it is, to speed things up, but it
doesn't work backwards.
Satoshi has mentioned a simplified payment verification system that
he is planning to implement, which would allow payment only clients
which do not have to verify all the blocks - he just hasn't written it
yet.
I think even if you could just have someone ‘click here to install
instantly' it wouldn't do any good because they wouldn't have any
bitcoins and they wouldn't know what a bitcoin is 
NewLibertyStandard
May 25, 2010, 08:17:50 PM
Although I'm not familiar with the specifics of the algorithm
implementation in C++, I am familiar with how the verification works in
general. Although the algorithm would have to be re-written, it really
should be possible to verify blocks in both directions at the same time.
Each block contains the hash of the previous block, but the first block
contains a genesis hash, which isn't the hash of a previous block. The
first time bitcoins starts, it would treat a recent hash, perhaps a one
day old hash as a temporary genesis hash and quickly verify the roughly
144 blocks up to the most recent block and it would continue to verify
and optionally generate new hashes. Another thread would grab a previous
hash, perhaps a two day old hash and treat it as the new temporary
genesis hash. It would quickly verify the roughly 144 blocks, and verify
that the last hash matches the previous genesis hash. The second thread
would continue verifying previous blocks until it reached the real
genesis block, which I believe is defined within Bitcoin itself. As you
can see, blocks are always being verified in forward direction, but the
beginning point is just pushed back until it reaches the real beginning.
There could even be a third thread which would start at the real genesis
hash and verify blocks from there so that they meet in the middle. All
three of those threads could be grouped into another thread which would
be run for each different chain of blocks which it is told about from
other Bitcoin peers. If more than one chain is verified as authentic,
Bitcoin would calculate and compare the total amount of computing power
required to create the chain and keep only the strongest chain. Off the
top of my head, an easy way to calculate the strongest chain, would be
to find the largest sum of the inverses of the numeric value of each
hash.
Satoshi Nakamoto
May 26, 2010, 08:34:34 PM
It does in fact download 500 blocks at a time, then the counter
counts one at a time as it verifies the blocks.
The advantage of letting bitcoin download and verify the blocks is
that you do not have to trust the person you're downloading them from.
If you downloaded the blk*.dat files from some site, you
would have to trust that site, since you would be accepting the data
without verifying it yourself. If you're copying blk*.dat
from another computer of yours, that should be fine.
How long is the initial block download taking for you?
Share database of Bitcoin blocks ?
2010 May 24 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
I have a question.
I saw that everyone need to get blocks before starting to get coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks somewhere on the official website?
Well, what if the main website gets hacked and the blocks you are downloading are not the original blocks?
I mean, this makes the network a hell of a lot of insecure.
I think that probably they won't be accepted by the majority of the network, that they have a different database/hash ... is it right?
I'll defer to others on whether having a central database is a good idea, but if you're creating multiple directories with the -datadir command line option, you can safely bootstrap that directory by copying "blkindex.dat" and "blk0001.dat" from an already established data directory into your new one.
While a central database, or at least a partially-completed centralized copy of a certain number of blocks would speed things up, but then, so would mass-transfer between clients (requests for 500 blocks or so instead of one blocks at a time) and the latter would implement it within the confines of the network, without needing web hosting for a copy of the block database.
Currently, I believe one could grab a copy of someone else's blk*.dat files and speed the process up that way, but it really shouldn't be needed when the same thing can be done with a few snippets of code.
A draft standard for the bitcoin wire protocol would possibly be a help here, in that it would be possible for someone C++-illiterate to see what actually is possible in the current system ;-)
EDIT: if I understand correctly, a complete false start that wouldn't disappear as soon as a client connected to the network at large would require generating as many blocks as were currently in the network, so, one individual would have to generate 57525 blocks to do major harm to the network.
It could give someone a head start in forging a block, but not really. Having a rouge starter set of blocks would be just like having each new node started from that set of blocks be a rouge node, so it should be similarly impractical to forge anything.
Most of the slowness results from the blocks needing to be verified one at a time in order, not from network delays. At least according to, if I'm not mistaken, satoshi, the Bitcoin author, in another thread. There has been some talk about a lightweight client, which doesn't verify all the blocks, but instead only broadcasts transactions. I'm not familiar with the algorithm, but if it's possible, I think it would be best to just alter the regular client so that when it starts up the first time, it grabs the most current block and verifies blocks in reverse order while also continuing to verify new blocks. That way Bitcoin could start generating blocks immediately.
Good idea, but we would need some form of indicator it did that to the user, and warn the user about the potential hazards.
(Atleast, that's my idea.)
It only verifies the last few as it is, to speed things up, but it doesn't work backwards.
Satoshi has mentioned a simplified payment verification system that he is planning to implement, which would allow payment only clients which do not have to verify all the blocks - he just hasn't written it yet.
I think even if you could just have someone ‘click here to install instantly' it wouldn't do any good because they wouldn't have any bitcoins and they wouldn't know what a bitcoin is
Although I'm not familiar with the specifics of the algorithm implementation in C++, I am familiar with how the verification works in general. Although the algorithm would have to be re-written, it really should be possible to verify blocks in both directions at the same time. Each block contains the hash of the previous block, but the first block contains a genesis hash, which isn't the hash of a previous block. The first time bitcoins starts, it would treat a recent hash, perhaps a one day old hash as a temporary genesis hash and quickly verify the roughly 144 blocks up to the most recent block and it would continue to verify and optionally generate new hashes. Another thread would grab a previous hash, perhaps a two day old hash and treat it as the new temporary genesis hash. It would quickly verify the roughly 144 blocks, and verify that the last hash matches the previous genesis hash. The second thread would continue verifying previous blocks until it reached the real genesis block, which I believe is defined within Bitcoin itself. As you can see, blocks are always being verified in forward direction, but the beginning point is just pushed back until it reaches the real beginning. There could even be a third thread which would start at the real genesis hash and verify blocks from there so that they meet in the middle. All three of those threads could be grouped into another thread which would be run for each different chain of blocks which it is told about from other Bitcoin peers. If more than one chain is verified as authentic, Bitcoin would calculate and compare the total amount of computing power required to create the chain and keep only the strongest chain. Off the top of my head, an easy way to calculate the strongest chain, would be to find the largest sum of the inverses of the numeric value of each hash.
It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.
The advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you're downloading them from. If you downloaded the
blk*.datfiles from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself. If you're copyingblk*.datfrom another computer of yours, that should be fine.How long is the initial block download taking for you?