MC2: A cryptocurrency based on a hybrid PoW/PoS system

[twelph]

Also, some things have to be implemented before the launch.  It would be really hard to add security forks after the coin has been launched.

Thank's for clearing that up. I'm not a programmer

[wizzardTim]

Oh my, I feel something good is about to happen... 

[twelph]

Oh my, I feel something good is about to happen... 

I know. He should get the name finalized, release another whitepaper draft, and make a separate thread specifically asking for developers so this thing can get moving! I'm going to be giddy waiting the two weeks until he releases this on github.

[Joerii]

Count me in.

Have you considered starting a project on a crowd funding site like kickstarter ? With all the news around BTC at the moment I think you could get a large amount of funding rather easily.

[Impaler]

tacotime:  Perhaps a simpler way to utilize multiple hashs is to actually have multiple chains which are 'braided' together.  It would work like this, for each time-increment of the network in which we would normally find 1 block, instead one block of each type of hash is found.  This forms a set for blocks that are hashed together with simple md5 to created as seed value which servers as input for ALL the blocks of the next time increment.  Thus the whole 'braid' advances its individual sub-chains in parallel and in perfect synchronization as only one time-increment can be worked on at a time.  It also allows each sub-chain to maintain its own difficulty based solely on the like-hash blocks rather then on an average of them all.  

This would address what I see as a potential flaw in your model.  Because of the random mix of hash types and the widely different solving times involved it is very likely that a long string of hard hashes will slow the network speed significantly.  Conversely a few ASIC friendly hashes in a row result in a huge speed burst.  But with each hash having a separate difficulty being continually adjusted to meet the target time you get a more consistent total solving time and at the same time you put a sharp and consistent upper limit on each type of hardware's ability to control the network.   You may even tamp down the wild network-speed increases from new hardware too because total network solving time can now only increase at the growth rate of the slowest rising hash-rate.

Now all that sounds great but the really fun part is that the different sub-chains can do DIFFERENT WORK, and have DIFFERENT PROOF methods.  This allows the necessary flexibility to solve the old "fox, hen and bag of corn must be taken across river" situation we end up with when we start looking at allowing the user base to decide anything democratically.  We know that people have perverse incentives most of the time and will try to make decisions which benefit them at someone else expense.  But if they the voting 'right' is distributed differently we can expect different outcomes, thus as people have said Stake-holders are far less likely to desire inflation then are miners.  Braided chains allow you flexibility in deciding who get what authority rather then lumping everyone together and requiring each group to validate the whole chain as would be the case with the original one-chain methodology tt describes.

[Luckybit]

Count me in.

Have you considered starting a project on a crowd funding site like kickstarter ? With all the news around BTC at the moment I think you could get a large amount of funding rather easily.

Not a bad idea. You could perhaps give away Bitcoins to people who pledge a certain amount or perhaps give away some of these Memcoins.

[Michael_S]

Another thing that one may think about for a new coin design is how to be sustainable by avoiding indefinite long-term increase of block chain size:

Fundamentally, as long as a coin uses a pure "block chain" approach, the size can (and will) increase indefinitely as long as the coin exists, and thereby outpace any Moore's law kind of HW growth, which is finally bound by physical limits (size of atoms etc.)... so sooner or later any however big mining node would face problems providing the storage capacity for saving the complete transaction history.

I am wondering whether a concept could be designed to store the current "state" of the currency (state = "which address owns how many coins"), rather than the complete transaction history. The history could still be stored somewhere, optionally, but for sole operation of such a new crypto-currency, the "state" would be sufficient.

Just some rough calculations, using today's BTC as dimensioning basis (21e6*1e8 = 2.1e15 currency base units):

If a mining node wants to store the "state" of the network, how much storage capacity would it need?
--> In the worst case there are 2.1e15 addresses each holding exactly 1 base unit of the currency.
This is about "2100 Tera bits" * (A + B + C), with
A = "nb of bits per address",
B= "number of bits needed to express the balance",
C = "nb of bits needed for some meta data for the protocol and cryptography purposes".

In practice of course, the storage requirement would be a few orders of magnitude lower, so about a Terabyte of storage would probably be enough for all future.

