Sent .0098×37÷2=0.1813 BTC
My PTS address Pvxtus6iJ7pS7uJDir8c5puVNcDQaatQR5
I will send another half after I receive PTS

I want to buy 300PTS right now. Is that OK?

We will use a escrow, and I will pay the transaction fees.

Exchange is back and working!

Quote from: victor on November 12, 2013, 04:19:41 am

Hmm... I do have an improved miner with only a few lines changed and ~20% more HPM.
Maybe try this bounty later, after I am paid the 1BTC for fixing crash (I am still waiting for that 1BTC )

Ok.. I was waiting on bitstamp withdraw to pay your bounty... coming now.

20% more than my pool miner?

Got the 1BTC, thank you!

No, it is just 20% more than the original pts-miner. But that's just a few line changes within a few minutes. I just wanted to show that there is much room to make improvements on the miner.

see http://bitsharestalk.org/index.php?topic=429.0

Hi bytemaster,

I have posted a patch at http://bitsharestalk.org/index.php?topic=408.15 sometime earlier today, and my patched clients has been running fine for a few hours instead of consistently crashing. May I claim this bounty?

My BTC address: 12FtgmhWyu64x9kCC8GzGG5DCgQ4ps2PgE

Thanks,
Victor

Quote from: gigawatt on November 11, 2013, 04:50:55 pm

Running a few tests to see if I can replicate the issue.  I've got a watchdog wrapper for my protoshare client, so if it crashes I'll capture the debug.log file for analysis.

I'll let you know if I spot anything.

We are aware of this issue and have a 1 BTC bounty for any patches that can help resolve it quickly.

My quick patch below should fix this issue. Please test it.

http://pastebin.com/FQv3snaP

The cause of this problem is that the old client disconnects the new client due to the wrong proof of work; however there is a race condition that sometimes the new client still wants to communicate with the old client, but since the old client has closed this connection, a "broken pipe" signal will be passed to the new client and it is terminated.

Interestingly, on Windows platform a flag MSG_NOSIGNAL is passed to send() to avoid this problem. This should also apply to Linux since MSG_NOSIGNAL is supported after kernel 2.2+

--- ProtoShares/src/net.cpp     2013-11-11 11:46:13.019922787 -0800
+++ ProtoShares-new/src/net.cpp 2013-11-11 12:34:22.155890315 -0800
@@ -710,7 +710,7 @@
     while (it != pnode->vSendMsg.end()) {
         const CSerializeData &data = *it;
         assert(data.size() > pnode->nSendOffset);
-#ifdef WIN32
+#if 1
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_NOSIGNAL | MSG_DONTWAIT);
 #else
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_DONTWAIT);