I get asked to help with these fairly often.

Hard drives have blocks.  Files are chains of these blocks.  Directories are special files containing a list of file names and addresses for that file's chain.  When you format your drive, all of the blocks are marked free, but not typically changed.*

As you use the newly formatted drive, blocks get overwritten.  When you realize that you had a wallet on there and try to undelete it, the utility searches all of the blocks looking for directories, and then it scans the directory looking for a file named wallet.dat.

What you actually get is the current contents of the blocks that formerly had your wallet.  You should not hold your breath, because the odds aren't good, unless you realize your mistake very early and don't use the drive at all.  You can improve your chances slightly by shutting down the computer immediately (flip the switch), and then using a different computer to attempt the recovery.

If the undelete tool doesn't find a wallet.dat, the directory has been overwritten.  The blocks for the file may not have.  Pywallet can search the drive, block by block, looking for keys.

In an extreme case, if the wallet was not encrypted, you can walk the candidate file byte by byte, treating each overlapping region as if it were a private key to be checked.  This takes forever even for moderately sized files, and you can just plain forget about doing it on a whole drive.  Also, it never works.

*  This is extremely simplified.

Step 1.  Post this in the appropriate forum.
Step 2.  Listen to the answers you get there.
Step 3.  Bounty goes to the address in my signature.

If you think that is bad, you obviously haven't seen campbx yet.  Gox just blew past $350 while campbx still hasn't crossed $300 yet, and is mostly hovering at $290.

Which is really odd, because campbx is so easy for US users to get funds in to and out of.

This is really cool.  I've been watching it run on a couple of computers here.

I'm getting consistent results here, showing that the selfish mining strategy is a really good way to lose 20-30% of your mining revenue.  I'll note that this is roughly what I was expecting.  In every other context, the whole world considers it obvious that getting your blocks out as fast as possible is a good thing.  Still, science is the art of not fooling yourself, and getting the result you expect is not the same as showing that a model has skill.

As fun as this is, it needs to be much faster to be really useful.  We need hundreds or thousands of runs, covering hundreds or thousands of blocks.  We also need to verify that model parameters are realistic, and that the simulation isn't adding or causing un-real effects.  We should also invite the authors to verify that the attack behavior is implemented correctly.*

* To the limited extent possible.

You answer your own question.  Either his wallets were not encrypted, not encrypted well, or he was convinced to cough up the key.

The payment protocol message doesn't automatically map into a transaction.

Your node could collect several payment requests and bundle them into a single paymany transaction.  This may not be included in the first iteration, but can be added later if desired.  The point is that the payment requests are informational messages, not control messages.

This is true.  Under orders from the secret committee that runs the foundation, I added a secret file to the bitcoin source master repository.  Don't bother looking for it on your copy of the source , it is hidden secret file.  This file allows the cabal to push updates to all nodes, changing the block validation rules.  The end result is that the central bank foundation can print unlimited bitcoins.

(Note:  I'm mocking the idiot here.  Not only is this not true, it couldn't possibly become true, no matter how many sock puppet accounts Atlas creates to spread these lies.)

Agreed.  The image that comes to mind is the guy selling his method for beating the stock market.  If it worked, he wouldn't need to sell it.

I'm calling for (and have pledged a bounty for) a network simulator with latency.

I don't believe for a minute that this is economically efficient based on the output of an iterated finite state machine.  Gamma is not a property of the network, it emerges unpredictably during each race from the chaos of the network.

Well done, you got me.  Work can be wasted if done at the wrong end of the chain.  If you read on to the end though, I clarify that expression.


What may have tripped me up was the way they describe gamma on the various pages.  When I was reading the paper, I was struggling to find a unifying theme for all of the ways they use gamma.  It seems to be a choice on one page, and then an expression of the natural race between competing blocks on the next.

In regards to latency, you seem to be missing a very important aspect of reality on the bitcoin network.  If you are sitting on a block, waiting for the rest of the network to find one so that you can publish yours, the signal that you need to act is also the signal that you have already lost.  Don't feel bad, this entire paper was written because of the same misunderstanding.  You can not win races by waiting for the rest of the network to pass you.


I agree with you so much that I traveled back in time to do it.  What is fully deterministic in their model is everything else.  When a new block is found, gamma of the network switches to it, while 1-gamma switches to the attack block.  This is not reality.



"every other node" was hyperbole, but not far off from what it would really take.  If the bitcoin network was laid out like an efficient mesh on a flat sheet, you wouldn't need many sensors.  But the bitcoin network is tangled up like a wad of Christmas lights.


