Right.  Instead of looking for the stats we can't get, we should be looking at the stats we can get and figuring out how we can use them to make something that works better than if we ignored them.  

So, really, that's what I'm interested in too.  The stats we can get from the block chain aren't exactly the NGDP, or aren't exactly the velocity of money, or whatever,  But they are what we can get, and if we're to do any better than we've done they're what we have to start with.  

I'm no economist, and I don't know what to assume or do about them, but surely they are related to figures that economists have studied?  Maybe not perfectly, but enough for some broad empirical rules under reasonable assumptions about those relationships, about how to respond to them to make things better than they'd be if we simply ignored them?  

'Cause if we can't do better than ignoring them what's this conversation about in the first place?

Let me see that I correctly understand the way it works.... 

A miner first constructs a potential block in the dependent blockchain.  He takes the hash of this block, then constructs a potential block for the bitcoin blockchain embedding the hash into a coinbase transaction.  - maybe as part of a script on the output or something? 

Now he starts hashing.  If he finds a hash with difficulty acceptable to the dependent blockchain, he packages up the entire bitcoin block header, with the hash, and publishes that in the altchain block as his proof of work.  Altcoin miners can check the block, verify that the hash goes with the header and the nonce and meets the altcoin proof of work requirement, and accept it. 

If he finds a hash with difficulty acceptable to the bitcoin blockchain, he sends the block to the bitcoin blockchain, complete with its somewhat funny-looking coinbase txout containing something that wasn't strictly necessary for Bitcoin.  He can spend the txout, and it's a valid tx that everyone else on the bitcoin network can check, so this isn't a problem. 

It is possible in principle for a hash to be published in either chain or both or neither, or in the case that multiple altchains are being merge mined, in any combination of them.

If merge mining multiple altchains, the miner must embed multiple hashes into the coinbase transaction - which shouldn't be too difficult if the alts cooperate with each other,  but the altchains need to know how to find their own block hashes and not specify so much about the shape of the coinbase transaction that the miner cannot construct one that successfully contains all the hashes in a usable form.

Do I have this right in principle?

I am working on a project which requires a blockchain.  Rather than trying to scare up a cadre of hashers and trying to keep a tiny new altchain secure in a world where whales can eat such small blockchains for a snack or even destroy them accidentally, I would like to take advantage of the vast SHA256 hashing infrastructure that has been built for Bitcoin. 

Is there any guide available for creating a merge mined coin that gets down to specifics like blockchain header structure etc?  And how to modify mining software to test it against a bitcoin testnet chain? 

Or should I just download Namecoin/IXcoin/CoiledCoin sources and try to figure it all out from the worked examples? 

+1.  Dev would be a highly relevant topic for the altcoin forum; it would be very nice to have it separated. 

In the presence of transaction fees, I think we can rule out many sources of 'noise' in measuring the velocity of money.  One can move coins to a different account within a wallet without incurring fees, and if wallets become sophisticated enough for accounting purposes, a natural desire to avoid incurring expenses ought to mean that money hardly ever moves between wallets unless it is genuinely being moved between actors. 

So we should be able to know, instantly, what the velocity of money is.  We can detect how much of the money supply is spent in every ten-minute block and we can react.

keep in mind that with a cryptocurrency we can directly monitor and instantly respond to any changes in the velocity of money. 

We know exactly how much money is spent every block.  We can apply any kind of deterministic calculation to it to adjust the money supply over subsequent blocks.   Does that help?  I mean, if we observe that the velocity of money is contracting sharply (or expanding sharply) what adjustments ought to be made in upcoming blocks to preserve a stable economy that 'seeks' a particular level of inflation/interest?

The only real issue I have with transaction fees as normally implemented in cryptocurrencies is that the externality they supposedly compensate for applies to everyone operating a full node, but that the people being paid for that externality are exclusively the much smaller set who have specialized hardware to solve block formation puzzles.   A distortion in the allocation of fees to offset costs seems to me no less certain to lead to economic distortions destroying value than a distortion in the amount.


Interesting.  I came to exactly the same conclusion when I spent some time thinking hard about it, with the added condition that the end of the trading period should be probabilistic (like the end of a block interval) rather than deterministic (like the end of a minute).  Otherwise people would be playing endless games about the last fraction of a second before the end of the period.   But anyway, I'm all in favor of the model where all bids and asks for an interval are matched up and executed in batches where every seller and every buyer get exactly the same price.

