[ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine

[enerbyte]

@enerbyte: nice, that looks to be pretty good quality, how did you get it made?

but I like to have the logo in high resolution.

Sorry I was going to upload it before but I forgot about it. Here is the svg vector logo:

mega.co.nz/#!IB4igDiL!i3FDHKRRnFeRMBTYXOlYOgEhHVUAXCqyFg_0J6ePO7A

thanks, I'll update the files soon.

... just have to look for some offline qr code generator....

I've used libqrencode by Fukuchi in the past with good results.  The *nix version is at: http://fukuchi.org/works/qrencode/ and a link to the win32 version can be found on that page under the "BINDINGS and PORTS" section.

thanks for this, here also another   http://larsjung.de/jquery-qrcode/

[enerbyte]

Updated Files!



Donations: CX2XwA94yn2yugPkRaLKnrZx2HWc8RQMAw

[kalon]

Am I understanding this correctly, Basically 1GH is running the Cryptonite network? It looks like that pool solves almost every block. Seems like a nice pool but this strikes me as a big problem.

I know Bitfreak had doubts that p2pool could work with XCN but if there is any technical way (totally above my head) to make it work then that seems like it would be the best solution. I don't understand the technicalities of implementing the system but Cryptonite has seemed much more likely to be able to adopt the more decentralized pooling system (as apposed to Bitcoin) from an end user point of view because the blockchain is so much more manageable.

This pool issue is something which needs to be rectified and I'd hope someone smarter than myself could make that solution be p2pool.

[jwinterm]

Am I understanding this correctly, Basically 1GH is running the Cryptonite network? It looks like that pool solves almost every block. Seems like a nice pool but this strikes me as a big problem.

I know Bitfreak had doubts that p2pool could work with XCN but if there is any technical way (totally above my head) to make it work then that seems like it would be the best solution. I don't understand the technicalities of implementing the system but Cryptonite has seemed much more likely to be able to adopt the more decentralized pooling system (as apposed to Bitcoin) from an end user point of view because the blockchain is so much more manageable.

This pool issue is something which needs to be rectified and I'd hope someone smarter than myself could make that solution be p2pool.

I think maybe part of the issue is that most people use Claymore's GPU miner, and I think maybe that miner only works with 1GH pool.

[Tuck Fheman]

Am I understanding this correctly, Basically 1GH is running the Cryptonite network? It looks like that pool solves almost every block. Seems like a nice pool but this strikes me as a big problem.

I know Bitfreak had doubts that p2pool could work with XCN but if there is any technical way (totally above my head) to make it work then that seems like it would be the best solution. I don't understand the technicalities of implementing the system but Cryptonite has seemed much more likely to be able to adopt the more decentralized pooling system (as apposed to Bitcoin) from an end user point of view because the blockchain is so much more manageable.

This pool issue is something which needs to be rectified and I'd hope someone smarter than myself could make that solution be p2pool.

I think maybe part of the issue is that most people use Claymore's GPU miner, and I think maybe that miner only works with 1GH pool.

v2.1 - Added "nonce-pool.com" pool support.

[bitfreak!]

There are already several pools available, people just seem to prefer 1GH for different reasons. Even if there was a p2pool I'm not sure it would take much away from 1GH.

[cnerd]

Updated Files!

sheesh, man, these look sweet!
Kudos to you!

[kalon]

There are already several pools available, people just seem to prefer 1GH for different reasons. Even if there was a p2pool I'm not sure it would take much away from 1GH.

Perhaps. But it may be more enticing because it would clearly lead to a more decentralized network and if the options there and easy to setup XCN could be the clear winner in this regard since every other network would require full blockchain to do so.

The nice thing about 1GH is that there is no need to setup an account. I too, like this model. There is also the fact that mining on another pool at this point would basically be equivalent to solo mining.

It may not be a problem now that 1GH is running the network but long term viability would require lessening their share. P2pool's benefits would be worth the switch.

[fnxt]

meanwhile this coin has time

[enerbyte]

Updated Files!

sheesh, man, these look sweet!
Kudos to you!

Thanks! 

[AhmedMSedeek]

XCN Faucet Coming soon

www.XCNFaucet.com

[bitfreak!]

@hesky: I didn't write that paper, I only read it 2 days ago myself. I'm not even sure if he would want the paper shared in this thread yet. The way it works doesn't really make it compatible with the existing mini-blockchain scheme. The balances have to be encrypted and lots of complicated math stuff is involved. Here is an email I sent to the author of the paper just a few minutes ago.

I just had a quick read of your paper and I have to say I'm extremely impressed. The math is way over my head but I understand the concept. Me and Catia (our lead developer) had a discussion about your paper on our IRC channel and I thought you'd be interested in hearing our thoughts and conclusions.

Before I start making any criticisms of your proposal I first want to say that's it's probably the best anon cryptocoin scheme I've ever heard of. Overall I think it has more advantages and less disadvantages than any other anon scheme out there, but I still think it could use a little bit of work in some areas.

As I understand it, zero knowledge proofs are quite cpu intensive and large in size, we could be talking several kb to sign a tx. But since we can eventually discard old transactions that's not such a huge deal, and I guess that's one of the reasons the mini-blockchain scheme is suitable for this job.

You also suggest adding multiple new fields to each account, each of which will be quite large. The Paillier encryption key along with the encrypted balance will be quite large. On top of that you also suggest adding the "signature threshold" and the public keys themselves directly into the account structure.

We actually thought about doing that originally but Catia was able to come up with a better way where the keys could be stored in the transactions instead of the accounts themselves. However I'm assuming you were forced to do it that way because you are allowing the user to choose their own account identifier.

We also thought about allowing the user to choose their own account identifier/address because doing it that way lets you unlink the address and the signing keys, so you can update them on the fly. The main issue with that approach is that it requires the account to be created first before it can be used.

You'll basically need to be online and fully synced to create a new account (if your identifier is short you may need to check it doesn't exist first, so you need a full copy of the account tree). And on top of that, if the balances are encrypted, you wont be able to use a block explorer to verify payments.

