Momentum 2.0 Discussion

[FreeTrade]

More details on the MemoryCoin 2.0 PoW

https://bitcointalk.org/index.php?topic=355532.new#new

I'm going to try to keep the interface as similar to ProtoShares as possible, so that infrastructure developed for ProtoShares can be deployed for MemoryCoin too.

[barwizi]

Momentum 3.0

[bytemaster]

This entire thread may be moot given my recent ideas regarding proof-of-stake: http://bitsharestalk.org/index.php?topic=1138.0

In effect, I believe I can almost entirely eliminate proof-of-work from new coins.

[bytemaster]

There are many different ways to apply aes.  The CBC mode is sequential.  I am sure block mode could be accelerated on gpu but CBC would have to run in a single thread


Sent from my iPhone using Tapatalk

[FreeTrade]

Cool.

I'm reading a bit about AES - came across this . . . any thoughts -

http://developer.amd.com/resources/documentation-articles/articles-whitepapers/bulk-encryption-on-gpus/

Conclusion

The results illustrated in this article prove the viability of implementing the AES algorithm on the AMD GPUs, which show considerable speedups compared to the current generation Intel processor or commodity graphics cards. We have obtained a speedup of up to 16 times with the ATI Radeon™ HD 5870 GPU while the ATI Mobility Radeon™ HD 5650 GPU is showing up to 3 times the performance increase.

[bytemaster]

I would love to see this tested in memory coin.


Sent from my iPhone using Tapatalk

[FreeTrade]

The population of the memory is sequential which helps eliminate memory bus latency and allows the CPU to saturate the BUS.  A GPU would have an advantage in the comparison step because it could compare all birthdays with the new birthday in parallel.    That said, a GPU would be limited in parallelism because it could only store 1000 or 2000 birthdays at a time.

Would it be limited also because the CPU could do the XOR step with data in L2 cache - so let's say an i7 with 4 cores could run 4 processes, each using 2MB L2 cache . . but a GPU running many more cores would run out of this faster memory much quicker.

Hope you don't mind, giving serious consideration to using this style of POW in the MemoryCoin relaunch.

[bytemaster]

There are too many empty blocks in PTS block chain.  The whitepaper seems to imply that miners not including latest transactions in the block is a better mining strategy, or at least they don't have incentive to do so.

The most efficient mining strategy is to cache all transactions that you receive while mining the current block until someone finds the current block, and then create a new block with all of the cached transactions. This property means that a transaction broadcast 5 seconds after the last block was found has no advantage over a transaction broadcast 5 minutes after the last block was found
because few miners will begin working on including either transaction until the next block is found.

With this many empty blocks, many transaction confirmations got badly delayed, this clearly is not a desirable result -- am I missing something?

This does not prevent transactions from being included, this only delays their inclusion 1 block.   It may have some benefits for markets on block chains.

This property does not hold with the current momentum algorithm.

[barwizi]

Well, memory is one step, what else?

[marketp2p]

There are too many empty blocks in PTS block chain.  The whitepaper seems to imply that miners not including latest transactions in the block is a better mining strategy, or at least they don't have incentive to do so.

The most efficient mining strategy is to cache all transactions that you receive while mining the current block until someone finds the current block, and then create a new block with all of the cached transactions. This property means that a transaction broadcast 5 seconds after the last block was found has no advantage over a transaction broadcast 5 minutes after the last block was found
because few miners will begin working on including either transaction until the next block is found.

With this many empty blocks, many transaction confirmations got badly delayed, this clearly is not a desirable result -- am I missing something?

[bytemaster]

I would like to refocus this topic on my Momentum 2.0 mining algorithm.  A new thread can be created to discuss human-in-the-loop mining.

[liberman]

Who ever generated the captchas would know the answers.

Yeah, but you still have to mine.
That could be your advantage for being the main developers. I think we could all agree that you deserve more, as you are the guardians/promotors/inventors of the project.

[liberman]

What would happen is some miner with ambitions to grab the entire market would pay Amazon's Mechanical Turk to have all of the private keys revealed and cached for when they are required.    It would be a lot of work, but once done would grant them all of the blocks.   Amazon would probably pay $0.05 per solution which means for $1 million dollars you would be able to 'own' $10 million dollars worth of blocks.     Perhaps you could scale it to billions of items...

Well, that means that person has to have $1 million dollars first. And then decide to invest on this. A very unlikely thing.
Putting the captchas is a better solution than just letting mine alone, because he can invest just $100,000 and have 70% of all the mining power.
(Note that with $100,000 you can rent 10,000  32 core computers in amazon for 10 hours, giving each of them around 700c/m, enough to obtain most of the bitshares.)

[bytemaster]

I'm also interested in other companies trying things like this when they make their own Protoshares.  I think the model is too good to convince everyone to join your chain.

It could work well for other companies, that is true.

[Lighthouse]

I'm also interested in other companies trying things like this when they make their own Protoshares.  I think the model is too good to convince everyone to join your chain.

[bytemaster]

Fast validation times are a requirement.   It is easy to make a memory hard pow that takes too long to verify. 


Sent from my iPhone using Tapatalk

How about launching a slow validation coin, and then create a second currency/genesis bitshare block that maps 1:1 to "SlowCoin" when they are all mined?

That would allow a memory hard pow, right?

This is interesting, and possible because the value of the coin is based almost entirely on the social contract being honored by the backing company.  You could make arbitrary changes like this and it wouldn't be that big a deal so long as the social contract doesn't change to the downside.

This may work for the ProtoCoin but part of the purpose of the ProtoCoin is to test features of the final chain. 

[Lighthouse]

Fast validation times are a requirement.   It is easy to make a memory hard pow that takes too long to verify. 


Sent from my iPhone using Tapatalk

How about launching a slow validation coin, and then create a second currency/genesis bitshare block that maps 1:1 to "SlowCoin" when they are all mined?

That would allow a memory hard pow, right?

This is interesting, and possible because the value of the coin is based almost entirely on the social contract being honored by the backing company.  You could make arbitrary changes like this and it wouldn't be that big a deal so long as the social contract doesn't change to the downside.

[ThisNinja]

Fast validation times are a requirement.   It is easy to make a memory hard pow that takes too long to verify. 


Sent from my iPhone using Tapatalk

How about launching a slow validation coin, and then create a second currency/genesis bitshare block that maps 1:1 to "SlowCoin" when they are all mined?

That would allow a memory hard pow, right?

[barwizi]

true... if only human brains were stackable like servers.

[bytemaster]

Who ever generated the captchas would know the answers.


Sent from my iPhone using Tapatalk

From where i am standing

1) We all seem against VPS etc
2) There is a GPU miner in the works, if not two.
3) The original intention was a well dispersed CPU only coin.

People should stop complaining about amazon users, they are basically just outsourcing hash power.

here's the real deal.

Botnets 1,2 and 3 plus GPU farms 1,2,3,4,5,6,7 ~ 15 are about to wreck havok combined. with a single i7 you'll be lucky to get 0.01 PTS per day.
Momentum 2.0 is the beta product and has to deal with these issues yet remain feasible. So the question really is how do we go to being a truly CPU mined algo without complicating the mining process. Keeping it scalable for those with multiple machines? IMO it's all down to tweaking the algo making it VPS harder and GPU NO-NO, for those that don't get what i am saying. Current arguments like registered mining and long term maturity do nothing in the end, as you know once i am registered i can point all my miners to one account or use one machine to pipe all the others. Long term maturity falls on rocks because botnets will just mine, for those six months plus more. with GPU farms that makes it worse, i know quite a few farms, much to my awe ( 700 mh/s + on scrypt). These belong to companies and individuals who can mine 12 hours of any coin and 12 hours of momentum and still be very profitable. We need sharks and whales in the pool to make it interesting and bring in lumpsum investments, so lets make something scalable, convenient  yet not easy to rape.

Thank you barwizi... you hit the nail on the head.   

Why don't botnet operators CPU mine for Bitcoin?  Because the profits are too low.   We need to achieve the same result.   Right now a GPU farm is only 3x more powerful per card than a CPU farm and of course you can rent GPUs on Amazon as well.   3x is a relatively small gain compared to what Litecoin saw (right?) and many people have GPUs.... I think we need to separate concerns:

1) Giving away the coin like 'free AOL CDs' 
2) Securing the network with hash power.

When we try to 'mix' these two you have things that don't work.   

[barwizi]

Who ever generated the captchas would know the answers.


Sent from my iPhone using Tapatalk

From where i am standing

1) We all seem against VPS etc
2) There is a GPU miner in the works, if not two.
3) The original intention was a well dispersed CPU only coin.

People should stop complaining about amazon users, they are basically just outsourcing hash power.

here's the real deal.

Botnets 1,2 and 3 plus GPU farms 1,2,3,4,5,6,7 ~ 15 are about to wreck havok combined. with a single i7 you'll be lucky to get 0.01 PTS per day.
Momentum 2.0 is the beta product and has to deal with these issues yet remain feasible. So the question really is how do we go to being a truly CPU mined algo without complicating the mining process. Keeping it scalable for those with multiple machines? IMO it's all down to tweaking the algo making it VPS harder and GPU NO-NO, for those that don't get what i am saying. Current arguments like registered mining and long term maturity do nothing in the end, as you know once i am registered i can point all my miners to one account or use one machine to pipe all the others. Long term maturity falls on rocks because botnets will just mine, for those six months plus more. with GPU farms that makes it worse, i know quite a few farms, much to my awe ( 700 mh/s + on scrypt). These belong to companies and individuals who can mine 12 hours of any coin and 12 hours of momentum and still be very profitable. We need sharks and whales in the pool to make it interesting and bring in lumpsum investments, so lets make something scalable, convenient  yet not easy to rape.

[bytemaster]

Who ever generated the captchas would know the answers.


Sent from my iPhone using Tapatalk

[Lighthouse]

What would happen is some miner with ambitions to grab the entire market would pay Amazon's Mechanical Turk to have all of the private keys revealed and cached for when they are required.    It would be a lot of work, but once done would grant them all of the blocks.   Amazon would probably pay $0.05 per solution which means for $1 million dollars you would be able to 'own' $10 million dollars worth of blocks.     Perhaps you could scale it to billions of items...

Why not make it an insurmountable task by changing it periodically? 

[bytemaster]

What would happen is some miner with ambitions to grab the entire market would pay Amazon's Mechanical Turk to have all of the private keys revealed and cached for when they are required.    It would be a lot of work, but once done would grant them all of the blocks.   Amazon would probably pay $0.05 per solution which means for $1 million dollars you would be able to 'own' $10 million dollars worth of blocks.     Perhaps you could scale it to billions of items...

[liberman]

There is no point in debating the human-interrupt designs because they are all based upon secrets (the digital value represented by the turing test) and a DAC cannot keep secrets.   This system can only work with a central authority keeping the secrets and signing validation receipts which are then included in block headers.

Conclusion, human in the loop systems are fundamentally centralized and would also be farmed out to Amazon's Mechanical Turk.

Just thinking about this:

Imagine you put an enormous database of captchas, something like 20 million ones in a public database accesible via p2p, and not tied to any particular server.
Every captcha has a public key, and a private key, but the private key is in the drawing.
So for every region that is going to be mined, a mathematical formula drives the miner to the captcha corresponding to the public key derived from the region signature. Then the miner must manually introduce the private key drawn in the captcha before he can proceed to mine.
The only way to automate the introduction of the private key in the captcha is by manually have a team of humans that spend a lot of time in manually introducing the captchas they are going to mine.
You can optimize the requirement of the introduction of the captcha to be something like once every hour for the average computer. This algo would mean that mining is actually a process in which a human must be involved, so only people really interested would mine.

[luckybit]

I think a core question is, do we want mining to be human scalable or capital scalable.

Current coins including protoshares are capital scalable, you can mine as much as you can spend money.   By requiring individual registration, or human-required interrupts like a rotating captcha you make it non-economical to run 3,000 servers if each server has an average 5 interrupts randomly per day.  Doesn't matter if it's a cloud miner, doesn't matter if it's botnet, the human element does not scale like the hardware does. 

To a certain extent this makes the guy with 40 computers in his garage the hardest working and best paid, requiring constant attention (5 interrupts x 40 divided by 24 hours in the day means an interrupt every 8.3 minutes).

I actually don't hate the idea of random interrupts, it incentivizes people run it on the computer they are actively working on because otherwise they'll be periodically checking at best or waiting for an email alert.  One imagines a new suite of tools will emerge to try and automate this, and that becomes the arms race improving captchas.

Perhaps moving icons could be used as a human interrupt. It could be decentralized and use a random seed which could move a fixed set of icons into a random order which the human being would simply have to put into the correct order or previous order.  Not saying a botnet couldn't eventually beat that too but it would take time and effort for botnet operators to beat and it wont be a situation where the botnets mine all the shares up at launch.

