fuck you wallet format!!!! (RANT)

[kokjo]

i have one question in mind right now: "WHY??"
WHY have you designed the wallet format this way it sucks!
you are even using dbname/tables but you only have one table in wallet.dat(the "main" table), BUT you are using it incorrectly.
im right not reading this code:
https://github.com/joric/pywallet/blob/master/pywallet.py#L1283

WHY have you not put the each type, in each separate table? i don't get it! its a mess.
a table for settings, one for keys, one for accounts, ...
and i see you are using public keys, as a database key why not use the hash/address, as a key to both the publickey and privatekey?

what is the benefit, of this madness? the dude that came up this db scheme, is a bad database coder.


/rant over

[1714047620]

1714047620

[check_status]

Is it insecure, slow, poorly arranged code?
If it's python, can't you modify it and use your own improvements? Submit your improvements to joric?

[kokjo]

Is it insecure, slow, poorly arranged code?
If it's python, can't you modify it and use your own improvements? Submit your improvements to joric?

it's not the code, its the structure of the wallet database. The code looks fine, I would have wrote it in another way, but that's irrelevant.

[casascius]

I think the fact that it is a database in the first place is a silly design decision.

[Pieter Wuille]

I believe the reason for only using one table is the result of the glue layer on top of BDB (which I suppose was designed by Satoshi). This way, only one open database object needs to be kept around per file. It's an ugly system, but it seems reasonable at least. As far as I know, Satoshi didn't really like the idea of alternate clients, so I don't think he designed with ease of interoperability in mind. Once that layer was in place, it was probably all to easy to add fields to (mostly) the wallet for various pieces of data (and I did so as well, later on...).

Regarding the choice for BDB in the first place: it makes sense for the transaction/block index database. These are large, need frequent updates and queries, and need a high degree of transaction atomicity. For wallets and IP addresses, I believe better solutions are possible. Both are only read at startup, and subsequently updated but mostly appended to. I hope we can move to a better format (especially for the wallet) soon. One that isn't prone to corruption under flaky hardware (perhaps by only appending to it, and occassionally rewriting it), isn't linked to a fixed database environment directory, and is backward compatible...

[kwukduck]

I think the fact that it is a database in the first place is a silly design decision.

^^ this

[DeathAndTaxes]

I don't think it being a database is a silly idea (maybe that is because I work w/ db everyday).  More applications that you think use databases internally.  Any mission critical I/O is going to need support for:

atomic transactions
read/write verification
high level of availability
dataloss recovery
backups

Once you implement all that you just built a good chunk of the "plumping" that makes a database and likely it isn't as good as databases which have tens of thousands of hours of development already.

Still the "db" as used by the wallet is horrible.  It really isn't a database.  More like a loosely typed flat file stuffed inside a database.  So you get all the disadvantages of flat files combined with all the complexity and disadvantages of a database.   Then it is compounded with the "weird" choice of Berkeley DB over SQL Lite.  Anyone have insight into that decision or was it simply a case of "using what you know"?

Having everything stored as varchar and recorded as a set of type, key, value is ..... yuck.

@Peter:
I never realized Satoshi didn't appreciate the need for alt clients.  Strange he saw the danger of centralization everywhere else but didn't notice the danger that centralization of development would bring.    Honestly IMHO even the term "alt client" is dangerous.  Hopefully in time Bitcoin will be evolve to a point where there are simply compatible clients and the project (under whichever name is evolves to) which began as the Satoshi client is just one of many peers.

[randomproof]

You would think that the wallet only stored the public/private key pairs.  In that case it could have been a flat file.  But it seems that all transaction history is stored in there, too, which is what is really complicating things.  The issue I see is that there are so many files in the data directory.  I've read somewhere that this version of bitcoin was not intended to take off, so maybe that's part of the reason.  I'd suggest using an SQL database of the blockchain which would make the job of pruning unneeded data (redeemed transactions) easier, then you could execute some simple SQL statements and get address balances and transaction details.  You could also build in most of blockexplorer.com into the client.

[casascius]

Any mission critical I/O is going to need support for:

atomic transactions
read/write verification
high level of availability
dataloss recovery
backups

These benefits have not been brought to Bitcoin by the choice of using a database to hold the wallet.  While I agree that a real database system should be used for a mission critical database, I don't regard a bitcoin wallet as a database.  I see it as a document, like an excel spreadsheet.  Using a database engine for a bitcoin wallet to me is as ridiculous as using a power drill screwdriver to take apart a pocket watch.

In my view, the wallet (containing keypairs) should totally be separate from the file that contains the transaction history.  You don't use your real wallet to keep all of your receipts for everything you bought since you were twelve, neither should Bitcoin do the same.

