Skip to content

Fix transaction remainder calculation

Andreas C. Osowski requested to merge mark-bradshaw:fix-transaction-remainer into master

Created by: mark-bradshaw

TL;DR - The addRemainder function is miscalculating the final remainder because the totalTransferValue variable is set inside the loop, when it should be outside the loop.

I believe I've located a bug in the transaction calculation code. It seems that this kicks in when you are sending iotas that require you to bundle up iotas from a variety of addresses, so this only applies occasionally.

While working on the cli-app I noticed that none of my transfers were ever getting confirmed. After a while I noticed that there were many transactions, not just my own, that were not getting confirmed and after some digging it appears to me that they problem is that the transactions in the bundle are not calculating the remainder iotas correctly.

I may be misunderstanding how the transactions are supposed to add up, but my understanding from our conversations is that the values of all transactions in a bundle sum to zero. And transactions that are getting confirmed do sum to zero, so I think I'm understanding correctly.

In any case, here's a scenario that I was encountering. This represents a transfer of 100 iotas. The inputs given to the addRemainder function are:

inputs [ { address: 'ITUCF9EUFSSARJBEZXRUAWGJRSVWQUVNJTFJXKUHXWSKZGIRAGWARQDHDCXQYQBIL9GARCURBL9APQZ9H',
    balance: 1},
  { address: 'OTME9EVTIVHLZUKXMIQTXTKYRPJKRZLHNKSXCDSFDDTRQFLSFBMIZGERH9DXA9FVIJTLBQEHLZGOMFLNV',
    balance: 72},
  { address: 'AVTNEYAYLALKFKYOJCIZ9ZQQZRJWOKXVVDRKCGWKSPSJHCVGOHKDSJAZWRUWEFM9MBGTWGF9UYYIVH9ZA',
    balance: 933127 } ]

Based on those inputs, I got this bundle:

[ { address: 'CNARWWVKTJIYQZTACAARJBRQUTVAXBNHX9FPGBZN9SEP9S9NPPMVSZX9EUD9LVEQYMTCYJGATYMOADZFH',
     value: 100 },
   { address: 'ITUCF9EUFSSARJBEZXRUAWGJRSVWQUVNJTFJXKUHXWSKZGIRAGWARQDHDCXQYQBIL9GARCURBL9APQZ9H',
     value: -1 },
   { address: 'ITUCF9EUFSSARJBEZXRUAWGJRSVWQUVNJTFJXKUHXWSKZGIRAGWARQDHDCXQYQBIL9GARCURBL9APQZ9H',
     value: 0 },
   { address: 'OTME9EVTIVHLZUKXMIQTXTKYRPJKRZLHNKSXCDSFDDTRQFLSFBMIZGERH9DXA9FVIJTLBQEHLZGOMFLNV',
     value: -72 },
   { address: 'OTME9EVTIVHLZUKXMIQTXTKYRPJKRZLHNKSXCDSFDDTRQFLSFBMIZGERH9DXA9FVIJTLBQEHLZGOMFLNV',
     value: 0 },
   { address: 'AVTNEYAYLALKFKYOJCIZ9ZQQZRJWOKXVVDRKCGWKSPSJHCVGOHKDSJAZWRUWEFM9MBGTWGF9UYYIVH9ZA',
     value: -933127},
   { address: 'AVTNEYAYLALKFKYOJCIZ9ZQQZRJWOKXVVDRKCGWKSPSJHCVGOHKDSJAZWRUWEFM9MBGTWGF9UYYIVH9ZA',
     value: 0},
   { address: 'FTWQXRVMTZJAQKDHQC99IWQFM9BNDIYOOKGKJGTSJPVSFJCFGRHAQLNVNHURXYJMIIRNKSZZCDMA9UCYL',
     value: 933027} ]

I believe everything in there is correct except for the remainder address. The value there should be 933100.

After reviewing the code, it appears that the issue is that totalTransferValue variable, which should be keeping track of how much is still left to send after applying each balance was getting reset to the total balance on each iteration of the for loop. Moving it out of the loop fixes the issue.

Merge request reports