[ANN] Nome Coin

[minerva]

changes italicized

ETA: based on my current rate of output, heat death of universe

Proof-of-work algorithm:

The block header is hashed with Keccak[r=1416,c=184] with 8192 bits (1 kibibyte) of output. Using a sequential memory-hard function, the previous hash is hashed again, repeatedly until it is hashed ((1.04^(months past first block))*1.5*difficulty) (rounded down) times. The block headers are then hashed again with Keccak[r=1088,c=512] with 256 bits of output. The previous hash outputs are then collectively hashed using Keccak[r=1344,c=256] with 256 bits of output. In order for the hash to be accepted, it must have an equal or greater number of leading zeroes then the difficulty target.

The intent is simple, to make this ASIC resistant (no one can determine the precise amount of memory needed for an ASIC miner, and thus some chip space will be underutilized), and to be within the cache limits of a CPU to allow mobile devices to still be able to confirm blocks.

Block reward and block difficulty will be retargeted every 660 blocks. The difficulty will target generating a new block every 15 minutes. The block reward will be targeted to equal 200*(difficulty-minimum_difficulty) coins per block.

This is meant to stabilize prices and incentive miners to mine, an increase in economic security (through an increase in liquidity) and an increase in computational security.

Block difficulty is the count of the required number of leading zero bits for a hash. While this decreases precision, it is unlikely for this to matter significantly. It is also unlikely that the distribution of outputs with most pseudorandom functions immune to preimage attacks to be 100% uniformly distributed. This of course means that the average block will be generated between 10 minutes and 22.5 minutes, but averages are a fiction anyway, since it can take between a millisecond and a day for a block to be generated for any cryptocoin.

Block header contains only block number, 8-byte nonce, and merkle root. Version, previous hash, difficulty, timestamp, extranonce, and transactions are located within the merkle root. The difficulty is a one-byte value.

Block fees will be charged per byte of a block, however the first kilobyte for a block is free (the block header and first transaction ought to be free). Block fees will be sent to an invalid address, this is a “fee” that is effectively “collected” by the entire “community” to avoid miners or other entities from causing a tragedy of the commons by spamming the blockchain with either data or dust transactions. It’s conceivable that in the future cryptocoins which round up to the nearest kibibyte will result in people using the spare room in their transactions to upload a book byte by byte. Block fees will be 0.002 coins per byte, although in the beginning block fees are too insignificant to matter. For every additional megabyte, marginal block fees per byte doubles.

The first 67,500 blocks may not be larger than one megabyte to prevent blockchain spam. The first 200,000 blocks may not be larger than two megabytes for the same reason.

Transaction fees will be a means for miners to make profit and to pay off block fees. Transactions fees could be at minimum 0.002 coins per byte.

Smallest coin size will be 0.0001.

Transactions in a future version should include data. It is wrong restricting the ability to add data to the blockchain to miners.

Sanity check for maximum transaction or maximum coins per block is 66000*difficulty.

Terminology will be changed. Wallets for this coin will be “password managers,” and each private key is a “password.” This is more accessible to relative laymen and might prevent certain forms of confusion. It is doubtable an absolute layman will ever be able to truly access a cryptocoin without an online wallet.

The client will ideally include a way to open a bootstrap file, instead of manually navigating through folders and moving files around. The bootstrap file extension should be changed to “.ledger”.


Future plans: Restrict stored transactions per public key to 1 until a block includes the transaction. Delete transactions stored after a week.

[Mylo]

Shit man, you need a read a vocabulary, not a new coin.

[minerva]

Shit man, you need a read a vocabulary, not a new coin.

perhaps

but I don't believe in buying cryptocoins.

I'm just putting forward my two cents as to the ideal cryptocoin.

[n00bnoxious]

You know what: This is the only coin I've seen in a very long time that's almost entirely innovation. Keep on with it, because the number of liteclones and dogeclones out there is getting out of control - finding people with actual brains is not an easy job!

And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.

Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.

[peterlustig]

Shit man, you need a read a vocabulary, not a new coin.

You need some manners. Also complaining about OP's perfect grammar while not being able to write a proper sentence, btctalk at it's best/worst...

@OP: Glad to see someone actually thinking about his new coin. Good luck.

[minerva]

Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.

1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.

I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).

[Mylo]

Shit man, you need a read a vocabulary, not a new coin.

You need some manners. Also complaining about OP's perfect grammar while not being able to write a proper sentence, btctalk at it's best/worst...

@OP: Glad to see someone actually thinking about his new coin. Good luck.

I'll give you a favour today my dear, I'll teach you two new words: Sar Casm. You can google the rest.
P.S. I bolded out the favourite part you liked most in my first message, enjoy x2.