Atomic transactions: The wallet should be nothing more than a repository of keypairs, so the only transaction that should ever need to take place is the occasional topping up of the keypool, and perhaps saving labels attached to addresses.  (For example, a keypool created with 500 keypairs, and topped back up to 500 when the reserve reaches 100, would make transactions and/or modification of the wallet happen so rarely that it would hardly be inefficient to achieve atomicity simply by writing a brand new file, swapping it with the old one via renaming, and then deleting the old one, as though it were a document.

Read/write verification: Nothing unique to a database - if verification is needed, this is easy to code in the client.  Write file, close file, read file, verify file (or hash).

High level of availability:  How does bdb increase availability as compared to say a flat xml file?  If anything, it has hindered it, judging by the number of people who have gotten "critical DB errors" and lost access to their wallet.

Data loss recovery:  If anything, people have lost more wallets as a result of bdb than have ever gained from it.  At least with XML you can manually hack together in a text editor.  bdb, no way.

Backups: Another place where bdb has offered no benefit, and the unusual placement (especially on Windows clients, as compared to the typical Windows user) has made backups difficult for the average user.  Rather, the client should treat a wallet like a document, the same way Microsoft Word treats a .doc file as a document, where a user can back it up the same way they'd back up a letter, such as by clicking File - Save As - and then choosing removable media as the destination for the file, or by dragging a copy out of their Documents folder and onto their flash drive etc.

[Pieter Wuille]

I think you're preaching to the choir. I don't think many people consider bdb for the wallet a good idea. I've already experimented with an own format to function as drop-in replacement for the database file. It doesn't look too hard, but obviously compatibility issues will complicate things.

[casascius]

You know what would be really nice down the road is if the database layer was abstracted in a way that allowed someone to use their own SQL server as the data store for the block chain, but defaulted to something statically linked for the sake of slimness for those who won't use this feature.  Likewise, the "in-memory transaction pool" also ought to be maintained as a database table.  This would help with the development of other applications (like payment processing, shopping carts) without requiring them to hack or tangle with bitcoind.  Likewise, I'm sure someone else has thought of this first.

[Mike Hearn]

I don't understand the request to have wallets not contain transactions. You need transactions to create spends, which is what a wallet is for.

Satoshis wallet design was clearly built with lightweight/SPV mode in mind, though the rest of it was never fully implemented. In that design you MUST store the transactions that are relevant to the keys in your wallet.

[casascius]

I don't understand the request to have wallets not contain transactions. You need transactions to create spends, which is what a wallet is for.

Satoshis wallet design was clearly built with lightweight/SPV mode in mind, though the rest of it was never fully implemented. In that design you MUST store the transactions that are relevant to the keys in your wallet.

In my mind, that need should be accommodated by the client maintaining an index that allows a rapid lookup of all of the transactions that are associated with any given hash160, directly from the block chain... the same way it already maintains an index of all unspent transactions.

If it worked this way, then it would be trivial for a user to close one wallet (File - Close) and open another (File - Open), the same way I might close one spreadsheet and open another.  And commands like importprivkey would run rather instantly (or O(log n) to be specific).

Right now, the idea that one must perform a lengthy "rescan" to switch to another wallet defies all common sense from the perspective of a typical user, and adds no useful benefit (except perhaps the non-consumption of the disk space that such an index would require).

That index, by the way, doesn't have to be exhaustive to be effective... a hashtable index that had just 32 bits of key and 32 bits of block reference (at the expense of collisions causing occasional unnecessary reads of blocks) would still be highly useful for finding all relevant transactions given a set of addresses in a reasonable timeframe without being unduly large.

[Pieter Wuille]

That requires the full blockchain (which is something that will get removed further and further from wallets in the future, imho), plus an extra additional index on top of it. Furthermore it misses any ability to store local data (address labels, accounts, comments, ...).

I believe what you are looking for is Electrum or another lightweight client, which keeps all that data and I assume fast rescan ability on a server.

I agree with you that we shouldn't need a lengthy rescan to switch wallets (afaik, we don't, but switching is far from how easy it should be), but the solution is adding multiple wallet support to the client. Using the blockchain as your transaction store may sound fun, but I don't think it's a viable end-user way of working in the future.

[casascius]

That requires the full blockchain (which is something that will get removed further and further from wallets in the future, imho), plus an extra additional index on top of it. Furthermore it misses any ability to store local data (address labels, accounts, comments, ...).

I am not sure I see it the same way.

I have proposed building an index on a set of data (the block chain) which is data maintained by the client, separate from the wallet.  The fact that down the road, that set of data maintained by bitcoind may be reduced (a partial block chain) has nothing to do with whether an index can be built upon it.  Especially when the index is only going to be referencing the portion of the block chain that will be kept not discarded.

Importantly, a properly implemented index can always be thrown away and rebuilt, so if you ever change your mind in the future as to what the index should look like, or will be making a major change to how much or how the blockchain data is kept, the new client version can simply dump the index and rebuild it upon installation.

Local data like address labels, accounts, and comments are fair game for the wallet file (the same way that if I yellow-highlighted cells in Excel, that that highlighting would be persisted in my .xls file when I went to save it).  They are the user's data, which is what a typical user would expect to be saved in a user file.

