summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAfanti <127061691+threewebcode@users.noreply.github.com>2024-05-13 10:25:31 +0800
committerGitHub <noreply@github.com>2024-05-13 10:25:31 +0800
commit2157872faa749e02e54d3a47ba9d17ebbefa5c21 (patch)
treea7cac7bd54d7997e1530ffb1e4b11a03850f2e66
parent10e5f62a3851fe465f8d7067d5b19d00adc78513 (diff)
downloadbips-2157872faa749e02e54d3a47ba9d17ebbefa5c21.tar.xz
bip-0114: fix typo
-rw-r--r--bip-0114.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki
index 410e84c..5b07137 100644
--- a/bip-0114.mediawiki
+++ b/bip-0114.mediawiki
@@ -111,7 +111,7 @@ The advantages of the current proposal are:
* If different parties in a contract do not want to expose their scripts to each other, they may provide only <code>H(Subscript)</code> and keep the <code>Subscript</code> private until redemption.
* If they are willing to share the actual scripts, they may combine them into one <code>Subscript</code> for each branch, saving some <code>nOpCount</code> and a few bytes of witness space.
-The are some disadvantages, but only when the redemption condition is very complicated:
+There are some disadvantages, but only when the redemption condition is very complicated:
* It may require more branches than a general MAST design (as shown in the previous example) and take more witness space in redemption
* Creation and storage of the MAST structure may take more time and space. However, such additional costs affect only the related parties in the contract but not any other Bitcoin users.