No, there is a block chain re-org invalidating B and C.  D is still valid in my scenario.

So the client remains oblivious to B and C being invalid, whether it asks for transactions older than T2 or transactions after D.

Huh?  I don't see how passing <txid> makes that problem any better.

Let's say you've got transactions A B C D (in that order).  With times T1, T1, T2 and T2 (A&B happened 2 blocks back, you got C&D in the last block).

Now imagine a block-chain re-org, so B and C are now invalid.

Ask for all transactions after D and you get nothing-- same as if you asked for all transactions with time greater than T2.

If an optional time param is needed, maybe get rid of the "since <txid>" notion and just make it "give me all receive transactions for [account] with [minconfirmations] that have a time greater than [time]".

Nice, I like your proposal.

Do you know C++?

Transactions are confirmed when new blocks are accepted; that's the idea behind my 95%-finished 'monitorreceived' code.  It will POST to a URL when new wallet transactions and blocks are accepted.  The block information includes all transaction ids (and a link to the previous block).

As you note, you still have the issue of what to do if your code misses a POST.  That shouldn't be a big issue, though, because you'll resynchronize the next time a block is found.  Worst case, you'll ship to the customer 1 block (10 minutes) later than is optimal if your connection to bitcoind is lost.

Good idea.

I think the first spot for plugins in bitcoin should be "send address resolver" services-- If I tell bitcoin "send 100 bitcoins to obama@whitehouse.gov" it could ask the plug-in resolvers (in some user-defined order) "do you have a bitcoin address for obama@whitehouse.gov" ?

If I tell bitcoin "send 100 bitcoins to eff.org" maybe a different resolver is used (DNSSec query to eff.org to get a bitcoin donation address, perhaps).  Or "send 11 bitcoins to +01-1-805-253-2751" ...

There are lots of potential problems, of course, ranging from what if the resolver software service/author starts redirecting bitcoins to them to what if the user misspells the destination.  That's why I think starting with a way of pluggin-in different solutions to try is the right way to start.

How do you think the code should deal with the issue of "a fixed txid might no longer be valid" ?  Or transactions that you THOUGHT had N confirmations and were in a block with timestamp T are re-organized to have M confirmations and are in a block with timestamp T2 ?

tcatm and I chatted in IRC about this problem-- he has the problem of how to keep the Javascript GUI (which shows you ever transaction) up-to-date.

Seems like you really want an efficient way of asking "Do I know about exactly the same set of transactions as bitcoind" (either for the entire wallet or for an account).  That's assuming transaction data can't change (somebody double-check that assumption for me-- if the transaction data changes, then the txid changes... I think).

That led to some brainstorming of computing a hash of all transaction ids (maybe just XOR them all together).  Or maybe something more complicated like a merkle tree...   but that seems like overkill.

Is there a good, simple solution to synchronizing "I have this set of stuff, give me everything I don't have" ?

No, it won't sort itself out "after a few weeks".  Let me see if I can do a back-of-the-envelope:

Difficulty on testnet currently at 373.  We want it no higher than, oh, 5, so with the typical 3-or-4 machines CPU-hashing on testnet generate a block in a reasonable amount of time.

So we generate 2016 blocks over 8 weeks.  That cuts difficulty by four: ~90
Then do it again: ~22
and again... ~5  SIX MONTHS later

That's optimistically assuming we can find people to cooperate to contribute hashing power to generate 2016 blocks at difficulty 300 in 8 weeks or less.

If you'd like to continue using the old testnet chain, be my guest.

I'm sympathetic to the "testnet and main net should have the same rules", but the truth is the testnet has, and always will have, many fewer people hashing on it.

Changing the main net downard-difficulty-adjustment code might make sense, but that's the topic for another thread.  Allowing main net difficulty to adjust all the way from 22,000 to 1 isn't the right answer (it makes sybil attacks where an attacker feeds you a bogus version of the block chain much easier).

Giving them all the same starting wallet is a bad idea; they will start out with the same keys, but will eventually each generate their own, so their balances will drift out of sync.

In theory everything should work out, but in practice using the same wallet on multiple machines hasn't been tested much (I fixed a couple of bugs in the last couple of weeks related to a wallet shared between machines).

So before cloning, delete the wallet.dat (assuming it has no bitcoins in it) and let the clones automatically generate a new wallet the first time they start.

Two thoughts:

listaccounts [minconfirmations]  (also new in 0.3.20, if I'm remembering correctly) will give you all accounts and their balances.  If an account's balance doesn't change, you know it hasn't received coins.

And why do you need to periodically update the user's account/assets?  Could you just query bitcoind for their current balance when they fetch their 'account status' page (or wherever you show the user how many bitcoins they have)?  Are you doing something with the received bitcoins without an explicit action on the part of the user, and does that something care about the total balance or individual transactions?

0.3.20 will support listtransactions '*'  for all transactions.

Transactions since <txid> ....  sounds dangerous.  Are you trying to mirror the transaction database that bitcoin keeps?  If you are, are you sure you'll deal properly with (rare) block chain re-organizations where transactions that you thought had one confirmation turn out to be invalid in a new fork of the chain?

I can imagine subtle bugs-- you ask for transactions since <txid> but that txid turns out to be an orphan transaction (double-spend on the losing side of a block chain re-org) so bitcoin returns... what?

All non-orphan transactions with transaction time equal to or greater than a given timestamp might work-- but what is your use case?

You can setup your own f2f bitcoin network using the -connect option, connecting only to friends.

One of those friends must be connected to the rest of the bitcoin world, of course.

Experimenting with sending transactions and blocks over XMPP or some other network is a great idea-- go for it!  It shouldn't be hard to create a "bitcoin bridge" that relays traffic on the main bitcoin network to/from another network.

So... who's excited about doing either a little wxWidgets programming or a lot of "port the bitcoin GUI to Qt" programming?

This isn't going to happen unless somebody actually does it...

I split this into it's own thread.

Here's a counter-proposal:

All RPC methods dealing with amounts take and report full-precision bitcoins.
E.g. if you have 1 BTC getbalance reports 1.00000000  (as it does now)
The send and move methods will be changed to NOT round to two decimal places.

luke-jr's patch that makes bitcoin avoid creating sub-cent change (when possible) will be applied.

The GUI will be modified to display full precision amounts, and will allow full-precision sends.
  (if you have 1 BTC, GUI should show balance: 1.00
   if you have 1.0001 BTC, GUI should show balance: 1.0001
   ...etc)

A new setting: maxtxfee  will be added, default will be 0.01 BTC.  RPC methods will fail with a new error message if a send/sendfrom would generate a transaction fee larger than maxtxfee.

A new RPC method to change maxtxfee setting (maybe a generic RPC method to change any run-time option that can be changed on the fly?)

The code should be checked and all references to CENT which really mean "minimum transaction fee" should be changed to reference a new "minimum transaction fee" constant (==CENT for now).

Patch/pull request is:
  https://github.com/bitcoin/bitcoin/pull/53

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.