đź“… Original date posted:2019-05-23
đź“ť Original message:The parameter used is property of the block just like the block height is a property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.
The transaction itself was not invalid in a re-org but evtl. others spending it if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.
Tamas Blummer
> On May 23, 2019, at 21:03, Jorge TimĂłn <jtimon at jtimon.cc> wrote:
>
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
>
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190523/c2fb6e5b/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 18:18:11
in reply to nevent1q…vzva
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 18:18:11Event JSON
{
"id": "5e90e6599c3de94cc20d3934db0da37d8cd0f70a5ca51b8edf099916b4114e36",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686161891,
"kind": 1,
"tags": [
[
"e",
"b72b1e530f79fa4fb81932af44198e28a4dcc369f9d5dfdf733984b5542ef714",
"",
"root"
],
[
"e",
"d5af0e0fa9d961bec7653afeb01a54c902db19ae0ef37264c072cced94cafcae",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2019-05-23\n📝 Original message:The parameter used is property of the block just like the block height is a property and is already evaluated in scripts,\nso no new kind of dependency or encapsulation break.\n\nThe transaction itself was not invalid in a re-org but evtl. others spending it if the difficulty on that fork is different,\nthis is however intended as then on that fork the other was the winner.\n\nTamas Blummer\n\n\u003e On May 23, 2019, at 21:03, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e \n\u003e The complains I could imagine about this, (apart from being a very\n\u003e specific use case) are the same complains I heard about op_expiry.\n\u003e Namely, that in a reorg, the same tx, having been valid in a given\n\u003e block could potentially become invalid in some other block mining it.\n\u003e I guess in this case the situation is less likely in this case than\n\u003e with op_expiry, but it is still possible.\n\u003e Another complain I could imagine is this kind of forces the\n\u003e implementation to break some existing encapsulations, but I guess\n\u003e those are just implementation details not that relevant here.\n\u003e I personally don't have strong feelings towards this proposal one way\n\u003e or the other, I'm just imagining what other people may complain about.\n\u003e \n\u003e On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.\n\u003e\u003e Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.\n\u003e\u003e \n\u003e\u003e I think we could do much better than them natively within Bitcoin.\n\u003e\u003e \n\u003e\u003e A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.\n\u003e\u003e A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.\n\u003e\u003e The output script may then decide comparing that value with a strike which key can spend it.\n\u003e\u003e The input of the transaction would be a multi-sig escrow of those who entered the bet.\n\u003e\u003e The winner would broadcast.\n\u003e\u003e \n\u003e\u003e Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.\n\u003e\u003e \n\u003e\u003e I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.\n\u003e\u003e \n\u003e\u003e Do you see a fault in this proposal or want to contribute?\n\u003e\u003e \n\u003e\u003e Tamas Blummer\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190523/c2fb6e5b/attachment.sig\u003e",
"sig": "d9a66421ee3e9f11756d0603250f4c3cfc9ab9421081a509aca17a034ca61b795135d07c9b555539480d781e6bf133c56f54bfd2b0f68da9e61e2beb07571bb0"
}