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 272F5BBD for ; Fri, 7 Sep 2018 05:02:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 853EB8B for ; Fri, 7 Sep 2018 05:02:31 +0000 (UTC) Received: by mail-wr1-f49.google.com with SMTP id n2-v6so13571584wrw.7 for ; Thu, 06 Sep 2018 22:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FIZb8Y5LvraqH/38viDIKqGgEXBKBpSoxDMearZitWY=; b=TtzrkIxWj9jydKbU0MUa1p5adDMWxpELKIxCwe14ACtAFcsoXVg2LXg3kA6pSZzwZ2 FGGPPSGRvWNsc3zZqiEKPRaw3WuP06gOdPCVJagBRhyeXXtM5bbk38z1/c0NYcnCMrX1 nbTfOkovnQhBvrE88e8xP1gYW4JNh0xEPqXgGwpG17HholErFpR7f7DYOG8ViXX/1pbM 6RFKpafNCLd/6KndS6+W5C4Vfybv5QoXmFGf/22+ksQyqjMZLPduVKlUBFPkd6rzn2p+ k/gC6aZ6rBZM6zl7ZprFYhVuyb6muXWw/eO2/C90mQmxjejDMCELheZ4pSc0GbR4Cmqb /4iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FIZb8Y5LvraqH/38viDIKqGgEXBKBpSoxDMearZitWY=; b=BCeMqAK0DTvnOQWKoNETuEeyUTEj32dnzI/lK8T+/bCXSQAORox80Cs0034m8foNRv cDr0ZOMp4XKUGJFBavgLpghsRz26FVfJf0fCwEU6XI1UdwfLPdBl4OJvobYK9hupig/k f+2DEBTzl5kDEFEUamqA1SOkLasCQRlodc4p323sDK8rTqVcHyMnF2AAef2Nyd7Bx5r+ qQO9LSALi/1MooN1kZfrVvHd9dZ3qcsogyxvHWU0g4swYrbNUiGEEfQNjux6r8Btmrty NU4vS363P8Gyw8w+LE0cVrrNYWkrPDSWKRnx/Dt8E664f+4wV9jGVY1szjRZs4veRdGu cdow== X-Gm-Message-State: APzg51BHnkT3W79nx3/BBuCV0uTxYX+iTGeNu/yCc0hbP4tbkH14l5Lm tWHBB8c0HRj2hEvNdTKzBR9iVS19ITkxxuppaCTLSQ== X-Google-Smtp-Source: ANB0Vdb8GTXTYh7/2gcASXu5CGIZS1ZuT8KZ1XKJht+wh2i/pRQvHc2EhE0JRCNzxv2xIJ5QLAKEmXVy4nMLN8vWU/E= X-Received: by 2002:adf:8205:: with SMTP id 5-v6mr4625860wrb.160.1536296549918; Thu, 06 Sep 2018 22:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:c703:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 22:02:29 -0700 (PDT) In-Reply-To: <20180906203244.GQ62902@hank.reardencode.com> References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> <20180906203244.GQ62902@hank.reardencode.com> From: Terry McLaughlin Date: Fri, 7 Sep 2018 00:02:29 -0500 Message-ID: To: Brandon Smith , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000020ac28057540ea6c" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,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: Fri, 07 Sep 2018 13:43:16 +0000 Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' 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: Fri, 07 Sep 2018 05:02:32 -0000 --00000000000020ac28057540ea6c Content-Type: text/plain; charset="UTF-8" Please help me guide me in the direction I need to go On Thursday, September 6, 2018, Brandon Smith via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I made a similar proposal about 7 months ago, and documented some of the > discussion points here: > > https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz. > mediawiki > > On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev > wrote: > > Functionality such as this does not currently exist not because no one > > thought of it before, but because it has been proposed many times > > before and determined to be harmful. The existing design of CLTV/CSV > > were carefully constructed to make it impossible for a transaction to > > go from valid to invalid based on the time. The most naive > > construction-- e.g. push the current time/height on the stack-- would > > have that property and was specifically avoided. > > > > When a spend goes from valid to invalid it means that a reorganization > > will destroy coins even completely absent any dishonest actions of the > > coins prior owner in the coins recent casual history. Effectively a > > coin with any kind of non-monotone validity event in its recent > > history functions like a recently generated coin: a coin that reorgs > > destroy. Bitcoin addresses the issue for recently generated coins by > > not permitting their use for 100 blocks. I've yet to see an argument > > for a use case for non-monotone validity that still sounds useful once > > the negative effects are addressed (e.g. by subjecting coins that have > > gone through them to a maturity limitation). > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000020ac28057540ea6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please help me guide me in the direction I need to go=C2=A0

On Thurs= day, September 6, 2018, Brandon Smith via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
I made a similar propos= al about 7 months ago, and documented some of the
discussion points here:

https://github.com/reardencode/bips/blo= b/reverselocktime/bip-0zzz.mediawiki

On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev wrot= e:
> Functionality such as this does not currently exist not because no one=
> thought of it before, but because it has been proposed many times
> before and determined to be harmful.=C2=A0 The existing design of CLTV= /CSV
> were carefully constructed to make it impossible for a transaction to<= br> > go from valid to invalid based on the time. The most naive
> construction-- e.g. push the current time/height on the stack-- would<= br> > have that property and was specifically avoided.
>
> When a spend goes from valid to invalid it means that a reorganization=
> will destroy coins even completely absent any dishonest actions of the=
> coins prior owner in the coins recent casual history. Effectively a > coin with any kind of non-monotone validity event in its recent
> history functions like a recently generated coin: a coin that reorgs > destroy. Bitcoin addresses the issue for recently generated coins by > not permitting their use for 100 blocks.=C2=A0 I've yet to see an = argument
> for a use case for non-monotone validity that still sounds useful once=
> the negative effects are addressed (e.g. by subjecting coins that have=
> gone through them to a maturity limitation).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listi= nfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/b= itcoin-dev
--00000000000020ac28057540ea6c--