Yeah, generation would be challenging / impossible, unless we decreased the generated block rate to something like once an hour, but that brings more problems. The time per block is targeted at 10 minutes to balance transaction speed with latency concerns. I think The MadHatter is right, Mars would have its own Bitcoin network for Mars-Mars transactions.

However, Mars-Earth transactions could happen on either network. The Mars client would send his transaction to Earth. Ten minutes later, an Earth node sees that transaction, checks for double spending, decides it's ok, and puts it into a block. Ten minutes after that, the Mars client sees that his transaction was confirmed by at least one block. Earth-Mars transactions would be even simpler. An Earth client broadcasts his transaction to Earth nodes, who check it and include it in their blocks. Eventually one of them wins the race and the transaction gets confirmed. Ten minutes later, the Mars client gets the new block and sees that he has received the money.

Transactions on either planet could happen in either Terracoin or Marscoin. It would be silly for people on Mars to conduct local transactions in Earth's Bitcoin (and vice versa), but it would be technically possible.

I see no need for dedicated edge nodes or anything similar. Today's Bitcoin could handle this situation (unless I'm missing something big).

The simplest Linux config files typically have formats that look something like this:
The standard extension, if there is one, is .conf. Hash (#) is the most common comment character by far. Semicolon ( and C-style comments crop up too.

I think a good, human-manipulatable config file that ISN'T part of the wallet would be a big step forward. There are a lot of options that are currently specified on the command line (noirc, for example, or -minimizetotray) which might be better specified in a config file.

Nah, it's insanely easy nowadays. Have you seen evilize?

http://www.mscs.dal.ca/~selinger/md5collision/

That number is based on the average payment. Specifically, anything over 500 times the size of the average payment will incur a roughly 0.02% fee.

Satoshi, why does difficulty adjust so rarely? It would seem to me that it would be better to adjust once every 50 blocks or so.

Passing the password in the GET string is wrong, but passing the password without hashing it is perfectly acceptable.

As the DB operator, he could easily steal any bitcoins or cash you gave him. There's really nothing to do about that.

Cool! How exactly are you analyzing the topography of the chain?

There _is_ a getreceivedbyaddress call! I use it .

Also, (get/list)receivedbylabel is nice for when you want to get the amount received by every address in each label. Let's say I create one-time use addresses for a store all with the same label. If I want to know how much my entire store has received, I don't have to call getreceivedbyaddress a million times; I just call getreceivedbylabel for the label.

I use this for my donations system in my signature.

Alright, thanks. That's all I need.

Satoshi, you didn't fix the bug; you just ripped out the minimize to tray code. Could you possibly make this optional? I wasn't experiencing the original bug, and I very much like the minimize to tray feature.

I think that would be cool, but as always, the decision rests with Satoshi, the project lead.

That's not a terrible idea, though. A better low level interface to the generation and transaction spec would be nice.

So wait, I have to pay you AND put one of your banners on my site? No thanks.

Why not just do a banner exchange in that case? What service do you provide for me that necessitates me paying you?

The JSON-API definitely needs some sort of security features. On Linux, you can use iptables to restrict the users who can access it, but that's hardly secure. If I want to access it from my website backend, then whatever user runs my httpd needs to be able to access it, and that's the user most likely to be compromised on my server!

Of course, a password wouldn't help that scenario too much, since the password would just be another variable in django's settings.py for an attacker to read, but still, it beats a blank!

Very nice Satoshi. What about the slow block download bug?

By the time everyone has Bitcoins, the fee will have been removed or adjusted.

It's good the spec already addresses this problem. I'd like to see some more in depth access to things like the coin list (so we can choose to spend coins based upon who sent them to us, etc) and the client list. For example, all of my computers at home -connect to my router, which runs (but does not generate) with port 8333 open.

I wish there were some way to prioritize network traffic to my own local nodes over remote nodes.

Hello all,

I've made a patch against svn-r102 that adds three RPC methods:
ListGenerated [pendingOnly=false]
Returns a list of generated transactiosn. If pendingOnly is true, includes only accepted but not yet matured transactions.
Here's an example output:
[
    {
        "value" : 50.00000000000000,
        "maturesIn" : 0,
        "accepted" : true,
        "confirmations" : 8184,
        "genTime" : 1275586091
    },
    {
        "value" : 50.00000000000000,
        "maturesIn" : 0,
        "accepted" : true,
        "confirmations" : 7545,
        "genTime" : 1275963218
    }
]

I released a similar patch is the past, but this one is finally production-quality.

I also added two more functions:
gethps and getkhps

Those just return the hash rate and the hash rate / 1000. getkhps was also added as a key in getinfo.

Anyway, this patch can be downloaded at:
http://www.alloscomp.com/bitcoin/patches/bitcoin-svn-102-rpccalls-2010-07-14.patch

If you're using Linux x86_64, you can try out my binaries at:
http://www.alloscomp.com/bitcoin/binaries

Could you make it possible to reenable that feature with a startup switch or even compile flag? I like it a lot, and I don't have this issue.

For the block download problem, this patch might solve it. I haven't had time to test it yet, but it looks good.

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