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 00CFB12D2 for ; Fri, 18 Sep 2015 06:43:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 596DFE1 for ; Fri, 18 Sep 2015 06:43:03 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so17904773wic.1 for ; Thu, 17 Sep 2015 23:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MB3qpLJN7hHflC7BQfGxJsuJIN8cVQktpF2o7wWzPtE=; b=XJDD+SyTrjYrY3KkzNC+TCw+HyrVOde1jWJgOjdnJ3ggsuJbYp5AbpXbnAtPt2iA9y Mb8APRJWTyL6t0ve+3JG07fUoLmYOoNd7gERyL1HhUna/TCMLKptUnyZpcrXP6Qt8c3R z3ta8tX706P+lKLuTEqrcROmAip9FyEDnG3n4bwwVSGWlKh+7ERDN3XFOChyRe4nVN9l YVcV2Oa9I1mEd35D2WzgfNC3YD/0I2wyFEEBwFbpx4b0uzoRXXHZSnfoc1xavdKsqD2U 8XvC9UbPks94/XVK3VRewZT2YUFz5Y5ExxAmSGKolhU6DVghM6waiO3kHc6IjBreA7oT MuWw== X-Received: by 10.194.191.164 with SMTP id gz4mr4927901wjc.21.1442558581818; Thu, 17 Sep 2015 23:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.200 with HTTP; Thu, 17 Sep 2015 23:42:42 -0700 (PDT) In-Reply-To: <014345a983eabf243d9ce127de0dff7c@xbt.hk> References: <014345a983eabf243d9ce127de0dff7c@xbt.hk> From: Btc Drak Date: Fri, 18 Sep 2015 07:42:42 +0100 Message-ID: To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=047d7ba98212d64b66051fffd757 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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 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: Fri, 18 Sep 2015 06:43:04 -0000 --047d7ba98212d64b66051fffd757 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Btc Drak =E6=96=BC 2015-09-17 15:12 =E5=AF=AB=E5=88=B0: > >> Forgive me if I have missed the exact use-case, but this seems overly >> complex. Surely fill-or-kill refers to getting a transaction confirmed >> within a few confirms or to drop the tx from the mempool so it wont be >> considered for inclusion anymore. As such, you could just repurpose a >> small range of nLocktime such that a TX will be accepted into mempool >> for a specific period before expiring. >> > > What I'm describing is to implement fill-or-kill as consensus rule. > Certainly, we could implement it at the P2P network level: everything is > the same as I described, but the nLockTime2 and nKillTime are for referen= ce > only and tx validity depends only on the nLockTime. Benevolent miners > should drop the tx after the suggested kill time but there is no guarante= e > Sure, you can make the scheme I describe consensus based by adding the rule tx is not valid to mine after expiry: this still keeps the simplicity I described. --047d7ba98212d64b66051fffd757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org> wrote:
Btc Drak =E6=96=BC 2015-09-17 15:12 =E5=AF=AB=E5=88=B0:
Forgive me if I have missed the exact use-case, but this seems overly
complex. Surely fill-or-kill refers to getting a transaction confirmed
within a few confirms or to drop the tx from the mempool so it wont be
considered for inclusion anymore. As such, you could just repurpose a
small range of nLocktime such that a TX will be accepted into mempool
for a specific period before expiring.

What I'm describing is to implement fill-or-kill as consensus rule. Cer= tainly, we could implement it at the P2P network level: everything is the s= ame as I described, but the nLockTime2 and nKillTime are for reference only= and tx validity depends only on the nLockTime. Benevolent miners should dr= op the tx after the suggested kill time but there is no guarantee

Sure, you can make the scheme I describe consens= us based by adding the rule tx is not valid to mine after expiry: this stil= l keeps the simplicity I described.
--047d7ba98212d64b66051fffd757--