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

[bitfreak!]

I installed the latest Cryptonite-qt this morning. It seems to run fine, no crashes, but the progress bar says "7 days behind".

Yes it's a common issue, usually fixed by doing a resync or adding more peers. The best way to sync is to use cryptonited instead of qt because it's much more stable. Another thing to try is to connect only to our seed node (206.72.193.148) while syncing, that worked for another person experiencing the same issue recently.

[kalon]

Couple things I've noticed which seem like items to be fixed in the qt client:

1. When clicking on a transaction to get details, the from field always shows 'unknown', though the information is certainly obtainable and is listed in the block explorer.
2. In payment requests, the balloon for the message field states that the message will appear when opened by the recipient's client but will not be sent with the payment. This does not appear to be true since I can't see where it's encoded. Also, why wouldn't it auto fill the message field in the recipient's payment screen? It could be useful for returning confirmation codes to prove a particular customer has a payment. However, wouldn't it also be better if the message was encrypted so that only the payment recipient could read it?

One last one, There doesn't seem to be any qr codes. They're intended to be added to the next release right?

[fiatpete]

In the last couple of days my qt client on win7 64bit is having problems syncing up. Has the number of full nodes dropped or am I just unlucky? Its also prone to crash since I did a resync.
On the first issue could XCN pay for full nodes in the way it pays for miners? So say every 2000 blocks it could divide a special reward of XCN to all full nodes which have been up since the last reward. This would keep the number of full nodes from dropping as in other coins like BTC. This reminds me, the CPU utilization is much higher than my blackcoin wallet even when it's staking. I assume this is either a coding issue or the M7 PoW lacks the 'ease of verification' which sha256 has? This could cause scalability issues later.
On the 2nd issue could we have an install and uninstall option or put all the config setting in a config file in the cryptonite directory rather than filling up the registry.
It's a very interesting coin which certainly fixes some of the major issues with bitcoin. Imagine being able to run a full node with no third party involved on your smartphone. But it needs to stay flexible to fix other issues as everything needs to be right for a small coin to stand a chance.

[Travis9x]

Is there any TODO list for this project?

The current development roadmap looks something like this:

1. web wallet improvement
  - create variant of wallet with client side encryption
  - add more extensive multi-sig transaction tools
2. block explorer improvement
  - add list of pruned blocks
  - add charts and more info
3. "slice sharing" optimization
4. bug squishing (eg wallet corruption, syncing issues)
5. consider move to rpc wallet
6. add chain pruning command
7. block mixing, side chains, etc

With the sheer number of people having wallet corruption and syncing issues (about half the posts in this thread seem to be about just that), I'd think #4 Bug Squishing should be bumped up to the #1 slot.  I'm sure there are a LOT of people who get quickly turned off from XCN after their wallet gets corrupted in the first day or two (before they get around to making a backup), and lose all their coins…people who would otherwise have become Cryptonite advocates.

[bitfreak!]

1. When clicking on a transaction to get details, the from field always shows 'unknown', though the information is certainly obtainable and is listed in the block explorer.

Yeah that should be easy to fix, but small Qt issues like that are not high on our list of priorities. We may still ditch Qt in favor of an RPC based wallet.

2. In payment requests, the balloon for the message field states that the message will appear when opened by the recipient's client but will not be sent with the payment. This does not appear to be true since I can't see where it's encoded.

The balloon text is from Bitcoin but it should still apply to Cryptonite. That payment request stuff creates a cryptonite URI, but you are right it doesn't appear to encode the message in the URI. I think that bug probably exists in bitcoin too.

Also, why wouldn't it auto fill the message field in the recipient's payment screen? It could be useful for returning confirmation codes to prove a particular customer has a payment.

Well I guess it's supposed to be a message from the payee to the payer, not necessarily something that the payee wants to have included in the transaction. But you are right it could be useful as a way to verify payments from specific customers.

However, wouldn't it also be better if the message was encrypted so that only the payment recipient could read it?

The payment recipient (aka payee) is the one who created the URI in the first place, why would he/she want to send an encrypted message to themselves? If you're simply asking why can't the messages be encrypted, of course they can if the payer knows the full public key of the payee then he/she can encrypt the message using that public key, meaning only the payee with the private key can decrypt it. But the payer can only get the full public key if it has been used to sign transactions in the past or if it's given to the payer by the payee.

One last one, There doesn't seem to be any qr codes. They're intended to be added to the next release right?

I believe that's just because the build you're using doesn't have those features enabled. You need to have the libqrencode library installed when building to make the QR code stuff work.

[bitfreak!]

With the sheer number of people having wallet corruption and syncing issues (about half the posts in this thread seem to be about just that), I'd think #4 Bug Squishing should be bumped up to the #1 slot.  I'm sure there are a LOT of people who get quickly turned off from XCN after their wallet gets corrupted in the first day or two (before they get around to making a backup), and lose all their coins…people who would otherwise have become Cryptonite advocates.

Well #1 and #2 are web development things that I work on, where as #3 and #4 are core code jobs which catia works on. Although catia hasn't been able to do much work on Cryptonite lately so I'm not sure how long it will take him to get around to those issues, which is why I placed them further down the list. But you are right it's important to fix those corruption issues, it's just so hard to debug these Qt issues. One of the main reasons we are considering ditching Qt and moving over to an RPC wallet is because Qt is such a pain in the ass to debug and catia doesn't use Windows, which makes it even harder. Also keep in mind that it's very easy to backup your wallet file and/or your private keys, so even if your wallet file gets corrupted you wont lose your coins. The corruption doesn't just randomly occur either, it will only happen if you shut down Qt while it's syncing, but that's necessary some times if it wont sync.

[bitfreak!]

In the last couple of days my qt client on win7 64bit is having problems syncing up. Has the number of full nodes dropped or am I just unlucky? Its also prone to crash since I did a resync.

It seems like an old miner has been running for a few days because it looks like there is an old fork being mined or something and I suspect that is contributing to the recent sync problems which several people other than yourself have reported. Just follow the suggestions I gave a few posts ago.

On the first issue could XCN pay for full nodes in the way it pays for miners? So say every 2000 blocks it could divide a special reward of XCN to all full nodes which have been up since the last reward. This would keep the number of full nodes from dropping as in other coins like BTC.

That's actually a decent idea but it's more complicated than it sounds, you need to develop a protocol for proving who is a seed node and how long they've been online. You also need a way to ensure that they are actually seeding other nodes with legit data. Then you need to alter the protocol to allow those types of special rewards to be accepted by the network. Not simple at all, but it is a good idea.

This reminds me, the CPU utilization is much higher than my blackcoin wallet even when it's staking. I assume this is either a coding issue or the M7 PoW lacks the 'ease of verification' which sha256 has? This could cause scalability issues later.

I'm unsure what you mean. Cryptonite doesn't use PoS, it's purely PoW. So if you're CPU mining than your CPU usage should be 100%, else you're not taking full advantage of your CPU.

On the 2nd issue could we have an install and uninstall option or put all the config setting in a config file in the cryptonite directory rather than filling up the registry.

The registry changes only happen if you're using Windows, I'm not entirely sure why, but the same thing happens with Bitcoin.

[fiatpete]

In the last couple of days my qt client on win7 64bit is having problems syncing up. Has the number of full nodes dropped or am I just unlucky? Its also prone to crash since I did a resync.

It seems like an old miner has been running for a few days because it looks like there is an old fork being mined or something and I suspect that is contributing to the recent sync problems which several people other than yourself have reported. Just follow the suggestions I gave a few posts ago.

I've been running 'addnode 206.72.193.148 add' which sometimes helps but it still takes a long time to get any peers. Are there any other known good peers that people can use?
Looking in debug.log I'm getting a lot of the below messages for different peers. Have I ended up on the wrong fork?
2014-11-13 10:08:07 ERROR: AcceptBlockHeader() : extended invalid chain
2014-11-13 10:08:07 ERROR: ProcessBlockHeader() : AcceptBlockHeader FAILED
2014-11-13 10:08:07 Misbehaving: 58.20.250.60:8253 (0 -> 100) BAN THRESHOLD EXCEEDED

On the first issue could XCN pay for full nodes in the way it pays for miners? So say every 2000 blocks it could divide a special reward of XCN to all full nodes which have been up since the last reward. This would keep the number of full nodes from dropping as in other coins like BTC.

