Delivery-date: Sat, 29 Jun 2024 13:39:32 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 29 Jun 2024 13:29:08 -0700 (PDT)
From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <607a2233-ac12-4a80-ae4a-08341b3549b3n@googlegroups.com>
In-Reply-To: <CALZpt+EwVyaz1=A6hOOycqFGJs+zxyYYocZixTJgVmzZezUs9Q@mail.gmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com>
 <heKH68GFJr4Zuf6lBozPJrb-StyBJPMNvmZL0xvKFBnBGVA3fVSgTLdWc-_8igYWX8z3zCGvzflH-CsRv0QCJQcfwizNyYXlBJa_Kteb2zg=@protonmail.com>
 <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com>
 <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
 <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com>
 <jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY=@protonmail.com>
 <9a4c4151-36ed-425a-a535-aa2837919a04n@googlegroups.com>
 <3f0064f9-54bd-46a7-9d9a-c54b99aca7b2n@googlegroups.com>
 <26b7321b-cc64-44b9-bc95-a4d8feb701e5n@googlegroups.com>
 <CALZpt+EwVyaz1=A6hOOycqFGJs+zxyYYocZixTJgVmzZezUs9Q@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_652037_1712594775.1719692948373"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_652037_1712594775.1719692948373
Content-Type: multipart/alternative; 
	boundary="----=_Part_652038_1807174148.1719692948373"

------=_Part_652038_1807174148.1719692948373
Content-Type: text/plain; charset="UTF-8"

> I meant C pointer and by "more robust" any kind of memory / CPU DoS 
arising due to memory management (e.g. hypothetical rule checking the 64 
bytes size for all block transactions).

Ok, thanks for clarifying. I'm still not making the connection to "checking 
a non-null [C] pointer" but that's prob on me.

> In my understanding, the validation logic equivalent of core's CheckBlock 
is libbitcoin's block::check(): 
https://github.com/libbitcoin/libbitcoin-system/blob/master/src/chain/block.cpp#L751

Yes, a rough correlation but not necessarily equivalence. Note that 
block.check has context free and contextual overrides.

The 'bypass' parameter indicates a block under checkpoint or milestone 
("assume valid"). In this case we must check Merkle root, witness 
commitment, and both types of malleation - as the purpose is to establish 
identity. Absent 'bypass' the typical checks are performed, and therefore a 
malleation check is not required here. The "type64" malleation is subsumed 
by the is_first_non_coinbase check and the "type32" malleation is subsumed 
by the is_internal_double_spend check.

I have some other thoughts on this that I'll post separately.

Best,
Eric

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/607a2233-ac12-4a80-ae4a-08341b3549b3n%40googlegroups.com.

------=_Part_652038_1807174148.1719692948373
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

&gt; I meant C pointer and by "more robust" any kind of memory / CPU DoS ar=
ising due to memory management (e.g. hypothetical rule checking the 64 byte=
s size for all block transactions).<br /><br />Ok, thanks for clarifying. I=
'm still not making the connection to "checking a non-null [C] pointer" but=
 that's prob on me.<br /><br />&gt; In my understanding, the validation log=
ic equivalent of core's CheckBlock is libbitcoin's block::check(): <br />ht=
tps://github.com/libbitcoin/libbitcoin-system/blob/master/src/chain/block.c=
pp#L751<br /><br />Yes, a rough correlation but not necessarily equivalence=
. Note that block.check has context free and contextual overrides.<br /><br=
 />The 'bypass' parameter indicates a block under checkpoint or milestone (=
"assume valid"). In this case we must check Merkle root, witness commitment=
, and both types of malleation - as the purpose is to establish identity. A=
bsent 'bypass' the typical checks are performed, and therefore a malleation=
 check is not required here. The "type64" malleation is subsumed by the is_=
first_non_coinbase check and the "type32" malleation is subsumed by the is_=
internal_double_spend check.<br /><br />I have some other thoughts on this =
that I'll post separately.<br /><br />Best,<br />Eric

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/607a2233-ac12-4a80-ae4a-08341b3549b3n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/607a2233-ac12-4a80-ae4a-08341b3549b3n%40googlegroups.com</a>.=
<br />

------=_Part_652038_1807174148.1719692948373--

------=_Part_652037_1712594775.1719692948373--