What makes you assume that?

It is possible but becomes harder and less profitable for almost all coins as time goes on.

Contacted OP directly using PM and email.

They don't have the power to. It's not centralized around them. Only miner consensus would result in that.

I strongly oppose a lock on the thread as I have an entry already nearly finished that I've put time into. I would rather risk this not being trustworthy directly over this being locked with our submission nearly complete.

Really? I've never seen it before. I took a look, and while I like what I see there, I do agree that it fills a specified niche, though this aims to take it farther (though in a more brute-forcey approach, I must admit).

BAGSGHOST: You haven't specified a bit about what you want your coin to be or how you want it configured.

This is just a cheap way for someone to get money off an idiotic market with all of those extra fee options.

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.

Have you looked into allowing Google Voice accounts to also help? A lot of people have accounts already in use and good standing so an API would help finish bridging this gap.

How are you getting details about available input scripts to the offline machine? Does it have its own camera to receive this data?

Reserved for a quick review or potential entry

I'm working with the devs a bit on this. We planned to stick an nLockTime on the premine but that was hampered by how coinbase transactions are processed. If anything, the premined coins can be tracked in the blockchain.

With that said, I've been around less than a week so I barely know what is going on.

Edit: Aaand, I can't even get my copy of the client connected. Sorry, other devs. I don't know what's going on, and the premine was never secured.

Coins can adapt to that. The network can set its parameters thus. Say someone designed an on-die FPU that could crunch modulos instantly or perform large decimal exponentiation much more rapidly than before. The parameters are adjusted to favor stage 1. Likewise for a potential on-die hash acclerator.


It scales linearly to a basic home computer.

NASTY VIRUS

Did a decompile and  analysis in a VM, looks very nasty. Disables UAC, downloads a remote access tool, and even crashes my decompiler due to obfuscation. Obviously very complex but also not too polished, debug statements printing to console remain.

PM me to get details about all of the source and a copy of the decompiled/original files, some of which are not directly accessible. I'll send it in a passworded ZIP, but once I send it to you it's YOUR responsibility not to run it.

SCAM BY EFFECTIVE PREMINE

I can't download the wallet, since the host derped. This is clearly a limited-opening scam as the download link goes down after activity so only the first certain number of users actually managed to download it. Find a good host and restart the coin.

I ended up writing up an early test implementation in Java, and posted it as a gist. Note that it differs from the original post in some aspects.

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)

Then take what I followed with from the second part of my post. Whether the creator, as a judgment call, decides that their coin's goal is to be novelty. Though I'm not sure if te honor system really works here well. I do have to agree, the volume in the existing forum is too much for easy handling. At least coin releases should be moved off to a sub-forum and discussion remains.

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)