You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After posting the below multi-payment unit, I get the following validation error:
{"error":"inputs and outputs do not balance: 1000 !== 1000 + 681 + 508"}
It looks like the payment validation doesn't know which payment message was used to pay the fees. In this example, the fees are paid from the second message, still the validation assumes it was paid from the first payment message.
Expected behavior: the composer should add the fee paying message as first if the validation assumes that; or the validation should be intelligent enough to find out which message paid the fees.
I used the divisible_asset.composeAndSaveDivisibleAssetPaymentJoint function to generate this unit with an extra payment message which the composer placed in the first position.
A calculation that proves the fees are paid from the second payment:
sqlite> select sum(amount) from outputs where unit='u0EIU2LlYc87lYrM7KukLdq5/I6zMHPatpiU192m7Xk=' and is_spent=0 and asset is null;
sum(amount) = 4959
4959 - 681 - 508 = 3770
Unit that I tried to post on the testnet and resulted in the validation the error:
The above unit breaks another rule: it has two messages with payments in bytes, which is not allowed.
if (objValidationState.bHasBasePayment)
return callback("can have only one base payment");
objValidationState.bHasBasePayment = true;
The bytes payment doesn't have to be the first but it must be unique. The error message is misleading indeed since the first message is checked first but the unit is invalid anyway. You have to merge the two bytes payments in one message.
I see. I didn't know about that restriction. It's gonna be tricky to combine the base payments and issue an asset in one unit. My goal here is to sweep 1000 bytes from a smart contract and issue 1 asset in exchange all in as single unit, but it appears a difficult task to solve with the current API.
After posting the below multi-payment unit, I get the following validation error:
It looks like the payment validation doesn't know which payment message was used to pay the fees. In this example, the fees are paid from the second message, still the validation assumes it was paid from the first payment message.
Expected behavior: the composer should add the fee paying message as first if the validation assumes that; or the validation should be intelligent enough to find out which message paid the fees.
I used the
divisible_asset.composeAndSaveDivisibleAssetPaymentJoint
function to generate this unit with an extra payment message which the composer placed in the first position.A calculation that proves the fees are paid from the second payment:
Unit that I tried to post on the testnet and resulted in the validation the error:
The text was updated successfully, but these errors were encountered: