PreviousFields missing TakerGets

[inmyth]

This occasionally happens in subscription where ModifiedNode's PreviousFields is missing TakerGets like below. I believe in normal response both TakerGets and TakerPays should exist. As I'm using ripple-lib-java the parser would return null exception. If this is a correct behavior would someone explain to me the meaning of no TakerGets ? Some sample tx where this happens are :

• 5C5D507B8D33DF36DD598D2EC4443D5EF0301D9629A8455A88D27F8F2B96BDC1
• F21E52A5C16FBD052E723BE811F962FE54644F3523BA4E593E6A5F48B8D02E16
• A42B485F1B8ED8ADE41E4F2BC06248D761CB216248415CE46559B9767C278C8C

        {
          "ModifiedNode": {
            "FinalFields": {
              "Account": "rKLPBY3nEhETSThEfWRaHNBH1Rxeo57UGn",
              "BookDirectory": "6CBBA821BB26420284E9C91F4E8B5D66FA66DDB55163D1F54A16EA3D901EFD40",
              "BookNode": "0000000000000000",
              "Flags": 0,
              "OwnerNode": "0000000000001142",
              "Sequence": 185846,
              "TakerGets": "5000000000",
              "TakerPays": {
                "currency": "BTC",
                "issuer": "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS",
                "value": "0.3224999809395302"
              }
            },
            "LedgerEntryType": "Offer",
            "LedgerIndex": "0AF9357F71535A90E94304AFDB531722F9F4898A70B93E430C4F8BADEA9D0FD1",
            "PreviousFields": {
              "TakerPays": {
                "currency": "BTC",
                "issuer": "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS",
                "value": "0.3224999809744544"
              }
            },
            "PreviousTxnID": "E4AD49194E32791845BF2FBCF5C48D47673608C5BA8D4C75DE4E22237D221DEC",
            "PreviousTxnLgrSeq": 31757659
          }
        }

[sublimator]

Interesting. Is it always XRP when it's missing ?

[sublimator]

In [1]: 0.3224999809744544 - 0.3224999809395302
Out[1]: 3.492423017448232e-11

In [2]: 0.3224999809395302 / 5000000000.
Out[2]: 6.449999618790604e-11

Out[1] is the difference between before and after of TakerPays, and Out[2] is the amount of BTC per drop. It seems there was not enough BTC taken to take a whole drop, the smallest quantity of XRP possible.

?

[sublimator]

Seems like a bug really

[JoelKatz]

If the value doesn't change, the previous value doesn't appear under PreviousFields. If the amount of XRP rounds down to zero, then there's no change.

Though the current code does this more often than I think it should, it will happen at least some of the time no matter what. (Consider an offer to buy 1 FOO for 2 drops and where the first use is a payment that takes 0.5 FOO.)

[sublimator]

Those cases can't be detected and the offer just ignored? Spam/ledger consistency worries?

[JoelKatz]

On Mon, Aug 7, 2017 at 9:27 PM, sublimator notifications@github.com wrote:

Those cases can't be detected and the offer just ignored? Spam/ledger consistency worries?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ripple/rippled/issues/2199#issuecomment-320846867, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1j7apUER_Xoaa0_5ACSqcVcXoNjxOQks5sV-POgaJpZM4OwNxQ .

The offer changed, just not on the XRP side. What do you think should happen if a payment gives 10 FOO from an offer to buy 20 FOO for 1 drop?

We can't fail the payment or remove the offer without taking from it or we get denial of service attacks. If we move one drop, we're leaving an offer with no XRP on it. If we just sell the 10 FOO, we've ignored the user's request to sell 20 FOO and (among other problems) made it much more difficult to remove trust lines.

[sublimator]

Any plans to break the atom (drop) ?

[inmyth]

So far I observe this happening on XRP trade only. I take it it's up to client to process or ignore such offer ? Also does this happen intentionally ? It's difficult to see why someone would trade fractions of drops when each submission costs 12 drops.

[sublimator]

I take it it's up to client to process or ignore such offer ?

If you meant to handle these odd metadata cases, rather than make assumptions about both TakerX fields changing then I guess the answer is yes.

Seems like they made subtle tradeoffs.

does this happen intentionally ? It's difficult to see why someone would trade fractions of drops

Maybe the tip of the book only partially consumes an offer/payment, and there's a tiny fraction left?

[JoelKatz]

@inmyth They may have no choice. For example, they may be trying to pay, sell, or buy 1 bitcoin and have an offer for 0.9999999999999 bitcoins that they take. They will then wind up taking 0.0000000000001 bitcoins from the next offer to complete their 1 bitcoin purchase, sale, or payment, and that might take less than a drop from that next offer.

[bachase]

Closing this given that this behavior is as intended. Thanks for your inquiry.