I'm not personally notified, no...     But if I have a Bitcoin client connected to the network then yes, it (along with all the other connected clients) should be sent every transaction shortly after they happen.  It has to-- it might be generating blocks, and the whole point of block generation is to record the valid transactions the client has seen that haven't been included in a previous block.

There's a discussion in this thread of how likely it is that an attacker could "split the network" to successfully double-spend coins.

See the "Bitcoin snack machine" discussion.

Real-world, ordinary-sized transactions should wait a few seconds for the transaction to propagate across the network.

There are already a few places in the source code where that is done.
I think Satoshi's done a darn good job of anticipating future needs.  The wire protocol and database serialization formats both have version numbers, as do bitcoin addresses.  The core transaction mechanism is very flexible (I worry that it might be too flexible, but that's why we've got the TEST network to see if we can break it).

I can't think of anything simple that would make it more future-proof.  If you're worried about SHA256 getting broken or the 21quadrillion Bittiestcoins not being enough... then you worry too much.  Stop worrying, you'll just suffer from analysis paralysis and get nothing done.

You ask hard questions!  Most common: probably Windows INI files, because Windows is most common OS.

I'd lobby for using JSON; it's (mostly) a subset of YAML (which is a common choice for config files), so any JSON or YAML parser will read it.
I think the only big advantage is that it keeps authentication where it belongs in the transport layer, so if, in the future, you do want to go with full-fledged HTTPS with certificates the API doesn't have to change.
No, I just confused "command" with "parameter", and did this:

I think that's a politically correct way of saying "we accept food stamps."   Try going in with a fistful of Euros and see what happens.

After further research...  I think the Transmission approach, combined with the existing "only allow connections from 127.0.0.1" is a good short/medium-term solution.

Putting the username:password in a settings.json file in the Bitcoin directory aught to work nicely (since Bitcoin can already parse JSON).  And keeping the authentication stuff off the command line and in the HTTP headers instead of the JSON request params is nice and clean.

Long term, the "right" way to do authenticated, secure JSON-RPC is with client-side certificates and https.    But that looks like it would be a lot of work to implement and a big learning curve for users to figure out how to generate client-side certificates and how to get both sides of the JSON-RPC connection using them.   And I'm not even certain a full-blown client certificate solution would solve the problem of malicious Javascript making JSON-RPC requests via XMLHttpRequests to localhost; if the user installed the client certificate in the browser (because maybe there was a nifty JSON-RPC-powered web front-end to controlling Bitcoin), would the browser automatically send the client certificate if a malicious website made requests?

The Transmission BitTorrent client does authenticated JSON-RPC; see "Remote Control" section of:
 https://trac.transmissionbt.com/wiki/ConfigurationParameters

E.g. setting.json file might look like:

It uses HTTP 'basic' authentication (Authorization: basic base64(username:password) in the HTTP headers).

The Bitcoin Faucets (production and TEST) are now running with this change.

I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list.  I agree that reading the command-line password from a file would be more convenient and more secure.

I'll try to do some research on how other projects tackle JSON-RPC authentication.

A few things make those 31.42BTC transactions unique:

+ The timestamps in them will be different.
+ The input transactions will be different (you can think of those as being different 'coins' going in to make the payment).
+ And if the input transactions don't add up to exactly 31.42 (and they probably won't), they'll have different output transactions for returning any change to Alice.

By the way: all that stuff is hashed together to give each transaction a unique 256-bit transaction ID (which you never see, but is used internally so Bitcoin can quickly figure out if it has already seen this transaction before).

Yes.  Whoever has the private key that can create that last signature can spend the coin-- he or she (or them-- eventually maybe as bitcoin clients add features) are the owner.

The transaction history isn't exactly a "chain" -- multiple coins can get combined as input to a transaction (they're all "spent"), and multiple coins can get produced from a transaction (they're all "unspent" until they're used as the input to another transaction), so it's a more complicated network (I think of a chain as one link followed by another in a straight line).  But it will all trace back to one or more 50 Bitcoin GENERATE transactions.

