finally received
thanks James
you were one of the lucky ones!
As soon as I updated bitcoind, the mysterious crashes disappeared, but in all my trying to get things working, I had introduced a bug. [actually several iterations of bugs, fix, etc] Luckily it crashed after it sent out the batch and even recorded it on the blockchain.
"redeems": ["18012868213293812918", "17850665843091522447", "5367518091929625836", "10698833842468636419", "3709520954231419634", "17756615019036468931", "1377570613671922302", "11216020719769436505", "4536820520574248760", "1726627746411273772", "8444607710286649226", "7942006562702961293", "3965154387168484586", "13882380870973955071", "7446170061506132826", "11490956104839622575", "1423932192", "53387808"]
If your redeem is not in the above list, it will have to wait a bit more, but now that it looks like the non-MGW issues are finally fixed, it should just be a matter of letting the servers catchup like normal.
In order to prevent any buffer overflows, I limit each batch to 16 withdraws, which is usually plenty, but I think there are around 75. Anyway, there was a data structure that assumed the number of redeems matched the number of outputs, but when there are multiple withdraws to the same address this is not true and usually this is harmless. Of course when everything is max'ed out, it matters a lot.
I need to go over the code again to make sure there are no more unexpected buffer size issues. At least I am finally able to debug MGW code. It was quite frustrating to have it keep crashing at random places and it seems to be some sort of issue with the bitcoind?
James