Would it be good enough if I volunteered to write a little perl or python or php or bash script that reads the passphrase from a file descriptor and then posts the right JSON-HTTP request?

If the consensus is to teach bitcoind to read arguments from file descriptors, somebody please figure out if there's a standard for how other unix apps do that.  Here's what curl does:

In the long run, block size will NOT be the bottleneck, so it will NOT determine the marginal cost of a transaction.

The bottleneck is, and I believe will continue to be, the number of ECDSA signature verifications a miner can perform per second.  Each miner (or mining pool operator) will have a transaction processing capacity of N transactions per second.

If there are more than N transactions per second going across the network, then the smart miners will select the most profitable N for inclusion in their blocks and drop the least profitable.

And the smart miners will keep track of how much it would cost them to invest in more CPUs or specialized ECDSA-verification hardware so they can process N+M transactions per second.  And figure out how much they would make in fees or side-deals (or whatever) when they handle those extra M transactions per second.  If it is profitable, they will increase their transaction processing capacity.

---

I think what bitcoin is missing right now is code in the clients to figure out the "right" amount of fees.  We're currently relying on hard-coded rules that match in the client and in the miners (because it was All One Application to start).  We need to move to something more dynamic.  Some thoughts I jotted down last night:

Users want to know what fee to pay, given the constraints "I want this transaction confirmed in B or fewer blocks with probability greater than P".

If we think of that as an equation:
... then the question is can a client estimate f by looking at the block chain and/or observing transactions as they fly across the network and (eventually) get included in blocks?  Or can we come up with a protocol to communicate f between clients and miners?

My rule of thumb is "never inline methods more than 1 line long."

Unless you're doing something super performance-critical, in which case my rule of thumb is "don't change anything until after you've written a realistic benchmark."

But I'm an old-fashioned C++ coder, kids these days seem to want to put all the code in .hpp files.

To be completely sure you get all the donations you deserve, you should put the donation address on an https:// page.

Otherwise hackers can hijack http: pages if they can insert themselves into the network between you and your web visitors, and replace the donation address on the webpage with their bitcoin address.

People keep saying that, but it is simply not true.

With a given number of "front-end" CPUs checking ECDSA transaction signatures, miners will be able to process at most N transactions per second.

If there are more transactions than that going over the network, then miners will drop the least-profitable transactions and only process the most-profitable N.

