I sort of hate to contribute to such a resoundingly stupid idea, but if you want shallow water out in the middle of the ocean, there is the Minerva Reef. 

It's long been known to sailors as a place where you can drop anchor with <20 meters of anchor chain, far from any land.  In fact a few "communities" have been attempted there, including one centered around a saloon that someone built on stilts and one that actually dredged local sand together to bring a dry surface above sea level, though none have gained any sort of permanence.

As I understand it, you generate a verifiable 'trace signature' of a program run which bears a distinctive cryptographic relationship with the code itself; it can be considered to be 'signed' by the code used to create it.

But GIGO still applies.  Given the same starting point, the same code could run with different input, then you can give 'trace signatures' to two different people to verify, and have two people verify that the code ran correctly and those two people will still have different results. 

However, for some data structures, if you are given the starting point, the 'trace signature' AND the results, you can verify that the starting point was transformed into the results via the 'signed' run of the code, even if that valid run had unknown inputs.  This is possible with some structures and not others, but because of the cryptographic chain-of-evidence qualities, the Bitcoin Blockchain is one of the finest examples of a structure that it *DOES* work with.

But I think this is going rather far afield from the original intent of this thread, which was to make Bitcoin able to handle more transactions per second.

If you ever needed proof that the Discovery Channel employs no one who can do math and doesn't bother fact-checking, there it is.  This thing has been around for years and gotten no closer to construction.

That's not a building, that's a render.  The "Freedom Ship" initiative collected several USD$million and failed to build anything. Most people agree it was a scam.

Naval architects, looking at the proposed size of the darn thing, were pretty unanimous in their "Why are people giving these idiots money to build something that can't exist?"  response -- mostly because the ocean has swells miles long that greatly exceed the proposed height of the vessel, meaning it would be an unsupported spar between wave crests - and at the proposed size/mass, we can't build anything capable of supporting itself on that big a span.  So, it would break up.

Adding a conf file is the usual way to do it and the least trouble.  Otherwise you have to specify absolutely everything with command line arguments -- every time.

I only ever saw it in email, on three different cryptography lists.  Metzdowd, Cypherpunks, and one that's no longer funct. I heard that some people talked to him on IRC a few times but I never did.

There are a lot of 'obvious' ways to make the block times more stable.  But most of them also make it nearly certain that whoever has the most compute power gets FAR MORE than a share of the blocks proportional to compute power.

For example, if you ask people to solve a linear rather than probabilistic puzzle, then the fastest computer will win - every time.  If you ask people to solve a dozen puzzles instead of a single puzzle, then what you have is a time to completion with (approximately) a 'normal' distribution -- but whoever has a computer twice as fast as everybody else an earlier, narrower "hump" in their normal distribution than everybody else. Because 90% of the possible solutions are in the area of the 'hump' that comes before the area in everybody else's 'hump' the faster computer will get to its solution 90% of the time before someone else does, meaning double the compute power gets nine times as much probability of winning.  

I'm pointing this out because the complaint of getting beaten to every block is consistent with the problem of being in the smaller of two mining pools, or independent mining, under one of these flawed 'block time stabilization' algorithms.

What exactly is the mechanism by which the block times were stabilized?  And does it leave everyone with fair chances at getting blocks?

No.  The chain that started on January 9 2009 is the chain that is still active.

But there were several blockchains that started on earlier dates with different Genesis Blocks, in November and December of 2008 - each of which ended when it became clear that the protocol needed a fix and the fix couldn't happen leaving the early blocks valid.

This is why we have a 'testnet' now.  

I remember talking with him in email when he announced stuff to the crypto list way back in the way back.  He was very intense, in a way you started to realize only slowly.  If you explained a problem, he'd shut up and listen, then work night and day to fix it.  If you *told* him there was a problem, but didn't explain it, he'd badger you until you broke it down and made it exactly clear what you were on about.  Then you wouldn't hear 'boo' from him until it was fixed.  

