I was thinking of a kind of replay attack:

+ Control the TPM's view of the world (e.g. make it seem like it is Jan 1, 2010)
+ Get the TPM to sign a small transaction, shut it down.
+ Increment time, get it to sign another transaction
+ Repeat.

Replace "time" with "blockchain" and you've got the same problem: can the TPM know that it's view of the external world is correct?  If it sends a nonce (to prevent replay attacks) to some external service that adds a timestamp and signs it with a public key known to the TPM code... then we're back to using two different servers.

Great ideas, Mike. I think the "use two servers" approach will happen first (you typically want at least two servers anyway just for backup and redundancy), but trusted code running in a TPM could be an extremely powerful and cost-effective building block for much more secure solutions.

RE:

That seems like the hardest problem.

Does the TPM have access to a guaranteed-to-be-unhackable time source? If it does, then a policy like "do not approve more than X bitcoins worth of transactions in timeperiod Y" should work well enough to prevent more than petty theft, assuming you've got some other way of watching the blockchain for unauthorized transactions and shutting down the compromised machine or using an emergency offline backup key to move the funds to a non-compromised wallet.

RE: tx replacement:

Somebody aught to start experimenting with transaction replacement with testnet-in-a-box.

Put together a test plan, modify the code and try to break it.

Assuming it all works, submit a pull request to enable transaction replacement on testnet (with a pointer to your test plan and results of testing, please).

Then we can start trying to break transaction replacement on testnet; again, assuming no bugs/hacks/issues turn up after "enough" testing, and if there's general consensus that the benefits outweigh the risks, it could be rolled out to the production network.

We just pulled a DoS fix involving filling up memory with orphan transactions; one concern with transaction replacement is DoS (could I fill up the memory pool by spamming "will be replaced" transactions?)

Those 0.002 bitcoins cannot be redeemed, because there is no input that will make that script valid (because there are no OP_ENDIF opcodes in there to match the OP_IFDUP/OP_IF opcodes).

If you're using multisig to secure your wallet, then I think backup could be "free" ; all the involved multisig keys could be derived predictably from singlesig keys that you'll already need to backup. Disaster recovery from a lost wallet would mean importing all the backed up singlesig keys, then deriving (say) the first 1000 multisig ScriptSigs that would have been derived from those keys and scanning the blockchain for transactions involving those (and, hand-wave, hand-wave, doing something smart to derive more than 1000 in case it looks like more than 1000 were used).  (or, in other words: what kjj said)

If you're using multisig for escrow involving other people... then the escrow transaction has to be recorded and backed up, including all the keys involved.  In that case I'm pretty sure you'll want to record and backup other information about the escrow-- like "100 BTC escrow to my cousin Bob; release them if he's still not smoking on June 1."

Backup should be part of the user experience design for the escrow function; for example, I think a lot of escrows will an associated date, so the client should store the escrow transaction id AND the public keys involved in the escrow AND a "remind me to do something on June 1" AND (maybe) a link to my Address Book entry for Bob so I can call him on June 1. For me, I think the best way to backup that kind of escrow information would be for the client to send me an email containing all of that stuff in a standardized mini-file-format; I'll let gmail archive it and that would be my emergency backup.

So, emergency recovery of a lost wallet would then be:

1. Recover all private keys from paper backup (or whatever the singlesig backup solution is).
2. Re-import all escrows that involve other people from email archive.


RE: Bytecoin and "OR BACKUP_KEY" :  In either the OP_EVAL or the BIP16 case you need a new type of 'standard' transaction (and bitcoin address) to make that work.

Nice!  Thank you very much for looking deeply into this; it looks like the inter-process-communication doo-hickey bitcoin uses to handle bitcoin: URLs was left behind when you blue-screened, and that's making startup fail the next time around.

The dreaded DB_RUNRECOVERY...  that's usually caused by running an older version of BDB (0.6 is compiled against BDB 4.8) on a datadir written with a newer version of BDB.

Recovery isn't hard; just delete the .bitcoin/database/log.000* file(s) and any .bitcoin/__db*.log files.  Were you previously running a self-compiled version of Bitcoin?