When you run to the press, you tell the world that you are no longer interested in civil peer review.  

Damn.  The cage already got you.  Society and ignorance have conditioned you to oppose being forced to act in your own best interest*.  Woe is you who are unwilling to trade your cage for freedom**.



Seriously though, how many millions more have to die to this nonsense before the useful idiots*** pushing these schemes understand that they always end up on the dying side, and never on the ruling side?

*  As decided by your enlightened masters.

**  As defined by your enlightened masters.

***  Sadly, a term of art.  This is the soviet term for westerners that spread their poison for them.  The idiots in question are far from useful.

Please do run your simulations.  When you do, make sure that you faithfully simulate a network with latency.  The word latency exists in their paper exactly one time, as a casual aside in the solution section, which should immediately set alarm bells ringing in all of our heads.  In addition, they seem to suffer from the strange notion that work in bitcoin can be wasted.  Despite the fancy pedigree of the email address in the page footer, I suspect that their paper has more to do with hubris, ignorance of physics and a serious lack of understanding of how bitcoin really works.

Let me start with latency.  As far as I can tell from the paper, their "simulation" (and here you should imagine me doing very sarcastic air quotes) involves a network where the evil miners have magically found a way to detect the competing block in the honest miner's memory, before it has begins to spread on the network.  Gamma seems to play some sort of role here, but the meaning of it seems to change from page to page.  Or at the very least between pages 8 and 11.  Can anyone give me a good justification for abusing this poor variable in this way?

The charts are very illuminating.  In figure 2, each of the simulation points is exactly on the calculated line.  This is a dead giveaway.  The only way that can happen is if their model is fully deterministic except for mining function.  Amusingly, in a universe without latency in any form, which is the only universe where this model is meaningful, their solution is unnecessary, and actually counterproductive (since it causes the problem they aim to solve).

The real gold of this paper comes on page 13.  On page 13 they handwave over the latency issue by pointing out that an attacker could insert itself between every other node on the network.  Let me just sum up a few years of discussion on this topic:  We Know.  If an attacker is able to isolate a single node, they can fuck with that node.  If an attacker is able to isolate every node (lol), they can fuck with every node.  Note to researchers:  If anyone can control the spread of information across the entire network, they don't need whatever crazy scheme you've cooked up; they can already do much worse things.  In particular, if an attacker is capable of creating the conditions necessary for this garbage to work, they can just not forward any blocks but their own, and they multiply whatever skimpy hashing power they have by infinity and they gain total control over all mining.

Of course, everyone instantly sees how silly that is, so they had to dress it up in pseudo-scientific gibberish so that people would click on their crappy website and check out the douchebag's glamour shot.

Sigh.  Is there even any point in addressing point two now?  Work is not cumulative.  Publishing a block does not make the rest of the network "start over".

It is like that scene in the Matrix.  Just set your terminal to green and let it scroll by for a while.  After a while you'll be able to just "see" things.

Wait...  Are you typing addresses by hand?

Each node validates network messages.  If some nodes think that a block or transaction is valid, while other nodes think it is invalid, you can have a fork.  This is what happened when the BDB bug hit a while back.

In the case of the BDB bug, the people running the network (aka, "us") decided that we'd invalidate one fork to re-merge the network.  This option is not likely to be possible or practical for all such forks in the future.  In particular, as more implementations start up, the fraction of the network hurt by any given fork will grow smaller and smaller and at some point the majority will refuse to insert bug compatibility.

In practice, this will cause accidental or intentional forks at small numbers of nodes.  As in, someone may be able to carefully craft a transaction or block that will knock one node out of sync, with the intention of doing mischief to that node.  Equally possible will be that such things will just happen by chance, and some times they will go unexploited, but other times people will lose money because of it.

The only real safety is to be running the exact same software as the majority, and in the exact same environment.  Note that the BDB thing didn't hit all nodes that it potentially could have hit, because it depended partially on the environment.*

The monoculture carries different risks, but it is largely resistant to these sorts of problems.

Are you familiar with the Brown M&Ms thing from rock history?  It was parodied in Wayne's World II.  But it was there for a reason.  Van Halen put on a huge show, and to do it safely, they had a list of detailed technical requirements they presented to the local promoter.  The brown M&Ms were a canary.  If the promoter forgot that step, it was assumed that the other things in the contract had also been neglected, so they had to check everything personally.  If the promoter presented the M&Ms correctly, it was likely that they were careful with everything else too.

