bump.

Just a note folks.  The debate's been here for a while. 

We do something, or we keep kicking the can down the road?

You need lines 161 to 165 of chainparams.cpp for mainnet, and lines 220 to 224 for testnet.

Here's the mainnet source:
and here's the testnet source:
In both blocks, the first line is the pay-to-pubkey prefix byte, the second is the pay-to-script-hash prefix byte, the third is the secret-key prefix byte.  The fourth is a sequence of four bytes that prefixes deterministic-wallet public keys (so called "stealth addresses", as well as special keys that allow someone to accept but not spend payments &c. ) and the fifth is a sequence of four bytes used to prefix the corresponding deterministic-wallet secret keys.

Because the the prefix bytes are attached to a base256 encoding (ie, binary) of known width,  they affect the leading cinquantoctal digit of the corresponding base58 representation of the same number.  That zero is why mainnet pay-to-pubkey txouts always start with 1, the 5 is why mainnet pay-to-script-hash txouts always start with 3, and so on.

Incidentally, the four-byte prefixes correspond to cinquantoctal prefixes 'xpub' and 'xprv' on mainnet and 'tpub' and 'tprv' on testnet.  Somebody with far too much time to invest in encoding transformations figured out what range of numeric values would start with 'xpub' and 'xpriv' etc when converted to base58 from a binary number 4 bytes wider than a key value, then exactly which four bytes to prefix to ensure that the base256 representation always yields a number in that range.

I cannot think of a single way to reach a fair distribution without having a permissionless-entry stage.

I mean, when he INVENTED coinage Croesus of Lydia went entirely the other direction:  He said, "Here are tokens I give out to people who do me favors.  Now all of you have to give me one every year, so you all get to figure out what favors you can do for the people who do me favors in order to get them to give you one... every year."

In one swell foop the guy invented currency, government corruption, and taxation.  And, oh yeah, capitalism.  But he didn't see that last one coming.

The point is, not only was it "Permissionless" entry, it was COMPULSORY entry into the market, fostered by everybody working under an unavoidable debt.

CfB doesn't have the power to compel people to use his tokens, so permissionless is really the best he can do.

Hey, I got nothing against Proof-of-stake.  In fact it's got a lot going for it and I think I know a better way to secure a PoS chain that I'll probably try to do.  But because I'd want a fair distribution, I'll start with proof-of-work or something like it, then transition gradually to proof-of-stake over the course of years, while continuing to distribute coins steadily -- making a very slowly-increasing fraction of the distributed coins be PoS as opposed to PoW until the PoW awards are insignificant compared to the rest.

It's at least 900K bitcoins.  Possibly some number up to 1.3M bitcoins.

No address we can associate with Satoshi has ever spent a single dang coin except in a couple of test tx he sent to Hal Finney way back in the wayback.

Man, they never listen. 

It ain't about PoW vs PoS.  It's about allocating all the darn coins so close to the beginning that it makes no economic sense.

Secret keys on testnet start with 239 (as the wiki page says) but in base58 form do they really start with 'c'?

I don't have a key to edit the wiki, but for whoever does, the following page: 

https://en.bitcoin.it/wiki/List_of_address_prefixes

is wrong about what initial bytes bitcoin actually uses in its addresses.

From the source code, we have

0 for base58 '1' (pubkey addresses on mainnet)
5 for base58 '3' (scripthash addresses on mainnet)
128 for base58 '5' (secret keys on mainnet) <--- wiki page says 111
111 for base58 'm' or 'n' (pubkey addresses on testnet)
196 for base58 '2' (scripthash addresses on testnet)
239 for base58 '2' (secret keys on testnet)    <-- wiki page says base58 'c'

It really is upsetting how many THINGS bitcoin building depends on.

How many things a version change in some code not controlled by it can screw up or introduce vulnerabilities in.

I know all the cool kids are using boost, but did a crypto project really need the vulnerability to version rot?  I know all the cool kids are using OpenSSL but did we really have to wait until a version upgrade broke our consensus before we implemented a consensus library to get past it?  I know all the cool kids are using autodeps, automake, autoconf, etc, but those still change often enough to distrust them for a crypto project.  

