From 6c7609f13775c1a6b80b2346eefd5a96a27daca6 Mon Sep 17 00:00:00 2001
From: thephez <thephez@users.noreply.github.com>
Date: Fri, 28 Sep 2018 11:09:47 -0400
Subject: [PATCH] Content - Update Tx malleability

---
 _includes/devdoc/guide_transactions.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/_includes/devdoc/guide_transactions.md b/_includes/devdoc/guide_transactions.md
index db7e9cd4..a6553900 100644
--- a/_includes/devdoc/guide_transactions.md
+++ b/_includes/devdoc/guide_transactions.md
@@ -756,6 +756,14 @@ be added to the block chain immediately. But it does become a problem
 when the output from a transaction is spent before that transaction is
 added to the block chain.
 
+Dash Core 12.3 implemented [BIP-147: Dealing with dummy stack element malleability](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki)
+which fixes a design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY that
+caused them to consume an extra stack element ("dummy element") after signature
+validation. Previously, the dummy element was not inspected in any manner, and could be
+replaced by any value without invalidating the script. BIP147 removed this
+malleability vector by forcing the dummy element to be an empty byte array and
+rejecting anything else.
+
 <!-- Not applicable to Dash
 Bitcoin developers have been working to reduce transaction malleability
 among standard transaction types, one outcome of those efforts is
@@ -786,4 +794,8 @@ in a way that invalidates the lost transaction. One method which will
 always work is to ensure the reissued payment spends all of the same
 outputs that the lost transaction used as inputs.
 
+For additional information regarding the types transaction malleability,
+reference [this blog post](https://blog.dash.org/segwit-lighting-rbf<!--noref-->-in-dash-9536868ca861)
+by one of the Dash Core developers.
+
 {% endautocrossref %}