Topic: MC2: A cryptocurrency based on a hybrid PoW/PoS system - page 40. (Read 195184 times)

This goal is provably impossible in itself. The CPU/GPU is an ASIC. The best you can hope for is that your hash schedule explores ALL the features of the CPU at MAXIMUM efficiency, making an identical CPU the only possible ASIC design. All the features: FPU, MMX/SSE2, memory segmentation and virtualization, all of the cache, branch predictors, debug and JTAG registers and the myriad other tiny atavisms that make a modern CPU work.

If you don't use them all with maximum efficiency, then a stripped down CPU or GPU optimized for the specific features you use will have a better performance at the same density/power/price point. In practice it's unlikely you hit even less than one order of magnitude gap between a software version on a generic CPU and custom software on a custom ASIC.

So I'm not sure I understand the appeal of ASIC resistance. The most you can achieve is to make the ASIC design very expensive. This will hold ASICs at bay for a few years, but if the currency is successful and the mining market is large then an ASIC will eventually be designed. When someone does it, it's game over, he controls the mining market. A huge entry barrier will dissuade other competitors to do the same because the potential benefit is lower.

If you absolutely must do proof of work, for example to control the currency price like in Eltase's design, then a simple scheme for which ASICs are easy to make or already exists (like bitcoin PoW) is much better from an economic standpoint.

Because it's bad in terms of throughput in a software implementation doesn't necessarily mean that there will be no advantage from using an ASIC.  In fact, I would be surprised if fast syndrome based hashes or chaotic hashes weren't still much faster on an FPGA/ASIC, as at the end of the day it likely just boils down to yet more logical gates being used.  I'm leaning much more towards algorithms that have had more extensive cryptanalysis done on them so that I can ensure the blockchain is secure rather than applying a hash that requires a bloat of logic gates (which may or may not be reducible; a lot of these implementations are probably just straight C++).

In fact, an FSB hash has already been done on FPGA: http://csg.csail.mit.edu/6.375/6_375_2009_www/projects/group2_report.pdf


As I said before, with optimization it's like you can get these chaotic based hashes to fit into an FPGA too.

The Great Depression was not caused by "not enough money" moving around. The Great Depression was seeded with the Federal Reserve's inflation policy and ignited by the policies of the New Deal. If you want to learn what really happened, read David Stockman's "The Great Deformation" and http://wiki.mises.org/wiki/Great_Depression.

Deflation encourages saving and investment, whereas inflation encourages consumption. If a currency with a relatively fixed supply (given that hybrid PoS / PoW currencies need to have minimal inflation in order to work) based on the free market appreciates by 400% annually from a beginning market capitalization of a few million current US dollars to a market capitalization of a fraction of the total market capitalization of all fiat currencies and of gold, or that is to something like 20 trillion current US dollars, then the holder of such a currency is called a saver, and such a saver will also want to invest part of his or her profit while the currency is appreciating, and a significant percentage of his or her total profit once the currency has reached its true market capitalization.

Therefore, the saver is also called an "investor". This is something that people who believe in Keynesianism and Monetarism don't understand, that savers are investors.

It is really important for the developers of Netcoin and its initial users to understand the economics behind currencies well, otherwise they are going to make severe mistakes in Netcoin's development.

To learn economics, read http://library.mises.org/books/Gene%20Callahan/Economics%20for%20Real%20People.pdf, David Stockman's "The Great Deformation", and https://mises.org/journals/qjae/pdf/qjae14_3_3.pdf.

The only flaws in Austrian economics are Mises' Regression Theorem and the reliance on anarcho-capitalism.


Your argument is based on the position that there is psychological benefit to a currency's supply being limited so that one whole number unit is worth hundreds if not millions of US dollars.

This is a flawed argument as there is marginal, if any, psychological benefit. The average user is not going to care if one whole number unit of his currency is worth 1 current US dollar or 100,000 current US dollars, as he or she is going to simply hold 100,000 times the amount of the former if the latter's scenario is the case.

A currency's worth is derived from its supply being relatively stable, and durable, portable, and divisible.

The divisible part is where current cryptocurrencies are flawed. If Bitcoin were to reach a 20 trillion current US dollar market capitalization, its smallest unit would still be worth a significant amount of current US dollars, not making it satisfy the divisibility property.

I believe that the supply for the perfect cryptocurrency needs to be 10 trillion units, divisible to 8 decimal places. This would allow its smallest unit to be usable to round off the smallest transactions even if market capitalization for the currency was greater than 70 trillion current US dollars.

Remember that a significant portion of the world still needs to industrialize, and that further productivity gains are still possible, from making free markets actually work to technology improvements. This increases the total market capitalization of all possible currencies from 70 trillion current US dollars.


Taco, what do you think of this chaotic hash? ASICs and FPGAs might be defeatable, even if the problem is that the efficiency of energy consumption takes a hit.

Okay.  Such an attack when you manipulate stake difficulty seems pretty unlikely.  The following reasons are why:
1) The stake difficulty adjusts every 4.5 days and is based on the linear weighted average of the previous four 4.5 day periods (no per-block adjustments ever occur).
2) You need to wait 29 days after submitting the ticket for it to mature before you even have the chance to spend it.

This means that an attack like this will involve mining a hidden chain for at least one month, probably closer to two depending on your hash power.

But the way to mitigate the attack is similar to what you described (I'm not sure why you described it as the square root of the difficulties?), but just assign a blockchain score of:
block=1{summation}block=n of  (PoW Difficulty in Block 1 * (PoS Difficulty in Block 1)^-1) + ... + (PoW Difficulty in Block n * (PoS Difficulty in Block n)^-1)
where n is the current block in the chain.  Now it should be difficult for the attacker to manipulate the chain, because his chain should have a lower score if he tried to lower either the PoW or PoS difficulty.  Again, this attack is not an easy one and requires you to mine for a long time.

Let's say an attacker has 51% PoW and 10% PoS.  The attacker can generate more PoW blocks in his chain, but he can never validate the majority of them and his cumulative difficulty score will certainly be lower than the main chain, making a double spend impossible.

Let's say an attacker has 10% PoW and 51% PoS.  The attacker can validate or invalidate any block they choose, but the attacker's likelihood of a successful double spending is very low (the same as with bitcoin with 10% of the network hash rate).

The only time you can get absolute certainty that a double spend can succeed is with 51% PoW and 51% PoS.  But you suspect there is a flaw in this logic, and now I'm really worried and losing sleep over it. X)  I will try to come up with a simulation program for this so we can play with it and see what the longest valid fork you can make is.

I see.  Let me sleep on it and I'll think further about it.

What about the Sibyl attack where you make so many peers that you can isolate nodes from communications temporarily? Doesn't matter what the entire network actually did. It just matters what you saw the network do. Feed some clients 5 secret sauce blocks and they are borked. Making temporary attacks like this permanent is not good.

I see.  You need a way to prevent such a fork from happening.  Why not just not disallow reorgs for any length of valid blocks greater than five?  There should be an easy way to detect this attack and reject it from ever entering the network.  I understand that you need to have reorgs to prevent the chain from forking, but it seems like a 12 minute string of blocks seen by no one else on the network is really unlikely.

Well, in order for stake difficulty to go down on the other chain you need to use submit less stake Tx per block.  As the stake Tx go down, stake difficulty goes up (as it's a fraction of the supply needed to claim a stake submission Tx).  We can rate the trust in the block as the stake submissions * (1/stake difficulty) and select the chain based on this stake trust value too, which will likely be larger after summation among all the blocks up to where the fork emerged.  This may be untrue if few people in the network are submitting stake at the time and the malicious stakeholder has a lot.

If you fix reorgs to a certain length and incorporate the above it may be very difficult to perform a double spend, as stake difficulty only decreases once every 4.5 days.

Okay.  This behaviour can probably be simulated too, although it's a little more complicated, and I'm tired.  I'll think about it more later.

Right, sorry I got confused. Good choice.


I'm not understanding you here. You will always have 51% attacks. Attacks will involve a weighted combination of PoW and PoS that exceeds 51%.
Regardless of the resource combination used, the attacker will be able to 1) select which blocks go through the network, 2) double spend, AND 3) prevent all txns.
This is true in bitcoin. I'm near certain it will be true for your coin as well.

There's an important omission in your whitepaper. You need a single-valued function that compares proof across blockchains.
 
