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

[Blazed]

Nice to see a coin that will not be a pump and dump like so many others..

[1715114887]

1715114887

[1715114887]

1715114887

[1715114887]

1715114887

[1715114887]

1715114887

[1715114887]

1715114887

[cdog]

Crowdfunding sounds good, and although Im fine throwing a couple hundred LTC towards NTC seeing the light of day with nothing expected in return, if the dev budget and continual improvement of Netcoin requires $100k+ in funding, Im not sure if hundreds of others will do the same. Although I really hope that the crypto community comes out bigtime for this, because NTC has huge, HUGE potential. Im sure Satoshi himself would be (and probably is) proud of Taco and his awesome effort to do this, besides his massive contribution to crypto via GUI Miner.

[wizzardTim]

Crowdfunding sounds good, and although Im fine throwing a couple hundred LTC towards NTC seeing the light of day with nothing expected in return, if the dev budget and continual improvement of Netcoin requires $100k+ in funding, Im not sure if hundreds of others will do the same. Although I really hope that the crypto community comes out bigtime for this, because NTC has huge, HUGE potential. Im sure Satoshi himself would be (and probably is) proud of Taco and his awesome effort to do this, besides his massive contribution to crypto via GUI Miner.

I agree. NTC is bigger, much bigger than Bitcoin. It's many steps further.

[Luckybit]

Do we have any update from Taco or regarding the new white paper?

He's going to go into detail (greater detail than the paper) on the Wiki. In all likelihood we'll be able to do that concurrently with crowdfunding the project, and getting paid developers assembled. Unfortunately I don't have a recent update on his thinking, but I'm sure he'll chime in as soon as he gets a chance!

Current whitepaper link as posted on the 1st post of this topic is broken (http://www.platinumdigitalreserve.com/storage/mc2%20draft%20v0.031.

should probably be http://www.netcoin.io/latest.pdf instead

Yeah, that's right. Sorry! We'll have to update all those links. Forum is now at netcoin.io/forum. It'll open soon when we move into the next phase. Not trying to be a tease, but we don't have much to talk about until we have a development update, so it makes sense to open up the new forum when that happens.

Tacotime for President! Netcoins as the currency. Peace on earth.

Can someone give me the cliffnotes on how they decided to fund development? Im all for supporting this in any way possible.

You should start a White House petition so they can talk to TacoTime's prime minister, who can then talk to his school and see if they would let him take off some time to work on this full-time. Development is going to take the form of a crowdfunding run where the funds raised will go to development of various components of the proposal. The exact terms aren't finalised yet, but essentially the stake funders occupy in the network is required for its security. Ultimately the goal is to contribute to the public domain a body of work, where Netcoin is an implementation of that, which can't function without your stake in it (if that makes sense).

Can developers be paid in such a way so that it's not a lump sum payment?

Btw the new whitepaper is MUCH easier to follow. I now have a much better understanding on how Netcoin is intended to work. I can't find any faults with it yet but I'll continue looking at it.

[Luckybit]

The reasoning for N being based on very recent blocks versus the secure hash
algorithm being based on a table and eventually older blocks is to ensure the diversity of
randomization as well as to make sure that the most complex element of the secure hash
function, N, is difficult to predict.

This ^

I think just so long as it's difficult to predict it can work.

[tacotime]

There are a few problems with the PoW/PoS method as detailed.  I'm trying to upload proposed updates to the wiki, but the wiki is still kind of buggy and won't let me.

Namely:
1) You can't invalidate previous blocks without recursively invalidating the blockchain as described.  The solution I am proposing is to make truncated PoS subblocks that verify the PoW blocks (this will make more sense when you read it entirely).
2) Truncating SHA3-256 to 16 bits is somewhat dangerous from a security perspective for ticket selection.  This can be resolved by making the input data for the hash fairly random (ie, hash the concatentation of the last 256-bits of the block header hash + SHA3-256 hash of the stake transaction in the block + bits and pieces of the last n blocks' block header hashes + block header hashes of the stake subblocks).  What you really don't want is someone gaming the ticket hashes by manipulating the transaction list, this needs to be thought about a little more to ensure it can not be manipulated.
3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw.  At high transaction volume, it will be more or less impossible for a PoS miner to calculate hashes for all possible additions of transactions to the ledger, so an algorithm as just described that is less intensive is needed.
4) To keep block timing consistent, we need to adjust difficulty based on the value of N for each new PoW block.  This is pretty easy, as hashing performance scales almost linearly with N in the ranges I specified if I remember right.

