An internal wiki page Examples-of-Rounding-Issues describes a scenario where a tfSell offer fails to cross even though its stated amounts match an existing offer, because the payment engine computes an intermediate quality that's fractionally worse (~10⁻¹³) than the stated quality. Reproduction steps from that page:
`Account const gw("gw");
Account const alice("alice");
Account const carol("carol");
Account const bob("bob");
Env env(*this);
auto pay_ = [&](auto& env, auto const& src, std::vector const& accts, auto const& amt) {
for (auto const& dst : accts)
env(pay(src, dst, amt));
};
env.fund(XRP(1'000), gw, alice, carol, bob);
auto const AAA = gw["AAA"];
auto const BBB = gw["BBB"];
env(trust(alice, AAA(2'000)));
env(trust(carol, AAA(2'000)));
env(trust(bob, AAA(2'000)));
env(trust(alice, BBB(2'000)));
env(trust(carol, BBB(2'000)));
env(trust(bob, BBB(2'000)));
pay_(env, gw, {alice, carol, bob}, AAA(1'200));
pay_(env, gw, {alice, carol, bob}, BBB(1'200));
env(offer(alice, AAA(50), BBB(6)));
env(offer(carol, AAA(1'000.01), BBB(120.0012)));
env(offer(bob, BBB(120.0156), AAA(1'000.13)), txflags(tfSell));`
The wiki claims that without tfSell, this crosses; with tfSell, it does not, because the effective quality computed during crossing falls just short of the stated quality.
Looking at current develop:
OfferCreate.cpp still substitutes an unbounded deliver amount (STAmount::kMaxValue / 2 / kMaxNative) as the target output when tfSell is set, rather than the stated TakerPays (~lines 450–476).
BookStep.cpp's checkQualityThreshold() still does a strict quality >= qualityThreshold_ comparison with no rounding tolerance (~line 462).
I haven't compiled/run this test case myself, so I can't confirm whether it still reproduces. Could someone confirm:
- Whether this test case still fails to cross on current
develop.
- If so, whether this is considered a defect (worth an issue/fix) or intentional/expected behavior of
tfSell.
I am working on retiring the xrpld wiki (in favor of xrpl.org) and need to confirm whether this behavior should be documented.
An internal wiki page Examples-of-Rounding-Issues describes a scenario where a
tfSelloffer fails to cross even though its stated amounts match an existing offer, because the payment engine computes an intermediate quality that's fractionally worse (~10⁻¹³) than the stated quality. Reproduction steps from that page:`Account const gw("gw");
Account const alice("alice");
Account const carol("carol");
Account const bob("bob");
Env env(*this);
auto pay_ = [&](auto& env, auto const& src, std::vector const& accts, auto const& amt) {
for (auto const& dst : accts)
env(pay(src, dst, amt));
};
env.fund(XRP(1'000), gw, alice, carol, bob);
auto const AAA = gw["AAA"];
auto const BBB = gw["BBB"];
env(trust(alice, AAA(2'000)));
env(trust(carol, AAA(2'000)));
env(trust(bob, AAA(2'000)));
env(trust(alice, BBB(2'000)));
env(trust(carol, BBB(2'000)));
env(trust(bob, BBB(2'000)));
pay_(env, gw, {alice, carol, bob}, AAA(1'200));
pay_(env, gw, {alice, carol, bob}, BBB(1'200));
env(offer(alice, AAA(50), BBB(6)));
env(offer(carol, AAA(1'000.01), BBB(120.0012)));
env(offer(bob, BBB(120.0156), AAA(1'000.13)), txflags(tfSell));`
The wiki claims that without
tfSell, this crosses; withtfSell, it does not, because the effective quality computed during crossing falls just short of the stated quality.Looking at current
develop:OfferCreate.cppstill substitutes an unboundeddeliveramount (STAmount::kMaxValue / 2/kMaxNative) as the target output whentfSellis set, rather than the statedTakerPays(~lines 450–476).BookStep.cpp'scheckQualityThreshold()still does a strictquality >= qualityThreshold_comparison with no rounding tolerance (~line 462).I haven't compiled/run this test case myself, so I can't confirm whether it still reproduces. Could someone confirm:
develop.tfSell.I am working on retiring the xrpld wiki (in favor of xrpl.org) and need to confirm whether this behavior should be documented.