Clearly the children of the current generation will mine fewer bitcoins then their parents. That's not even up for debate. 35.5% of all bitcoins have already been mined. By December 9th of next year 50% of all bitcoins will have been mined.

Therefore, "The biggest indicator for success in a Bitcoin economy is not a level of merit or hard work, but the amount of bitcoin wealth inherited from family members", says Red, a forum troll at bitcointalk.org.

Thanks!

I'm sure this is lame and off-topic. But why do artist paint on actual canvas? As opposed to any of the other many substrates commonly available? Plastic, wood, metal, cardboard, sheetrock, etc. Just a stupid question, but I don't know many artists to ask.

We went through this about a year and a half a go. There is a whole long thread.

The short answer is: as long as there are stable or inflating prices of goods vs bitcoins, setting up a bitcoin fractional reserve bank is trivial. However, if goods prices begin deflating vs bitcoins lending simply becomes to risky for too little potential profit.

In a deflationary situation, people tend to hoard bitcoins expecting to get "zero risk" interest. Any lender has to charge substantially more in interest than risk free benefit of hoarding. In inflationary situations, hoarding costs goods value over time. People with excess bitcoins are encouraged to lend for low interest, to make up for the natural loss inflation would cause them.
 

5) Decide how to reconcile multi-interval chain forks

This seems like a hard problem but it really isn't. If two forks come from a common chain, and there was an unavoidable network partition, then none of the transactions should overlap. Even if there is partial over lap, once you remove duplicates all transactions should confirm in either order. So, given the two 4 block chain forks that share a common block X:

X, A, B, C
X, D, E, F

Dropping duplicate transactions means the two concatenations below are identical.

X, A, B, C, D, E, F
X, D, E, F, A, B, C

If there are two different transactions trying to consume the same out-points then you have an intentional double spend. This should be flagged for everyone to see and all the referenced out-points should be locked.

The only issue comes from what to do with mining transactions on long forks where transactions from both forks can't be honored. In that case you have to decide which is the major fork and which is the minor fork. The minor fork's transactions get concatenated to the major fork. Decisions like this have to be considered based on the intentions of each forked party. As such they should be human decisions.

However they can be easily automated by pre-negotiating and publishing consensus rules listing well known (non-anonymous) peers. Long forks result from a long term partitioning of the GEM network. The fork most "visible" to the pre-negotiated peers becomes the major fork.

This partitioning could have been accidental (benign) or deliberate (malicious). If it was an accidental partitioning, everyone on the minor fork would know about the partitioning as soon as they stopped receiving announcements. At that point they would know, under published rules, when their mining would be rejected. That allows them to stop appropriately and to begin again once connectivity is restored.

If the partitioning was deliberate, the perpetrators knew in advance their ploy would be rejected. Unless, they had the collaboration of a majority under the pre-negotiated rules. But in that case, the other fork would have noticed the collaborators leave. It would then know in advance it was the minor fork.

If collaborators appear on both branches, then there is clearly a malicious attack in progress. Otherwise, the network would never have appeared partitioned. It is in cases like these, that public disclosure, revoking of trust, and renegotiated rules become warranted.

Third Order (Social) Dynamics

Systemwide, Bitcoin and GEM have to do the same six things:

0) Broadcast/receive transactions to/from all peers
1) Calculate how many new coins to give out each 10 minute period
2) Decide who to give those new coins to
3) Validate transactions & build new transaction blocks
4) Reach block consensus among all peers on 10 minute intervals
5) Decide how to reconcile multi-interval chain forks

GEM does the (0) identically to Bitcoin, so I won't be discussing it. GEM does, however, reassign some of the latter five responsibilities.

Originally, Bitcoin did all five of these using a single transaction block proof-of-work process. However, pooled mining refactored (1, 2). Mining rewards are detached from transaction processing responsibilities. With pooled mining, the pool operator becomes the actual "Bitcoin "peer". It receives transactions, validates them and builds the blocks (3, 4, 5). The miners themselves avoid these responsibilities and concentrate on hashing (2). This makes pool miners peers among themselves, but not true peers of those who process and validate transactions.

