Good morning,
CLTV < unix epoch is for absolute lock time measured sanely in blocks, while >
unix epoch is for absolute lock time measured in that arbitrary human-preferred
unit called "seconds". I believe you mean CSV, as that is for relative lock
time measured in blocks (but note that it has a special encoding, so you might
be able to get 52560 precisely).
The scheme as-is puts a lot of non-financial data onchain, which will make our
bitcoin-dev colleagues cry. We can consider something similar to
pay-to-contract instead, which is similar to Taproot (indeed pay-to-contract is
the basis of Taproot)
To create a Numerifides command, a user does the below:
1. Generates a secret private key p = random() and the public key P = p * G.
2. Encodes the Numerifides command (it could simply be a mapping "google.com =
127.0.0.1") as "command".
3. Computes the pay-to-contract public key: C = P + h(P || command) * G. This
has corresponding private key c = p + h(P || command) that only the user knows.
4. Generates a P2WSH to the script: <52560 blocks> OP_CHECKSEQUENCEVERIFY
OP_DROP <C> OP_CHECKSIG
5. Pays to that P2WSH on the Bitcoin network.
6. Broadcasts command, P, and the txid+outnum of the UTXO that pays to the
P2WSH above, to the Numerifides network (not the Bitcoin network, Bitcoin
cannot understand it).
Numerifides network nodes, on receiving a command+P+outpoint, then verifies it
by confirming that it can get C = P + h(P || command) * G, and that the
outpoint is unspent, and pays to a P2WSH matching the above script template
with the <C> replaced with the computed C.
When the command expires (i.e. the lock time is completed) then the user can
reclaim its locked coins from c = p + h(P || command), meaning it only has to
memorize p and command.
UTXOs that pay to the above construction that have expired the CSV will have
the corresponding command deleted from your Numerifides database.
If two commands conflict, then we simply prefer the one with higher locked
amount (if equal, I do not know, your choice, maybe prefer the earlier one).
And so on. What those commands are can be specified as you wish in your
Numerifides proposal.
If you insist on bringing in proof-of-work, the proof-of-work can be embedded
in the "command" rather than on the Bitcoin blockchain. All that is published
on the Bitcoin blockchain will be the point <C> (33 bytes) and a signature
using c (64 bytes) plus a relatively small script, keeping bitcoin-dev happy.
The same scheme can be used for practically any kind of asset I believe, not
just names.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