All the best of luck to topic starter, looks like he isn't a dev but needs one.

[decanus21]

Sarcasm, be it in two words or one, just doesn't work on the internet  

[peterlustig]

I'll give you a favour today my dear, I'll teach you two new words: Sar Casm. You can google the rest.
P.S. I bolded out the favourite part you liked most in my first message, enjoy x2.

All the best of luck to topic starter, looks like he isn't a dev but needs one.

Forgot the sarcasm tags there. Frankly, there are so many morons and trolls in this board I actually thought you were serious. 

[n00bnoxious]

Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.

1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.

I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).

How do you suggest that miners agree to reject blocks based on their non-chain-specific content? This would require the manual intervention of "the majority" of miners wouldn't it?

If you need a dev to start looking at it with you I may be able to provide *some* hours. Can't guarantee a huge number as the number of projects I'm working on gets longer every day, but I'm intrigued by the intellectual concept. I'm also interested to explore the idea of developing a coin that ISN'T centred around pumping/dumping. I'm utterly sick of all the liteclones. Almost none of them has innovated anything, and I'm fairly certain the level of saturation is seriously damaging the entire community. I've even heard tell that the saturation may be deliberate in order to damage the market, although I take that with a pinch of tinfoil.

For these reasons, I'm backing Darkcoin as a technological leader, and Cypherfunk as a personal interest project as they both bring something new and interesting to their target demographic, and have both very quickly gained a great following, both of which communities are active, strong and very long-term focussed. If you can achieve the majority of what you've set out in the brief above I can see this coin gaining serious traction.

[minerva]

Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.

1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.

I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).

How do you suggest that miners agree to reject blocks based on their non-chain-specific content? This would require the manual intervention of "the majority" of miners wouldn't it?

If you need a dev to start looking at it with you I may be able to provide *some* hours. Can't guarantee a huge number as the number of projects I'm working on gets longer every day, but I'm intrigued by the intellectual concept. I'm also interested to explore the idea of developing a coin that ISN'T centred around pumping/dumping. I'm utterly sick of all the liteclones. Almost none of them has innovated anything, and I'm fairly certain the level of saturation is seriously damaging the entire community. I've even heard tell that the saturation may be deliberate in order to damage the market, although I take that with a pinch of tinfoil.

For these reasons, I'm backing Darkcoin as a technological leader, and Cypherfunk as a personal interest project as they both bring something new and interesting to their target demographic, and have both very quickly gained a great following, both of which communities are active, strong and very long-term focussed. If you can achieve the majority of what you've set out in the brief above I can see this coin gaining serious traction.

No, just a majority intervention of a majority of pools.

Problem with Darkcoin is with encrypted block chain... how can you trust it? What if there was a bug, and you can't see someone printing billions of coins? Such an issue happened in the early days of Bitcoin. Bitcoin is founded on the absolute minimum of trust. Minimum of trust of miners, minimum of trust of programmers, etc.

What these liteclones fail to realize is that if you don't use a new method of mining, people with established GPU infrastructure will quickly kill it. You need to change the hashing method to something new to restrict it to CPU mining for the first few weeks.


I welcome any assistance.


Minor note: I'm changing the name of this coin from Unnamed Coin to Nome Coin.

All the best of luck to topic starter, looks like he isn't a dev but needs one.

[vandokkum]

Just do it.

[n00bnoxious]

Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.

1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.

I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).

How do you suggest that miners agree to reject blocks based on their non-chain-specific content? This would require the manual intervention of "the majority" of miners wouldn't it?

If you need a dev to start looking at it with you I may be able to provide *some* hours. Can't guarantee a huge number as the number of projects I'm working on gets longer every day, but I'm intrigued by the intellectual concept. I'm also interested to explore the idea of developing a coin that ISN'T centred around pumping/dumping. I'm utterly sick of all the liteclones. Almost none of them has innovated anything, and I'm fairly certain the level of saturation is seriously damaging the entire community. I've even heard tell that the saturation may be deliberate in order to damage the market, although I take that with a pinch of tinfoil.

For these reasons, I'm backing Darkcoin as a technological leader, and Cypherfunk as a personal interest project as they both bring something new and interesting to their target demographic, and have both very quickly gained a great following, both of which communities are active, strong and very long-term focussed. If you can achieve the majority of what you've set out in the brief above I can see this coin gaining serious traction.

No, just a majority intervention of a majority of pools.

Problem with Darkcoin is with encrypted block chain... how can you trust it? What if there was a bug, and you can't see someone printing billions of coins? Such an issue happened in the early days of Bitcoin. Bitcoin is founded on the absolute minimum of trust. Minimum of trust of miners, minimum of trust of programmers, etc.

