Apologies for bombing into this thread, but I'm taking the opportunity to address a specific person who I absolutely know will be reading it, simply due to its subject line.

1.  I AM NOT SATOSHI.

2.  I get annoyed when I am stalked.  I get FURIOUS when my friends are stalked.  "You wouldn't like me when I'm angry."

3.  That cell phone had absolutely nothing interesting on it.  I may not have Satoshi's level of OpSec, but I don't put anything interesting on cell phones.  Ever.

4.  There is nothing involving me or anyone close to me that you can do to get Satoshi's keys.  Leave them alone.

5.  There's a God Damned Pandemic on and you should have feckin' stayed home.  Leave before they shut down air travel, or you'll be stranded here.

We don't know.  We don't need to.

I have a business card which I like to think might be Satoshi's.  It reads, "This card intentionally left blank."  I could upload a picture of it if you're interested.

FWIW, speaking as someone whose name is on your list of candidates, I regard this fixation on Satoshi's identity as being a little dangerous.  There are people who might do awful things to other people if they think that by doing so they might get their hands on Satoshi's coins.  Many of them read this forum.

What Buffet, Roubini, and all these guys are looking at, is centralized payment and money transfer services that work, securely, immediately, for thousands of times as many transactions, for drastically smaller expense than the cost of PoW.

"decentralization" and "peer to peer" are not things that add value from their perspective.  They see Bitcoin as an inefficient slow service that does what other services can do, in a way that's drastically more expensive and doesn't work as well.

Of course a share value can fall.  But it can't really fall while the company is still okay.  It represents ownership.

A coin on the other hand?  A coin can go to zero while the company is fine.  Why should the company care? 

The problem with a coin is that there's nothing to prevent the company from just plain walking away.  It got the ICO investors' money, it owes them nothing, so...  done deal, right?  It's over.  The company gets nothing for whatever resources it devotes to the ICO coin after that point, so sooner or later it's just going to cut expenses and drop it.

You're not going to get real investors investing in something that creates no obligation and confers no ownership.

The problem with this line of thinking is that the coin does not represent a promise of any kind on the part of the company that issued it.

Investors want to invest in things that will either cause the company to give them royalties or payments or a share of their future growth.  That's what stocks and bonds are.

A coin - which can go to zero while the company is still okay - does not represent any obligation by anybody to the investor.  It's essentially just a receipt for a donation.  And not even usually a tax deductible donation.

I've been looking at it again recently because I'm thinking of undertaking a new block chain project of my own. I may even update it to the current bitcoin sources.

But what I have in mind goes in a sharply different direction from Bitcoin, so simpler (earlier) versions could be a better starting point too.  Still deciding what to base it on.

I didn't give away the last bit of how to get the premine done.  I gave the information to get about 90% of the way there.  I told you how to figure out what the key you needed to import that transaction would be.  But I guess what the hell.  We'll go to 99%.  

There's a database of uncommitted transactions.  Processing a block, the software takes transactions from this database to add txOuts to your wallet - whenever it finds one of the uncommitted transactions in the block.  

Normally this is fine. When it's forming a block itself, it adds the coinbase tx to the database before it processes the block.  When it's checking existing blocks, it adds the transactions it sees in the block to the database when it receives the block.

Your problem is that the genesis block is causa sui. The software isn't forming the genesis block itself, and it didn't receive it.  So the initial coinbase transaction doesn't get into the database of pending transactions in either of the two "usual" ways.

Your software sees a valid block, where every transaction checks as a valid transaction, etc.  It decides to accept the block. So when it accepts the block as part of the block chain, it takes everything in its database that matches any of those transactions (ie, nothing in the case of the Genesis block) and checks all of that stuff to see if there's a txOut in it that can be added to your wallet.  If it finds the txOut, it adds it to your wallet.  It didn't add the genesis coinbase.  No problem, I told you how to import it yourself after the fact.

So you imported the key, and it imports just fine, because it looks back through the blocks, and sure enough, there exists such a coinbase transaction.  But then you try to actually spend it, and when it's checking the transaction it repeats the whole "did this txOut successfully get imported from the database?" check, and observes that no, that's an empty damn database when the genesis block is processed and no such amount exists.

This was supposed to be sort of an "exam question" - somebody who is capable of making and maintaining an altcoin is expected to be able to figure it out.

That would involve going to see where txOuts get added to the wallet, tracing back to see why the genesis coinbase wasn't making it, figuring out that the txOuts get added to the wallet when they are looked up in the database, discovering that the coinbase txOut isn't in the database when the block gets processed,  looking to see when and how transactions get into the database, realizing that neither of those things were happening in the case of your genesis block, and then correcting the problem.  A moderately involved case of debugging a code problem.

It sounds like everybody is going to be waiting for the instant when the amount they personally can spend puts the transaction fee total over the top, and then releasing blocks all at once.  Sorting it out ought to be fun.

EDIT: I'm shutting this topic down.  I gave up on keeping track of this ages ago, because it just got too depressing for me and besides I couldn't keep up.   

People keep sending me messages asking me to take things off the list insisting that so-and-so isn't dead.  If you have successfully revived something, congratulations.  But this list is now a historical artifact and I'm not keeping it up to date. Nor am I interested in debating what "dead" means in terms of a block chain coin.

Usually it turns out that they are just reusing the name of so-and-so, which is, yes, still dead.  Alternatively, they may have a live block chain of so-and-so which still does not appear on the significant exchanges, or which has still such an insignificant market value, that it is, yes, still dead.  And these points are just too tedious to debate and I don't even have time to research them all.

There are also messages I find particularly depressing, or which make me angry, and those are from people who are digging zombie so-and-so up for one more lurch around the gravestone, in a necromantic version of a pump and dump scam, using the fact that "so-and-so has been around a long time" to reassure their prospective bagholders.

Anyway:  To everybody reading this list:  These coins were what I considered dead, at the time I was maintaining the list.  Some of them may not have stayed dead, and that's okay.  Some of them may be in the hands of people now pretending they aren't dead, as part of a scam, and that's not okay.  I'm not going to help you decide which.

To everybody who has something that appears on this list and believes it isn't dead:  That's fine.  Maybe it isn't.  I am not updating the list, so consider this as information about its history, rather than information about its present.

Whoever, or wherever, Satoshi is:

I hope he's doing okay.

That would be an awesome thing to do.  Surely somebody has that wallet.

See, that's the thing.  If I could help them, I'd certainly have got in touch with them directly.  The only person who can help them is someone who knows how they can get their hands on that key.

I'm not on here much any more, but I went to make a donation to the ALS foundation in memory of Hal the other day and noted that the donation address that got set up back in 2014 has 14 BTC in it which nobody ever spent, and the wallet hasn't been touched in years.

https://blockchain.info/address/1JsnZLEGgLJY7rbDdaKTzC2JyvfaKUpF5p

Granted, that was supposed to run until a closing date, and those donations came in after that date, but the wallet that could spend them wouldn't have dropped the key.  Or at least it shouldn't have.

I'm hoping someone at the ALS foundation still has the key?  Or someone who managed the whole thing for them still does?  It would be a real shame, IMO, if that much in donations just got left twisting in the wind.

To be fair: 

You shouldn't rely on the randomness of the hash if people are betting on it.  Especially not after the hashing.

If you have a miner who stands to make more on the bet than they would on the block subsidy, the economics can favor them getting a hash low enough to make a block, but then withholding it, looking for a hash low enough to make the block *AND* having a final digit that will win them the bet as well.  They risk losing the block subsidy if another miner finds a block first, but they can also instantly release the block they found the first instant they get a whiff of the other miner's block, and then they have a nearly-equal chance of getting the block subsidy anyhow.  Meanwhile, they go on looking to win the bet. 

