From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 11AD1F2E for ; Thu, 23 May 2019 19:03:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9876B83A for ; Thu, 23 May 2019 19:03:21 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id g18so6409215otj.11 for ; Thu, 23 May 2019 12:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=eSsAi/5fAL0C3o7CArCJx0Gz6tAZ4A3H+s35hLA40K0=; b=FoEH5lB8LMx/PTtmv2iufbLHMaJydOlmcUTqvXtJhDp6abNib7BeHSrJo58jQ3siar Hb55/8flT3To2lciwKWncJJ8CRnd9xmpyCpfx4wgXi9NM9cTLOSex7xARTShyyonwIIW tpDtmuaTvwif7fAbFiXu0cMedbW89OloVCKkZcxBmzgc6HUksdbsWxdyon4J70HndfD9 A+wKkDiQZGyrjKjOiqwYcn9MV6LskQko9n2XgdpM/j+YHXORQLnA55G3rNgNLZYhtGGg HTJvnmEimEtDFpreDSYFM9C4RpQP7ucWCVsZokKRnBYWX8THQ/ANUFfi7/+9D5+QxXQx v6Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=eSsAi/5fAL0C3o7CArCJx0Gz6tAZ4A3H+s35hLA40K0=; b=hSb1GVzh7gjlWN43L3ZLxSOFfC3qOQfN1x7P4ULmaSangelE69XQa/WaL5WruyNAcj gCWC7nqQtM4uVeSjnQn0lla4rg5ZfvQ4uGwi3988eTYiZidcZJ//NXRsURXHp5Zqcgyp uDXqqcpWk3QMeNMZSPTGggGgzFHT24o3pYkTkHAaVPV1dy53C/MYVKfho8lHBIri8kr2 t6fmm2bY4BZsjSP6XhigqLtDN5LclRlIQGATkhy/mi2bKckPwtTqX64PiXrS5+OuABTQ SvpUTKY1MvPr5xKTn8JPKpzRwVf/mIvhRlDaVUA70Y/if0BA8qFFhQEx9XYjYTZ1+pWt XGmg== X-Gm-Message-State: APjAAAVgiGwcrXTfT3s55X1mJnyXirmtWFdV+XHMKyL9viWR7NWgCIGV dL5hzgklJnKR2uEYThLuFpPiUm44R6aAb46HMFHffg== X-Google-Smtp-Source: APXvYqwntLttZaDDFKr4vlTALj2PoBPnZDa0yMHJZi6AvL79c7/zhxAoz8X3p7kmj70+zbNZ3GR+WrReHH1FZ3GpN8I= X-Received: by 2002:a05:6830:2145:: with SMTP id r5mr5356042otd.226.1558638200872; Thu, 23 May 2019 12:03:20 -0700 (PDT) MIME-Version: 1.0 References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> In-Reply-To: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 23 May 2019 21:03:09 +0200 Message-ID: To: Tamas Blummer , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FROM_EXCESS_BASE64, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 23 May 2019 19:06:44 +0000 Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 19:03:22 -0000 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 wrote: > > Difficulty change has profound impact on miner=E2=80=99s production there= by 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 f= or the block the transaction is included into. > The output script may then decide comparing that value with a strike whic= h key can spend it. > The input of the transaction would be a multi-sig escrow of those who ent= ered 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 signifi= cant economic interest of Bitcoin economy, and is compatible with Bitcoin= =E2=80=99s 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev