Please do not use cryptopool as it is not working. Please solo mine for now instead.


Hi, what is your cancercurecoin.conf? The default RPC port is 9666. You shouldn't have to change any port numbers, unless there is a conflict with another application.

I can confirm that the client software is working without any problems. Problems that pools are experiencing are not due to failures in the client software. I suspect that the pools have not been configured correctly to send 5% of the block subsidy to the charity address (which must be the first coinbase output), which is a protocol requirement. I cannot confirm this at the moment as I am waiting on more information. Pool masters should send me the debug.log file.

I highly advise people to not mine on any pools unless they have confirmed that their software has been configured to comply with the CancerCureCoin protocol rules. People are able to solo-mine in the meantime. I'm sorry for any inconvenience.

Regards,

Matthew (Developer)

A config file should be like this:


The default RPC port has been set to 9666, you can use that, or another one if you wish.

I apologise profusely for the technical issues the CancerCureCoin network was experiencing.

The reason: A couple of days ago I needed to reset the genesis block. The time of the genesis block was set to today at 22GMT. To test the network I had to increase the time of the seed nodes by two days. This all worked fine. Then about three hours ago I set the time of the nodes back to the correct time ready for the launch. I verified that the nodes all had the correct time. However I did not reset cancercurecoind on the nodes. Because I did not do this, the time() function still returned the incorrect time and thus the nodes were out of sync with the rest of the network.

I have fixed the problem by restarting cancercurecoind on each of the seed nodes.

I hope people will treat this as an innocent error on my part and will be happy to continue to use CancerCureCoin. Once again I am very sorry. Please let me know if there are any more issues. I can contacted via cbitcoin@thelibertyportal.com or via PM. Make sure to send the debug.log if there are problems.

I will hopefully have the Linux and OSX wallets ready tomorrow, but for now I need some rest. In the meantime, please refer to the doc/build-osx.md and doc/build-unix.md files to build from source. This is relatively simple.

Thank you,

Matthew (Developer)

Blocks should be coming through now. I will explain what went wrong in a moment. Sorry for this inconvenience. Everything appears to be working now.

I can confirm that each of the seed nodes is responding with the correct genesis block hash which is:

5270190d7a1b54825cb35433f8b42c16bfb251a1004dcc317513e8734132ca1d

However, blocks do not appear to be picking up from the seed nodes. Please hold.

I'm going to verify the genesis blocks of the seed nodes. The seedNode branch on github is out of date. The seed nodes should be using the correct genesis block, but because I had to pass my code around secretly it is likely that something got mixed up, so it is probably that the seed nodes are using the wrong genesis block. I'm looking into this now...

Hi. I am the developer behind this coin.

Today it was planned that the Windows, Linux and OSX wallets would be up. I am responsible for the last two, however due to technical issues on my end I have not been able to provide those on time. I am not responsible for the Windows wallet. Unfortunately I had to spent a lot of time reseting the genesis block and passing code around secretly because miners were mining prematurely before launch.

However I have provided the source code, which is now on Github. This source code was tested yesterday but only briefly due to time constraints.

I am currently unable to test cancercurecoind because I'm having to reinstall a lot of software due to technical issues, but I am going to test the mining function when I can (which was working yesterday). In the meantime I hope that everyone can be patient whilst any technical issues are resolved.

I've noticed that there seems to be very few connections at the moment. If anyone is struggling to connect to the network, or if you receive any errors, please post the contents of the debug.log file. This can be found at:

Windows: %APPDATA%\CancerCureCoin\debug.log
Linux: $HOME/.cancercurecoin/debug.log
Mac: $HOME/Library/Application Support/CancerCureCoin/debug.log

Regards,

Matthew

These contracts from what I tell are verified like the bitcoin scripting language, only with a new language with commands that provide block-chain data, commands that stores information that can be referenced in later contracts and jump commands. They didn't explain how they would limit the execution of contracts. I suppose they will have a limit on the number of steps each contract execution can make.