Sometimes I remember thinking he didn't ever sleep if there was work to be done on the code; he didn't seem to have anything like a schedule other than 24/7 when working on code -- he was as likely to be online at any hour of the day or night as at any other, but wouldn't stay in contact for more than about 30 seconds.  But if there wasn't work to do on code (or if he was talking about the code or trying to get feedback) he seemed most active early in the morning (US/Pacific time). I have no idea if that was 'morning' wherever he was.

I have source code for the original Bitcoin client and miner, from November 2008.  in a RAR archive, if you can believe it.  RAR is obscure now.  Hell, it was obscure in 2008.  Nobody but an olde-skool dyed-in-the-wool download geek from way back in the 1980s would be all that likely to use it, and the number of people who'd even heard of it was dwindling fast by that point.

No RPC, no UPNP, no QT, barely any use of Boost.  It's just two files of C++ code.

I can confirm that the blockchain restarted several times while the kinks were getting worked out. The original code  has a different 'genesis block' hash.

The US and Japan have history that makes that really awkward.  

The Armistice they hammered out at the end of WWII deprived Japan of the right to have an Army or Navy.  In return, the US offered to 'protect' the Japanese from outside aggressors.  Now, in fact the US hammered this so-called agreement down Japan's unwilling throat at the end of the war as effective terms of surrender, but it hasn't really been a bad agreement for either side -- so far.

That armistice is, AFAIK, still in effect.  The JDF is not an 'Army' in the technical sense, and can't be construed as one by International Law because, for as long as the Armistice has been in effect, it hasn't taken military action on soil controlled by another government. And for all that a lot of their "merchant marine" is heavily armed and owned by the government, they aren't a 'Navy' by the same token -- they have never taken overt hostile action against ships which are part of the armed forces of another nation, nor targeted land-based installations or forces on the sovereign territory of another government.

So, if China attacks Japan, the US would be forced to either take sides with Japan, or withdraw from the Armistice.  Neither of which they want to do, because they don't want to be in a war with China and they don't want to lose face in the International community by refusing to honor the terms of their Armistice, and they don't really want Japan released from a broken Armistice and free to officially rearm.

On the other hand, if the Japanese attack China, they'd be sacrificing their US protection (whatever that's worth with China) because that would make their forces into an Army/Navy, which would violate the Armistice at no cost to the US.  It would even leave the US free to come in on the side of China if they wanted to (or if the Chinese made it worth their time) after being 'betrayed' by the Japanese.

If you figure it out, don't tell your legislators, or they'll "fix" it.

No nation accepts taxes in any form other than the official currency that they print.

Whether you need to pay tax depends on the laws where you are.  

If you're in a jurisdiction that treats bitcoin as money, and you would owe taxes if you received money, then yes.

If you're in a jurisdiction that treats bitcoin as a commodity, and you would owe taxes if you sold a commodity at a higher price than you bought it for, and later you sell it for more money than its current value, then yes -- later.

If you're in a jurisdiction that treats *ANYTHING* of value as 'income' and taxes income, then yes.  And maybe even 'yes' again later when you sell it, if you sell it for more than its current value.

If you're in a jurisdiction that doesn't really know what the hell bitcoin is yet, then maybe.  And 'maybe' is really the worst possible answer.  It means somebody can decide well after you do whatever you're going to do, that you were wrong and should have done something else and now owe a fine.

An alt coin *will* take the top spot from bitcoin.  But it won't happen quickly, and unless we see an alt more innovative than we've seen yet, it won't happen at all.

It'll take a coin that offers *MAJOR* capabilities that Bitcoin doesn't have.

It frequently happens that an altcoin is tooling along and then one day has the misfortune of becoming the most profitable altcoin to mine.

Immediately big pools jump on it with thousands of ASICs, make a hundred blocks in a few minutes, and drive its difficulty through the roof.  After that it isn't as profitable to mine any more so they go away, leaving the altcoin with an impossible difficulty target and basically at a point where it'll be weeks before anyone is able to mine another block. Further, people who were mining it get discouraged and go away, making the problem worse.

I have a simple proposal.  If an altcoin forms blocks by several different algorithms (SHA256, Scrypt, Proof-of-Stake, etc) it won't generally be the most profitable coin to mine in more than one of those categories.  And if it keeps track of the difficulty separately, it needn't be affected too badly.

