Remove requirement to use "bank" port (closes #463)

cosmos · Aug 6, 2020 · 6280b53 · 6280b53
1 parent 3d1d336
commit 6280b53
Show file tree

Hide file tree

Showing 4 changed files with 4 additions and 8 deletions.
diff --git a/misc/aspell_dict b/misc/aspell_dict
@@ -1,4 +1,4 @@
-personal_ws-1.1 en 624 
+personal_ws-1.1 en 625 
 ABCI
 ABI
 ADR
@@ -474,6 +474,7 @@ proofSpecs
 proofTimeout
 proofTry
 proto
+protobuf
 provableStore
 prover
 pseudocode

diff --git a/spec.pdf b/spec.pdf
diff --git a/spec/ics-004-channel-and-packet-semantics/README.md b/spec/ics-004-channel-and-packet-semantics/README.md
@@ -685,7 +685,7 @@ function acknowledgePacket(
 
 The acknowledgement returned from the remote chain is defined as arbitrary bytes in the IBC protocol. This data
 may either encode a successful execution or a failure (anything besides a timeout). There is no generic way to
-distinguish the two cases, which requires that any client-side packet visualizer understands every app-specific protocol
+distinguish the two cases, which requires that any client-side packet visualiser understands every app-specific protocol
 in order to distinguish the case of successful or failed relay. In order to reduce this issue, we offer an additional
 specification for acknowledgement formats, which [SHOULD](https://www.ietf.org/rfc/rfc2119.txt) be used by the 
 app-specific protocols.
@@ -699,7 +699,7 @@ message Acknowledgement {
 }
 ```
 
-If an application uses a different format for acknowledgement bytes, it MUST not deserialize to a valid protobuf message
+If an application uses a different format for acknowledgement bytes, it MUST not deserialise to a valid protobuf message
 of this format. Note that all packets contain exactly one non-empty field, and it must be result or error.  The field
 numbers 21 and 22 were explicitly chosen to avoid accidental conflicts with other protobuf message formats used
 for acknowledgements. The first byte of any message with this format will be the non-ASCII values `0xaa` (result) 

diff --git a/spec/ics-020-fungible-token-transfer/README.md b/spec/ics-020-fungible-token-transfer/README.md
@@ -101,7 +101,6 @@ that the module itself doesn't need to worry about what connections or channels
 
 Both machines `A` and `B` accept new channels from any module on another machine, if and only if:
 
-- The other module is bound to the "bank" port.
 - The channel being created is unordered.
 - The version string is empty.
 
@@ -116,8 +115,6 @@ function onChanOpenInit(
   version: string) {
   // only unordered channels allowed
   abortTransactionUnless(order === UNORDERED)
-  // only allow channels to "bank" port on counterparty chain
-  abortTransactionUnless(counterpartyPortIdentifier === "bank")
   // assert that version is "ics20-1"
   abortTransactionUnless(version === "ics20-1")
   // allocate an escrow address
@@ -140,8 +137,6 @@ function onChanOpenTry(
   // assert that version is "ics20-1"
   abortTransactionUnless(version === "ics20-1")
   abortTransactionUnless(counterpartyVersion === "ics20-1")
-  // only allow channels to "bank" port on counterparty chain
-  abortTransactionUnless(counterpartyPortIdentifier === "bank")
   // allocate an escrow address
   channelEscrowAddresses[channelIdentifier] = newAddress()
 }