[rpc-tests] Check return code

[maflcko]

This fixes #6826.

If this PR indeed fixes the issue, travis should fail and imo the PR should be merged nonetheless.

---

Update:
The original commit was 027ca44 with the corresponding failing travis build. Due to requests I force pushed a rebase onto #6828.

(This closes #6828)

[jamesob]

Concept ACK

Edit: though I do think it awkward to merge something that's going to have expected build failures... should we assess how difficult it'd be to implement the fixes and attach them to this PR?

[maflcko]

@jamesob I could only identify #6828. It should be safe to just merge #6828 before this one to prevent the red travis cross in the master branch.

[TheBlueMatt]

If that's the only one, can you just do them in the same PR? It seems overkill for each to have it's own.

On October 14, 2015 11:36:42 AM PDT, MarcoFalke notifications@github.com wrote:

@jamesob I could only identify #6828. It should be safe to just merge
#6828 before this one to prevent the red travis cross in the master
branch.

---

Reply to this email directly or view it on GitHub:
#6827 (comment)

[jamesob]

Agree with @TheBlueMatt

[maflcko]

Done.

[jamesob]

ACK

[TheBlueMatt]

The right way is to fix the expected fees, not change the tolerance to nno longer catch errors.

[TheBlueMatt]

The altnerative is just revert the minRelayTxFee stuff (ie #6722) and merge this afterwards.

[maflcko]

@jonasschnelli @TheBlueMatt Can you elaborate? I may be missing something but the rpc tests should not fail by changing the relayFee. Right now the bitcoin coin selection can only terminate if there is a tolerance of at least 2 bytes. (I.e. the transaction fee is paying for two bytes more than the tx actually has.) Consequently the feeTolerance is 2 bytes times whatever_you_pay_per_byte.

Regardless, #6828 (or this PR, which includes #6828) should be merged independent of #6722 because reverting minRelayTxFee is not "an alternative" to replacing this outdated magic number.

[jonasschnelli]

utACK. But agree with @TheBlueMatt. The fee tolerance change might be controversial. Not sure anymore, but when i first implemented this, fees had a tiny variance because of signature sizes, etc.

It would be nice if we could fix the fee tolerance in a proper way, although, very precise fees are not the main objective to test during fundrawtransaction rpc tests.

[maflcko]

@jonasschnelli I am not changing the behavior of fundrawtransaction. The fee tolerance was already there with 2 bytes * 1 sat/byte = 2 sat and due to #6793 I changed it to 2 bytes * 5 sat/byte = 10 sat. This should be uncontroversial and be enough to get the travis rpc tests back. (If you want to get rid of the 2 bytes tolerance, you'd have to adjust wallet code but that's just really out of scope of this PR)

Also, ping @laanwj for input.

[jonasschnelli]

utACK

[morcos]

ACK

[TheBlueMatt]

Can you update this comment to explain why this is picked (signatures may or may not take an extra byte or two, but never be smaller)

[maflcko]

@TheBlueMatt done.

[laanwj]

Looks good to me. This is the minimum to get the tests working again.