From 47844cf05bb7321d06f4cf27a22eb119f37f8a26 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Wed, 12 Apr 2017 16:43:46 -0700
Subject: [PATCH] Ledger Format: Add missing SignerList index format while
 we're here

---
 content/reference-ledger-format.md | 8 ++++++++
 reference-ledger-format.html       | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/content/reference-ledger-format.md b/content/reference-ledger-format.md
index 212410a918..30f4de3864 100644
--- a/content/reference-ledger-format.md
+++ b/content/reference-ledger-format.md
@@ -632,5 +632,13 @@ When processing a multi-signed transaction, the server dereferences the `Account
 
 A SignerList contributes to its owner's [reserve requirement](concept-reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) node in the ledger.
 
+### SignerList Index Format
+
+The `index` of a SignerList node is the SHA-512Half of the following values put together:
+
+* The RippleState space key (`S`)
+* The AccountID of the owner of the SignerList
+* The SignerListID (currently always `0`)
+
 
 {% include 'snippets/rippled_versions.md' %}
diff --git a/reference-ledger-format.html b/reference-ledger-format.html
index c4dbe4ab6d..4554be626e 100644
--- a/reference-ledger-format.html
+++ b/reference-ledger-format.html
@@ -160,6 +160,7 @@
 <li class="level-2"><a href="#signerlist">SignerList</a></li>
 <li class="level-3"><a href="#signerentry-object">SignerEntry Object</a></li>
 <li class="level-3"><a href="#signerlists-and-reserves">SignerLists and Reserves</a></li>
+<li class="level-3"><a href="#signerlist-index-format">SignerList Index Format</a></li>
 
             </ul>
         </div>
@@ -1400,6 +1401,13 @@
 <p>When processing a multi-signed transaction, the server dereferences the <code>Account</code> values with respect to the ledger at the time of transaction execution. If the address <em>does not</em> correspond to a funded <a href="#accountroot">AccountRoot node</a>, then only the master secret associated with that address can be used to produce a valid signature. If the account <em>does</em> exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.</p>
 <h3 id="signerlists-and-reserves">SignerLists and Reserves</h3>
 <p>A SignerList contributes to its owner's <a href="concept-reserves.html">reserve requirement</a>. The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line (<a href="#ripplestate">RippleState</a>) or <a href="#offer">Offer</a> node in the ledger.</p>
+<h3 id="signerlist-index-format">SignerList Index Format</h3>
+<p>The <code>index</code> of a SignerList node is the SHA-512Half of the following values put together:</p>
+<ul>
+<li>The RippleState space key (<code>S</code>)</li>
+<li>The AccountID of the owner of the SignerList</li>
+<li>The SignerListID (currently always <code>0</code>)</li>
+</ul>
 <!-- rippled release notes links -->
     </div>
       </main>