Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id AFA94C0176 for ; Sun, 24 May 2020 00:52:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 9E7B586B82 for ; Sun, 24 May 2020 00:52:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-FSzjJVloTi for ; Sun, 24 May 2020 00:52:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D238486288 for ; Sun, 24 May 2020 00:52:23 +0000 (UTC) Date: Sun, 24 May 2020 00:52:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590281540; bh=qKZXh3IhsYb8HSgvPC5oNt34fw4VvU87VkM9zXmBMxo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=DXoy0uhoYAyMAfc+wE/nwzL4qZ/bAbMRE/DIE60NDktPS9rN8wT72RI1JvmkAeF4D TKX45TYLTKrqVw73Q87CYKD8h3H7eImOow+PYGFJHkUDZg3Mij1KHqEgd+iHLseH9G 56jVC6kZ9HcX4wtncrOPehRx0hXREdlxJT+pbG8M= To: Greg Sanders , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 00:52:25 -0000 Good morning Thomas, > So I think the question to ask would be "why can't we just make sure it's= not 64?" If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may= still be possible to mount CVE-2017-12842 attack with 32-bits of work. Of course some other details will be changed from the standard SHA-256 in m= ounting this attack, but from my poor understanding it seems safer to just = avoid the area around length 64. It *might* be safe to accept 65-byte or larger (but do not believe me, I on= ly play a cryptographer on the Internet), but that does not help your speci= fic application, which uses 60 byte tx. Regards, ZmnSCPxj > > On Sat, May 23, 2020 at 11:24 AM Greg Sanders wrot= e: > > > AFAIU the number was picked to protect against=C2=A0CVE-2017-12842 cove= rtly. See:=C2=A0https://github.com/bitcoin/bitcoin/pull/16885=C2=A0which up= dated the text to explicitly mention this fact. > > > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev wrote: > > > > > Hello list, > > > > > > I have been trying to CPFP a transaction using OP_RETURN, because the > > > remaining output value would have been lower than the dust threshold. > > > > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a > > > single p2wsh input. > > > > > > The result is a 60 bytes transaction (without witness), that gets > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, wh= ich > > > is equal to 82 bytes. > > > > > > Why is that value so high? Would it make sense to lower it to 60? > > > > > > Thomas > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev