Topic: [ANN] Pre-Pre-Pre-Announcement (Read 1236 times)
How do you impose a mining limit? I can just buy my uber-miner and send 300khash of its power through some proxy out there.
a coin with mining limit at 300 khash/s max. or 400 ?
yes 400 khash/s max, that's good
yes 400 khash/s max, that's good
scrypt works pretty good...
But any balance will be temporary, as whatever algorithm or technique is used, if it is profitable people will aggregate the appropriate resources.
Exactly. Also, the perceived 'bottlenecks' are usually addressed to some degree by general advances in system architectures, sometimes skewing the distribution further.
'highly multi-faceted mining rig with fast disks, fast processors'
How does that improve conditions for the 'average' users with basic home systems? What you're proposing sounds like a disadvantage to distribution of hashrate.
It scales linearly to a basic home computer.
But any balance will be temporary, as whatever algorithm or technique is used, if it is profitable people will aggregate the appropriate resources.
Exactly. Also, the perceived 'bottlenecks' are usually addressed to some degree by general advances in system architectures, sometimes skewing the distribution further.
The point with my mass PW algo is how pliable it is. As a network matures and miners change, the numbers can change without having to switch algos and potentially fork. Simply changing t would affect how much raw hashing is done in proportion to disk IO (spacing out bursts of disk IO) to not favor massive disk-laden servers but still deny ASICs profitability, or minimizing t would bring it to a disk-laden server.
I'd assume that a value of roughly 31 for t would put today's hashing into the CPU-favored range due to the difficulties of piping data into an openCL kernel. Anything up there would starve an ASIC of hashing input due to lack of fast enough disks to keep up with hundreds-of-gigahash hashing.
That middle ground would effectively require a highly multi-faceted mining rig with fast disks, fast processors, or even specialized high-speed buses for loading data onto a GPU, instead of allowing a specialization of a given component. n essence, it would level the playing field quite a bit.
As for killing off pools, that's a whole other idea I myself am queasy about, though it wouldn't cause massive hashrate drops (instead making them harder to achieve)
I'd assume that a value of roughly 31 for t would put today's hashing into the CPU-favored range due to the difficulties of piping data into an openCL kernel. Anything up there would starve an ASIC of hashing input due to lack of fast enough disks to keep up with hundreds-of-gigahash hashing.
That middle ground would effectively require a highly multi-faceted mining rig with fast disks, fast processors, or even specialized high-speed buses for loading data onto a GPU, instead of allowing a specialization of a given component. n essence, it would level the playing field quite a bit.
As for killing off pools, that's a whole other idea I myself am queasy about, though it wouldn't cause massive hashrate drops (instead making them harder to achieve)
'highly multi-faceted mining rig with fast disks, fast processors'
How does that improve conditions for the 'average' users with basic home systems? What you're proposing sounds like a disadvantage to distribution of hashrate.
Also, I suggest looking into the proposed opencl 2.0 specifications and HSA before going too far with that concept.
make it more beneficial to those who mine using nvidia cards. AMD is now facing scarcity.
You can make the algo an x86 instruction set, or you can use some OpenGL functions as the algo.
That way the ASIC will be x86 CPU or OpenGL graphics chip.
That way the ASIC will be x86 CPU or OpenGL graphics chip.
The point with my mass PW algo is how pliable it is. As a network matures and miners change, the numbers can change without having to switch algos and potentially fork. Simply changing t would affect how much raw hashing is done in proportion to disk IO (spacing out bursts of disk IO) to not favor massive disk-laden servers but still deny ASICs profitability, or minimizing t would bring it to a disk-laden server.
I'd assume that a value of roughly 31 for t would put today's hashing into the CPU-favored range due to the difficulties of piping data into an openCL kernel. Anything up there would starve an ASIC of hashing input due to lack of fast enough disks to keep up with hundreds-of-gigahash hashing.
That middle ground would effectively require a highly multi-faceted mining rig with fast disks, fast processors, or even specialized high-speed buses for loading data onto a GPU, instead of allowing a specialization of a given component. n essence, it would level the playing field quite a bit.
As for killing off pools, that's a whole other idea I myself am queasy about, though it wouldn't cause massive hashrate drops (instead making them harder to achieve)
I'd assume that a value of roughly 31 for t would put today's hashing into the CPU-favored range due to the difficulties of piping data into an openCL kernel. Anything up there would starve an ASIC of hashing input due to lack of fast enough disks to keep up with hundreds-of-gigahash hashing.
That middle ground would effectively require a highly multi-faceted mining rig with fast disks, fast processors, or even specialized high-speed buses for loading data onto a GPU, instead of allowing a specialization of a given component. n essence, it would level the playing field quite a bit.
As for killing off pools, that's a whole other idea I myself am queasy about, though it wouldn't cause massive hashrate drops (instead making them harder to achieve)
Thinking about creating a coin that can be botnet resistant AMD Video card resistant and ASIC resistant. Let's put our minds together and come up with a solution to this!
I'm thinking of making it tie to the amount of clicks you do on your browser but this might be defeated by some progammer who can script the clicks. Hmm.. Let's all stick our head together!
Memory bound proof of work algorithms. MemoryCoin was the first implementation I've seen, with their Momentum PoW algorithm. The problem is that people/"the market" wants to mine with their GPUs etc. but I believe that will fade out eventually.I'm thinking of making it tie to the amount of clicks you do on your browser but this might be defeated by some progammer who can script the clicks. Hmm.. Let's all stick our head together!
There are other memory bound functions that are worth looking into, and I'm working with one for my longer term project. The trick is striking a balance so mining is achievable, while leveling the playing field so everyone has a reasonable opportunity to participate. But going for more distributed hash-power density is a complex issue.
But any balance will be temporary, as whatever algorithm or technique is used, if it is profitable people will aggregate the appropriate resources. Just as all the GPUs are sold out everywhere now, and people have built GPU farms and ASIC farms, if you do an algorithm that favors memory or some other factor people will eventually start building monster rigs optimized for it.
Quote from: rarkenin
and you kill off centralized pools.
But this is also a case of "be careful what you wish for". Another area to maybe look into is difficulty allocation.
I actually wrote up a proposal for a mining algo that can be configured and tweaked (even as a coin runs, similar to difficulty) to be 99% dependent on hard disk/SSD speed, to just being disk-intensive enough to make ASICs (and potenially GPUs) unprofitable/unworkable, depending on the t value (As specified in the proposal)
Tell me what you think!
Edit: Couple that with small generation transactions in blocks and you kill off centralized pools. The link is to an old altcoin I abandoned due to lack of knowledge of the c language(I'm really a Java guy)
Tell me what you think!
Edit: Couple that with small generation transactions in blocks and you kill off centralized pools. The link is to an old altcoin I abandoned due to lack of knowledge of the c language(I'm really a Java guy)
I'd prefer a completely mining resistant coin. They'd be so valuable.
+1 This. 
Pay more tax on larger transactions?
Pay more tax as you mine larger amounts of coins?
This could then be bypassed by launching miners to several different wallets. Then sending it all to a single wallet.
Pay more tax as you mine larger amounts of coins?
This could then be bypassed by launching miners to several different wallets. Then sending it all to a single wallet.
oh i got it! How about you mine by going to work everyday and then your employer gives you coins?!!
as long as they worked for Fiat...
Might as well make a coin that you travel around the world and scatter by hand, requiring a pickax and a shovel to mine.
I have a great idea... how about the person will need to actually work to proof he deserves a payment ?
I'd prefer a completely mining resistant coin. They'd be so valuable.
Thinking about creating a coin that can be botnet resistant AMD Video card resistant and ASIC resistant. Let's put our minds together and come up with a solution to this!
I'm thinking of making it tie to the amount of clicks you do on your browser but this might be defeated by some progammer who can script the clicks. Hmm.. Let's all stick our head together!
I'm thinking of making it tie to the amount of clicks you do on your browser but this might be defeated by some progammer who can script the clicks. Hmm.. Let's all stick our head together!
Jump to: