ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-20 📝 Original message: Good morning, CLTV < unix ...
📅 Original date posted:2018-04-20
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/35ebca45/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/35ebca45/attachment.html>;