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

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

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?

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.

( 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 ?

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. 

Taco, any updates ?

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

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.

Your PoS idea is very similar to cunicula's ABAB system, that we discussed in the PoA thread (see https://bitcointalksearch.org/topic/proof-of-activity-proposal-102355 , 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.

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.



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.

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...)

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.

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.

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.

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.

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

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

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.

I have... it depends on how big a dev team I can assemble, what the size of my donations are, and what kinds of problems we encounter when actually implementing it.  Originally I didn't have the intention of forging a new PoS system (I just had the polymorphic hash tree idea in mind for a while), but if there is added security included by using one I would definitely prefer to have it included.

In about two weeks I will also open a dev channel in freenode, and people interested can hop in and begin discussing the chain and its shortcomings, solutions to these, and so on.

As cool as the sci-fi futuristic term Credit is, it still has the connotation of owing someone something. I would advise against making a drastic name change like that if you are hoping for eventual widespread adoption of the currency. Metacoin is still my first choice .

You seem to be alternating between simplifying and complicating different aspects of your design that is based on other coins. The simplification process is a step in the right direction, but I was wondering if making certain things more complex for the sake of security might cause too many unforeseen challenges early on. Have you considered staggering the implementation of certain features and security protocols as your coin progresses in usage?