Topic: How do you create an altcoin? (Read 21879 times)

Just register as issuer on icoinhost.org and we will create your 10 million altcoin for free

Is it so easy?

I will create a windows binary and a mac if I can. Im just editing files on debian.

I've been wondering this too as I'd like to create an alt-coin but with the intention of trialing out an innovation (application wise not technical as I want it to be SHA based so I can run tests on mining it without wasting electricity by using my Ant Miner U1 ASIC instead of my PCs GPU) to see if a theory I have is right or wrong.I don't plan to release it as I understand that releasing 'premined' coins is heavily frowned upon so will need to start fresh (with a new copy) after the tests are over if I plan to release it to the public.

I'd like a clear and easy to understand guide on how to modify the parameters in the code including links to source code and other things necessary to make this happen as I thought I have a theory to try out something (can't disclose it here yet as releasing an untested idea for an alt-coin is unfair to push onto the public.It's best to get as many issues ironed out first as I've seen so many alt-coins based on cloning ideas with a different look/setup,that I'm fedup of seeing anymore alt-coins without offering something of interest/use/worthwhile)

Thanks

can you make it happen? PM me if you want to make such alt-coin. I'll help you promo

From me

Oh ok

I have a feeling I'm going to regret this, but it's been made

Here

bum bum bum bum bump 

One thing you should have is a solid mathematical foundation.

You should be able to at least calculate an estimated network propagation time for transactions and how that relates to block generation. If that's not taken care of, not only will orphan rates be insanely high, but the whole network could be vulnerable to a 51% attack, forking, local net farming, and a lot of other horrible deaths.

bump... 

A few ideas that spring to mind are:

- Set a maximum upper bound on the hashrate for a single entity and/or pool.

- Modify difficulty in a logarithmic manner, so someone hashing at 300Mh/s will only be seeing double the benefit of someone hashing at 30Mh/s.

- Adopt a proof of stake system (or hybrid PoS/PoW). This sounds somewhat similar to PPCoin in the sense that it is "green" and depends less on raw hashing power.




Of course, none of these ideas are perfect; my big concern with the first two is they will make botnets incredibly powerful when mining this currency. These are just some debate-spawning ideas to consider off the top of my head.

This all sounded do-able until you got to the part about how much money someone's computer cost.

For one thing if someone chooses to throw money at the problem of acquiring coin, they will almost certainly succeed in acquiring coin, even if they end up buying it over the counter due to the coin not being on any exchanges.

So trying to prevent money from being an effective means of acquiring coin seems somewhat doomed from the outset.

Merely making a system that is very very low in resource-consumption as compared to "proof of work" based systems is easy. Ripple, for example, seems to have solved that problem. We have but to wait for the Ripple server source code to be released and we are ready to produce as many eco-friendly financial networks as we have server-hardware to run them on.

Pure proof of stake also could be a reasonably eco-friendly approach.

The "Decrits" system is probably worth studying too, however it still does deliberately burn energy as part of its economic model or economic checks and balances.

Yet another compromise approach is to continue to use proof of work like bitcoin does for securing the chain but do not use it for distributing coins. Instead of having people use hashing to obtain "coins other than transaction fees", have them use scripts and/or human interaction to initially acquire coins.

We have been testing for some time now methods of dispensing coins that would indeed work just as well for a raspberry pi as for a powerful expensive laptop on a "worker" by "worker" basis.

The current implementation however  makes no attempt to limit the number of "workers" run by a single computer or a single owner of computers or user of computers or hijacker of innocent bystanders' computers.

Rather the opposite in fact: it envisions that the more time a human being has available to personally supervise "workers" the more earnings that human would be likely to reap.

That is, we do not merely aim at making the problem(s) involved in obtaining coins be problems that CPUs are far more likely to be good at than GPUs; we go even farther, allowing the problems to be such that in some respects human beings might well be better in some ways and/or in some situations at solving some of the problems than CPUs are.

Our testing so far indicates that the more "workers" a human deploys, the more of some human's or humans' time (the human of the first part of this clause or one or more other humans acting on behalf of that human) is likely to be consumed.

So far this is partly simply a reflection of the current state of the art of "worker" software:

The problems are more suitable to CPUs than to GPUs due not to any intrinsic resistance to parallelisation but, rather, to what one might term "the human element". Ultimately "the human element" should tend more and more to be the programmers of the "workers", but until such programmers have developed the start of the art of "worker" software to a point where there no longer exists any situation that that software does not elegantly handle and even, possibly, turn to its advantage, there is and will be occasional need for a human to restart a "worker" or even to reprogram a "worker" so it will in future elegantly handle the situation that had led to the need for human intervention.

Thus it currently seems likely that botnet "workers" will tend overall to work less effectively than "workers" who are members of a group of workers whose human supervisor to number of workers ratio is better. (Thus also the larger the botnet controlled by a single human, the less effective that botnet's "workers" tend to be.)

So far it is looking very promising, but that part way up above about money being or not being an issue is still present because it costs money to provide connections and problems for "workers" so more workers is more expensive than less workers so botnet operators need to be able to afford worker accounts for all of their workers, they cannot just deploy millions of workers they have to also obtain worker accounts for those workers to connect to.

-MarkM-

For those who want something to work on while GARR22 comes out with his guide:

Here's a pseudo guide that points to threads that help with certain pieces of altcoin creation:
https://bitcointalksearch.org/topic/a-psuedo-guide-on-how-to-build-an-altcoin-help-fill-in-gaps-193025

I would be interested in creating an "ecocoin" geared towards solo CPU miners (and penalize or prevent other forms of mining).


What are some ways of rewarding solo miners and discouraging or even preventing pools?
Any way to force CPU mining instead of GPU (and certainly not ASIC)?
Would it be possible to reward miners MORE for using less computing power somehow?
Any way to prevent people from owning/running more than one miner?

Ideally I'd want to control it so that the average person mining on a Raspberry Pi (for example) can earn around 3 ecocoins per 24 hours of mining.

Does everyone see where I'm headed with this? The idea is that:
1) It doesn't hog electricity.
2) If you own a Raspberry Pi or something like that, you earn as much in a day from mining as someone who owns a $10,000 computer.

Awesome looking forward to it!

Oh well then as long as we're bumping I'll just bumplink this:

https://bitcointalksearch.org/topic/ann-new-alt-coin-generator-197598

-MarkM-

I too shall bump this.

Don't mind me, just bumping

achillez: just start one (daemon or qt) in server mode, and start another one to connect to it. Once connected, you can start mining. It's really simple, but took me a day to figure it out.

Alexmerced: you get hash and merle root from the debug log. See my explanation in the previous message.