diff options
| author | Afanti <127061691+threewebcode@users.noreply.github.com> | 2024-05-13 10:25:31 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-05-13 10:25:31 +0800 |
| commit | 2157872faa749e02e54d3a47ba9d17ebbefa5c21 (patch) | |
| tree | a7cac7bd54d7997e1530ffb1e4b11a03850f2e66 /bip-0114.mediawiki | |
| parent | 10e5f62a3851fe465f8d7067d5b19d00adc78513 (diff) | |
bip-0114: fix typo
Diffstat (limited to 'bip-0114.mediawiki')
| -rw-r--r-- | bip-0114.mediawiki | 2 |
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. |