And then there's C++.  A language in which arbitrary and unexpected behavior can be lurking behind every overloaded operator, implicitly called constructor/destructor on procedure entry/exit, etc.  

And the STL, which leaks copies of information in deallocated memory all over the place if you're not extremely careful.  Still, you've got explicit memory management so you CAN avoid leaking copies of information in deallocated memory if you are very careful, and that's more than I can say for most "modern" or "more convenient" languages.  

And the STUPID depending for a binary format on a database that changes its binary format with EVERY new release, which has forced us to maintain our own archived copy of an obsolete database that has had security bugs fixed SINCE we did!  The only reason our wallets aren't vulnerable is because we used them to store encrypted data in the first place. 

As an old cryptogeek this is a nerve-wracking codebase.  Don't get me wrong, the code is good - but doing all this, and trying to stay secure given the limitations and version changes of all these tools, is like dancing on a tightrope over a fire.  I vastly prefer C, where every operation is visible and every operator does exactly one thing.  In C it's easy to know when things AREN'T happening.

D'oh! 

I figured it out.  I had a version mismatch in my automake and needed to regenerate aclocal.m4 before configuring so it would correctly create test_driver. 

I just ran 'make check' on a freshly-built bitcoin 0.10.0 and got 2 tests passed out of 3, with 456 failed test cases. 

All of them are from src/test/crypto_tests.cpp and state "error in sha256_testvectors": check hash == out failed."

Please tell me this is because I've got something configured wrong.....   

Looking more closely at the atomic cross-chain trading protocol, I have a bit more coding to do for security.  

It works fine as long as both chains are proceeding, neither party can block the other from making a transaction in a given timeframe, and a reorg doesn't block out just part of the protocol on one or both chains.  But dealing with alts, often the block chain security is kinda thin, and I can't really trust that there'll not be long reorgs created by attackers -- either on my chain or one of the others.  

First thing, for secure cross-chain trades, because the protocol depends on transactions waiting until after other transactions have occurred,  I'll absolutely have to add minimum and maximum block heights to transactions. That is, a transaction would not be valid in any block prior to its minimum block height, nor in any block after its maximum block height.  

Second, I'll want to implement time-locked outputs;  That is, different outputs, even if created in the same transaction, will need to be able to specify different minimum block heights before which they cannot be validly spent and possibly even different maximum block heights after which they cannot be validly spent.

Finally related to secure trades, and also to eventually implementing proof-of-stake that doesn't give attackers infinite free shots at causing reorgs,  I'll need each tx to specify a very recent block (current block as of the time the tx is created) and not be valid in any block chain that does not have that block as its ancestor.  This will prevent a couple of possible scams involving chain reorgs either on the metacoin chain or the chain it's crossing with; if a given tx is invalidated by a reorg, then other tx in the same sequence must also be invalidated by the very same reorg.

I keep spending coding effort on this thing, like a hobby; maybe in the back of my mind I have already decided to do it.  With my conscious mind I still have huge doubts.

Doge, for all that I don't care much for its prospects, at least doesn't appear to be a scam.  Or at least, not actively scamming at this time.  Litecoin likewise doesn't appear to have any active scams going. 

But, honestly?  The single most non-scammy alt I can think of is Namecoin.  Thousands of nodes on their network all the time, mostly just because people are running full nodes in order to keep their browsers updated on the .bit domains.  Namecoin actually provides a real service, so there's a constant non-pump demand for it.

I'm not sure of the context for this comment, libsecp2561k is plain C.
[/quote]

No , that's a real effect of using c++. I appreciate that secp is in C. 

C++ allows a lot of hidden actions and allows them to be redefined via overloading. It's very hard to be sure that nothing unintended is happening when using C++. The fact that the Bitcoin software is written in it is at best unfortunate for hardcore security reviews but it's hard to put up a good GUI app with anything better for security.

I propose a game.  It's called "I am Spartacus!"

Next time the question comes up, just claim that you are Satoshi Nakamoto.  And I don't mean any one of you, I mean every one of us. 

Anytime a reporter asks.  Any time a newbie asks.  Any time one of these spec threads comes up.  There's one right answer, and the answer is,

"I am Satoshi Nakamoto."

Seriously, let's try it. 

