That is not always true. I made many trades when spread was even wider and I made the most profit percent from it, in relation to the investment.
There is always wide spread at the beginning of a new trade and in static phases.
In my experience the only thing that effect negatively trading is stale market, no volume; wide spread is sometime and effect of it, but rarely the cause.
In wide spread market I just place my trade and if volume pick up and I am close enough to the sweet spot it get fulfilled.
When that happens I start doing the same faster and faster to keep (ab)using the wide spread, until the trades find balance and then the trend starts... then you use your preferred standard trading paradigm.
I also see that "others" are doing exactly the same in many markets and even here... blink blink
Anyway you maybe right in this case, since we still need a minimal volume to trade and this Google sheet is not the most widely known by the trading masses... so post your trade and spread the voice and when it pick up, you may find yourself lucky.
Cheers.
 

Spread is a good thing in my book!

I know this is and old topic, but I just now read it.
I am a long time Boinc-er (using the Berkley distributed computing platform) and between the projects I participate, there is one called PrimeGrid and it is all about various prime number mathematical work, one of them is finding various kind of them.
The projects uses GPU in some of their calculation, so maybe it could interesting to look at what they are using it for and get some new ideas.

Thank you, I do keep dated incremental backups.
I just added the addnode into the .conf file since it states on the main (first) post that the hard coded peers/nodes are down and to add those to configuration start syncing.

So I did.
I think there is a big split happening most the block explorers are frozen and the 3 exchanges are on different chains. Some peps can deposit to some of them but not the others and vice versa.
Thank you anyway.

How do I get on the right chain?

I am running version v1.3.4.1-unk-beta

I have the following node on the .conf file:

addnode=80.241.218.9
addnode=176.58.92.169
addnode=176.9.63.136
addnode=195.130.216.149
addnode=192.99.35.133
addnode=149.210.168.71
addnode=71.105.130.10
addnode=91.132.178.106
addnode=88.218.101.44
addnode=115.29.160.13
addnode=78.13.151.160
addnode=93.171.209.97
addnode=190.177.100.76
addnode=54.72.105.98
addnode=83.247.7.131

but now that I restarted the walled it says: "Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."

and getpeerinfo gives me:

[
{
"addr" : "80.241.218.9:13931",
"services" : "00000003",
"lastsend" : 1402745253,
"lastrecv" : 1402744778,
"bytessent" : 339,
"bytesrecv" : 58164,
"blocksrequested" : 0,
"conntime" : 1402744775,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.2/",
"inbound" : false,
"startingheight" : 174315,
"banscore" : 0
},
{
"addr" : "176.58.92.169:13931",
"services" : "00000003",
"lastsend" : 1402745253,
"lastrecv" : 1402745191,
"bytessent" : 1383,
"bytesrecv" : 63789,
"blocksrequested" : 0,
"conntime" : 1402744776,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.2/",
"inbound" : false,
"startingheight" : 180368,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "176.9.63.136:13931",
"services" : "00000003",
"lastsend" : 1402745252,
"lastrecv" : 1402744961,
"bytessent" : 5514,
"bytesrecv" : 369814,
"blocksrequested" : 0,
"conntime" : 1402744776,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.1/",
"inbound" : false,
"startingheight" : 180368,
"banscore" : 0
},
{
"addr" : "195.130.216.149:13931",
"services" : "00000003",
"lastsend" : 1402744962,
"lastrecv" : 1402745289,
"bytessent" : 339,
"bytesrecv" : 45289,
"blocksrequested" : 0,
"conntime" : 1402744777,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.2/",
"inbound" : false,
"startingheight" : 174315,
"banscore" : 0
},
{
"addr" : "192.99.35.133:13931",
"services" : "00000003",
"lastsend" : 1402745348,
"lastrecv" : 1402745312,
"bytessent" : 73702,
"bytesrecv" : 1359054,
"blocksrequested" : 0,
"conntime" : 1402744778,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.2/",
"inbound" : false,
"startingheight" : 181908,
"banscore" : 0
},
{
"addr" : "149.210.168.71:13931",
"services" : "00000003",
"lastsend" : 1402745348,
"lastrecv" : 1402745312,
"bytessent" : 37237,
"bytesrecv" : 710109,
"blocksrequested" : 0,
"conntime" : 1402744778,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.2/",
"inbound" : false,
"startingheight" : 181908,
"banscore" : 0
},
{
"addr" : "91.132.178.106:13931",
"services" : "00000003",
"lastsend" : 1402745319,
"lastrecv" : 1402745347,
"bytessent" : 5229,
"bytesrecv" : 56840,
"blocksrequested" : 0,
"conntime" : 1402744786,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.1/",
"inbound" : false,
"startingheight" : 181908,
"banscore" : 0
},
{
"addr" : "88.218.101.44:13931",
"services" : "00000003",
"lastsend" : 1402745317,
"lastrecv" : 1402745317,
"bytessent" : 40888,
"bytesrecv" : 703496,
"blocksrequested" : 0,
"conntime" : 1402744792,
"version" : 70006,
"subver" : "/Satoshi:1.3.4.1/",
"inbound" : false,
"startingheight" : 181908,
"banscore" : 0
}
]

The size difference is probably, because you did not strip your binary.

To build static try to put 'STATIC=all' at the end of your make line. (without quotes)

Also, did you 'make clean' in between retries?

Well, that is correct for now, but since the package contains all files with the Unix style end-of-line, I prefer to use MSYS on Windows, so I am sure that nothing breaks now, nor will in the future.