In Bitcoin PoW, the single-valued function is the summation of difficulty targets for each block in the blockchain. If you copy this directly, you run into trouble.

Block Proof = PoW Difficulty
Chain Proof = Summation of Block Proof

A 51% PoW attacker can patiently mine in secret. His PoS difficulty will slowly adjust downwards. Eventually, his PoS difficulty will go low enough that he is able to overtake the main chain with negligible stake. PoS becomes a sham and only PoW matters.

You are using two difficulties. PoW difficulty, PoS difficulty. You need to consider two proof relevant numbers for each block.
To do this, define a single-valued function that maps the (PoW difficulty, PoS difficulty) pair into overall block difficulty.
The two difficulties make analysis of 51% attacks complicated. Resource requirements most likely depend on attack duration. That's a bit messy, but I don't think it is a problem.

My suggested single-valued function is a geometric average.
Block Proof = (PoW Difficulty)^0.5 * (PoS Difficulty)^ 0.5
Chain Proof = Summation of Block Proof = (PoW Difficulty in Block 1)^0.5 * (PoS Difficulty in Block 1)^ 0.5 + (PoW Difficulty in Block 2)^0.5 * (PoS Difficulty in Block 2)^ 0.5 + ...

Ideally, there would be some clever function that keeps the long-run and short-run resource requirements identical. Not sure what that clever function would be. The above will probably work though.

Another option would be to ditch PoS difficulty. You could either fix the ticket price permanently and allow the number of lottery tickets issued to change over time.
Or you could just give every satoshi a ticket by default. (e.g. define an easily derived ordering of all extant satoshis in the ledger, use the PoW hash to draw a random number, map the random number to the satoshi, the satoshi owner is the lottery winner). Every new block causes the ledger to update. Ledger needs to be ordered in exactly the same way for everyone.

I'm just glad that there is actually some innovation coming out of this. I can't say I have a grudge against any coin in particular really, but I definitely do appreciate when they aren't just a 100% copy of an existing coin renamed and marketed to people who didn't get in early enough.

Also +1 for the method at which you are releasing. Going public weeks or months before the release of a client so not a small group of people getting in early. Not to mention that people can find flaws that can be fixed before it is released.

You're asking someone head-deep in bitcoinomics making arguments that are based around bitcoin-only definitions of inflation and deflation and relating currency to stocks/businesses etc. to make reasonable arguments. It isn't going to happen. Any coin that adopts yet-another-stupid-deflationary scheme is going to lose out to one that drops this nonsense once and for all. The scheme you're probably looking for is in my signature.

This is the beauty of BBQcoin, Tenebrix, Fairbrix, CoiLedCoin, GRouPcoin, GeistGeld and so on, the EASY coins that are NOT regarded as profitable. If they were regarded as profitable, they would be raped. Ordinary people using their CPU (BBQ, TBX, FBX) or their single GPU (p2pool bitcoin, merging the least-difficult of the merge-able coins) have been and still as of this moment continue to be able to quietly pick up a steady stream of such coins over the course of a year or more.

BBQcoin of course is no longer in that category, as it has finally moved on from that early adopter phase and started to reward its early adopters.

But the others listed are still there, still being ridiculed and ignored by Old Money, still quietly feeding the dreams of the common cryptocitizen.

Oh and by the way, GRouPcoin keeps on minting 50 coins per block forever, so there you go, your inflatacoin is already out there, already adopted by early adopters, already offering the common people lots and lots and lots of time to get in on it while it is still in the early adopter phase...

-MarkM-

Ok, so perhaps it could be stated that MC2 is 'double the security of Bitcoin' ( that should set the forums alight  )

The other point I can extract from your post is that it is more 'large organisation / government tamper resistant' ( need to rephrase that so it is a snappier line perhaps )

So,

Double the security
Faster payments
Lighter client footprint ( less disk space )
Increased resistance to attack from large powers

Great, when can I start using it  

In the best case (that the majority of both proof of stake and proof of work miners are honest), it's about twice as secure I would say.  Hence, the time for a secure confirmation should be one half that of Bitcoin, in that ideal case.  If a network attacker emerges to the scene, the case in Bitcoin is that there is no secure amount of confirmations.  In the case of MC2, no blocks will go through the network (>50% PoW) or only blocks that the attacker selects will go through the network (>50% PoS).  Only in the case of >50% PoW and >50% PoS can the attacker double spend.

