Connect with us

Satoshi Nakamoto

Bitcoin generation broken in 0.3.8? (64-bit)

I was starting to wonder when my systems seemed to quit generating coins if there was something going on.

Published

on

The following content was written by lfm on August 08, 2010, 03:06:59 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I was starting to wonder when my systems seemed to quit generating coins if there was something going on. They went from about 1 block / day to none in a week.

ArtForz in irc suggested I run a test isolated net with two nodes only connected to each other with empty wallet dir. I took a couple of quad core systems and set them up. they have produced no blocks in about 90 minutes now while hashing at a combined rate of over 8000 khash/sec. Is this evidence of a problem yet or is it more bad luck?

The systems are Linux 64 bit one Intel quad q6600 and one AMD quad phenom II 940.


The following content was written by FreeMoney on August 08, 2010, 03:09:03 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn’t mean much. I’m sure we’d know if 3.8 wasn’t generating any blocks.

The following content was written by lfm on August 08, 2010, 03:13:09 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn’t mean much. I’m sure we’d know if 3.8 wasn’t generating any blocks.


This is on an isolated test net with just two machines, connections = 1, difficulty = 1

The following content was written by lfm on August 08, 2010, 03:14:54 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn’t mean much. I’m sure we’d know if 3.8 wasn’t generating any blocks.

maybe only a problem with 64 bit linux or something


The following content was written by knightmb on August 08, 2010, 03:24:29 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I haven’t had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.

The following content was written by FreeMoney on August 08, 2010, 03:38:21 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn’t mean much. I’m sure we’d know if 3.8 wasn’t generating any blocks.


This is on an isolated test net with just two machines, connections = 1, difficulty = 1


Oh, that is odd then, that would be like not finding one in over 500 hours, possible I guess, but getting out there

The following content was written by lfm on August 08, 2010, 03:41:26 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I haven’t had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.

I guess I want to know how long I need to run 8000 khash/s at difficulty 1.0 to have any reasonable evidence of a problem. ArtForz said it should tell me in an hour or so.

The following content was written by ArtForz on August 08, 2010, 03:43:05 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


At ~ 8Mhash/s combined not generating a block at 1.0 diff in over 1h is pretty unlikely.
As in, under 0.1% probability unlikely (50% is ~6 min, 1% ~42 min)

Forgot to mention, he’s running a custom compile of stock 0.3.8 sources.

The following content was written by lfm on August 08, 2010, 03:58:09 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I haven’t had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.

I am wondering if its something odd in the way I have my systems set up or Huh just various plain ubuntu installs so far as I know.

The following content was written by lachesis on August 08, 2010, 05:05:04 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I’m having a similar problem with my own compile of the SVN trunk. I just reverted to the stock builds to test and see what happens. I should try setting up my own network of two nodes with my builds.

The following content was written by lfm on August 08, 2010, 07:18:55 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Ok chatting with lachesis in irc he tried this and I get the same result: We added some prints in main.cpp at the SHA calls like so :

Code:
       loop
        {
            SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
            printf(“mid hash =\n”);
            for (int i = 0; i < 8; i++)
              printf(” %08x”, ((unsigned *)&tmp.hash1)[i]);
            printf(“\n”);
            SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);
            printf(“full hash =\n”);
            for (int i = 0; i < 8; i++)
              printf(” %08x”, ((unsigned *)&hash)[i]);
            printf(“\n”);

            if (((unsigned short*)&hash)[14] == 0)

and then in the log we get:

mid hash =
 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
full hash =
 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
mid hash =
 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
full hash =
 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19

repeating! The hash call isn’t doing anything!
(he maybe got a different repeating value, I don’t know)

The following content was written by knightmb on August 08, 2010, 07:20:20 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


There is one behavior that I’ve noticed.

Block sync stalling.

When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block. The problem is, if you stop and restart the client, it just picks up where it left off on the same stuck block. The only way I’ve seen to fix this is to delete the block chain so that the client will re-download it.

I’ve had to clear out a few block chains for a few servers because of this, I’ll notice they are stuck on block 70,000 for example, while the rest of the network is working on block 70,839 for example.

That might explain why you go weeks without winning a block with a 24/7 PC going.

The server farm I had running before were spitting out blocks all day, but now that I’m just down to a few dozen servers and the difficulty is way up, I barely see about 3 or 4 blocks a day spread across all of them. But I know the 0.3.8 version is working like it should, except for the occasional block freeze.

The following content was written by lfm on August 08, 2010, 10:32:32 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


This seems to be a different problem. The blocks do not seem to be “stuck” on my systems. The getinfo shows them up to date

It seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others.

There is one behavior that I’ve noticed.

Block sync stalling.

When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.




The following content was written by tcatm on August 08, 2010, 11:56:54 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Did you compile it yourself? There’s a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.

The following content was written by lfm on August 08, 2010, 01:13:30 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Did you compile it yourself? There’s a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.

That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.


The following content was written by lachesis on August 08, 2010, 03:47:15 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.
That appears to fix it for me too.

EDIT:
I’ve uploaded corrected Linux builds to http://www.alloscomp.com/bitcoin/binaries/release-r123-2010-08-08/. Enjoy!

The following content was written by knightmb on August 08, 2010, 05:46:55 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Did you compile it yourself? There’s a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.

That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.

I just tested it out, I get the same results. Repeating values with stock, more random values with the flag modification. Probably needs to be fixed for the next release, though I’m not sure how mine are generating anything then?

The following content was written by nimnul on August 08, 2010, 05:50:10 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


@lachesis: 404 not found

@knightmb: What about a fixed CentOS build?

The following content was written by knightmb on August 08, 2010, 05:56:09 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


@lachesis: 404 not found

@knightmb: What about a fixed CentOS build?
Should be simple enough for CentOS, I was going to test it out first to see if those suffered the same issue, thought it seems like all the builds would suffer this issue if the compile flag is what makes the difference.

The following content was written by knightmb on August 08, 2010, 06:06:20 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


This seems to be a different problem. The blocks do not seem to be “stuck” on my systems. The getinfo shows them up to date

It seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others.

There is one behavior that I’ve noticed.

Block sync stalling.

When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.



I’m starting to wonder if the two are connected now since the hashing seems to get stuck, maybe that’s why it gets stuck on a block.

The following content was written by knightmb on August 08, 2010, 06:27:50 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what’s being produced, it’s the 64bit Linux machines (the 64bit windows machines don’t appear to have this problem) that aren’t producing any coin since the latest releases. All of the 32bit builds (stock or custom) appear to be just fine.

The following content was written by knightmb on August 08, 2010, 06:32:27 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Did you compile it yourself? There’s a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
This works for the 64bit builds, strange that it has no affect on the 32bit builds? Should it be disabled for 32bit builds as well?

The following content was written by tcatm on August 08, 2010, 06:49:15 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I don’t really know what it changes. I wonder why the define was made in the first place. The code should be able to determine whether it’s running on a SSE2 CPU or not. I discovered it while comparing my 4xSSE2 hash function to the original one in 0.3.6 so it really means, that no 64bit build since 0.3.6 was able to generate any coins. Maybe satoshi can tell us why he put the define in the makefile.

The following content was written by ArtForz on August 09, 2010, 12:31:45 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Just had a “fun” gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So… did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.

The following content was written by knightmb on August 09, 2010, 01:16:31 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Just had a “fun” gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So… did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.


Not on 64bit linux, just 32bit and 64bit everything else in between (Linux/Windows)

I didn’t notice until I checked the generation dates against the release dates of the software.

If you don’t strip the debug symbols the binary is 8 times it’s normal size.

The following content was written by lachesis on August 09, 2010, 02:05:51 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Just had a “fun” gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So… did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Nice work mate! Time to PM Satoshi.

Sent you ฿5.01 for your troubles.

The following content was written by lfm on August 09, 2010, 10:04:43 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


The 32 bit Linux build seems ok for those who don’t care to try to build it themselves. It’s only a few percent slower than the 64 when built right.

I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.

The following content was written by lachesis on August 09, 2010, 03:45:39 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Yet another argument for cmake or similar.

The following content was written by satoshi on August 09, 2010, 06:50:41 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I found that SSE2 only added a slight 2% speedup, which didn’t seem worth the incompatibility.  I was trying to take the safer option.

It doesn’t look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There’s one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can’t see how that would switch at runtime.  Maybe I’m not looking in the right place.

Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.

The following content was written by knightmb on August 09, 2010, 07:02:12 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I found that SSE2 only added a slight speedup, about 2%, which didn’t seem worth the incompatibility. 
I do the see point because a non-SSE2 machine, the client would crash?
Quote
It doesn’t look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There’s one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can’t see how that would switch at runtime.  Maybe I’m not looking in the right place.

Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.
Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn’t work for some reason.