You can make his life easier by giving people points for solving captchas which they can use to skip future captcha challenges. If you solve a challenge or a particularly tough puzzle then you earn a lot of points and you don't have to do any more puzzle solving for a while because you have enough credit. Basically the human being mines by solving the puzzle or captcha to take back his time freedom.

A botnet could not do this.

There is no point in debating the human-interrupt designs because they are all based upon secrets (the digital value represented by the turing test) and a DAC cannot keep secrets.   This system can only work with a central authority keeping the secrets and signing validation receipts which are then included in block headers.

Conclusion, human in the loop systems are fundamentally centralized and would also be farmed out to Amazon's Mechanical Turk.

I would propose that this is a preferable outcome, and much less scalable than EC2 or botnets.  Worst case scenario existing mechanical-turk esque markets are bid up and people working there make a little more along with the market provider.

Unless you make periodic human attention the limiting factor, you make scaling your mining operation about how much money you can bring to bear.

It will always be about how much money you can bring to bear.  Even with people in the loop.  Out sourcing to Amazon's Mechanical Turk is one way, but another way is hiring people on craigslist. 

So long as you are going to be centralized, there is no need for mining.  I could just collect email addresses and payout faucets and then sign a block every 5 minutes.  It would be far less annoying.

That is the main problem with the captcha solution. It does promote centralization and i have not discovered a decentralized way of doing it which is also transparent.

There may be some way of solving the problem but all of the ideas I have are based on the human attention / interaction leveling the playing field. I don't think we should give up, we should continue to research ways to provide incentives to human beings not to cheat with botnets.

[bytemaster]

There is no point in debating the human-interrupt designs because they are all based upon secrets (the digital value represented by the turing test) and a DAC cannot keep secrets.   This system can only work with a central authority keeping the secrets and signing validation receipts which are then included in block headers.

Conclusion, human in the loop systems are fundamentally centralized and would also be farmed out to Amazon's Mechanical Turk.

I would propose that this is a preferable outcome, and much less scalable than EC2 or botnets.  Worst case scenario existing mechanical-turk esque markets are bid up and people working there make a little more along with the market provider.

Unless you make periodic human attention the limiting factor, you make scaling your mining operation about how much money you can bring to bear.

It will always be about how much money you can bring to bear.  Even with people in the loop.  Out sourcing to Amazon's Mechanical Turk is one way, but another way is hiring people on craigslist. 

So long as you are going to be centralized, there is no need for mining.  I could just collect email addresses and payout faucets and then sign a block every 5 minutes.  It would be far less annoying. 

[Lighthouse]

There is no point in debating the human-interrupt designs because they are all based upon secrets (the digital value represented by the turing test) and a DAC cannot keep secrets.   This system can only work with a central authority keeping the secrets and signing validation receipts which are then included in block headers.

Conclusion, human in the loop systems are fundamentally centralized and would also be farmed out to Amazon's Mechanical Turk.

I would propose that this is a preferable outcome, and much less scalable than EC2 or botnets.  Worst case scenario existing mechanical-turk esque markets are bid up and people working there make a little more along with the market provider.

Unless you make periodic human attention the limiting factor, you make scaling your mining operation about how much money you can bring to bear. 

[Lighthouse]

I think a core question is, do we want mining to be human scalable or capital scalable.

Current coins including protoshares are capital scalable, you can mine as much as you can spend money.   By requiring individual registration, or human-required interrupts like a rotating captcha you make it non-economical to run 3,000 servers if each server has an average 5 interrupts randomly per day.  Doesn't matter if it's a cloud miner, doesn't matter if it's botnet, the human element does not scale like the hardware does. 

To a certain extent this makes the guy with 40 computers in his garage the hardest working and best paid, requiring constant attention (5 interrupts x 40 divided by 24 hours in the day means an interrupt every 8.3 minutes).

I actually don't hate the idea of random interrupts, it incentivizes people run it on the computer they are actively working on because otherwise they'll be periodically checking at best or waiting for an email alert.  One imagines a new suite of tools will emerge to try and automate this, and that becomes the arms race improving captchas.

mining is meant to be fire and forget, that is why systen stabilty is one of the big five,

Fire and forget is the exact element that enables botnets and cloud miners, I understand that everything to this point has been fire and forget but I'm proposing that feature is the problem.

[bytemaster]

There is no point in debating the human-interrupt designs because they are all based upon secrets (the digital value represented by the turing test) and a DAC cannot keep secrets.   This system can only work with a central authority keeping the secrets and signing validation receipts which are then included in block headers.

Conclusion, human in the loop systems are fundamentally centralized and would also be farmed out to Amazon's Mechanical Turk.

[barwizi]

I think a core question is, do we want mining to be human scalable or capital scalable.

Current coins including protoshares are capital scalable, you can mine as much as you can spend money.   By requiring individual registration, or human-required interrupts like a rotating captcha you make it non-economical to run 3,000 servers if each server has an average 5 interrupts randomly per day.  Doesn't matter if it's a cloud miner, doesn't matter if it's botnet, the human element does not scale like the hardware does. 

To a certain extent this makes the guy with 40 computers in his garage the hardest working and best paid, requiring constant attention (5 interrupts x 40 divided by 24 hours in the day means an interrupt every 8.3 minutes).

I actually don't hate the idea of random interrupts, it incentivizes people run it on the computer they are actively working on because otherwise they'll be periodically checking at best or waiting for an email alert.  One imagines a new suite of tools will emerge to try and automate this, and that becomes the arms race improving captchas.

mining is meant to be fire and forget, that is why systen stabilty is one of the big five,

[Lighthouse]

I think a core question is, do we want mining to be human scalable or capital scalable.

Current coins including protoshares are capital scalable, you can mine as much as you can spend money.   By requiring individual registration, or human-required interrupts like a rotating captcha you make it non-economical to run 3,000 servers if each server has an average 5 interrupts randomly per day.  Doesn't matter if it's a cloud miner, doesn't matter if it's botnet, the human element does not scale like the hardware does. 

To a certain extent this makes the guy with 40 computers in his garage the hardest working and best paid, requiring constant attention (5 interrupts x 40 divided by 24 hours in the day means an interrupt every 8.3 minutes).

I actually don't hate the idea of random interrupts, it incentivizes people run it on the computer they are actively working on because otherwise they'll be periodically checking at best or waiting for an email alert.  One imagines a new suite of tools will emerge to try and automate this, and that becomes the arms race improving captchas.

[luckybit]

Don't be so concerned about botnets and ec2, botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do - this is starting to become a DRM vs warez analogy which always ended bad for the important part, the user / customer. And ec2 is always only a viable option at the beginning, it is not cost effective pretty soon unless you front a serious amount of cash which in turn could have bought rigs aswell - same same but different

Captcha's would make it so a human would have to be involved in the process of mining. Botnets cannot easily solve these captchas yet and when they can an update can change them. The original Bitcoin protocol has an alert functionality built in to tell the user to update and this could be extended to include alert captcha. That is just one solution. Another is to shuffle the algorithm in such a way that a botnet cannot optimize for it.

One thing about botnets is they run unattended. A popup alert which asks (are you a bot?) with a captcha would make it a lot harder to do botnets even if not impossible. I'm sure there are more creative ways too.

A solution to botnets is a human user authentication protocol. To come up with an optimal algorithm I recommend a SWOT analysis of the latest botnet technologies. What are the strengths and what are the limitations of botnets? The knowledge of limitations of botnets should be exploited in the protocol design. One example of a strength of a botnet is that it allows a central controller to control a bunch of computers at a time, potentially millions. The weakness of a botnet is the central controller is usually just one person or a group of people in an IRC chatroom and they cannot monitor 100 computers in real time 24/7.

The easy solution is to build in a reverse turing test and require every human miner solve the puzzle before they are allowed to mine. The botnet operator would have to solve each individual puzzle on each computer manually which would be as time consuming as the person using digital ocean. If the puzzle is designed right the botnet operator would not be able to solve it easily at all. For instance a lot of botnets rely on a keylogger so if you use the mouse for data entry then it would defeat the botnet. Additionally a game which is really simple like tic tac toe or something similar would be helpful as well. The most extreme solution is to just link all mining to a Keyhotee ID and have signed mining.

I don't know what algorithm would work best for an anti-botnet solution but I think it is necessary to find one if the DAC idea is to work long term. If there are botnets then proof of stake voting is impossible as it would be impossible to determine whether a real human voted or a botnet. The voting could be accomplished by code voting, but proof of stake is ruined if botnets have the highest stakes.

