&quot;[]&quot; are placeholders for the appropriate data. I believed that CLTV less than the Unix epoch would be for a relative time lock but admittedly I&#39;ve never written Bitcoin script so CSV definitely could be the appropriate opcode to be use here for a relative time lock.<div><br></div><div>52560 was meant to be a year in block time, coinciding with the duration of the name registration.</div><div><br></div><div>I&#39;ll look into your proof of mainstake as that does sound similar to what I&#39;m working on here.<br><br>Thanks,</div><div>Tyler<br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, 2018, 23:43 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 Tyler,<br></div><div><br></div><div>Offhand, I am uncertain the first script given in &quot;Technical Proposal&quot; works as a &quot;check proof-of-work&quot; script.<br></div><div><br></div><div>Are the &quot;[]&quot; comments? Or are they pushes of actual data embedded in the SCRIPT?  It seems to be comments...?<br></div><div><br></div><div>OP_CheckLockTimeVerify is absolute time, not relative time.  Why blockheight 52560 in particular?  I believe this was in 2010?  Or are you thinking OP_CHECKSEQUENCEVERIFY which imposes a relative timelock?<br></div><div><br></div><div>Locking funds for a time may be enough without pulling in proof-of-work, especially since the Bitcoin blockchain itself is already proof-of-work.  See my half-baked ideas for proof-of-mainstake, where locking funds in the mainchain is used as voting rights for correctness of the sidechain, avoiding normal proof-of-stake problems since the stake that backs the chain is on a separate proof-of-work chain.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></div>