Bitcoin Forum
July 19, 2019, 01:45:26 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: Why is OpenSSL needed in the official client?  (Read 3826 times)
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1064
Merit: 1036


View Profile WWW
September 29, 2012, 09:16:23 PM
 #61

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).

I do Bitcoin stuff.
1563543926
Hero Member
*
Offline Offline

Posts: 1563543926

View Profile Personal Message (Offline)

Ignore
1563543926
Reply with quote  #2

1563543926
Report to moderator
1563543926
Hero Member
*
Offline Offline

Posts: 1563543926

View Profile Personal Message (Offline)

Ignore
1563543926
Reply with quote  #2

1563543926
Report to moderator
1563543926
Hero Member
*
Offline Offline

Posts: 1563543926

View Profile Personal Message (Offline)

Ignore
1563543926
Reply with quote  #2

1563543926
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
September 30, 2012, 12:35:13 AM
Last edit: September 30, 2012, 12:56:43 AM by 2112
 #62

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

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1000

No Maps for These Territories


View Profile
September 30, 2012, 08:44:26 AM
Last edit: September 30, 2012, 01:04:48 PM by John Smith
 #63

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

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1064
Merit: 1036


View Profile WWW
September 30, 2012, 11:08:43 AM
 #64

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.

Quote
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.

Quote
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.

Quote
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.

I do Bitcoin stuff.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
September 30, 2012, 12:42:04 PM
 #65

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
misterbigg
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001



View Profile
September 30, 2012, 05:10:26 PM
 #66

Thanks to everyone for their informative replies, this has provided useful insights into some of the thinking that goes on in the development process.
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!