Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E583440A for ; Mon, 20 Jul 2015 20:30:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 273D9155 for ; Mon, 20 Jul 2015 20:30:10 +0000 (UTC) Received: by lbbqi7 with SMTP id qi7so22030862lbb.3 for ; Mon, 20 Jul 2015 13:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MaY7nfONJVagy31ZyQ5LQVZz5UGzZEzPPJkT12Q8hNc=; b=ItnpzBUtQsPaaGndzptlNEZuPjzC8KLnG1oxIWjwzBIfn5TnoboAyEdWMMsdhj0o/3 fn2wTtJPk45vJu78/GDlansKBwC1beYSAtMMNXnoJMrd6VOgh76iU/vULajIiLluIfZI D9UdxOsYWEaVQTdZtrdnVd4FPgoS9F/6t2bX2aBIt+gTfxhxybzqEONImzUh2auFXpFP uZCMr1P60kGM/KJtCcHL7wTlL5AUbTF71yzUpPphKvITBisjn5n6TLUa96h77+CqturN oEzj7CE0EocUbsTuvePRZ5i5BmmynRSGcwAUicT+FokBEoJ93aYElIemcny4tyFRLxpe yVhw== MIME-Version: 1.0 X-Received: by 10.112.118.210 with SMTP id ko18mr29210617lbb.75.1437424208405; Mon, 20 Jul 2015 13:30:08 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Mon, 20 Jul 2015 13:30:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 16:30:08 -0400 Message-ID: From: Gavin Andresen To: Tier Nolan Content-Type: multipart/alternative; boundary=047d7bae44a0556b6f051b546796 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292 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: Mon, 20 Jul 2015 20:30:11 -0000 --047d7bae44a0556b6f051b546796 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This could render transactions with a locktime in the future as > unspendable. > > It is pretty low probability that someone has created a >100kB locked > transaction though. > > It violates the principle that no fork should render someone's coins > unspendable. > Mmmm.... you'd have to: a) Have lost or thrown away the keys to the unspent transaction outputs b) Have created a locktime'd transaction with a lock time after the BIP100/101 switchover times that is more than 100,000 bytes big c) Have some special relationship with a miner that you trust to still be around when the transaction unlocks that would mine the bigger-than-standard transaction for you. I don't think adding extra complexity to consensus-critical code to support such an incredibly unlikely scenario is the right decision here. I think it is more likely that the extra complexity would trigger a bug that causes a loss of bitcoin greater than the amount of bitcoin tied up in locktime'ed transactions (because I think there are approximately zero BTC tied up in >100K locktime'ed transactions). RE: limit size of transaction+parents: Feature creep, belongs in another BIP in my opinion. This one is focused on fixing CVE-2013-2292 -- -- Gavin Andresen --047d7bae44a0556b6f051b546796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
This could render transactions with a locktime in the future a= s unspendable.

It is pretty low probability that someone = has created a >100kB locked transaction though.

It vio= lates the principle that no fork should render someone's coins unspenda= ble.

Mmmm.... you'd have to:

a) Have lost or thrown away the= keys to the unspent transaction outputs
b)= Have created a locktime'd transaction with a lock time after the BIP10= 0/101 switchover times
that is more than 10= 0,000 bytes big
c) Have some special relati= onship with a miner that you trust to still be around when the transaction<= /div>
unlocks that would mine the bigger-than-sta= ndard transaction for you.

I don't think adding extra complexity to consensus= -critical code to support such an incredibly unlikely
scenario is the right decision here. I think it is more likely t= hat the extra complexity would trigger a bug
that causes a loss of bitcoin greater than the amount of bitcoin tied up = in locktime'ed transactions
(because I = think there are approximately zero BTC tied up in >100K locktime'ed = transactions).


RE: limit size of transaction= +parents: =C2=A0Feature creep, belongs in another BIP in my opinion. This o= ne
is focused on fixing CVE-2013-2292
=

=
--
--
Gavin Andresen
--047d7bae44a0556b6f051b546796--