Very nice!

Is there a standard spot to put the build descriptor file in the source tree, or a standard name for it?  I'd like to commit the build descriptor file.

bitcoinex:  I'll tag the tree when I think we have a release candidate.  There are still a few loose ends I hope to tie up today:

1. New -testnet genesis block.
2. New block chain lock-in point.  I'm thinking block 105,000 is a good candidate for the lock-in point.
3. Compile/run/sanity test on Windows.  I am planning on spinning up an Amazon EC2 Windows instance to create a build/testing environment (although probably a VMWare image would be better-- can anybody help with this?  I normally don't do windows).

Am I missing anything else stopping a 0.3.20 release candidate?

No, if necessary we'd change the difficulty adjustment rules and make the code:

if (current block is > some_number)
  ... new rules for adjusting difficulty
else
  ... old rules for adjusting difficulty

I could have done that and kept the testnet block chain, but it is cleaner to just reset it with new rules.

And "pulling the same trick" means throwing an overwhelmingly massive amount of hashing power at the main network (like 16 times the current overall hashing power) for a significant amount of time, which is getting increasingly hard to do.

Difficulty on the -testnet is annoyingly high.   I propose resetting the -testnet with a new genesis block, and changing the -testnet rules for difficulty adjustment as follows:

1. Adjust difficulty on the testnet every 126 blocks (1/16'th the regular net adjustment).
2. Keep the "difficulty can adjust up at most *4", but remove the limit on how quickly difficulty can adjust down.  Minimal difficulty would remain the same.

Unless I hear howls of protest or better ideas, I'll generate a genesis block and submit a pull request with the changes.  I won't switch the -testnet faucet to the new chain until we've got 0.3.20 release candidate builds out.

This seems like a good idea; maybe not for the next (0.3.20) release, but 0.3.21.

From the jansson docs:

"integer numbers whose absolute values are too large to be represented in the int type will result in an overflow error"

As I said in the thread about possibly changing the ECDSA curve bitcoin uses, programmers like to solve "problems" that they know they can solve and that they think will make things a little bit better.  But, in my humble opinion, unless you're solving an important problem changing things because you think you know how is often a bad idea.

This is a perfect example:  change the RPC to spit out 64-bit integers (or move to a new RPC that spits out integers) and anybody using jansson on a 32-bit-int platform will get an overflow error.

I kind of like tcatm's suggestion to define new RPC methods that specify a base unit using strings... but then I thought more about it:

We could use scientific notation, so 1 BTC would be 1e08 base units; then if we ever needed more precision the JSON interface wouldn't change, you could just specify 1e-03 as a value....
... but that's exactly what we have now.  1 BTC is 1e00, 1 base unit is 1e-08, and if we ever needed more precision the JSON interface is ready.

ribuck:

Accuracy/precision is a red-herring unless you're treating numbers as strings, since JSON-RPC numbers ARE ALWAYS double-precision floating point numbers (according to the JavaScript/ECMAScript spec).  Bitcoin could send a number that looks like 2100000000000001, but the code that interprets that JSON-RPC number will convert it into an inexact double-precision floating-point equivalent.  And then the code that displays that number will have to decide how to round and format that inexact floating point number and display it to the user.

When we need more than 51 bits of precision (wouldn't THAT be a fantastic problem to have!), then we'd HAVE to send numbers as strings, and have the JavaScript (or whatever) on the other end feed them into a bignum-type library to handle them.

It sends it from the ClearCoin wallet.  It doesn't do anything special to try to 'mix' coins, though, so if you send ClearCoin exactly 11 bitcoins and then release exactly 11 it is pretty likely the transaction history would be easy to figure out.

Which reminds me... I released a new version of ClearCoin this week that lets you release an arbitrary amount.  So if you wanted to pay somebody 11 bitcoins but make it hard to figure out where the payment came from by looking at the transaction histories you could:

Fund the escrow account with, oh, I don't know, 20 bitcoins.
Release 11.
Let the escrow expire, and you'll be sent the leftover 9.

I haven't heard from anybody...  I'll ask again:  PLEASE HELP TEST

luke-jr's patches got me thinking about whether or not passing double-precision values over the JSON-RPC api would ever cause problems.  I've convinced myself it isn't an issue:

JSON numbers are 64-bit double-precision floating point values, which have 53 bits of precision.

21 million bitcoins is actually 2,100,000,000,000,000 (2.1 quadrillion) of the smallest possible unit.  That's a bit over 2⁵¹ -- you need just over 51 bits to represent them.

So, unless your JSON library is buggy, you should never run into rounding errors converting to/from JSON, even if you're sending 0.00000001 bitcoins.

Can you back up and describe what problems your patches solve?

Here are the problems I care about:

+ If a user receives 1.000001 bitcoins, there is currently no way to transfer the entire amount somewhere else using either the GUI or the RPC.

+ If a user receives 1.000001 bitcoins, the GUI will tell them they have 1.00.

I don't care about systems without a FPU-- are there any such systems that bitcoin actually runs on?

I don't care about BTC vs TBC.

No, not "everybody" -- if it is too expensive for you, then you stop doing it.  Only the people who can generate most efficiently will stick around, and they'll stop "going hard" when the cost of adding more generating hardware is more than the value of the bitcoins they get.

Hopefully bitcoins will become more valuable over time (that will happen if people find them useful/valuable).


Mostly no, total value of the transaction doesn't matter.  A large-value transaction that is made up of lots of little transactions is more expensive to verify, but so is a small-value transaction made up of lots of tiny transactions.  And for both, if they're big enough they'll have to include a transaction fee to get accepted.

I made a google spreadsheet with the number of transactions occurring in the bitcoin block chain per month, and the total value of those transactions:
 https://spreadsheets.google.com/pub?key=0Ar4FtkFP4j73dDQyY3ZJWjdhMlBkZEtTSFJTZm9ieUE&hl=en&gid=0
(click on the BitcoinTransactions spreadsheet; the first is just another version of #produced over time)

Looks like bitcoin is growing nicely; I'm not sure why the big spikes in July and October...

I made the calculations using my bitcointools python code:
  https://github.com/gavinandresen/bitcointools/blob/master/statistics.py

That would make an odd transaction pattern-- e.g. if you started with 11 bitcoins in your wallet, you'd generate a chain of transactions that was:

A paid B 11 bitcoins
B paid C 11 bitcoins
C paid D 11 bitcoins
 ... etc, every 6 hours.  That makes it obvious what you're doing (a series of exactly-11-bitcoin transactions would be extremely unlikely).

Ideally, you want the graph of transactions involving your coins to be indistinguishable from a random sub-graph of the entire bitcoin transaction graph.  Creating lots of wallets won't help you do that; you need to mix your coins with other people's, so the mixing looks the same as just ordinary "X paid Y" transactions.

That's easy-- if #5 is the lowest ordinal piece of dust, then it goes to the first txout.  Etc.

It's all arbitrary but deterministic, and all recorded in the block chain, so you could define rules to trace every .0000000001-of-a-bitcoin forward through transactions.

Answering the original question:

Arresting counterfeiters is a good government economic intervention.

A counterfeit-proof currency like bitcoin is better, of course.

Sure there is-- block 0 contains coins 0-49, block 1 coins 50-99, etc.

If you get sent 500 bitcoins, they can all be traced back to generation transactions, so you "own" a bunch of little pieces of land in bitcoin-world.

ribuck:  I did misunderstand, sorry.

And maybe I should have been clearer:  the idea behind a reproducible virtual image is exactly to capture tools, version numbers, etc etc.   Auditors that create their own virtual images with the same CPU, OS, tools, etc. will be relied upon to confirm that yes, the bitcoin executables on the website were indeed built using standard compilers/linkers/etc from a particular source revision.

ribuck:  what do you suggest instead?

I've read Ken Thompson's paper; that is what motivated me to propose a reproducible virtual machine image as the best we can do IN PRACTICE.

Yes, it is theoretically possible somebody might sneak bitcoin-stealing code into the gcc compiler.  Code that detects that bitcoin is being compiled and injects instructions to send coins to the sneaky gcc hacker.

In reality, we trust that the gcc maintainers are trustworthy and careful and that they care about their reputations.   If you don't trust them, what is the alternative?

Nefario: can "we" make building bitcoin easier?  I've been asking people to submit patches to the bitcoin linux build process, but so far none have been forthcoming...

devrandom:  Nice!

No.  Unless you're changing your wallet outside of bitcoin, rescanning isn't necessary.

It would be nice if the GUI had "backup wallet" and "merge backed up wallet with current wallet" options-- the "merge wallet" would need do a rescan.  Maybe next release somebody will implement those features...

You must have compiled against a newer version of Berkeley DB, and it uses a new log file format.  Try removing the ~/.bitcoin/log.* files before running the older bitcoin version.

I changed build-unix.txt as you suggested.