Quote from: burner640k on May 05, 2015, 03:32:21 PM

OK, so I took a break from looking at it but now am back again trying to figure out why I was not credited Blur for the Crave I burned using darkpoold (block 52061, hash 1a278074b96bc61f913c0df3afca88c5fd0771757e2f02b171adf9bc6553001d, address CDssAhibe5m4hx3yMyi5TuxrqrSDuJRwqk).

I noticed that someone else may have run into the exact same problem as me, though I do not see them posting here. Whoever burned 13.99994986 Crave from address BvEeWXL6qz3YXRmBQbbh25ri4uQudpD67H at block 53204 you did not get any Blur.

In looking at that I noticed that both that person and I did the same thing, we burned all the Crave we had at our address, no change. Every other burn that I see has change. So maybe the bug with darkpoold is that if the burn does not have change it does not get recognized?

So after even further digging my prior thought above is incorrect, the problem of my missing Blur is not because I burned all the Crave at that address.

However I think I am narrowing in on the problem that has plagued my burn. I am not a programmer but Python is easy enough to read through and follow to get an idea of what is going on.

When darkpoold tries to match a vout to an input it grabs the transaction id of the input and then looks back at that previous transaction that happened in an earlier block. But when it goes to figure out what address in the prior block matches that output it uses the same function for getting the address as it does for the vout. This function requires asm to have 5 elements and if it does not it rejects it. In most cases this has been true so it processes fine.

Unfortunately for my burn, block 52061, darkpoold looks at the first input and gets the transaction id for that, b03b0fe5b13cf3f506b52027876dbfde089a7a84e3cd49167ae5679df1f0bcf0. It then looks at that transaction which is for block 49674 and tries to match an output from that block to an input in the burn block, 52061. It finds the correct match, the 3rd vout in that transaction. After this it then tries to find what address that vout went to. However the get_address function calls the get_pubkeyhash that expects the asm to have 5 elements but my vout from that block, block 49674, only has 2 elements. So it rejects that and does not report my address so the burn fails.

It looks like when getting addresses for the vin's in a burn block it should not have the same requirements as the vout for the burn block. darkpoold controls the vout format of the block but it does not control how all the transactions that came in are formatted.

This has been quite a learning experience but I think I am getting close to why my 520 Crave burn was not recognized by the network. The good news is if I am correct if darkpoold gets patched then my Blur should show up if the database is rebuilt.

burner640k

Posts

Merits