On Mon, 10 Jan 2011 16:13:13 +0100, Jonas Smedegaard <dr@jones.dk> wrote: > On Mon, Jan 10, 2011 at 09:48:06AM -0500, micah anderson wrote: > >On Mon, 10 Jan 2011 09:46:29 +0100, Jonas Smedegaard <dr@jones.dk> > >wrote: > >> On Mon, Jan 10, 2011 at 12:54:58AM -0500, micah anderson wrote: > >> >On Fri, 7 Jan 2011 20:17:29 +0100, Jonas Smedegaard <dr@jones.dk> > >> >wrote: > >> >> So what really is the issue here is that _at_ _each_ _runtime_ > >> >> _environment_ are the db files incompatible. > >> > > >> >http://download.oracle.com/docs/cd/E17276_01/html/programmer_reference/changelog_4_8.html#id1655659 > >> > > >> >Database or Log File On-Disk Format Changes: > >> > > >> > 1. The log file format changed in 4.8. > >> > > >> >So it seems that its just the db4.8 logs are not backward compatible > >> >with 4.7. Transaction logs are great, if you want to do recovery, > >> >but I wonder if they are really needed. If I recall, they simply > >> >grow, until you rotate them, unless you set specific DB_CONFIG > >> >flags. > >> > >> According to Helmut Grohne, all Bitcoin users maintain a full history > >> of transactions in those logs - so I suspect they shouldn't be > >> rotated but just (slowly) grow and grow... > > > >Well sure, that is because they are transaction logs and every database > >operation is written to the logs. That is the definition of database > >transaction logs... it is nothing particularly unique to bitcoin. > >Berkeley DB (and other databases, when configured to do so) produces > >transaction logs that can be used to reconstruct changes from a given > >point in time. > > You wrote "wonder if they are really needed." > > What I meant to say was that according to Helmut Grohne, each and every > Bitcoin user _must_ maintain a full history. Yep, that is true. > >It is true that bitcoin maintains a full history of all bitcoin > >operations (if I used the word 'transactions' here, it would be > >confusing because 'transactions' as also a database term, that history > >is maintained in the database itself. > > So, what was the point again? That the storage format need not be in > log format? The storage format is the database. The logs are database transaction logs. You get those transaction logs with *every* berkeley db implementation with every software that uses them. In fact, I dont know a database implementation that doesn't have transaction log capability (http://en.wikipedia.org/wiki/Transaction_log). A database transaction log (also commonly called a binary log) is just a record of every operation that has happened on the database. They are not unique to bitcoin at all. Database transaction logs are there in the case of crash, you can do a restore by replaying the logs. Bitcoin stores inside the *database* the entire history of all bitcoin operations. The fact that database transaction logs are on just means that the entire history of all database operations, (which, incidentally aren't exclusively bitcoin trades between users), is also written to the transaction logs. > As I understand it, the log format is used only when bootstrapping via > IRC, but I really don't know these details. No, the database transaction logs are a property of databases, and are not unique to bitcoin at all. The bootstrap via IRC basically does this: 1. uses a hard-coded address in the source to connect 2. gets p2p info and blocks from other nodes on irc 3. writes the acquired info into the database It just so happens that the way database writes are done is by doing this: a. writing to the database log file what exactly is going to be written to the disk, once that has been committed to hard storage it then... b. does the database operation databases do this because if there is a crash, the database may not have properly flushed to the disk 30 different database operations, so they never were written... but there is storage of the log which has all the changes that should be there, so those are replayed. as that wikipedia page says: If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions. > Helmut Grohne seemed to know - he mentioned having reverse-engineerd the > protocol and reimplemented in Python. I tried to persuade hime to join > me in maintaining Bitcoin - until his own implementation perhaps would > eventually mature and be superior. No luck, unfortunately. :-( haha, awesome, would be nice to have it in python.
Attachment:
pgpDJbYb9i2Dj.pgp
Description: PGP signature