[solracx]

I think that tacotime should announce or reveal his plan/roadmap to implement this currency. This discussion takes too long without any progress recently.

+1  I completely understand them trying to get it right, different, innovative, taking time to get outside ideas to implement... But it's been almost 3 months already... It's time to get this going, and for a release, updates on a release at least.

This coin isn't going to go anywhere unless folks start coding.

Right now it appears to be all planning.... months of planning.

I suggest incrementally adding features over time. 

That's exactly what ZenithCoin plans to do.  Incrementally add features.   No coin is going to be perfect on first launch, but the important point is that the coin can evolve and adapt over time.

[cryptrol]

This coin isn't going to go anywhere unless folks start coding.
Right now it appears to be all planning.... months of planning.
I suggest incrementally adding features over time. 
That's exactly what ZenithCoin plans to do.  Incrementally add features.   No coin is going to be perfect on first launch, but the important point is that the coin can evolve and adapt over time.

Are you saying we need another crap coin NOW, that will eventually be improved later ?
No, thanks.
Also Rome wasn't built in a day.
Also you can early adopt almost 3 coins a day at the moment.

[cryptrol]

I really like the polymorphic hash tree idea, have you considered increasing p, or r in scrypt ? Wouldn't this increase ASIC resistance (and even GPU) ? Also, would it be possible (or useful) to increase this factors (or also n) if a given difficulty is reached ? This would really be a game changer for hasher's. In fact scrypt has this parameters set for long term compatibility/security in case hardware improvements provide some orders of magnitude speed bumps in memory or processing power, we have seen this done with n and YAC but with time intervals, maybe it makes more sense than using difficulty, but using time is a guessing game.

I am still trying to understand how difficulty will accommodate while using so many different algorithms. Isn't it possible for an algorithm to out-weight others in terms of difficulty driving ? Let's say that an optimization (hard or soft) is found for an algorithm and it hashes way faster than the other's. How will this affect the difficulty ?

Forgive my ignorance.

[Luckybit]

There are a few problems with the PoW/PoS method as detailed.  I'm trying to upload proposed updates to the wiki, but the wiki is still kind of buggy and won't let me.

Namely:



2) Truncating SHA3-256 to 16 bits is somewhat dangerous from a security perspective for ticket selection.  This can be resolved by making the input data for the hash fairly random (ie, hash the concatentation of the last 256-bits of the block header hash + SHA3-256 hash of the stake transaction in the block + bits and pieces of the last n blocks' block header hashes + block header hashes of the stake subblocks).  What you really don't want is someone gaming the ticket hashes by manipulating the transaction list, this needs to be thought about a little more to ensure it can not be manipulated.
3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw.  At high transaction volume, it will be more or less impossible for a PoS miner to calculate hashes for all possible additions of transactions to the ledger, so an algorithm as just described that is less intensive is needed.
4) To keep block timing consistent, we need to adjust difficulty based on the value of N for each new PoW block.  This is pretty easy, as hashing performance scales almost linearly with N in the ranges I specified if I remember right.

1) You can't invalidate previous blocks without recursively invalidating the blockchain as described.  The solution I am proposing is to make truncated PoS subblocks that verify the PoW blocks (this will make more sense when you read it entirely).

If I understand correct the stakeholders are the signatories who vote Yea or Nay to validate whether or not the transaction ledgers match? If they vote 60/40 in Yea then it is true and 60/40 in Nay then it is false?

So it creates a validation chain over time, and you're using truncated PoS sub blocks as the mechanism to accomplish this? Complexity is the enemy of security but I also understand that in this case there is no simpler algorithm that I can think of to do it. It seems like it would work on paper but you're going to have to explain in more detail on the wiki.


3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw.


So what you're trying to do here is essentially verify the integrity of the transaction list?
An algorithm captures the latest snapshot of the list, captures the time stamp as the meta-data part of the input, analyzes the meta-data along with the transaction list to determine whether or not the snapshot is plausible/implausible? This would be narrowed down to a true or false?

Will probability be factored in or is it just true or false?