The one reason I think it would be useful to create new accounts in such a way is to let user pay a fee to decide how long the account will last before being pruned. If the user has to pay a fee at some later time in order to extend the expiry time of their account, why not enforce a fee when creating the account too?

I think it would be a bad idea to allow accounts to be created without a fee, it may lead to some type of DDoS attack. And the default expire time you suggest would be like a free ride, people would just move their coins to a new account before the old one expired. Also, indirect incentive isn't a great incentive.

More troublesome than any of that though, is the problem of deciding how much it costs to store an account in the account tree. Whether you enforce the fee instantly or at some later point in time, it's extremely difficult to come up with a reasonable way to decide what the fee should be.

You've got to remember that the whole purpose of enforcing what we call account "maintenance fees" is to ensure that low balance accounts don't hang around for a long time. So you also need to decide what a "low balance" is, which is difficult because it really dependent on the market value of the coin.

For example 0.1 BTC is a substantial amount of money, but in another cryptocoin 0.1 might be the typical fee because the coin supply is so huge. You also need to remember that over time the value of a coin can change dramatically, so you can't always enforce the same level of maintenance fees.

We've thought long and hard about a mechanism for dynamically determining the value of the maintenance fees but it's quite a hard problem and there doesn't seem to be any perfect solution, which is why we didn't implement anything like this in Cryptonite, it's really not as simple as it first seems to be.

The other thing worth mentioning in relation to the anonymity aspect of your proposal is that the addresses involved in a transaction will not be hidden unless the sender adds in a few hundred random outputs in order to mask where the coins really went, which will cause even more bulkiness in the scheme.

I think the proposed scheme is going to be much bulkier than the mini-blockchain scheme, but that is the cost of anonymity and it cannot be side stepped. But at least in this case a lot of the data can be pruned and forgotten about, which is what makes it superior to other anonymity schemes I've seen before.

The only other potential issue I can see with your proposal is that when you encrypt balances it may be hard to determine whether the coin is still operating properly. We're already forgetting about old transactions, encrypted balances on top of that is heading into the obscure darkness.

To summarize, I really like the anonymity aspect of your proposal, but I think the pruning stuff could really be fleshed out a lot more, you don't seem to talk about it much in the paper. Do you have any plans to implement this idea? It's not really possible to merge the scheme into Cryptonite unfortunately.