GEM emulates pools in this regard. It treats mining (1, 2) as one problem, and transaction processing (3, 4, 5) as a separate problem.

Bitcoin relies on an algorithm to decide how many coins (1) per block. It then used the proof-of-work as a system wide weighted random number generator (2) to decide who gets them. The combined process is seen as a reward for providing transactional stability.

GEM solves those two problems behaviorally. It lets anyone mine when they see profit to do so. This solves (1 & 2). However, like pooled miners, GEM miners are not required to simultaneously mine and process transactions. Mining rewards answering the "how many new GEMs?" question. It does NOT reward securing transactions.

Securing transactions is assigned to those with a self-interest in secure transactions. This generally means merchants, exchanges, and GEM transaction service providers. These folks profit from GEM clients buying and selling actual goods worth real dollars. Their profit depends on their client's unwavering trust in the GEM system. Clients can go elsewhere. They are never required to trust anyone. Client trust has to be earned.

GEM miners, however, are in a different class than clients. Miners are *required* to trust the system. But, only for a very short period. GEM miners mine only when there is short term gain to be had. They must immediately trade their mined GEMs for someone else's (dollars/goods) before the stabilizing price evaporates their ROI. When there is no profit to be had, miners lose interest. These are not the people who should be trusted with transactional stability.

So who (3) validates transactions? Anyone who wants to be a "full peer" can receive all broadcast transactions, validate them, and build a transaction block every 10 minutes. This activity is NOT rewarded in GEMs. This is done deliberately to minimize the breath of transaction broadcasts. If you care about transactional security/stability you are welcome to join in. You just have to pay your own bandwidth bills.

How do you (4) reach consensus? Easy. You throw dice just like Bitcoin does. Every full peer creates their own block on 10 minute intervals. Then they broadcast the hash of their block and a randomness dependent "fitness function" to the other full peers. Everyone selects the block with the best "fitness", downloads it, revalidates it, then broadcasts an "announcement" transaction to the world.

WTF is a "fitness function". The best example is the bitcoin proof-of-work test condition. The block+nonce must hash to a value less than the target value. In the above example, the "fittest" block could be the one with the lowest value. Or it could be the one with the shorted Hamming distance to the previous block. It really doesn't matter what function you choose. As long as the block creator can't manipulate it trivially.

The function just serves to get everyone to the same starting place. If it turns out the fittest block was created by someone nobody trusts, they can choose the next fittest. Anyone can pick any block, announce their intentions and see who follows them. If nobody does, they can switch to choice most popular among the circle they trust. If nobody trusts their circle, that is no fault but their own. GEM can't make people like you!

The goal is for the block chain and announcements to notify every peer and client immediately if something is going wonkey. If 20 of your trusted peers announced in your previous block, and only 2 in your most recent, you are mining or transacting on a fork or stale branch. Full peers should know this within a few seconds of each 10 minute interval. Miners can be sure of the consensus by pinging a few of their trusted exchanges.

I don't think I am giving anyone outsized power. No one can force anyone to change to a particular new client. No one can force anyone to trust anyone else *blindly*. I think those are good principles. SolidCoin implemented a trust model where everyone is forced to trust one known guy, nine unknown guys, and anyone who might get rich. That seems silly.

In your example, say EvilCo bought off all the programmers and one or two exchanges. Now if they tried to do malicious things, all the evidence is public. The other non-malicious humans could just decide not to trust them and continue on. Trust always remains a human decision.

If that forks the chain, then presumably the malicious humans are on one fork and the non-malicious are on the other fork. How you feel about that is really a function of who comes with you to your fork. If you are on the fork with 99% of people, you win. If you are on the 1% fork, you lose. The great mass of humans retain all the power. There is simply nothing EvilCo can do to "muscle" them around. EvilCo has to "market" them around. EvilCo can't even divide the system 50/50 and have both forks continue. That's an unstable state. It's an all or nothing game.



