I'm talking about developing a Bitcoin address with corresponding private keys specifically meant for this purpose —sending fund to multisig address before it's automatically transferred to the recipient.
Escrow would be a contract address between the sender and receiver but this has nothing to do with escrow or contract. It's simply a reversible solution for people who could have their keys stolen.
if you are sending funds to a multisig where you own the keys.. then you are just (in practice) sending funds to yourself.. thus no point needing to call it a refund.. its just you sending funds to yourself.. as a wasted transaction before sending it to someone else
becasue you own the keys you dont need to send it "back" thus no point using it forward before giving it to a recipient..
a multisig is meant for having 2 people combine to control decisions. .. which is escrow
so which are you trying to explain.. wastefully sending funds to yourself in a new address.. pointlessly to want to send it back you YOURSELF if you change your mind/accidentally moved/funds moved via theft. .. its wasteful because you dont need to "send back" because you own the keys for the multisig.. which means a hacker would too!! so you or they can just do with as they please from the address. so its the same as just hoarding from a base utxo address
or .. send coins to a multisig where there is the recipient or a middleman having the other key to co-sign funds forward or back when conditions are met
either way.. those proposals wont help fund thefts of a hoard where there was no situation of wanting funds to move as a spend. but where an invader found the keys..
..
i know you are trying to suggest a CPFP
where a parent address pays a child address.. and the child then pays it forward or back where it moves the coins faster back or forward rather then just paying direct to a recipient.
but again. there ends up no point.. because a hacker will have whatever keys you have so wherever the child funds are the hacker also has.. just like you.
(EG imagine you exposed keys to the internet/hacker via a spend in september 2021, in whatever scheme you make. where you end up needing to use the child keys in your scheme in september. then the hacker has them too because the child keys got exposed too)
............
if you are talking about needing two devices to finalise a payment to a recipient (one device for parent tx to child and second device for child to recipient) well you can do that anyway without needing any special sub layer network or change in protocol. however a hacker wont care because they will just take the parents key. and just send funds direct to hacker address without doing the send to child thing