I like the efficiency your method brings and I&#39;m also not that enthused about bloating the blockchain with &quot;non-financial data&quot;, however I do think there&#39;s value in having the data live in the base chain, both from accessibility and censorship resistance of the data to less additional &quot;networks&quot;. Already today any user that includes a commensurate miner&#39;s fee can use the pushdata opcodes and add whatever data they want to the blockchain.<div><br></div><div>One thing that the design requires is a separate method of communicating bindings and not being censored - if it were onchain, a DNS lookup could simply be no more than a light client requesting the relevant block.</div><div><br></div><div>I think anything that gets seriously far along will need to have some data crunched and if only 100 users per day would fill up blocks then of course constraints would necessitate other avenues.</div><div><br></div><div>Thanks,</div><div>Tyler</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 20, 2018, 00:30 ZmnSCPxj &lt;<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning,<br></div><div><br></div><div>CLTV &lt; unix epoch is for absolute lock time measured sanely in blocks, while &gt; unix epoch is for absolute lock time measured in that arbitrary human-preferred unit called &quot;seconds&quot;.  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).<br></div><div><br></div><div>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)<br></div><div><br></div><div>To create a Numerifides command, a user does the below:<br></div><div><br></div><div>1.  Generates a secret private key p = random() and the public key P = p * G.<br></div><div>2.  Encodes the Numerifides command (it could simply be a mapping &quot;<a href="http://google.com" target="_blank">google.com</a> = 127.0.0.1&quot;) as &quot;command&quot;.<br></div><div>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.<br></div><div>4.  Generates a P2WSH to the script: &lt;52560 blocks&gt; OP_CHECKSEQUENCEVERIFY OP_DROP &lt;C&gt; OP_CHECKSIG<br></div><div>5.  Pays to that P2WSH on the Bitcoin network.<br></div><div>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).<br></div><div><br></div><div>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 &lt;C&gt; replaced with the computed C.<br></div><div><br></div><div>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.<br></div><div><br></div><div>UTXOs that pay to the above construction that have expired the CSV will have the corresponding command deleted from your Numerifides database.<br></div><div><br></div><div>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.<br></div><div><br></div><div>If you insist on bringing in proof-of-work, the proof-of-work can be embedded in the &quot;command&quot; rather than on the Bitcoin blockchain.  All that is published on the Bitcoin blockchain will be the point &lt;C&gt; (33 bytes) and a signature using c (64 bytes) plus a relatively small script, keeping bitcoin-dev happy.<br></div><div><br></div><div>The same scheme can be used for practically any kind of asset I believe, not just names.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></div>