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

Wow, this coin will either never be released, or by the time it is, there will be much better.    Taking way too much time.

I'm a bit tied up until August 5th, but after that date I have a lot of time to devote to a quality translation of both the paper and the wiki. Hope that's not too late. If time is really an issue I will try to squeeze in some preliminary work before that date.

If you guys have the time, this article about how the M-PESA penetrated the Kenyan market is worth reading.

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1593387

We can take many of their ideas and use it for the greater benefit of Netcoin

Also, we should make a list of the skills that our supporters that are willing to contribute to this clause, so that we can assign and divide up tasks in an organized concerted effort.

That's a great idea. Thank you. tacotime is reworking some entropy-related issues in the paper based on what Impaler identified. I can send you a PM when the new paper is out and get a raw version to you if that helps with translation. Getting the next iteration of the paper translated would be really good. It's changed quite a bit since the last version, so I would recommend waiting for it to save you some time!

Absolutely. The sooner you can do this the better.

Is there any demand for translations of the whitepaper and wiki. Would be happy to translate both into Dutch in the future. Did this for PPCoin and Bitcoin as well.

http://www.scribd.com/StarkFujikawa/documents

Ah I see your plan is a bit different then what was presented in the first paper and which I was still operating under.  Your looking much much deeper into the block-chain and picking individual bits out to create a 1024 bit value that gets hashed before modulus.  While this dose pull in a lot of good entropy I'm still concerned that having Block #0 (the block immediately preceding the one being mined) is a concern.  If your willing to go thousands of blocks back for entropy why not just start at block #64 (that's 64 blocks prior, and go back all the way back to #65599) to completely block any possibility of manipulation by throwing away certain solutions.  An ASIC equipped attacker would need to mine astronomically large amounts of blocks (8^64) in order to have control of even 1 bit of the resulting lottery value.  It's overkill, but better to be safe then sorry.

Your concern for a set rotation of hashes causing the lottery ticket value to be drawn from blocks with similar hash type blocks can be solved quite simply by going back in a jump size that's not a multiple with your number of hash types, say ever 101 blocks which over the 1024 blocks your sampling should draw equally from all hash types.

There is difficulty scaling for each algorithm based upon N value to meet average block times.  Because ChaCha20 is only marginally faster than Salsa20 and the PBKDFs used in the beginning don't really affect total time required to perform the scrypt hashes, it's easy to generate a scaling function based simply on measuring execution time on CPU and GPU.  So long as this is fairly precise (the adjustment of difficulty for individual blocks based on the execution time of the algorithm for any given N), this isn't really an issue.  Also note that the PoS system makes it extremely difficult to fork the chain by any PoW method anyway, see:
http://www.netcoin.io/wiki/Netcoin_Proof-of-Work_and_Proof-of-Stake_Hybrid_Design

If you only use a single bit from each of these blocks, there are only two possible hashes arising from manipulating the current block.  Please see: http://www.netcoin.io/wiki/Netcoin_Proof-of-Stake_Voting_for_Proof-of-Work_Blocks

That means that the person attacking needs to manipulate all 1024 blocks before this to select their own lottery winner hash.  The end result is only a problem 2^16 possibilities, so there may be room for manipulation there if it can be reduced, however at minimum you would need to manipulate the last 16 blocks to perfectly achieve manipulation I would guess.

Perhaps the best case would be to just pull 16-bits from the block header of 16 of the last 65526 blocks and then generate the ticket numbers.


As I said, that's another (easier) option, though we do need randomization for the stake system.  However, if we do not randomize the selection of block header hashes, an ASIC selecting for a certain type of hash may have an advantage in the ticket selection system resulting from the block header hash algorithm used to generate the tickets/lottery winner hashes always being the same.

In a related note, how is longest chain resolved when different hashes are used?  Say I have two competing forks with the same number of blocks but different block algorithms, which one is longest?  My understanding in BTC is that difficulty and extra nonce can break all ties, a chain at low difficulty that contains more blocks can still be considered shorter if the cumulative hashing necessary to make it is less then another chain, thus the highest 'work' chain is always considered longest.  If different algorithms are being employed then the ability to cross compare difficulties and work become much harder.

But the number of inputs for the 'hash lottery' is irrelevant if the most recent block is at all an input towards that hash as the attacker will have full control of the result by repeatedly trying different last block solutions until they get the desired result.  The entire block history back to the genesis block could be hashed and it wouldn't mean a thing.

