just some small thoughts:
1, from the user experience perspective, I think something predictable will be preferred.
When the work proof is based on counting the PutResponse relayed, the waiting duration will be difficult to predict. Probably, we can have a time limit as well. (say 1 hour and 10 Put responses whichever reached first)
2, Relaying a message won’t create much work for the joining node to do, which means an attack may launch many nodes with limited cost. A more cheap-to-network-but-costly-to-client approach can be: each group member sends out a hash-puzzle to the client regularly. That puzzle even don’t need to be synced among group members. If a member thinks the joining one can’t resolve the puzzle properly, it can remove from the waiting list. If enough members removed the joining one, the connection can be rejected.
3, The main purpose of the RFC is to make an attack pay cost(money and time) to connect. Maybe we can achieve this by two stages: stage 1 pay-for-join and time-to-connect; stage 2 pay-for-join and the hash-puzzle triggered by put_request only.