This will be used to supplement the PoS solution? Are you saying that the PoS solution you highlight in the paper will not scale?

Consistency issues may also arise; for example, if two transactions are sent at nearly the same time, Node A might first see Tx A and Node B might first see Tx B. Node A claims a block and hashes the transaction list with Tx A sorted into the list. Then Node B sees Tx A and makes a list sorted with both A and B in it. Node B will thus never generate the same hash as the one used by Node A to solve the block. To remedy this, stakeholder nodes will have to generate hashes for all possible incorporations for the last n transactions.

If the remedy you are describing based around some sort of combinatorics based consistency check? Are you saying all possible Tx orders would have to be included so that they both generate the same hash? I'm confused about this.

Are you saying that the transaction list is like a finite Markov chain?

[Lawyer]

http://bitcoinnews.io/dan-kaminsky-predicts-the-end-of-the-current-proof-of-work-function/

Around the 40 minute mark on the Security Panel at Bitcoin 2013 (video starts at 40 mins), Dan Kaminsky predicts that the current proof-of-work function isn’t going to be used by the end of the year — he assigns 0% probability it’s going to be used. A move away from ASICs, and back to mining with CPUs!

CPUs at the ready…

https://www.youtube.com/watch?feature=player_embedded&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&v=si-2niFDgtI

This is very interesting indeed.

[mrvegad]

http://bitcoinnews.io/dan-kaminsky-predicts-the-end-of-the-current-proof-of-work-function/

Around the 40 minute mark on the Security Panel at Bitcoin 2013 (video starts at 40 mins), Dan Kaminsky predicts that the current proof-of-work function isn’t going to be used by the end of the year — he assigns 0% probability it’s going to be used. A move away from ASICs, and back to mining with CPUs!

CPUs at the ready…

https://www.youtube.com/watch?feature=player_embedded&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&v=si-2niFDgtI

This is very interesting indeed.

He is right,  its called eMunie.

[Luckybit]

http://bitcoinnews.io/dan-kaminsky-predicts-the-end-of-the-current-proof-of-work-function/

Around the 40 minute mark on the Security Panel at Bitcoin 2013 (video starts at 40 mins), Dan Kaminsky predicts that the current proof-of-work function isn’t going to be used by the end of the year — he assigns 0% probability it’s going to be used. A move away from ASICs, and back to mining with CPUs!

CPUs at the ready…

https://www.youtube.com/watch?feature=player_embedded&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&v=si-2niFDgtI

This is very interesting indeed.

I think he said that to cause people to think. It wont actually happen I don't think.

Netcoin also has some ideas which Bitcoin could never compete with even if they changed the core hashing algorithm to Scrypt. Netcoin has the lottery ticket system which is a game changer for doing PoS. It's nothing like PPC. In a way it takes the best of Bitcoin, the best of PPC, the best of Litecoin and combines them all into the Bitcoin killer.

As soon as the whitepaper and wiki are finished I will invest a good day studying Netcoin and then see if it's as good as I think it is and if it is then I'll put my full support behind it as the next thing.

Here is something to note, PPC is going to rise quite a bit in the next few weeks. It's a good time to buy PPC. SunnyKing turned out to be right, his algorithm aligns scarcity to Moore's law and because there is this ASIC arms race the more that happens the greater the value of PPC.  And it seems to do this without the volatility of Bitcoin and Litecoin.

But it does have it's flaws as well because the difficulty algorithm was an experiment which could have failed if the ASICs did not come this summer.  I'm interested in Primecoin along with Netcoin.

[tacotime]

I'm sick right now, but I'll try to answer these as best I can.

1) You can't invalidate previous blocks without recursively invalidating the blockchain as described.  The solution I am proposing is to make truncated PoS subblocks that verify the PoW blocks (this will make more sense when you read it entirely).

If I understand correct the stakeholders are the signatories who vote Yea or Nay to validate whether or not the transaction ledgers match? If they vote 60/40 in Yea then it is true and 60/40 in Nay then it is false?

So it creates a validation chain over time, and you're using truncated PoS sub blocks as the mechanism to accomplish this? Complexity is the enemy of security but I also understand that in this case there is no simpler algorithm that I can think of to do it. It seems like it would work on paper but you're going to have to explain in more detail on the wiki.

