+1 privacyshark (purchased my domain there)
+1 link2voip (long time customer, even before Bitcoin)

Due to obvious privacy reasons I won't list the customers of bitcoin4cash.

I'd imagine that Mars would have a separate Bitcoin network. It would be a (very) foreign currency, after all.

Exchange points (automated edge systems, not people manually moving coins) could be designed to handle the laggy conversions between planets.

The getinfo RPC call should return the version of the bitcoind server.

Just a suggestion.

Maybe I should be useful submit a patch 'eh?

Satoshi, could you explain this security safeguard? Is this an undocumented feature of the Bitcoin client or something?

I figured it was a bug with the display. I spent the bitpenny back the other direction and the balance on the first box returned to its initial state.

Check this out...

I just installed 0.3.1 on two different machines and moved one bitpenny (0.01):

-= Before the transfer =-

[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo
{
    "balance" : 1.150000000000,
    "blocks" : 68717,
    "connections" : 6,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 181.5432893640505
}

[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo
{
    "balance" : 0.000000000000,
    "blocks" : 68717,
    "connections" : 22,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 181.5432893640505
}

-= AFTER the transfer =-

[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo
{
    "balance" : 1.139999999999,
    "blocks" : 68717,
    "connections" : 10,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 181.5432893640505
}

[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo
{
    "balance" : 0.010000000000,
    "blocks" : 68717,
    "connections" : 20,
    "proxy" : "",
    "generate" : false,
    "genproclimit" : -1,
    "difficulty" : 181.5432893640505
}

I personally think it is a display problem, but I can't be sure.. strange, no?

Both machines are running FreeBSD 7.2/amd64.

Ahem...

-I"/usr/local/include/wx-2.9" != 2.8.11.0

Also, yes you need 2.9. You'll have to build it from source on most distributions. Luckily, it's easy.

Hello all,

As part of an experiment I am attempting to buy AND sell Bitcoins with cash in the mail. I have had a few successful trades so far. I'd like to be able to trade in the opposite direction as well.

I currently have a $100 USD bill available (no, I can't sell more or less). I am asking for the current Bitcoin Market with a transaction fee of 6.9%+$1 to cover the stamp and envelope/packaging.

If you are interested in receiving a $100 USD FRN in the mail please PM me fast. I'm sure Mr. Franklin will disappear soon.

The masses of asses are best controlled by fear. I say if it isn't illegal; do it.

Step 1:

Install the following from the ports tree:

x11-toolkits/gtk20
devel/boost-all
devel/gmake
databases/db48

Step 2:

Install wxWidgets 2.9 from source. The ports version won't work.

You can get 2.9 here: http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.9.0.tar.bz2

Step 3:

Apply the attached patch to the "makefile.unix" file.

cd ~/bitcoin-0.3/src/
patch < makefile.unix.patch.txt

Step 4:

Tweak any compiler options in makefile.unix. (See the CFLAGS line). The default options are the options I use on my machines. They are: "-O3 -march=nocona -fstack-protector". Be sure to set your 'march' at the very least.

Step 5:

Build with:

gmake -f makefile.unix bitcoind

And enjoy!

$ cat ~/.bitcoin/debug.log |grep "Bitcoin version"
Bitcoin version 0.3.0 beta, OS version FreeBSD 8.0-RELEASE-p3 amd64
$

And what about performance? It's insanely great on FreeBSD. Especially with the ULE scheduler.

CPU: Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz (2666.38-MHz K8-class CPU)
hashmeter   4 CPUs   2585 khash/s

Amen brother & welcome!

Incrementalism is a devious thing.

My mini-cluster of Intel(R) Core(TM)2 Quad CPU Q8400 on FreeBSD 8.0/amd64

hashmeter   32 CPUs   20,704 khash/s

(2588 khash/s per node!! GO TEAM FREEBSD! Roast those penguins! )

I'll share some of my "secret backup sauce". Some of you might find it helpful.

I simply use shell scripts on a cron that make hourly or daily (depends on the velocity of transactions) rotating 90-day snapshots of my entire ~/.bitcoin directory (after I truncate the debug.log; it gets quite huge). The snaps are compressed, PGP'd, and uploaded via scp to a pile of servers I have all over the world. I've never lost a coin yet!

End users are notoriously bad for backing things up.

Even making the wallet.dat file easier to locate (talking about windows here) and urging the user to make copies of it to a USB thumbdrive or whatever would help a lot. Perhaps the place where the wallet.dat is stored on windows could be standardized? I personally know of 2 people who have lost their wallet.dat file because they backed up the wrong folders on windows before a wipe+reinstall. This kind of frustration will only lead to people dropping the whole concept of Bitcoin.

Seasteading isn't a new idea. However, that website is new and particularly interesting to me. Thanks! I'll check it out in more detail. It reminds me of the Freedom Ship. Too bad it couldn't raise enough capital. :/

Robert Menard's work is only the very tip of the iceberg. His works are a great starting place, however he doesn't have all of the answers. To gain a complete and concise understanding one must spend a lot of time researching law, history, and religion. Funny how all three are so intertwined.

Oh it can and does happen.

(Oh, the other vector of attack would be the IRC channel. But hey, I switch that off on my clients for various reasons.. one of which is my uncanny ability to get everyone klined. )

No. That would be foolish. Why should your Bitcoin node trust mine? I could start spreading IPs across the network that I claim are bad and the entire network blocks them.

It would have to be per-node on a case-by-case basis.

I had posted on the forum 5 or 6 months ago about how to make the client harder to detect. (I can't remember the title of the post atm.) So allow me to reiterate:

The post involved making the Bitcoin client select a random port to bind to and not offering a handshake upon connecting to it. Make the connecting party send the handshake. This would improve privacy a LOT.

An attacker would connect to some random port on your computer and get dead air. A valid Bitcoin client connecting to your computer would *send* a handshake to invoke a response from your computer. (Why should it volunteer to identify itself? lol?)

I also think that the Bitcoin clients should emulate what TOR has recently done (as of 3-4 versions ago). TOR's bridge system spoofs the SSL to look like Firefox connecting to Apache. Bitcoin should do the same.

If the Bitcoin clients just looked like thousands and thousands of Firefox browsers connecting to Apaches on random port numbers it would make a passive attack (DPI) a waste of time.

The only vector for attack at this point would be someone running a valid node and looking at the IP seed files. If you are in a country where running Bitcoin is illegal you should be running Bitcoin over TOR (or some other onion/garlic network) or not running it at all.

Censoring IPs is a moot point when investigators/anti-currency groups/government could easily use TOR to bypass it. (Or botnets, or open proxies, vpn services, and on and on...)

We just need to make the Bitcoin client robust enough to detect the "evil doers" (thanks dubbya), and refuse to communicate on a case-by-case basis.