stellar-deprecated / stellard

INACTIVE. Server in the Stellar network. Maintains the distributed ledger. Introduces and validates transactions. This repo is not in active development, it is being replaced by stellar-core.

INACTIVE. This repository is not in active development. It is being replaced by stellar-core

#stellard - Stellar P2P server

This is the repository for Stellar's stellard, reference P2P server.

###Build instructions:

• https://github.com/stellar/stellard/blob/master/doc/building-stellard.md

Vagrant (your very own testnet)

1. Install vagrant (http://www.vagrantup.com/)
2. run vagrant up
3. There is no step 3.

You now have a running testnet accessible on ports 9001 (websocket) and 9002 (rpc). It will not connect to other instances and will have it's own ledger set.

NOTE: running vagrant provision will reset your ledger, starting you over from scratch

Repository Contents

./bin

Scripts and data files for Stellar integrators.

./build

Intermediate and final build outputs.

./Builds

Platform or IDE-specific project files.

./doc

Documentation and example configuration files.

./src

Source code directory. Some of the directories contained here are external repositories inlined via git-subtree, see the corresponding README for more details.

./test

Javascript / Mocha tests.

Running tests

mocha test/*-test.js

License

Stellar is open source and permissively licensed under the ISC license. See the LICENSE file for more details.

For more information:

• https://www.stellar.org
• https://www.stellar.org/developers/

stellard's Issues

Newlines in JSON payload can cause failure

Putting the below JSON in post.json and submitting it via curl -H "Content-Type: application/json" -X POST https://live.stellar.org:9002 -d - < post.json gets a response containing "Unable to parse request". If I remove all of the new lines and indentation, it works.

{
    "method": "submit",
    "params": [
        {
            "secret": "<secret>",
            "tx_json": {
                "TransactionType": "TrustSet",
                "Account": "gK7NVjpKeR54Y8dEBqPTye9MW4C69cvWCK",
                "LimitAmount": {
                    "value": "20",
                    "currency": "NZD",
                    "issuer": "gs9HHU3pmkKBuvykhNm6xiK1JKrput9i3K"
                }
            }
        }
    ]
}

Fee pool doesn't get passed

I start server A with --start
make a couple transactions
connect server B that was started with --net and a clean DB
server B gets a different fee pool amount than A

Stellarize rippled-example.cfg

server_info should report the number of websocket connections

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

• LDBCommand
• ReplayIteratorImpl::cleanup
• Table::Open

account_tx ignores "forward" key if ledger_min/ledger_max set

When sending an account_tx RPC call, the "forward" key is ignored if the "ledger_min" or "ledger_max" keys are included (even if both are set to -1).

Furthermore, when not using "ledger_min"/"ledger_max", the (undocumented in Stellar, but documented in Ripple) "marker" field is present in the result, and can be used on subsequent calls. But if "ledger_min" or "ledger_max" is used, "marker" disappears and instead we get "offset".

Similarly, if "offset" is present in the request, then "marker" is not returned and instead "offset" shows up in the response, though this bit isn't particularly surprising. FWIW "forward" works just fine with "offset", as long as "ledger_min" and "ledger_max" are omitted.

Unable to reach full range of destination tags (dt) with RPC

A DestinationTag is stored as a uint32 meaning it has a range from 0 to 4294967295 (2^32-1).

For some reason, I can't submit with dt > 4294967289 via RPC but I can submit them with the stellar-client.

Example (sends .1 STR to an account (my ili test account) that requires dt):

This works

curl -X POST https://live.stellar.org:9002 -d '
{
  "method": "submit",
  "params": [
    {
      "secret": "sMasterSeedHereXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "tx_json": {
        "TransactionType": "Payment",
        "Account": "gAccountIDHereXXXXXXXXXXXXXXXXXXXX",
        "Destination": "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
        "Amount": "1000000",
        "DestinationTag": 4294967289
      }
    }
  ]
}'

This doesn't work:

curl -X POST https://live.stellar.org:9002 -d '
{
  "method": "submit",
  "params": [
    {
      "secret": "sMasterSeedHereXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "tx_json": {
        "TransactionType": "Payment",
        "Account": "gAccountIDHereXXXXXXXXXXXXXXXXXXXX",
        "Destination": "gfLKu2CSsprSRpETxgzadNzYaHiW8L9YCC",
        "Amount": "1000000",
        "DestinationTag": 4294967290
      }
    }
  ]
}'

Add Windows build instructions to Wiki

The Stellard Build wiki page (https://wiki.stellar.org/Building_Stellard) links to a non-existent Visual Studio 2013 Build Instructions page.

Create this page.

change static_path_find to allow you to specify the amount to send.

remove the source_currencies field
add a field source_amount
if source amount has a value then the value can't also be set in the destination_amount field.

Now you can say I want the receiver to get 200 EUR. What amount of currencies do I need to send to him to get there.

This change allows you to say I have 1000 USD and I want the receiver to get EURs what is the path.

Server hangs on ubuntu

when you start up with no db on ubuntu using --start. It will hang.

Here is the .cfg

[peer_ip]
0.0.0.0

[peer_port]
52001

[websocket_public_ip]
0.0.0.0

[websocket_public_port]
9001

[websocket_secure]
0

[rpc_ip]
0.0.0.0

[rpc_port]
9002

[rpc_allow_remote]
1

[ledger_history]
full

[node_size]
medium

[ledger_history]
full

[node_db]
type=LevelDB
path=/var/lib/stellard/node

[database_path]
/var/lib/stellard/db

[debug_logfile]
/stellard-src/vagrant/debug.log

[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org

[validation_seed]
sasjHMUsFhFbXQDJ5vZ77XuWeFm8s

[validation_quorum]
1

Unprintable currency code causes api to fail

Same issue as XRPLF/rippled#422. It appears not to have been fixed in stellard.

I believe ledger entry EE7C5EADC9EF67F579F6CDC188D1BB349F4D122997F6C0EC551E8B98A3304CA1 has an unprintable currency code, so any api call that involves it fails.

The binary representation of the entry is:

11007222000200002500055CC5370000000000000000380000000000000000550FAEF87C0A271
3B15005ECCBD2642D2B349A041C12C2E805A2F9244E7CAF6BD56295DFDE2ADFA2A00000000000
00000000000000009920200000000000000000000000000000000000000000000000000166800
0000000000000000000000000000000000000992020000000000004D072CAE760D8631FA815CD
AE2DFFBB8788DE8D67D8C38D7EA4C68000000000000000000000000000992020000000000009A
1243667C31080E0F2AEAAC4A00BA7C708F6BC

and I think 0x992020 is the currency code in this case.

When all your peer slots are full you should still give your peer list to nodes that connect before you hang up on them.

'forward' parameter doesn't work for account_tx

limit 1 offset 0 should be the last transaction if forward=true and the first transaction if forward=false

Clear InflationDest if Account hasn't been active

Should probably happen when Inflation Voting happens. We need to see if there has been any activity on this account in the last year or something.
Probably requires a new field in account to put in the time of last activity.

We don't need this if Accounts get cleaned up after some time.

Slow ledger download

Hi @nullstyle We spoke at yesterday's meetup about slow ledger downloads and lots of error msgs.

Things are going much smoother today--fewer Timeout messages--but its still pretty slow so I thought I'd post what I was seeing. At this rate, I think it will take approx 3 days or so for me to completely sync the entire ledger.

As promised, here is the output from console:

2014-Aug-13 18:13:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:13:56 InLedger:WRN Timeout(1) pc=4 acquiring 67A6C1D96BB8FC371DB9411CFB768CFF9108941DA02E34D26B8F11E85A305B38
2014-Aug-13 18:14:00 LoadManager:WRN time jump
2014-Aug-13 18:14:26 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:14:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:15:03 NetworkOPs:WRN Got TX data with no consensus object
2014-Aug-13 18:15:12 InLedger:WRN Timeout(1) pc=1 acquiring 4C2ADCF414EDE79F375F453E5E83BDC59D1AD51EF893DAF520B651579133FC67
2014-Aug-13 18:15:19 LoadManager:WRN time jump
2014-Aug-13 18:15:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:15:56 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:16:14 InLedger:WRN Timeout(1) pc=4 acquiring 8700D0009E55FC53109AB886ABA287F3113D75E2CC952BD7D040BC06F719553D
2014-Aug-13 18:16:20 LoadManager:WRN time jump
2014-Aug-13 18:16:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:16:41 InLedger:WRN Timeout(1) pc=4 acquiring 351E2EFACEDE2442115E4ADF2D2E70776363481996F8F178CF9D602A6DB15531
2014-Aug-13 18:16:48 LedgerTiming:WRN CLC::shouldClose range Trans=no Prop: 5/0 Secs: -2000 (last: 2006)
2014-Aug-13 18:16:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:17:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:17:56 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:17:58 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/1 Secs: -2000 (last: 3005)
2014-Aug-13 18:18:00 LoadManager:WRN time jump
2014-Aug-13 18:18:02 LoadManager:WRN time jump
2014-Aug-13 18:18:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:18:28 LedgerTiming:WRN CLC::shouldClose range Trans=no Prop: 5/1 Secs: -2000 (last: 2005)
2014-Aug-13 18:18:48 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2009)
2014-Aug-13 18:18:55 LoadManager:WRN time jump
2014-Aug-13 18:18:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:18:58 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/3 Secs: -2000 (last: 2004)
2014-Aug-13 18:19:05 LoadManager:WRN time jump
2014-Aug-13 18:19:18 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2005)
2014-Aug-13 18:19:22 LoadManager:WRN time jump
2014-Aug-13 18:19:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:19:38 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2006)
2014-Aug-13 18:19:38 Peer:ERR We do not have the map our peer wants 54.221.208.116:52001
2014-Aug-13 18:19:48 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2004)
2014-Aug-13 18:19:56 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:20:08 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2006)
2014-Aug-13 18:20:12 LoadManager:WRN time jump
2014-Aug-13 18:20:14 LoadManager:WRN time jump
2014-Aug-13 18:20:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:20:38 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/1 Secs: -2000 (last: 2005)
2014-Aug-13 18:20:42 LoadManager:WRN time jump
2014-Aug-13 18:20:46 LoadManager:WRN time jump
2014-Aug-13 18:20:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:21:12 LoadManager:WRN time jump
2014-Aug-13 18:21:14 LoadManager:WRN time jump
2014-Aug-13 18:21:18 LedgerTiming:WRN CLC::shouldClose range Trans=yes Prop: 5/0 Secs: -2000 (last: 2004)
2014-Aug-13 18:21:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:21:26 LoadManager:WRN time jump
2014-Aug-13 18:21:46 LoadManager:WRN time jump
2014-Aug-13 18:21:56 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:22:26 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:22:55 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:23:25 PeerFinder:WRN Endpoints drop    54.221.208.116:52001 as duplicate
2014-Aug-13 18:23:32 LoadManager:WRN time jump

Thanks!

Split cpp files back out of these rippl_app_pt#.cpp files

statically link libsodium on linux

convert to the SConstruct:

if ! pkg-config libsodium; then
   echo -lsodium
elif dir=$(pkg-config --variable=libdir libsodium) \
   && test -f "$dir/libsodium.a"; then
   echo $(pkg-config --cflags libsodium) "$dir/libsodium.a"
else
   pkg-config --cflags --libs libsodium
fi

Write trust line test

There is something that is failing for me on the ripple network so we might as well write a test case for it and see if we can duplicate the problem.

Write a test in the existing testing framework that does the following:
create accounts: A,B,GW1,GW2,GW3

A trusts GW1 GW2 GW3 each for 100 BTC
B trusts GW3 for 100 BTC

A is sent 5 BTC from GW1
A is sent 5 BTC from GW2
A is sent 5 BTC from GW3

A sends 3 BTC to B

does the final send work?

Design sending/receiving anonymously

Refactor RippleAddress

right now it does this super gross checking of what the type of thing it is actually holding and has switches all over the place to see if you can do certain things depending on this type flag. For example: RippleAddress::humanNodePublic ()

Two tests started failing after moving to latest stellar-lib(ripple-lib)

Transaction to Change InflationDest

Changes the InflationDest field in AccountRoot

create Docker file for stellard

Build Fails on Mac OS X

Currently compilation is failing on Mac OS X using clang. The important bits of the error are below:

In file included from src/ripple_data/crypto/StellarPrivateKey.cpp:1:
In file included from src/ripple_data/crypto/StellarPrivateKey.h:4:
In file included from src/ripple_data/crypto/../protocol/RippleAddress.h:23:
In file included from src/ripple_data/crypto/../protocol/../crypto/Base58Data.h:35:
src/ripple_data/crypto/../../ripple/types/api/Base58.h:86:24: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
    static std::string encode (InputIt first, InputIt last,
                       ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iosfwd:188:33: note: template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^

I assume building on linux with gcc/g++ works, and a quick google search leads me to believe this is one of the nuances of clang. I'm working on a fix and will submit a PR soon.

refactor RPCHandler::transactionSign

in comment at top of function

Add an admin command that allows you to set an arbitrary .cfg value

implement inflation

Describe the stellar protocol in an RFC style document

Stellar aims to be become an "common financial platform, designed to be open and accessible to everyone".

It would greatly benefit from a precise documentation of the protocol.

Successful open systems like the World Wide Web have shown that it is crucial to have a precise definition of the underlying protocol to allow anyone to create interoperable implementations.

Make sure the master account can't be deleted

this guy: gHb9CJAWyB4gj91VRWn96DkukG4bwdtyTh

Better API for transaction history

Clean up where status goes in the API

stellard account_currencies gnnVq3ghZ3xoRE9tG78zCh5AWodVmEey32

if this succeeds you get something like:
{
"result" : {
"ledger_current_index" : 21574,
"receive_currencies" : [],
"send_currencies" : [],
"status" : "success"
}
}

if it fails you get something like:
{
"result" : {
"error" : "ledgerIndexMalformed",
"request" : {
"account" : "gnnVq3ghZ3xoRE9tG78zCh5AWodVmEey32",
"command" : "account_currencies",
"ledger_index" : 0
},
"status" : "error"
}
}

We need to have the status be either in the result object or outside of it. it can change relation depending on if there is an error or not.

contracts

Ledger:WRN Can't get seq 0 from 3 error

Fix this

Add uptime to server_info

vagrant kill issue

huh, I just installed vagrant and virtualbox on my OS X machine and ran vagrant up, and it finished building. And one of the very final steps, which is to kill the stellard process that was spun up just to initialize the ledger, apparently passes the wrong flags to kill. Awesome

Stellard occasionnaly throws SHAMapMissingNode exc. on Windows

Inflation doesn't happen every week

I'm investigating, why Inflation doesn't happen when it supposed to:
All inflations go to address g4eRqgZfzfj3132y17iaf2fp6HQj1gofjt, because it has 97 bln STR behind it.

1. First inflation happened in ledger 113 (not July 1st as it's written in stellard comments)
   TIME STAMP: 1405300900
   DATE (M/D/Y @ h:m:s): 07 / 14 / 14 @ 1:21:40am UTC

2. Second inflation in ledger 17018 (too early)
   TIME STAMP: 1405635360
   DATE (M/D/Y @ h:m:s): 07 / 17 / 14 @ 10:16:00pm UTC

3. Third inflation in ledger 75519
   TIME STAMP: 1406800490
   DATE (M/D/Y @ h:m:s): 07 / 31 / 14 @ 9:54:50am UTC

4. Fourth inflation in ledger 75521 (just 30 seconds later)
   TIME STAMP: 1406800520
   DATE (M/D/Y @ h:m:s): 07 / 31 / 14 @ 9:55:20am UTC

And that's it, no other inflations so far.
Please check, something's wrong.

package.json does not have stellar-lib listed

I ran npm install and then did a test and it said that stellar-lib was not installed. I did a npm install stellar-lib and then npm test worked.

Does an entry for stellar-lib need to be added to package.json?

What does it mean when stellard returns "Current ledger is unavailable."?

I'm running stellard via docker.

Does stellard connect to an existing network, by default?

How do I know whether stellard is connected to a network of other nodes?

What does this error mean when returned by stellard after it has been running for a while?

root@solar:~/stellard# curl -X POST 172.17.0.13:9102 -d '{ "method" : "ledger" }'
{
   "result" : {
      "error" : "noCurrent",
      "error_code" : 12,
      "error_message" : "Current ledger is unavailable.",
      "request" : {
         "command" : "ledger"
      },
      "status" : "error"
   }
}

What's the recommended way to configure stellard so that it's useful and usable?

account_tx returns no accounts if ledger_min omitted

The documentation claims that the ledger_min parameter for account_tx is optional and defaults to 0. Similarly ledger_max is optional and defaults to -1. If either (or both) are provided, with their default values, then everything works correctly. But if neither parameter is provided, the returned transaction list is empty.

> curl -X POST https://test.stellar.org:9002 -d '
{
  "method": "account_tx",
  "params": [{
    "account": "ganVp9o5emfzpwrG5QVUXqMv8AgLcdvySb"
  }]
}'

{
  "result": {
    "account": "ganVp9o5emfzpwrG5QVUXqMv8AgLcdvySb",
    "ledger_index_max": 32630,
    "ledger_index_min": 32630,
    "status": "success",
    "transactions": []
  }
}

M-of-N design

allow people to delete accounts

STR is not checked as a bad currency but XRP is

https://github.com/stellar/stellard/blob/86549bc32b24a96a5bcf95d1d855859484f6d3b6/src/ripple_data/protocol/SerializedTypes.h#L66

0x5852500000000000

should be:

0x53545200000000000

Kind of a big security issue this one.

Add a field to AccountRoot for inflation vote

name: InflationDest
type: Account
flag: Required

sign message to prove address ownership

(I also created a client issue for this)

Please add a feature to the server which allows a user to sign a message or string with the private key, and then allow another user to verify the signature proving the owner of an address authored the message.

I would suggest a stellard api call for sign_message(secretkey,message) -> signature and validate_message(address,sig,message) -> bool

Bitcoin clients have this, and its pretty important to be able to prove a gateway or address owner really did author a document.

This change is critical to support sending secure payment instructions to gateways.
A stellar account can then sign a message with fiat account deposit instructions etc.

Tests for account deletion

A is account deleted
B is account that gets the remaining funds
C is some other account

Should test among other things these situations:

• A is holding IOUs
• A has offers
• A has offers in the same ledger where their offer is taken by C. make sure both orders of operation are tested
• A has offers and IOUs
• C is holding an IOU from A
• B holds same type of IOU that A holds
• A holds an IOU from B

Other cases if you think of them.

Steps to build stellard on wiki

Why does setting RequireDestTag (65536) makes flags be 131072

If you set requireDestTag on an account, you use 65536

curl -X POST https://live.stellar.org:9002 -d '
{
  "method": "submit",
  "params": [
    {
      "secret": "sMasterSeedHereXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "tx_json": {
        "TransactionType": "AccountSet",
        "Account": "gTargetAccountIDHereXXXXXXXXXXXXXX",
        "Flags": "65536"
      }
    }
  ]
}'

But when you do an account_info, it shows that the flag is 131072. Here is an example from justcoin:

{
   "result" : {
      "account_data" : {
         "Account" : "gnhPFpbYXcYGMkGxfWdQGFfuKEdJoEThVo",
         "Balance" : "14100428650718",
         "Flags" : 131072,
         "LedgerEntryType" : "AccountRoot",
         "OwnerCount" : 0,
         "PreviousTxnID" : "B49CA02A605F451C64547F00C3DB3961504F0C8CE7FF85E21214CD7627811F60",
         "PreviousTxnLgrSeq" : 126812,
         "Sequence" : 386,
         "index" : "3B438257E1B6205011E2B06969C90877881660F7F93ED52A25486D093A766365"
      },
      "ledger_current_index" : 126821,
      "status" : "success"
   }
}

Why does this happen? It is also documented in the Ripple wiki ( https://ripple.com/wiki/Require_a_destination_tag_for_inbound_payments ) in the last sentence in the "Requiring a DestinationTag" section

Destination tags should be 64-bit

Destination tags, as I understand them, are unsigned 32-bit integers. That seems like an unnecessary limitation. They should be 64-bit integers. JavaScript can use strings to represent them if that's a concern (as JavaScript can only represent integers up to 52 bits).

A few points in favor:

1. In the theoretical future world where Stellar takes off and is used everywhere, one recipient might actually need to distinguish payments to more than 4 billion different accounts. Using multiple destination addresses isn't a great solution, because people will expect to be using something like [email protected]. As an example of who might need more than 4 billion tags, a gateway that converts between STR and BTC (assuming BTC also is ubiquitous) might, as BTC addresses are free to create and therefore you could have tens or hundreds of addresses per user.
2. Proving ownership of an address is easiest done by sending a payment of a specified tiny amount to an address with a unique destination tag. 4 billion tags is a lot, but it's still not enough to really be totally secure. With a 10 stroop fee, and assuming a 1 stroop payment (because the payment amount is irrelevant), you can run through all the tags with just over 47k STR. With the current value on stellarvalue.org (I'm not sure how accurate it is, but it's ballpark at least), that's less than $300. Bumping the destination tags up to 64-bit obviously makes this attack impossible.

I can't think of any good reason against this change. 64-bit integers are easy to handle in modern software, have no real performance penalty to speak of, and as I said before, JavaScript clients can treat it as a string, they have no need to actually represent it as a number

Tests for inflation