What these liteclones fail to realize is that if you don't use a new method of mining, people with established GPU infrastructure will quickly kill it. You need to change the hashing method to something new to restrict it to CPU mining for the first few weeks.


I welcome any assistance.


Minor note: I'm changing the name of this coin from Unnamed Coin to Nome Coin.

All the best of luck to topic starter, looks like he isn't a dev but needs one.

Darkcoin doesn't have an encrypted blockchain. There is a plan for fully encrypted individual transactions, but that's not been implemented yet. Darksend (coinjoin implementation) is almost released, but still technically in Beta, and is going through extensive testing before being released.

I agree with you on the front of the liteclone algo issue. I don't think any of the devs realise what the release of ASICs is going to do. PM me if you'd like help with anything related to the coin. I'm more than happy to invest in a long-term project that goes against all the pump/dump principles that seem to have taken over the entire crypto community.

[minerva]

Just do it.

well, in the past week I've downloaded winmerge and grepWin. I can't say I'm familiar with C but I can read it. (I'm a typical altcoin developer from the looks of it, not that Bitcoin or Dogecoin devs made multiple bad commits in the past)

It appears in order to create a new coin, I'll have to change various checkpoint and genesis block parameters around. Uncertain fully of the tasks required. I will likely release the code for public comment before releasing the client, and to counteract anyone from premining, I'll probably mine the first block and change the genesis block in the client (as well as the magic number).


I'm altering the original post in the next thirty minutes to simplify some things, and to explain my thoughts on hashes/pseudorandom number generators, as well as future plans with the coin.

I don't think any of the devs realise what the release of ASICs is going to do.

ASICs are a mixed blessing, they increase and decrease network security, they increase barrier to entry, and threaten the cryptocoin with a 51% attack by a sufficiently wealthy entity. Problem with litecoin is they had specific values for scrypt from the very beginning. Changing it will wreak havoc and encourage secret ASIC mining, unless the plan for changes is a year ahead of time and done in a slow transparent process.

Whatever formulas I make up, they need to be close enough to being adequate or correct now or before market capitalization reaches dogecoin proportions.Naturally I welcome any help, but I'm not quite sure what I should specifically request.

[n00bnoxious]

Just do it.

well, in the past week I've downloaded winmerge and grepWin. I can't say I'm familiar with C but I can read it. (I'm a typical altcoin developer from the looks of it, not that Bitcoin or Dogecoin devs made multiple bad commits in the past)

It appears in order to create a new coin, I'll have to change various checkpoint and genesis block parameters around. Uncertain fully of the tasks required. I will likely release the code for public comment before releasing the client, and to counteract anyone from premining, I'll probably mine the first block and change the genesis block in the client (as well as the magic number).


I'm altering the original post in the next thirty minutes to simplify some things, and to explain my thoughts on hashes/pseudorandom number generators, as well as future plans with the coin.

I don't think any of the devs realise what the release of ASICs is going to do.

ASICs are a mixed blessing, they increase and decrease network security, they increase barrier to entry, and threaten the cryptocoin with a 51% attack by a sufficiently wealthy entity. Problem with litecoin is they had specific values for scrypt from the very beginning. Changing it will wreak havoc and encourage secret ASIC mining, unless the plan for changes is a year ahead of time and done in a slow transparent process.

Whatever formulas I make up, they need to be close enough to being adequate or correct now or before market capitalization reaches dogecoin proportions.Naturally I welcome any help, but I'm not quite sure what I should specifically request.

Sounds like a fairly reasonable plan. Having experienced the DRK hardfork well after release, it was a bit of a mess and caused quite a few miners and users problems.

I'm not sure that every 660 blocks is small enough for your retarget - it's important to protect against multipool hopping, or whale attack. That can screw all your miners very quickly. All it takes is somebody to point a botnet at a pool and you've suddenly got 100MH+ that will most likely disappear as soon as the diff goes up, leaving all the rest of the miners with a stupidly high diff until the next 660 blocks have passed. You may want to look at DarkGravityWave (WIP, but looks almost 100%), or HeavyCoin's temporal retargeting. Both are max one-block retargets, and HVC's even starts retargeting before the previous block is finished. Better to get that stuff in before you start - hard forking later is a painful experience.

I have a fair bit of experience in C, C++ and Qt (amongst others) so hopefully will be able to provide some kind of sensible help for you. Fire me a message when you get a better idea of what's going to be required and I'll see where my skills fit best.

[UnNamedCoin]

Sorry you had to change the name.
I hope it wasn't on my account