I'm not attempting to hack anything on to bitcoin. Bitcoin is what it is. I'm just trying to use shared understanding to keep discussion of the interesting bits on track. So far, so good!

I'm not sure what your beef is with the monetary model. It's exactly the same as EnCoin's. I guess you are saying you don't like the in-points transaction out-point structure in the blocks and think balances would be better. That is not part of the discussion I'm trying to have.

Most of your logic about bitcoin not being able to scale is sound. However, it was never meant to scale in the way you say it can't. Peer to peer in bitcoin didn't mean that every client user must be a peer. Satoshi wrote from the beginning that competing transaction processing peers would evolve. Most people would just choose a peer and use bitcoin as a service.

I see that bitcoin is about halfway there now. Mining pools represent the first stage of transaction processing centralization. Eventually someone will re-factor the wallet file to remove the private keys and put them on people's cell phones. Then new transactions will be created and signed offline. Then they'll be sent to their favorite merchant or transaction processor directly. When you think about bitcoin this way, there will be no scaling problems at all.

If I could submit secure GEM transaction from my phone. I'd have no problem using the system without running a peer at all. As long as I know merchants (and others) have a vested self-interest in keeping EVERYONE honest. AND I know these folks won't be blindly trusting ANYONE to remain honest. Then the system is in safe hands.

There should never be a 51% trust problem. That is a silly problem to try and invent. Trust is a human concept that can't be automated. System validity is easier though. If any single human peer working alone can't detect 100% of system wonkiness then you have design issues.

It's really easier than it seems. But it will take me longer to describe it than I have now. I'll write what I can now and clarify later.

The 51% problem is possible because bitcoin allows undetected alternative forks to be created in private. It then makes it possible for malicious parties to require everyone to switch to their "secret" fork because of a mathematical quirk in the rules.

You prevent this by deciding on transaction "confirmation" depth. Say three blocks deep. Then having each peer create a rolling block lock for those committed transactions. In this implementation, it is not possible to require any node to switch to any alternate fork if it requires changing a previously committed block.

What is missing from bitcoin is the ability for anyone to detect that a network partitioning (accidental fork) is currently in progress. What I want to add is the ability for peers on either fork to detect the absence of those transacting on an alternate fork. Making a personal decisions to stop mining or transacting on your current fork becomes much easier if you realize your "personally trusted" trading partners are absent from your current fork.

The block chain implementation is simple. Currently in bitcoin, only mining transactions are validated against the PREVIOUS block in the chain. Regular transactions can be copied and move from one fork to the other with zero knowledge of the account owner. This is what makes fork substitution difficult to detect, except for those who lost the mining transaction in the discarded blocks.

I propose that GEM validate every new transaction against a particular "currently known" block in the chain. That allows any merchant to create an announcement transaction that says, I'm currently trading on this fork. I does this by simply transferring 1 BTC from it's "well known address" to itself.

So if you are mining on a chain and you wish to sell you GEMs at Fred's exchange. But you don't see Fred's announcements in the previous three blocks of your chain. Well then, you are forked, and you should consider whether to continue or stop mining. Perhaps Fred is forked or perhaps totally offline. This is easy to detect if your chain has lots of announcements from other major know merchants. Certainly, it is a good time to check Fred's website or send an email. The point is, you are informed something funny is separating you from your other trusted peers.

More later

It doesn't require source code. It is quite obvious what he did. In fact thwarting the 51% attack is quite trivial in a trusted environment. All CoinHunter really had to implement was, "In cases of chain forking, trust the fork my machine is using." Period. It is that simple if you are willing to trust CoinHunter.

