Been giving some thought to Arc's hybrid custody model. This model operates on the premise that you maintain custody of your funds unless you go offline for x weeks or longer, at which point your funds can be reclaimed or swept by the other party involved.
While it's unlikely that most nodes would consent to establishing channels that propose unilateral, fund-sweeping arrangements, such channels could be beneficial for close-knit relationships like family and friends. This is particularly true in situations where one party is more likely to lose their device or private keys than the other. In these cases, the more tech-savvy, reliable or attuned party can sweep and reclaim the funds that their family member or friend would have otherwise lost. With such an arrangement, even grandma could use the lightning network without worrying about losing access to her funds if she misplaces the device or forgets her seed.
To implement this kind of arrangement in the Lightning Network, we would need to define a new type of channel in the open_channel channel_flags message, or apply some similar modification. Let's tentatively label this new channel type as a Unilateral Sweep Channel (USC). Config-wise, nodes would need to specify whether they accept USC channels, which would allow incoming channel requests of this type to be accepted or denied accordingly. Additionally, two configuration options would need to be created: one for the minimum number of blocks before a unilateral sweep and another for the maximum number of blocks before a unilateral sweep a node is willing to agree to for a USC channel. Any incoming open_channel message containing a value below the minimum or above the maximum would be denied.
If this type of channel is accepted between two nodes, they would need to establish separate logic for constructing the commitment transaction for the USC channel. In these channels, the unilateral sweeping ability is granted to the channel initiator and is achieved by modifying the witness script of the channel initiator as follows:
OP_IF
# Penalty transaction
<revocationpubkey>
OP_ELSE
OP_IF
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<local_delayedpubkey>
OP_ELSE
<block_height>
OP_CHECKLOCKTIMEVERIFY
OP_DROP
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<sweepingpubkey>
OP_ENDIF
OP_ENDIF
OP_CHECKSIG
In this script, we're introducing two additional values: block_height and sweepingpubkey. The sweepingpubkey operates in a manner similar to the revocationpubkey, with the key distinction being that the sweepingpubkey is always known, enabling the channel initiator to sweep the funds once the required conditions are met (block_height & to_self_delay).
The block_height is incorporated to set the point at which this transaction can be broadcast. For instance, if Alice opens a USC channel with her Father Bob, and they both agree that Alice can sweep the funds after four weeks, they would set the block_height to current_block_height + 4032. With each new commitment transaction, the block_height value increments by the specified amount (in this case, 4032).
To address scenarios where Alice broadcasts an outdated state using old but now valid block height data, we must also set the to_self_delay. This would afford Bob the time necessary to issue a penalty transaction as usual. Bob's script would not reflect the modifications detailed above and would retain its typical form, allowing Alice to be the sole party able to sweep funds in the USC channel.
Lastly, nodes should aim to update these commitment transactions as frequently as possible to extend the block_height in the condition. If the condition is halfway to being met, the node should seek an updated commitment transaction from its peer. If the channel initiator goes offline and the block height limit is approaching, the recipient of the channel should proactively force-close the channel. This action prevents the block_height from reaching the threshold that would otherwise permit their peer to sweep the funds.
I am getting hung up on whether these nodes are regulated and what kind of new UX is needed, etc...