Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer expiration field has no effect #141

Closed
dchapes opened this issue Aug 2, 2013 · 6 comments
Closed

Offer expiration field has no effect #141

dchapes opened this issue Aug 2, 2013 · 6 comments

Comments

@dchapes
Copy link

dchapes commented Aug 2, 2013

Perhaps I'm misreading the wiki documentation for offer_create or this feature is just not implemented yet (which if either is true implies the wiki should be updated). The following assumes that the "Expiration" field has the same format as other Ripple times and is an absolute time; e.g. that "Expiration": 428679695 represents an expiration time of Thu 1 Aug 2013 13:41:35 UTC. (i.e. the result of date -u -r expr 428679695 + 946684800 as per the wiki documentation on Ripple time formats)

Transaction C942A879310087A5461490D079A35E50D16E7405AC9F381AD96CB580CE12FEEA added a offer like so:
Aug 1 13:40:40 UTC Offer dchapes seq=440 will take 0.01 GDW/Goodwill for 1 XRP @ 0.01 (expires 2013-08-01 13:41:35 +0000 UTC)
After the supposed expiration time the offer still appeared in the order book and was taken by transaction BA82C45DBC615E83EE97FB85F76BC88B431149A630786460CA0BA1F67F2F377D:
Aug 1 20:08:30 UTC Offer xxxx seq=177 will take 1 XRP for 0.01 GDW/Goodwill @ 100 : Flags=0x00080000

The relevant parts of the transactions are:

"CreatedNode": {
"LedgerEntryType": "Offer",
"LedgerIndex": "C0B9A44082C270EA8B7895EBB69A9C7B84D0AFDD8CC063C45DFF1DA1F7AEB552",
"NewFields": {
  "Account": "rQ96qm46YsRX2F7SSCQxToR2ybRuUYsZ4R",
  "BookDirectory": "310713758521807E476386E3A31F43108B8AB791851350204D038D7EA4C68000",
  "Expiration": 428679695,
  "OwnerNode": "0000000000000002",
  "Sequence": 440,
  "TakerGets": "1000000",
  "TakerPays": {
    "currency": "GDW",
    "issuer": "rGDWKWni6exeneJdNbEZ3nVX3Rrw5VG1p1",
    "value": "0.01"
  }
}

and

"DeletedNode": {
  "FinalFields": {
    "Account": "rQ96qm46YsRX2F7SSCQxToR2ybRuUYsZ4R",
    "BookDirectory": "310713758521807E476386E3A31F43108B8AB791851350204D038D7EA4C68000",
    "BookNode": "0000000000000000",
    "Expiration": 428679695,
    "Flags": 0,
    "OwnerNode": "0000000000000002",
    "PreviousTxnID": "C942A879310087A5461490D079A35E50D16E7405AC9F381AD96CB580CE12FEEA",
    "PreviousTxnLgrSeq": 1501926,
    "Sequence": 440,
    "TakerGets": "0",
    "TakerPays": {
      "currency": "GDW",
      "issuer": "rGDWKWni6exeneJdNbEZ3nVX3Rrw5VG1p1",
      "value": "0"
    }
  },
  "LedgerEntryType": "Offer",
  "LedgerIndex": "C0B9A44082C270EA8B7895EBB69A9C7B84D0AFDD8CC063C45DFF1DA1F7AEB552",
  "PreviousFields": {
    "TakerGets": "1000000",
    "TakerPays": {
      "currency": "GDW",
      "issuer": "rGDWKWni6exeneJdNbEZ3nVX3Rrw5VG1p1",
      "value": "0.01"
    }
  }
}

"tx": {
  "date": 428702910,
  
}
@JoelKatz
Copy link
Collaborator

JoelKatz commented Aug 5, 2013

This does appear to be a bug. A crossing offer took an offer that expired prior to the time the parent ledger closed. I will investigate.

@alexdupre
Copy link
Contributor

Are you able to reproduce it with the current rippled servers? I was unable, the second crossing offer deleted the first (since it was expired), but didn't take it, and in fact the second one has been added to the order book.

@dchapes
Copy link
Author

dchapes commented Nov 7, 2013

Thank you for looking into it. The bug still exists although perhaps in a modified way.
I can't repeat it when making a crossing offer either with the same or a different account.

However, the expired offer still shows in the book_offers results (other unfunded offers don't) and, more importantly, in the results of ripple_path_find (based on the price/rate returned). Using a payment transaction I was able to take from an expired offer. The payment transaction did remove the offer instead of shrinking it but it shouldn't have let anything be taken from it.

For example (again with GDW and XRP):
Nov 7 17:57:20 UTC Offer 1192 giving 115 XRP for 1 GDW/Goodwill @ 115 (expires 2013-11-07 17:58:09 +0000 UTC)
Nov 7 18:09:10 UTC Routed payment from rfo to rfo 0.0115 XRP(sendmax: 0.000101 GDW/rfo)
(Then next best bid was at 10 XRP/GDW and the best ask was ~180 XRP/GDW).

The second payment tx is the interesting one, it was tx B0D7589E51BD3CB02FF1B149730750C38992D9B2BF8A31A0C765D2F217850FDE. It shows that -0.011500 XRP and 0.00001 GDW were traded/exchanged before deleting the remaining portion of the offer. I assume I could have taken as much of the offer as desired as long as it was done in a single payment transaction.

@JoelKatz
Copy link
Collaborator

JoelKatz commented Nov 8, 2013

This is a bug. A payment can take from an expired offer. The offer will always be removed, but it can be partially taken from.

@alexdupre
Copy link
Contributor

I think you erroneously removed the 'continue' statement in this commit: 5a9416f

@JoelKatz
Copy link
Collaborator

JoelKatz commented Nov 8, 2013

Guilty as charged. Fixed in 46861fa

@JoelKatz JoelKatz closed this as completed Nov 8, 2013
rec pushed a commit to rec/rippled that referenced this issue Sep 9, 2015
Workaround for windows min and max macros with std::min and std::max
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants