In this update lies the proof that just shows the workings of a fud - if a dev does not post he gets fud and if he makes a post he gets fud too - damned if you do and damned if you dont  

Most likely, but if I am right, you will be out of a job if others copy the technology going forward.  It is in your interest if he disappears, get dishearted or fails

Unfortunately with crypto it is a matter of damned if you do and damned if you dont for a dev. If a dev does not make a post, fudders take advantage of that and post that the dev has disappeared and is a scammer. If a dev does make a post then fudders take advantage of that and try to take apart the dev based on his post. The only certainty in crypto these days is fud.

If a dev decides to make a post he needs a thesaurus, dictionary, linguist, elocutionist and a tech manual because every word will be analysed and taken apart. I am a strong believer of less is more and wise men speak because they have something to say - fools because they have to say something (Plato). Fools and scammers will try to say as much nonsense, empty promises  and impossible things as they can to cause hype and to make a quick profit. Scammers are after the low hanging fruit. I am thinking more and more that it is best for devs to stay quiet and only speak or post when there is something useful to be said. In the last case the worst that can happen is the fudders fud the price down and when something useful is posted eventually, then the price goes up again quickly and the fudders say ****!, ****! I sold at such and such a low price.

The dev could be a scammer which would be very disappointing, but then he would have been long gone after taking his profit and be already posting under a new name. On the other hand the answer can be as simple as that the dev is working on solutions and will go to market when the solution is finished being coded and tested and perhaps there are also production issues as per the IRC quote becuause nothing in life is perfect. It is an interesting and noble field to try and code something to be GPU resistant because if that can be done with a great level of success it could mean a more equal processing of POW blocks for a greater number of people by using CPUs. The dev probably made an unfortunate choice of words and was over-confident when he launched the coin to use absolute words like "foolproof" instead of using a more tempered "resistant". Sometimes the best tests are conducted under real life conditions where there are people that actually test the assumptions and break it. Sometimes it takes 2 or 3 or more attempts and adjustments to get a theory right. Ill be watching to see what the dev comes up with in his research in this field and if he gets it right it would be a valuable contribution to the crypto body of knowledge.

I could be wrong of course, and perhaps naive, but maybe the dev is following the second option. If the dev is in fact just keeping quiet until there is something to deliver, he is wise and following the approach that I would recommend for alt-coins currently.

What is there to post? Dev was last online on 9 July which is 1 month ago. So either wait for the dev or someone take it over.

In the meantime, withdraw coins from the exchange and stake them. There are lots of coins on the exchange that are not staking. Also, you never know what might happen and with people staking the chain is kept alive while waiting for the dev or whatever.

Only when he returns from the Bahamas when the ICO funds have run out.

Try the bootstrap.

https://bitcointalk.org/index.php?topic=1135151.msg12042518#msg12042518

Regarding the question about staking orphans on the Pi or otherwise.

There are 2 types of staking - fixed block rewards and percentage based block rewards. The lengths can also differ between in perpetuity or for a fixed period. Orphans do seem to matter if you are mining POS of a fixed block reward for a fixed period, meaning that if you lose a block you have lost the coins and when the period expires you have lost out, although your weight seems to stay the same after an orphan meaning the chances are good that you will get a block soon after the orphan.

Based on visual observation orphans do not seem to matter with percentage based POS mining in perpetuity because if you miss one block your weight seem to stay the same and you will get that block reward or close to it with a next block soon after the orphan. Over time the POS reward has to add up to the coin design of a certain % per year. The last example is similar to closing your wallet for a week and opening it again for staking and then getting a large block reward to bring your POS rewards in line with the coin POS reward design. Since PayCon falls in the second category orphans do not really mind as long as you get a few blocks once in a while.

Here are the Raspberry Pi wallets for PayCon based on the commit just before TOR. TOR requires 64bit and since arm7 is 32bit the TOR portion of the code cannot run on Pi. Both the dynamic Qt and headless daemon (command line) wallets are included as well as a static headless daemon wallet. The static wallet has the advantage that you do not need to install dependencies before running the wallet.

