I introduced you to gerneralized covenants[1] earlier, but in a domain specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
A covenant
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
would put a coin under the alternative control of a Transfer and Exit keys together with the script in control of the current owner.
Additional transaction level validations of transactions spending input with covenants apply as in [1]
Owner of such coins would be able to transfer them to others provided an addtional Transfer signature, in which case the coin remains encumbered with the same covenant.
If Exit and owner signs the covenant is dropped on the output, it becomes a plain Bitcoin again.
The Thransfer and Exit signatures could be threshold signatures of a federation, whereby member decide if the proposed transfer transaction complies with whatever unique rules they impose.
The result is a federated side chain embedded into the Bitcoin block chain.
Bob could purchase some asset guarded by the federation with a transaction:
Inputs
100.0001 pk(Bob)
Outputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)
Transfer to Alice with consent of the transfer validators:
Inputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100.001 pk(Alice)
Outputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100 pk(Bob)
Alice might be approved to exit with the exit signature of the federation:
Inputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)
Outputs
99.9999 pk(Alice)
Tamas Blummer