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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
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! ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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.
|
|
|
I'm getting errors when trying to compile with just wxBase. g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I"/opt/tdep/include" -I"/usr/include" -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp In file included from util.cpp:5: headers.h:22:24: error: wx/clipbrd.h: No such file or directory In file included from headers.h:100, from util.cpp:5: db.h: In member function 'bool CDB::Exists(const K&)': db.h:140: error: 'class Db' has no member named 'exists' make: *** [obj/nogui/util.o] Error 1
Clipbrd.h isn't installed with wxBase. Moving wxWidgets-2.9.0/include/wx/clipbrd.h to my include directory just eliminates those two "no such file" lines.
|
|
|
I'm using Linux From Scratch, so installing a dependency-ridden package like GTK would be a bit of a pain. Why should I add a dozen additional packages and hundreds of megabytes to my system when BitCoin doesn't even use them?
|
|
|
On Linux it needs libgtk2.0-0 installed
Will this requirement be removed sometime? I'd rather not have to deal with GTK.
|
|
|
I'm at theymos.ath.cx. I should be online 24/7. You need to look up my IP address before you give it to Bitcoin. My IP address only changes infrequently, so this should be OK.
|
|
|
I generated 5 blocks today on my Pentium processor. Two of them were within 3 minutes of each other.
I have noticed some slowdown since the adjustment, but I still generate a lot of coins. My computer is off while I'm sleeping, and BitCoin bootstraps quickly when I turn it back on. Do you guys-who-are-having-trouble have the BitCoin port open?
|
|
|
The CA's root certificate needs to be included in the browser to make the warning go away. CACert isn't included in any popular browser, and Startcom was only recently added to Windows. With Startcom, anyone who doesn't install the optional root certificates update in Windows update will still get an error in Chrome, Safari, and Internet Explorer. Firefox has had it built-in for a while.
HTTPS isn't the default (or really necessary) for bitcoin.org, so it doesn't much matter. If you want to manually switch to HTTPS, then you can deal with the self-signed certificate.
|
|
|
The TLS certificate is self-signed, so the warning is "correct". The encryption is just as strong as any other HTTPS connection, but without a CA's signature the site's identity can't be guaranteed -- a man-in-the-middle attack could be used. Unfortunately, getting a signature costs money. Verifying the certificate's fingerprint here before adding an exception will prevent any MITM attack. This is only necessary when you add an exception; subsequent MITM attempts will trigger a warning by your browser.
|
|
|
It doesn't even detect bitcoin.exe normally, just when it's in the installer. I sent the file to ESET, but I don't know if they actually check into these things.
|
|
|
|