|
Did you try "LD_LIBRARY_PATH=/usr/lib ./bitcoin"? Are you sure libcrypto.so.0.9.8 actually exists?
|
|
|
|
|
If BitCoin counted the number of hashes it calculates per second/minute, it would be possible to determine the average number of blocks that will be solved per day. This would be very useful.
If hashing works the way I think it does (nonce is incremented per try), this data could be gathered efficiently by saving the start nonce and start time and comparing it to the end nonce and end time whenever the nonce is regenerated.
|
|
|
|
|
The number of coins created per block is halved every 4 years, not the number of blocks created. 50 coins are created per block now. When we reach about 200,000 blocks, each block will be worth 25 coins. After another 200,000 blocks (4 years), each block will be worth 12.5 coins.
|
|
|
|
|
The network adjusts the difficulty so that roughly 6 blocks are created network-wide every hour. Each block can contain lots of transactions.
|
|
|
|
Do all CPUs--no matter their strength--produce the same amount of coins at the same rate? No. For each SHA-256 hash you calculate, you get one chance of solving the block. Better CPUs can hash more data per second. If not, can I give the Bitcoin application the highest priority on a system and dedicate all of the CPUs power to Bitcoin production? Will this produce more coins compared to running the application normally? It'll already use 100% of the CPU's capacity if nothing else wants to. Setting priority just says, "If CPU resources are scarce, prefer the higher-priority program over the lower one." |
|
|
|
Cool. This could be an easier alternative to Exchange Zone for exchanging digital currencies, with BitCoin as the medium of exchange. Do you charge any fees? |
|
|
|
Here's the approximate number of BitCoins that will be created over a 25-year period (starting now). An unpredictable number will be lost, though.  The JavaScript and resulting csv data is attached if you want to make a better graph. |
|
|
|
Nothing's saved to your outbox unless you select the "save to outbox" option. This can be changed in the settings. I will be participating in the tournament. You'll probably all slaughter me, though.  |
|
|
|
|
I usually have 45-50 connections on my always-on computer. I counted 49 users in IRC, so it looks like I'm connected to nearly everyone.
|
|
|
|
|
To eliminate segmentation, every peer should have a list of every other peer. Tor also has this requirement, so we should copy them: have several trusted directory servers periodically create a signed list of all peers and publish it via HTTP. All BitCoin clients have the option to act as a directory mirror, which will be indicated in the dirServers' list. Generators need to ask to be added to the list (which could also include info like the maximum number of connections that peer will accept), but people just wishing to make transactions can just get the list from a dirMirror and connect to a few random peers.
If this is too centralized, we can do what I2P did and allow anyone to become a directory server. You need to be able to detect when a dirServer goes rogue in this case, though.
|
|
|
|
I understand public-key cryptography. Look at the diagram in section 2 of the BitCoin paper. For owner 1 to send coins to owner 2, he needs to know owner 2's public key in order to create a hash and sign it. To receive payment, owner 3 needs that same public key to verify that it has been signed by owner 1. |
|
|
|
|
The paper seems to say that coins are transferred by signing the receiver's public key with the sender's keys. Then the receiver has to use that same "verified" public key to transfer the coins to someone else. Since the public key is connectible to an identity by the person who originally sent the coins, this is a problem.
I could be wrong about how this works, though. How do you think it works?
|
|
|
|
|
Say that I buy 100 BTC from NLS. He has my identity. I then buy something with those particular BitCoins. If the seller and NLS share info, can I be identified? My understanding is that I can, because I used the same BitCoin address to both receive and send those coins.
|
|
|
|
http://en.wikipedia.org/wiki/E-goldIn 2007 the proprietors of the e-gold service were indicted by the United States Department of Justice on four counts of violating money laundering regulations. In July 2008 the company and its three directors pled guilty to charges of "conspiracy to engage in money laundering" and the "operation of an unlicensed money transmitting business" in the U.S. District Court for D.C. The company faces fines of $3.7 million. Running an exchange seems very dangerous. I would never do it without talking to a lawyer and setting up a LLC.
|
|
|
|
Cool; it works!  Thanks for your help! I am using 2.9.0. (No memory issues for me.) |
|
|
|
Using DB-4.7.25 fixed that problem. I'm now getting this error, though: g++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I"/usr/include" -I"/opt/tdep/include" -o bitcoind -L"/usr/lib" -L"/usr/local/lib" -L"/opt/tdep/lib" obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -l wx_baseu-2.9 -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l crypto -l gthread-2.0
obj/nogui/init.o: In function `wxArrayString::Item(unsigned int) const':
init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x7): undefined reference to `wxTheAssertHandler'
init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x42): undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
collect2: ld returned 1 exit status
make: *** [bitcoind] Error 1 |
|
|
|
|
I'm using Berkeley DB 4.5.20.
|
|
|
|
|
Show Posts
