With davidonpda's help, I did some testing myself today with Satoshi's latest code changes (setting priority based on transaction age, bitcoin amounts in, and total transaction size in bytes -- svn rev 176).

It behaved as expected, putting larger, older transactions ahead of the pennies being flooded into the network, so "normal" transactions will be confirmed promptly even if somebody decides to be a jerk and floods the network with transactions.

Computers could get 1 billion times faster and Bitcoin's hashing and elliptic curve digital signatures will still be "safe."

2^256 is a really, really big number.

2^226 is also a really, really big number.  It is a billion times smaller than 2^256, but still far and away big enough.

Even 2^160 (the size of the bitcoin address hash) is big enough.

Back-of-the-envelope:
Lets say computers in a few years can do a quadrillion hashes per second-- that's about 2^50 hashes/second.  How many seconds to find a SHA-256 hash collision?  2^205 seconds.  That is much longer than the age of the universe.

How long to find a bitcoin address hash collision?  2^130 seconds, which is 43,161,132,283,224,056,755,882,116,619,960 years.  Also much, much longer than the age of the universe.

(actually, those numbers are the MAXIMUM time.  Divide by two for the average time.  Insanely big divided by two is still insanely big.)

You should be worried that some weakness in SHA-256 is found that allows hashes to be cracked other than by brute-force.  And if you're worried about that, then it is dumb to switch to SHA-512 now-- perhaps a flaw will be found in the entire SHA* family of hashing algorithms.

If there's a c++ programmer out there looking for a good "get me feet wet" project involving Bitcoin, I think importing/exporting public/private keypairs (in one of OpenSSL's file formats) would be a really good choice.

The hard part is importing; you'd have to write code to re-scan the block chain to find transactions to/from the newly imported public/private keys, and add them to the wallet.

