Satoshi didn't premine a darn thing.  He had way too much class for that.

That said, he did sic something like sixty computers on mining for the first two years of Bitcoin's life, starting when there were only about fifty people who had ever heard of his cryptocurrency protocol, only about thirty became miners in the first year, and most of them (remember, everyone is CPU mining at this point) were only using single computer.  

So, yah, he's got a lot of coin. About a million by my estimate, making him the first Bitcoin Billionaire as of a few weeks ago when we poked our noses over a thousand bucks a coin.  A bit less than a billionaire now that we're under the thousand again, but let's face it; he's filthy rich if he ever wants to start using his Bitcoin.

Blockchain explorers matter.

I mean yes, the blockchain is the same, and equally secure, whether anyone serves it on the web or not.  The software works whether anyone explains how or not.  The logo doesn't contribute anything to the ideas or the protocol or the security.  Bugs can get fixed even if the dev team never responds via email to a single  complaint. 

But the existence of a web-based blockchain explorer, like a good website and a good logo and good support and a responsive dev team, helps to inspire confidence.  I'd consider it to be important enough that the code to do it should be part of the "standard" sources package for an altcoin, and having a blockchain explorer on the web would ideally be one of the things you do starting on day one when you launch an altcoin.

The world will not know who Satoshi is until his will is read.  I expect he will leave his bitcoins to someone.

I agree.  That is NOT a good future for Bitcoin, and Bitcoin as an investment is far less stable than Bitcoin as a currency.

With an investment that is widely held but traded in small volume, a single trade involving a significant amount can make the market swing wildly.  If most coin is in the market most of the time, the same single trade has little effect on the market. 

Also, I consider it more important to undercut competitors for money movement than it is to charge according to the blockspace occupied - so I'd be all for making fees proportional to the amount transferred rather than proportional to the space occupied.  The miners might still prioritize tx by fee per kilobyte, but IMO that ought to mean that transactions in larger amounts naturally have priority to go through faster. 

Heh.  I know that; what the law actually forbids is them picking a date and trading old dollars for new ones at some fixed rate.  IE, that thing where a hundred units of the "old" dollar are worth one of the "new" dollars.  But really, all that forbids is using the same name for the new note.  If you don't use the same name, then the new 'Franklin' note is just a synonym for a hundred-dollar bill.

If you're talking about American Dollars, they have actually got a law that says they will never devalue their currency. 

Not that that'll really stop 'em.  All it means is that they need a *NEW* unit of currency (maybe they'll call it the 'Franklin') that trades at  one Franklin per 100 Dollars.

Nah, if you have a chain that's dedicated to a single channel then transactions in that chain only get checked by half as many people.  Besides, it's better for people transacting within a single channel to "load balance" by picking the blockchain in their channel that has the smallest number of tx in the memory pool.

And transactions that are served by one of the two-channel blockchains never need to be in blockchain zero; that's just for tx that span 3 channels or more.  Which, in practice, is almost none of 'em.

Edit: you seem to be talking about a different approach: a "tree" of subchannels, each node of the tree having its own blockchain.  I considered that, but in that scheme it's really hard for two people (or more) who want to make a transaction to find a blockchain that they have in common where the transaction can be made.  You have to have both of them going up the tree to the lowest tree node that they have in common, which would concentrate fully a quarter of the traffic on the root blockchain, split another quarter between its two subchains, split an eighth of the traffic between their four second-level subnchains, etc.  That won't scale past about four times what Bitcoin can handle now, because the root blockchain of the tree scheme would become a bottleneck.

Well, you could assign channels to geographic regions or industries, but each blockchain is shared by 2 channels.  So if a client in europe (channel 3 let's say) wants to transmit money to a client in America (channel 2) they'd need to use blockchain 2.3, which is distributed on both continents.  For example with 6 channels you might have:

channel 1 blockchains: 1.2 ,1.3, 1.4, 1.5, 1.6  (asia)
channel 2 blockchains: 1.2, 2.3, 2.4, 2.5, 2.6  (north america)
channel 3 blockchains: 1.3, 2.3, 3.4, 3.5, 3.6  (europe)
channel 4 blockchains: 1.4, 2.4, 3.4, 4.5, 4.6  (south america)
channel 5 blockchains: 1.5, 2.5, 3.5, 4.5, 5.6  (africa)
channel 6 blockchains: 1.6, 2.6, 3.6, 4.6, 5.6  (australia)

and all channels share blockchain zero.

(which is a total of 15 blockchains, not 36)

But no blockchain would be restricted to just one continent, because every channel has one blockchain (besides zero) in common with every other channel.  The idea is that because most transactions involve just two people, you will very rarely need a blockchain that spans more than two channels.  blockchain zero is reserved for transactions involving more than two people.

Still, your idea is valid; someone in channel 3 could give you a bitcoin.europe.Gux8854.... payment link to click on. But there's no way to enforce such a breakdown; the guy with the channel 3 address might live in Australia.

There's a simple protocol for destroying 1.5 million coins; simply transfer them to a provably unspendable address via pay-to-script hash, then reveal the script that always evaluates to false and let everyone see that the hash matches.  No client modification was necessary.  In fact I wondered *why* you had done a client modification to address this, because you can't prove that makes it unspendable; you can only prove you'd need to have most folks (and miners) using a different client in order to spend it.

At that point, even if the 1.5 million still show in the blockchain, no client no matter how old will honor an attempt to spend it.

But at this point, with everyone running the modified client, you can't do that without causing a fork.  

How about FOUR THOUSAND (or even FORTY THOUSAND) transactions per second?

This is so cool!  I had come up with a scalability solution of my own earlier this week, and this one MULTIPLIES by it!  

A fundamental change in protocol design has been exactly what Bitcoin needs to continue to be viable as it grows.  This will do it.  Actually either of these will do it.  But combining them is AWESOME!

By combining these two ideas we could get THOUSANDS of transactions per second.  

My scalability solution was to split wallets into multiple "channels" and have one blockchain for each pair of channels.  So when you get to the point where 6 channels (15 blockchains) is having trouble coping with transaction volume, you can shift to 7 channels (21 blockchains).  Every client would be listening on one channel (5 blockchains before the additional channel is added; 6 blockchains afterward), and each channel would contain a total of 1/6 (or 1/7) the total tx volume.  By the time you get up to 20 channels (190 blockchains) you could handle a thousand tx per second even with Bitcoin's current speed.

You'd need one additional blockchain (probably with an extremely low volume of transactions) which would be in all  channels, to handle the rare tx that involves wallets in *more* than 2 different channels (all of them much more complicated than the standard pay-to-script-hash). So each single-channel client would actually be listening to 6 (or 7, or 20) blockchains - but the last one nearly negligible in bandwidth and volume.  

These blockchains would back each other up; every time a new block appears in any blockchain it would list the hashes of the most recent block so far found in all other blockchains.  The mining awards would simply be split between blockchains.  Thus all blockchains would be "merge mined" together.

One downside is that any particular transaction would only be checked by the clients on two channels rather than by all clients.   IE, all users would be relying on tx checked by 1/3 (or 2/7, or 1/10) of total users, so it's no longer a completely trustless model; you'd be trusting a few thousand other users not to collude to deceive you, rather than trusting that ALL of them would not collude to deceive you.

Upsides:

It would be easier to "throttle" bandwidth without refusing altogether to participate, simply by limiting the number of blockchains in which you advertise full node (or "download this blockchain from me") service.  Bandwidth costs could even be made much less onerous than that; see the second point below.

It would be easier to run a fully participating node for one channel.  It would use only 1/6 or 1/7 the total bandwidth and tx checking CPU load, and only 1/6 or 1/7 (or far less; see the next point) the storage, of Bitcoin's single blockchain architecture, spread across all blockchains in your channel).  

There is a huge privacy and bandwidth enhancement:  The length of a particular blockchain could be limited. You could at any time transfer all of a blockchain's UTXO to a different blockchain (and everybody could check that you did it correctly), shut down the now-empty blockchain, and start a new one to replace it.  Effectively this would amount to a very aggressive "pruning" strategy for releasing transaction history -- which would also be a huge contribution to financial privacy and a huge savings in bandwidth and storage.  At any given time, the blockchains in use might average only a week or so old.  Only one blockchain, probably the "all-channels chain" which would have a very light transaction history anyway, would need to stretch all the way back to the Genesis Block.  Of course this wouldn't help against an opponent who keeps copies of all historical blockchains, but it would preclude downloading all transactions in history from any full node, once the blockchain those tx were on has been pruned.

Any particular user who wants to would have the choice to support the protocol more fully by subscribing to multiple (or all) channels if they have enough bandwidth and storage to do so.

Now, what's awesome about this is that these two enhancements multiply by each other. If we can get *EACH BLOCKCHAIN* up to 200 tx per second, then multiplying the number of blockchains as outlined above would be many times as effective.  

With 7 channels, or 21(22) blockchains, we'd be up to over 4000 tx/second, rather than the 150 or so I had been envisioning. With 20 channels (190 blockchains) you could be approaching 40,000 tx/second rather than the 1400 or so I had been envisioning.  

Is it possible using pay-to-script-hash, to come up with an appropriate script for mutually conditional transactions?

What I mean is, you have the following scenario: 

Alice and Bob want to make transaction A, but if and only if Carol and Dave make transaction B.
Carol and Dave want to make transaction B, but if and only if Alice and Bob make transaction A.

All four parties want both transactions to go through, or neither.  But none of them wants to structure it as a single four-way transaction, because Alice and Bob are not allowed to know before both tx are broadcast which txouts Carol and Dave are about to use, and vice versa. 

Nobody cares, though, if the other pair do instead a similar transaction (same amount transferred) involving *different* txouts. As long as it isn't exactly transaction A or transaction B, they don't want their own transaction to go through.

They can cooperate to the extent of giving each other identifying information for their transactions; they can give each other partial hashes of their tx (ie, their hash matches their tx if you zero the part of their script that contains your hash) before broadcasting the tx.

I'd start with a "bump" to reward the early birds for the first couple of years, then taper off similar to how most coins do, and finally settle into a steady state of mild inflation. 

With apologies to those who can't see the graphs of equations in their heads, I think the mining reward per block in any given year would be something like ...

50 - (50 x ( Y³/(50 + Y³))) + (3 x 1.03^Y)

where Y is the year from the start of the coin.  This amount would be paid to miners about once every fifteen minutes, making about 96 rewards per day.

Fifty minus the first complicated term is the "Bump" that plays essentially the same role as starting at 50 and halving it every two years (it goes close to zero after about 26 years) and thrice one point oh three to the Y power is the long term inflation rate.

The minimum payment would be about twenty-three years out, I think, with something like four coins per block. After that the reward would grow at an annual rate of about three percent and the money supply  would show a rate of inflation slowly approaching three percent.

Block times - that's hard to say.  If it scales to millions of tx per second then it probably doesn't use anything like the same structure as Bitcoin's block chains, so it's hard to say what the question would mean exactly.  But as I said, the above for an approximate mining reward per fifteen minutes.  It might wind up split among thousands of miners who each contributed in some way to the construction and checking of the "block".

I think I'd try for very quick (10 seconds or so) initial confirmation of small transactions at least (albeit with some *very* small possibility, less than one time in a hundred thousand, of being wrong) because that's consistent with getting something from a vending machine.  Larger transactions represent longer-term decisions, so insta-confirm is possibly not as important there.  For absolute commitment type confirmations on the level of the way ten blocks means "confirmed" in Bitcoin, an hour or so would be acceptable.

#1)  It must scale to millions of tx per second. This is the single most important criterion.

#2) It must keep the costs of transferring vending-machine sized amounts down to less than Sales Tax/VAT/Card Processing fees/Bank "coin handling fees"/ whatever the alternatives are charging.

#3) It must keep the costs of transferring remittances and purchase-sized amounts down to less than the cost of sending it via Western Union/Bank Transfer/Travelers Cheques/Card Processing Fees/Exchange Rates/ whatever the alternatives are charging.

#4) It must keep the costs of transferring large sums or stock purchase prices down to less than the costs of brokerage fees.

#5) It must NOT limit mining to people who buy special equipment or use acres of computer resources.  Mining should be limited to nodes with always-on Internet connections, but should not have many other limitations. Ideally, most nodes ought to be able to mine, with similar opportunities for everything from a Raspberry Pi to a top-of-the-line supercomputer. 

#6) The amount of stuff you have to download or keep to verify a transaction should not normally exceed 4 MebiBytes.  The amount of stuff you have to download or keep in order to run a full node and mine should not normally exceed 4 GibiBytes.

#7) It must be possible to download this stuff more-or-less at full speed, rather than one block at a time in a rigid sequence.

#8) Running a full node and mining should not require more bandwidth than half of what most connections provide.

#9) The protocol must support complicated transactions, conditional transactions, "Colored coins", and Contracts.

Maintains its value over time compared to what?  Something that can always buy the same number of pairs of Alpaca Socks?  Something that can always buy the same number of Houses?  Something that can always buy the same number of pounds of rice? 

No.

All of these coins fluctuate.  So does the price of everything else, including gold and Swiss francs.  There is no such thing as absolutely staying the same value. 

It is still a problem however. 

Chinese Banks, and indeed all other Chinese Financial-sector businesses, are banned from buying, selling, or providing services for Bitcoin.  That means that if a Chinese merchant accepts them he cannot bank them with the rest of his earnings, nor easily exchange them at some exchange or financial service for Yuan that he can bank.  Being Chinese will mean that he cannot easily establish a financial-services account in some other country, and if he did, getting the money back into China would feed a lot of rent-takers compared to his usual business of taking Yuan.  He'd be left with less money than if he'd sold something for Yuan in the first place.

In order for accepting Bitcoin to be viable for a Chinese merchant, there must be someone accepting Bitcoin for the things (mostly wholesale fresh inventory) that the business needs to continue.  At least enough such other merchants that he can spend nearly as much Bitcoin as he takes in.  Or someone, not a financial service, who wants to buy his Bitcoin for Yuan. 

Obviously he can keep his profits in Bitcoin, but retail margins are razor-thin -- he *HAS TO* spend 95% of the money he takes in to make a 5% profit on his merchandise.

Keeping banks out of the game made it much more difficult for Chinese non-banks to deal with Bitcoin.

Heh.  No, not "legal tender" -- no government backing means no law saying that it's a legal form of payment for all debts.

What the guy would say if he were being correct was "We can and will accept bitcoin as payment for goods."

You must remember that someone can pretend to be as many different people as he wants to. 

It's called a Sybil attack.  It's the most effective way to subvert decentralized or peer2peer networks. 

When someone wants to know what's going on in the Bitcoin network, they start up bots from a thousand different IP addresses at once, pretending to be a thousand different people, and listen to all the messages comparing the times at which different nodes get the messages, so they can detect what IP address transactions originate from. 

When someone wants to get more coins than one "user" is entitled to, they'll start up a thousand bots and pretend to be a thousand people... 

I don't think that's technically possible unless some central power retains a "master key" that can arbitrarily modify the blockchain.  And if some central power does, it's very hard to trust that they won't abuse it. No such key exists for Bitcoin, so unless you change the protocol to use the NIST curves or something, where a backdoor already exists, nobody can do that. And if you proposed such a change, you'd make most owners of Bitcoin really angry.

Further, opinions vary on what constitutes "abuse."  You can't really have someone enforcing US law on the blockchain when the coins are circulating worldwide. 

There is a problem here.  Nobody can "adjust" the value of anything you have.  I mean, how do you feel about owning a house if its market value is going up and down in a real estate bubble?  So, if two people believe that a certain number of coins is worth a certain other thing, they don't have to pay attention to anyone trying to "adjust" the value of a coin.  The one owns the house and decides how much it is worth; the other owns the coins and decides how much they are worth.  

If the servers and exchanges attempt to "adjust" the price against some currency or some commodity, you immediately get Gresham's Law, where whichever one is valued more by people than the official exchange rate allows for, goes wherever it can get an unadjusted price.  

He can get bitcoins out, but he has to do it just a few at a time.

Send ten coins into a mixer, let them get mixed up with a hundred other coins, get ten coins out....  Wait a while for the mixer to give away all of your ten coins to some other reprobates, send them another ten.....  

Or he could gamble in small quantities on SatoshiDice;  He'd be swapping the stolen bitcoins for other bitcoins whenever he won, and getting rid of them to other people whenever he lost.  By the time he cycles all the money through SatoshiDice a few times it gets pretty untraceable, and SatoshiDice gets maybe 8% of it.  

But this only works for getting a few coins at a time laundered, so it could take a long time.