Also note that one of the batch files in the miniupnpc folder is named 'mingw32make.bat', very similar to the command that you instruct to use, 'mingw32-make', if the user has Windows CLI completion enable, and type the first few letter then auto-complete, that batch file will be used causing problems... also in Windows batch file can be called without the .bat extension, making this one even more similar to the actual command that we want to use.

... but yes for now is just matter of preference.

About this part... actually there is already a directive in the makefile.mingw that does exactly that... from msys while in the bitcoin src directory, call:

This part has a problem. On windows if you download the tar.gz file, depending on how you unpack it, most of the time you will end up with files that may not run correctly like the two batch files in it... again the reason is that those files from the package have the Unix end-of-line encoding (LF) and will not work correctly used from windows console (cmd.com).
So either a conversion from Unix LF to Windows CR+LF on those files is needed, or just use mingw to compile it using "$ make -f Makefile.mingw init upnpc-static" from msys instead of Windows command prompt.

This would not fix the problem... which is the actual $BOOSTDIR/tools/build/v2/engine/build.bat you are using has been coded with Unix style end-of-line (LF) instead of windows style end-of-line (CR+LF), so since it is a batch (.bat) file to be ran inside the regular windows console (CMD.COM) it will fail to execute correctly.
The solution is to open the file $BOOSTDIR/tools/build/v2/engine/build.bat with and appropriate editor that can convert the end-of-line encoding to the correct one (CR+LF)... something like NotePad2 or NotePad++ or anything else of your liking that has this feature.

EDIT (after more checking...):
... I find out that actually there are a lot of them (batch files) with the "wrong" end-of-line encoding, in some it does not cause any problem, but in some it does (depending on parsing engine), so if you have those files the best course of action is to search for and open all of them (*.bat) in something like NotePad++ and convert all the end-of-line to windows style and save all the files.
This should fix some if not all of the problems peps are having while compiling boost on windows.

(Anyway this problem mainly arise when the boost tar.gz packaged file is extracted (tar xvfz) on windows, so it should not arise if you use the boost .zip file, that supposedly and hopefully has the end-of-line of the batch files (.bat) encoded for the purpose of being open and used on windows.)

P.S.:
those solution should also fix the problem in windows where you get:

It would be nice if Bitcoin would move to BangDB, way better performance.

If you want generics on useage there is this:
http://www.devtome.com/doku.php?id=pywallet

also at the bottom of the first post of this very thread:
https://bitcointalk.org/index.php?topic=34028.msg424586#msg424586

for specific case needs there is the amazing Google search.

and if you have a specific problem you may able to get better help, if you actually post specifics of your problem, like:

• What syntax error?
• Doing what?
• Trying to do what?
• Steps?

Moreover, I am sure that you are more then welcome, by the author and the community at large, to ultimately write or paste a guide of your liking and satisfaction.

And anyway even about that I do not understand what you are looking for... again... step by step guide for what?... bulletproof guide for what?... usage, installation, integration... your post is so vague that this is probably the only reply you will receive until you explain yourself more clearly and detailed.

Almost everything work fine when I use the CLI, but I have a problem with the web interface which I would like to use for simplicity and curiosity.
When I try to use it, this is what it shows in the browser:

and this is on the console:



EDIT (after more testing...)
This is mainly happening in IPython with the %run magic; also causing the IPython instance to not function correctly after pywallet.py is interrupted by CTRL+C or forcing a quit by directing the browser to 'http://localhost:8989/quit.'
Control and escaped characters can be noticed at its prompt:



But instead, if we call the pywallet.py from the actual python executable called as a escaped IPython console command instance. by '!python(.exe) pywallet.py --web', then in this nested-Russian-Dolls-mode everything works.
... not optimal, since almost all of the IPython feature are defeated, but it works.

So could anybody help troubleshoot and fix this?  

The "--version" CLI option does not return the correct info... I don't know if you want me to file a bug report: then where? Or clone your GIT repo apply changes and push? Or just tell you here the correction:

Ask or check your addresses and use any of these charts:

http://cryptolife.net/upwg/
https://en.bitcoin.it/wiki/List_of_address_prefixes

Well when you open an account on exchange you deposit onto an M of N wallet which you use to do transactions. Once deposit is verified the account is active and you can do transaction on exchange virtually, but for each one you authorize the amount from that wallet using the 2 out of 3 key you have.
The trades happens virtually and instantaneously, the real solvency lags behind, but it only noticeable only if you want to withdraw right the way.

Sorry, nothing against the idea, but how are you going to use the currently existing ASICs for DRK?
And for the BTC side, how is this different then other BTC pools?

Probably partially true...
I think he is on a Government gag order, if he talks directly he will go to prison for long time, and in this way he can give the info to the world.
They said on multiple occasion that there was an investigation that they could not talk about and at the beginning they also said they still have the BTC, but for a technicality, of which they also could not explain in details) could not be accessed. And about that part somewhere else few days ago some big wallet start moving BTC around.
The BTC are there and somewhere in the world are also the Keys.

Nope it doesn't I tried on two computers and only the linux version works... the windows and the OSX cannot be unzipped. Also the homepage seem to have two download pages
If you click download from the home page http://heavycoin.github.io/ you will go here: http://heavycoin.github.io/mining-launch.html
If you click the download on the top right you will go here: http://heavycoin.github.io/download.html
but all of the zip file cannot be unzipped on windows nor my OSX laptop.

None of the zip file on the site works... also why would you have only a windows 32bit version... most of them now days are 64bit.