I believe what you are looking for is Electrum or another lightweight client, which keeps all that data and I assume fast rescan ability on a server.

Actually, given that I have no real unmet needs for the way I transact, I am not really looking for anything, other than to bridge the gap between the mindset of the developers and the mindset of the average user that will be downloading the client.  This way, new users have a greater likelihood of saying "Aha this is what I was looking for", rather than "WTF I don't understand".

[MatthewLM]

What do people think about other wallet formats?

[Pieter Wuille]

I believe what you are looking for is Electrum or another lightweight client, which keeps all that data and I assume fast rescan ability on a server.

Actually, given that I have no real unmet needs for the way I transact, I am not really looking for anything, other than to bridge the gap between the mindset of the developers and the mindset of the average user that will be downloading the client.  This way, new users have a greater likelihood of saying "Aha this is what I was looking for", rather than "WTF I don't understand".

Let me try to formulate things differently. I'm only talking about the Bitcoin reference client (its wallet) being used by end users. Using address-to-block indexes in fat servers that serve many thin clients, is obviously a good idea.

But for an end user who is running the bitcoin software (for now with a full node, later perhaps in SPV mode when it is implemented), I see no reason to replace storing the transactions in the wallet by an on-the-fly scan through the block database (even with an extra index to speed it up). First of all, the endpoints (in particular the receiver) is ultimately responsible for having the transaction around: in case the transaction is not yet in the blockchain, sender and receiver of the transaction are those who will keep broadcasting them. In case of a reorganisation, a transaction may be lost and again the owners are responsible for keeping the transaction alive. Second, further developments with multisig transactions will require transactions being negotiated (which is non-trivial and requires many communication steps) before they can be published and mined into the chain.

It seems to me your largest issue is usability. And I agree, there are many improvements possible for the end-user using a local bitcoin wallet. But the solution is supporting multiple wallets, improve efficiency, improving the user interface, simplify saving and restoring backups (tagged with for example the first block that would need to be scanned for incoming transactions), .... Adding an extra index may be viable right now, but I can't believe that such a requirement will be necessary for how bitcoin wallets will be used in the future.

That said, I didn't say such an index is a bad idea - there are certainly uses (in particular when the nodes functions as a back-end for thin clients, or runs a large service). It's not a priority right now, but that can change. I just don't think it is the thing end users need now.

[casascius]

It seems to me your largest issue is usability. And I agree, there are many improvements possible for the end-user using a local bitcoin wallet. But the solution is supporting multiple wallets, improve efficiency, improving the user interface, simplify saving and restoring backups (tagged with for example the first block that would need to be scanned for incoming transactions), .... Adding an extra index may be viable right now, but I can't believe that such a requirement will be necessary for how bitcoin wallets will be used in the future.

Can I suggest that the ability to maintain, open, and close multiple wallets at will is a compelling benefit for a typical end user that would justify the index?  Also would be the ability to import or sweep funds from private keys in non-exponential time from handheld bitcoin cash.  I mean, that's a pretty huge benefit: I can hand someone bitcoins on a QR code, and they can scan and sweep the funds, either some or all of them.  End users can "be their own bank" by printing their own cash at home, and I can tell a restaurant (like Meze Grill in NYC who recently refused my bitcoins due to difficulty accepting them) that all they have to buy is a $250 USB QR code scanner, they can be accepting home-printed bitcoin cash with the official bitcoin client in no time.

If you give us this index with the official blessing of being a core feature, then others can add the rest of these features that depend on it so you don't have to be burdened with it.  Give us the framework, the infrastructure, and let others put in the effort of carrying it to the level of practical application.

[westkybitcoins]

I think the fact that it is a database in the first place is a silly design decision.

Yep.

[etotheipi]

What do people think about other wallet formats?

For reference, I went as far in the opposite direction as I could, when creating the Armory wallet format.  I hate the Satoshi wallet format as much as kokjo.  Armory uses a simple binary format, easy to read, and only two operations on it are ever used:  append, or overwrite-in-place-with-same-data-size.   I documented it here: 

http://bitcoinarmory.com/index.php/armory-wallet-files

I had two goals in mind when I made the wallet format:

• I want 100% control of what happens in the wallet file.  Inspired by the wallet-not-actually-encrypted bug in 0.4.0
• I want it to be dead simple for other developers to be able to read (and maybe modify) the wallet files

There's quite a bit of extra wallet-management code to protect against corruption & errors, and enforce atomic operations, but that's in code -- it doesn't affect the simplicity for other developers to read the files.    The most important feature is that when I encrypt my wallet, the encrypted key is guaranteed to overwrite the original unencrypted key, which prevents any leaks happening when I back it up to Dropbox, etc.  Same with deleting data:  it's overwritten with zeros in-place.  I know the overwrite may not happen in-place on-disk, but there's nothing I can do about that -- at least when someone copies the wallet file from my HDD, the binary file will not have any surprises in it.
[/list]