summaryrefslogtreecommitdiff
path: root/bip-0116.mediawiki
diff options
context:
space:
mode:
authorcocoyeal <ricodigging@gmail.com>2024-05-29 16:18:11 +0800
committercocoyeal <ricodigging@gmail.com>2024-05-29 16:18:11 +0800
commit46a2440718ce96681155e4c96bfc373d079d2eef (patch)
treeb49a43a013d085727b1ffe38f7a83031ac4f45c0 /bip-0116.mediawiki
parent758a58ab54fddce0c6d062ed8fdf2b28c2eb7790 (diff)
downloadbips-46a2440718ce96681155e4c96bfc373d079d2eef.tar.xz
remove duplicated words
Diffstat (limited to 'bip-0116.mediawiki')
-rw-r--r--bip-0116.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki
index 86b0f9a..70b340f 100644
--- a/bip-0116.mediawiki
+++ b/bip-0116.mediawiki
@@ -59,7 +59,7 @@ This includes execution pathways or policy conditions which end up not being nee
Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying.
Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage.
-Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations.
+Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would otherwise be possible, due to various built-in script size and runtime limitations.
With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies.
==Rationale==