Bitcoin Forum
May 19, 2019, 07:39:36 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 »
261  Bitcoin / Development & Technical Discussion / Re: Bitcoin x86 for Windows on: July 27, 2010, 07:47:42 PM
OK, thanks.  I'd also like to know if it runs fine as long as you don't turn on Generate.  You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load.  At least Pentium 3's could run it without generating.
262  Bitcoin / Development & Technical Discussion / Re: Bitcoin x86 for Windows on: July 27, 2010, 06:27:30 PM
I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin.  This is the fastest SHA256 yet using the SSE2 assembly code.  Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.

I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.
I added a subset of the Crypto++ 5.6.0 library to the SVN.  I stripped it down to just SHA and 11 general dependency files.  There shouldn't be any other crypto in there other than SHA.

I aligned the data fields and it worked.  The ASM SHA-256 is about 48% faster.  The combined speedup is about 2.5x faster than version 0.3.3.

I guess it's using SSE2.  It automatically sets its build configuration at compile time based on the compiler environment.

It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available.  I want the release builds to have SSE2.  SSE2 has been around since the first Pentium 4.  A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.

This is SVN rev 114.
263  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: July 27, 2010, 03:04:58 AM
New difficulty factor 244.213223092
+35%

I updated the first post.

date, difficulty factor, % change
2009          1.00
30/12/2009    1.18   +18%
11/01/2010    1.31   +11%
25/01/2010    1.34    +2%
04/02/2010    1.82   +36%
14/02/2010    2.53   +39%
24/02/2010    3.78   +49%
08/03/2010    4.53   +20%
21/03/2010    4.57    +9%
01/04/2010    6.09   +33%
12/04/2010    7.82   +28%
21/04/2010   11.46   +47%
04/05/2010   12.85   +12%
19/05/2010   11.85    -8%
29/05/2010   16.62   +40%
11/06/2010   17.38    +5%
24/06/2010   19.41   +12%
06/07/2010   23.50   +21%
13/07/2010   45.38   +93%
16/07/2010  181.54  +300%
27/07/2010  244.21   +35%
264  Bitcoin / Development & Technical Discussion / Re: Bitcoin x86 for Windows on: July 27, 2010, 01:29:42 AM
Crypto++ 5.6.0: http://www.cryptopp.com/
Cached SHA256: http://pastebin.com/rJAYZJ32 (although I'm pretty sure this is publically submitted elsewhere, I was linked to it on IRC)
I added the cached SHA256 state idea to the SVN, rev 113.  The speedup is about 70%.  I credited it to tcatm based on your post in the x64 thread.

I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes.  It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++.  Does it only work with the MSVC and Intel compilers?
265  Bitcoin / Development & Technical Discussion / Re: Bitcoin x64 for Windows on: July 26, 2010, 06:41:31 PM
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.

Performance: 4700khash/s on 4 cores, I think that speaks for itself.

I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Is that still starting from Crypto++?  Lets get this into the main sourcecode.
266  Bitcoin / Development & Technical Discussion / bitcoind without wxWidgets on: July 26, 2010, 05:23:33 PM
I replaced the last of the few wxBase dependencies in bitcoind.

bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.

main(int argc, char* argv[]) is added to init.cpp.  CMyApp and the Startup folder stuff are moved to ui.cpp.  ui.cpp and uibase.cpp aren't linked by bitcoind.

The makefiles have -DGUI to control whether the GUI is used.

I test compiled MinGW, VC and Ubuntu.  I don't know if I broke the Mac OSX build, someone will need to check that.
267  Bitcoin / Development & Technical Discussion / Re: Stealing Coins on: July 25, 2010, 10:27:36 PM
Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA.  I shouldn't have said "prime numbers".  ECDSA doesn't take much time to generate a keypair.
268  Bitcoin / Bitcoin Technical Support / Re: md5? on: July 25, 2010, 10:06:57 PM
For future reference, here's my public key.  It's the same one that's been there since the bitcoin.org site first went up in 2008.  Grab it now in case you need it later.

http://www.bitcoin.org/Satoshi_Nakamoto.asc
269  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 25, 2010, 09:51:31 PM
Great catch!  Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
SVN rev 111
270  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 25, 2010, 09:44:16 PM
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
That's strange, didn't someone just say that was supposed to work?  (what library was he using?)  Post if you figure out what wrong.

I hope it's not going to put up this much of a fight for all PHP users.

Looks like we've got the Fortran scenario already.
271  Bitcoin / Development & Technical Discussion / Re: JSON-RPC password on: July 25, 2010, 09:34:29 PM
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
Code:
...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients.

This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:
Code:
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
+1 to you for having such a long password that you found this bug.

Uploaded to SVN as rev 110.
272  Bitcoin / Development & Technical Discussion / Re: Stealing Coins on: July 25, 2010, 08:48:01 PM
Quote
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
2^80 is if you can use a birthday attack.  You can't use a birthday attack for this, so the difficulty is the full 2^160 bits.  Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.

Bitcoin Addresses are the only place where 160-bit hash is used.  Everything else is SHA-256.  They're calculated as:

bitcoinaddress = RIPEMD-160(SHA-256(publickey))

Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case.  An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision.  Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256.  If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it?  You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.

For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone.  But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256.  If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.
273  Bitcoin / Development & Technical Discussion / Re: Stealing Coins on: July 25, 2010, 08:01:40 PM
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.

But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.
You would still have to sign it with public key 654321.  You need to find a collision using a public key for which you know the private key.

When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.

Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.

He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone.  Someone trying to brute force would have to take time generating a key for each attempt.
274  Bitcoin / Development & Technical Discussion / Re: Stealing Coins on: July 25, 2010, 07:06:23 PM
Red, thanks for telling me privately first!  Please go ahead and post it (and relieve the suspense for everyone!)

His point is that transactions paid to a Bitcoin Address are only as secure as the hash function.  To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself.  An attacker would only have to break the hash function, not ECDSA.
275  Bitcoin / Development & Technical Discussion / Re: Stealing Coins on: July 25, 2010, 05:45:22 PM
It's best if you tell it to me privately so it can be fixed first.

I just e-mailed you my e-mail address.  (or you could PM me here)
276  Bitcoin / Bitcoin Discussion / Bitcoin 0.3.3 released -- PLEASE UPGRADE on: July 25, 2010, 04:55:09 PM
Please upgrade to 0.3.3!  Important security improvements were made in 0.3.2 and 0.3.3.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
277  Bitcoin / Development & Technical Discussion / Re: a simple traffic load test run on: July 25, 2010, 03:29:52 PM
Please do these tests on the test network.  That's what it's for.  Thanks.
278  Bitcoin / Development & Technical Discussion / Re: a simple traffic load test run on: July 25, 2010, 02:46:33 PM
Was that on the test network?
http://bitcointalk.org/index.php?topic=363.0
279  Bitcoin / Development & Technical Discussion / Re: Reading/Writing Blocks and FLATDATA on: July 24, 2010, 04:04:20 AM
FLATDATA was a workaround to serialize a fixed field length array.  There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time.  We don't support MSVC6 anymore because we use something in Boost that doesn't.  We lost support for it after 0.2.0.  Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
280  Bitcoin / Bitcoin Discussion / Version 0.3.2.5 -- please test! on: July 24, 2010, 03:32:52 AM
Please test 0.3.2.5 in preparation for the 0.3.3 release!  This build is looking good and should be the one that goes into 0.3.3.  I encourage you to go ahead and upgrade now if you're on Windows or Linux.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes

Download here:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

Thanks!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 »
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!