This is not true.  Transacting with bitcoin requires bi-directional communications between transacting parties, but maintaining a local copy of the blockchain most certainly does not.


This would work also, but is not required per the light client protocol.  What has been proposed is to broadcast the blocks as they are published, and ultimately to broadcast the blocks "naked" once that protocol is ready.  The reason is that, eventually, most user clients will be some flavor of light client.  Unlike a full client, that are normal today, a light client doesn't care about all of the transactions in a block, and doesn't participate in the p2p bitcoin network (other than as an edge node, listening for it's own transactions).  A light client can fucntion just fine with occasional access to a bridge node (such as an electrum node) that can provide the light client information concerning transactions it's seen with addresses that the light client manages.  All that the light client requires is the blockchain headers and the merkel trees of block that contain input transactions for all of it's own addresses.  Broadcasting the published blocks would provide an alternative method for light clients to aquire the most recent block headers & merkle trees.  A light client may or may not keep the merkle trees for the blocks that it doesn't have input transactions, but as small as they are individually, the actual transactions are the bulk of data a full node sees while connected to the p2p network, and a light client has no use for most of these transactions.  Datacasting of naked blocks (block headers and merkle trees with all transactions pruned out) to either light clients directly or to disconnected bridge nodes used as intermediaries would permit bitcoin economies to function with only slow or occasional access to the Internet.