The only thing that makes the solidcoin solution wacky is that he didn't say that. Instead he said, "Trust me, and trust any of the nine anonymous individuals whose names I'm withholding from you, and trust anyone who amasses one million solid coins no matter the mechanism they use to acquire them.

Basically he is saying, CoinHunter's friendship or $17,100 buys the mandatory trust of every solidcoin user. Even when those trusted parties remain completely anonymous. Personally I find that appalling and the notion of "anonymous trust" an oxymoron.

Well I have to admit I didn't really try scaling to 100 trillion GEMs. But I did plan on keeping the block chain. If the whole system can scale to handle the transactions a 100 trillion GEM economy needs, I can scale it to handle the additional mining.

Generation could either be implemented similarly to bitcoin but with variable interval blocks as you suggest. Or alternately, GEM mining could be encapsulated as individual transactions. Multiple mining transactions would be placed in each fixed interval block just as is done with other transactions. Both ways of course beg the question of how the system would deal with chain forking and reconciliation.

I'm proposing a dynamic mining economy. One where inflationary periods might bring most mining to a standstill. One where deflation will cause miners to come out of the woodwork. And one where in stable periods, the most efficient will tend to drive out the fastest miners.

In GEM The fork with the *most* hashing is not necessarily the preferred one. Therefore bitcoin fork reconciliation rules cannot apply. If they did, in inflationary periods, most any idle mining pool could collaborate to grab 75% CPU. They could then rewrite the chain and double spend at will.

I have a solution of course. I was saving that for the next section though. It uses rolling block locks and a trivialized version of EnCoin's TrustNet mechanism.

About a year ago, I guy linked to his libraries for doing just this. It was aimed at anonymous banking relationships. Not so much coins, but like bearer bonds and things like that. I recently saw it linked but I can't find it.


Edit:

Search "open transactions" by user "fellowtraveler"

I think this was his first thread, but there are lots of others.
https://bitcointalk.org/index.php?topic=847.0

There is really no upward bound on how many blocks can be generated in a given period of time. You just have to add more miners.


Since they all mine non-competitively, 10% more miners (meaning 10% increase in MHash/s) per year would match your growth rate. However, since we already compensated for increasing (MHash/j) That would mean increasing electrical consumption 10% per year as well.


Wow, that is a vote of confidence! But still, it is just a matter of adding 10% more miners and 10% more electricity.

I'm not saying this concept isn't electrically STUPID! (In fact sometimes it is hard to type this stuff with a straight face.) It just seems like it could be plausible.

-----

But your statement points out a really important dynamic. I put in the non-linear "Deflation Spending Subsidy" to help in cases like this. I probably should have given this specific example more thought.

Let's consider two different transaction fee rates.

10%: At this rate, miners would have to mine 10% of the existing GEM economy just to keep up. As they mined more than that, it would be supplemented by the subsidy.

So in my hand wavy example, if they mined (transaction fee * 2) GEMs, it would result in 3 GEMs for the price of two. Distributed 2 to 1, between miners and spenders. So you wouldn't really need to mine a full 20% of the economy to get a 10% net increase of GEMs. If they mined (transaction fee * 3) GEMs, maybe it results 6 GEMs for the price of 3. (3 to miners and 3 to spenders.) [Waving Hands]

Reducing the transaction fee,

5%: At this rate, miners would only have to mine 5% of the existing GEM economy to break even. After that the subsidy kicks in. (transaction fee * 2) mining results in 10% GEM growth. So mining 10% of the economy would get you 10% growth.

So the non-linearity really depends on where we set the transaction fees. (2x at 10%) fee = (4x at 5%) fee with a much higher subsidy. (12 for 4)? [Waving Hand some more]

Anyway, I think I used the wrong non-linear subsidy function in the example. I want it to be able to grow fast, but be tied directly to mining effort. And something not too exponential so it doesn't blow sky high if miners over compensate while trying to make a fast buck.

----

Do you think an appropriate function exists?