Yes, the stuff for the wiki for this component is written, but right now the wiki is not really working correctly.

3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw.


So what you're trying to do here is essentially verify the integrity of the transaction list?
An algorithm captures the latest snapshot of the list, captures the time stamp as the meta-data part of the input, analyzes the meta-data along with the transaction list to determine whether or not the snapshot is plausible/implausible? This would be narrowed down to a true or false?

Will probability be factored in or is it just true or false?

You have it correct.
Ideally the algorithm should have an input cutoff range for probability, with 1 being totally stringent, 0 being "accept any transaction arrangement", and anything between there being a different level of stringency.  Stakeholders themselves could adjust this value, but via experimentation on the testnet we can obtain what will be an ideal cutoff, at least at some level of traffic.

This will be used to supplement the PoS solution? Are you saying that the PoS solution you highlight in the paper will not scale?

Consistency issues may also arise; for example, if two transactions are sent at nearly the same time, Node A might first see Tx A and Node B might first see Tx B. Node A claims a block and hashes the transaction list with Tx A sorted into the list. Then Node B sees Tx A and makes a list sorted with both A and B in it. Node B will thus never generate the same hash as the one used by Node A to solve the block. To remedy this, stakeholder nodes will have to generate hashes for all possible incorporations for the last n transactions.

If the remedy you are describing based around some sort of combinatorics based consistency check? Are you saying all possible Tx orders would have to be included so that they both generate the same hash? I'm confused about this.

If the transaction volume is low, you can calculate ledger hashes for all possible likely transactions that should be included in the block.  When the transaction volume becomes huge, the combinatorial calculation of all possible hashes becomes computationally intensive and possibly impossible for the use that we want (instantaneous confirmation of validity of the blockchain).  Hence, the theoretical algorithm as described above.

Are you saying that the transaction list is like a finite Markov chain?

Sort of.  I will write more on this later, I am not feeling good.

[_ingsoc]

Yes, the stuff for the wiki for this component is written, but right now the wiki is not really working correctly.

The Wiki is painfully slow right now, and I'm not sure why. I'm working with XWeb, who hosts the Netcoin stuff, to figure out why. In the meantime, I've managed to put up the stuff tacotime wanted to push out, so if anyone is interested: http://www.netcoin.io/wiki/Netcoin_Proof-of-Work_and_Proof-of-Stake_Hybrid_Design

[_ingsoc]

Okay, Wiki seems fine now. Even on a shitty tethered connection in the middle of nowhere, I can use it without too much drama. Let me know if anyone has any trouble.

[cunicula]

Chain Score=∑((PoW Difficulty)^1/2∗(PoS Difficulty)^1/2∗(Number of Stake Vote Blocks)^1/2∗(PoW Block Height)^1/2)

1) What is the purpose of the term (PoW Block Height)^1/2?

Block height can be manipulated to some extent. When the hash rate is increasing, blocks appear more frequently than every 10 minutes.
When the hash rate is decreasing, blocks appear less frequently than every 10 minutes.

As an attacker, you would benefit by gradually adding hashing power over time, so that the average block interval on the attack chain is below that on the main chain.
Given enough time, you could overtake the main chain in terms of block height. Once you have established a block height lead, attack cost less
in terms of stake and work. I don't think it is a big deal, but I would like to know the rational behind this.

2) My intuition says that is safer to use weights that sum to 1, e.g. (1/4,1/4,1/4,1/4) rather than (1/2,1/2,1/2,1/2).

Can't say exactly why right now.
If you prefer (1/2,1/2,1/2,1/2) to (1/4,1/4,1/4,1/4) for some reason, then explain why and I will try to figure out whether I am right or wrong.
If you don't have a preference, then just go with (1/4,1/4,1/4,1/4) and I will conserve mental energy.

[digicoin]

Interesting read

http://www.hostmerchantservices.com/2013/07/bitcoin-the-hidden-danger-to-your-business/ Bitcoin: The Hidden Danger to Your Business

[frga13]

Interesting read

http://www.hostmerchantservices.com/2013/07/bitcoin-the-hidden-danger-to-your-business/ Bitcoin: The Hidden Danger to Your Business

Chrome said that this URL is hidden danger to my computer

[digicoin]

False alarm? Use Firefox. I drop Chrome for a long time