In a similar way, the people that are most familiar with the software have a sort of list of likely forks points in the code, where if someone gets it wrong, their node will (or at least can) eventually fork from the rest of the network.  When someone posts a new implementation, they can check a few of those, and if they aren't done right, the devs are pretty safe saying "Your code has big obvious flaws.  It probably has other more subtle flaws too.  Please do not let anyone use this code until you can show that you really understand the reference software."

*  I run one ancient node for amusement.  By some quirk of fate, it was not hit by the BDB thing, even though it really should have.  I think that all of my nodes that are merely old did get hit by it.

Scarce doesn't mean rare, it means "not of infinite supply".

Any finite supply, no matter how massive, needs to be allocated.

There are really only two ways to allocate, by price on markets, or by force.

One of those ways always works, every single time it is tried.  The other, never works, no matter how often it is tried.

The failure of allocation-by-force, in all of the various names and guises it has gone under over the centuries, is never understood as a failure of the idea itself by those who mistakenly believe that they would be part of the ruling class.  They always believe that it would have worked, if not for some boogeyman thwarting the plan.

Also, it takes a really fucked up person to fail to see the hundreds of millions killed by socialism/communism in the last century as an essential part of the system.  If Stalin had been a frightening aberration, you could be excused, but every time this shit comes up, in every country, in every culture, people die by the truckload.  Slaughter is an essential part of allocation-by-force, no matter what name it is operating under, no matter who is doing it, and no matter how enlightened they pretend to be.

The world already has a resource based economy.  It is called free market capitalism*, and it works.  If you want to make it better and more efficient, lobby your government to stop fucking with it.

*  It is very popular these days to use force (aka Government) to meddle in some market, then pretend that the failures of the meddling are failures of capitalism.  If anyone is getting ready to do so, let me just say in advance, "Fuck you".

The gist is incredibly useful.  Be sure to copy out the commands and reformat them so you can see what's really going on.  The long lines can be hard to follow.  If you unpack the commands in the gist, you can see that the redemption info is needed both to create and to sign.

The transaction goes through several stages when redeeming multisig.

First, a partial transaction is created that specifies which transaction is to be redeemed, and lists the outputs.

Second, the information needed to actually redeem the P2SH input are added to the transaction.  You can see this as an explicit step if you call signrawtransaction with the redemption info, but without any private keys.

Next, one or more signatures are added.  This can be one step, or many.

Here is example PHP code.  This is not a utility suitable for production usage, it is just a demonstration of how things work, but you can use it for one-off redemption, or modify it to accept the payment info.

Should be an interesting thing to watch.  Normally, cash would be held as evidence until after the trial.  In bitcoin, the evidence is totally public, so there is no need to hold the coins themselves.

If the government dumps the coins before the conviction, it will send a very strong signal that the federal government "gets" bitcoin and has a huge amount of faith in the mechanics of the system.

If the government does not dump them, well it just means they are the dinosaurs everyone was expecting anyway.

Winning at trading isn't so much about having a good strategy, it is about figuring out when to stop using one strategy and then picking the next one wisely.

Every strategy has pitfalls.  If one didn't, we'd all be using that one.  Balancing has a place, as does momentum trading, which is very nearly the exact opposite.  I don't think I'd be comfortable recommending either of those as "the strategy" for the public at large to be using, but for some specific people with specific needs, one or the other might be perfectly correct for them.

Ally or not, I told you exactly what you need to do.

This change has some risk associated with it.  Not doing the change also has a risk associated with it.  Everyone judges these risks on their own.  If you want to change minds, you'll need to use a combination of reducing the perception of risk on one side and increasing the perception of risk on the other.

The view of cryptography that I've outlined is, more or less, the view held by most people that actually work on and with cryptography.  You are unlikely to increase the perception of risk by repeating the well known statement that a sudden break is technically possible.

Your best bet is to develop a working implementation of the change, test the hell out of it, and convince people that the risk of accepting the change is very low.  These are things that you can do yourself, hire out, or attempt to crowdsource along with others that share your view.


Any G is as good as any other.  Outside of curiosity and historic interest, no one cares much why we use the G we use.  If you are looking for a project to hone your c++ and/or bitcoin skills in preparation for the other patch, changing to a different G is relatively easy.  I think you only need to add a new address type, a new flag for WIF, and a new SIGHASH flag value.