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/ConfigurationParametersE.g. setting.json file might look like: {
"rpc-enabled":1
"rpc-authentication-required": 1,
"rpc-password": "xxxxxxxxxx",
"rpc-port": 9091,
"rpc-username": "xxxxxxxxxx",
"rpc-whitelist-enabled":1
"rpc-whitelist":"127.0.0.1,192.168.*.*"
}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.
|
|
|
|
The other question - and I know this must have been answered somewhere and I just couldn't find it - what determines transaction uniqueness? Say Alice buys a widget from Bob for 31.42 bc. Alice then decides she wants another widget, and places a new order - with the same keys for both buyer and seller - for another 31.42 bc. What makes these two transactions distinct? If a node sees one transaction for 31.42 from A to B, then sees a transaction for 31.42 from A to B, what tips it off that these are two distinct transactions rather than the same transaction detected twice?
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). |
|
|
|
So, the chain contains a full history of transactions, and a coin's current owner is determined by all nodes as being the last signature in the chain associated with a coin. Am I reading this right?
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. |
|
|
|
From the wiki, "a coin is a number associated with an address." Fine, but this doesn't answer my question. What form does the record by which you verify that an individual who has spent a coin no longer owns it take? Is it simply the latest associated address?
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).
|
|
|
|
I'm working on an alternate bitcoin client and I'd like to try it on the test network. Is there a list of bootstrap hosts for the test network somewhere, so I don't need to implement an IRC client at this point?
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.
|
|
|
|
Could someone make a graph of all the coin values ever awarded, their path through the system, and their current holder? Something like http://www.wheresgeorge.com/ but on the whole economy? 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. Yes. You can get the "top 10 most valuable BitCoin addresses", but not the "top 10 richest users" 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. But could someone, conceivably, state with accuracy how much money has been donated to Bitfountain's posted address? Yes; the BitFountain BitTap BitFaucet donation address doesn't change, so you can see how many bitcoins have gone in. |
|
|
|
Fractional reserve banking is unstable without a monopoly over the ability to print currency, due to the >0 possibility that a bank runs out of reserves. 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.
|
|
|
|
It's ALIVE!  Source on git now has: + different genesis block + ridiculously easy minimum proof of work threshold + protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 } If you compile and connect and turn on coin generation you'll generate a lot of play money quickly... (I've turned off generation, but will keep my three clients -- two Linux, one Mac -- connected) |
|
|
|
There's a stackoverflow question about double hashing, by the way. Consensus is that it's not less secure. It's too late for my brain to process the nuances of hashing... |
|
|
|
|
Very good point about the genesis block.
Unfortunately, I'm not exactly sure HOW to generate a valid genesis block; I can tweak the data but need to generate a valid block hash... hmm, I see some time in gdb in my near future...
RE: changing the protocol version: Good Idea, too. Every wire protocol message starts with the bytes '{ 0xf9, 0xbe, 0xb4, 0xd9 }', I'll tweak that in the TEST code so TEST and production clients can't talk to each other even if they manage to get connected.
|
|
|
|
|
Yep, Americans have been getting a really sweet deal from the Chinese for a while now-- we send them pieces of paper with dead presidents on them (well, the electronic equivalent) and they send us all sorts of useful stuff.
|
|
|
|
As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!
If I understand correctly, you've got two chances to find a collision instead of one. So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal. Bitcoin is using, essentially SHA255 instead of SHA256. It'll still take longer than forever to find a collision... |
|
|
|
|
Show Posts
