From 3a053c4828377b11b4ad956f9a56c9b4da8b965c Mon Sep 17 00:00:00 2001
From: Christopher Sanborn
 <23085117+christophersanborn@users.noreply.github.com>
Date: Mon, 1 Oct 2018 10:07:56 -0400
Subject: [PATCH] Added a link to an example transaction in main net showing
 cTXO output fields.

---
 bsip-1203.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsip-1203.md b/bsip-1203.md
index 81b39ca..f8b8ec4 100644
--- a/bsip-1203.md
+++ b/bsip-1203.md
@@ -92,6 +92,8 @@ _Field_ | _Purpose_
 **`owner`:** | BitShares owner structure specifying weighted list of keys or accounts that may spend this commitment. (Typically lists just one public key, the "AuthKey" for the cTXO.)
 **`stealth_memo`:** | Also known as the "transaction receipt" when transmitted off-chain.<br><br> **`one_time_key`:** &nbsp; _(EC curve point, 33 bytes)_<br> **`to`:** &nbsp; Use the AuthKey here! _(EC curve point, 33 bytes)_<br> **`encrypted_memo`:** &nbsp; Data that recipient needs to "open" the commitment.<br><br> _The stealth memo is optional as far as the network is concerned, but essential if you want the recipient to be able to detect the incoming transaction without sending a "receipt."_
 
+_(An example transaction showing all these fields can be seen in [block 22157273](https://cryptofresh.com/tx/8182e9d78cbce7df281bc252a9e6d87566ca0622). In this Tx, the stealth_memo '`to`' field names the recipient's address key, rather than the cTXO Auth key, and thus breaks unlinkability.)_
+
 Since the `stealth_memo` field can be used to record both the OTK and the AuthKey, all the wallet needs to do to scan for incoming transactions is to download batches of stealth memos and, for each one, test whether the combination of the OTK and the wallet's Address key yields the AuthKey.  If it does, then use then derive the AES decryption key from _Shared(OTK,AuthKey)_ and use that to read the additional data in `encrypted_memo`. 
 
 Structure of `encrypted_memo`:
@@ -101,7 +103,7 @@ _Field_ | _Purpose_
 **`from_key`:** | Original use:<br><br><ul>Identifies address key of sender **(optional)**. &nbsp; _(EC curve point, 33 bytes)_</ul>Alternate possible uses:<br><br> <ul><li>Instead of ID'ing the 'from' address, could use this field to embed an _invoice nonce_ to allow receiver to correlate payment to an invoice.</li></ul>
 **`amount`:** | Value of commitment. &nbsp; _(Integer, 32 bytes)_
 **`blinding_factor`:** | Blinding factor. &nbsp; _(Integer, 32 bytes)_<br><br>_Note: Except when a blind_sum is needed, the blinding factor is deterministic from a hash of the shared secret, meaning this field can potentially be repurposed or omitted. To guarantee that the blinding factor can always be deterministic, transactions can be padded with a commitment to zero to absorb the blind_sum._
-**`commitment`:** | The Pedersen commitment. &nbsp; _(EC curve point, 33 bytes)_<br><br> _Note: This field is redundent, since the commitment is determined by_ C = amnt * H + blind * G, _and could potentially be omitted._
+**`commitment`:** | The Pedersen commitment. &nbsp; _(EC curve point, 33 bytes)_<br><br> _Note: This field is redundant, since the commitment is determined by_ C = amnt * H + blind * G, _and could potentially be omitted._
 **`check`:** | Checksum to confirm correct decryption. &nbsp; _(4 bytes)_
 
 _(TODO: How is this serialized? Do omitted fields "take up space"?  Can fields be chosen a la carte? How hard will it be to extend this memo format, for, say, multiple assets in the case of CA? See fc::raw::pack.)_