Not handling big numbers (>2^64) correctly)

[irisli]

I played around with stellard and found out a few things:

• The smallest amount you can send ".00000000000000000000000000000001" (10^-31). Anything smaller (more digits) doesn't work. I havent found any problems associated with this (other than a stellar-client related one).
• The largest amount you can send is "99999999999999999999999999999999". Anything bigger than this doesn't work.
• If you try to send an amount (using RPC) with an unquoted amount, the highest that stellard will accept is 2^31. (Minor issue but could be confusing)

Sending big amounts

If you try to send a large amount of the currency (such as 99999999999999999999999999999999), it becomes shortened to 1844674407370955e4 (2^64).

Not showing all the numbers

First problem is that stellard truncates the last few digits and doesn't show the exact amount. If you send 99999999999999999999999999999999, it becomes 1844674407370955e4 (2^64) (emphasis on the e4).

Accepting a bigger range than it supports

If you send a large amount such as 99999999999999999999999999999999, it gets reduced to 1844674407370955e4.

Example:

> curl -X POST https://live.stellar.org:9002 -d '
> {
>   "method": "submit",
>   "params": [
>     {
>       "secret": "SECRET",
>       "tx_json": {
>         "TransactionType": "Payment",
>         "Account": "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
>         "Destination": "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
>         "DestinationTag": "215923937",
>         "Amount": {
>             "currency": "0000000000000000000000000000020000000000",
>             "value": "99999999999999999999999999999999",
>             "issuer": "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM"
>         }
>       }
>     }
>   ]
> }'

{
   "result" : {
      "engine_result" : "tesSUCCESS",
      "engine_result_code" : 0,
      "engine_result_message" : "The transaction was applied.",
      "status" : "success",
      "tx_blob" : "120000228000000024000000912E0CDEBCE161D9468DB8BAC710CB0000000000000000000000000000020000000000A875C163F4051AA79FC1298C81CCFE1087880E2368400000000000000A73201FDDBA388A36807579A481B921DD22E15A8C5321F0D15AE83C6E315FF32303BD744009CDB0EA314FD668256F691EC4EF831B19D3230A01A6B25903B028B17852C18C866AF462E30682A7F93E648BE3BC390DEAE62C4F405D37FC2AF0D7CF72188D088114A875C163F4051AA79FC1298C81CCFE1087880E238314457870BC89A13F983892DF95B5EC0D1843048D51",
      "tx_json" : {
         "Account" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
         "Amount" : {
            "currency" : "0000000000000000000000000000020000000000",
            "issuer" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
            "value" : "1844674407370955e4"
         },
         "Destination" : "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
         "DestinationTag" : 215923937,
         "Fee" : "10",
         "Flags" : 2147483648,
         "Sequence" : 145,
         "SigningPubKey" : "1FDDBA388A36807579A481B921DD22E15A8C5321F0D15AE83C6E315FF32303BD",
         "TransactionType" : "Payment",
         "TxnSignature" : "09CDB0EA314FD668256F691EC4EF831B19D3230A01A6B25903B028B17852C18C866AF462E30682A7F93E648BE3BC390DEAE62C4F405D37FC2AF0D7CF72188D08",
         "hash" : "DE4C5088F1D3EBCA7B30BD8C9ED0B1A2973AC3886F862CD893F284268FCF0C6B"
      }
   }
}

Possible overflow

Where might have the rest of the 99999999999999999999999999999999 have went?

It might have overflowed to the issuer part of the amount triplet. Note that the address is shorter than a normal address. It doesn't look like an attack could be possible because of this.

{
  "currency" : "0000000000000000000000000000020000000000",
  "issuer" : "ggggggggggggggggggggBZbvji",
  "value" : "1844674407370955e4"
}

This triplet shows up if you look at the transaction information. Here is the full verbose output on how to find this:

> curl -X POST https://live.stellar.org:9002 -d '
> {
>   "method": "tx",
>   "params": [
>     {
>       "transaction": "DE4C5088F1D3EBCA7B30BD8C9ED0B1A2973AC3886F862CD893F284268FCF0C6B"
>     }
>   ]
> }'
{
   "result" : {
      "Account" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
      "Amount" : {
         "currency" : "0000000000000000000000000000020000000000",
         "issuer" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
         "value" : "1844674407370955e4"
      },
      "Destination" : "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
      "DestinationTag" : 215923937,
      "Fee" : "10",
      "Flags" : 2147483648,
      "Sequence" : 145,
      "SigningPubKey" : "1FDDBA388A36807579A481B921DD22E15A8C5321F0D15AE83C6E315FF32303BD",
      "TransactionType" : "Payment",
      "TxnSignature" : "09CDB0EA314FD668256F691EC4EF831B19D3230A01A6B25903B028B17852C18C866AF462E30682A7F93E648BE3BC390DEAE62C4F405D37FC2AF0D7CF72188D08",
      "hash" : "DE4C5088F1D3EBCA7B30BD8C9ED0B1A2973AC3886F862CD893F284268FCF0C6B",
      "inLedger" : 688970,
      "ledger_index" : 688970,
      "meta" : {
         "AffectedNodes" : [
            {
               "ModifiedNode" : {
                  "FinalFields" : {
                     "Balance" : {
                        "currency" : "0000000000000000000000000000020000000000",
                        "issuer" : "ggggggggggggggggggggBZbvji",
                        "value" : "1844674407370955e4"
                     },
                     "Flags" : 65536,
                     "HighLimit" : {
                        "currency" : "0000000000000000000000000000020000000000",
                        "issuer" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
                        "value" : "0"
                     },
                     "HighNode" : "0000000000000000",
                     "LowLimit" : {
                        "currency" : "0000000000000000000000000000020000000000",
                        "issuer" : "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
                        "value" : "1844674407370955e4"
                     },
                     "LowNode" : "0000000000000000"
                  },
                  "LedgerEntryType" : "RippleState",
                  "LedgerIndex" : "18781E378CEA5729D813F648394A5E46718EFC3DC4409D893EBDBB91CF90B042",
                  "PreviousFields" : {
                     "Balance" : {
                        "currency" : "0000000000000000000000000000020000000000",
                        "issuer" : "ggggggggggggggggggggBZbvji",
                        "value" : "0"
                     }
                  },
                  "PreviousTxnID" : "E609CF1BCE91615BE47C01813443C30BC508491984AC82ED9F7D328BD063D85D",
                  "PreviousTxnLgrSeq" : 688969
               }
            },
            {
               "ModifiedNode" : {
                  "FinalFields" : {
                     "Account" : "gGMjbshdme85rVoQLjNwQUysFgrQNEAcgM",
                     "Balance" : "1086696407",
                     "Flags" : 0,
                     "InflationDest" : "g4eRqgZfzfj3132y17iaf2fp6HQj1gofjt",
                     "OwnerCount" : 22,
                     "Sequence" : 146
                  },
                  "LedgerEntryType" : "AccountRoot",
                  "LedgerIndex" : "F8C947E970F5827EB6B8AD3A695AEBCBD93612C3F188DCE7DE5C6C8A259EAB67",
                  "PreviousFields" : {
                     "Balance" : "1086696417",
                     "Sequence" : 145
                  },
                  "PreviousTxnID" : "E609CF1BCE91615BE47C01813443C30BC508491984AC82ED9F7D328BD063D85D",
                  "PreviousTxnLgrSeq" : 688969
               }
            }
         ],
         "TransactionIndex" : 1,
         "TransactionResult" : "tesSUCCESS"
      },
      "status" : "success",
      "validated" : true
   }
}

[JoelKatz]

This is just one of the many reasons you should be signing your own transactions. You're trusting the server to form the correct amounts and generate the actual underlying transaction. If you feed garbage in, you will not only get garbage out, but you will get signed garbage!

The issue is not big amounts but illegal amounts. "99999999999999999999999999999999" is an illegal amount. Not because it is too large, but because it has too much precision.
https://wiki.ripple.com/Currency_format#Rationale
"The legal exponent range is -96 to +80. With the exception of 0 (which is represented as a mantissa of zero), the legal mantissa range is 10^15 to 10^16 -1."

[irisli]

Thanks @JoelKatz for the info. Then the next thing here is if we want to add a warning in stellard when someone tries to create a transaction with an illegal amount or do we just expect the user to know what the legal limit is.

One thing that still remains though is that stellard should show all the significant digits of a number instead of shortening it into something like 1844674407370955e4. It should show all the digits like 18446744073709551615

[irisli]

Amending my previous comment after understanding more about rippled/stellard:

Stellard represents my large amount as 1844674407370955e4 because it is actually 18446744073709550000 (and not 18446744073709551615). There was too much precision and therefore 1615 credits were lost due to stellard flooring it.

I recently did a test and found that stellard floors truncates the lost precision amounts. Here are my test results (sending and receive a credit, showing full precision given by stellard).

     42.12360172934135
+ 10000
= 10042.12360172934
- 10000
=    42.12360172934
+      .0000000000777777
=    42.12360172941777

The lost precision isn't hidden but is rather "burned".

This is actually more of a protocol issue than a rippled/stellard issue although rippled/stellard are opaque in how amounts are handled.

[JoelKatz]

@irisli If you're going to form transactions, you need to understand the rules for forming valid transactions. The "user" in this context is the software that's forming and signing transactions -- it has to understand the serialization format. If it can produce data that's not in canonical form, the signature isn't going to be valid.