More interesting than this would be the use of the SNARK programs to replace the scripting system, as previously mentioned elsewhere. That way completely arbitrary programs can be used in transactions.

If there is a backdoor, it doesn't appear to have been used yet, so what would they be waiting for?

I've fixed the address generation example and also added a (basic) generator for all upper-case and digit addresses such as this one I just generated: 17BK2E43VFA57KE6X5GQUAH12ECE7WL227.

cbitcoin now supports HD keys (BIP0032), it can properly construct and sign transactions of the standard types, various other things have been improved and there is a client on the way.

Hi. I'm not sure if this is the best forum to post this, but I thought I'd post the source code for an experiment I did with a bitcoin trading algorithm. It doesn't make money but maybe people would be interested in it. It was designed to use the old trade hill API. That part would need to be changed to test it out. I tried changing it to use MtGox but the MtGox had some sort of firewall that I had no idea how to pass.

I used OpenCL to check many trading strategies on previous price data to make a guess as to the best future trading strategy. It used three technical indicators. The RSI one didn't seem to do much but the PPO indicator and the PM one which I think I invented myself (variation on price momentum) gave the best results (though still not good enough to make a profit). It was an interesting experiment.

Please don't try using it with a live account unless you actually get it to make money which I doubt would be very easy.

See the code here: https://github.com/MatthewLM/BitcoinTradingAlgorithm

Thanks. I've not actually tested it running on the bitcoin network yet so let's hope it goes smoothly! 

This is a continuation from the off topic discussion at https://bitcointalk.org/index.php?topic=359582.100 about using SNARK programs as an alternative crytocurrency validation model. Program execution correctness can be verified with SNARK. See here for more information about SNARKs: http://eprint.iacr.org/2013/507.pdf

The essential idea is that miners do all of the validation and provide proof-of-knowledge about the correct unspent outputs which other nodes can verify without needing to verify transactions themselves.


Indeed. If even a single hash would increase the complexity too much (would it? I don't know), I suppose you could obtain the unspent outputs from running an ordinary validation program, and then provide the tree hash as an input to a SNARK program which verifies that the unspent outputs match at the end of execution. That way you only need a boolean output for the SNARK program.


This is what I thought. And if you could embed previous proofs into new proofs then blocks could contain a proof that the previous proof was verified. Then you would only need the latest block, because that block would act as proof for all of the previous blocks. That would be ideal. The blocks would need to then also calculate and provide proof for the total work done, so that nodes can simply choose the block with the chain with the highest total proven work.

I suppose it's partially zero-knowledge as you wouldn't need all of the inputs to the program. I did read somewhere that the SNARK programs can have public inputs as well as arbitrary inputs which are unknown to verifiers. Is that right? Some details would be hidden to the verifier, such as the transactions.

Because nodes wouldn't need to store and validate the block-chain. It only needs to be validated once. The output of the validation could be the unspent outputs, so that all miners need is the last block alongside the unspent outputs. Then they can build upon that. Non-miners would simply verify the proofs in the blocks and take the unspent outputs relevant to them. Why is this not a good idea?

How would anyone actually start developing a crypto-currency that worked in such a way? It all seems very theoretical to me.

I read part of the paper. In layman's terms, the "GHOST" parent selection of blocks takes into account the work of all the blocks that are children of a block which is a candidate to be made parent. Therefore it takes into full account the hash distribution of the network. In the current system, if the time between blocks was reduced significantly, then blocks which are propagated slowly will be placed on a side-chain as they will lose out in the propagation race, therefore, unlike the "GHOST" system, the current system cannot take the full hash-distribution into account.

Now if only that was explained in the abstract, it would have saved me so much time!

I was thinking about this myself. Could you use a zero-knowledge proof to validate the block-chain without needing the actual block-chain? I don't know very much about it at all.

Maybe some rich person is having a laugh?

"Mil" will not be confused with million if you say "mils", ie. "That will be 2.56 mils please". You could also apply it to one ("one mils"), even if it sounds a bit weird at first. "Mike" makes sense for micro-bitcoins, and you could say "mikes" to be consistent with "mils".