Y'all know about http://twollars.com/?

If that coin is one of the inputs to a later valid transaction, then it is spent and cannot be spent again.

That later transaction is the record that somebody spent the coin; it is signed with the private key, and that key (which Bitcoin keeps for you in your wallet) should be known only to the owner.

Here's how you can lose coins by backing up and restoring your wallet file:

Lets say you have one shiny 1,000 Bitcoin coin in your wallet (it's actually just a transaction for 1,000 bitcoins paid to a public key that's stored in your wallet).

You backup that file.

Now you spend 1 Bitcoin.  Your shiny 1,000 BTC coin is broken into 1BTC, plus 999BTC in change.  That change is given a new, different public key.

Now if you restore your wallet file, Bitcoin sees that the 1,000BTC coin has been spent-- 1BTC was sent somewhere, and the other 999BTC was sent somewhere else.  Because you don't have the key for the 999BTC, it has no idea that those coins belong to you.

So they're lost.

Trying out alternative policies for handling change on the TEST network would be a good idea, in my opinion.

Maybe change transactions should always get signed with the same public key, so you wouldn't lose coins when restoring your wallet... although that would give you less privacy because it would tend to tie all your transactions together.

Maybe your wallet should get initially populated with 100 "change" addresses, with one randomly chosen as needed.  And some super-geeky way of replacing them with another, new, 100 addresses.

Maybe there's an even better way of handling the "I lost BTC when I restored my wallet" problem; ideas?

TESTcoins are maturing, and the TEST Faucet is open and giving out 50 TESTcoins per visit:  https://freebitcoins.appspot.com/TEST/

Feel free to grab some play money any time; there's no coins-per-IP-address limit, but you will have to solve the CAPTCHA if you revisit.

Unix and Mac and Windows all have ways of scheduling recurring tasks (Linux: crontab, Mac: crontab, or I think iCal can do it, Windows... I dunno).

So if you're a little bit geeky, you could arrange for "bitcoin sendtoaddress 1mJMYFAVORITECHARITY9R4 amount" to get run once a month.  (just run bitcoin with the -server flag).

The TEST Faucet will be running on host:  li133-197.members.linode.com
(starting tomorrow, if all goes as planned).  You can connect to it to bootstrap.

I know EricJ2190 tried out the test network today-- Eric (and anybody else who might have compiled and run) you need to git pull, recompile, and nuke your ~/.bitcoinTEST directory.  The client was generating blocks WAY too fast.

That'll teach me to go messing with code I don't really understand (on the bright side, I now know what the OpenSSL BN_bn2mpi() routine does).

Oh, and Eric:  I added your pnSeed fix to my git branch.

Every generated coin gets a unique address, so you until they get bundled together and sent somewhere you don't know to whom ("whom" as in "which Bitcoin Address") they belong.


You can get the top 10 addresses that have received the most coins (and could figure out how many have gone back out), but there will probably be a lot of generated coins that have never been spent which will just look like little 50-coin islands.


Yes; the BitFountain BitTap BitFaucet donation address doesn't change, so you can see how many bitcoins have gone in.

That's like saying: "Gold atoms are unstable because quantum mechanics tells us that there is a >0 possibility that they will spontaneously decay."

Yes, in the very very very long run the universe will suffer heat death and there will be no gold (or any other atoms) left.

If the probability of bank runs is very small, then fractional reserve banking works.  Or, in other words, if banks can establish and maintain trust in their ability to repay deposits they'll be stable even if they practice fractional reserve banking.

I hope we'll eventually find out the hard way if, or which, Bitcoin banks can establish and maintain trust.

That's right.

One of Bitcoin's big advantages is that you can be your own bank; you don't have to trust a government-backed fractional reserve bank to keep your extra cash safe.

If you WANT to trust a fractional-reserve Bitcoin Bank, feel free.  But don't go crying to your congressman if you lose all your money, please.