Update p2p.asciidoc

p2p.asciidoc

@@ -108,15 +108,15 @@ Using BOLT #9 we can break down the above string as follows:
 |===
 
 
-If Alice sees this string in a node announcement message from Bob's node, then it knows from bits 16 and 17 that Bob's node supports multi-part payments.
-And because the pair is odd, Alice's node knows that the feature is backwards-compatible.
+If Alice sees this string in a node announcement message from Bob's node, then she knows from bits 16 and 17 that Bob's node supports multi-part payments.
+And because the pair is odd, Alice knows that the feature is backwards-compatible.
 If Alice also has multi-part payments enabled, then Alice and Bob can make use of this feature.
 If Alice does not have multi-part payments enabled, she can simply ignore this and get on with her life.
 She could still open a channel with Bob without having the feature enabled herself.
 However, if the feature bits were even then the feature would be mandatory.
 If Alice did not also have this feature enabled, she would have to find another node to open a channel with.
 Alice also knows from bits 18 and 19 that Bob does not have large channels enabled.
-If she has would like to open a large channel, then she would have to find someone else to open it with.
+If she would like to open a large channel, then she would have to find someone else who has large channels enabled to open it with.
 
 In this way, upgrades and new features can be rolled out on the Lightning Network in an asynchronous bottom-up way.
 Users can enable the features they want when they are ready to do so.