Exactly.  And the people figuring out who got what *KNOW* that at most one of each size went to each participant.  That's why we don't do that.

Some time ago the NSA declassified a cache of documents relating to William F. Friedman.

Mr Friedman was chief cryptographer of the Signals Intelligence Service starting in the mid 1930s. He continued as chief cryptographer through the SIS's conversion into the modern NSA, and retired in the early 1960s.

The documents are about 2Gbytes, mostly PDF scans of original paper documents, that comprise his memos, notes, patent applications and patents, appointments, personnel records, meetings, correspondence, etc.

The Friedman files include a bunch of documents about the Pearl Harbor Investigations. Then as now, conspiracy theorists faced with an attack on American soil believed (and many still do) that the attack was a government inside operation perpetrated against the American People by the gummint for their own nefarious purposes, and apparently about 10 years were spent trying to confirm or deny these rumors. As chief cryptographer, Friedman was called into these investigations frequently to testify regarding what US intelligence knew or didn't know, and when they knew it. An interesting side note about this is that if not for this investigation laying bare a lot of information that would otherwise have remained classified, the world probably would never have known about what happened at Bletchley Park in England.

I'm hosting the Friedman Files as a torrent; please download and host if interested. As declassified information it is completely legal and no copyright infringement is taking place.

Here is the magnet link:

magnet:?xt=urn:btih:5de4d39cf70f65a885093980292f8036200bf951&dn=FriedmanPapers&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969&tr=udp%3a%2f%2ftracker.leechers-paradise.org%3a6969&tr=udp%3a%2f%2fexodus.desync.com%3a6969&tr=udp%3a%2f%2fopen.demonii.com%3a1337

WRONG plan! 

You want at least ten outputs of each denomination you're creating. 

The whole idea of standardizing denominations is for txOuts to be indistinguishable.  The only one of a given denomination created in a transaction is VERY distinguishable from all other outputs.

Getting different amounts of change though doesn't have to mean that one is traceable.

Picture the same set of inputs, but a set of outputs all denominated in 30BTC, 10BTC, 3BTC, 0.1BTC, O.03BTC, etc.  Up to whatever set of denominations you can make at least ten each of and down to whatever denomination people are willing to give up as a mixer fee to enhance their anonymity.

Now some participants get more of one denomination, some participants get more of a different denomination, but with ten of each denomination there will always be a way to split up whatever amounts among three participants, and there's no way for an eavesdropper or block chain snoop to know which is whose.  They can't even use the number of each denomination issued as a guide to what particular amounts were paid out. 

Bitcoin's first-cut code had several script instructions enabled, which were disabled by the time it launched.

Hal Finney was mostly responsible for that; he pointed out numerous ways in which the lack of ability to 'lock' resources before doing a transaction could result in legit-looking scripts that could later be attacked, or could result in a denial of service.  Satoshi and Hal disabled backward-branching instructions from Bitcoin's scripting language (which means it's no longer turing-complete) for security's sake.  That more-or-less forces multi-step transactions to wait several blocks between steps, during which interval people can verify that the previous step did happen and is now part of the chain, before going on.

No backward branching means that flow-of-control in a bitcoin script can jump forward over part of the script (in an 'if' branch for example) but can't jump backward to something it's done before (in a 'while' or 'until' loop, or in a recursion for example). 

ETH lifted this restriction among others.  That means contracts in ETH are more flexible and scripts can do more - but it also means they are trickier and enables people to make smart contracts that can be attacked in more unexpected ways - particularly with 'locking' of resources.  An ETH script can do many steps immediately based on balances that existed before the script ran - and then the whole sequence can be invalidated by a very shallow blockchain fork.  When more than one blockchain-recorded transaction is required to complete an interaction, this results in a relatively cheaper attack - if the two tx get into different blocks, and then one but not the other is invalidated by a fork. 

Carlton, I'm just admiring the way you resort to ad hominems when you can't refute a point.  It's a nice little acknowledgement that I said something you KNOW you'd look silly denying.