From http://subversion.apache.org/faq.html#divining-bdb-version  :

... will show what version of BDB the log files were written with.

FYI:

The Bitcoin Faucet bitcoind's are both running on a Linode VPS, which was mysteriously restarted 14 hours ago.  The 5 bitcoins in the main-net Faucet's wallet were stolen, also; I'll shutdown the Faucet website, do NOT donate any coins to the Faucet donation address, it is controlled by the thief.

Transaction ID:  14350f6f2bda8f4220f5b5e11022ab126a4b178e5c4fca38c6e0deb242c40c5f
... if you want to start watching where the coins end up.

Windows, Linux and Mac binaries for 0.6rc2 are up at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

Please use github to report bugs:
  https://github.com/bitcoin/bitcoin/issues

Note that there were a few "release candidate 1 doesn't work on Windows" bug reports that, as far as I know, have not been fixed. We need some good Qt-on-Windows developers to help out, none of the current core developers use Windows as our primary development platform.

A lot of bug-fixing happened between release candidate 1 and release candidate 2, but we did also sneak in one major new feature that was long overdue:  a Backup Wallet menu entry.

Be aware: the 0.6 release will create wallet.dat files that will not work with older releases, so you should back-up your wallet before running in case you need to revert back to an older release. 0.6 doesn't mark the wallet as backwards-incompatible until a new 'compressed' keypool key is added, so until you do something that generates a new key the wallet will stay compatible. Compressed keys will benefit everybody by using less network bandwidth, allowing more transactions to fit into each block, and making the blockchain smaller than it would otherwise be.

Even a little time testing helps a lot; if you do can do some testing please reply in this thread with a message like "Bitcoin-Qt and bitcoind both worked nicely for me on my OS 10.6.8 Mac, running on -testnet."

From the arimaa whitepaper:
Right-- good luck with that! Any system that relies on Wise, Efficient and Effective Bureaucracies to decide hard questions like "are these 400 accounts really one scammer trying to get more than their fair share" are doomed to fail if they ever get large enough to attract the attention of scammers.

If you have a really good automated way of telling the scammers from real people that doesn't require them sending in a DNA sample or body part, please let me know. I could use a good solution for the Bitcoin Faucet.

This would replace the existing JSON-RPC getmemorypool command?


And a meta-question: are there any other implementations that will be supporting external mining via JSON-RPC soon? There's no reason to go through the whole BIP process to make a change or improvement to one implementation.

Do you have to talk about those three projects?

How about Bitcoin-Charity.com or CoinWorker.com for projects that aren't so potentially controversial?

https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

... but it is pretty narrowly targeted at stress-testing the transaction validity code.

Last year at the NYC conference I mentioned that I would really like to see somebody who knows a lot more about network simulation than I do develop tools to help test proposed protocol changes, simulate Sybil or DoS attacks, etc.

I'd still really like to see that...

eleuthria is right.

The bad-for-not-upgraded-miners scenario is:

+ Somebody gets a valid BIP16 transaction into the chain.

+ They then spend that transaction by broadcasting a 'standard', non-BIP16 transaction, BUT they create a signature for the BIP16 part that old miners consider valid, new miners consider invalid.

+ The old miners will add that 'poisonous' transaction to their memory pool and if they include it in the blocks they mine then those blocks will be rejected by most of the network.

makomk pointed out a while ago that I hadn't noticed that old miners will accept spends of half-valid BIP16 transactions, because the old code doesn't check to see if a transaction is spending a non-standard input. He's right; one of the changes in the 0.6 release is an AreInputsStandard() method, to make upgrading smoother next time.

Executive summary:  if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well)  or there is a good chance you'll produce nothing but orphan blocks.  I welcome suggestions on how to effectively get that message out to the community.

Reposting from the bitcoin-development mailing list:

---

Mining support for BIP 16 is still under 50%, and won't possibly be over 50% by March 1.  Which means we need a new evaluation/switchover date:

Re-evaluate support: March 15'th
Target switchover: April 1

