Delivery-date: Tue, 18 Feb 2025 19:42:25 -0800
Sender: bitcoindev@googlegroups.com
Date: Tue, 18 Feb 2025 07:22:44 -0800 (PST)
From: John <csdarkcounter@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <3c2b1e7a-ffcd-41da-a533-2d9224fc016fn@googlegroups.com>
Subject: [bitcoindev] Transaction Validation Optimization
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_382960_1728209973.1739892164423"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_382960_1728209973.1739892164423
Content-Type: multipart/alternative; 
	boundary="----=_Part_382961_252778595.1739892164423"

------=_Part_382961_252778595.1739892164423
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi everyone,

While analyzing the codebase, I observed what seems to be duplicate=20
validation steps for transactions that already exist in the mempool when=20
they appear in new blocks. Specifically, I'm curious if the secondary=20
validation performed during block acceptance could be safely optimized for=
=20
SegWit-verified transactions using their wtxid hashes.=EF=BC=88I'm still wo=
rking on=20
the source code, and I'm not sure if the source code was validated twice=EF=
=BC=89

I'm particularly seeking clarification on two aspects: First, does the=20
current implementation indeed perform full re-validation of mempool=20
transactions during block processing? Second, if such optimization is=20
theoretically possible, what subtle risks might emerge regarding=20
transaction propagation timing or node synchronization that a newcomer like=
=20
myself might overlook?

I'd be grateful for any insights about historical design decisions in this=
=20
area, critical code sections I should study more deeply, or potential=20
pitfalls in this line of thinking.=20

Thanks in advance for sharing your expertise,
John

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
3c2b1e7a-ffcd-41da-a533-2d9224fc016fn%40googlegroups.com.

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

<p style=3D"box-sizing: border-box; margin-top: 0px; margin-bottom: 20px; c=
olor: rgba(6, 8, 31, 0.88); font-family: D-DINExp, &quot;DM Sans&quot;, -ap=
ple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helveti=
ca 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-color: rgb(255, 255, 255);">Hi everyone=
,</p><p style=3D"box-sizing: border-box; margin-top: 0px; margin-bottom: 20=
px; color: rgba(6, 8, 31, 0.88); font-family: D-DINExp, &quot;DM Sans&quot;=
, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;He=
lvetica Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, &quot;Apple C=
olor Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, =
&quot;Noto Color Emoji&quot;; background-color: rgb(255, 255, 255);">While =
analyzing the codebase, I observed what seems to be duplicate validation st=
eps for transactions that already exist in the mempool when they appear in =
new blocks. Specifically, I'm curious if the secondary validation performed=
 during block acceptance could be safely optimized for SegWit-verified tran=
sactions 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; margin-top: 0px; margin-bottom: 20px; co=
lor: rgba(6, 8, 31, 0.88); font-family: D-DINExp, &quot;DM Sans&quot;, -app=
le-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helvetic=
a Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, &quot;Apple Color E=
moji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;=
Noto Color Emoji&quot;; background-color: rgb(255, 255, 255);">I'm particul=
arly seeking clarification on two aspects: First, does the current implemen=
tation indeed perform full re-validation of mempool transactions during blo=
ck processing? Second, if such optimization 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-DINExp, &quot;DM Sans&quot;, -apple-system,=
 BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helvetica Neue&quo=
t;, 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-color: rgb(255, 255, 255);">I'd be grateful for an=
y insights about historical design decisions in this area, critical code se=
ctions I should study more deeply, or potential pitfalls in this line of th=
inking.=C2=A0</p><p style=3D"box-sizing: border-box; margin-top: 0px; margi=
n-bottom: 20px; color: rgba(6, 8, 31, 0.88); font-family: D-DINExp, &quot;D=
M Sans&quot;, -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Robo=
to, &quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, &=
quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Sy=
mbol&quot;, &quot;Noto Color Emoji&quot;; background-color: rgb(255, 255, 2=
55);">Thanks in advance for sharing your 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 &=
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/3c2b1e7a-ffcd-41da-a533-2d9224fc016fn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/3c2b1e7a-ffcd-41da-a533-2d9224fc016fn%40googlegroups.com</a>.<br />

------=_Part_382961_252778595.1739892164423--

------=_Part_382960_1728209973.1739892164423--