That's actually a decent idea but it's more complicated than it sounds, you need to develop a protocol for proving who is a seed node and how long they've been online. You also need a way to ensure that they are actually seeding other nodes with legit data. Then you need to alter the protocol to allow those types of special rewards to be accepted by the network. Not simple at all, but it is a good idea.

Yeah I realize it would be difficult to implement in a way which couldn't be cheated, it was something to think about to avoid the situation most coins have where all the coins go to the miners and none for the nodes or devs. Would people object if the protocol was changed so a percentage of the transaction fee went to a dev fund to pay for code improvements?

This reminds me, the CPU utilization is much higher than my blackcoin wallet even when it's staking. I assume this is either a coding issue or the M7 PoW lacks the 'ease of verification' which sha256 has? This could cause scalability issues later.

I'm unsure what you mean. Cryptonite doesn't use PoS, it's purely PoW. So if you're CPU mining than your CPU usage should be 100%, else you're not taking full advantage of your CPU.

Sorry I should have been clearer, when win64_cryptonite-qt_14091021 is just running as a full node verifying blocks it uses more cpu than my blackcoin client when it stakes, so it's verifying and sometimes creating blocks . I've seen it get upto 25% so my worry was that your M7 PoW was more difficult to verify than the standard bitcoin sha256. It should be possible to run nodes on very low spec machines to encourage as many people as possible to run xcn and leave it running in the background to increase the network security.

On the 2nd issue could we have an install and uninstall option or put all the config setting in a config file in the cryptonite directory rather than filling up the registry.

The registry changes only happen if you're using Windows, I'm not entirely sure why, but the same thing happens with Bitcoin.

If this get popular most people will be running this on windows ( unless we get a smartphone version) and being able to completely uninstall and then re-install could solve some of the sync issues.

[bitfreak!]

Sorry I should have been clearer, when win64_cryptonite-qt_14091021 is just running as a full node verifying blocks it uses more cpu than my blackcoin client when it stakes, so it's verifying and sometimes creating blocks . I've seen it get upto 25% so my worry was that your M7 PoW was more difficult to verify than the standard bitcoin sha256. It should be possible to run nodes on very low spec machines to encourage as many people as possible to run xcn and leave it running in the background to increase the network security.

Well obviously the M7 PoW algorithm is slightly more difficult to verify because it uses 7 different hashing algorithms instead of just sha256, but it shouldn't really make a noticeable difference. The CPU usage spikes that you are referring to are probably the times when your node is seeding other nodes, particularly when it has to generate a "slice" of the account tree. That's why "slice sharing optimization" is the top priority for the core code development right now. The plan is to keep a second copy of the account tree in memory which is set 10k blocks in the past so that those slices can be served up almost instantly and wont have to be generated on the fly when they are needed.

[yonghongtang]

The only good news is bitfreak is still very  active.

[djm34]

The only good news is bitfreak is still very  active.

and the bad is ?

[polanskiman]

The only good news is bitfreak is still very  active.

and the bad is ?

Negativist 

What's up DJm34? Optimising ccminer any further?

I have another good news. The diff having dropped dramatically for the past few weeks I am now making double the XCN I used to make.

[zdminer]

The only good news is bitfreak is still very  active.

and the bad is ?

Negativist 

What's up DJm34? Optimising ccminer any further?

I have another good news. The diff having dropped dramatically for the past few weeks I am now making double the XCN I used to make.

I have even better news. The price having dropped dramatically for the past few weeks I am now buying quadruple the XCN I used to buy with BTC i earn mining other coins.

[WowWtf]

I say skip all the other steps and go straight to 6. and 7.

Point 6 isn't really a high priority because you can do a resync to prune your chain. The prune command will just allow the chain to be pruned while the node is still running, instead of having to restart it. The things in point 7 aren't a high priority either because they are highly complicated and I'd rather make sure the foundation is solid before we go extending upon it.

Point 6 and 7, and 4 are the only ones that are gonna bring in demand for this coin.....This coin desperately needs demand...hype..

[Jungian]

Why do we need 3rd party users (miners) to confirm transactions and update the blockchain for us when anyone who has a valid copy of the blockchain can do it for themselves? By getting rid of 3rd party confirmations, transactions would be nearly instant and there would be no fees.

