Just FYI, I read more about Namecoin, downloaded it, did a source comparison to bitcoin, installed it, ran it, bought some NMC, liked it.

I am coming to regard work sharing as an essential feature in a BTC competitor.  Someone (perhaps I) has to code support for accepting blocks with an associated hash that only indirectly hashes the block.  Mike has kindly described this process in some detail here: https://en.bitcoin.it/wiki/Alternative_Chains

With this change, the barrier to entry for mining new chains would be practically gone.  With a bit of setup, rigs would begin mining BTC, NMC, BC2, etc., using the same calculations!  New chain promoters could pay miners a small fee (related to setup and bandwidth) to include the chain in a Merkle tree of block headers tucked into the Bitcoin coinbase script.

The next question will be monetary policy details, but it doesn't really matter.  Just put up a site where people can post their favourite policies, promotional material, and instructions to mine currencies governed by them.  The market will choose among them.

For example, I imagine a bitcoin whose money supply goes as the log of total difficulty.  It would be a simple matter to code it up, given a "hook" interface like what VinceD created for Namecoin.  I'd distribute the code as a plugin to a modified Bitcoin client, pay the going rate (low thanks to Mike block trees) to get a lot of miners hashing on a chain, and start promoting the new currency.

If I see this come about in the next few months, I'll be happy and stop worrying about early BTC speculators.  I may still curse the market for overvaluing BTC, but against bubbles, yea, even the gods themselves contend in vain.

oskar, thanks for posting your summary just as I stumbled upon the thread!  Good thing I started reading it at the end.  More suggestions:

Alternative chains

I would like to make it easy for distinct proof-of-work chains to share hashing power along the lines Mike proposed here: https://en.bitcoin.it/wiki/Alternative_Chains

I haven't completely thought through the details, but I think the "headers" message (or a successor) should support an "indirect" header in addition to the standard kind.  The indirect header would come with a standard header from another ("main") chain.  This "main" header would hash to a value below the target in the alternative chain, and the indirect header message would include:

• the main header's coinbase transaction, whose script would include a Merkle root of headers from different chains
• the Merkle branch anchoring the coinbase transaction to the main header
• another Merkle branch anchoring the alternative chain's header to the root contained in the coinbase script

This would avoid the need to fragment hashing power as is happening between Bitcoin and Namecoin.  This would encourage a proliferation of experimental currencies and other applications, which would be a Good Thing.

The original BTC block chain would not necessarily have to accept indirect headers, though it would be nice to have it share logic with chains that do.

Pluggable policies

Subtle differences in the block acceptance rules in use among miners threaten chain unity.  When (not if) a block appears and some, but not all miners accept it, confusion will ensue.  I would suggest a protocol field encoding the block acceptance rules.  It could be, for example, a hash of a Forth or C++ program.  Miners could obtain and compile (or interpret) the program when they notice they are hashing on the losing side of a chain split.  Obviously, they'd want to restrict this feature to avoid malware, so C++ is probably not the best choice.

I call it "pluggable policies" because I imagine changing the client to support loading and using multiple block acceptance policies for different chains.  This is not strictly a protocol change.

Agreed.  I personally have put only a fraction of 1% of my BTC into the keys that I generated with my homegrown script, cited earlier in the thread.  I would put more in, but I first want to prove I can get the BTC out, which will require another round of vaporware to condense.  Even if successful, I will want to test successfully about 100 times to become confident that it doesn't sometimes fail.  Some more vaporware might help: transaction validation code extracted from a popular client.  And even then, to store a lot of wealth, I would probably distribute it among several addresses.


My genkey.py is open-source, though not well tested as far as I know.  Are you thinking of a friendly front end for the key generator, plus an offline transaction signer and a patch to allow the official client (or BitcoinJ) to import and broadcast the transaction?  I plan to do this eventually (minus the friendly front end).  I might be encouraged to hurry up for some BTC.

@stillfire @mother_of_another,

Okay, NC is more interesting than I thought.  Thanks for the food for thought.

@stillfire