Unless you come up with an idea how to prevent a botcontrolled pc from mining but a normal one not without crippling everything and making the whole process a pain in the ass, thats the way it is and you are just whining because you think something is unfair - welcome to the real world.

There may be ways but none are easy to implement without bringing in some level of centralization. If you use captchas it would require either centralization or an external data stream. If you do some scheme with cellphone txt message authentication then the miner loses anonymity. Eventually the best solutions will make mining unprofitable for botnets and make mining a process where a human being has to attend to the process and interact with it somehow.

The lottery mining idea is great because it increases human interaction with the process which exploits the fact that botnets cannot gain any benefit from it because botnets don't have any human interaction capability. So a botnet is not going to benefit very much from a lottery like they would from a mining pool.

This is a good time for experimentation to find out if its theoretically possible to provide disincentives for botnets and incentives for humans.

[bytemaster]

Fast validation times are a requirement.   It is easy to make a memory hard pow that takes too long to verify. 


Sent from my iPhone using Tapatalk

[Sy]

Please, don't compare us with music industry, it has absolutely nothing to do. This is about a business model and how shares could be distributed, not about copyright.

1. We don't want to make it hard for everyone, just for botnets. And this is what this thread is all about.
2. Every good miner gets much less than it could if there were no botnets.
3. Invictus and their supporters get less if they put things easy to botnets.
4. Nobody says nothing against anonimity, but about identity, which is what Keyhotee is all about.
5. This is an idea of Invictus, they are free to impose the rules they want. If you don't like them, don't use the system or fork it.

¿Perhaps you have something to loose so you insist so much about not putting things difficult to botnets?

Na, just more realistic than the others out there who scream botnets are evil and unfair, why waste energy into something you can't change - and if, at any point, it makes it uncomfortable for the user, your main audience, it's not worth it.

[Pocket Sand]

I believe in the methods bytemaster has laid out earlier, for this currency to be decentralized, so does mining. By forcing licenses this currency becomes centralized and that defeats the purpose of DAC.

[phoenix]

I definitely like the idea of restoring the momentum to the POW algorithm. I think the comparison step might be to easy for a GPU, although that might not be a bad thing for the network, as long as it stays ASIC resistant.

[liberman]

Which brings me straight back to my prevous quote - dont make it a pain in the ass.

You guys sound like the music industry and mp3s - just accept that there is a part you can't control and don't make it hard for everyone else - you are not really missing out, every miner still gets the same with or without botnets mining.

This is the internet, you are doomed if you try to control everything - signed mining, seriously? For a currency which greatest benefit has always been anonymity... 

Please, don't compare us with music industry, it has absolutely nothing to do. This is about a business model and how shares could be distributed, not about copyright.

1. We don't want to make it hard for everyone, just for botnets. And this is what this thread is all about.
2. Every good miner gets much less than it could if there were no botnets.
3. Invictus and their supporters get less if they put things easy to botnets.
4. Nobody says nothing against anonimity, but about identity, which is what Keyhotee is all about.
5. This is an idea of Invictus, they are free to impose the rules they want. If you don't like them, don't use the system or fork it.

¿Perhaps you have something to loose so you insist so much about not putting things difficult to botnets?

[Sy]

Which brings me straight back to my prevous quote - dont make it a pain in the ass.

You guys sound like the music industry and mp3s - just accept that there is a part you can't control and don't make it hard for everyone else - you are not really missing out, every miner still gets the same with or without botnets mining.

This is the internet, you are doomed if you try to control everything - signed mining, seriously? For a currency which greatest benefit has always been anonymity... 

[liberman]

Don't be so concerned about botnets and ec2, botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do - this is starting to become a DRM vs warez analogy which always ended bad for the important part, the user / customer. And ec2 is always only a viable option at the beginning, it is not cost effective pretty soon unless you front a serious amount of cash which in turn could have bought rigs aswell - same same but different

EC2 is all right, as you have to pay for it. The only inconvenience is that at the end the money goes to Amazon.
But botnets... how can we accept those? Do we want criminals to be part of our organization?
I don't like the idea of sharing my parts with such people. And the more shares they STEAL, the less we decent people have.