It is actually quite hard to target a particular rate of interest or inflation (measured in value) by adjusting the number of units of currency in circulation.   As an altcoin implementor you can influence the latter only.  We tend to assume that in some hypothetical steady state it eventually averages out that the value inflation and the currency inflation track each other in the long run - but is that purely a naive illusion?

Let me put this gently.

If the people of Iceland want this coin to succeed, there is only one thing they need to do. 

They need to secure the damned blockchain.

That means point your computers at it and mine.

I don't have any great solutions, but I've sure been admiring the problem.  

Eliding a whole lot of discussion of economic principles, I want to enumerate the 'levers' I can see that could easily be set (and not easily 'gamed') to try to create a stable cryptocurrency money supply for a healthy economy.

First, we can adjust the block formation subsidies over time.  This is the primary means by which new money now enters cryptocurrency economies.  I think offhand that the "halving every n months" model is the wrong model.  I'd be more confident in a model where each year 5% more is awarded than the previous year.

Second, we could have transaction fees that destroy a small fraction of the money whenever it's transacted.  In "normal" cryptocurrencies transaction fees are simply transferred to the miner - but in principle, they could instead disappear from the economy, or we could have some fraction disappear and some fraction go to the miner instead.   These tx fees are now usually set proportional to the disk space occupied by the transaction, but in principle they could be dependent on some other feature of the transaction or the block the transaction gets into, such as the amount transacted.  

Third, we could have money be created (or destroyed) in proportion to the bitcoin-days destroyed by a transaction -- effectively paying interest or charging demurrage on the interval for which the coins have been held prior to the transaction.  

We could also influence factors such as the velocity of money; for example we could regard as invalid or nonstandard any transaction that did not destroy at least as many coin-days as the number of coins transacted - meaning that the coins could not be spent on average more often than once a day.  Of course, if you have a penny that's four months old, that would mean you could spend a dollar instantly when you get it - it would be a matter of averages, not a requirement on every individual input.  I think of this because I think of the volatility caused by people who spend their money a thousand times a day (robotic twitch-market traders for example) as a bad thing.  

Some combinations of these could be more interesting than they are on their own; for example, a cryptocurrency could charge a tiny transaction fee based on the amount transacted, while simultaneously creating new money for the coin-days destroyed, such that transactions where the inputs were on average more than a week old create more money than the transaction fee (meaning free transactions, or even a bit of extra money back) while transactions where the inputs being spent are less than a week old would mean you had to pay some of the transaction fees out of the inputs.

But anyway, these are the levers we have to work with.  Transaction fees, block formation subsidies, interest/demurrage on the inputs used up in a transaction, and transaction speed limits.  What combination in the opinion of people who've actually studied economics would be worthwhile?  

I don't really understand why anybody uses web wallets. 

Use a local wallet.  Keep it encrypted.  Unencrypted keys are never stored, and keys encrypted or not never leave the local machine.  Keep it on removable media and remove it when you're not using it.  Then just run an OS more secure than Windows to keep keyloggers etc off of it.

So, yes, a uint64_t is capable of recording up to 18446744073709551615 Satoshi.  And the entire money supply of bitcoin only amounts to 2100000000000000 Satoshi, so there were a bit more than 3 orders of magnitude to play with.  

While the amount in a txin or txout can't be negative, you don't want to use an unsigned int for it, because internally you often compute differences, and those can be negative.  Remember, 'if (A - B < 0)' is *always* false with unsigned quantities.  So if you weren't super-careful you could get it wrong doing things like checking to see if the total outputs of a transaction are smaller than the total inputs.  

If you wanted to subdivide into smaller fractions, you could do that, up to 3 orders of magnitude.  All that would be required is raising the COIN constant, fiddling with the 'units.h' file, and a few other minor adjustments.  Of course, then you'd have to stick in code that interprets amounts written in the blockchain before the switchover differently.  

Conversely if you wanted to have a bigger money supply, which many altcoins do, you could do that too, by pretty much the same procedure plus modifying a few things like MAX_MONEY and the payout schedule, etc.

Or you could use something bigger than 64 bits, I guess.  But you don't need to.

