Why is OpenSSL needed in the official client?

[Pieter Wuille]

Pieter knows moe about this. Basically OpenSSL has the uncompressed and compressed ECDSA public key formats which are defined in the SEC standards but it also has a hybrid format. http://openssl.sourcearchive.com/documentation/1.0.0e-3/crypto_2ec_2ec_8h_aa2c7ec2902c397d59393d357921e14b5.html Literally that is all the documentation gives you. I have no idea where Pieter Wuille learned all this stuff.

Right. SEC defines the compressed (0x02/0x03 + 32-byte X coordinate) and uncompressed (0x04 + 32-byte X coordinate + 32-byte Y coordinate) formats, but doesn't specify the hybrid format (0x06/0x07 + 32-byte X coordinate + 32-byte Y coordinate). From that link, it seems that the hybrid format may have been specified by that ANSI X9.62, but I won't spend $100 to buy the standard...

Anyway, it's that hybrid format that's bothersome. Making an implementation support it is trivial though - just change the 0x06 or 0x07 byte to a 0x04 and pass it that way to the crypto library.

I just learnt this from the OpenSSL source code, and the SEC document (see the secg site).

[2112]

Why not sqlite for the wallet (and maybe the blockchain) ?

In my opinion, even sqlite is overkill for the wallet. It's yet another dependency (something you don't like, right?), and all we need is a simple key-value store that is read at startup and loaded into memory. Probably we'll move to a very simple custom append-only format with checksums.

For the blockchain: performance. LevelDB is exactly what we need: not more than a key-value store with atomic writes, with very good performance and consistency.

It seems like almost every technical thread about bitcoin{d,-qt} needs to take a detour into the DB-land.

I just wanted to stress that the "append-only" is the key concept to understand what is required architecturally to implement Bitcoin efficiently. Incidentally it is also a key ingredient to make any Bitcoin implementation GAAP-compliant.

It is alway scary experience to post here a link to some Microsoft's web property. But this thread already has at least 2 posters who aren't scared of MSFT, so here it goes:

http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx

LevelDB unfortunately will not be "exactly what we need" unless a significant reachitecturing is undertaken.

Mike Hearn had explained this succintly. I'll find the link and post it here.

https://bitcointalk.org/index.php?topic=94453.msg1048149#msg1048149

Gavin Andressen had estimated that the rearchitecturing of storage layer could take up to 3 years anywhere from 1 to 3 years while seriously impacting other intended deliverables. Again I'll find the link and post it here.

https://bitcointalk.org/index.php?topic=101011.msg1170970#msg1170970

[wumpus]

As far as I know it is not possible to compile a Qt application using the Visual Studio IDE, you need their preprocessing junk to make sense of "slots" and "signals" keywords.

That's simply false.

Keywords such as "slots:" are defined away with a macro when compiling the actual code. There is no specific preprocessor for Qt (there is the "moc" compiler, but it adds class introspection information and such that is linked as a separate file, it does not transform source code).

I have compiled Bitcoin-Qt with visual studio 2010 express. I have no time to maintain a parallel build system though, mingw works perfectly for our purposes.  I'm using Qt Creator as IDE, which is similar enough to VS but without need to buy an expensive license after 30 days.

But if you'd like to maintain a VS build system I can send you what I have.

BTW@ 2112 you can use bitcoin with leveldb right now if you want. See pull request https://github.com/bitcoin/bitcoin/pull/1677

[Pieter Wuille]

It seems like almost every technical thread about bitcoin{d,-qt} needs to take a detour into the DB-land.

Not too surprising, it's one hell of a weakness right now. BDB is just not the right fit for how we use it.

I just wanted to stress that the "append-only" is the key concept to understand what is required architecturally to implement Bitcoin efficiently. Incidentally it is also a key ingredient to make any Bitcoin implementation GAAP-compliant.

I was talking about the storage system, not wallet semantics (which is what you want changed to conform to those rules). Even if we move to an append-only wallet file, that doesn't mean anything will observably change.

LevelDB unfortunately will not be "exactly what we need" unless a significant reachitecturing is undertaken.

Mike Hearn had explained this succintly. I'll find the link and post it here.

Mike Hearn also implemented a first Bitcoin-on-LevelDB port himself (see pull request 1619), which was abandoned after I modified it to work on top of my rewrite of the validation engine (see pull request 1677).

The problem you probably were referring to is the fact that Bitcoin relied on reading uncommitted data during block validation, something that isn't supported by LevelDB (it just has atomic writes, no real database transactionality). Mike solved that in his port by writing a tiny caching layer around LevelDB. I solved it by avoiding the need for such operations altogether, with a nice performance improvement along the way.

Gavin Andressen had estimated that the rearchitecturing of storage layer could take up to 3 years anywhere from 1 to 3 years while seriously impacting other intended deliverables. Again I'll find the link and post it here.

https://bitcointalk.org/index.php?topic=101011.msg1170970#msg1170970

He wasn't talking about the storage layer. He was referring to your request for changing the wallet semantics. I disagree that it would take that long, by the way, but I disagree it's within our scope right now. There are enough alternative wallets already, those are in a perfect place to experiment with different types of wallets.

By the way, changing the wallet storage (but just that) to use an append-only format is also already implemented (by me), but it had some issues left, and I felt other things were more important to work on.

[CIYAM]

Bite the bullet, leave your ivory tower and its comfy silk cushions and get back
to the real world. You might have to drop the snazzy VC++ auto-complete, but
you'll just become a better coder for it.

Actually ever since Herb Sutter joined MS their compiler has been extremely standards compliant (although you do have to flick some compiler switches to get it to adhere correctly).

I don't actually use the IDE myself (being a console guy). The only big problem with not doing that is the lack of auto-dependencies (at least in the free version) although it isn't really that hard to construct your own make system (which I did for my own project) and there are other free ones out there.

[misterbigg]

Thanks to everyone for their informative replies, this has provided useful insights into some of the thinking that goes on in the development process.