Satoshi has a bunch of features that he 'figured out from the start' that are not implemented yet; I'll ask him if this is one of them after I figure out exactly what feature I want and convince myself it is possible to do securely.  So I'm going to try to gather my thoughts and see if there is much point:

This is the main problem I was trying to solve:

• A merchant's website should give the customer a unique payment address during the chekcout process.  Ideally, generating that unique address would be done entirely on the web server without requiring a RPC call to a bitcoind process running somewhere.

Communicating with bitcoin or some merchant-services website during the checkout process adds another possible point of payment failure-- it is better for the merchant if their customers can continue to pay them even if their bitcoin daemon (or MyBitcoin or MtGox merchant services) is temporarily down for maintenance.

OP_OVER OP_ADD solves that problem, and, thinking about it, has some other very nice properties.  Here's how it would work in practice:

1. Merchant gets one or more public keys to use for payments.  They're stored in the web server's database.

2. Customer checks out:  web server computes HASH160(public_key+order_id), and converts the result to a bitcoin address version#2 (first byte is not base58-encoded-0, but something else).

3. That bitcoin address makes its way to bitcoin software running on the customer's machine (or at an online wallet service).  Since it is a version#2 address, bitcoin creates an OP_OVER OP_ADD.... transaction for it instead of an OP_DUP ... transaction.

4. Merchant's web server software tells a bitcoind running somewhere "if you see payments to HASH160(public_key+order_id), that's one of mine."

5. When the merchant want's to spend the bitcoins it got from the customer, it has to tell a bitcoind running somewhere the public_key,order_id pair.


If the merchant doesn't completely trust the payment processor then keeping steps (4) and (5) separate is very nice-- the payment processor can't spend the merchant's bitcoins until the merchant tells them the order_ids  (merchant would have to use truly random order_ids to be completely safe, of course).

And, as noted before, this is a little more private than standard bitcoin transactions because the public key isn't revealed until the coins are spent.

You might care if you got the dollar bill from somebody you suspect is working for the Secret Police, you think think the Secret Police might be trying to trace payments by recording bill serial numbers, and you're spending the dollar to pay a local print shop to produce some illegal Subversive Propaganda.

That's roughly similar to tracing bitcoin transactions.

How long is the split?  There's really no problem if the split is less than the block generation maturation time (20+ hours)-- a bunch of miners will be disappointed on one side of the split or the other, but that's about the extent of the damage.

Longer than 24 hours... is kind of hard to imagine for a big country.

Would transactions continue to be processed:  yes, but...  the sudden drop in network hashing rate (and the drastic slow-down in block generation) might trigger future safety checks in Bitcoin, so you might have to do something special to tell it "yes, I really do want to generate transactions even though something weird is happening with the network."

If a little country or region got split from the main network, it will probably have a lot less hashing power and it will take much longer to generate the 100 blocks needed to start to cause problems.  That's a feature, not a bug.

After communication was restored the more-difficulty block chain would "win" and transactions from the losing block chain would get retransmitted and move over to the more-difficulty chain.

If somebody had a super-secret communication channel that worked during the split they could use it to double-spend.  But if the bad guys have a super-secret channel then probably some good guys would, too, and as jgarzik points out, it only takes one little link to relay blocks and prevent a split.

Actually, I'm surprised Mark doesn't remember (or maybe he just didn't want to get bogged down in details)-- he paid for my lunch, and I paid him back in Bitcoins.

Which turned out to be a good deal for him, they went from about 40cents apiece to something like 60cents apiece in the week or so it took him to setup a bitcoin account and give me his receiving address (I paid at the 'when we had lunch' exchange rate, of course).

If you have a bitcoin business and are thinking about advertising, FTL listeners might be a receptive market-- and I bet you might be able to convince Mark and Ian to take payment in bitcoin.

... I think that's right, you don't need the OP_OVER OP_ADD.  You have to know the random number to generate a valid signature, given only its hash.

You'd have to be very careful NEVER to use the same random number anybody else has ever used or will ever use; if your 'random' number is an order number (or even common-hash-of-an-order-number) then you're sunk, anybody can generate a valid <signature> <public_key> <r> triple.

For two extra bytes per transaction it might be better to hash in the public key, just so people don't shoot themselves in the foot.

They can only invalidate transactions that they made (or further transactions that spend transactions that they made).  That makes the attack a lot less likely in practice; if they had a lot of bitcoins, and purchased a lot of good or services (or exchanged them for dollars or euros) with a lot of people, then some of those people are likely to know WHO "they" are.  And if they're in the same legal jurisdiction, it seems to me you'd have a pretty good case for suing them for fraud.

Even if 'they' decided to do this just to try to mess up the bitcoin network it might be messy for the exchanges to clean up but I don't think it would cripple them.  The bitcoin client already trys to select "old money" when it creates transactions, so assuming that the exchange has a good cushion of bitcoins on deposit all the attacker is likely to accomplish is to invalidate their own deposits at the exchange.

All that said:  I'm not going to advise people to hold money they can't afford to lose in bitcoins until the network has a lot more hashing power.  There is still some risk while bitcoin is young.

The bitcoin integration/testing source tree is at GitHub, and we (jgarzik/tcatm/gavinandresen right now) use GitHub's "pull request" feature to keep track of patches that people think are ready for integration into mainline bitcoin.  This post is a walk-through of how to create a pull request.

1. You'll need a GitHub account; sign up for free, and set up git and ssh to work with GitHub.

2. You need a fork of the main bitcoin source tree.  Login to your GitHub account, browse to the bitcoin project, then poke the little 'Fork' button near the top of the screen.

3. Connect that fork at GitHub with source code on your development machine.  The easiest way to do that is to clone your github fork, using the SSH Read+Write URL github shows you on your fork's page.  For example:
You might already have a clone of the bitcoin git tree that you've modified; you should push those changes into your new GitHub fork.  Assuming you made your changes in the 'master' branch on your machine (next time you should create a specific feature branch), the command would be:

4. Submit a PULL request by going to your fork's GitHub page, selecting the branch containing the changes you want pulled ("niftynewfeature" in the above example), and then poking the "Pull Request" button.  Enter a good description of what your changes do and why they're a good idea and how everybody and their brother is already using them to make the world a better place .

Eventually, if all goes well, after discussion and argument and nit-picking and revision, your changes will get pulled into the bitcoin repository.  If all doesn't go well, you (or the core developers) can close your pull request and resubmit it when the feature is perfect.

Sirius and I both have access to the webserver, although Sirius knows a lot more about Drupal than I do.

But if somebody puts together Drupal templates (theme?  what does Drupal call them/it?) with the spiffy new look I'd be happy to upload them.  Or, even better, create a Drupal account for that somebody so they can update the look and content themself and fix the bugs that are almost certainly going to happen.

I got this question from an editor at TechWorld.com.au :

... and I'm looking for good answers.

Actually, falling asleep last night I realized what I proposed would be yet another variation on an 'anybody can claim' transaction (anybody can just choose an r1 that make r1 XOR hash_xor_r1 evaluate to a hash that they own).

I think this would work:
... supply <scriptsig> <public_key> <r1> to claim.

I'm not suggesting anything like this get implemented any time soon, I started this thread just to explore what is possible.

Very nice!

The 'sig opcount <= 2' rule for tx relaying is slated to change with the 'sendmany' patch I pulled on Monday.

The new rule will be 'sig opcount <= size/34

Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output.  Make the txout something like:
... and to spend the txin is:  <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160).  Or something like that (I shouldn't be thinking about cryptography when I'm this tired).

