Yes, the delivery address and the fact that you're selling a physical product (the USB stick).

Kind of like how you used to be able to buy cheap OEM copies of software but they had to ship a token piece of hardware in the box so they could say they were hardware vendors...  (actually, can you still do that any more?)

Good Idea.  I think the PDF signing is overkill, but Good Idea.

Here's a bitcoin business I want somebody to create and run:  "Coin on a Stick"

You sell USB sticks containing Mac and Windows versions of the latest bitcoin (including the entire block chain) plus a wallet file containing N bitcoins.

Sell them via Ebay or PayPal, and ship them ONLY to a PayPal-verified address.

The buyer has to trust you not to double-spend the coins in the wallet, and has to wait for delivery of the physical USB stick.  But they don't have to download or install anything (they should be able to just run bitcoin from the stick and transfer the coins to themselves or a mybitcoin or mtgox account).

But, since you are sending a physical product to a verified address, you'll be treated as any other merchant selling real goods by PayPal or the credit card companies.

So if the merchant sees an attempted double-spend within 5 seconds they accept the bitcoins but don't give the merchandise/service/whatever.

That sounds like a good idea to me.  Maybe instead of 5 seconds it aught to be "before the transaction is fully confirmed."

The only drawback I see is buggy clients that might have bugs that cause 'honest' double-spending mistakes.

Oh, and merchants would have to explain to customers whey they kept their double-spent coins (although the merchants could easily produce both transaction IDs to show the world that it WAS a double-spend, so they shouldn't have to worry about their reputation being sullied).

Sure, every block has a unique hash.

But I don't think that helps at all; you might see that transactions A B C D are in block #100,000 with hash H1, but after a block chain re-org block #100,000 might contain transactions A D (with block hash H2).

The probability of that happening rapidly approaches zero as the block gets confirmed; after 6 confirmations you can safely assume it just won't happen.

The fool-proof way of dealing with your use case (customer orders something, you want to ship after you're sure payment has cleared):

+ Give each customer an account.  When they order, use getaccountaddress to get a bitcoin address to which they can send payment.

+ Every N minutes ask bitcoin either the balance (with minimum 6 confirmations) for accounts with pending orders or all accounts

+ If the account balance is enough to pay for the order, ship it and move the coins from the customer's account to a PAID account.
   If not... either wait or tell the customer they paid the wrong amount or maybe refund any extra they sent (you'll have to ask them for a refund address).

The inelegant polling will eventually be fixed by bitcoin POSTing when new blocks or transactions arrive, but I think you'll still need to ask bitcoin what the account's current balance is-- trust me, you really don't want to recreate all the bitcoin logic dealing with double-spent transactions or block chain reorganizations.

If you grow to handling thousands of orders per day (which would be a very good problem to have) you'll want to buy or build a version of bitcoin optimized for high-volume transaction websites.  Or maybe you'll run 20 bitcoinds, each handling 1/20'th of the customers -- I dunno, I don't spend a lot of time worrying about problems I'll have when my project is outrageously successful.

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