📅 Original date posted:2014-10-01
📝 Original message:-----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-----
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:26:06
in reply to nevent1q…nxa0
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:26:06Event JSON
{
"id": "9ae24f42ef327e7cdb98981da56b36f48d17c31871a1850aa344f8ca7eb04293",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686151566,
"kind": 1,
"tags": [
[
"e",
"b0d4dbe43a898155b6750ed1dce6a700ce007fe7f2dce49b1bbfe7e2cca60c4c",
"",
"root"
],
[
"e",
"8af6cb574939f69429b401d927ee5fd64909289b70e6cca85f870244a4f59e1f",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2014-10-01\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n\n\nOn 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003eOn Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:\n\u003e\u003e On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr \u003cluke at dashjr.org\u003e\n\u003ewrote:\n\u003e\u003e \u003eThoughts on some way to have the stack item be incremented by the\n\u003e\u003e \u003eheight at\n\u003e\u003e \u003ewhich the scriptPubKey was in a block?\n\u003e\u003e\n\u003e\u003e Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.\n\u003e\u003e scriptPubKey would be:\n\u003e\u003e GET-TXIN-BLOCKHEIGHT-EQUALVERIFY\n\u003e\u003e (fails unless top stack item is equal to the txin block height)\n\u003e\u003e \u003cdelta height\u003e ADD\n\u003e\u003e (top stack item is now txin height + delta height)\n\u003e\u003e CHECKLOCKTIMEVERIFY\n\u003e\n\u003eThis sounds do-able, although it doesn't address using timestamps.\n\nFor timestamps replace \"height\" with \"time\" in the above example; the minimum block time rule will prevent gaming it.\n\n\n\u003e\u003e You'd want these sacrifices to unlock years into the future to\n\u003ethoroughly\n\u003e\u003e exceed any reasonable business cycle; that's so far into the future\n\u003ethat\n\u003e\u003e miners are almost certain to just mine them and collect the fees.\n\u003e\n\u003eFor many use cases, short maturity periods are just as appropriate IMO.\n\nVery 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.\n-----BEGIN PGP SIGNATURE-----\nVersion: APG v1.1.1\n\niQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8\ncGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o\nJwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV\nf5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb\n63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr\n1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm\nvrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq\nSOgO\n=WybM\n-----END PGP SIGNATURE-----",
"sig": "2a142a38d76a77c65b34701e0e8ddc2b02385294cee47c123d8e967c98aabce095ed98682f60287453cfc6a274731f6f454ed0a016164cb1523c0699cefe71fe"
}