Latest posts of: Gavin Andresen

Quote from: ThiagoCMC

There are rumors that the Bitcoin network will split in two, one side, people using 0.5.1, 0.4.0.... On the other side, people using 0.6.0...

I've been working hard to make sure there will be no blockchain split, and I've convinced myself I've thought through all the "old/new client sending transactions to an old/new miner" cases.

The only case where an old miner could be split off the network is if they are mining non-standard transactions (which means they've modified their mining code) and do not upgrade. If you are in that situation, then you should either stop adding transactions containing OP_NOP1 into your miner's memory pool or upgrade to interpret OP_NOP1 as OP_EVAL.

But I've said it before and I'll say it again: don't trust me. I make mistakes. Two serious bugs in my OP_EVAL/multisignature code have been found (and fixed) in the last week. Version 0.6 will have at least a month of release candidate testing.

I still firmly believe the benefits of the new 0.6 features far outweigh the risks. Please help minimize the risks; review code if you can, run release candidate on the testnet and try to break them, read the BIPS and try to think of ways bad people might use them to do bad things. Review the contingency plans and think about how they could be improved or if you could help when (when, not if) vulnerabilities are found.

makomk reported a remote vulnerability that I pulled into the master bitcoin/bitcoin tree on December 20. If you are running git-HEAD code on the production network you should pull the latest code to get the bug fixed.

This affects only anybody who has pulled and compiled their own bitcoind/bitcoin-qt from the source tree in the last 5 days.

Gory details:

I made a mistake. I refactored the ConnectInputs() function into two pieces (FetchInputs() and ConnectInputs()), and should have duplicated a check in ConnectInputs for an out-of-range previous-transaction-output in the FetchInputs() method. The result was a new method I wrote to help prevent a possible OP_EVAL-related denial-of-service attack (AreInputsStandard()) could crash with an out-of-bounds memory access if given an invalid transaction.

The bug-fix puts a check in FetchInputs and an assertion in AreInputsStandard. This does not affect the back-ported "mining only" code I wrote that some miners and pools have started using.

The good news is this was found and reported before binaries with the vulnerability were released; the bad news is this was not found before the code was pulled and could have made it into the next release if makomk had not been testing some unrelated code.

Before releasing 0.6, I would like to have an "intelligent, bitcoin-specific fuzzing tool" that automatically finds this type of bug that we can run before every release. If anybody already has one, please speak up!

Quote from: casascius on December 24, 2011, 05:47:54 AM

The most important metric would be when the block was received. If I receive a block that tries to replace a block 6 or 10 or 100 blocks ago on the chain I already know about, and I have no reason to believe I've been segregated from the network at large, I'm not going to vouch for it.

Yes.

The times the blocks are announced also matters; if my node suddenly sees a longer 10-block chain it has never seen before, then either it is a 51% attack or the network was split and just came back together.

If the network was split 10 blocks ago then I should see that those 10 blocks took twice as long to create as expected.

Rating blocks is a neat idea; I can think of several potential criteria, there are probably more we could come up with:

Did I first see the block announcement long after the block's timestamp?
Does it look like it is part of a network split? (two chains that are both producing blocks more slowly than usual)
Are they part of a sub-chain with a 'normal' distribution of blocks from the well-known mining pools? (an attacker's chain won't have blocks from ANY of the mining pools)
Does it contain any double-spends that conflict with alternate chains I know about?
Do the transactions in it look 'normal'? (reasonable number of transactions, reasonable amounts)

Somebody should simulate some 51% attacks and network splits and try out various detection algorithms.

And maybe see if it would be practical to have a checkpoint lock-in rule of something like "auto-checkpoint any AAA-rated block once it is 4-deep in the best chain". I don't think that should be built-in to bitcoind, but a little side program that monitored the block chain and the pools and told bitcoind to add a checkpoint once an hour or so would be pretty spiffy...

I was working on user-defined checkpoints today-- command-line/bitcoin.conf (and maybe a RPC call) that just says "Add this block hash at this height as a checkpoint."

You and your 10 trusted friends could then run a little program that coordinated automatic lock-ins whenever you like...

https://github.com/bitcoin/bitcoin/pull/727 :

This is designed to work nicely with 'gettransaction' and new 'blockhash' information returned in listtransactions; it is modified from the 'getblock' that was in my monitorreceived patch.

getblockhash <index>
Returns hash of block in best-block-chain at <index>.

e.g. getblockhash 0 returns 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
(genesis block hash)

getblock <hash>
Returns details of a block with given block-hash.

e.g. ./bitcoind getblock $(./bitcoind getblockhash 0) returns the genesis block:

Code:

{
  "hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
  "blockcount" : 0,
  "version" : 1,
  "merkleroot" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
  "time" : 1231006505,
  "nonce" : 2083236893,
  "difficulty" : 1.00000000,
  "tx" : [
   "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"
  ],
  "hashnext" : "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"
}

Quote from: netrin on December 23, 2011, 05:46:08 PM

Is that gavinandresen/bitcoin-git or bitcoin/bitcoin? If I also pull the anon-ish 'coin control' is that likely to interfere with 0.6 testing? How and where would you prefer test feedback?

bitcoin/bitcoin is the 0.6 tree

I haven't done a code review of the anon-ish coin control, so I don't know if it will mess up 0.6 testing; it might interfere with the multisignature transaction changes.

The github issues tracker is the best to report any bugs you find, for general "it sucks" or "I love it" or "can you make this new RPC command to this" the best place is either IRC chat or right here.

So...

I've been mostly quiet about the alternative block chains, but I have to say I'm a little disappointed.

I had hoped that they would be full of interesting experiments with different transaction types or smart contracts or different fee-setting algorithms or maybe some innovative scheme for instant transactions.

Instead, it seems like you've been too busy dealing with low hashrates and transaction-spam attacks, and have been spending all of your time re-inventing a lot of infrastructure (exchanges and block explorers and mining pool software and etc.).

I'm curious to hear what other people think: will altchain innovation pick up in 2012? Am I irrationally biased and just not seeing the awesome power of (insert-your-favorite-altchain-feature-here)?

I think there's an interesting dynamic, where the larger and more popular an altchain gets, the harder it is to do things like schedule a block-chain splitting-change (because you have to get all your exchanges and mining pools and etc. to upgrade). I wonder if that means the experimentation will only happen with brand-new blockchains, and if a blockchain will only really take off it the inventor manages to "get it 99% right" the very first time...

Quote from: SAC on December 22, 2011, 07:50:48 PM

Is it wise to download any of the binaries around here, unless you audit all the code yourself before compiling it you should not be running any of it with that concern...

Run them inside a virtual machine that you don't use anything else for and you're almost certainly safe.

OP_EVAL, and OP_EVAL-bitcoin-address support were pulled into the master git branch two days ago; the plan is still to evaluate miner support on January 15, and if a majority of miners are supporting it (looks like that won't be a problem), to roll out version 0.6 with the low-level support fully enabled.

And Luke-Jr is correct: sending coins into an OP_EVAL transaction is perfectly safe, but until February 1 it will be unsafe to spend them.

BIP 11/12/13 support is Core functionality only for 0.6-- the network needs to support the new transaction types BEFORE users start using them.

The coinbase must be between 2 and 100 bytes long and must be valid when deserialized as a "CScript", but may contain arbitrary data.

Block 158479 looks like it is doing merged mining.
The '07456c6967697573' at the start is the string 'Eligius'.
The stuff in the middle looks like hashes for other block chains.
And the '074f505f4556414c' at the endis is the string 'OP_EVAL'.

No, I bet nobody knows if or how TD F 90-22.1 applies to Bitcoin.

I am not a lawyer, but I bet the IRS would say that you should report any funds greater than $10,000 held by non-US bitcoin exchanges or wallet services.

I don't know what the IRS would say about Bitcoins held on a server that you control but that happens to be located outside the US, or if it would matter if they were also held on your computer or printed out and stored in a safe deposit box somewhere in Kentucky.

Reposting from email to bitcoin-development mailing list:

I've been busy pulling patches into git HEAD for a Bitcoin version 0.6, with the goal of having a Release Candidate 1 out in a couple of weeks.

So if you've done all your Christmas shopping and have time to help test, code review, etc. now would be the time.

Major changes pulled so far:

Implement BIP 11/12/13:
  "Standard" multisignature transactions
  "Standard" OP_EVAL transactions
  OP_EVAL bitcoin addresses
Implement BIP 14 (separate protocol from client version)
Private key import/export (RPC commands, not GUI)
New DNS seeds

Quote from: Gabi on December 21, 2011, 02:50:10 PM

The problem is, the bitcoin client SUCKS. It sucked 6 months ago, it sucks even more today with version 5 (congratulations, you managed to make it suckier... the impossible made possible)

If I thought that downloading and installing software onto your computer is the way to go then I'd be helping make it better.

I don't. I think 90-something-percent of future Bitcoin users will be using it on an iPad or mobile phone or on their computer in a web browser.

I'm sorry you think 0.5 is worse than 0.4, but you're in the (vocal) minority. Nobody stepped up to support the 0.4 wxWidgets-based GUI, and we've got several people working on the 0.5 Qt-based GUI, so I'm confident switching was the right decision.

Quote from: bithobo on December 20, 2011, 02:00:44 PM

You know what? Screw global warming for now. How would a libertarian society handle the current level of water poisoning? Fish are dying out, more and more beaches fill with algae, rivers are full of waste (from detergents to artificial manure) etc. None of these things visibly influence businesses that make the mess. How free should this market stay?

The standard answer is if the river is owned, then the owner(s) of the river will have the right incentives to keep it unpolluted. See, for example: http://www.cato.org/pubs/journal/cj1n2-6.html

If you care about clean rivers, then buy them (or donate money to an organization that buys them; the Nature Conservancy is one of my favorite charities).

It is the Chinese government's river, not the free market's, why are they tolerating all the pollution?

Global Warming and air pollution is a stickier problem because nobody owns the climate or the air we breathe, and nobody CAN own them. Personally, I think we do actually need good government for some things, which is why I describe myself as "mostly libertarian".

And if I were King, I think I'd implement the Cato Institute's suggestion and give all of our National Parks and public wilderness to private environmental organizations to take care of (or sell, if they decided they could put the money to better use for something else).

My reaction to Ben Laurie's papers:

Incentives matter.

Yes, it is true that we cannot be absolutely, positively safe against a 51% attack unless we are absolutely certain 50% or more of the world's entire computing resources are dedicated to Bitcoin mining.

So what?

The natural incentive for somebody with lots of hashing power is to profit by playing by the rules, NOT to cheat.

And if you assume that your attacker is Rich and Powerful but Economically Irrational, then any alternative system that you propose will almost certainly be at least as vulnerable as Bitcoin. Create a system that requires 500 semi-trusted "mintettes" that all agree on a transaction log and then imagine 251 Special Agents infiltrating and corrupting the organizations that run those mintettes.

Increase the number to 40,000 mintettes to make it harder... and you've just re-invented Bitcoin.

RE: documentation about key encryption:

See the comment at the top of crypter.h:

Code:

Private key encryption is done based on a CMasterKey,
which holds a salt and random encryption key.

CMasterKeys are encrypted using AES-256-CBC using a key
derived using derivation method nDerivationMethod
(0 == EVP_sha512()) and derivation iterations nDeriveIterations.
vchOtherDerivationParameters is provided for alternative algorithms
which may require more parameters (such as scrypt).

Wallet Private Keys are then encrypted using AES-256-CBC
with the double-sha256 of the public key as the IV, and the
master key's key as the encryption key (see keystore.[ch]).

The way I think of it: Take the passphrase and salt and SHA512-hash them nDerivationIterations times. That gets you an encryption key and initialization vector.

Use those to AES-256-decrypt the encrypted_key master key.

Now you can AES-256-decrypt the private keys, using the master key as the key and the (double-sha256-hash) PUBLIC part of the keypair as the initialization vector.

The "SHA-512-hash them a bunch of times" is actually done by the OpenSSL EVP_BytesToKey routine-- documentation for that is here: http://www.openssl.org/docs/crypto/EVP_BytesToKey.html

Quote from: cypherdoc on December 17, 2011, 06:20:37 PM

i hadn't backed up my wallet for a while and just noticed that there is now a wallet.dat and a wallet.dat.rewrite in my Bitcoin folder. which is the real private key wallet that needs to be backed up?

wallet.dat

wallet.dat.rewrite SHOULD be automatically removed as part of the upgrade-to-0.5 process; I don't know why it isn't in some cases-- and, frankly, I would much rather spend time getting really, truly secure wallet solutions working.

RE: bitcoin version 0.4 starting up on your machine:

You should run the old bitcoin, un-check the "start on windows system startup", then exit.
Then remove it using the Add/Remove Programs control panel doo-hickey (did that move again in Vista?). You should see both "bitcoin" (the old 0.4) and "bitcoin-qt" (the new 0.5).

... all of which is, I know, annoying and painful. Again, frankly, I'm more interested in spending time on the very-highest-priority issues rather than making every beta release upgrade completely smooth in all cases.