Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

DrPolar's Achievements

  1. Well, I tried everything from issuing 9,999,999 for "10" USD to 10,000,001 for "10" USD and +/-24 on each side of the drops. Nothing. Then I tried 10,000,000 for 9.99 USD and 10,000,000 for 10.01. Nothing is moving that outstanding Buy order.
  2. That was just suggested on another forum. I will give that a try. But I am kind of miffed at this. Somebody suggested it is a "rounding" error with floating point interpretations of strings. Just for all our information, does anybody know what restrictions on the depths of floating point decimal is? One would think, that this protocol swallows text based JSON and the value strings should have a pretty determinate conversion specification. Is there a specification, or is it just whatever string to number parser implementation the server(s) are using?
  3. I can provide the accounts. If you look them up on https://test.bithomp.com/explorer/ A = rK6gsSCrcMa7sG5nZo5M1afyaSwhUwvhR5 B = rh1uSQTQAEQMBog9vcRoPRztrVLQ9yzxMe C = rJojTfWow9ZTUPFof9soQPLJPNN9ms1YAU you can get the transactions. The current situation is that there is some USD/C in A because of previous mentioned experiments. However, you can see that there is a B Buy USD order sitting on the ledger, and A has multiple matching Sell orders.
  4. A has XRP, and B has 1000 USD/C. A creates a Buy order (trading XRP for USD/C). So, A is funded. B creates a Sell Order (trading USD/C for XRP). So, B is funded. As far as I can tell, the orders are matching. As I said above, if I reverse the order of the submission of OfferCreates it works. That is, if I perform the Sell Order from B (taker gets USD/C, taker pays XRP) then perform the Buy Order from (taker pays USD/C, taker gets XRP), it works, and the Sell order disappears from the ledger. However, if I do the Buy order first, then the Sell Order, both objects sit on the ledger. Thanks for the warning on using the USD. I may now try to understand Rippling. I need to look at that more. So, you can ripple through two different issued currencies of the same moniker? In any case, rippling is turned off on all accounts.
  5. I am trying to build an Exchange on XRPL using xprljs, or at least I should say that I am just going through the motions to understand it better. I have created three accounts on the TestNet, which I will call A, B, C. C is the issuer for the USD, which I will label as USD/C. I started the accounts such that A has no USD/C, B has 1000 USD/C, and C has -1000 USD/C. I have set set trust lines from A to C and B to C to each hold a large amount of USD/C. First, I created a Buy Offer from A to buy 10USD/C for 10e6 drops. Second, I have created a Sell Offer from B to sell 10USD/C for 10e6 drops. The Sell order did not get resolved, and both the Buy and Sell orders remain on the ledger not moving. This Sell order will not get resolved, unless I issue another matching (identical) Buy order. And the "old" Buy order remains on the ledger. Now, I have done this in the reverse order, issuing the Buy order from A first, and then second, create the sell order from B. Then the sell OfferCreate gets resolved immediately and he transfer executes, and there are no buy or sell orders left on the ledger. Furthermore, I can keep issuing Sell OfferCreates from B and they will pile up over any outstanding Buy Orders, regardless of how many Buy or Sell orders there are on the ledger. It seems odd to me, because what this means (to me) is that I cannot issue Sell OfferCreates based on outstanding Buy OfferCreates. I had thought that the direction would not matter. Is this not the case? If I looked at the order book for buys, how could I choose (or wait for) a suitable buy order and match it with a Sell Order and have it execute. What am I not understanding?
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.