Quote from: slb on October 19, 2014, 09:09:03 AM

Quote from: arielbit on October 19, 2014, 07:12:27 AM

once dash have ease of sending transaction, i'll send some donation..

I have some finding about the recent transaction problem. I knew what was the problem when I fixed my test pool - transactions with size bigger than 10,000 bytes were hardly accepted in the blockchain. I took my investigation further and here are my finding:

1. Minergate uses old or modified code:
This is the code from the current version on Dashcoin:

Quote

#define CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE 20000

Here is what they probably use:

Quote

#define CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE 10000

2. Minergate started to use this code on 2014/10/06 10:28:17
I looked at the blockchain for odd blocks and they started to appear here:
http://chainradar.com/dsh/blocks/2241/30

Quote

67225 14-10-06 10:28:17 576 1 63d91c6d5f7f9eab1cc2ad3f3be0435fba2427694ba4579e1cdb6077e8e47110

Before this block all blocks have size >17,000 bytes, which means all pools have honest code before this point of time (CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE with value 20000)

http://chainradar.com/dsh/block/63d91c6d5f7f9eab1cc2ad3f3be0435fba2427694ba4579e1cdb6077e8e47110

Proof that the block is Minergate's:
https://minergate.com/pool-stats/dsh/23491
Search for 63d91c6d5f7f9eab1cc2ad3f3be0435fba2427694ba4579e1cdb6077e8e47110

3. Minergate used correct code before 2014/10/06 10:28:17
Here is a Minergate's block just 2 blocks below the first strange block I showed above.

Quote

67225   14-10-06 10:28:17   576   1   63d91c6d5f7f9eab1cc2ad3f3be0435fba2427694ba4579e1cdb6077e8e47110
67224   14-10-06 10:28:43   27286   3   87e8bd5e525649322ed3e5a7d582629917353b06680ba4c035736c03d6834a40
67223   14-10-06 10:17:47   23295   4   4e2dad2aa98dab526f9ea269c0d6dc0388ebb20af159e95c71df3f0bcd8bfdbe

Proof that the block is Minergate's:
https://minergate.com/pool-stats/dsh/23491
Search for 4e2dad2aa98dab526f9ea269c0d6dc0388ebb20af159e95c71df3f0bcd8bfdbe

How this is affecting the network:
1. Transactions with >10000 bytes will break with frequency, related to how much of the hashrate Minergate controls. This produce a snowball effect - the more failed transaction - more people goes to Minergate, because the other pools cannot send transactions.
2. The higher number of transaction failed leads to the constant need of reset and cache delete.

How to act:
DO NOT MINE AT MINERGATE
To improve the effective transaction median and reduce the rejected transactions, we must put Minergate's hashrate percent to minimum as possible until they fix their daemon.

Spread the hashrate between pools
Lets don't make the same mistake again and give so much power to a single pool.

Make sure you are running dashcoind with version 1.0.2

Quote

dashcoind --version

The fact that Minergate had a version with CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE 20000 before their version with value 10000 makes me almost certain this is not a simple mistake.

okay...moving my miners off mg.

but can you tell me how sending large amounts from mg seems to work almost all the time and i struggle with amounts 10x smaller from simplewallet given they reduced this parameter? i've was able to send 3 separate 24M DSH txns from there that arrived within a very short period of time when my 2M DSH txns from my simple wallet would take hours if not a day to get there