So such a design would require memory well within feasible physical limits, sustainable forever, because a given max. storage limit would never be exceeded.

(Maybe a hybrid "state + incremental blockchain" approach is also possible...)

[BubbleBoy]

Any solution to the byzantine consensus problem with a hybrid PoW-PoW stake system that further introduces fault-tolerance and enhances network security with no real net increase in computation power should be a better solution, not a worse one (main tradeoff is chain bloat, but I'm sure people find this acceptable).  

I can understand the need for compromise but where in your paper is this tradeoff made explicit and it's security/efficiency improvement analyzed ? You simply assert that proof of stake is Good, and build from there. The same for the PPC paper, it's all hand-waving spiced with low level implementation details. Don't view it as an attack on you or your objectives, I am a fan of getting rid of wasteful hashing; however this is a very hard computer science problem (Byzantine consensus vs. the Sybil attack) and I expect a hairy analytical paper with all sort of funny symbols and equations, not implementation details.

It seems to me the cryptocurrency community needs more thinkers than doers. Not enough analysis goes into these bitcoin forks, and the results up to now are half baked and flaky.

 Yes, I'm adding more hash algorithms -- but there is no simple way to implement them all together with an ASIC or FPGA without using a massive number of logic units.  You're looking at maybe 35k gates with a scrypt ASIC while this would easily require 100k+ to hit all encryption algorithms.  

So what ? A modern FPGA can include over ten million gates (virtex 7). A large 22nm ASIC can contain hundreds of millions of simple gates. Indeed it's a bit more work to get the first device done (a fixed cost), but once you have the mask the marginal cost to multiply it is the same as a simple Bitcoin mask which uses a single type of hash. What you should be targeting for is that each chip cannot be much more efficient than a CPU, and scrypt, a password derivation technique, is NOT a proper primitive for this task, the same for you multi-hash scheme.

[iddo]

(2) The requirement of at least some coins (very large amounts as the chain matures) that are 90 days old in addition to 51% of the network hash rate.  The first addresses any potential failure of SHA2-256, while the second addresses double-spend attacks created by short forks of the chain.  In this way the hybrid PoW-PoS system is a better solution to the byzantine consensus problem as far as I can tell.

Your PoS idea is very similar to cunicula's ABAB system, that we discussed in the PoA thread (see https://bitcointalk.org/index.php?topic=102355.0 , last post about it is #129). We have abandoned the ABAB sort of systems both because they can be even less secure against double-spending attacks than pure-PoW, and because we've come up with a much better system (cunicula removed from the wiki his old protocol that ABAB is based on, and replaced it with a complicated variant of our best PoA protocol, the straightforward PoA variant is described in post #158 of the PoA thread).

You appear to have quite interesting ideas that are unrelated to PoS (though I haven't considered them carefully yet). Having PoS in a new cryptocoin also implies problems with stakeholders' incentives to participate versus fair initial coins distribution, not as much of a problem as ripple has with doing the initial coins distribution (because your protocol is mixed with PoW), but still. I advise you to either drop PoS and focus on your other ideas, or consider the implications of PoS more carefully by reading the PoA thread etc. It'd be a pity if it turns out that your ideas are useful, but your entire effort will fail just because the PoS component was unsound. I'm available for further discussion (also on freenode irc) if you'd like.

[chriswen]

Proof of Activity is different from Proof of Stake.  PPC PoS requires 30 days.  MC2 has proposed a 90 day wait before you can mine stake blocks.  90 days is quite significant.

[rezurect]

Newbie here, so sorry if this is stupid and not possible.

As a late adopter most people don't want to download the entire blockchain. A marker from where i can download might help.
Instead of downloading 4 gigs, i download only half that if u can put some marker in between.
OR maybe an optional more efficient blockchain storage mechanism ,which wouldnt end up 4 gigs in a few years.
I'm pretty sure it'll help adoption rates.

Away till 24. Dev work starts in 2 weeks.
I expect the competition is going to be with LTC. Hope u get the coin out before a LTC price explosion.Expecting a release soon.

Best of luck Tacotime

[Joerii]

Taco, any updates ?

[alex_fun]

Pos=hoarding often,


With fluctuating exchange rate and miners need to cover electricity costs how it can become avoid becoming another pump and dump? People simply jump in mine at day 1, then hoard, then via POS they get even more. 

[saigo]

( if this was already mentioned, apologies in advance )

I think the first coin to establish a system that goes some way to avoiding the need for an exchange will likely be very successful. I don't know how/if this could be coded into client wallets etc, but how about this idea :

I want to send $200 to Mr X, in exchange for a number of noXcoin ( or whatever the name of this imaginary new coin is ), I load my own client wallet with $200 ( let's worry about how I can do that in a while ), this creates a string like a bitcoin address, but prefixed with $, this sting is unique and becomes known on the network, using this string, I send the $200 over to mr X.

Mr X has a number if hours, lets say for now it's 2 hours, ( maybe this time period can be set by the initial sender, the 'guy that goes first' ), to send me my noXcoins, as soon as he does so, the trade is 'locked down' by the network and neither party can reverse the trade. If I do not get my coins inside the 2 hours, the trade gets cancelled, and my $200 get credited back to me by the network.

How do I get these $200 into my wallet? I guess that's the difficult part in this at least, I think something has to be  built into the design that will allow banks to join the network and offer the ability for people to send $,€,£ etc to their wallets, ( for a small fee I guess to give them the incentive ), right, this wouldn't work from day one, and we have to trust market forces to take place and the banks to jump on board with that one in putting their end of the system in place. Maybe there is another better solution to that ?

[Allaun]

How would you prevent someone from messing around with the democratic voting system? Would they be able to game it using multiple clients/computers/VMs?

There are ppl out there who have access to large blocks of ips. If i put my mind to it i can borrow /18 ranges of ips for a month or two. I have done it before and always have access to many /24s.

That will be rapidly obsolete in the future when IPv6 rollout is complete. Of course, then you can grab a billion ip address if you like.

[aaaxn]

Hi,

I would really like the idea of new coin that gets rid of constant arm race between miners, because this makes bitcoin really expensive system. It is fundamental problem, because it can make bitcoin non competitive transaction system. Centralized payment solutions benefit from economy of scale, while cost of running bitcoin network is proportional to bitcoin value and transaction volume.

Too bad your paper states that you are rely on exponential increases of hashing speed, which means your system will use as much energy as original bitcoin. Am I right?

I read your paper and it is quite complicated. Do we really need two types of blocks to implement PoS? I'd like to present much simpler mechanism.

Let's copy entire bitcoin algorithm and make one simple change. Instead of using same difficulty target for all miners let's have it dynamicaly reduced by amount of coin days destroyed in coinbase transaction.

Definitions:

base mdifficulty - difficulty calculated using bitcoin alorithm for current block
coin stake - amount of coin months destroyed in coinbase transaction

In bitcoin block is valid when its hash matches base difficulty. In my proposed system block is valid when it matches difficulty adjusted by coin stake.

modified difficulty = base_difficulty /  MAX(1, coin_stake)

So for example with base difficulty set as 1000 miner with no stake will have difficulty 1000
Miner with 2 coin months used in coinbase will have difficulty 500.

Of course difficulty adjustment equation can be modified to be less aggresive and/or define maximum difficulty reduction, but you get the idea. Do you see problems with this approach?

[rezurect]

Feathercoin gis getting 100Mh/s. Hope you get your coin out before a litecoin boom.

[Nathaniel B]

First, I just want to say that I applaud Tacotime's acknowledgement of how a coin should be released especially with all these silly copycat alt coins that provide nothing novel being spammed almost daily now. Litecoin has shown the advantages of alternative hashing algorithms, but I also concur that a more in depth look at optimizing a coin for GPU mining above all else is key. If GPU mining is able to be protected as the best way to mine a coin then this provides the best decentralization as gamers will always be a huge distribution of hashing power whereas ASICs and FPGAs will always be skewed towards a relatively few individuals/groups with significant capital (not that GPU mining farms are impossible just that even a few thousand GPU farms will pale in comparison to the gaming community).

Now, while just optimizing the hashing algorithm provides a useful trait for a new coin, I suggest that we take this opportunity and add a few additional key traits to the new coin to provide utility to the community well beyond any current cryptocurrency. In order of importance I suggest the following additional key features:

Distributed Exchange
Distributed exchange is perhaps the killer feature that everyone is talking about often with unrealistic expectations. Obviously we cannot solve the problem of converting fiat directly into cryptocurrency, but I believe we can provide a decentralized exchange mechanism that only relies on outside trusted parties for a final withdrawal or deposit of fiat. My suggestion has two main features. First, we incorporate the colored coins idea (https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1) to allow any outside party to create and sign particular coins as having some additional meaning (in the fiat use case that would be some amount of USD for instance). Second, we create a new type of transaction that posts an offer to the network to exchange some number of new(whatever our new currency is called)coins for a certain number of colored coins properly signed by an entity or set of entities or vice versa. Once the network sees offers that match, a transaction is recorded in the block chain that atomically transfers ownership to each party. (TODO optimize incentives for miners to match offers well through transaction fees etc.)

I would also like to see a way to exchange with other cryptocurrency directly, but this has many additional hurdles such as requiring all nodes or at least miners to keep other block chains in memory and possible denial of service attacks from people accepting offers and not sending the BTC or LTC agreed upon.

Built in P2Pool type mining option
The P2Pool project epitomizes the distributed nature and serves as an important bulwark against a few popular pools from having a huge influence on block chains. I suggest we incorporate this option directly into the client. This also will give users a no hassle option to mine and receive coins out of the box without dealing with pool registration and the risk of them being hacked.

Built in GPU mining option
I suggest we bundle and integrate a graphical interface such that novice users can easily mine with their GPU with just the normal official client. Combined with the above P2Pool suggestion this should further democratize mining making it as user friendly as possible to novice users.

Zerocoin anonymization
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf
While this may yet be too computationally and space intensive for now, I think we should at least consider the possibility of implementing this state of the art crypto work. It is going to be presented at the top academic conference in computer security this May. Read the paper for details, but the gist is that you can truly anonymize the coins such that no one can match the input and outputs of transactions. The main disadvantage it has for bitcoin is that the protocol would have to be accepted by all the users, but if we incorporate this by default in the client from the start we solve that problem. There is some concern about how heavyweight the crypto is so that will have to be considered.

0-confirmation double spend resistance
The normal defense against a double spend is to wait for a number of confirmations such that an attacker will have to have close to or more than 51% of the hashing power of the network. This is a very strong guarantee and works well for transactions of any amount, but comes at the cost of waiting for at least 1 block. For asynchronous transactions such as online purchases where product is eventually shipped after some delay this is almost no cost at all, but in the scenario where a user wants to use bitcoin like cash for an in store purchase and walk out with merchandise, this wait time greatly exceeds that of a 1 second credit card processing wait.

This is as far as I know a novel idea that I came up with to partially address wait time. A transaction with zero confirmations can easily be double spent. I propose that if multiple transactions are floating in the network waiting to be confirmed into the next block and there are conflicts among them (double spends) that as long as each transaction by itself would be valid that instead of choosing one the network writes both into the block and destroys the coins involved. While the merchant would still lose the coins so would the attacker removing the incentive to double spend. Now of course for large transactions one would still be ill advised to accept 0 confirmations, this destroys the incentive for a casual theft of small amounts. I think this could be especially useful for payment processors like bitinstant when people use it on their phones to pay for food or beer as if they left immediately after, there is a significant delay before anyone would be aware of the zero confirmation double spend.



I am also available to contribute some time to design/programming. I think this should be a significant undertaking with as many people involved as possible to really create a significant contribution to the cryptocurrency community. Anything halfhearted or just an incremental improvement will not make much difference. I'd rather not have a slew of alternative currencies that slowly build on each other, but rather a significant leap forward with real testing and new features.

Let me know if anything is unclear. I'll try to answer any questions although most of these ideas are preliminary so lots of work in finalizing an actual working implementation is yet to be done. I do believe that all these suggestions are quite practical if we have enough programmers volunteer to create and test them.

Nathaniel

[Nathaniel B]

Also just to clarify, I just registered this forum account but have been using bitcoin for almost 2 years now. See my post history for proof.

[Joerii]

In three days Taco will have saved his job and have not lost 25k ( I hope ) and I'm sure he's gonna be thrilled by all the responses