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 1A3D313C2 for ; Sat, 19 Sep 2015 05:09:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D38CE8 for ; Sat, 19 Sep 2015 05:09:24 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so52279674wic.0 for ; Fri, 18 Sep 2015 22:09:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/t8HxxcTrGJYOfDW/qVAZrFs+4u7XNWRFZeAbFOUjdk=; b=QeoQrcOukWEmR1n01OvTh0NVeD25fUR/3vVuXaQC21r9cbrf6HlyoJGhz6C2qDlXij 9n2IPLpWgrJM+GXR9ySztyle/XWxXjc0OZPF0fxrfxc+UCiCpjA4acbQfh42A4IHliix ELWoDWecf8de8klatAA5KTojjplFYis+JnxY664et8ReHI8p9ZUrCL5NtMz6KFhHr+0i Mc5u05bsHHilz9377d0HxrVrALJ/uEYAFsJpgBk6/U6plkcwFLpOSZCIPBwvvOo+9u2O qSFyZIVFOadT/szYevA8SfgGew7ny/IkuuCt5IyH8NCmNcRS0bKeaoLvir1iJIpOW7mP mgig== X-Gm-Message-State: ALoCoQkdSBIDbfdiCGBCbq6kTNvBVb4KL4SkjGHVKHzbixQdGObvKM0BdS+G6Q/Z9PcdP6Y/I/sh MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr10717174wjc.109.1442639363122; Fri, 18 Sep 2015 22:09:23 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 18 Sep 2015 22:09:23 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 18 Sep 2015 22:09:23 -0700 (PDT) In-Reply-To: <201509190201.01455.luke@dashjr.org> References: <201509190201.01455.luke@dashjr.org> Date: Sat, 19 Sep 2015 07:09:23 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke-Jr Content-Type: multipart/alternative; boundary=089e0141aa1ac74589052012a6d8 X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,URIBL_SBL autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Fill-or-kill transaction X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 05:09:25 -0000 --089e0141aa1ac74589052012a6d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How them being expensive to generate make them less likely to be reorged? Would an op_return output used as a nonce to make the hash of the transaction contain some proof of work make the non-coinbase expirable transaction more secure against reorgs? I'm afraid your point is irrelevant. On Sep 19, 2015 4:01 AM, "Luke Dashjr" wrote: > On Thursday, September 17, 2015 7:14:38 PM Jorge Tim=C3=B3n via bitcoin-d= ev > wrote: > > As Mark points out this can be made safe by requiring that all the > outputs > > of a transaction that can expire have op_maturity/csv/rcltv of 100. Tha= t > > makes them as reorg-safe as coinbase transactions. > > Not quite as safe. Remember that mined bitcoins have not only a 100-block > maturity requirement, but *also* are expensive to generate. > Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use... > > Luke > --089e0141aa1ac74589052012a6d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

How them being expensive to generate make them less likely t= o be reorged? Would an op_return output used as a nonce to make the hash of= the transaction contain some proof of work make the non-coinbase expirable= transaction more secure against reorgs?
I'm afraid your point is irrelevant.

On Sep 19, 2015 4:01 AM, "Luke Dashjr"= <luke@dashjr.org> wrote:
On Thursday, September 1= 7, 2015 7:14:38 PM Jorge Tim=C3=B3n via bitcoin-dev wrote:
> As Mark points out this can be made safe by requiring that all the out= puts
> of a transaction that can expire have op_maturity/csv/rcltv of 100. Th= at
> makes them as reorg-safe as coinbase transactions.

Not quite as safe. Remember that mined bitcoins have not only a 100-block maturity requirement, but *also* are expensive to generate.
Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use...

Luke
--089e0141aa1ac74589052012a6d8--