Merge pull request #79 from ripple/gh-pages

Dev Portal from Staging to Master for 10/8 second push
Merge pull request #78 from mDuo13/gh-pages
2025-11-04 11:55:50 +00:00 · 2014-10-08 18:41:21 -07:00 · 2014-10-08 18:40:39 -07:00 · 2014-10-08 18:39:27 -07:00 · 2014-10-08 15:15:56 -07:00 · 2014-10-08 15:13:16 -07:00
13 changed files with 1617 additions and 733 deletions
--- a/css/api-style.css
+++ b/css/api-style.css
@@ -98,7 +98,7 @@ h2 {
 #output {
  width: 60%;
 }
-p, h3 {
+h3 {
  margin:16px 0;
  font-family:'open sans';
  font-weight:300;
@@ -150,7 +150,7 @@ p, h3 {
 }

 #request_options > div {
-  float:right;
+/*  float:right;
  margin:0;
  width:200px;
  color:#fff;
@@ -161,23 +161,25 @@ p, h3 {
  background-image:linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), linear-gradient(top, rgba(255,255,255,0.15), transparent);
  background-image:-webkit-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -webkit-linear-gradient(top, rgba(255,255,255,0.15), transparent);
  background-image:-moz-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -moz-linear-gradient(top, rgba(255,255,255,0.15), transparent);
- */
+ 

  border-radius:4px;
  border-bottom:1px solid #fff;
  background-color: #346AA9;
  font-weight:300;
  font-size:16px;
-/*   line-height:50px; */
+/*   line-height:50px; 
  text-align:center;
  cursor:default;

  user-select:none;
  -webkit-user-select:none;
  -moz-user-select:none;
+*/
+  margin-top: 5px;
 }
 #request_button {
-  background:#3a87ad;
+  background-color: #346AA9;
 }
 #request_button.depressed {
  background:#295F7A;
@@ -290,9 +292,9 @@ ul.toolbar li {
  border:1px dotted #3a87ad;
 }

-#selected_command {
+/*#selected_command {
  margin-top:-32px;
-}
+}*/

 #selected_command a {
  text-decoration:none;
@@ -410,7 +412,8 @@ span.cm-atom {
 #rest_url_wrapper {
    font-family: sans-serif;
    display: inline-block;
-    margin-bottom: -11px;
+    text-indent: -2em;
+    padding-left: 2.5em;
 }

 #rest_url {
@@ -418,4 +421,37 @@ span.cm-atom {
    border: 0;
    background: none;
    font-size:13px;
+    vertical-align: top;
+}
+
+#rest_url .editable {
+    font-weight: bold;
+    font-family:'inconsolata',monospace;
+    border-width: 0 0px 1px 0;
+    border-style: dotted;
+    border-color: #aaa;
+    min-width: 5em;
+    background: none;
+    vertical-align: top;
+}
+
+#rest_url .non_editable {
+    vertical-align: top;
+}
+
+#rest_url_wrapper p {
+    margin: 0;
+}
+
+#rest_url div {
+    display: inline-block;
+}
+
+#rest_url input {
+    margin: 0 !important;
+}
+
+#rest_url div label, 
+#rest_url div input {
+    display: block;
 }
