The advice here is very relevant:
  http://producingoss.com/en/money.html

Why the change:  because it is twice as fast to compile just 32-bit, a 32-bit-only executable is smaller and faster to download, and there is no advantage to running 64-bit (bitcoin doesn't need more than 4 gigabytes of memory, there are no performance-critical routines that would be faster running 64-bit, etc).

If there's a good reason to compile 64-bit, or if we ever drop support for 32-bit Macs then a 64-bit version would make sense.

BIP 12 says:  "If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2."
I waffled on whether to propose any recursion at all, but I think just a touch of recursion will be safe and very useful.

And I wasn't clear, because I'm just thinking out loud:  I meant take two big 256-bit random numbers (call them n1 and n2) and then produce three keypairs, where the private keys are n1, n2, and n1*n2.  Thinking a little further, a 2-of-2 with that key arrangement gives a kind of "a and b OR c" ...  but if c knows both n1 and n2 then the n1*n2 is redundant....

Anyway, my point was that with some cleverness I think lots of things become possible with just what is proposed with BIP 11, and I'd like to give people time to explore what can be done and figure out how to make this stuff easy to use before thinking about even more complicated transaction types.

Yes, it ignores the block.

Pulling out just the detect-too-low-difficulty-blocks parts wouldn't be terribly hard.

(A-and-B)-or-C will wait for another BIP; there are some nifty (and generalizable) ways of doing that by using OP_EVAL recursively that have the added benefit of keeping never-used public keys out of the blockchain.

(1,1) is silly but standard according to BIP 11.  It is just a slightly larger version of the standard <sig> <pubkey> OP_CHECKSIG form used by most coinbase transactions.

I think (1,2)....(3,3) combined with all the things that can be done with deterministic keys or "I only have part of the private key" or other tricks will enable plenty of innovative solutions.

Just thinking off the top of my head: what interesting things could you do if you create 3 keys, where the private key for the third is the product of the first and second?  If you make them a 2-of-3-to-redeem, is that the same as an (a and b) OR c transaction?

I think the version on the bitcoin wiki ( https://en.bitcoin.it/wiki/BIP_0011 ) is a little more up-to-date, but you should check with genjix, he's the BIP-meister.

Pull request for BIPS 11 12 and 13 is here:  https://github.com/bitcoin/bitcoin/pull/669
Unless I hear objections, I'll probably pull it tomorrow.

How:

CNode::Misbehaving(int howmuch) is called when code detects that a peer is doing something out-of-the-ordinary.  In this case, if a peer sends you a block that can't possibly be in the best chain, Misbehaving(100) is called.

When a Node accumulates a misbehavior score greater than or equal to "-banscore" (default 100), their connection is dropped and their IP address is banned from reconnecting for "-bantime" seconds (default 24 hours).

When are they un-banned:

After -bantime seconds. But the list of banned IP addresses is stored in memory, so if you shutdown and restart bitcoin everybody is un-banned.

There is no way to see the list of currently banned nodes, but you will see "Disconnected n.n.n.n for misbehavior" and "connection from n.n.n.n dropped (banned)" in the debug.log.

Interesting idea!

Thinking out loud...  There Doesn't Have To Be One Way To Do It.  Piuk (or somebody) should hack together a client or miner that uses a ledger system; it could refuse to relay or include any transactions with inputs smaller than 0.001 BTC, so it only needed a truncated ledger to create new blocks (if it is a miner, maybe it connects to a trusted 'traditional' bitcoin node to make sure it only builds on valid blocks which might contain tiny inputs).

I don't know nuthin about merged mining-- anybody have objections to Luke-Jr's pull?

My only concern is: will this be a "used by exactly one person (the Eligius pool)" feature?

Neat idea!

Umm, they seemed to be doing OK overall when I was there a couple of years ago, despite the horrible drought, terrible floods, and Hurricane Yasi.


I'm all for doing things to keep people from dying and suffering. Rereading the IPCC report, the big killers/dangers will be an increase in malaria and other diseases in poor countries.

It seems to me policies that make the poor countries richer (free trade, open immigration, stable political institutions and rule of law) is the best way to tackle those problems.

Or to put it another way: The US will probably spend years arguing over whether or not a carbon tax (or cap and trade or whatever) is a good idea (I'm watching to see what happens with Australia's carbon tax with great interest, by the way). Maybe we'll eventually pass one and reduce our carbon emissions.

I predict that will just move carbon-intensive industries somewhere else in the world, and carbon emissions will continue to rise.

I think it would be better to spend the time arguing over what we could do to help make poor countries rich. Or argue for open borders so poor people in places that are getting flooded (don't buy real estate in Bangladesh...) have a place to go.

Or, if you REALLY think rising CO2 levels will be a catastrophe, then rich countries or individuals should create solar-powered CO2 scrubbers and spend money installing gazillions of them in the desert.  Because betting on the whole world coming together and agreeing to do something is about a million times less likely than getting everybody on this forum to agree on... well, pretty much anything.


Don't buy real estate in Florida.  New York will be mostly OK ("The average elevation of Manhattan is reported to be 29 meters (97 feet"); I can't find a mean elevation for LA, but city hall is 300 feet above sea level so unless you buy beachfront property you'll be OK.

With global warming, we're talking changes that happen over a hundred or three (or more) years. I may be wrong (I often am), but I'd be the big worry 100 years from now will not be global warming, but something else.  Maybe running out of Unobtanium for our flying cars....

Maybe it is because I am married to a geologist, but I tend to look at a longer timescale. When the dinosaurs were around CO2 concentrations were up around 3000ppm.

I'm not saying there will be no effects of global warming-- I am claiming that we, and mother nature, will adapt.

We could argue about whether it would be less expensive or better to change our behavior now rather than just adapt later-- last I looked, adapting by (for example) moving inland and abandoning low- lying cities and countries was estimated to be cheaper than spending money to reduce CO2 emissions.

How far back in history do you have to go to find a time when the Earth couldn't support human life?

If I recall correctly, CO2 concentrations were pretty darn high when the dinosaurs where walking around. There were no people around then, but I don't see any reason why we couldn't live in a much warmer, wetter world.

You got it backwards. The dinosaurs came after the mass extinction of other species.

Which is kind of my point: if there IS a mass extinction event, then that sucks for the species that go extinct. But new species will arise that are well-adapted to the new climate. And we humans are a pretty darn adaptable species...

So go implement it and see how well it works.

Create a little HTTP-based protocol with, oh, three methods:

• You send a block height or block hash, you get back a ledger hash.
• You send a ledger hash, you get back the full ledger or an "I have no idea what you're talking about, that's not a valid ledger hash".
• You send two ledger hashes, you get back the changes from one to the other or an "I have no idea what you're talking about, one of those isn't a valid ledger hash".

Then you just need to convince a bunch of semi-trustworthy people to run "ledger servers." And maybe have some mechanism for reporting when a ledger server has a bug or 'goes rogue' and reports a ledger hash that is different from everybody else.

Oh, and you might need to solve the incentive problem of "why would I run a ledger server if I'm not paid for it" (and maybe write a bunch of denial-of-service-prevention code in case some jerk with a botnet decides to ask for 10,000 full ledgers from 10,000 different IP addresses).

I didn't read through the whole "what is the Libertarian solution to Global Warming" thread, so excuse me if I'm saying what somebody else has said.

And I'm not a climate scientist (although I am married to a geologist who is a professor in the same department as Ray Bradley and several other world-class climate scientists), so I can't assess the scientific literature and pick apart various estimates of CO2 sensitivity or urban heat island effects on weather stations or ...

But it seems to me pretty clear that there is a clear consensus among scientists that Global Warming is happening and we're almost certainly the cause.

So the question for me becomes:  how big a deal is it, for both people and our environment?

According to the climate scientists, we've been warming for 100 years now, and nobody seemed to notice.

I know there are worries that there will be a 'climate tipping point' -- that warming will shut down the gulf stream or make the Greenland Ice Sheet fall into the ocean all at once or ocean chemistry changes will make all that methane down there suddenly bubble up to the surface. I'd be very interested in evidence that any of those things have ever happened in the past (because on a geological time scale the Earth's climate has varied a LOT).

And I'm certain warming will be bad for some species-- maybe polar bears will go extinct. Then again, a warmer environment will be good for some species, and I recently read an interesting article about new species arising to fill empty ecological niches much more quickly than biologists expected (I dont' remember the details, but they were seeing new species arise over a period of decades instead of centuries or millenia). I think we all (biologists included) have a bias towards species that already exist, and have trouble having faith in Nature's ability to adapt.

So given that the world was a MUCH warmer place back when the dinosaurs were roaming around, and given that most people most places in the world didn't even notice an almost 1° C rise in temperature over the last century, I just don't think it will be a global catastrophe.

Which is a good thing, because I don't think the kind of global agreement that would be required to reduce carbon emissions has any realistic chance of happening-- the incentives for a country or region to cheat (and burn lots of cheap fossil fuels) are just too great.

You can remove the addr.dat file and run with the -noirc and -nodnsseed options to experiment right now.

I fixed the bootstrap-from-hard-coded seed node code a couple of months ago, so use a recent version of bitcoin to see it working properly.

No.
See: https://en.bitcoin.it/wiki/Script
Opcodes 1-75 push data onto the stack.

It is high on my list because I think most miners (and pools) would be happy to include many more free transactions than the current rules allow, and if there is another price spike or somebody rich decides it would be fun to make the block chain a couple of gigabytes bigger it is much easier to react if the fees are not hard-coded.

The rough plan is:

 + Give miners more "knobs" to set fee policy-- let them specify (via command-line switch and maybe bitcoind RPC command) how much (if any) space to set aside in blocks for free transactions, how much to charge per-kilobyte and/or per-ECDSA-signature-validation, and what the priority/size/number-of-signatures thresholds are for considering a transaction for inclusion in the free space.

 + As Meni says, teach clients to look at the recent blockchain history and, for a given transaction, estimate how much of a fee will be required to get it into a block reasonably quickly. Maybe a "createtransaction" RPC call that locks coins for a certain amount of time and returns the how-long-to-confirm estimate along with "commit/aborttransaction" calls....

 + Figure out a reasonable UI for fees. Maybe:  calculate the probability sending the transaction with 0 fee will get into the next, oh, 3 blocks, and if it is greater than, oh, 90% then just send it without a fee.  Otherwise, let the user decide between paying a fee that will get it included (with 90% probability) in the next 3 blocks or letting them know how long it might take if they pay no fee.

Lots of details to be worked out...

The setup.exe is a "NSIS installer" -- I think this will work (but I haven't tried it):