Despite the unfortunate name of this thread, the interest in a second Bitcoin currency in no way depends on notions of fairness or what the early adopter reward should be.  Those questions may lead one to an interest in a BC2, but the currency will stand or fall on its market value, if anyone bothers to implement it.  The questions of interest to me are: How much effort will it be to start BC2 (or BC3 etc.)?  How well will it compete against BTC?  And, what monetary policy will produce the best result?

I have read a little about Namecoin and found it uninteresting.  Certainly, it does not compete with BTC or address the weakness of BTC's early blocks.  If your point is that Namecoin is failing, and so therefore BC2 will fail, then apples to oranges.

I understand the technical details of how the currency works.  I will try to answer what can be done.  First, you must grasp the distinction between:

• Bitcoin, the technology properly called Nakamoto proof-of-work chains,
• bitcoin, lowercase, the currency ("BTC") based on a particular proof-of-work chain started in 2009,
• the block acceptance rules (monetary policy) implemented in the software used to extend a given chain, and
• the network of computing resources ("mining" or "hashing" community) working on extending a given chain and, in the process, protecting its transactions.

The technology can be trivially used to start new chains (even for non-financial applications as detailed in the wiki).  I have written in favour of starting a new chain with a policy similar to BTC's except for a much higher minimum difficulty.  ("Minimum difficulty" is a parameter of Bitcoin monetary policy.)  The new chain would result in a currency (herein called "BC2") functionally equivalent to BTC and competing with it but lacking the overhang of early wealth that concerns you.

BC2 would face several hurdles to acceptance similar to what BTC has overcome versus older national and digital currencies.  However, it would be based on a more proven technology than Bitcoin was in 2009, and the technical barriers to its adoption as a BTC alternative would be slight.  For example, once critical infrastructure supports BC2 (Block Explorer and MtGox, or something like them, come to mind), merchants, miners, and pool operators would have only to repeat the steps they took to support BTC.

It is hard to discuss this proposal in the forum, because most users oppose the idea, and many put it down to "jealousy".  I do not presume to know the motivation of any particular BC2 opponent or opponents in general, but one reason may be that they have a lot of BTC, want to profit from the continuing rise of the BTC price, and fear that a competitor could derail this plan.  Or perhaps they worry that a second currency will confuse the public and threaten the technology's acceptance.  Some may scorn the idea as a plan to punish the Bitcoin pioneers.  I consider objections on these lines baseless.  As I see it, a currency like BC2 would make an attractive product in comparison to BTC, and the potential value of all BTC (in a rational market, if such a thing exists) is inherently limited in a way that would not apply to BC2.  (Look up Forum user unk's posting history for some eloquence along these lines.)