Unless you come up with an idea how to prevent a botcontrolled pc from mining but a normal one not without crippling everything and making the whole process a pain in the ass, thats the way it is and you are just whining because you think something is unfair - welcome to the real world.

I had an idea that I put in the other thread. I just repeat it here:

Why don't you use signed mining?
I mean: to be a miner, you must be aproved by Invictus and recive a key to be able to mine, and any client which tries to mine without being signed cannot find a block. You can also impose limits on the amount one miner can mine.
Then, after the 6 months period, you just release a new version which removes the signing requirement.
You can even sell a license to mine, but please make it cheap.

I don't exactly know how this could be implemented, but I'm sure you can think ways.

And another answer from BitMinerN8:

I also had this idea on my way driving to work this morning. It's great to have so many people thinking about it. I don't have it fully fleshed out either, but I think we can all agree that we don't want it centralized. There needs to be some method of Mining Contracts or Mining DAC's that utilize Keyhotee ID's. Something that tied mining availability, the right to work, to a reward system. This along with difficulty keeps it from spinning out of control.

[Sy]

Don't be so concerned about botnets and ec2, botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do - this is starting to become a DRM vs warez analogy which always ended bad for the important part, the user / customer. And ec2 is always only a viable option at the beginning, it is not cost effective pretty soon unless you front a serious amount of cash which in turn could have bought rigs aswell - same same but different

EC2 is all right, as you have to pay for it. The only inconvenience is that at the end the money goes to Amazon.
But botnets... how can we accept those? Do we want criminals to be part of our organization?
I don't like the idea of sharing my parts with such people. And the more shares they STEAL, the less we decent people have.

Unless you come up with an idea how to prevent a botcontrolled pc from mining but a normal one not without crippling everything and making the whole process a pain in the ass, thats the way it is and you are just whining because you think something is unfair - welcome to the real world.

[liberman]

Don't be so concerned about botnets and ec2, botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do - this is starting to become a DRM vs warez analogy which always ended bad for the important part, the user / customer. And ec2 is always only a viable option at the beginning, it is not cost effective pretty soon unless you front a serious amount of cash which in turn could have bought rigs aswell - same same but different

EC2 is all right, as you have to pay for it. The only inconvenience is that at the end the money goes to Amazon.
But botnets... how can we accept those? Do we want criminals to be part of our organization?
I don't like the idea of sharing my parts with such people. And the more shares they STEAL, the less we decent people have.

[FreeTrade]

botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do

[Sy]

Keep in mind that you usually want a cpu coin to be mineable by everyone, the steps you are taking will reduce your audience to a smaller circle, those with more than 4 GB of RAM and such and yes, there are still ppl with 4 GB and less.

Avoiding GPUs and such is always a good thing, allowing gpus usually pushes out cpus thus shrinking the ppl who can mine even more.

Don't be so concerned about botnets and ec2, botnets were and will always be out there, just accept it, if you got the criminal energy to control a 100k+ botnet you can mine whatever you like no matter what you do - this is starting to become a DRM vs warez analogy which always ended bad for the important part, the user / customer. And ec2 is always only a viable option at the beginning, it is not cost effective pretty soon unless you front a serious amount of cash which in turn could have bought rigs aswell - same same but different

Concentrate on the core, faster retargets for the next one (4032 is really bad) and that maturing time are good.

[FreeTrade]

I'd like to suggest the following POW for consideration -

Step 1.
Generate 1GB-4GB of psuedo random data, maybe SHA512

Step 2.
Find pattern in this data
>Step 2.0 Choose starting byte, say byte 0, use nonce as seed.
>Step 2.1 Load sequential 1-2MB from data into L2 cache from starting byte
>Step 2.2 Perform simple conditional + arithmetic operations on 1-2MB data and seed to provide answer + new seed
>Step 2.3 Use answer at byte start location for next data set.
>Step 2.4 Repeat from 2.1  n times
>Step 2.5 If answer < x, problem solved
>Step 2.6 Choose new starting byte, say byte 1, repeat

Step 1 and 2.3 is designed to require minimum amount of RAM per process
Step 2.1 is designed to obviate any latency advantage of GPU
Step 2.2 is designed to harness the CPU's large L2 cache

The validation will take longer than Momentum 1.0 - as the validating system will need to generate the psuedorandom data used in the solution, maybe 20 or 40MB, but a miner will likely need to generate it all.

[barwizi]