Important:
1) Always backup your wallet.dat first before you do anything
2) The wallet was built on a Raspberry Pi2 (ARM7) running Raspbian Wheezy and the instructions and scripts assume you are running as user "pi".
3) Installation directory where the binaries are installed is ~/opt/PayCon or /home/pi/opt/PayCon
4) If you decide to instal the dynamic wallets, all that is needed is to execute the dynamic command below on your Pi in a terminal window and afterwards you need to click on the PayCon icon on your desktop to launch the Qt wallet or go to the directory with the wallets and run the daemon (PayCond) with the options you want at the command prompt or in a terminal window
5) An Internet connection is required for the installation
6) A bootstrap.dat is available to fast track the blockchain sync - up to block 293520. The installation script does not force the install of the bootstrap.dat as it is 100MB. You need to manually download it, unzip it and place the bootstrap.dat in the ~/.PayCon folder.
7) The bootstrap.dat also works for Windows wallets. Windows users just have to copy the bootstrap.dat file into their c\users\yourusername\AppData\Roaming\paycon folder and run the Win client again
8.) You need at least an 8GB memory card for the dynamic wallets, but the static wallet can run on a 4GB card.
9) The installation itself takes about 30-45min on an out-of-the-box Pi
10) You cannot just download the dynamic wallets, you have to run the script to get the dependencies as well else it will not run. You can however just download the static wallet and run it. Note that the Qt wallet will crash the first time it is loaded but just run it a second time then it will work from there on forward.
11) The installation script does not enable the UFW firewall by default. If you want to enable it, uncomment the UFW lines in the script and add the port you want open and run it again or enable it manually by running the UFW commands as in the script with the correct port numbers.
12) Always verify the checksums when you download files to make sure it was downloaded ok. To verify the checksums on your Pi, go to the ~/opt/PayCon folder and execute sha256sum <filename> and md5sum <filename> and compare the values with the values in the checksums.txt file. Do the same for the bootstrap.dat

Users will be familiar with the Qt wallet as it works like a Qt wallet in Windows. Instructions to use the headless command line daemon wallet:

1) Since you the installation script created a PayCon.conf file with the startup settings in it, go to the folder with the binaries ~/opt/PayCon and enter ./PayCond in a terminal window to start the server
2) After the blockchain has been imported you can enter the normal wallet commands that you would as in a Windows debug console preceded with ./PayCond eg. ./PayCond getinfo
3) Remember to always make a backup of your wallet.dat file before you do anything like encrypting it
4) To encrypt your wallet run the command ./PayCond encryptwallet <yourpassword>

Let me know about any issues that you may encounter.

To kickstart the installation execute one of the following commands at the command prompt or in a terminal window on your Pi, depending if you want to install the static wallet or the dynamic wallets.

Static wallet:

Dynamic wallets:

Direct links:
Link to static wallet installation script
Link to dynamic wallet installation script
Link to static PayCond wallet (rename PayConds to PayCond)
Link to dynamic PayCon-qt wallet
Link to dynamic PayCond wallet
Link to virustotal scan for static PayCond
Link to virustotal scan for dynamic PayCon-qt
Link to virustotal scan for dynamic PayCond
Link to bootstrap.dat up to block 293520 (100MB)
Link to checksums.txt

It seems that some people are struggling with slow syncing.

I have updated the bootstrap.dat to block 24905. 14.4MB unzipped.

Link to bootstrap.zip (9.5MB zipped)
Link to axiom_bootstrap.tar.gz (9.5MB tar.gz
Link to checksums.txt

Remember to verify the checksums.

Impersonation of the dev team it seems.

You can use a PGP/GPG key pair to sign the binary. Then you must just make sure that someone trustworthy has signed your key. Perhaps you have gone through a key party in the past? You can generate a key pair with several tools eg. Kleopatra.

It is only in the case of where a private key of a public/private key pair is a function of a human input, that the redundancy of the user's language could potentially cause a reduction of the key space. If you do the maths it is not feasible to create a rainbow table for 256bits and in addition there is not enough computing power in existence today to attempt that.

Ok, answer the following for me:

1) Can you tell me the key length of the private key of a wallet?
2) Can you tell me who "chooses" the private key - the "wallet" or the user?
3) At which point does the redundancy of the language come into play - a) upon private key generation or b) when a user decides to encrypt his wallet with a password of his choosing if he actually decides to encrypt his wallet?
4) After you have explained 1-3 can you explain the relevance of the users wallet password and redundancy of a language to the private key in the wallet and how you will derive the private key of the private/public key pair from the public key by using the wallet password if you happen to obtain the users wallet password from a rainbow table of some sorts that you are referring to? My question in point 4 is what you are in fact saying is possible in your argument.