I doubt that most Bitcoin users are aware of the situation, let alone how it came to be.  (BC2's chance of success would benefit from spreading this knowledge.)  Please look at Sipa's graph of difficulty and network hash rate over BTC's entire history: http://bitcoin.sipa.be/speed-ever.png.  Difficulty was at the minimum (because few computing resources went to mining) through nearly all of 2009 and didn't really take off until July 2010 (with the advent of GPU mining).  During those first 18 months, when the project could at best have been described as experimental, 65000 blocks were mined.  The "work" expressed in those blocks' hashes would get you perhaps about one block at today's difficulty.

This would be no big deal, but for certain of Satoshi's monetary policy choices, which the early user(s) supported by running his software.  Namely, the 50BTC reward for each block (constant over the period in question).  This fact of policy translates into 3.25 million BTC earned by whoever mined those 65000 blocks.

Satoshi could have chosen another formula for bitcoin creation (without having to abandon the deflationist principle or the 21 million bitcoin limit).  He could have chosen a formula that would have slowed money creation to a trickle while difficulty (more precisely, network resource growth) stagnated.

Some people may look at this and conclude that Satoshi designed it this way to obtain a lot of bitcoins for himself and his friends.  I don't see it that way at all.  Taking Satoshi at face value, I think he expected the climb in network hash rate to occur 12-18 months earlier than it did.  I think he did his best to promote both the technology and the currency before and after he started the chain, and it is really a matter of chance that it caught on when it did and not earlier.  Going out on a limb and giving Satoshi the benefit of the doubt, I think he is disappointed that it took so long, even though an earlier widespread adoption would have left him with far fewer BTC.  In other words, I think he and his fans wanted most of all to establish the technology for the benefit of humankind, and that amassing great wealth was, at best, a secondary motive.

With all due respect to the amazing thing Satoshi and the team have created, they have not been backed by a large budget (at least until recently) and have left several loose ends to be addressed by stakeholders once the system grows.  For example, ambitious scalability improvements have been proposed but not implemented, not even in a proof-of-concept.  The simplicity of the total BTC curve has more to do with Satoshi's time constraints than elegance or popular appeal.  To the list of loose ends, I think we can add the need to create a stronger block chain.

How best to do that is a question I've worked on and discussed a little in the forum, but I will leave it for another post.

Here's a wallet created with keypool=0, binary attached(upload folder is full), db_dump shown:
EDIT: broke up long lines

Note the long strings of 'ffff' apparently in the middle of the private key.  The public key starts with '04ff5443...' and is the last 65 bytes of both the database key and database value in the lines starting with "036b657941" and "fd17013082"

If I had massive wealth in BTC, I guess I would build OpenSSL from source and step through key generation to discover what is going on.

Thank you, yes, I have read many of unk's posts, and I like him or her.  I favour conservatism when it comes to changing features.  For everyone who supports New Feature X, two may oppose it, and three may not care but would rather stick to what they know.  But I won't be surprised if there are a few compelling changes to be made, possibly even in the area of inflation policy.  In the end, miners and users determine what works, but coordination before a launch seems useful.

p.s., your use of the term jealousy suggests to me that you don't really understand the argument.  It is not jealousy that makes me ride a bike rather than drive.  It is a personal preference and a reasoned judgement of the relative merits of both.  Anyway, jealousy and ambition (or inspiration) could be two facets of a single phenomenon.

I, too, agree 100% with Steve's post.  (By the way, I stopped following pro sports around 1990.)  If you are referring to me (the OP) as one who prefers "forcible imposition" over free market competition, I suggest you read more carefully.  Nothing could be further from the truth.

If my squawks come across as complaints or whines, go away!  In fact, I am expressing demand for a new product in the hope of gauging such demand among the broader market and finding people capable of assisting in such product's creation.  If you can suggest a better (less intrusive, cheaper, or more effective) way for me to find interested parties, I will gladly listen.

Let's see if I can recast this in Ayn Rand terms...

1) OP can afford a Ferrari.
2) OP wants a Lear jet (go OP!)
3) OP is insightful, daring, and innovative (my hero!)
4) The cloud of seigniorage threatens the market value of OP's portfolio.
5) OP wants to create and profit from something of greater value than all the world's BTC.

Does that look better?

Getting back to the "antidote" that this post is about, I really don't see the need to support BTC destruction as a way to create BCP.  It is complicated and probably controversial, as it seems to attack BTC in an unfriendly, not to say unfair way.  A little patience with minting the new currency would, in my opinion, pay off better in the long run.  A BTC<->BC2 exchange would be very straightforward to set up (technically, not to say legally) and would be the way to distribute the new currency to non-miners.

I also no longer feel the need to "poll" miners prior to working on a genesis block as I outlined in another thread.  The initial difficulty should be on the order of 10,000 to 100,000 (or 2-20% of BTC difficulty at the time).  And the project (and supporting software) should be widely advertised among Bitcoiners, so anyone who might be interested can make a conscious decision whether to join at the outset.  Apart from that, we do not have to regulate the generation speed of the first blocks.

In a few years' time, assuming ASIC mining or quantum mining overtakes GPU mining, there may arise a perception that yet another startup currency would hold more value than BC2.  And that would be fine.

Good distinction.  But by choosing between buying BTC and starting up a competitor, we implicitly set a value on BTC's first mover position, which is the pioneers' reward.