Etlase2 had suggested a fixed fee to exert downward pressure on the EnCoin supply. He used that to rationalize minters needing to mint continuously to replace fee coins. Basically GEM is a variant on his ideas. Since I began with the fixed fee and constant electricity mining. Fees and mined GEMs were the two easiest quantities to measure.

If (total mined/trading fees) = 1, then the total GEMs mined equals the total GEMs destroyed. So the number of GEMs in existence remains exactly the same. Since nothing really changes monetarily, I defined that as "just right" (stable).

Rationally speaking, if the number of GEMs in existence is exactly right for the external economy, there is no reason to mine or to take a transaction fee. Everyone should just be left alone to trade among themselves.

Originally, I proposed a different concept where in the stable state, all fees were refunded back to the original parties. In the stable state of that version, miners didn't have to mine, and weren't rewarded for mining. However, that represents a bigger deviation from bitcoin principles and I don't want to take needless tangents.



I think the ratio = 1 definition of stable is pretty sound conceptually. Defining the fee percentage is going to require some serious arbitrary rationalization!


Yes that is correct. At least in respect to the miners. They will always receive the same GEMs for each successful mining proof-of-work.

The non-linear "Deflation Spending Subsidy" however, tends to break all the rules. It is intended to encourage GEM spending and discourage GEM hoarding in moments of deflated values. This subsidy come out-of-thin-air as a result of mining. However, it is paid to those with spending transactions in the previous block, NOT to the miners.

This is the only time I break the 1 GEM = X Joules rule. But it seems fair, since the transaction fee destroys GEMs without refunding Joules at all. Etlase2 proposed banking all transaction fees into a sort of "Deflation Spending Subsidy" savings account. That holds everything to the 1 GEM = X Joules rule should ideological purity becomes a goal.

Does Minting Model = Logarithmic mean there is a fixed maximum number of coins. But these are mined using logarithmically diminishing rates? (I'm not an expert at all the alt-chains).

If so, you might want to include the maximum number of coins those Logarithmic systems will approach.
i.e. 21,000,000 for bitcoin.

Also perhaps how far down the curve each Logarithmic system is. Gives a feel for early adopter status.
i.e. bitcoin is projected to reach 50% distributed on (X date).

I edited the above couple of posts for clarity. Just-in-case there are people who don't free like talking about solidcoin.

I was wonder about this too. I asked CH in an earlier post but I think that section of the post got derailed.

I seems implausible that they would go to all the trouble of adding in interleaving blocks (What I called a vector clock) without realizing they could be used in fork detection. Basically this would supplement or override "the longest chain" rule in cases where a long fork appears out of the blue. Otherwise, anyone who could isolate a single trusted peer could run wild.

However, I didn't think it was plausible to invent ten 1.2 MSC accounts to make interleave feature work either.

I guess I'm just cynical. I think the only thing that makes rich people different from me is...

...they have more money.

No, I mean simpler than that. You have a rule that says, "only accounts with one million plus SC, can sign these even blocks."
You might just as well said, only humans with real name validated verisign certificates could sign. It's the non-anonymity that makes the trust. Not the money.


Which makes this a very ironic statement. Since at this very moment, people are camping in the streets protesting the anonymous rich! I dare you to go down to wall street and tell everyone, "Those with the most money should be in charge of your security!"

I have to admit I thought the trusted nodes as vector clock idea was clever.
Did you build in any additional logic to help resolve chain forking due to network partitioning?


I really have to disagree here though. You system would have been trivial to implement without the million SC accounts. All you need is a dozen people to say, "Hi, I'm Fred. I'm watching the system. If something goes wrong. Sue me at this address." That is basically what you did by giving out million plus SC accounts. Except you're not telling anyone who the account holders are. So if they collaboratively misbehave, there is no one to sue.

Good to know. But the only way to build real trust is through non-anonymity.
Anonymous trust is a bit of an oxymoron.