diff options
| author | s7r <s7r@sky-ip.org> | 2015-10-04 15:04:16 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-04 12:04:41 +0000 |
| commit | 3a73fbc0df9972cdb2ce1f1b319da365edcaaf59 (patch) | |
| tree | f31d18b28df2ec4f284758fc7ca477d9cd47e408 | |
| parent | 3212492e2047c469f4aa78f7862ac6542e2db1f3 (diff) | |
| download | pi-bitcoindev-3a73fbc0df9972cdb2ce1f1b319da365edcaaf59.tar.gz pi-bitcoindev-3a73fbc0df9972cdb2ce1f1b319da365edcaaf59.zip | |
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
| -rw-r--r-- | 98/dbe3d9505f62b443feec16d4b6de3e447adb8e | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/98/dbe3d9505f62b443feec16d4b6de3e447adb8e b/98/dbe3d9505f62b443feec16d4b6de3e447adb8e new file mode 100644 index 000000000..cad6b0575 --- /dev/null +++ b/98/dbe3d9505f62b443feec16d4b6de3e447adb8e @@ -0,0 +1,204 @@ +Return-Path: <s7r@sky-ip.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 08ECA192C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 4 Oct 2015 12:04:41 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from outbound.mailhostbox.com (outbound.mailhostbox.com + [162.222.225.17]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id A42ED26C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 4 Oct 2015 12:04:32 +0000 (UTC) +Received: from [0.0.0.0] (relay3.tor.maximilian-jacobsen.com [92.222.252.206]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) + (Authenticated sender: s7r@sky-ip.org) + by outbound.mailhostbox.com (Postfix) with ESMTPSA id D1BFD783360; + Sun, 4 Oct 2015 12:04:25 +0000 (GMT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org; + s=20110108; t=1443960268; + bh=AH0vcvZPUtPACrXSJ4LdAqBcbRD8SsYPNuxXlw+mYbA=; + h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; + b=Nl5SWcmECHc9P99Ta2cOxp2RA2Xx4mANlwWhcbEbtlj0NVS3bmS70mJltAmsD8bVe + q06BV8LgNo/mPQ9ZN6US+Kiz01EV3m5Qn+GrJRccn697iKipUGTpI5o/LyhWMw+ci5 + nI5yn3sB6BIULOzEiMi+ucDGIJM+EqajPVE6sEik= +Reply-To: s7r@sky-ip.org +References: <20151003143056.GA27942@muck> <20151004083525.GA18291@navy> +To: Anthony Towns <aj@erisian.com.au>, Peter Todd <pete@petertodd.org> +From: s7r <s7r@sky-ip.org> +X-Enigmail-Draft-Status: N1110 +Message-ID: <561115C0.3080601@sky-ip.org> +Date: Sun, 4 Oct 2015 15:04:16 +0300 +User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 + Thunderbird/38.3.0 +MIME-Version: 1.0 +In-Reply-To: <20151004083525.GA18291@navy> +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: 8bit +X-CMAE-Score: 0 +X-CMAE-Analysis: v=2.1 cv=ALXFTbJy c=1 sm=1 tr=0 + a=fprIrJRbhJgrpfilpkVy7A==:117 a=fprIrJRbhJgrpfilpkVy7A==:17 + a=N659UExz7-8A:10 a=ii4Wo4WLkbxurG_m1VUA:9 a=hEe4lACS1XNLRuMv:21 + a=vth5ueeHYeKuAzyc:21 a=pILNOxqGKmIA:10 +X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,URIBL_BLACK autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: bitcoin-dev@lists.linuxfoundation.org +Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to + motivate the change +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 04 Oct 2015 12:04:41 -0000 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA256 + +Hi aj, + +On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote: +> On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via +> bitcoin-dev wrote: +>> So we need to make the case for two main things: 1) We have +>> applications that need a relative (instead of absolute CLTV) 2) +>> Additionally to RCLTV, we need to implement this via nSequence +> +>> However I don't think we've done a good job showing why we need +>> to implement this feature via nSequence. BIP68 describes the new +>> nSequence semantics, and gives the rational for them as being a +>> "Consensus-enforced tx replacement" mechanism, with a +>> bidirectional payment channel as an example of this in action. +>> However, the bidirectional payment channel concept itself can be +>> easily implemented with CLTV alone. +> +> Do you mean "with RCLTV alone" here? +> +> RCLTV/OP_CSV is used in lightning commitment transactions to +> enforce a delay between publishing the commitment transaction, and +> spending the output -- that delay is needed so that the +> counterparty has time to prove the commitment was revoked and claim +> the outputs as a penalty. +> + +I partially understand - can you please provide a simple Alice and Bob +example here with the exact scenario? Thanks. Why is there a need to +'delay between publishing the commitment transaction and spending the +output'? If the absolute CLTV script reached its maturity it means +something went wrong (e.g. counterparty cheated or got hit by a bus) +so what is with the delay time needed for proving that the commitment +was revoked? I assume an absolute CLTV script reaching its maturity +(nLockTime) is the proof itself that the commitment was revoked - but +maybe I'm missing something obvious, sorry if this is the case. + +> Using absolute CLTV instead would mean that once the effective +> delay a commitment transaction has decreases over time -- initially +> it will be longer than desirable, causing unwanted delays in +> claiming funds when no cheating is going on; but over time it will +> become too short, which means there is not enough time to prove +> cheating (and the channel has to be closed prematurely). You can +> trade those things off and pick something that works, but it's +> always going to be bad. +> +I agree, I see the logic here. Absolute CLTV is not necessary inferior +to RCLTV - there are use cases and use cases. For example, you can +avoid unnecessary waiting until the nLockTime expires if you use +absolute CLTV in combination with P2SH (2/2). Again, it always depends +on the use case - it might be a good solution, it might not be such a +good solution, but even absolute CLTV alone clearly fixes a lot of +things and takes smart contracts to the next level. + +>> There is a small drawback in that the initial transaction could +>> be delayed, reducing the overall time the channel exists, but the +>> protocol already assumes that transactions can be reliably +>> confirmed within a day - significantly less than the proposed 30 +>> days duration of the channel. +> +> Compared to using a CLTV with 30 days duration, With RCLTV a +> channel could be available for years (ie 20x longer), but in the +> case of problems funds could be reclaimed within hours or days (ie +> 30x faster). +> +Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it +would be neat to have both, but if I can only have (for the time +being) absolute CLTV so be it - it's still a lot better. + +> But that's all about RCLTV vs CLTV, not about RCLTV vs +> nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily +> BIP 68 (nSequence relative locktime), if they could be +> disentangled. +> +> You could do all that with "<n> OP_CHECK_HEIGHT_DELTA_VERIFY" that +> ignores nSequence, and directly compares the height of the current +> block versus the input tx's block (or the diff of their +> timestamps?) though, I think? +> +> I think the disadvantage is that (a) you have to look into the +> input transaction's block height when processing the script; and +> (b) you don't have an easy lookup to check whether the transaction +> can be included in the next block. +> +> You could maybe avoid (b) by using locktime though. Have "<n> +> OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions +> locktime against the input's block height or time; if the locktime +> is 0 or too low, the transaction is invalid. (So if nLockTime is in +> blockheight, you can only spend inputs with blockheight based +> OP_CRLTV tests; and if it's in blocktime, you can only spend inputs +> with blocktime based OP_CRLTV. "n" does need to encode whether it's +> time/block height though). +> +> That way, when you see a txn: +> +> - run the script. if you see <n> RCLTV, then + if the tx's locktime +> isn't set, it's invalid; drop it + if the input txn is unconfirmed, +> it's invalid; try again later + workout "locktime - n" if that's >= +> the input tx's block height/time, it's good; keep it in mempool, +> forward it, etc +> +> - if you're mining, include the tx when locktime hits, just like +> you would any other valid tx with a locktime +> +> I think the use cases for BIP68 (nSequence) are of the form: +> +> 1) published input; here's a signed tx that spends it to you, +> usable after a delay. might as well just use absolute locktime +> here, though. +> +> 2) here's an unpublished input, you can build your own transaction +> to spend it, just not immediately after it's published. BIP112 is +> required, and OP_RCLTV as defined above works fine, just include +> it in the published input's script. +> +> 3) here's an unpublished input, and a signed transaction spending +> it, that you can use to spend it after a delay. BIP68 is enough; +> but OP_RCLTV in the second transaction works here. however without +> normalised tx ids, the input could be malleated before +> publication, so maybe this use case isn't actually important +> anyway. +> +> So I think OP_CRLTV alone works fine for them too... +> +> (Does that make sense, or am I missing something obvious?) +> +> Cheers, aj +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.0.22 (MingW32) + +iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9 +mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k +dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb +j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD +/csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th +RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk= +=U0N6 +-----END PGP SIGNATURE----- + |