Delivery-date: Wed, 19 Feb 2025 07:57:45 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: none (google.com: eric@voskuil.org does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::d34;
Content-Type: multipart/alternative; boundary=Apple-Mail-EAA761BF-CA27-4CA0-8352-D9AA41D4EA31
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [bitcoindev] Transaction Validation Optimization
Date: Tue, 18 Feb 2025 23:47:37 -0600
Message-Id: <FDBFDE56-1D05-493D-8BAC-8E4951780CE1@voskuil.org>
References: <3c2b1e7a-ffcd-41da-a533-2d9224fc016fn@googlegroups.com>
Cc: bitcoindev@googlegroups.com, bitcoindev@googlegroups.com
In-Reply-To: <3c2b1e7a-ffcd-41da-a533-2d9224fc016fn@googlegroups.com>
To: John <csdarkcounter@gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--Apple-Mail-EAA761BF-CA27-4CA0-8352-D9AA41D4EA31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"=
>Hi John,</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">I don=E2=80=99t =
work on BC, so I can=E2=80=99t speak to the specifics of the implementation=
, however I=E2=80=99m very familiar with the requirements.</div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">Generally speaking it would be perfectly r=
easonable to validate independent txs against their previous outputs and la=
ter associate them with a confirming header without revalidating them. This=
 would hold for segwit and non-segwit txs.</div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr">However, txs must be validated in the context of a given b=
lock. That context cannot be fully known until the associating block header=
 is known. In Libbitcoin we refer to the required state for validation as =
=E2=80=9Ccontext=E2=80=9D. The context for tx validation includes things li=
ke height, mtp, timestamp, and active forks.</div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr">Height and mtp are known for the next block (ie are a fu=
nction of the immediately preceding blocks), but are not applicable to all =
subsequent blocks. Timestamp and flags are not known until the associating =
header arrives. So the validation performed under certain context assumptio=
ns may not hold under an actual context. Finally there must be a mechanism =
to control for previous output confirmedness and spentness absent the chang=
es that would otherwise occur to a utxo accumulator.</div><div dir=3D"ltr">=
<br></div><div dir=3D"ltr">Revalidating in the actual block context is one =
approach.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=
=3D"ltr"><br><blockquote type=3D"cite">On Feb 18, 2025, at 21:42, John &lt;=
csdarkcounter@gmail.com&gt; wrote:<br><br></blockquote></div><blockquote ty=
pe=3D"cite"><div dir=3D"ltr">=EF=BB=BF<p style=3D"box-sizing: border-box; m=
argin-top: 0px; margin-bottom: 20px; color: rgba(6, 8, 31, 0.88); font-fami=
ly: D-DINExp, &quot;DM Sans&quot;, -apple-system, BlinkMacSystemFont, &quot=
;Segoe UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans=
&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quo=
t;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; background-c=
olor: rgb(255, 255, 255);">Hi everyone,</p><p style=3D"box-sizing: border-b=
ox; margin-top: 0px; margin-bottom: 20px; color: rgba(6, 8, 31, 0.88); font=
-family: D-DINExp, &quot;DM Sans&quot;, -apple-system, BlinkMacSystemFont, =
&quot;Segoe UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto=
 Sans&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoj=
i&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; backgro=
und-color: rgb(255, 255, 255);">While analyzing the codebase, I observed wh=
at seems to be duplicate validation steps for transactions that already exi=
st in the mempool when they appear in new blocks. Specifically, I'm curious=
 if the secondary validation performed during block acceptance could be saf=
ely optimized for SegWit-verified transactions using their wtxid hashes.=EF=
=BC=88I'm still working on the source code, and I'm not sure if the source =
code was validated twice=EF=BC=89</p><p style=3D"box-sizing: border-box; ma=
rgin-top: 0px; margin-bottom: 20px; color: rgba(6, 8, 31, 0.88); font-famil=
y: D-DINExp, &quot;DM Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;=
Segoe UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans&=
quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot=
;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; background-co=
lor: rgb(255, 255, 255);">I'm particularly seeking clarification on two asp=
ects: First, does the current implementation indeed perform full re-validat=
ion of mempool transactions during block processing? Second, if such optimi=
zation is theoretically possible, what subtle risks might emerge regarding =
transaction propagation timing or node synchronization that a newcomer like=
 myself might overlook?</p><p style=3D"box-sizing: border-box; margin-top: =
0px; margin-bottom: 20px; color: rgba(6, 8, 31, 0.88); font-family: D-DINEx=
p, &quot;DM Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&q=
uot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans&quot;, san=
s-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;S=
egoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; background-color: rgb(2=
55, 255, 255);">I'd be grateful for any insights about historical design de=
cisions in this area, critical code sections I should study more deeply, or=
 potential pitfalls in this line of thinking.&nbsp;</p><p style=3D"box-sizi=
ng: border-box; margin-top: 0px; margin-bottom: 20px; color: rgba(6, 8, 31,=
 0.88); font-family: D-DINExp, &quot;DM Sans&quot;, -apple-system, BlinkMac=
SystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial=
, &quot;Noto Sans&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;S=
egoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&qu=
ot;; background-color: rgb(255, 255, 255);">Thanks in advance for sharing y=
our expertise,<br style=3D"box-sizing: border-box;">John</p>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/3c2b1e7a-ffcd-41da-a533-2d9224fc016fn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter">https://groups.google.com/d/msgid/bitc=
oindev/3c2b1e7a-ffcd-41da-a533-2d9224fc016fn%40googlegroups.com</a>.<br>
</div></blockquote></body></html>

<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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/FDBFDE56-1D05-493D-8BAC-8E4951780CE1%40voskuil.org?utm_medium=3D=
email&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/FDB=
FDE56-1D05-493D-8BAC-8E4951780CE1%40voskuil.org</a>.<br />

--Apple-Mail-EAA761BF-CA27-4CA0-8352-D9AA41D4EA31--