No, you can't, because every time you send them they become "new", and the priority is age multiplied by amount:
 (valuein is the size of the bitcoin input, age is # of blocks deep, and txsize is the number of bytes the transaction takes up)


Ummm... the more you mess around with the coins in your wallet, the newer they are, and the lower their priority (relative to everybody else who might want to get their transactions into the next block).  I haven't thought deeply about it, but I bet simply leaving your coins as they are and making change as necessary will work out best.  But please, create your own client and try to break things on the test network!

I think it is WAY too early to nail all that down; bugs in that code caused changes just a few months ago.

Just write the code, and when core bitcoin changes, be prepared to change your code.  For the specific case we're talking about, you don't need to know all the possible ways scriptSig satisfies scriptPubKey-- you just need to reverse engineer how the standard send-to-bitcoin-address works so you can sign your own send-to-bitcoin-address transactions.

The behind-the-firewall nodes will need the following from an on-the-network bitcoind:

1. They need to be able to ask it "tell me about any transactions to these bitcoin addresses..."
2. They need to be able to send it a signed transaction and ask "Please broadcast this for me."

Item 1 is implemented in my monitorreceived patch ( https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived ).

Item 2 would be cool.  Anybody want to design and develop an "accept transaction" patch?

All the other functionality needed (like generating public/private keys, generating and signing transactions) could be, and should be, in my opinion, be done as a project separate from bitcoin.  Making the code small and self-contained and as secure as possible would be the goal; it could be re-used to create a type of lightweight client that ran on cell phones in addition to running behind corporate firewalls.

But again:  if that clear interface includes a command to "send XYZ bitcoins to some address", then how is the separation making you more secure?

I agree-- we're in the Wild West days of open-source currency.  I expect people will get burned by scams, imitators, ponzi schemes and price bubbles..

I tend not to worry about things that are out of my control; I don't think there's a whole lot that can be done about scammers, imitators, and ponzi schemes besides warning people to be careful with their money (whether dollars, euros or bitcoins).

First: I've reviewed Bitcoin's networking code looking specifically for possible buffer overflow vulnerabilities, and found none.  It is possible I missed something; please help review the code and let me or Satoshi know if you find anything suspicious.

Second: I don't think splitting the wallet handling code into a separate process will improve security at all.  If there is code that can send the nicely-compartmentalized wallet handling code a command "Send XYZ bitcoins to address 1ABC...", and that code has a buffer overflow vulnerability in it, then you are just as vulnerable as today.

If your PC has been compromised, then you are in trouble; anything you do on your machine may be intercepted by a bad guy.  Log into your bank account website-- the bad guy might hijack your session and transfer money out.  Start up bitcoin-- the bad guy might inject keyboard and mouse events to send coins out.

Even if Bitcoin implemented multi-factor authentication before allowing wallet access ("scan your fingerprint and enter your password to send coins"), if your PC is compromised a bad guy could arrange to modify the bitcoin address that you say you want to send coins to, so you think you're authenticating a payment to Wally's Discount Center but you really authenticate payment to Doctor Evil's Empire.

The test network (run bitcoin with the -testnet flag) is a different block chain, implemented so that the two chains never get confused.  If anybody wants to start yet another block chain, it isn't technically hard, and won't cause any problems for "real bitcoin".

The hard part would be getting anybody to use your alternative; it would have to be better in some way other than just "I started the new chain, so I've got a lot of the easy-to-generate-at-the-beginning-coins."

Actually... prioritizing free transactions based on both amount and their "age" should make this attack toothless.

The basic idea is that if you're spamming lots of small free transactions, you'll be creating lots of brand-new "pennies" (you'll take an old 50BTC generated transaction, then split off a penny and get a penny and 49.99 change.  Then split that 49.99 to get another penny, and so on and so on).

Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain ("old money") are given priority would let normal transactions go through.

The spammy transactions would still take up network bandwidth and disk space; if that becomes a problem, nodes could just ignore small, new transactions (not relay them) and let the nodes that are doing the spamming queue up and rebroadcast the transactions.  They'd trickle into the network eventually, and in the meantime the spammer's bit-pennies would be tied up.

You already did.

Hmmm....

At some point (bitcoin 0.9?) debug.log should contain only really critical errors/warnings.  Right now it is more of a trace.log.

Flushing it after every write is the correct thing to do-- otherwise critical information about what caused a crash could easily be lost.

Always closing and re-opening it is darn convenient if you've got a log-rotating script running... but working poorly with FileVault is definitely a bug.

That's not right-- the person paying you doesn't know your public key, they just know your bitcoin address (which is a 160-bit hash of your public key).

You can (and I have) send bitcoins to ANY 160-bit bitcoin address, whether or not there actually is a public/private keypair corresponding to that address.

If Satoshi goes rogue, then the project forks.  He has a very strong incentive (success of the project, growth of the value of the bitcoins he owns) not to do that.

If the SVN repo gets hacked, then we back out the hacked changes (that's easy to see; several of us look at every svn commit) and warn people who might have compiled with bad source to recompile.

I'm having trouble figuring out exactly what you would like to happen-- is your complaint that you have a different definition of what "open source, peer-to-peer" means than the rest of us?

tentative: I don't get it.

You seem to be saying that somebody might be secretly working on a longer block chain, and all their hard work will be ruined because they won't be able to replace the block chain everybody else is using non-secretly because the block chain everybody else is using might get locked in.   Ummm... yeah!  Don't work on longer block chains in secret.

Either that, or you're saying Satoshi might accidently lock in a shorter block chain, and most people either not noticing or not caring.  Umm... no, I don't see that happening.

The block chain lock-in check is only done when new blocks are accepted.  Here is what would happen if Satoshi tried to commit a block lock-in that most of the network thought was shorter:

1. Imagine everybody downloads the new client with the bad lock-in.
2. Everybody who had the longer chain before ignores the lock-in, and continues to push the longer chain.
  (unless the longer chain contains a bad transaction-- the chain is checked for bad transactions on startup, see  CBlock::CheckBlock)
3. Newbies who are downloading the chain for the first time will hit the lock-in code, and will be running with a shorter chain.

There will be chaos as newbies generate blocks on the shorter chain, which only other newbies will accept.  "oldies" will also continue to generate on the longer chain.  Transactions will get added to both chains... and the "oldies" will beat Satoshi into submission.  Unless there is a legitimate bug (like the overflow bug that inspired the block chain lock-in code in the first place).

If I am misunderstanding your concerns, please speak up.  The number one development priority for bitcoin is security.  If you have found a problem, please email or private-message Satoshi, or post here (besides possible network denial-of-service attacks-- only email about those if you have a brilliant idea for how to prevent them...).

Ok, looks like two problems-- if rpcallowip=* works, then maybe bitcoin thinks your IP is something else (or maybe there is a bug in the bitcoin rpcallowip code).  Run this on the web server:

As to why the PHP code isn't working-- can you turn on error_reporting and get more information on what isn't working?

Does it work if you (temporarily) set rpcallowip=*  ?

And are you SURE you're running a bitcoind that supports rpcallowip?  Run bitcoind getinfo, and check the "version" value returned (version 0.3.12 or later, if I'm reading the source correctly).

If bitcoin thinks the connection is not allowed, then it just ignores the connection attempt-- nothing is written to debug.log.  That's probably the right thing to do-- otherwise somebody malicious could try to fill up your hard disk by repeatedly attempting to connect to port 8332.

If you can recompile bitcoind, the "ClientAllowed" routine in rpc.cpp is where a printf() to log connections could go.  But I'd guess either you misspelled "rpcallowip" (I always type rcp instead of rpc...) or have a firewall blocking connections.

If you can ssh into the web server machine (or any other machine, actually), try:
  curl http://machine_or_ip:8332/

If you get "couldn't connect to host" then it is a firewall problem.
If you get "Empty reply from server" then it is an rpcallowip problem.
If you get an HTTP "Authorization Required" or "Authorization Failed" reply, then it is a username/password mismatch (those ARE logged in debug.log, though-- grep for ThreadRPC).

Looks good to me.

Try to connect then look at the end of bitcoin's debug.log; see if it is even getting the connection.

Also:  did you restart bitcoind after adding the rpcallowip?  The .conf file is only read at startup.