If you're already supporting BIP16, restart bitcoind with the argument:
  -paytoscripthashtime=1333238400

... to delay switchover until April 1.

Hopefully this will be the last delay; Tycho has told me that the deepbit pool will support BIP16 as soon as he's able to merge and test the changes, which will put support at well over 55%.

---

If you are a solo or p2pool miner you are strongly encouraged to upgrade bitcoind/Bitcoin-Qt in the next month; if you don't, you risk creating orphan blocks that the rest of the network will reject (and that risk will rapidly become greater over time as BIP16 transactions start to appear in the main block chain and get relayed across the network).

In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin.

The poll in this thread says the community prefers BIP 16.

The chart on the bitcoin wiki says the core developers prefer BIP 16.

And the actions of the big mining pools and independent miners says that they overwhelmingly prefer BIP 16.

Luke, I'd be delighted to add Eligius to the list of pools that are supporting BIP 16 in my signature.

I think you might be conflating two costs:

Cost #1 is the cost to get a bunch of domain transactions accepted.

I believe pent's proposal is based on additional difficulty, which will be independent of the bitcoin price.

In other words, if bitcoin difficulty is 100, then maybe you need to solve a difficulty 110 block to get your additional DIANNA data accepted by the other DIANNA nodes who are maintaining the key:value database.

If bitcoin difficulty rises to 1 million, then you need to solve a difficulty 1-million-and-ten block to get your data accepted.

The additional difficulty factor should be set by the DIANNA nodes based on their ability to process/store data. More thinking is needed about what that function looks like (it reminds me of the bitcoin fee algorithm; it's trying to solve a similar problem, preventing spam/abuse but allowing as many transactions as possible for the lowest possible price).

Then there's a completely separate Cost #2, which will be higher than cost #1, that is the payment that miners (aka registrars) will charge to handle domain transactions (and do the work of bundling them up, creating some sort of summary hash, and getting that hash into the bitcoin block chain).  That's just a free market.


(I'm completely ignoring Cost #3, which is the "what if I want to purchase an existing domain" price, and is whatever the owner is willing to sell it for.)

Yes
Yes, you could do it that way, re-using Bitcoin's Script system for signatures.  I suppose it might be useful to require m-of-n signatures for a domain to be transferred to somebody else.  I wouldn't make them full-fledged Transactions, though (multiple "inputs" to a domain renewal or transfer doesn't really make sense, for example).


Yes, I think that's right, although I was imagining that the DIANNA and bitcoin difficulties would be kept separate and not combined. Combining them is probably a better idea (if you find any blocks that satisfy the bitcoin difficulty but not the DIANNA+bitcoin difficulty you can still announce them on the bitcoin network and get the block reward).

RE: what is the incentive for maintaining the DHT:  the registrars/mining pools would, I think, be the primary maintainers of the DHT and their incentive to maintaining it is the registration fees that they charge.

I haven't thought deeply about possible attacks; if a DHT is used then you have to defend against Sybil attacks (you must have some way of checking to make sure the data you get from the DHT is valid, e.g. have the DHT nodes return a Merkle branch down to the data they're returning that you can verify hashes to the correct Merkle root).

I should have made it clear:  I imagine there will be an arbitrary number of registrars. They will compete to provide the best service (fastest updates of the DNS database, lowest prices, etc).

If you were willing to do the proof-of-work and insert your own updates into the bitcoin block chain then you could be your own registrar (I assume most people won't be willing to setup the necessary software, run it, etc. just to register a couple of domain names).

I really like your idea of scaling up difficulty based on the number of domain operations in a block to prevent the key:value database from growing arbitrarily big.

It seems to me that should be enough to make domain operation pricing correct; I don't see why there needs to be a block reward or fees, I assume the registrars will charge whatever they need to charge to make a profit, and I would strongly encourage you to avoid making the DNS system yet-another-currency.  I'd like to use dollars or euros or bitcoins (preferably bitcoins) to pay for my domain names, please.

I imagine a system something like:

+ I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna'

+ The registrar makes sure the register/renew/transfer operation is valid

+ The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes

+ After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash.

+ The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records.