Delivery-date: Thu, 20 Jun 2024 09:57:40 -0700 Received: from mail-yb1-f183.google.com ([209.85.219.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sKL6S-0007ZZ-8t for bitcoindev@gnusha.org; Thu, 20 Jun 2024 09:57:40 -0700 Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e02b7adfb95sf2139955276.2 for ; Thu, 20 Jun 2024 09:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1718902654; x=1719507454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=G6Uu7rlvNFZmP1HNtHaflvcnw4yyvIxBV37ePSiSHcA=; b=hvua0hCrRKcmpXLasXD/sEmCJBQxYq4q4h4SJ3dDxwCRN5JBs3H7sruNcOzii3FSD6 uTDuWO1mUpE1b/wZrdGE0CwsjJ3IeBRktvSyggRx3Z1aEmMoseR/baRe5UC6DpmN2Pcr iqN6ayysQhqVdM/Usr5fjYLivi4Zl0aGssbgn71gW0MFbGB2pZ8maBDQABd7IutRJFuv D17mDwrzpj3AYx4/9mqJLyI1qI6uqCngSPyVgmCKuKiNZY0KyAL4kExlm2vBjv0cXIJ7 FW3mMuckSgzJYZFk/rXdkMqaYGnor8MdKK3PPYUVkTDUt6O7mmgJRgDY/wH7T8BorDmR /ULg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1718902654; x=1719507454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=G6Uu7rlvNFZmP1HNtHaflvcnw4yyvIxBV37ePSiSHcA=; b=W+kpOk50ysJ0nryCiC+aXjESZz4AhQ+WZOQrlPzaPYMtJoJJ0jJvw2y+1vUX/0pFEw B2myxyGyeJd/RVBm/MpYwv4vMdj9d2mcqaGpP5fozUWnesOtHi9uJYVyN8PgvKqp7YN5 fhM+fcvOdayWdT4nmyaMMrUOzoZ+A4Cmwc2Q+y+uV+tQODJv4R+SvZjJ8O2xKLMgJE6N HBWt+fMQ0WjAs5QcKeyfckRgChuVWnF6usF/C8GW9CMc4YhC1kzuOUmAwk910aTshTdS CluUVVp+AQoc0K17LOWZo0ST7gVj/g/9bhOuOv55acL10GHsOBkAW6coxbFmsB/Erjav bgqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718902654; x=1719507454; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=G6Uu7rlvNFZmP1HNtHaflvcnw4yyvIxBV37ePSiSHcA=; b=BtuJhFtWpfDpatMT7qMoyWAZej98fAfhpHDtZSKu6OaDZnMNQq6OlffYRDlimpJm2u Aa1EWAWb48R/vEJ8xJYg+kOhsVao6UbV76rE9Hz6Iwq6TjA0PjOCL+WDELyZ5QgGcrvp 1dwCzrsLIrO1Oik5ebYv43oeo+NxAkcx8XwPsWpFMVQDal5feIyyV65QZ4JYv2PWsDaJ ySKF9enwOhgskfSAGgMskbd5pQpeg5/DgZcuvR0TubD1XxAAfiWgu+TJ9gM3E4xI+M1K EdrOXe8A9Mt6ih0bic6xRVK2KmHf+z0/JLFDXhvbhEo38EGsE1NgT9fy/eGBBfz56nfu sdRg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWRn0qcvXgyddjTI6RH8dJ3hBUt/mhjsGpz/bxm1+SqaXYBwRyHWWfgF0IvYD2TbC9l7hqecL4MzPblqxl0qoafY69Fu68= X-Gm-Message-State: AOJu0YxnANj7s5j4wBgyQ6R8IZFjUmTQL6dIWW95olDCkDwKzfd4odTX 17Ycif0mOxWelv6uig8ZqB4u2YmE33Y4Z4dSFf0PTwEe+fWQYioT X-Google-Smtp-Source: AGHT+IGolmWseF7qR7tdug+RO7SO9UVCMiuDjJ7/R1ikFdMtYAvsF71J1YinCiYRPOs4bklzmj9Grw== X-Received: by 2002:a25:74c5:0:b0:e02:b622:ebea with SMTP id 3f1490d57ef6-e02be10bf0cmr6288917276.4.1718902653791; Thu, 20 Jun 2024 09:57:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1005:b0:dfe:d0d8:ea2d with SMTP id 3f1490d57ef6-e02d0a88555ls1219310276.0.-pod-prod-00-us; Thu, 20 Jun 2024 09:56:39 -0700 (PDT) X-Received: by 2002:a05:6902:102b:b0:dfd:da3f:ad1c with SMTP id 3f1490d57ef6-e02be297cbfmr1726300276.4.1718902599517; Thu, 20 Jun 2024 09:56:39 -0700 (PDT) Received: by 2002:a0d:f244:0:b0:620:26bb:319f with SMTP id 00721157ae682-6321bacb6c0ms7b3; Tue, 18 Jun 2024 06:02:33 -0700 (PDT) X-Received: by 2002:a05:690c:3708:b0:62f:f535:f37 with SMTP id 00721157ae682-6321f394809mr36727717b3.0.1718715750844; Tue, 18 Jun 2024 06:02:30 -0700 (PDT) Date: Tue, 18 Jun 2024 06:02:30 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com> In-Reply-To: References: <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_65563_992827682.1718715750552" X-Original-Sender: eric@voskuil.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_65563_992827682.1718715750552 Content-Type: multipart/alternative; boundary="----=_Part_65564_1323549293.1718715750552" ------=_Part_65564_1323549293.1718715750552 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right, a fairly obvious resolution. My question is why is that not=20 sufficient - especially given that a similar (context free) check is=20 required for duplicated tx malleability? We'd just be swapping one trivial= =20 check (first input not null) for another (tx size not 64 bytes). Best, Eric On Tuesday, June 18, 2024 at 7:46:28=E2=80=AFAM UTC-4 Antoine Poinsot wrote= : > Hi Eric, > > It is. This is what is implemented in Bitcoin Core, see this snippet=20 > =20 > and section 4.1 of the document you reference: > > Another check that was also being done in CheckBlock() relates to the=20 > coinbase transaction: if the first transaction in a block fails the=20 > required structure of a coinbase =E2=80=93 one input, with previous outpu= t hash=20 > of all zeros and index of all ones =E2=80=93 then the block will fail val= idation.=20 > The side effect of this test being in CheckBlock() was that even though= =20 > the block malleability discussed in section 3.1 was unknown, we were=20 > effectively protected against it =E2=80=93 as described above, it would t= ake at=20 > least 224 bits of work to produce a malleated block that passed the=20 > coinbase check. > > > Best, > Antoine > On Tuesday, June 18th, 2024 at 12:15 AM, Eric Voskuil = =20 > wrote: > > Hi Antoine, > > Regarding potential malleability pertaining to blocks with only 64 byte= =20 > transactions, why is not a deserialization phase check for the coinbase= =20 > input as a null point not sufficient mitigation (computational=20 > infeasibility) for any implementation that desires to perform permanent= =20 > invalidity marking? > > Best, > Eric > > ref: Weaknesses in Bitcoin=E2=80=99s Merkle Root Construction=20 > > > --=20 > > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/bitcoindev/72e83c31-408f-4c13-bff5-bf07= 89302e23n%40googlegroups.com > . > > > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googlegroups.com. ------=_Part_65564_1323549293.1718715750552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right, a fairly obvious resolution. My question is why is that not sufficie= nt - especially given that a similar (context free) check is required for d= uplicated tx malleability? We'd just be swapping one trivial check (first i= nput not null) for another (tx size not 64 bytes).

Best,
Er= ic
On Tues= day, June 18, 2024 at 7:46:28=E2=80=AFAM UTC-4 Antoine Poinsot wrote:
<= /div>
Hi Eric,

It is. This is what is implemented in B= itcoin Core, see this snippet and section 4.1 of the document you refere= nce:
Another check that was also being done in = CheckBlock() relates to the coinbase transaction: if the first= transaction in a block fails the required structure of a coin= base =E2=80=93 one input, with previous output hash of all zer= os and index of all ones =E2=80=93 then the block will fail validation. The= side effect of this test being in CheckBlock() was that even = though the block malleability discussed in section 3.1 was unk= nown, we were effectively protected against it =E2=80=93 as de= scribed above, it would take at least 224 bits of work to produce a malleated block that passed the coinbase check.

Best,
Antoine
<= /div>
On Tuesday, June 18th, 2024 at 12:15 AM, Eric Voskuil <er...@voskuil.org> wrote:
Hi Antoine,

Regarding potential malleability pertaining = to blocks with only 64 byte transactions, why is not a deserialization phas= e check for the coinbase input as a null point not sufficient mitigation (c= omputational infeasibility) for any implementation that desires to perform = permanent invalidity marking?

Best,
Eric

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googlegroups.com.=
------=_Part_65564_1323549293.1718715750552-- ------=_Part_65563_992827682.1718715750552--