I think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).

Have one branch of source that cross-compiles across multiple operating systems is always tricky business.  Grin

The following content was written by dkaparis on August 09, 2010, 07:31:37 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


Yet another argument for cmake or similar.

It’s a fact.

I intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.

On that note, I’m currently tackling x64 build for windows and notice that for 64-bit MSVC, the X86_SHA256_HashBlocks function is deferred to an external definition that is not present in the project. In the original CryptoPP library it seems to be in a separate asm module. I wonder how are people building x64 on windows, are they setting defines to use the C-source sha version?

The following content was written by satoshi on August 09, 2010, 08:34:06 PM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


I uploaded 0.3.8.1 for Linux with re-built 64-bit.  I ran a difficulty 1 test with it and it has generated blocks.

http://bitcointalk.org/index.php?topic=765.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

The following content was written by Ground Loop on August 10, 2010, 06:09:27 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate “difficulty 1” point-to-point test.  A “known good” hardcoded hash seed could make this better.

The following content was written by lfm on August 10, 2010, 06:56:27 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

here: 1HKXYYPCzQptzJsaq2nt8xUgsWNVFRfJWD
or here:  75.158.131.108

Quote
It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate “difficulty 1” point-to-point test.  A “known good” hardcoded hash seed could make this better.

Ya a couple “test vectors” at runtime might be nice but then again if they’re hacking they might hack out the test vectors cuz “they just slow ya down!” (logical or not)

If there was a well defined hook for the SHA variants it might make it less likely the test code would get hacked out. Not exactly sure how a hook should be designed to work for all the players out there. Stuff like GPU codes and SSE codes where several nonces might be tried in parallel need to be supported.


The following content was written by aceat64 on August 10, 2010, 07:42:32 AM in the thread bitcoin generation broken in 0.3.8? (64-bit). All content is owned by the author of the bitcointalk.org post. (original)


In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate “difficulty 1” point-to-point test.  A “known good” hardcoded hash seed could make this better.

ArtForz actually made a patch to check up on BitcoinMiner(), http://pastebin.com/YGUcqPYK

Editor-in-chief and serial coder & blogger.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Satoshi Nakamoto

Has someone made a “buy with bitcoins” button?

I mean an image. You know a nice one that people can put on their checkout webpages.

Published

on

The following content was written by mtgox on July 21, 2010, 08:48:44 PM in the thread Has someone made a “buy with bitcoins” button?. All content is owned by the author of the bitcointalk.org post. (original)


I mean an image. You know a nice one that people can put on their checkout webpages.

The following content was written by jgarzik on July 21, 2010, 09:01:11 PM in the thread Has someone made a “buy with bitcoins” button?. All content is owned by the author of the bitcointalk.org post. (original)


More than just an image…

Even though the bitcoin network itself handles fundamental transaction processing, web shopping carts will need additional amounts of payment processing to match purchases to incoming payments, be notified when a payment is processed (currently bitcoin purchase can take multiple hours to be confirmed), though order fulfillment and completion.

Even a simple “donate” button will require some sort of payment processing gadgetry a la Paypal’s web button engine, if you want people to provide names and/or messages along with their donation.

It’s tempting to code up a button engine myself, actually…

The following content was written by mtgox on July 21, 2010, 09:14:07 PM in the thread Has someone made a “buy with bitcoins” button?. All content is owned by the author of the bitcointalk.org post. (original)


Yeah I know. I’m 90% done with the code part of it. Just seeing if someone had already made a button image before breaking out photoshop.

So wait to code yours since hopefully you can just use mine 🙂
Continue Reading

Satoshi Nakamoto

On bitcoin generation, and bitcoin organizations

Bitcoin is a currency, literally, in its infancy. The concept is, as far as I know, the first of its kind.

Published

on

The following content was written by jgarzik on February 20, 2011, 06:44:53 AM in the thread Pros and cons of using new Bitcoin addresses for each transaction?. All content is owned by the author of the bitcointalk.org post. (original)


Can someone please give me a list of the pros and cons of using new Bitcoin addresses for each transaction? It seems very inconvenient to use a new address each time.