One of the PoS arguments is that with PoW, the government can easily attack it by getting enough hashing power.  With MC2, by this attack vector you can only temporarily stop transactions from going through, and then, if this becomes a problem, you can force PoW miners to also have some PoS when minting a block.  This is a pretty unlikely case, though.  But, in any case, it should be more secure than Bitcoin from this type of attack.  But what PoS people like to ignore is that the government can also destroy these chains just by buying a lot of it if they wanted to.  Right now, if Bitcoin were PoS the cost to destroy it would only be about $1 billion USD (actually, way less if you write an algorithm to try to buy at the VWAP and bought progressively over a couple of years).  That's not really all that much money to a major world government.

MC2 makes the assumption that it's no more likely for persons with stake to be any more honest than PoW miners.

Coins are already bought with straight coins instead of coin time...  You submit the coins to the chain and then they wait for the 29 days until maturity and are issued a ticket, but being able to purchase them has nothing to do with the age of the coins used to purchase them.  The 29 day lag phase is to help prevent manipulation of the tickets, which is another attack vector on the chain (if you can manipulate the block headers over this time period and before the time of the stake submission Tx, you can effectively select who the lottery winners are and which tickets are issued).  I like that there are absolutely no coins generated for 29 days, too.  But if you wanted to eliminate the lag phase, you could also use all previous odd blocks for ticket generation and even blocks for lottery generation, or whatever.  I'm not sure it's hugely advantageous to an attacker, as the window to claim the coins is so large (91 days).

To the question, you can transfer the tickets by just sending the private key used to purchase the stake Tx somewhere.  The risk would be that it becomes stolen along the way or by the pool itself, and the pool would risk having you steal the reward, so I'm not sure a pool would form by this means (seems pretty unlikely).  Rather, a stake pool would involve you sending a little of your coins their way, them using them to buy the stake ticket, then spending it to secure the blockchain and sending back the coins back to the user with interest at a certain time.  Large enough stake pools should be able to give daily interest, similar to PoW pools.  The risks will be for the pool operators to assess, as it's likely that people will try to hack them constantly, but if you transfer the tickets to effectively shielded and quiet network nodes, they should be difficult to find.

I think three points there that will catch the eye of the ordinary non-uber-technical user :

Improved security
Uses less disk space
Faster payment

Now, how much more secure is it, how can this be conveyed to the user in a daily life situation ?

For marketing I'd focus on those 3 things for the main big marketing push, ( plus any other innovations say on the wallet side, see my edit in OP ) and move the others to the 'small print' where people that are really interested and capable of understanding them will find them if/when they need to

Okay


If that's too technical:

Let me play devils advocate for the moment.

Can someone give me a short list of reasons ( bullet list ), why Joe-public will use this coin rather than the already established Bitcoin ?

The list needs to be free from techno jargon, so anyone can understand it.

If such a list can be produced, and it is convincing, then this coin stands a chance of success and perhaps grab a decent share of bitcoins 'market'

This is important, as such a list needs to be used aggressively in a strong marketing exercise if uptake of the coin by users and merchants is to occur. Otherwise this coin will just be another btce / Bter exchange toy, which will make some miners some BTC for a while.

Edit : and this shouldn't just be about the underlying features o
f the coin, think about peripheral things like the wallet, merchant / website interface etc.. What new innovations are there to pull me away from using / accepting bitcoin for my service, product, business ?

That's true.  I had considered this before (and had noted in the paper to be aware that this indicates a possible attack on the network), but it's probably best to just invalidate any block without a majority Yea vote.

I'll get back to your other post soon.

Sigh.  

Can you actually address ANY of the points that people are ACTUALLY bringing up? Strawmanning is uncool.

I forgot to respond to something.
Do not just ignore people who abstain. Abstaining should be equivalent to voting Nay.

You will never see a Nay vote in attack blocks. Double spenders mine in secret.

That means their blocks have missing votes, not Nay votes. To offer significant PoS protection you must treat Nay and abstain as equivalent for block validity purposes.