I think there needs to be some cryptocurrency development specifically to address business concerns. 

Bitcoin is digital cash.  That's fine, but businesses don't actually use cash very much.  They accept cash as payments, sure, but when they turn around and pay someone it's always a check or an EFT or a payment authorization or a money order or something. 

And there's a reason why businesses use these forms.  They use them because they limit risk due to theft, because they limit risk due to embezzlement (which is also theft but has a different risk profile), because they involve counterparties who can revoke payments if the payee fails to perform, because they leave a paper trail specifically so that it is possible to know exactly  who is being paid in terms of real-world identity, because they leave a paper trail specifically so that they can later prove that the payment was made and when and who authorized it, and for many other reasons -- many of which are the same reasons why the crypto-anarchist contingent want to NOT use those means of payment.

The crypto-anarchists and the businesspeople agree one hundred percent on keeping down payment processing costs.  Cheap is good; free is better.  Businesses now are using these other payment forms rather than cash even though they increase bottom-line costs in the normal case, and that indicates that these additional services have substantial value to them. 

I think that if we want to provide that value -- if we want to "get traction" as something that businesses will actually use -- then we have to build these capabilities into the blockchain.   

An issue like this sort of illustrates the divide.  Technicians can be satisfied with the "just issue a double spend to invalidate the pending payment" solution, because there's a reasonable way to get the effect - but if you're going to be using it for business purposes, you want it in a more solid nailed-down format; one where everybody knows exactly what the rules about this tx are and nobody has to take any final step to get it to (not) happen after the deadline. 

it would be a useful facility.  As you say it would reduce the motive/rewards for theft.  Unless the thief also controls one of the output addresses, the key to the input could not be used to directly get the money for herself. 

Also it would be a useful escrow-ish ability, along with outputs spendable only after a certain date.

If you want the files in a different place, then move them to a different place and alter your launcher to call

"bitcoin-qt -datadir=location"

instead of just

"bitcoin-qt"

(where location is the directory where you put the files of course).

Well, somebody has to have a better idea.  The money based systems have collapsed.  Again and again and again, ever since forever.  But what emerges from the wreckage, so far, has always been another money based system.

I think money based systems *are* consistent with sustainability, but so far haven't been sustainable under human management.  Is our management ability getting any better?  I dunno.  Maybe.  We have power tools for information that we didn't have before.  Maybe we'll be able to apply some decent craftsmanship now on a large scale. 

I don't think I get why the limit is at 2h either.  Generating blocks is probabilistic and does sometimes take that long, but that's difference from the current time, not difference from the last block. 

1h is needed to prevent a significant part of the network from dropping during DST adjustments.  Yes, there are still some systems that don't have a stable internal clock set to GMT, and those are sensitive to local-time resets which are different from country to country, sometimes automated and sometimes not, often forgotten about, sometimes both automated and done by hand, sometimes done the wrong direction out of confusion, etc.  The DST changeovers are an old network headache, but less and less important as systems standardize more on internal GMT clocks.  It may be time to just drop that hour as having been a bad idea in the first place, but I'm pretty sure that's why at least one hour is there.

It's probably worth adding another 15m or so for people who just have their clocks set wrong.  But that gets us 75 minutes, not 120.  Why the extra 45?

Honestly?  

I think instead of arguing about figuring out which ones are scams, it would be a better plan to make a list with a fixed number of places -- say, 20 -- and put coins onto it if and only if they apparently AREN'T scams, and also show some outstanding combination of development, innovation and/or community support/activity, and no signs of known security problems.

Admit a new alt to the list only when one of the ones currently on the list is delisted due to getting hacked committing a scam, or being abandoned by its development team.

And then set out to burn every nonlisted altcoin to the ground, preferably so fast their promoters never even get a chance to pump let alone dump.

Litecoin makes the list even with no innovative feature except Scrypt mining, partly because it *introduced* scrypt mining and partly because the community (and market cap) is huge and active, it has a dev team that's responsive, etc.

