diff --git a/generic-structures/draft-steele-cose-merkle-tree-proofs.html b/generic-structures/draft-steele-cose-merkle-tree-proofs.html index 79985f5..6defdf4 100644 --- a/generic-structures/draft-steele-cose-merkle-tree-proofs.html +++ b/generic-structures/draft-steele-cose-merkle-tree-proofs.html @@ -1440,7 +1440,7 @@

Implementers should not expect interoperability accross "verifiable data structures", but they should expect conceptually similar properties across registered proof types.

For example, 2 different merkle tree based verifiable data structures might both support proofs of inclusion. -Protocols requireing proof of inclusion ought to be able to preserve their functionality, +Protocols requiring proof of inclusion ought to be able to preserve their functionality, while switching from one verifiable data structure to another, so long as both structures upport the same proof types.

diff --git a/generic-structures/draft-steele-cose-merkle-tree-proofs.txt b/generic-structures/draft-steele-cose-merkle-tree-proofs.txt index 847ecc8..d8b3e3d 100644 --- a/generic-structures/draft-steele-cose-merkle-tree-proofs.txt +++ b/generic-structures/draft-steele-cose-merkle-tree-proofs.txt @@ -210,8 +210,8 @@ Table of Contents properties across registered proof types. For example, 2 different merkle tree based verifiable data structures - might both support proofs of inclusion. Protocols requireing proof - of inclusion ought to be able to preserve their functionality, while + might both support proofs of inclusion. Protocols requiring proof of + inclusion ought to be able to preserve their functionality, while switching from one verifiable data structure to another, so long as both structures upport the same proof types.