Topic: [ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine - page 47. (Read 578565 times)

Nice and simple. I tested it and seems to work fine, limited at 1 use per hour.
I'd be cheeky to say that it's not paying much (0.0000001), but I know you'll just tell me to donate some 

I know you're having an important topic now to discuss, but this is supposed to be an addition to the coin

XCN Faucet is NOW Online!!

www.XCNFaucet.com

Since the coin value supposedly will start low and increase with time.

^ I realize that it's a bit distasteful to presuppose that the value will increase. Probably bad omen as well.

Well sure, but what would be the goal of that? I don't see why that would be useful.

Regarding the account fee, wouldn't it be possible to make it gradually decrease with the block height?

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?

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.

@bitfreak

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

Could you kindly elaborate more about it?

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.

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.

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.

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