warning, I am a newbie…liked the videos presentations, did some research…and tried it.  Bitcoin.exe on an i7 –only application—24/7 x 10 days—on generate mode.  Only successful in the gratuitous .05 BTC from faucet per computer per public ip address.  I had plans to accept Bitcoins on all my websites…hired web developers  …faced ZERO SUPPORT ANYWHERE.

Bitcoin definitely needs to grow some organizations that can offer technical advice and software support for bitcoin itself.  Most major open source projects have one or more companies doing this.  That would help with bitcoin adoption, too.

Quote
So question number ONE.  What happens to the Bitcoin if I don’t use it, save it?  I speculate it ONLY serves to increase the value of those users and optimists who are “fan boys”.  I have spent too much time…wasting…which cost me more money than I could have possibly made  in two weeks.

Bitcoin is a currency, literally, in its infancy.  The concept (distributed notary service with digital signatures) is, as far as I know, the first of its kind.  It is still being “bootstrapped,” meaning that bitcoin does not have a self-supporting economy — which must, by its nature, encompass mundane things like buying gasoline with BTC, paying rent or mortgage with BTC, buying groceries with BTC.

So, what can you do with the bitcoins you have right now?  Not a lot, if you ignore bootstrapping services (services like currency exchanges or bitcointo.com).  Mostly software services like web hosting, and an odd assortment of tangible goods.

But it seems like most folks in the bitcoin community recognize that we just started construction of a very interesting and unique experiment in currency.  Any endeavour is, unfortunately, very high risk from an investment standpoint.  It might fail for dozens of reasons…  but wouldn’t be fun and interesting if it succeeded?

Quote
Question Number Two.  My PC’s were set up by my SYSADMIN’s.  After a few bouts of “actvity”….I ended up with 100% CPU on all cores…and the “connect” prompt  says unconnected.  Thats a lot of power and CPU cycles for Nothing…a big fat waste of time.  You want me to be impressed so we can get the concept moving?  Put up simple to understand “NOOB” isms…so that morons like myself…can learn HOW to connect.  If no connect…why the 100% CPU on all cores and NOTHING going on?  FOR DAYS?  I don’t have time for games.  When you guys are serious…I’ll be back.   I love all the concepts supporting it…but I will not GIVE AWAY valuable product from my websites for coins that have no value TO ME.

Step 1: Turn off “Generate coins” option.  It is a waste of time and electricity.

Step 2: Wait for all the blocks to download.  As of this writing, there are 109245 of them.

Step 3: Don’t panic, and read the forums.  If you can post specific problems you are seeing after following steps #1 and #2, you can get answers.

Step 4: Hire better SYSADMIN’s.  They should be able to answer these basic questions and offer basic support, or not install software that neither you or they understand.


Continue Reading

Satoshi Nakamoto

How many bitcoin addresses exist?

The larger the hash160 is, the more base58 characters required to represent its address.

Published

on

The following content was written by davux on November 10, 2010, 10:21:15 PM in the thread Pros and cons of using new Bitcoin addresses for each transaction?. All content is owned by the author of the bitcointalk.org post. (original)


It’s not. It’s 62^33, which is slightly over 10^59.
How did you arrive to this result?

An address has 33 significant characters, each of which has 62 possible values (10 numbers, 26 uppercase letters, 26 lowercase).
So you have 62 * 62 * … * 62 possibilities (33 times).

Actually, now that I remember, it’s 58 (uppercase i and lowercase L are not included because they look too similar, same for zero and uppercase o).

So there are 58^33 possibles values, which is slightly more than 10^58. Still high, but not quite as high as 10^92.

The following content was written by theymos on November 10, 2010, 10:40:57 PM in the thread Pros and cons of using new Bitcoin addresses for each transaction?. All content is owned by the author of the bitcointalk.org post. (original)


An address has 33 significant characters, each of which has 62 possible values (10 numbers, 26 uppercase letters, 26 lowercase).
So you have 62 * 62 * … * 62 possibilities (33 times).

Actually, now that I remember, it’s 58 (uppercase i and lowercase L are not included because they look too similar, same for zero and uppercase o).

So there are 58^33 possibles values, which is slightly more than 10^58. Still high, but not quite as high as 10^92.

As ByteCoin already explained earlier in the topic, an address contains a non-data check code and version number. There are actually “only” 160 bits of randomness in each address: 2^160, or 1.46×10^48 possible addresses.

Addresses can also be 25-34 characters in length, depending on how numerically large the hash160+check code is (the larger it is, the more base58 characters required).
Continue Reading

Trending