I think it very likely that a specialized piece of hardware like an ASIC would adopt this strategy.  If they submit their first valid block found to the chain then they have a 1/8 chance of being able to mine the next block and a mean wait time of 7 blocks until the lottery once again allows them to mine.  During that time they will be cut out of all mining and their machine will be idle.  So it makes sense to employ that time and hashing power to attempt to take more then 1/8th of all blocks even if it is by continuing to work on creating an reorganization around your own submitted blocks.

Once ASICs can produce blocks 8 times faster then the remaining network average they will by simple Nash equilibrium start to take most blocks without collusion but rather a simple desire to utilize their otherwise unusable hardware and hash potential.  And this is to speak nothing of a malicious attack which are typically willing to lose some money in the process.

I do not understand your point about all 8 hashes needing to be used in each group of 8 blocks, I see nothing in your protocol that enforces this and if that's the case why use a complex lottery and not a simple fixed rotation based on the block height modulus, this has the virtue of both being simple, guaranteeing an equal proportion and allows for absolutely no attack on that part of the coin.

I've been aware of such an attack, but keep in mind your following statement:

The attacker must now lose block rewards in order to manipulate the blockchain, which seems very unlikely (but possible).  This is actually why the last 256 bits of the block header hash are chosen for use as an in chain entropy source, because manipulation would require a vast amount of resources and additionally the discarding of block rewards.

Additionally, all 8 hash types must be used at least once per cycle of 8 blocks -- the best you could hope to achieve would be to sort them in a way that appeals to you.  Alternatively, you could just arrange all 8 hashing algorithms in the same order and avoid randomization.  Correspondingly, all 8 difficulty ranges of N must also be in place; the best an attacker could achieve is the minimum N values for each range eg 512, 768, etc.

This is why in the wiki there are bits taken from a very large number of block header hashes for ticket generation/lottery hash selection.  This will be addressed in the next edition of the paper.

Tacotime:  I think I may have thought of an exploit to the hash rotation system.  In your paper you describe the hash of the last 8 blocks being being modulus to derive the hash type of the next block.  The chance for each hash type to be selected will be quite equal if all block are submitted to the network, but if an attacker is willing to check the blocks they mine for what hash they will allow next and continues working on resolving the block until they get a solution that will allow repetition of the same algorithm.  It is thus a simple matter of performing on average X times more hashing (where X is the number of hash types selected amongst by modulus) to create a block-chain that is composed of only one hash algorithm.  As your planning to mix SHA and Scrypt it seems a fairly trivial process for the existing ASIC's to attempt to monopolize the chain in this way, and indeed they all have an economic incentive to due so and no direct collaboration is necessary as it would be the optimum strategy.

The number of prior blocks that are hashed together to create the hash that's modulus will be used is not material in preventing this kind of attack, as the changing of just 1 small part of a hash input will radically change the result and the modulus then gives a perfectly proportional distribution of all the hash options.  It is effectively no more secure then hashing each block to determine the next hash, the only defense is to increase the number of hash types used or to mandate a rotation of hashes by modulus of the block height.

I am also in, please keep us informed 

Okay I'll put my idea in the place of Paypal-like Profit-Oriented Decentralized Organization Supported by Blockchain

I cannot say for certain that title is based on my idea but I'm assuming it is because I'm the person who proposed something like it. If it is someone elses idea then I apologize in advance.

As long as you put it in a page, we can always move it around as you refine your ideas. Adoption of ideas that change the details within tacotime's specifications at this point is problematic because we want to try and move development forward as soon as he finishes the paper. Anything is worth putting up, and of course, if it's something that can be done without changing the underlying features of the coin that can be organised independently of the coin itself. Throw it up on the wiki and we can have a look!

Where on the Wiki would I put my ideas and which ideas?

The PayPal-Like organization seems like it could be based on the idea I mentioned about a mining/investor syndicate but I would never call it PayPal like. I'll contribute but I would need more information on what they are going to adopt.

I suppose any idea I had I could put it under Hypothetical Features.

Or others who want to be a contributor know exactly what they can contribute in the project.

Thanks for your update

We'll have some info about the crowdfunding and other details about the specifications this weekend. I'll take a few days after tacotime makes this public to prepare a concise package of exactly what everyone gets for what they put in. I also want to detail exactly what's going to happen during and after the funding. There will be bumps along the way, so I just want to make sure everyone understands exactly what's going to go on so nobody (or close to) feels unhappy with the process!

Not yet. People still discuss about underlying algorithms