Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-20 📝 Original message: "[]" are placeholders for ...
📅 Original date posted:2018-04-20
📝 Original message:
"[]" 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've
never written Bitcoin script so CSV definitely could be the appropriate
opcode to be use here for a relative time lock.
52560 was meant to be a year in block time, coinciding with the duration of
the name registration.
I'll look into your proof of mainstake as that does sound similar to what
I'm working on here.
Thanks,
Tyler
On Thu, Apr 19, 2018, 23:43 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> Offhand, I am uncertain the first script given in "Technical Proposal"
> works as a "check proof-of-work" script.
>
> Are the "[]" comments? Or are they pushes of actual data embedded in the
> SCRIPT? It seems to be comments...?
>
> 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?
>
> 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.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/3b929dfe/attachment.html>
📝 Original message:
"[]" 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've
never written Bitcoin script so CSV definitely could be the appropriate
opcode to be use here for a relative time lock.
52560 was meant to be a year in block time, coinciding with the duration of
the name registration.
I'll look into your proof of mainstake as that does sound similar to what
I'm working on here.
Thanks,
Tyler
On Thu, Apr 19, 2018, 23:43 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> Offhand, I am uncertain the first script given in "Technical Proposal"
> works as a "check proof-of-work" script.
>
> Are the "[]" comments? Or are they pushes of actual data embedded in the
> SCRIPT? It seems to be comments...?
>
> 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?
>
> 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.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/3b929dfe/attachment.html>