From 9cc8b275ca809c2a6a1dc51dab651270f103deab Mon Sep 17 00:00:00 2001
From: Jesus Christ <120573631+Gudnessuche@users.noreply.github.com>
Date: Tue, 7 Jan 2025 17:55:22 +0000
Subject: [PATCH] Update bip-0345.mediawiki

Grammatical errors made to make reading easily digestible.
---
 bip-0345.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki
index 2bbb5ee84e..7ae888f3a0 100644
--- a/bip-0345.mediawiki
+++ b/bip-0345.mediawiki
@@ -33,7 +33,7 @@ This document is licensed under the 3-clause BSD license.
 === Motivation ===
 
 The hazard of custodying Bitcoin is well-known. Users of Bitcoin must go to
-significant effort to secure their private keys, and hope that once provisioned
+significant effort to secure their private keys, and hope that once provisioned,
 their custody system does not yield to any number of evolving and
 persistent threats. Users have little means to intervene once a compromise is
 detected. This proposal introduces a mechanism that significantly
@@ -81,7 +81,7 @@ Institutional custodians of Bitcoin may use vaults in similar fashion.
 
 This proposal provides a mitigation to the
 [https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By
-setting the spend delay to, say, a week, and using as the recovery path a
+setting the spend delay to, say, a week, and using as the recovery path, a
 script that enforces a longer relative timelock, the owner of the vault can
 prove that he is unable to access its value immediately. To the author's
 knowledge, this is the only way to configure this defense without rolling