I think 2.0 should be even more memory intensive and have a minimum processing threshold that has a large footprint process. By raising the minimum compute power required to hash we force botnets out of business by making it very noticeable to owners that their computer is being used. Also users of instances will have to hire out more expensive machines which may not give them ROI, i ROI.

with that in mind, let us always remember that there is no such thing as ASIC resistant algo, as long as the market has enough fiat supporting it and a growing requirement for more specialized machinery, one entity will venture to make one. So a more balanced approach should include a distribution plan that evens the curve in a manner beneficial to the community.

[bytemaster]

Would this go along with the vesting period?

Botnets, ASIC, and even to an extent cloud computing should be the overall concern.  If GPU mining provides a < 50% speed boost it still levels the playing field as both CPU and GPU's will get faster with new technology.  Also, most new cpgpu's can do opencl so I do not believe GPU's should be the ultimate enemy, however momentum algorithm may limit their effectiveness which is a plus.

Yes.  The goal was to make minor improvements in every area based upon lessons learned.  I agree that GPUs are not an enemy by themselves unless the reason the GPU successful is because the algorithm is trivial for an ASIC.   I believe this will keep ASICs and GPUs using a large amount of memory.

Any thought on lowering the vesting time period to under 6 months?  45-90 days would be nice 

Vesting is a separate discussion from the proof of work.   Lots of thought, but not sure how to evaluate the different periods so it is not set in stone.

[Brekyrself]

Would this go along with the vesting period?

Botnets, ASIC, and even to an extent cloud computing should be the overall concern.  If GPU mining provides a < 50% speed boost it still levels the playing field as both CPU and GPU's will get faster with new technology.  Also, most new cpgpu's can do opencl so I do not believe GPU's should be the ultimate enemy, however momentum algorithm may limit their effectiveness which is a plus.

Yes.  The goal was to make minor improvements in every area based upon lessons learned.  I agree that GPUs are not an enemy by themselves unless the reason the GPU successful is because the algorithm is trivial for an ASIC.   I believe this will keep ASICs and GPUs using a large amount of memory.

Any thought on lowering the vesting time period to under 6 months?  45-90 days would be nice 

[bytemaster]

Would this go along with the vesting period?

Botnets, ASIC, and even to an extent cloud computing should be the overall concern.  If GPU mining provides a < 50% speed boost it still levels the playing field as both CPU and GPU's will get faster with new technology.  Also, most new cpgpu's can do opencl so I do not believe GPU's should be the ultimate enemy, however momentum algorithm may limit their effectiveness which is a plus.

Yes.  The goal was to make minor improvements in every area based upon lessons learned.  I agree that GPUs are not an enemy by themselves unless the reason the GPU successful is because the algorithm is trivial for an ASIC.   I believe this will keep ASICs and GPUs using a large amount of memory.

[Brekyrself]

Would this go along with the vesting period?

Botnets, ASIC, and even to an extent cloud computing should be the overall concern.  If GPU mining provides a < 50% speed boost it still levels the playing field as both CPU and GPU's will get faster with new technology.  Also, most new cpgpu's can do opencl so I do not believe GPU's should be the ultimate enemy, however momentum algorithm may limit their effectiveness which is a plus.

[bytemaster]

I have been thinking about ways to restore Momentum to a memory-hard problem and have had an insight that I believe changes the game.

Lets define a Birthday to be 1 MB of 'random data' that is relatively expensive to calculate and seeded with a nonce
Lets define a Collision to be the number of bits in common between two random sequences. 
The goal is to produce two nonces such that the number of bits in common between the two 1 MB sequences is above some threshold.
The cost of validation is populating 2 MB of memory, performing an XOR, and then a population count.
Now lets populate the memory with AES which has hardware acceleration on CPU but not GPU

The population of the memory is sequential which helps eliminate memory bus latency and allows the CPU to saturate the BUS.  A GPU would have an advantage in the comparison step because it could compare all birthdays with the new birthday in parallel.    That said, a GPU would be limited in parallelism because it could only store 1000 or 2000 birthdays at a time.   Even so I am not convinced that a GPU implementation would be a bad thing given the other changes we are making.

This proof is slightly harder to validate, but most of the optimization techniques used to accelerate Momentum 1.0 would not scale as well with this system and an ASIC would still require a very large amount of memory.   

What do you all have to say?