Dogecoin makes the list, even though the coin itself shows no innovation AT ALL.  The "work" in Doge is by the community, not the dev.  It has scads of tipbots, wallets, blockchain explorer, good website,  active reasonably-moderated independent forums, a longstanding active reddit, good support, etc. and those things represent real work that a real community has done. Also, it happens to have the third-largest market cap after Litecoin's second.  But the market cap is still so small as to be nearly irrelevant by comparison to the combined market cap of cryptocurrencies.  It's a drop in the bucket compared to Litecoin, and Litecoin is a drop in the bucket compared to Bitcoin.  There is no reason to even consider market cap as a criterion for any coins smaller than Doge.

Darkcoin makes the list.  Darksend is an interesting new innovation, the dev is responsible and active, he's been fixing security problems instead of denying their existence and getting huffy at the people who pointed them out.  He hasn't promised a damn thing he hasn't delivered on, and the community is both active and supportive and, like the Doge community has developed some additional tools.  

Myriadcoin makes the list.  Their multi-algorithm mining appears to be a good idea, possibly a defense against burst mining and other scummy chain raping tactics.  Of course, also a possible security problem but if so the method of exploiting it hasn't been discovered yet and at least somebody's making an effort to solve a real problem.

Namecoin definitely makes the list; using a blockchain to create a lasting public record of domain registrations is a good idea, it's useful, and it's been around long enough for a scam to have revealed itself by now.

BitMessage makes the list; using a blockchain to provide secure email (and make spamming it expensive) is brilliant.  I just wish it had enough uptake to be more useful.

I can't decide about Peercoin.  Its proof-of-stake mining is an interesting idea for innovation and it has active support/community.  It has good support and has been around long enough for people to be pretty sure it isn't a deliberate scam.  The problem is that I'm not entirely convinced that their proof-of-stake implementation isn't vulnerable to an attacker using stake to support both sides of a fork.  If an exploit can be demonstrated, then they need to fix it or stop existing immediately.  If not, they make the list.


So, off the top of my head, I count seven.  Thirteen more places available on the list, who gets 'em?  

Of course there was no need to wait to start on AUR... We'll see what BCX comes up with on his fork of the attack while someone keeps the main chain very very slow to give him time to work.  

Heh. You're right that hashes are a uniform distribution, which makes it spectacularly simple to do this trick. 

Coin age destroyed is a Poisson distribution multiplied by total money supply -- which is different but if you normalize by dividing out the money supply (conveniently, meaning divide by block height) you can similar statistical tricks using different formulas.  There are at least two perturbing factors though, which are both disturbances to the pattern and sources of interesting information. 

First, the money supply itself is actually less than proportional to block height, depending on the rate at which bitcoins get lost.   The "coin age destroyed" graph, normalized by the theoretical money supply, would have an overall downward slope that would reveal approximately the rate per year at which bitcoins vanish due to lost keys (or just really persistent hoarders...).

Also the distributions would get narrower as the velocity of bitcoins increase, so the variance of the Poisson distribution would increase or decrease depending on the health of the bitcoin economy as of a particular period. And that would be another interesting thing to study.

That was kinda the point.  Transactions becoming invalid due to double spends does not indicate fraudulent or gravely mistaken -- it just indicates a protocol move.  Transactions becoming invalid due to timeout are no more nor less than the same kind of protocol move. 

If anything, it would make it more defensible to consider double spends to be fraudulent or gravely mistaken because it would give people another, cleaner, more reliable option to accomplish the same kind of move in most cases.

The advantage is that it would eliminate an attack on protocol.  With cancellation via double spend somebody can try to prevent cancellation by forcing the potential canceller offline (via a DDoS if they're technical, or via lineman's pliers if they're old-school)  until the transaction he might need to cancel becomes valid and confirms.  If you can build an expiry time into the transaction in the first place, you don't get to confirm that transaction after the time, whether or not you can keep the other protocol participant offline.

I could sort of see it as everybody wants to quickly reject any chain that everybody else is also rejecting, and having your software taking the same poison pill that's there for everybody will drop that chain like a hot rock.  You get onto the "right" chain faster that way, and if you're a miner you waste less mining effort. 

But as I said, it doesn't matter.  That output could never be "spent," not really.  Every time such a tx were broadcast, it would guarantee that the chain would continue from the next mined block that *failed* to include it.  Miners aware of this simply would never include it in a block.  Miners who weren't aware of it would issue an orphan block, figure out what went wrong, and then adjust their software to never include it again. 

And the further problem is that we need to absolutely trust the guy with the key to that txout.