Clever proposal!  I love the idea of improving the client as a vehicle to promote BCP.  Of course, barring some kind of non-free license, the current maintainers could just cherry pick and merge their favorite features into the original client.  Would you propose to try to prevent that?

How would you reconcile

with

given BTC's rising difficulty?  Lower the conversion rate for future mined BTC, perhaps to zero?  Looks like some devil-in-the-details, but I look forward to your thoughts.

p.s., Your mockup is beautiful, and you should feel proud.  Eye of the beholder thing.   

I maintain the analogy is relevant.  In the example, I did not ask whether you would pay the tax but whether you would have voted for it.  We are now voting on how much to reward Bitcoin pioneers by valuing BTC.

Apart from that, I agree with your comment.  If Bitcoin and the 2009 chain "offer the best return" for something, rational people will use it for that thing.  If something else offers better return, we will switch.

Granted.  But putting money into Bitcoin will not recover those dollars.  The interesting question, to me, is how much the market will value BTC versus a hypothetical, similar, fledgling competitor with lower seigniorage (higher minimum difficulty).  I am considering working on changes to the software that would support creating such a competing currency (or more than one).


Bearing in mind my caveat about TPTB, in a hypothetical, plutocrat-free world, even $100bn would have been outrageous.  If someone has been flogging me daily, would you berate me for not showing appreciation on the day he merely slaps me?

I don't know, maybe.  If bonds are denominated in it, they may still be outstanding.  And I'm sure lots of programs, on seeing "XBC", will display "European Unit of Account 9" to the user, which could be a real head-scratcher if the intent was bitcoin.


+1

Let's just say I advocate spending 30 minutes to test your hypothesis.

Obviously, the similarity to BTC would make porting BTC-related infrastructure fairly easy.  I doubt many serious merchants accept only BTC currently.  They added BTC to their list of supported currencies, so adding BC2 won't be any harder.  It will be much easier.  As soon as a few do it, people will see it and wonder what BC2 is.  They will find a website and learn about the similarities and key difference.  They will add some BC2 to their wallet and devote a portion of their mining power to it or inquire about it to their pool operators.

Creating a BTC-BC2 exchange seems like an afternoon's work, if MtGox doesn't beat me to it (or my lawyer talks me out of it).

Thanks
-John

@Littleshop @Vladimir @FreeMoney,

Thank you for your comments.  Actually, I believe I have a handle on the challenges to the proposed project.  Had Satoshi and the early team sought funding in the venture capital market, I doubt anyone would have given them the time of day.  New chain advocates are in a similar position, though I don't see it as requiring nearly as much development (or marketing) work as has gone into Bitcoin.  Maybe 10% as much of each.  Not a trivial amount, nor a prohibitive one.

No, I would not expect to make "a super easy million bucks".  I would hope and expect (eventually) to found a stronger currency using mostly existing tools, just as Satoshi and the rest built on OpenSSL, TCP/IP, and C++ in addition to Satoshi's insight.  Notice that I said initial difficulty should be on the order of 5% of the BTC chain's as of when the new chain starts.  Part of the project involves miner buy-in, as I described in the linked thread.

I would expect a new chain to remain a junior cousin to 2009/Nakamoto for several months to years until a critical mass of users saw its key advantage.  And, very likely, it would be surpassed by something else started by someone else building on my/our work.  Very likely, nothing would unseat BTC, but a good effort will cement BTC's position and thus advance the community's purported goals.  This would make for a nice consolation prize, in my opinion.

In case it's not clear, I do not advocate a "chain fork" in the sense of a second chain rooted in Satoshi's genesis block but diverging from BTC at some block N.  I am talking about a new genesis block with Block N's hash in its coinbase script as a timestamp, nothing more.  I would survey interested parties for truly compelling changes (Vladimir listed some candidates) but would tend toward conservatism under the theory, "Why mess with success?"

unk, noted, thank you.

The design I have in mind would facilitate creation of chains with different policies.  Of course, there is some advantage to reusability of infrastructure if the policies are similar.