[iCEBREAKER]

We've thought long and hard about a mechanism for dynamically determining the value of the maintenance fees but it's quite a hard problem and there doesn't seem to be any perfect solution, which is why we didn't implement anything like this in Cryptonite, it's really not as simple as it first seems to be.

For any scarce resource the proper pricing mechanisms and determinants of allocation are competition based.

When BTC was young, chainspace was cheap and uncontested, so people enjoyed (ab)using it for graffiti, SatoshiDice, etc. while the devs learned invaluable lessons to apply in later versions.

Thus, I'm in favor of erring on the side of being too permissive and possibly suffering DDoS-type attacks, rather than being too restrictive and pricing our intended target demographic of early experimentalist adopters out of the market.

IOW, I feel we should remain in 'Free Demo Mode' until XCN represents a viable value proposition for real usage/investment.

[bitfreak!]

Thus, I'm in favor of erring on the side of being too permissive and possibly suffering DDoS-type attacks, rather than being too restrictive and pricing our intended target demographic of early experimentalist adopters out of the market.

See the whole trick is making sure the fee is low enough that people don't really care about it or notice it, but also make sure it's high enough that it actually does what it is intended to do, which is prune low balance accounts from the account tree within a reasonable period of time. It's especially hard when the value of the coin is constantly changing. What you really need is a way to let miners vote on it, or maybe a PoS type system to let all stakeholders vote on it. We did some thinking along those lines but it's still not a simple problem to solve.

[digicoin]

@bitfreak

You wrote: It's not really possible to merge the scheme into Cryptonite unfortunately

Could you kindly elaborate more about it?

[kishan889]

I always love NO PREMINE coins

Good luck 

[bitfreak!]

@bitfreak

You wrote: It's not really possible to merge the scheme into Cryptonite unfortunately

Could you kindly elaborate more about it?

Well it's pretty obvious if you read the paper. The structure of each account is different, the structure of the transactions is different, the addresses are created differently, etc. The balances themselves are encrypted and you can't just magically encrypt all the Cryptonite balances. There are just too many protocol changes to merge it directly into Cryptonite. I think it's better to make it a separate coin anyway because it will be bulkier than Cryptonite and will have several other disadvantages that Cryptonite doesn't have. You will always find that when using any anon coin there are restrictions and obstacles that make it difficult to use. But in comparison to other anonymity schemes I definitely think this is one of the best.

[iCEBREAKER]

@bitfreak

You wrote: It's not really possible to merge the scheme into Cryptonite unfortunately

Could you kindly elaborate more about it?

Well it's pretty obvious if you read the paper. The structure of each account is different, the structure of the transactions is different, the addresses are created differently, etc. The balances themselves are encrypted and you can't just magically encrypt all the Cryptonite balances. There are just too many protocol changes to merge it directly into Cryptonite. I think it's better to make it a separate coin anyway because it will be bulkier than Cryptonite and will have several other disadvantages that Cryptonite doesn't have. You will always find that when using any anon coin there are restrictions and obstacles that make it difficult to use. But in comparison to other anonymity schemes I definitely think this is one of the best.

Since the new anon version (lets call it Crypto2) is based on XCN, would both coins share enough code to be developed in parallel?

Or would Crypto2 obsolete XCN, and effectively be a hard fork?

*adds XC2 to end of roadmap*

[heskey]

Regarding the account fee, wouldn't it be possible to make it gradually decrease with the block height?
I agree on keeping Cryptonite as it is, anonymity is a great feature, but there are obviously cases where it's a hindrance.

Anyways, very interesting stuff!

[bitfreak!]

Since the new anon version (lets call it Crypto2) is based on XCN, would both coins share enough code to be developed in parallel?

A lot of it is the same so many of the updates we apply to Cryptonite will also be relevant to 'Crypto2', but how it gets developed will depend on who develops it.

Or would Crypto2 obsolete XCN, and effectively be a hard fork?

No, like I said there are very good reasons to have both Cryptonite and an anonymous version of Cryptonite. If you read the email I quoted it should be quite clear what the advantages and disadvantages are.