Making transactions with non-DER-encoded (aka BER encoded) signatures non-standard has been on my TODO list for over a year now, but has never been the highest priority.  That's the first step to making non-DER-encoded signatures completely illegal.

Note that if there is a core-dumping bug in OpenSSL's decoding code then it needs to get fixed in OpenSSL. Writing a BER decoder just for Bitcoin is a bad idea, it is much more likely our new code would have a crashing bug.

From this very relevant article:
  "Megan McArdle on Arbitrage and Why We Love Being Conned"

+1

I think I've said it before, but I'll say it again: I'll start to worry when there is a quantum computer that can factor 64-bit numbers faster than non-quantum computers. I bet that is at least 20 years away...

Zooko Wilcox-O'Hearn also deserves recognition; he warned us that the method Bitcoin uses to compute the Merkle tree was possibly insecure (although at the time we couldn't see how to turn it into an exploit).

This was a nasty bug; if Forrest hadn't found it and responsibly reported it, an attacker probably could have stopped most of the nodes on the network before we got patched code out. It is bugs like this that make me think that having several different implementations of the Bitcoin protocol is a good idea.

See https://gist.github.com/2355445 .  Specifically, the section that starts "Example: re-define OP_NOP1 to be OP_Q_CHECKSIGVERIFY, using a quantum-resistant digital signature algorithm."

Is bitcoin 2 coming out next month?

No.

Everybody knows eleven is my favorite number, so if there was going to be a major release of bitcoin it would be "Bitcoin 11".  But it ain't gonna happen.

From an email I sent to somebody concerned about bitcoin usability just a couple of days ago:

Making the reference Bitcoin application more usable isn't a high priority for me right now.

The high priority is making it safe to use, even if your computer gets infected by malware. I WANT it to be hard and geeky to use so only geeks who are able to keep their computers secure run it.

Also, the "download and run software on my computer" way of doing things is dying. The vast majority of ordinary users will be using Bitcoin on their smart-phones or through a web browser in the near future....

From the whitepaper:

I'd have to think about it a lot harder than I'm willing to right now to be absolutely sure, but that seems like a mistake to me.

If peers have to fetch inputs and compute coin age to determine whether or not a chain is longest then it seems like that could be leveraged into a denial-of-service attack. Because an attacker could do minimal proof-of-work (or proof-of-stake) but then broadcast a chain with JUST a little-less consumed coin age than the current best chain.

Their chain will be rejected, but their peers will waste time figuring out that it should be rejected.

Also note that Bitcoin does NOT use total proof-of-work-performed to determine the best chain; it uses total proof-of-work-target. That's deliberate; if it used proof-of-work-performed, then if you happened to get lucky and found an extremely small block hash you could hold on to it, build on top of it, and only announce your "more proof of work" chain when the network chain's work started to catch up with your secret chain.

All right, all right, enough speculation.

I'll be announcing http://bitundies.com/, where you will be able to buy high-quality Alpaca wool undergarments for bitcoin.

Before I left for vacation, I submitted a pull request that makes the default policy for miners "more fees == more likely to get into a block."  That will be in the 0.7 release (the policy before was mostly "higher priority == more likely to get into a block"), and I've been encouraging the big mining pool operators to implement something similar if they have their own transaction-selection code.

When I get back from vacation I plan on writing code to watch the transactions that do or do not make it into blocks to derive an estimate of the average miners' fee policy, and use that to recommend a reasonable fee to the user.

Those changes will let fees float naturally-- users and miners will form a market and fees will rise or fall based on what users are willing to pay and what miners are willing to accept. I don't like the arbitrary, centralized setting of fees that we've had up until now.

So while driving across Wyoming today my mind wandered to proof-of-stake.  And whether or not it would be possible to attack a proof-of-stake system by repeatedly sending expensive to verify but invalid proofs of stake.

I think you could.

Example: if the proof-of-stake involves creating a bunch of valid signatures using private keys that you own, then an attacker could buy or create a few thousand keys (e.g. buy 10,000 units of currency and then split them into 10,000 addresses) and submit a proof-of-stake where 9,999 signatures are valid and the last one is invalid.

The proof-of-stake will fail, but it will cost the victims approximately the same CPU time to find that out as it takes the attacker to generate the signatures. If the attacker can repeatedly send the same proof-of-stake, and the victims don't cache the work of checking the signatures, then you've got the basis for a great denial-of-service attack.

Proof-of-work doesn't suffer from this attack, because it is MUCH easier to validate proof-of-work (one hash operation) than to generate it. I haven't thought deeply about whether or not you could come up with a proof-of-stake that has the same "hard to generate, easy to validate" property. I suppose you could require that a proof-of-stake have a small, limited number of signatures-- requiring that stakeholders maintain a small number of large-balance addresses. That's bad for privacy and security, though.

You could disconnect/ban peers that submit invalid proofs-of-stake; an attacker would have to mount a Sybil attack using lots of IP addresses to get around that. That might be a problem in an IPv6 world of essentially infinite IP addresses, though...

A hybrid system that requires proof-of-work AND proof-of-stake might work.  You'd have to be careful to tie the proof-of-stake to the proof-of-work, though, otherwise an attacker might be able to re-use the same proof-of-work over and over.

I'm curious: if you've been working on a proof-of-stake system, is this kind of attack the kind of thing you've already thought about and solved?

I wrote up a step-by-step guide for secure two-person cold-storage escrow using the new 'raw transactions' api:
  https://gist.github.com/3161162

+1

+1 to Sergio's points, too.  Casascius: I think you need to think more like an attacker; if they can cheaply mount an attack, then they will.