Thanks for the link to the wikipedia page in the other thread... so receiver CAN recover 'k' given the public key and signature.

Cool!

That doesn't solve the problem I'd like to solve (because you still need to generate a new keypair for every transaction), but it is cool.

Googling for 'ECDSA broadband subliminal channel' to figure out what the heck you're talking about...

... doesn't that require that the recipient (as well as the sender) know the private key?
(you encode the message in the 'k' param, which the recipient can only recover using the private key?)

It depends on how much you pay for electricity, what kind of computer you own (and what kind of graphics card it has), and whether or not you can figure out how to install and run "GPU mining" software.

Right, that was the problem I was hoping to brainstorm about.  I didn't want to re-open the "add data to the transaction database" discussion (I think "add data to the block chain" is misleading, since transaction data isn't actually part of the block-header-chain or transaction-merkle-tree).

I'm still wondering if there is a way to create transactions on the web server, without talking to bitcoind, using a small-ish number of pregenerated public keys, such that each transaction is unique and competitors can't tell how many transactions belong to any particular merchant.

Pre-generating a bunch of keys works, assuming that competitors don't know the pre-generated keys (bad assumption long-term if they keys are re-used, since they could just order a bunch of stuff and note the keys used for paying).

RE: opening up the "store random stuff in the block chain" argument:

Several things make me not worried about that:

1. OP_CHECKSIG drives network-wide costs (see the thread on network-wide transaction cost back-of-the-envelope calculations).
2. New -limitefreerelay code will, I'm pretty confident, mitigate penny-flooding.
3. 512 bytes plus inputs plus outputs will will make these either "very-low-priority-free" or over 1K non-free transactions.
4. We're past the point where block chain download size is 'convenient' for new users.  We should implement lightweight client mode (download only block headers until you start solo mining) as soon as possible.


RE: pregenerate a bunch of addresses to use for payment:

I like that idea!   If you're getting, say, 20 bitcoin orders a day then 1,000 addresses would last you a month.  And even if you recycled them when you ran out it should be easy to match orders to addresses based on the transaction date and amount...


The whole "click to pay" feature needs to be figured out, and should work nicely in all four cases of (customer,merchant) using (bitcoin,online wallet).  My brain isn't up to it today, though...

The web server doesn't have the bitcoin private key, and the problem I'm trying to solve is an order process where the web server doesn't have to communicate with bitcoin at all to generate the "pay me" address/link.

So I got email today from a merchant asking the most-frequently-asked question:  if I just put a bitcoin address on my "pay me" page, how do I know who paid me?

Which got me to wondering... can we do better than answer "run a bitcoin daemon and ask it for a new address for every order"  or  "use a shopping cart interface from your online wallet provider" ?

Ideally, the web software could generate a payment URI without talking to bitcoind, and copying/pasting or clicking on the URI would generate a transaction tagged with the right order ID.

Adding another transaction type that allows (say) an extra, arbitrary 512 bytes of data mostly solves the problem; the web software could encrypt or hash the order ID and generate a transaction that is the store's public bitcoin address and the encrypted/hashed order ID (or customer number or whatever).

Can we do better?  It would be nice if it was impossible to tell how many orders the merchant was getting...

Focusing on the use cases is the right approach.


One variation:

5. Export keys to transfer funds to somebody else.  Recipient is expected to import and then immediately send-to-self.  Sender keeps the keys 'set aside' in the wallet until they are spent by recipient, or, if not spent by recipient (lost in transit maybe, or recipient chokes on a lollipop before having a chance to redeem), may be added back into the sender's balance.

And one usability comment:

Is "selected keys" the right way to go?  Just selecting an amount of bitcoins to export/send seems like a better way to go (with a send-to-self transaction generated, if necessary, to create the right amount), with maybe an "advanced" option later that lets you select specific inputs to export/send.