I appreciate the discussion above and I do think some second layer technology such as LN or something similar to ZK-Rollups would be nice to implement with Grin on the long run. However, for me the usability problem, if any, is more pragmatic. Being both connected/ having an interactive transaction, is not the problem.
Lets say I want to send Grin to someone by phone for my beer on a crypto event. I do not want to send a QR code or file via messaging Apps, have them manually signe the transaction, and send another QR code back again. Simply having a mobile wallet that through a single step can connect over TOR, e.g. after reading a QR code from the receiver, and automatically send, sign and publishebthe transaction, has a higher priority. When the transaction is complete, the wallet should switch tor ID’s for both the sender and receiver. For me, developing something like that would be more pressing than implementing second layer technology since it does not require fundemental changes while greatly improving users experience in making mobile payments.
Optionally, one could generate a receiving QR code with a longer life span, e.g. last for a couple of hourse so it can be printed and used for the whole crypto event. For any end user payments would therefore be the same as any other crypto currency, since the QR with the receivers tor ID feels no different from a QR code with a receivers address. Users of Grin who want to pay can scan the QR code for the whole night and transfer their drinking money and the tor ID of the receiver is only switched when the event is finished. Signing and sending back transactions to your own wallet should be automatic.
Regarding, receiving transactions while being offline. I am not sure it is currently different when signing a transaction for sending and receiving. If one could have a seperate receiving signing key and sending signing key, one could use a simple third party scheme to accept receipt and sign while paying a small fee. Even beter, one could share it to multiple actors, nodes that are willing to sign for offline wallet, which can compete to be the first one to sign your transaction and obtain a small fee. In my opinion this would be better tha Grin box since it is decentralised oposed to how Grin boxes work. Prefarably the origin of such a receiving key would be scrambled when distributed on the node network, similar how send transactions are scrambled for privacy reasons. To protect overflow by an attacker sending fake receiving keys, as somewhere mentioned above, one could put a minimum treshold of e.g. 0.1 Grin on such a receiving wallet. This would only lead to a small loss of privacy, but I think for those who are unwilling to accept the slight inconvenience of needing to be online, this would be an acceptable trade off. The wallet software could generate it as a second receiving only internal wallet, which will be emptied up to the minimum holding amount of 0.1 Grin to the normal offline wallet once it goes online. Since this basically means you have two wallets in one, it would mean the user does have to specifiy to anyone whether to send to the always online wallet, or the normal wallet which needs to be online to receive transactions.
Just a crazy idear:
How about using the camera plus flashlight to ‘BEAM’ the transaction slate back and forth. For a user this would be a simple experience without having to actually connect phones. Just pointing the phone to one another an let them transfer the transaction slate back and forth by light as a binary message (the armored slate will ensure the transaction will not be corrupted). At least for doing a daily payment this would be great. I doubt the transfer speed would be sufficient, about 130 Hrtz/bits per second, camera probably maxed at 60 FP/s so 60 bits per second), but the idear just looks cool to me 
.