Flavien Charlon [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-02 📝 Original message:Very good, I like the ...
📅 Original date posted:2014-10-02
📝 Original message:Very good, I like the proposal.
A question I have: can it be used to do the opposite, i.e. build a script
that can only be spent up until block X?
On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org>
> >wrote:
> >> >Thoughts on some way to have the stack item be incremented by the
> >> >height at
> >> >which the scriptPubKey was in a block?
> >>
> >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> >> scriptPubKey would be:
> >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> >> (fails unless top stack item is equal to the txin block height)
> >> <delta height> ADD
> >> (top stack item is now txin height + delta height)
> >> CHECKLOCKTIMEVERIFY
> >
> >This sounds do-able, although it doesn't address using timestamps.
>
> For timestamps replace "height" with "time" in the above example; the
> minimum block time rule will prevent gaming it.
>
>
> >> You'd want these sacrifices to unlock years into the future to
> >thoroughly
> >> exceed any reasonable business cycle; that's so far into the future
> >that
> >> miners are almost certain to just mine them and collect the fees.
> >
> >For many use cases, short maturity periods are just as appropriate IMO.
>
> Very easy to incentivise mining centralisation with short maturities. I
> personally think just destroying coins is better, but it doesn't sit well
> with people so this is the next best thing.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
> JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
> f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
> 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
> 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
> vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
> SOgO
> =WybM
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141002/d08a3134/attachment.html>
📝 Original message:Very good, I like the proposal.
A question I have: can it be used to do the opposite, i.e. build a script
that can only be spent up until block X?
On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org>
> >wrote:
> >> >Thoughts on some way to have the stack item be incremented by the
> >> >height at
> >> >which the scriptPubKey was in a block?
> >>
> >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> >> scriptPubKey would be:
> >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> >> (fails unless top stack item is equal to the txin block height)
> >> <delta height> ADD
> >> (top stack item is now txin height + delta height)
> >> CHECKLOCKTIMEVERIFY
> >
> >This sounds do-able, although it doesn't address using timestamps.
>
> For timestamps replace "height" with "time" in the above example; the
> minimum block time rule will prevent gaming it.
>
>
> >> You'd want these sacrifices to unlock years into the future to
> >thoroughly
> >> exceed any reasonable business cycle; that's so far into the future
> >that
> >> miners are almost certain to just mine them and collect the fees.
> >
> >For many use cases, short maturity periods are just as appropriate IMO.
>
> Very easy to incentivise mining centralisation with short maturities. I
> personally think just destroying coins is better, but it doesn't sit well
> with people so this is the next best thing.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
> JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
> f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
> 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
> 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
> vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
> SOgO
> =WybM
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141002/d08a3134/attachment.html>