Mining involves two distinct tasks:  checking transactions and gathering them into a block (which is inexpensive right now because there aren't gazillions of transactions).  And then hashing (which will always be expensive).


Miner operators will keep track of the transactions they're dropping, and will do some math to figure out if it would be profitable for them to invest in MORE front-end CPUs to process more than N transactions per second.

Random thought RE: passwords and RPC:

I was thinking a better way of handling the password might be a new RPC command:

walletpassword <password> <timeout>

... which would store <password> in memory for <timeout> seconds.  If you know your server is secure, you'd give a very long <timeout> at startup.

That same <timeout> mechanism might be very handy in the GUI (somebody who knows more about password security might have something intelligent to say about the tradeoff between the risk of storing hashed-password in memory versus the convenience of not having to constantly re-enter it).

A walletpasswordchange <oldpassword> <newpassword> seems like it would be very handy, too.

Tacking <password> onto the beginning of RPC argument lists seems like the wrong thing to do.

To get even more "meta" : ask yourself why anything has value.

Tools, like hammers or cars or pants, have value mostly because they're useful and it takes effort to create them.

Some things have value because they're beautiful or rare.

Bitcoins have value because they are useful and rare.  As more and more people use them, they're useful for more and more things-- so their value will increase.  A lot of the current value of bitcoin is people who realize this and are trying to 'buy in early' -- they think that bitcoin will be used for more trading next year, so the value will be higher, so they want to get some now before the price rises.

I have no idea what the "right" value for bitcoin is, but I am very encouraged by all of the fantastic, innovative ways people are using bitcoin.  I expect most of those experiments will fail, and I hope that everybody realizes that there will be lots of failures along the way to what I hope will be a huge success.

Downgrading does not "fix" it.  The earlier version would broadcast the transaction, and then it would (most likely) either sit in the network with 0 confirmations for half a day or sit on your machine with 0 confirmations for a few hours, until it aged enough to graduate from the 'very low priority' category.

The rule of thumb is 1 BTC you just received needs 144 confirmations (1 day) before it is considered 'normal priority.'  10 bitcoins requires 1/10'th that-- 15 confirmations would do it.

Given the recent rise in bitcoin value, I think it makes sense to modify that formula so 1 BTC takes (perhaps) 10 confirmations to be considered 'not likely to be spam'.

Yes, the 0.3.21 release will charge a fee if you want to do things like send 0.05 bitcoins to yourself.

Why?  Because some people were sending 0.05 BTC to themselves over and over and over again, wasting everybody's disk space, bandwidth, and CPU time.  The fee is there to reveal the hidden costs of sending lots of tiny transactions.

Next release the normal fee will be dropped from 0.01 BTC to 0.0005 BTC.

The long-term goal is to figure out how to make fees dynamic; maybe in a few months you'll get a slider that lets you choose fees on a transaction-by-transaction basis, and will show you how long you're likely to wait for various amounts of fees...

Good, that looks like it will be easy to find.

Yep, if you control more than 50% of the hashing power you can just refuse to work on anybody else's blocks and your chain will always eventually be the longest.

Of course, if you do that there will be constant block chain splits and transaction confirmations will take twice as long (because you'd be throwing away the other half of the network's hashing power), so we'd all notice.

And I'm pretty confident we'd think of an effective way to ignore your blocks.  Seems like an awfully big risk for a +50% pool operator to take; why would they want to undermine the system that is (almost certainly) making them lots of money?

I think sipa is right-- it will just look like a weird double-spend.

Probably a good idea to reject transactions with non-canonical signatures (reject if encode(decode(tx)) != tx ).

I assume the DER-encoded ASN.1 octet representation is the same between different ECDSA implementations (so if a non-openssl-based implementation creates transactions its transactions would be accepted), is that a good assumption?

I like "mills" or "millies".

The new default transaction fee is 5 mills per kilobyte, by the way.

daemon=1
... is the right syntax for the conf file.

That'd be exactly when the power goes out.

I make the Amazon virtual machine images that I used to build the Windows and Linux binaries available... but Amazon recently took them down because they contain my ssh public key in the "allowed to login without a password" file. Removing the public key and then making the modified virtual machines public again is on my TODO list (Amazon doesn't want anybody to have a 'back door' into a public machine image, and bravo to them for checking-- I had no intention of logging into other's bitcoin-build-environment virtual machines, I just needed an easy way to login while I was putting together the releases).

If you have an EC2 account, you can run them and recreate the exact build environment and check to make sure you get exactly the same executable code  (the compilers may put timestamps inside the files which you'd have to ignore).

The plan for future releases is to use devrandom's 'gitian' build system, which is a spiffy way of creating a well-defined virtual machine image from signed and trusted repositories, fetching a specific version of the code from the git source tree, and compiling in a way that is completely reproducible.
 See: https://github.com/devrandom/gitian-builder

If you're willing to muck with the transaction processing code, you could only allow transactions to addresses that have been created and blessed by the Central Authority.  You'd have to also teach the wallet code not to create lots of addresses, but if you're going to require users to register and not be anonymous you might as well centrally create and issue them their wallets.

You then need a mechanism to broadcast new, blessed public keys to the entire network, but that might be as simple as generating a transaction from a baked-in blessed address (owed by the Central Authority) to the newly created blessed address.

Implementing and debugging would be a lot of work, and I'd be nervous about neglecting some little detail and leaving the system open to hacks (Bitcoin is nice because so many people are extremely motivated to find any chink in the system and either exploit it or patch it-- a small complementary currency wouldn't have that advantage).  But it could be done.

This is where I think maybe a standard https-based protocol might work nicely, so the same address shortening services can be used either in the bitcoin client and for online e-wallets.

Something simple, like user says "Please use these services for resolving addresses:
   https://bitdex.net/resolve
   https://btcquick.com/resolve
   https://mtgox.com/finduser
"

Protocol could just be POST the text the user types into the address field and get back JSON with a bitcoin address and maybe some extra information to reassure the user that they're paying gavin@acm.org "Gavin Andresen (my picture) (my gpg key fingerprint)" and not gaven@acm.org "Gaven Smith (some other guy's picture) (no gpg key fingerprint)" ...

Oh, and what version of bitcoin are you running?  0.3.21 includes a patch from luke-jr that modifies the coin-selection algorithm to avoid sub-cent change when possible.

It will also help if you keep a good selection of 'old' coins in the shared wallet.

I agree that transaction fee accounting/handling needs improvement.

Looks ok to me, assuming $account and $address are strings and $amount is a number.