New coins can instead be generated as a % bonus to payees by an algorithm in the transaction process. Users could then 'mine' new coins by simply moving them between accounts and this appears exploitative at first but is necessary to compensate for deflation and create demand. Perhaps there are mechanisms that can minimize the consequences of abuse and keep it fair.

How would you pick a fork? Why not mine every fork then?

[fiatpete]

Why do we need 3rd party users (miners) to confirm transactions and update the blockchain for us when anyone who has a valid copy of the blockchain can do it for themselves? By getting rid of 3rd party confirmations, transactions would be nearly instant and there would be no fees.

New coins can instead be generated as a % bonus to payees by an algorithm in the transaction process. Users could then 'mine' new coins by simply moving them between accounts and this appears exploitative at first but is necessary to compensate for deflation and create demand. Perhaps there are mechanisms that can minimize the consequences of abuse and keep it fair.

How would you pick a fork? Why not mine every fork then?

The same way we do now- by consensus. You have to accept the blocks that are reported by the largest number of nodes.  The greater the number of honest nodes there are on the network, the more difficult it is to pull off a 51% attack but, without the 3rd-party confirmation scheme (mining), the risk is isolated to you alone rather than the whole network and only while you are syncing. And it doesn't waste energy.

It sounds like your arguing for a type of proof of stake based on number of nodes rather than longest block. Have a look at https://download.wpsoftware.net/bitcoin/alts.pdf for some criticisms of PoS from a bitcoin dev. You might also want to look at some of the PoS coins such as peercoin, blackcoin and nxt. If xcn hard forked to PoS now there would be an issue of how to fairly distribute the coins as the only way for new users to get any would be to buy off of existing holders.
Also for my node to know that the fork is reported by the largest number of nodes wouldn't it need to connect to alot more nodes than the usual 8 or 16 limit?

[bitfreak!]

No, proof of stake is a 3rd-party confirmation scheme too. What I'm arguing is that there is no need for 3rd-party confirmation on new transactions because the blockchain enables all nodes to confirm new transactions for themselves and extend the blockchain. As long as all nodes begin with the same genesis block and follow the same rules for confirming new transactions, accidental forking shouldn't happen. Even the number and size of blocks between nodes can differ but they remain effectively synced as long as they share the same transaction history.

I think your understanding of how Bitcoin works and how Cryptonite works is somewhat faulty or incomplete. Blocks are solved periodically by miners for a reason, and I wouldn't exactly call it a 3rd party confirmation scheme, it's a decentralized confirmation scheme that anyone can participate in. Nodes can't just accept any transaction they get without worrying about whether or not other nodes got the same transaction, for all they know they could be the only node which got that transaction. Blocks are periodically solved via a PoW mechanism because that's the only real way that everyone can agree on which transactions should be accepted and in which order they were received. When a miner creates a block they are deciding on which transactions to include in their block, and if they manage to solve the block which they created then they send it out to the network and everyone agrees to place that newly solved blocked onto the end of their chain.

A fork can occur when two miners solve a block at roughly the same time, nodes just accept which ever block they received first and start mining a new block linked to that block. So there will be two different groups of miners which are mining two different chains for a small period of time until someone else solves the next block, which should resolve the fork because everyone will start mining on the longest chain. I have thought about ways that such forking could be eliminated entirely, such as a deterministic rule for choosing one block over another when two blocks are solved at the same time, but if you think about it carefully there is a critical flaw in that idea which could be exploited. As far as I can see there is no viable way to totally eliminate accidental forks.

[heskey]

Why are we not seeing any copycoins of this one? Is it somehow more difficult to clone?

[bitfreak!]

Why are we not seeing any copycoins of this one? Is it somehow more difficult to clone?

Yeah it's probably a bit more difficult to clone because the launch procedure is a bit different and you have to know how to deal with the first few weeks where it runs in "bitcoin mode".

[fiatpete]

Why are we not seeing any copycoins of this one? Is it somehow more difficult to clone?

Yeah it's probably a bit more difficult to clone because the launch procedure is a bit different and you have to know how to deal with the first few weeks where it runs in "bitcoin mode".

plus if you're going to do a copycoin for a pump and dump you chose a coin with a high market cap to try and get some of the people who missed out on buying the coin cheaply. But another possibility is a high market cap coin does a merger with xcn like darkcoin nearly did with shadowcoin as the mini blockchain would improve most of the top coins.