You dont have a clue what you are talking about regarding public/private key cryptography do you?

I guess this also applies to you. Are you sure you have no signs of a trojan on your system? Upload your wallet and minerd again and compare the virustotal hashes.

https://bitcointalk.org/index.php?topic=1135151.msg12024102#msg12024102

Those sites are probably fake or maybe contains only a tiny fraction of the keyspace. It is not possible to create a rainbow table for Bitcoin with today's technology. It will take too much time and energy and storage space. There are so many links to quote where people have already answered why this is not possible at this point. Just google it. Ill past a few:

Link 1
Link 2
Link 3

Move your coins to a new address and see if that address is accurate on the rich list, or perhaps move to an exchange and back and see if your receiving address is then showing at 100%.  When you move it to an exchange for example, look at the detail of the tx to the exchange in the block explorer and see how many debits there were - there should be many entries of small addresses of the block reward size of when you mined them which are then consolidated to the total amount. If you move them back the tx should have only a couple of entries consisting of the total and block reward.

You will also note that when you have lots of solo mined blocks that first consolidation transaction when you move it to an exchange for example has a large transaction fee because of all the processing that has to be done. The transaction back many times have no tx fee. Also, with some coins if you have many small reward size solo blocks and you want to send a too large an amount, the tx becomes too large and the wallet gives an error, then you have to send it in smaller chunks. I also have a theory that is why pool withdrawals sometimes get stuck with some coins if the withdrawal size is too big. I dont have a pool so I cannot test that theory.

EDIT: I am thinking off the cuff here with another theory completely untested at this point, that perhaps POW and POS work differently in that the one method's rewards are in its own unique addresses and the other method is in your receiving address. This could explain a 40% total in the rich list because you might have mined 60% POW and 40% POS and the rich list only shows the POS portion.

All I am saying is that with other coins where the same happened if I moved the coins the new address appears accurate on the explorer. My current receiving address does not appear on the rich list at all. I dont want to move my coins because it will reset the coinage. Perhaps you or someone else could test it by moving their coins to a second address and see if that then shows accurate?

Perhaps the wallet knows that it has found a block and the chain will honor that, but perhaps block explorers in general or maybe only certain block explorers do not know that or does not do that check or is not that advanced to link the address of the block reward to your wallets receiving address.

Try this.

It seems that coins found with solo mining are stored in the addresses that generated the solo blocks in the sizes of the emission curve at the time. Each block has its own address and sometimes a few blocks originate from the same address but a different address than your wallet receiving address. There will be many addresses with 500 coins for example. If you only solo mined and did not pool mine, then your wallet receiving address will not appear on the rich list at all. The solo block originating addresses are however linked to your wallet receiving address as far as your wallet is concerned as well as for coinage purposes. If you create a second address in your wallet and move your coins there, then the rich list will be updated and be accurate on the new address because in the transaction list all your originating solo block addresses will be debited and your 2nd wallet address credited. Coins that come from a pool address will not suffer the same phenomenon because by withdrawing from a pool the pool transaction debits the originating block addresses and credits your wallet address. This is why rich lists for many coins do not mean that much because a top wallet address could not appear on it if all his coins were solo mined and spread over 1000 small solo block addresses for example. I dont know if this is just something with certain block explorers and if other explorers actually pick up that the coins are linked to your receiving address like your wallet does.

If you look at the pie chart and the little table above it on the top 100 page you will notice that the % adds up to about 78% at the moment. The difference is 22% which is the grey area in the pie chart and is not listed in the table. These coins seem to be the solo blocks in their originating addresses. If all holders move all their coins to new addresses, the grey block (22%) will disappear and table will add up to 100%.

With lots of testing this theory is the only one that makes sense to me. Please test and see if you find the same. Just note however that if you move your coins, you wil reset your coinage for staking.

Can you please read this post and then run your miner through Virustotal. Please compare the hashes. If you have the "bitcoinminer" one it is a standard false positive and you have to look elsewhere for the infection. If it is the hash of the infected miner then you know what the source is of your infection.

You must never ever click on quoted links.

https://bitcointalk.org/index.php?topic=1135151.msg11981651#msg11981651