I may yet do it.  I did re-base it to Bitcoin 0.10.0 this week, following the latest Bitcoin release for all kinds of improvements in block chain handling.  I haven't implemented my side of the transfer-between-chains thing for anybody to be compatible with, and of course they'd need to add the code to their altcoins (and have a hard fork each for a couple of new transaction types) before it would work.

Mostly I've been not pursuing it because I don't want to explain to two or three hundred scammers why I'm not going to be making an effort to be compatible with their scamcoins.  Seriously, the altcoin world is filthy these days.  I would go so far as to say MOST alts actually have no interest in application as currency; their model of issuance (with most of the coins out in the first year, or coin production cut by more than half in the first year) makes no economic sense for that.  Nor does the ludicrous notion that it is reasonable for a significant fraction of the entire money supply to be reserved for one or a few people.  And one is left with the unfortunate implication that most of them have no reason to exist except as scams. 

And, do I really want to facilitate trading between scams?  Considered as an economic force, in the short term easy trustless trading would facilitate some scams and make others more difficult.  The question is, in the long run would it favor the less scammy operators?  With trustless trading, would market pressure mean the pump-n-dumps end with less money effectively stolen?  And hopefully faster, or with more accountability, or both? 

See, I'm of the opinion that the "fast distribution" thing is lame, and ultimately leads to the collapse of the cryptocurrencies that do it.

If the creation of coins in the beginning is more per block than, say, one and a half times what it is a year into the issue, you're doing it too fast.  In fact the economics would make more sense if the distribution per block a year out was slightly *more* than the distribution in the first few blocks, giving a very mild constant but permanent rate of currency supply inflation.

I think a lot of these altcoins fail because the distribution is way too fast and way too front-loaded. The resulting economic model whether for use as an investment or a currency is just plain broken. 

The only sensible way to interpret a coin where the early miners/early investors get way more than anybody else is as a ponzi game where the early investors are looking to make money on fools who come along later or hold on for longer.  The point is that Ponzis always collapse, and any sensible person can see that it's going to collapse (even if most of them can't figure out exactly when) so keeping it as an investment is just plain dumb and using it for spending money is a continual search for the greater fool who will accept it believing that the collapse is just a little further out than you believe it is.

If you want to be making a cryptocurrency that makes any kind of economic sense as a currency, the rate of currency creation a year out ought to be about the same, give or take  up to 20% depending on what kind of economic model you're looking for, as the rate of currency creation on the first day.  Let the rate at which new coins enter the economy remain fairly constant as you make the shift from PoW to PoS, and make that shift gradually and carefully. 

I wrote a nice multivalent-amount library, so you could have a txout representing any of thousands of different coins all trading on the same chain.  It would require some support from the clients (and miners) of the various altcoins to allow coins to move back and forth from their native chains though.  I was even sorta getting ready to maybe launch it.

But then I looked around at the altcoin markets and decided that most altcoins are scams and I didn't want to contribute to that.

I don't think there really is a reasonable way to have a 100% proof-of-stake coin that's that way from the very beginning.

I've been considering it recently, actually; I think the best I can do is to make a coin with a fixed proof-of-work award that never changes, and then inflation in the form of "interest" awarded for destroyed coin-blocks (coin-days times actual blocks-per-day) in transactions.

So, I'd start off awarding 10 coins per block, or whatever, and keep doing that indefinitely (you might prefer to stop after a couple of years) - and whenever somebody makes a transaction, the miner gets a month's worth of interest and they get the rest for proof-of-stake. 

And the "longest chain" is the longest chain by proof-of-stake and proof-of-work in the same ratio that POS:POW coins have been awarded, so there'd be a very gradual transition to being more and more centered on proof-of-stake as time goes on.

The interest rate would depend on the block rate, of course - but for 10-minute blocks, it would be an "approximately fair" rate of interest to multiply the input by about (1+10^-6)^coin-blocks. 

I actually have coded an unlaunched alt with multivalent amounts - so I could easily launch a blockchain tomorrow that can keep track of thousands of different kinds of coins, and keep them all separate, and allow trading between them on the chain. 

But moving them back and forth to their native blockchains is something that the devs on those blockchains would have to provide a way to do.