--- a/css/main.css
+++ b/css/main.css
@@ -152,7 +152,7 @@
  -moz-box-sizing: border-box;
 }
 body {
-  color: #898788;
+  color: #393738;
  font-family: 'Open Sans', sans-serif;
 }
 body .content-root {
--- a/css/mod.css
+++ b/css/mod.css
@@ -1,14 +1,15 @@
 .draft-comment {background: #faa; border: 1px solid #d88; padding: 2px;}

 td {border: 1px solid #DBDDE2 !important; padding: .2em;}
-table { border-collapse: collapse; clear: left; width: 550px}
-th { padding: .2em; }
+table { border-collapse: collapse; clear: left; }
+th { padding: .2em; font-weight: bold; }

 body .content-root {
    background-color: #F3F6FB;
    box-shadow: 930px 0 #FFFFFF inset, 931px 0 #DFE2E7 inset, 940px 0 5px -10px rgba(0, 0, 0, 0.1) inset;
 }
 code { max-height: 14em; overflow: auto;}
+.content code { color: #111; }
 .expanded { max-height: none; overflow: none;}

 .content h2, .menu a.level-2 {
--- a/css/style.css
+++ b/css/style.css
@@ -125,7 +125,6 @@ a {
  text-decoration: none;
 }
 a:hover {
-  color: #228a8a;
 }
 /* ----------------------------------------------------------------------------
 * Content styling
@@ -666,12 +665,8 @@ a.big.button {
 }
 a.big.button,
 a.big.button:visited {
-  color: #2badad;
  text-decoration: none;
 }
-a.big.button:hover {
-  background: #2badad;
-}
 a.big.button:hover,
 a.big.button:hover:visited {
  color: #fff;
@@ -742,9 +737,6 @@ a.big.button:hover:visited {
 .menu a:visited {
  color: #2badad;
 }
-.menu a:hover {
-  color: #228a8a;
-}
 .menu a.level-1 {
  font-family: montserrat, sans-serif;
  text-transform: uppercase;
--- a/js/apitool-rest.js
+++ b/js/apitool-rest.js
@@ -7,6 +7,8 @@ var rest_url = $('#rest_url');
 var rest_method = $("#rest_method");
 var selected_command = $("#selected_command");
 var spinner = $(".loader");
+var reminders = $("#rest_url_wrapper .rest_reminders");
+var test_warning = $("#test_warning");

 var GET = "GET";
 var POST = "POST";
@@ -14,6 +16,8 @@ var PUT = "PUT";
 var DELETE = "DELETE";
 var URL_BASE = "https://api.ripple.com:443";

+var DOC_BASE = "ripple-rest.html";
+

 function slugify(str) {
  str = str.replace(/^\s+|\s+$/g, ''); // trim
@@ -57,32 +61,47 @@ $(commands).click(function() {

 //---------- List of requests ------------------------//

+var DEFAULT_ADDRESS_1 = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn";
+var DEFAULT_ADDRESS_2 = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX";
+var DEFAULT_HASH = "9D591B18EDDD34F0B6CF4223A2940AEA2C3CC778925BABF289E0011CD8FA056E";
+
 Request('Generate Account', {
    method: GET,
    path: "/v1/accounts/new",
    description: 'Generate the keys for a potential new account',
-    link: 'ripple-rest.html#generating-accounts'
+    link: '#generate-account'
 });

 Request('Get Account Balances', {
    method: GET,
-    path: '/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/balances',
+    path: '/v1/accounts/{:address}/balances?{:query_params}',
    description: 'Retrieve the current balances for the given Ripple account',
-    link: 'ripple-rest.html#account-balances'
+    link: '#get-account-balances',
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:query_params}": "currency=USD"
+    }
 });

 Request('Get Account Settings', {
    method: GET,
-    path: '/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/settings',
+    path: '/v1/accounts/{:address}/settings',
    description: 'Retrieve the current settings for the given Ripple account',
-    link: 'ripple-rest.html#account-settings'
+    link: '#get-account-settings',
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    }
 });

 Request('Update Account Settings', {
    method: POST,
-    path: '/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/settings',
-    description: 'Change the current settings for the given Ripple account. <span class="btn-danger">Please, only use test accounts here.</span>',
-    link: 'ripple-rest.html#updating-account-settings',
+    path: '/v1/accounts/{:address}/settings',
+    description: 'Change the current settings for the given Ripple account.',
+    link: '#update-account-settings',
+    test_only: true,
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    },
    body: {
        secret: "sssssssssssssssssssssssssssss",
        settings: {
@@ -97,21 +116,28 @@ Request('Update Account Settings', {

 Request('Prepare Payment', {
    method: GET,
-    path: '/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/payments/paths/ra5nK24KXen9AHvsdFTKHSANinZseWnPcX/1+USD+rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn',
+    path: '/v1/accounts/{:source_address}/payments/paths/{:destination_address}/{:amount}?{:query_params}',
    description: 'Change the current settings for the given Ripple account',
-    link: 'ripple-rest.html#preparing-a-payment'
+    link: '#prepare-payment',
+    params: {
+        "{:source_address}": DEFAULT_ADDRESS_1,
+        "{:destination_address}": DEFAULT_ADDRESS_2,
+        "{:amount}": "1+USD+rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+        "{:query_params}": "source_currencies=USD"
+    }
 });

 Request('Submit Payment', {
    method: POST,
    path: '/v1/payments',
-    description: 'Send a prepared payment to the network. <span class="btn-danger">Please, only use test accounts here.</span>',
-    link: 'ripple-rest.html#submitting-a-payment',
+    description: 'Send a prepared payment to the network.',
+    link: '#submit-payment',
+    test_only: true,
    body: {
      "secret": "sssssssssssssssssssssssssssss",
      "client_resource_id": "348170b9-16b9-4927-854d-7f9d4a2a692d",
      "payment":     {
-          "source_account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+          "source_account": DEFAULT_ADDRESS_1,
          "source_tag": "",
          "source_amount": {
            "value": "1",
@@ -119,12 +145,12 @@ Request('Submit Payment', {
            "issuer": ""
          },
          "source_slippage": "0",
-          "destination_account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+          "destination_account": DEFAULT_ADDRESS_2,
          "destination_tag": "",
          "destination_amount": {
            "value": "1",
            "currency": "USD",
-            "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
+            "issuer": DEFAULT_ADDRESS_1
          },
          "invoice_id": "",
          "paths": "[]",
@@ -136,30 +162,46 @@ Request('Submit Payment', {

 Request("Confirm Payment", {
    method: GET,
-    path: "/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/payments/9D591B18EDDD34F0B6CF4223A2940AEA2C3CC778925BABF289E0011CD8FA056E",
+    path: "/v1/accounts/{:address}/payments/{:hash}",
    description: "Retrieve details of a payment and its status",
-    link: "ripple-rest.html#confirming-a-payment"
+    link: "#confirm-payment",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:hash}": DEFAULT_HASH
+    }
 });

 Request("Get Payment History", {
    method: GET,
-    path: "/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/payments",
+    path: "/v1/accounts/{:address}/payments?{:query_params}",
    description: "Browse through the history of payments sent and received by an account",
-    link: "ripple-rest.html#payment-history",
+    link: "#get-payment-history",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:query_params}": "direction=incoming&exclude_failed=true"
+    }
 });

 Request("Get Trustlines", {
    method: GET,
-    path: "/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/trustlines?currency=USD",
+    path: "/v1/accounts/{:address}/trustlines?{:query_params}",
    description: "Check the status of one or more trustlines attached to an account",
-    link: "ripple-rest.html#reviewing-trustlines"
+    link: "#reviewing-trustlines",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:query_params}": "currency=USD&counterparty=ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
+    }
 });

 Request("Grant Trustline", {
    method: POST,
-    path: "/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/trustlines",
-    description: "Add or modify a trustline from this account. <span class='btn-danger'>Please, only use test accounts here.</span>",
-    link: "ripple-rest.html#granting-a-trustline",
+    path: "/v1/accounts/{:address}/trustlines",
+    description: "Add or modify a trustline from this account.",
+    link: "#granting-a-trustline",
+    test_only: true,
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1
+    },
    body: {
        "secret": "sneThnzgBgxc3zXPG....",
        "trustline": {
@@ -173,37 +215,44 @@ Request("Grant Trustline", {

 Request("Check Notifications", {
    method: GET,
-    path: "/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/notifications/9D591B18EDDD34F0B6CF4223A2940AEA2C3CC778925BABF289E0011CD8FA056E",
+    path: "/v1/accounts/{:address}/notifications/{:hash}",
    description: "Browse through the history of payments sent and received by an account",
-    link: "ripple-rest.html#checking-notifications"
+    link: "#checking-notifications",
+    params: {
+        "{:address}": DEFAULT_ADDRESS_1,
+        "{:hash}": DEFAULT_HASH
+    }
 });

 Request("Check Connection", {
    method: GET,
    path: "/v1/server/connected",
    description: "Check whether the REST server is connected to a rippled server",
-    link: "ripple-rest.html#check-connection-state"
+    link: "#check-connection-state"
 });

 Request("Get Server Status", {
    method: GET,
    path: "/v1/server",
    description: "Retrieve information about the current status of the Ripple-REST server and the rippled server it is connected to",
-    link: "ripple-rest.html#get-server-status"
+    link: "#get-server-status"
 });

 Request("Retrieve Ripple Transaction", {
    method: GET,
-    path: "/v1/tx/85C5E6762DE7969DC1BD69B3C8C7387A5B8FCE6A416AA1F74C0ED5D10F08EADD",
+    path: "/v1/tx/{:hash}",
    description: "Retrieve a raw Ripple transaction",
-    link: "ripple-rest.html#retrieve-ripple-transaction"
+    link: "#retrieve-ripple-transaction",
+    params: {
+        "{:hash}": DEFAULT_HASH
+    }
 });

 Request("Generate UUID", {
    method: GET,
    path: "/v1/uuid",
    description: "Create a universally-unique identifier (UUID) to use as the client resource ID for a payment",
-    link: "ripple-rest.html#create-client-resource-id"
+    link: "#create-client-resource-id"
 });

 //---------- End req. List ---------------------------//
@@ -221,8 +270,13 @@ var cm_response = CodeMirror(response_body.get(0), {
    readOnly: true
 });

-function update_method() {
-    method = $(this).val();
+function update_method(el) {
+    if (el === undefined) {
+        method = $(this).val();
+    } else {
+        method = $(el).val();
+    }
+    
    if (method == GET || method == DELETE) {
        request_body.hide();
    } else {
@@ -231,12 +285,47 @@ function update_method() {
    }
 }

+function change_path(command) {
+    rest_url.empty();
+    reminders.html("&nbsp;");
+    
+    var re = /(\{:[^}]+\})/g; // match stuff like {:address}
+    params = command.path.split(re);
+    
+    //console.log(params);
+    for (i=0; i<params.length; i++) {
+        if (params[i].match(/\{:[^}]+\}/) !== null) {
+            if (command.params === undefined || command.params[params[i]] === undefined) {
+                var default_val = params[i];
+            } else {
+                var default_val = command.params[params[i]];
+            }
+            //rest_url.append("<span class='editable' contenteditable='true' id='resturl_"+params[i]+"'>"+default_val+"</span>");
+            
+            var new_div = $("<div>").appendTo(rest_url);
+            var new_param = $("<input type='text' id='resturl_"+params[i]+"' value='"+default_val+"' class='editable' title='"+params[i]+"' />").appendTo(new_div);
+            new_param.autosizeInput({"space": 0});
+            //var new_label = $("<label class='reminder' for='resturl_"+params[i]+"'>"+params[i]+"</label>").appendTo(new_div);
+            
+            
+        } else {
+            rest_url.append("<span class='non_editable'>"+params[i]+"</span>");
+        }
+    }
+}
+
 function select_request(request) {
    command = requests[request];
+    
+    if (command.test_only === true) {
+        test_warning.show();
+    } else {
+        test_warning.hide();
+    }

    if (command.description) {
        $(description).html($('<a>')
-            .attr('href', command.link)
+            .attr('href', DOC_BASE+command.link)
            .html(command.description));
        $(description).show();
    } else {
@@ -244,15 +333,19 @@ function select_request(request) {
    }

    selected_command.html($('<a>')
-                    .attr('href', command.link)
+                    .attr('href', DOC_BASE+command.link)
                    .text(command.name));
                                
    //rest_url.val(command.path);
-    rest_url.text(command.path);
+    //rest_url.text(command.path);
+    change_path(command);

    
-    rest_method.val(command.method);
-    rest_method.change();
+//    rest_method.val(command.method);
+//    rest_method.change();
+    request_button.val(command.method);
+    request_button.text(command.method+" request");
+    update_method(request_button);
    
    if (command.method == POST || command.method == PUT) {
        cm_request.setValue(JSON.stringify(command.body, null, 2));
@@ -270,22 +363,33 @@ function get_uuid(callback) {
    $.get(URL_BASE + "/v1/uuid").done(callback);
 }

+function get_path() {
+    s = "";
+    rest_url.find(".non_editable, .editable").each(function() {
+        if (this.tagName == "INPUT") {
+            s += $(this).val();
+        } else {
+            s += $(this).text();
+        }
+    });
+    return s;
+}

 function send_request() {
-    var method = rest_method.val();
+    //var method = rest_method.val();
+    var method = request_button.val();
    if (method != GET && method != POST && method != PUT && method != DELETE) {
        console.log("ERROR: unrecognized http method");
        return;
    }
    //var path = rest_url.val();
-    var path = rest_url.text();
+    var path = get_path();

    $(this).addClass('depressed');
    response_body.addClass('obscured');

    if (method == PUT || method == POST) {
        var body   = cm_request.getValue();
-        console.log(body);
        $.ajax({
            type: method,
            url: URL_BASE + path,
@@ -326,7 +430,7 @@ function reset_response_area() {

 $(document).ready(function() {
    request_button.click(send_request);
-    rest_method.change(update_method);
+    //rest_method.change(update_method);
    
    get_uuid(function(resp,status,xhr) {
        requests["submit-payment"].body.client_resource_id = resp.uuid;
--- a/js/jquery.autosize.input.min.js
+++ b/js/jquery.autosize.input.min.js
@@ -0,0 +1 @@
+var Plugins;(function(n){var t=function(){function n(n){typeof n=="undefined"&&(n=30);this.space=n}return n}(),i;n.AutosizeInputOptions=t;i=function(){function n(t,i){var r=this;this._input=$(t);this._options=$.extend({},n.getDefaultOptions(),i);this._mirror=$('<span style="position:absolute; top:-999px; left:0; white-space:pre;"/>');$.each(["fontFamily","fontSize","fontWeight","fontStyle","letterSpacing","textTransform","wordSpacing","textIndent"],function(n,t){r._mirror[0].style[t]=r._input.css(t)});$("body").append(this._mirror);this._input.on("keydown keyup input propertychange change",function(){r.update()});(function(){r.update()})()}return n.prototype.getOptions=function(){return this._options},n.prototype.update=function(){var n=this._input.val()||"",t;n!==this._mirror.text()&&(this._mirror.text(n),t=this._mirror.width()+this._options.space,this._input.width(t))},n.getDefaultOptions=function(){return this._defaultOptions},n.getInstanceKey=function(){return"autosizeInputInstance"},n._defaultOptions=new t,n}();n.AutosizeInput=i,function(t){var i="autosize-input",r=["text","password","search","url","tel","email","number"];t.fn.autosizeInput=function(u){return this.each(function(){if(this.tagName=="INPUT"&&t.inArray(this.type,r)>-1){var f=t(this);f.data(n.AutosizeInput.getInstanceKey())||(u==undefined&&(u=f.data(i)),f.data(n.AutosizeInput.getInstanceKey(),new n.AutosizeInput(this,u)))}})};t(function(){t("input[data-"+i+"]").autosizeInput()})}(jQuery)})(Plugins||(Plugins={}))
--- a/rest-api-tool.html
+++ b/rest-api-tool.html
@@ -129,21 +129,25 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
        <div id='io_wrapper'>
          <div id='input' class='io'>
            <h2>REST Request</h2>
-            <div id='request_options'>
-              <div class="button btn btn-primary api" id='request_button'>Send request</div>
+            <div id='test_warning' class='alert alert-danger' style='display:none;'>
+                <h4>Test accounts only!</h4>
+                <p>Never submit account secrets to a server you do not control, unless you are prepared to lose ownership of the account!</p>
            </div>
            <div style="clear:both;"></div>
            <h3 id='selected_command' title='Reference information'></h3>
            <p id='description'></p>
            <div id='invalid'>Invalid JSON</div>
-            <select id='rest_method'>
+<!--            <select id='rest_method'>
                <option value='GET'>GET</option>
                <option value='POST'>POST</option>
-            </select>
+            </select>-->
            <div id='rest_url_wrapper'>
-                <span id='rest_host'>https://api.ripple.com</span><span id='rest_url' contenteditable='true'></span>
+                <p><span id='rest_host'>https://api.ripple.com</span><span id='rest_url'></span></p>
            </div>
            <div id='request_body'></div>
+            <div id='request_options'>
+              <div class="button btn btn-primary api" id='request_button'>Send request</div>
+            </div>
          </div>
          <div id='output' class='io'>
            <h2>Response</h2>
@@ -232,6 +236,7 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
  <script type='text/javascript' src='js/es5-shim.js'></script>
  <script src='//cdnjs.cloudflare.com/ajax/libs/codemirror/3.16.0/codemirror.min.js'></script>
  <script type='text/javascript' src='js/cm-javascript.min.js'></script>
+  <script type='text/javascript' src='js/jquery.autosize.input.min.js'></script>
  <script type='text/javascript' src='js/apitool-rest.js'></script>


--- a/ripple-api-tool.html
+++ b/ripple-api-tool.html
@@ -132,15 +132,15 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
        <div id='io_wrapper'>
          <div id='input' class='io'>
            <h2>WebSocket Request</h2>
-            <div id='request_options'>
-              <div class="button btn btn-primary api" id='request_button'>Send request</div>
-            </div>
            <div style="clear:both;"></div>
            <h3 id='selected_command' title='Reference information'>server_info</h3>
            <p id='description'></p>
            <div id='invalid'>Invalid JSON</div>
            <p>JSON</p>
            <div id='request'></div>
+            <div id='request_options'>
+              <div class="button btn btn-primary api" id='request_button'>Send request</div>
+            </div>
          </div>
          <div id='output' class='io'>
            <h2>Response</h2>
--- a/ripple-rest.html
+++ b/ripple-rest.html
@@ -61,11 +61,12 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");

  
  <!-- syntax selection js -->
-  <script src='js/multicodetab.js'></script>
+  <script src="js/multicodetab.js"></script>
  <script>
    Flatdoc.run({
      fetcher: Flatdoc.file('ripplerest_api.md')
    });
+    $(document).on('flatdoc:ready', $().multicode_tabs);
  </script>
  <link type='text/css' rel='stylesheet' href='css/mod.css' />
  <script src="js/fixsidebarscroll.js"></script>
@@ -107,18 +108,6 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
        </div><!--/.nav-collapse -->
      </div>
    </div>
-<!-- 
-  <div class="header-subnav-wrapper">
-  <div class='header-subnav navbar-fixed-top'>
-    <ul>
-        <li><a href='?p=introduction' id='subnav-intro'>Introduction</a></li>
-        <li><a href='?p=ripple-rest-api' id='subnav-rest'>Ripple-REST API</a></li>
-        <li><a href='?p=web-sockets-api' id='subnav-websocket'>WebSocket &amp; JSON-RPC APIs</a></li>
-    </ul>
-    <div class='clearer'>&nbsp;</div>
-  </div>
-</div>
- -->
  <div class='content-root'>
    <div class='menubar'>
      <div class='menu section' role='flatdoc-menu'></div>
--- a/rippled-apis.html
+++ b/rippled-apis.html
--- a/ripplerest_api.md
+++ b/ripplerest_api.md
--- a/tx_format.md
+++ b/tx_format.md
@@ -32,7 +32,7 @@ Typically, you create a transaction in JSON format first. Here is an example of
  "TransactionType" : "Payment",
  "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
-  "Amount" : { 
+  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
@@ -46,9 +46,9 @@ Typically, you create a transaction in JSON format first. Here is an example of
 After doing that, you generate the signed binary format for the transaction. There are two ways to do this:

 1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
-  * [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is a JavaScript implementation of offline signing. 
+  * [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is a JavaScript implementation of offline signing.
 2. Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.)
-  * As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes. 
+  * As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.

 In either case, signing a transaction generates a binary blob that can be submitted to the network. This means using `rippled`'s [submit command](rippled-apis.html#submit). Here is an example of the same transaction, as a signed blob, being submitted with the WebSocket API:

@@ -152,52 +152,56 @@ After a transaction has been submitted, if it gets accepted into a validated led

 ### Identifying Transactions ###

-The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction by in an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).
+The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).

 The transaction hash can be used as a "proof of payment" since anyone can look up the transaction using the hash and verify its final status.

 ## Common Fields ##

-Every transaction has a the same set of fundamental fields:
+Every transaction type has the same set of fundamental fields:

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
 |-------|-----------|---------------|-------------|
 | Account | String | Account | The unique address of the account that initiated the transaction. |
+| [AccountTxnID](#accounttxnid) | String | Hash256 | (Optional) Hash value identifying another transaction. This transaction is only valid if the sending account's previously-sent transaction matches the provided hash. |
 | [Fee](#transaction-fees) | String | Amount | (Required, but [auto-fillable](#auto-fillable-fields)) Integer amount of XRP, in drops, to be destroyed as a fee for redistributing this transaction to the network. |
 | [Flags](#flags) | Unsigned Integer | UInt32 | (Optional) Set of bit-flags for this transaction. |
 | [LastLedgerSequence](#lastledgersequence) | Number | UInt32 | (Optional, but strongly recommended) Highest ledger sequence number that a transaction can appear in. |
 | [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. |
-| [PreviousTxnID](#previoustxnid) | String | Hash256 | (Optional) Hash value identifying a transaction. If the transaction immediately prior this one by sequence number does not match the provided hash, this transaction is considered invalid. |
 | [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
-| SigningPubKey | String | PubKey | (Omitted until signed) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
+| SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
 | SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
-| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, and `AccountSet`. |
-| TxnSignature | String | VariableLength | (Omitted until signed) The signature that verifies this transaction as originating from the account it says it is from. |
+| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, and `SetRegularKey`. |
+| TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. |
+
+The field `PreviousTxnID` is **DEPRECATED**. It has been replaced by [AccountTxnID](#accounttxnid). Always use `AccountTxnID` instead.

 ### Auto-fillable Fields ###

 Some fields can be automatically filled in before the transaction is signed, either by a `rippled` server or by the library used for offline signing. Both [ripple-lib](https://github.com/ripple/ripple-lib) and `rippled` can automatically provide the following values:

-* `Fee` - Automatically use the current base network fee.
+* `Fee` - Automatically use the current base network fee. (*Note:* `rippled`'s [sign command](rippled-apis.html#sign) supports limits on how high the filled-in-value is, using the `fee_mult_max` parameter.)
 * `Sequence` - Automatically use the next sequence number for the account sending the transaction.

 For a production system, we recommend *not* leaving these fields to be filled by the server. For example if fees become temporarily high, you may want to wait for fees to decrease before sending some transactions, instead of continuing regardless of fee.

+The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in. 
+
 ### Transaction Fees ###

 The `Fee` field specifies an amount, in [drops of XRP](rippled-apis.html#specifying-currency-amounts), that must be deducted from the sender's balance in order to relay any transaction through the network. This is a measure to protect against spam and DDoS attacks weighing down the whole network. You can specify any amount in the `Fee` field when you create a transaction. If your transaction makes it into a validated leger (whether or not it achieves its intended purpose), then the deducted XRP is destroyed forever.

 Each rippled server decides on the minimum fee to require, which is at least the global base transaction fee, and increases based on the individual server's current load. If a transaction's fee is not high enough, then the server does not relay the transaction to other servers. (*Exception:* If you send a transaction to your own server over an admin connection, it relays the transaction even under high load, so long as the fee meets the global base.)

-Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease. 
+Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease.

 For more information, see the [Transaction Fee wiki article](https://wiki.ripple.com/Transaction_Fee).

 ### Canceling or Skipping a Transaction ###

-An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger. 
+An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger.

-However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options. 
+However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options.

 For example, if you attempted to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction fee](#transaction-fees) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction fee for the new transaction 11), but it allows transactions 12 and 13 to become valid.

@@ -207,28 +211,49 @@ In this way, an AccountSet transaction with no options is the canonical "[no-op]

 ### LastLedgerSequence ###

-We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds. 
+We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds.

 Without the `LastLedgerSequence` parameter, there is a particular situation that can occur and cause your transaction to be stuck in an undesirable state where it is neither validated nor rejected for a long time. Specifically, if the global base [transaction fee](#transaction-fees) increases after you send a transaction, your transaction may not get propagated enough to be included in a validated ledger, but you would have to pay the (increased) fee in order to send another transaction canceling it. Later, if the transaction fee decreases again, the transaction may become viable again. The `LastLedgerSequence` places a hard upper limit on how long the transaction can wait to be validated or rejected.

-### PreviousTxnID ###
+### AccountTxnID ###

-The `PreviousTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one is also valid and matches the transaction you expected.
+The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.

-One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `PreviousTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
+One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.

-In order to use PreviousTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.
+In order to use AccountTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.

 ### Memos ###

-The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects, where each object has the following fields:
+The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields:

-| Field | Type | Description |
-|-------|------|-------------|
-| MemoType | String | A unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
-| (...) | (Variable) | Arbitrary additional fields defined by the MemoType, including the contents of the memo, any values needed to decrypt it or verify its signature, etc. |
+| Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
+|-------|------|--------------------------------------------------------|-------------|
+| MemoType | String | VariableLength | Arbitrary hex value; conventionally should be ASCII for a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
+| MemoData | String | VariableLength | Arbitrary hex value, conventionally containing the content of the memo. |
+| MemoFormat | String | VariableLength | Arbitrary hex value, conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml) |
+
+The `Memos` field is currently limited to no more than 1KB in size (when serialized in binary format).
+
+Example of a transaction with a Memos field:
+
+```
+{
+    "TransactionType": "Payment",
+    "Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
+    "Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
+    "Memos": [
+        {
+            "Memo": {
+                "MemoType": "5061796d656e7420726561736f6e",
+                "MemoData": "72656e74"
+            }
+        }
+    ],
+    "Amount": "1"
+}
+```

-The memos field is currently limited to no more than 1KB in size.

 ### Flags ###

@@ -249,6 +274,8 @@ The only flag that applies globally to all transactions is as follows:

 A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, additional exchanges of value may occur atomically to facilitate the payment.)

+Payments are also the only way to [create accounts](#creating-accounts).
+
 Example payment:

 ```
@@ -256,7 +283,7 @@ Example payment:
  "TransactionType" : "Payment",
  "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
-  "Amount" : { 
+  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
@@ -268,27 +295,36 @@ Example payment:
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | Amount | String (XRP)<br/>Object (Otherwise) | Amount | The amount of currency to deliver. *Note:* If the [*tfPartialPayment* flag](#payment-flags) is set, this is not the amount actually received. (Formatted as per [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts).) |
 | Destination | String | Account | The unique address of the account receiving the payment. |
 | DestinationTag | Unsigned Integer | UInt32 | (Optional) Arbitrary tag that identifies the reason for the payment to the destination, or the hosted wallet to make a payment to. |
 | InvoiceID | String | Hash256 | (Optional) Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
-| Paths | Array of path arrays | PathSet | (Optional, but recommended) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. If omitted, the server chooses a path. Must be omitted for XRP-to-XRP transactions. |
-| SendMax | String/Object | Amount | (Optional) Highest amount of currency this transaction is allowed to cost, including fees, exchanges, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) If omitted, do not send more than the `Amount` to be received. Must be omitted or empty for XRP-to-XRP transactions. |
+| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
+| SendMax | String/Object | Amount | (Optional) Highest amount of source currency this transaction is allowed to cost, including fees, exchanges, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) Must be supplied for cross-currency/cross-issue payments (implies source balance). Must be omitted for XRP-to-XRP payments.|
+
+### Creating Accounts ###
+
+The Payment transaction type is the only way to create new accounts in the shared Ripple ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](https://wiki.ripple.com/Reserves) to a mathematically-valid account address that does not exist yet. When the payment is processed, a new [AccountRoot node](https://wiki.ripple.com/Ledger_Format#AccountRoot) will be added to the ledger to reflect the newly-created account.
+
+If you attempt to send an insufficient amount of XRP, or any other currency, the Payment will fail.

 ### Paths ###

-The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from a path.
+The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from a path. You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands. 

-You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands. We recommend always including looking up the paths and including them as part of the transaction, because there are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)
+If the `Paths` field is provided, the server decides at transaction processing time which paths to use out of the provided set. This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.

-An empty `Paths` array indicates that the server should decide which paths to use, or there is a direct path connecting the source and destination accounts.
-
-A direct path could be:
+If the `Paths` field is omitted, by definition the payment should take a direct path connecting the source and destination accounts. A direct path could be:

 * An XRP-to-XRP transfer.
 * A payment along a single trust line that connects the two accounts in the currency being transferred.

+The `Paths` field must not be an empty array, nor an array whose members are all empty arrays.
+
+The `Paths` field can be automatically filled in when the transaction is signed, if the `build_path` field is provided to the [sign](rippled-apis.html#sign) or [submit](rippled-apis.html#submit) commands. However, we recommend pathfinding separately and confirming the results prior to signing, in order to avoid surprises. There are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)
+
+
 ### Payment Flags ###

 Transactions of the Payment type support additional values in the [`Flags` field](#flags), as follows:
@@ -296,21 +332,26 @@ Transactions of the Payment type support additional values in the [`Flags` field
 | Flag Name | Hex Value | Decimal Value | Description |
 |-----------|-----------|---------------|-------------|
 | tfNoDirectRipple | 0x00010000 | 65536 | Do not use a direct path, if available. This is intended to force the transaction to take arbitrage opportunities. Most clients will not need this. |
-| tfPartialPayment | 0x00020000 | 131072 | Instead of deducting transfer and exchange fees from the sending account's balance, reduce the received amount by the fee amounts. See [Partial Payments](#partial-payments) for more details. |
+| tfPartialPayment | 0x00020000 | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](#partial-payments) for more details. |

 ### Partial Payments ###

-A partial payment subtracts fees from the amount received instead of adding to the amount sent. Partial payments are useful for [returning payments](https://wiki.ripple.com/Returning_payments) without incurring additional costs to oneself. 
+A partial payment allows a payment to succeed by reducing the amount received, instead of increasing the `SendMax`. Partial payments are useful for [returning payments](https://wiki.ripple.com/Returning_payments) without incurring additional costs to oneself.

-By default, the `Amount` field of a Payment transaction specifies the amount of currency that is *received* by the account that is the destination of the payment. Any additional amount needed for fees or currency exchange is deducted from the sending account, up to the `SendMax` amount. (If `SendMax` is not specified, and fees are necessary to make the transaction the transaction fails.)
+By default, the `Amount` field of a Payment transaction specifies the amount of currency that is *received* by the account that is the destination of the payment. Any additional amount needed for fees or currency exchange is deducted from the sending account's balances, up to the `SendMax` amount. (If `SendMax` is not specified, that is equivalent to setting the `SendMax` to the `Amount` field.) If the amount needed in order to make the payment exceeds the `SendMax` parameter, or the full amount cannot be delivered for any other reason, the transaction fails.

-The [*tfPartialPayment* flag](#payment-flags) allows you to make a "partial payment" instead. When this flag is enabled for a transaction, the costs of transaction fees and exchanging currencies are deducted from the amount sent instead of from the sender's balance. Consequently, the `Amount` field __*is not guaranteed to be the amount received*__. In fact, __*there is no minimum guaranteed amount*__ that a partial payment actually delivers. 
+The [*tfPartialPayment* flag](#payment-flags) allows you to make a "partial payment" instead. When this flag is enabled for a payment, it delivers as much as possible, up to the `Amount` value, without exceeding the `SendMax` value. Fees and currency exchange rates are calculated the same way, but the amount being sent automatically scales down until the total amount deducted from the sending account's balances is within `SendMax`. The transaction is always considered successful as long as it delivers any positive amount. This means that partial payments can succeed at sending *some* of the intended value despite limitations including fees, lack of liquidity, insufficient space in the receiving account's trustlines, or other reasons.

-Validated partial payment transactions have a `meta.DestinationAmount` field, which indicates the amount of currency actually received by the destination account. *Note:* Early partial payments in historical ledgers do not have this field.
+A partial payment cannot provide the initial XRP to fund an account; this case returns the error code `telNO_DST_PARTIAL`. Direct XRP-to-XRP payments also cannot be partial payments `temBAD_SEND_XRP_PARTIAL`.

-A partial payment cannot provide the initial XRP to fund an account; this case returns the error code telNO_DST_PARTIAL. Direct XRP-to-XRP payments also cannot be partial payments temBAD_SEND_XRP_PARTIAL.
+The amount of XRP used for the [transaction fee](#transaction-fees) is always deducted from the sender’s account, regardless of the *tfPartialPayment* flag.
+
+#### Partial Payments Warning ####
+
+When the [*tfPartialPayment* flag](#payment-flags) is enabled, the `Amount` field __*is not guaranteed to be the amount received*__. In fact, __*there is no minimum guaranteed amount*__ that a partial payment actually delivers. Validated partial payment transactions have a `meta.DeliveredAmount` field, which indicates the amount of currency actually received by the destination account. When receiving a payment, you should confirm that, if the `meta.DeliveredAmount` field exists, you use that to determine how much your account received instead of relying on the `Amount` field. 
+
+*Note:* Early partial payments in historical ledgers do not have this field. If necessary, you can check the balance changes in the `meta` field to determine how much the destination account actually received.

-*Note:* The amount of XRP used for the [transaction fee](#transaction-fee) is always deducted from the sender's account, regardless of the *tfPartialPayment* flag.



@@ -336,7 +377,7 @@ Example AccountSet:
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | [ClearFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Unique identifier of a flag to disable for this account. |
 | [Domain](#domain) | String | VariableLength | (Optional) The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
 | EmailHash | String | Hash128 | (Optional) Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
@@ -376,7 +417,7 @@ The available AccountSet flags are:
 | asfRequireAuth | 2 | Require authorization for users to hold balances issued by this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth |
 | asfDisallowXRP | 3 | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | lsfDisallowXRP |
 | asfDisableMaster | 4 | Disallow use of the master key. Can only be enabled if the account has a [RegularKey](#setregularkey) configured. | lsfDisableMaster |
-| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [PreviousTxnID](#previoustxnid) | (None) |
+| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | (None) |
 | asfNoFreeze | 6 | Permanently give up the ability to freeze individual trust lines. This flag can never be cleared. | lsfNoFreeze |
 | asfGlobalFreeze | 7 | Freeze all assets issued by this account. | lsfGlobalFreeze |

@@ -399,7 +440,7 @@ Incoming transactions with unclear purposes may be an inconvenience for some gat

 For example, a destination tag is typically used to identify which hosted balance should be credited when the gateway receives a payment. If the destination tag is omitted, it may be unclear which account should be credited, creating a need for refunds, among other problems. By using the `asfRequireDest` tag, the gateway (or any account) can ensure that every incoming payment has a destination tag, which makes it harder to send an ambiguous payment by accident.

-Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to meet the reserve and make a transaction that disabled the flag, the account would never be able to send another transaction.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.
+Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to send a transaction that disabled the flag, the account would be completely unusable.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.

 ### TransferRate ###

@@ -426,8 +467,8 @@ A SetRegularKey transaction changes the regular key used by the account to sign
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
-| RegularKey | String | PubKey | (Optional) Public key of a new keypair to use as the regular key to this account, as a base-58-encoded string; if omitted, removes the existing regular key. |
+|-------|-----------|--------------------------------------------------------|-------------|
+| RegularKey | String | Account | (Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key. |

 Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too, unless you set the [asfDisableMaster account flag](#accountset-flags).)

@@ -461,7 +502,7 @@ An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.or
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | [Expiration](#expiration) | Unsigned Integer | UInt32 | (Optional) Time after which the offer is no longer active, in [seconds since the Ripple Epoch](rippled-apis.html#specifying-time). |
 | OfferSequence | Unsigned Integer | UInt32 | (Optional) The sequence number of a previous OfferCreate transaction. If specified, cancel any offer node in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
 | TakerGets | Object (Non-XRP), or <br/>String (XRP) | Amount | The amount and type of currency being provided by the offer creator. |
@@ -490,13 +531,13 @@ An unfunded transaction can remain on the ledger indefinitely, but it does not h
 * It becomes fully claimed by a Payment or a matching OfferCreate transaction.
 * A subsequent OfferCancel or OfferCreate transaction explicitly cancels the offer.
 * A subsequent OfferCreate from the same account crosses the earlier offer. (In this case, the older offer is automatically canceled.)
-* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook and 
+* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook.
  * This includes cases where one side or the other of an offer is found to be closer to 0 than `rippled`'s precision supports.
 * *Note:* there is a bug that can cause offers to be removed incorrectly in rare circumstances. (See [RIPD-456](https://ripplelabs.atlassian.net/browse/RIPD-456) for status.)

 ### Offers and Trust ###

-The limit values of trust lines (See [TrustSet](#trustset)) do not affect offer. In other words, you can use an offer to acquire more than the maximum amount you trust an issuing gateway to redeem.
+The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuing gateway to redeem.

 However, possessing non-XRP balances still requires a trust line to the account issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](https://wiki.ripple.com/Reserves), any offers that would require a new trust line also require the account to have the necessary XRP to pay the reserve for that trust line.

@@ -550,7 +591,7 @@ An OfferCancel transaction removes an Offer node from the global ledger.
 ```

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | OfferSequence | Unsigned Integer | UInt32 | The sequence number of the offer to cancel. |

 *Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate](#offercreate) transaction with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
@@ -591,13 +632,13 @@ Create or modify a trust line linking two accounts.

 ### Trust Limits ###

-All balances on the Ripple Network, except for XRP, represent value owed in the world outside the Ripple Ledger. The account that issues those funds in Ripple (identified by the `issuer` field of the `LimitAmount` object) is responsible for paying the balance back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account. 
+All balances on the Ripple Network, except for XRP, represent value owed in the world outside the Ripple Ledger. The account that issues those funds in Ripple (identified by the `issuer` field of the `LimitAmount` object) is responsible for paying the balance back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account.

 Since a computer program cannot force the gateway to keep its promise and not default in real life, trust lines represent a way of configuring how much you are willing to trust the issuing account to hold on your behalf. Since a large, reputable issuing gateway is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuing account "owe" you (off the network) for the funds that you hold on the network. In the case that the issuing gateway defaults or goes out of business, you can lose up to that much money because the balances you hold in the Ripple Network can no longer be exchanged for equivalent balances off the network. (The Ripple Ledger will still reflect that you possess the same balance with that issuing gateway, but you won't be able to redeem, making it unlikely to be worth anything.)

 There are two cases where you can hold a balance on a trust line that is *greater* than your limit: when you acquire more of that currency through [trading](#offercreate), or when you decrease the limit on your trust line.

-Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](https://wiki.ripple.com/Reserves). This applies to the account extending trust, not to the account receiving it. 
+Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](https://wiki.ripple.com/Reserves). This applies to the account extending trust, not to the account receiving it.

 A trust line with a limit *and* a balance of 0 is equivalent to no trust line.

@@ -617,7 +658,7 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel

 Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.

-Some of the fields that are mandatory for normal transactions do not make sense for psuedo-transactions. In those cases, the pseudo-transaction has the following default values:
+Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:

 | Field | Default Value |
 |-------|---------------|
@@ -634,7 +675,7 @@ A change in transaction or account fees. This is typically in response to change
 *Note:* There have been very few, if any, Fee psuedo-transactions, ever. It is possible, but very unlikely, that you may encounter one in a historical ledger.

 | Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
-|-------|-----------|---------------|-------------|
+|-------|-----------|--------------------------------------------------------|-------------|
 | BaseFee | String (Quoted Integer) | UInt64 | The charge, in drops, for the reference transaction. (See [Transaction Fee Terminology](https://ripple.com/wiki/Transaction_Fee#Fee_Terminology) |
 | ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
 | ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
--- a/websocket_api.md
+++ b/websocket_api.md
@@ -5294,9 +5294,9 @@ The following fields are deprecated, and may be omitted: `paths_canonical`, and
 ## sign ##
 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Sign.cpp "Source")

-The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction and secret key.
+The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction JSON and secret key.

-*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.
+*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when you do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.

 #### Request Format ####
 An example of the request format:
@@ -5352,6 +5352,8 @@ rippled -- sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "A
 ```
 </div>

+[Try it! >](ripple-api-tool.html#sign)
+
 The request includes the following parameters:

 | Field | Type | Description |
@@ -5359,11 +5361,15 @@ The request includes the following parameters:
 | tx_json | Object | [Transaction definition](transactions.html) in JSON format |
 | secret | String | Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
 | offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
+| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |
+| fee\_mult\_max | Integer | (Optional) If the transaction `Fee` is omitted, this field limits the `Fee` value that is automatically filled so that it is less than or equal to the long-term base fee times this value. |

-The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields are automatic:
+The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields from the [transaction format](transactions.html) are automatically filled in:

-* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. 
-* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee.
+* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. Automatically filled unless `offline` is true.
+* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee. Automatically filled unless `offline` is true.
+    * If `fee_mult_max` is included, and the automatically generated Fee is greater than the long-term base fee times `fee_mult_max`, then the transaction fails with the error `rpcHIGH_FEE`. This way, you can let the server fill in the current minimum `Fee` value as long as the current load fee is not too high.
+* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided. 

 #### Response Format ####

@@ -5441,7 +5447,73 @@ The response follows the [standard format](#response-formatting), with a success
 ## submit ##
 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Submit.cpp "Source")

-The `submit` method sends a transaction to the network to be confirmed and included in future ledgers. There are two ways to use it: either you can supply JSON along with your secret key (not recommended), or you can take a pre-signed transaction blob (for example, one created with [`sign`](#sign), or better yet, something [signed offline](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js)) and submit it as-is.
+The `submit` method sends a [transaction](transactions.html) to the network to be confirmed and included in future ledgers. 
+
+This command has two modes:
+
+* Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission.
+* Sign-and-submit mode takes a JSON-formatted Transaction object, completes and signs the transaction in the same manner as the [sign command](#sign), and then submits the signed transaction. We recommend only using this mode for testing and development.
+
+To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. 
+
+### Submit-Only Mode ###
+
+A submit-only request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| tx_blob | String | Hex representation of the signed transaction to submit. |
+| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
+
+#### Request Format ####
+
+
+<div class='multicode'>
+*WebSocket*
+```
+{
+    "id": 3,
+    "command": "submit",
+    "tx_blob": "1200002280000000240000001E61D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000B732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7447304502210095D23D8AF107DF50651F266259CC7139D0CD0C64ABBA3A958156352A0D95A21E02207FCF9B77D7510380E49FF250C21B57169E14E9B4ACFD314CEDC79DDD0A38B8A681144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+}
+```
+
+*JSON-RPC*
+```
+{
+    "method": "submit",
+    "params": [
+        {
+            "tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+        }
+    ]
+}
+```
+
+*Commandline*
+```
+#Syntax: submit tx_blob
+submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754
+```
+</div>
+
+[Try it! >](ripple-api-tool.html#submit)
+
+
+### Sign-and-Submit Mode ###
+
+A sign-and-submit request includes the following parameters:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| tx_json | Object | [Transaction definition](transactions.html) in JSON format, optionally omitting any auto-fillable fields. |
+| secret | String | (Required if `tx_json` is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
+| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
+| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
+| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. You must omit this field if the transaction is a direct XRP-to-XRP transfer. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |
+| fee\_mult\_max | Integer | (Optional) If the transaction `Fee` is omitted, this field limits the `Fee` value that is automatically filled so that it is less than or equal to the long-term base fee times this value. |
+
+See the [sign command](#sign) for detailed information on how the server automatically fills in certain fields.

 #### Request Format ####
 An example of the request format:
@@ -5472,7 +5544,17 @@ An example of the request format:
    "method": "submit",
    "params": [
        {
-            "tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
+            "secret": "sssssssssssssssssssssssssssss",
+            "tx_json": {
+                "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                "Amount": {
+                    "currency": "USD",
+                    "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                    "value": "1"
+                },
+                "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+                "TransactionType": "Payment"
+            }
        }
    ]
 }
@@ -5487,26 +5569,6 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r

 [Try it! >](ripple-api-tool.html#submit)

-The request includes the following parameters:
-
-| Field | Type | Description |
-|-------|------|-------------|
-| tx_blob | String | (Do not include if tx_json and secret are supplied) Hex representation of the signed transaction to submit. |
-| tx_json | Object | (Do not include if tx_blob is supplied) [Transaction definition](transactions.html) in JSON format |
-| secret | String | (Required if tx_json is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
-| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
-| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. (No effect when specifying the transaction as tx_blob.) |
-
-The JSON format for `tx_json` varies depending on the type of transaction. In the case of sending non-XRP currency (IOUs), you can obtain appropriate values for the `Paths` field by doing a `find_path` or `ripple_find_path` command first. The `Paths` field is not required for sending XRP. The provided path or paths are used as options for the path the payment takes; the server selects one or more of them to use according to its own criteria. You can omit the `Paths` field, but that leaves it up to the server to choose a path on the fly. Since the total cost of making the payment, including transit fees, is automatically deducted from the sending account, you should find paths ahead of time to avoid getting surprised. 
-
-By default, `rippled` tries to compute the cheapest combination of paths, but it may not have the resources to find the best option. A payment may even be broken up into multiple parts that take different paths if that is the cheapest way. An untrustworthy server could be modified to choose paths maliciously. 
-
-If `offline` is not set to true, then the server tries to automatically fill the `Sequence` and `Fee` parameters appropriately. 
-
-To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction. 
-
-You should provide a [LastLedgerSequence](transactions.html#lastledgersequence) field in your transaction to make sure that it expires quickly in the case that it does not succeed. Otherwise, a transaction may end up in limbo, neither failing nor confirming, for a long time.
-
 #### Response Format ####

 An example of a successful response:
Author	SHA1	Message	Date
Rome Reginelli	9c64b787ff	Merge pull request #79 from ripple/gh-pages Dev Portal from Staging to Master for 10/8 second push	2014-10-08 18:41:21 -07:00
Rome Reginelli	07fd5ce872	Merge pull request #78 from mDuo13/gh-pages [DOC] tx_format - clarify partial payments ( DEV-55 )	2014-10-08 18:40:39 -07:00
mDuo13	af8f2ed50e	[DOC] tx_format - clarify partial payments ( DEV-55 )	2014-10-08 18:39:27 -07:00
Rome Reginelli	092d715bfa	Merge pull request #77 from ripple/gh-pages Dev Portal from Staging to Master for 10/8 push	2014-10-08 15:15:56 -07:00
Rome Reginelli	63246c37c2	Merge pull request #76 from mDuo13/gh-pages REST - clarifications on errors and memo unicode	2014-10-08 15:13:16 -07:00
mDuo13	e1fc112df1	[DOC] Added clarification on memos and UTF-8	2014-10-08 15:12:21 -07:00
mDuo13	eb33c7e446	[DOC] REST- slight clarification on error formatting	2014-10-08 14:50:16 -07:00
Rome Reginelli	5bca4a1319	Merge pull request #75 from mDuo13/gh-pages Several important doc improvements including fee_mult_max	2014-10-08 13:19:12 -07:00
mDuo13	07a92022b3	[FIX] REST APItool links updated to reflect new REST docs	2014-10-08 13:17:12 -07:00
mDuo13	ec74ec90cb	[DOC] REST memos, clarifications	2014-10-08 13:12:50 -07:00
mDuo13	2aa95a4023	[DOC] fee_mult_max documentation	2014-10-08 13:12:10 -07:00
mDuo13	fd0354f957	Merge branch 'master' of https://github.com/ripple/ripple-dev-portal into gh-pages	2014-10-08 12:02:22 -07:00
mDuo13	5e229a1138	[DOC] REST revisions for account settings; also some mild restructuring	2014-10-08 12:01:35 -07:00
mDuo13	723e70a5ea	[MERGE] Merge branch 'gh-pages' of https://github.com/mDuo13/ripple-dev-portal into gh-pages	2014-10-06 17:16:25 -07:00
mDuo13	44c9340902	[DOC] rippled - first pass of fee_mult_max	2014-10-06 17:16:07 -07:00
mDuo13	e4374c3214	[MERGE] Merge branch 'gh-pages' of https://github.com/mDuo13/ripple-dev-portal into gh-pages	2014-10-04 10:07:16 -07:00
mDuo13	844640f141	[STYLE] wider tables, more text contrast, fix green buttons	2014-10-03 14:41:33 -07:00
Rome Reginelli	8fe388de6f	Merge pull request #74 from ripple/gh-pages Dev Portal from Staging to Master for 10/3 push	2014-10-03 13:55:45 -07:00
Rome Reginelli	7228faf419	Merge pull request #73 from mDuo13/gh-pages Small revisions in tx_format and rest tool	2014-10-03 13:22:29 -07:00
mDuo13	dff1e04c18	[MERGE] Merge branch 'gh-pages' of https://github.com/mDuo13/ripple-dev-portal into gh-pages	2014-10-03 09:42:15 -07:00
mDuo13	c43c2f0915	[DOC] REST - started reformatting method ref	2014-10-03 09:41:40 -07:00
mDuo13	d99b264cff	[FEATURE] REST API Tool: query p arams for Get Acct Balances	2014-10-03 09:41:06 -07:00
mDuo13	e6f753aa72	[TASK] REST API Tool - remove redundant test accts warning	2014-10-02 16:08:45 -07:00
mDuo13	b909e200fa	[DOC] minor clarification on PreviousTxnID	2014-10-01 14:52:07 -07:00
mDuo13	10fa680688	[DOC] tx_format - alphabetized and clarified AccountTxnID, added Creating Accounts section.	2014-10-01 00:13:41 -07:00
mDuo13	b689061d89	[DOC] tx_format revisions as per pull request #72	2014-09-30 16:37:02 -07:00
Rome Reginelli	8303508670	Merge pull request #71 from mDuo13/gh-pages Updates to tx_format	2014-09-29 16:27:42 -07:00
mDuo13	c7c7f30845	[DOC] tx_format revisions & related rippled submit/sign tweaks	2014-09-29 16:23:14 -07:00
Rome Reginelli	96164d68e2	Merge pull request #9 from ripple/master Catching up to master	2014-09-29 11:11:28 -07:00
Rome Reginelli	3abd182ea8	Merge pull request #70 from sublimator/master merging so credit is given where credit is due; I'll update/edit as necessary	2014-09-29 11:08:11 -07:00
Nicholas Dudfield	a4a9b734f8	Update SetRegularKey section Change Internal Type to Account An account is a 160 bit hash of a public key in compressed form (pub \| sha256 \| ripemd160). The RegularKey field has the same json representation as the Account fields, which are likewise hashes.	2014-09-26 18:53:53 +07:00
Nicholas Dudfield	39f4a1cb08	Update Paths section SendMax implies source balance when no direct trustline to Destination Paths MUST be set when cross-currency/cross-issue payments are made Empty Paths may not be serialized (ripple-lib doesn't serialize them, rippled errors) Crash script for empty Paths: ```shell export ALICE='rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn' export BOB='rPMh7Pi9ct699iZUTWaytJUoHcJ7cgyziK' export ROOT='rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh' function close_ledger() { ./build/rippled ledger_accept } function submit() { ./build/rippled submit $1 "$2" } function json-rpc() { curl -X POST -v http://127.0.0.1:5005 -d "$(cat <<RPC { "method" : "$1", "params" : [$2] } RPC )" \| python -c 'import sys,json; print json.dumps(json.loads(sys.stdin.read()), indent=2)' } submit masterpassphrase "$(cat <<TXN { "TransactionType" : "Payment", "Account" : "$ROOT", "Destination" : "$BOB", "Amount" : "1000000000" } TXN )" close_ledger submit bob "$(cat <<TXN { "TransactionType" : "TrustSet", "Account" : "$BOB", "LimitAmount" : {"value" : "500", "currency" : "USD", "issuer" : "$ROOT"} } TXN )" submit masterpassphrase "$(cat <<TXN { "Account" : "$ROOT" ,"TransactionType" : "Payment", "Destination" : "$BOB" ,"Amount" : {"value" : "1", "currency" : "USD", "issuer" : "$ROOT"} , "Paths" : [] } TXN )" # { # "result" : { # "error" : "internal", # "error_code" : 59, # "error_message" : "Exception occurred during transaction", # "request" : { # "command" : "submit", # "secret" : "masterpassphrase", # "tx_json" : { # "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", # "Amount" : { # "currency" : "USD", # "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", # "value" : "500" # }, # "Destination" : "rPMh7Pi9ct699iZUTWaytJUoHcJ7cgyziK", # "Paths" : [], # "TransactionType" : "Payment" # } # }, # "status" : "error" # } # } ```	2014-09-26 18:47:00 +07:00
Nicholas Dudfield	7582184ea5	Update Memos section: Include `Internal Type` in the table List the `MemoData` and `MemoFormat` fields (TODO: descriptions) Add example json, as the format is "weird" Show that the fields are variable length, and the json for this type is a hex string Make it clear that the 1 kbyte limit applies to the field as serialized For further reference: https://gist.github.com/justmoon/9462822 https://wiki.ripple.com/Example_API_Transactions TODO: Check the semantics and/or usage guidelines behind MemoData/MemoType/MemoFormat	2014-09-26 18:15:42 +07:00
Nicholas Dudfield	4e6adb1f34	Clean trailing whitespace	2014-09-26 18:10:46 +07:00
Nicholas Dudfield	71932be386	PreviousTxnID -> AccountTxnID PreviousTxnID (deprecated) mandates the PreviousTxnID field, present in the transaction to match that in the AccountRoot of the initiating Account. Note that this field is update on EVERY transaction affecting the account (eg. 1 drop inbound payments) See: https://wiki.ripple.com/Transaction_Metadata#Threading Relevant source from Transactor.cpp:211 // Deprecated: Do not use if (mTxn.isFieldPresent (sfPreviousTxnID) && (mTxnAccount->getFieldH256 (sfPreviousTxnID) != mTxn.getFieldH256 (sfPreviousTxnID))) return tefWRONG_PRIOR; if (mTxn.isFieldPresent (sfAccountTxnID) && (mTxnAccount->getFieldH256 (sfAccountTxnID) != mTxn.getFieldH256 (sfAccountTxnID))) return tefWRONG_PRIOR;	2014-09-26 17:58:37 +07:00
Nicholas Dudfield	d79b84ed43	Fix some typos / grammatical errors	2014-09-26 17:51:41 +07:00
Rome Reginelli	1aebd976ea	Merge pull request #69 from ripple/gh-pages Staging to Master for 9/25 push	2014-09-25 18:00:07 -07:00
Rome Reginelli	2430809517	Merge pull request #68 from mDuo13/gh-pages REST API tool improvements	2014-09-25 17:59:10 -07:00
mDuo13	daf5bca353	[FEATURE] REST API Tool breaks out editable components of URL only, move method to a button instead of a dropdown	2014-09-25 17:55:01 -07:00
mDuo13	bd99c824c7	[DOC] REST revisions - intro material and formatting	2014-09-24 18:18:44 -07:00
mDuo13	e0f404ecd7	[FIX] websocket - replaced a missing	2014-09-24 15:38:02 -07:00
				`@@ -0,0 +1 @@`
				var Plugins;(function(n){var t=function(){function n(n){typeof n=="undefined"&&(n=30);this.space=n}return n}(),i;n.AutosizeInputOptions=t;i=function(){function n(t,i){var r=this;this._input=$(t);this._options=$.extend({},n.getDefaultOptions(),i);this._mirror=$('<span style="position:absolute; top:-999px; left:0; white-space:pre;"/>');$.each(["fontFamily","fontSize","fontWeight","fontStyle","letterSpacing","textTransform","wordSpacing","textIndent"],function(n,t){r._mirror[0].style[t]=r._input.css(t)});$("body").append(this._mirror);this._input.on("keydown keyup input propertychange change",function(){r.update()});(function(){r.update()})()}return n.prototype.getOptions=function(){return this._options},n.prototype.update=function(){var n=this._input.val()\|\|"",t;n!==this._mirror.text()&&(this._mirror.text(n),t=this._mirror.width()+this._options.space,this._input.width(t))},n.getDefaultOptions=function(){return this._defaultOptions},n.getInstanceKey=function(){return"autosizeInputInstance"},n._defaultOptions=new t,n}();n.AutosizeInput=i,function(t){var i="autosize-input",r=["text","password","search","url","tel","email","number"];t.fn.autosizeInput=function(u){return this.each(function(){if(this.tagName=="INPUT"&&t.inArray(this.type,r)>-1){var f=t(this);f.data(n.AutosizeInput.getInstanceKey())\|\|(u==undefined&&(u=f.data(i)),f.data(n.AutosizeInput.getInstanceKey(),new n.AutosizeInput(this,u)))}})};t(function(){t("input[data-"+i+"]").autosizeInput()})}(jQuery)})(Plugins\|\|(Plugins={}))