So let's say someone is targeting a ten-minute blocktime and they've got SHA256 set up for a difficulty that gets a block every 40 minutes, scrypt for a difficulty that gets one block every 40 minutes, and two other hashing algorithms also set up for one block every 40 minutes each.

Now run the scenario.  A big ASIC pool jumps on the coin, but gets only about a quarter of the expected reward because the SHA256 blocks are spaced at 40 minutes instead of 10.  But if they run through it until the next difficulty adjustment and then abandon the coin, it may be a week before one of the regular miners gets a SHA256 block, but they still get three quarters of the blocks they're used to getting.  Also, when enough blocks pile up, even if none of the rest are SHA256 blocks, another difficulty adjustment comes along and the SHA256 difficulty can start coming down again. 

Yah.  But I really don't like trusted third parties.  I'm trying to cut the current tribe of trusted third parties out of the deal in fact.

What I'm trying to do is set up the equivalent of a four-party transaction on two different blockchains -- where information can flow back and forth, but you cannot have a four-way transaction because two of the actors (or actually two of the wallets) are on one blockchain and two of the actors (or actually two of the wallets) are on the other. 

As an example of an application, consider the disarmingly simple proposal:

 "I'll send you 50 litecoin if you send me half a bitcoin." 

Each participant has a Bitcoin wallet and a Litecoin wallet, so they can do the individual movements.  The issue is whether they have to trust each other or not. Even with a modified protocol so a client can *see* both chains, or even with a modified blockchain so that key information from the other blockchain can be stored in the local blockchain and used by scripts, I don't see a good way to do it. 

If we come up with a solution for this problem, then we don't need coin exchanges to trade coins back and forth.   

I doubt this would ever happen with Bitcoin because I'm betting it would take a protocol modification and take a lot of security analysis to figure out how much risk an extra capability adds.  But if we can develop a modified protocol for altcoins that makes new coins freely and securely exchangable without a need for trusted third parties, that would rock.  Bitcoin could adopt it after the rough-n-ready risk testing is done on alts.

One possibility I've come up with is an "on-recieve script."  That is, a txout created with a stored script that runs immediately and automatically when a coin is sent to a prearranged txout.  You can put money in a txout with such a script, show the other participant a script that matches the hash so he knows what it is, and then either one of you could trigger it by sending a coin to the address.

So if we have an on-receive script that

* checks the block height or time to make sure an agreed-on interval has gone by and aborts if not,
* checks some 'oracle' information about the other blockchain to see if a transaction there has happened,
* and sends the coins stored in the scripted txout immediately to Bob if it has or Alice if it hasn't,

Then we have a situation where someone could present cryptographic proof that a given transaction has taken place in the other blockchain, store it in the 'oracle' location, immediate blockchain, and then either of them could trigger the script to run (either paying the seller or returning the buyers money) by sending a penny to the address specified in the scripted txout. 

There is one main problem with that idea.  "On-receive" scripts open a whole big can of worms that needs very careful security analysis. 

He did in fact announce it.  As widely as he could anyway.  He published the paper, he discussed his paper on the cryptography list, he did everything but jump up and down and wave his arms.  Hardly anybody from the crypto list mined it mostly because hardly anybody thought it would succeed. 

Remember bitcointalk didn't exist, and if it had existed there'd be nobody on it. So announcing it here would have been pretty meaningless.

It isn't at all doubtful that he mined that much.  He wanted to prove the concept and he felt it absolutely necessary to secure the blockchain so nobody could come along with a really good computer and force a chain reorg. It's all about trust; he wanted Bitcoin to be trusted and therefore it had to have mondo hash power.  Until other people were providing enough hashing power for him to be confident of security, he mined like crazy.

That said, he's an idealist and it isn't very likely he will actually start spending the coins.

Nope.  Protocol doesn't work unless they are separate transactions. I mean, yes, the Bitcoin protocol works fine with a single transaction among four people.  But the particular trick I'm trying to do wouldn't.

That means both exchanges have become reliable enough for arbitrage. Up until now, delays in getting your money out and general unreliability during fast movements in price and the heavy load they cause have meant arbitrage has been risky or darn near impossible.