For the record:

I've never met Zhou Tong, and wasn't involved in any with with Bitcoinica.

I have met Tihan, Charlie and Patrick (Murck), and they are all responsible grown-ups who, like any of us, occasionally make mistakes. I think they're making a mistake getting stuck to the Bitcoinica tar-baby, but I think y'all should give them a little space because I think they're genuinely trying to help clean up this mess.

Thoughts:

We need better authorization and authentication for payments.  See https://gist.github.com/2217885  for my complete thoughts; the "are you paying who you think you are paying" process is relevant even if you're using a singlesig wallet.

That's not quite right.

The protocol supports it-- just take the output of an unconfirmed transaction (paying to you) and then broadcast a send-to-self transaction that uses it as input and has a big, juicy fee.

I think the Eligius mining pool might even notice and confirm both transactions-- Luke DashJr has a pull request to change the reference implementation's transaction selection code to consider fees for sets of related transactions when deciding what to include in a block.

Good question.

In my humble opinion, the block size should not be arbitrarily limited as it is now (1MB is the limit; typical blocks these days are 30-250K big), but should 'float' -- miners should collectively decide how large a block they're willing to validate and build on top of.

Obviously a miner wants to include as many fee-paying transactions in their blocks as possible, until the fee paid is less than their cost of validating and including the transaction (which is a small cost).

But miners also don't want to spend a very long time validating other miners' blocks, so they have an incentive to ignore blocks that are outrageously big. If they were willing to build on a 10-gigabyte-big block that took ten minutes to download and signature check, then they're shooting themselves in the foot-- an evil miner could mine a huge block, and then get a head start on mining the next block while the rest of the network was busy validating it.

BUT: moving to a floating maximum block size determined by miners will be really hard; it will require everybody-- merchants and miners and users-- to upgrade. It may never happen, because other ways of supporting very high transaction volumes might develop before then.

I just sent this email to the biggest mining pool operators; I think creating a real market between users and miners to set transaction fees is a very high priority.

---

After a lot of thinking, trying a few different implementations, and a couple days of testing I'm finally happy with a new scheme for selecting which transactions to include in created blocks.

Patch for version 0.6.3:
https://github.com/gavinandresen/bitcoin-git/commit/ed0531d8242c75c8c055ec5b4d134d42ea380158.patch

This is pull request #1590 and will very likely be part of the upcoming 0.7 release.

Backported patch for version 0.3.24 if you're stuck on an old version of bitcoind:
https://github.com/gavinandresen/bitcoin-git/commit/57df05e2cd48716ad2fa2e7379d61b980c65aade.patch

These add new command-line / bitcoin.conf options:

The above settings are the default, and match the current default behavior. If you are using a stock bitcoind to create your blocks and apply the patch, the only difference you will see is a higher block reward, because the new code prefers transactions with higher fees to transactions with lower fees.

The new options let you control your transaction acceptance policy without recompiling; here is what they do and how to use them:

-blockmaxsize controls the maximum size of blocks created, in bytes. I know some pools are limiting the size of the blocks they create because they think larger blocks are more likely to be orphaned; this setting lets you do that easily. Reasonable values are between 50,000 and 250,000 bytes.

-blockminsize lets you fill up any 'extra' space in blocks with free transactions, until the block is -blockminsize bytes big. You can use this to implement a policy of "Fill up the block with fee-paying transactions first, but if there aren't enough then include free transactions."  Reasonable values are 0 to blockmaxsize.

-blockprioritysize is the primary way to support free transactions. This many bytes at the beginning of the block are set aside for the highest priority transactions, regardless of whether or not they pay a fee. Reasonable values are 0 to blockmaxsize.

-mintxfee is the minimum fee, measured in bitcoins-per-1,000-bytes, for a transaction to be considered 'paid' instead of 'free.' It should ideally be a little larger than your real-world cost to process a transaction. Reasonable values are 0.0001 to 0.01  (setting this too low is dangerous; a transaction spammer can fill up your blocks with very-low-but-non-zero-fee transactions)

---

So, putting it all together, here are some possible fee policies you might want to follow:

CREATE SMALLER BLOCKS

You want to limit the size of the blocks you create so they propagate faster.


PUNISH HIGH-FREQUENCY USERS

You want to mostly include transactions based on priority, to discourage SatoshiDice-like services where people are sending blizzards of low-value transactions. But you still want to pick up any large-transaction-fee transactions.


MAXIMUM FEES

You want to maximize your block reward, including as many fee-paying transactions as possible but avoiding all free transactions.



MAXIMUM FEES, ALLOW FREE

You want to maximize the fees you get, but allow some free transactions if transaction volume on the network is low.


MAXIMUM COMPATIBILITY WITH EXISTING CLIENTS

If you want the best compatibility with Bitcoin-Qt and other existing clients, use the default values.

---

Next on my TODO list: implement client-side code to figure out what the average miner's fee policy is by looking at how quickly transactions are being accepted into blocks, and recommend a reasonable fee to users on a per-transaction basis.

Yes, partly.

The most important change is having miners sort transactions by fee-per-kilobyte, and prefer higher-fee transactions to lower-fee transactions. That way users that want their transactions to get confirmed quickly can pay a higher-than-average fee. Today, most miners are using the reference code which selects transactions based on priority, not fee.

Still todo: give better recommendations to users about how long it might take their transaction to get confirmed if they send it without a fee, and recommend an appropriate fee.

Self-correcting assuming there are good market dynamics between miners and users.  That's broken right now, but I'm working on fixing it (see pull #1590 for the first step).