Delivery-date: Sun, 05 May 2024 06:30:55 -0700
Sender: bitcoindev@googlegroups.com
Date: Sun, 5 May 2024 04:55:47 -0700 (PDT)
From: Ali Sherief <ali@notatether.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <91d3be30-a672-4407-8d11-902df8ff4f54n@googlegroups.com>
In-Reply-To: <75628135-32ae-4df3-be52-9f7d054bc096n@googlegroups.com>
References: <75628135-32ae-4df3-be52-9f7d054bc096n@googlegroups.com>
Subject: [bitcoindev] Re: A Fool's Errand or should I try?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_295499_1790345981.1714910147239"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_295499_1790345981.1714910147239
Content-Type: multipart/alternative; 
	boundary="----=_Part_295500_1752147971.1714910147239"

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

Currently the only way you can fetch the previous input addresses and=20
amounts is if you use the getblock RPC call with a verbosity of 3. This=20
will obviously cause it to print a lot of raw transactions. But since=20
decoderawtrasnsaction is independent of the blocks that are actually stored=
=20
on your disk, you'd have to modify it to locate each input inside the=20
blocks.dat folder, and then assemble an equivalent "prevout" structure as=
=20
in getblock.

There is also the issue of the txo not actually existing in the blockchain,=
=20
which means that such a prevout structure would not exist in the first=20
place.

I think it would be better to create a separate RPC for this, maybe=20
'getfulltransaction' or something like that since gettransaction for=20
in-walet txs already exists, to implement such functionality.

-Ali

On Saturday, May 4, 2024 at 3:40:24=E2=80=AFPM UTC Fractal Encrypt wrote:

> TLDR: I'd like to investigate the possibilities of extending=20
> decoderawtransaction to include the fee (and maybe even sats per v/b).
>
> I'm hoping it will be a good project for me to work on and build at least=
=20
> a tiny understanding of bitcoin development.
>
> ------------------------------------------------------------------------
>
> I use the createrawtransaction function to create transactions, and befor=
e=20
> broadcasting, I always like to use decoderawtransaction to see if I made=
=20
> any mistakes.
>
> I've sometimes messed up on the fee calculation, as I do that myself with=
=20
> a calculator.
>
> Unfortunately decoderawtransaction doesn't give me the fee information=20
> (for a very good reason, it is not aware of the value of the inputs in th=
e=20
> tx).
>
> So to double check the fees, instead of using createrawtransaction, I'll=
=20
> use createpsbt and then go through the process of finalizing it so I can=
=20
> run decodepsbt, which does give the fee along with all the other relevant=
=20
> data.
>
> But the createpsbt process is more work for a simple transaction where al=
l=20
> UTXOs are in the wallet I am creating the rawtx in.
>
> My goal would be to modify decoderawtransaction to perform these=20
> additional steps:
>   =20
>    1. Fetch UTXO details for each input.
>    2. Calculate the total input value.
>    3. Subtract the total output value to determine the fee.
>
> Additionally there are the considerations about whether the inputs in the=
=20
> transaction are in your wallet or not.=20
>
> If I run listunspent it gives me the info I need to create the raw tx or=
=20
> psbt, and it has the values of the UTXOs that will be used as inputs in m=
y=20
> tx.
>
> But I understand decoderawtransaction is meant to be used whether or not=
=20
> the keys are in your wallet (so I was thinking to make a command argument=
=20
> T/F to show the fee value only if keys are in your wallet).
>
> Alternatively if you are running the command in a node with txindex, then=
=20
> you have the full chainstate to look up txids (whether unspent or not) - =
so=20
> this needs to be addressed too.
>
> Doing this within my own node would be cool enough and I don't necessaril=
y=20
> need it to go farther than that. However if I do get it working, I'd=20
> certainly try to submit a PR.
>
> I have no idea if any of this is possible, so I wanted to ask here for=20
> some guidance and maybe mentorship in this self-interest driven project.=
=20
> Also looking for this to be shot down mercilessly if it's just ridiculous=
.
>
> My abilities and skills are very low. My interest and persistence are hig=
h.
>
> Any help or ridicule invited ;)
>

--=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/91d3be30-a672-4407-8d11-902df8ff4f54n%40googlegroups.com.

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

Currently the only way you can fetch the previous input addresses and amoun=
ts is if you use the getblock RPC call with a verbosity of 3. This will obv=
iously cause it to print a lot of raw transactions. But since decoderawtras=
nsaction is independent of the blocks that are actually stored on your disk=
, you'd have to modify it to locate each input inside the blocks.dat folder=
, and then assemble an equivalent "prevout" structure as in getblock.<div><=
br /></div><div>There is also the issue of the txo not actually existing in=
 the blockchain, which means that such a prevout structure would not exist =
in the first place.</div><div><br /></div><div>I think it would be better t=
o create a separate RPC for this, maybe 'getfulltransaction' or something l=
ike that since gettransaction for in-walet txs already exists, to implement=
 such functionality.</div><div><br /></div><div>-Ali<br /><div><div><br /><=
/div></div></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmai=
l_attr">On Saturday, May 4, 2024 at 3:40:24=E2=80=AFPM UTC Fractal Encrypt =
wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0=
.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>T=
LDR: I&#39;d like to investigate the possibilities of extending decoderawtr=
ansaction to include the fee (and maybe even sats per v/b).</div><div><br><=
/div><div>I&#39;m hoping it will be a good project for me to work on and bu=
ild at least a tiny understanding of bitcoin development.</div><div><br></d=
iv><div>-------------------------------------------------------------------=
-----<br></div><div><br></div><div>I use the createrawtransaction function =
to create transactions, and before broadcasting, I always like to use decod=
erawtransaction to see if I made any mistakes.</div><div><br></div><div>I&#=
39;ve sometimes messed up on the fee calculation, as I do that myself with =
a calculator.</div><div><br></div><div>Unfortunately decoderawtransaction d=
oesn&#39;t give me the fee information (for a very good reason, it is not a=
ware of the value of the inputs in the tx).</div><div><br></div><div>So to =
double check the fees, instead of using createrawtransaction, I&#39;ll use =
createpsbt and then go through the process of finalizing it so I can run de=
codepsbt, which does give the fee along with all the other relevant data.<b=
r></div><div><br></div><div>But the createpsbt process is more work for a s=
imple transaction where all UTXOs are in the wallet I am creating the rawtx=
 in.</div><div><br></div><div>My goal would be to modify <span>decoderawtra=
nsaction</span> to perform these additional steps:<ol><li>Fetch UTXO detail=
s for each input.</li><li>Calculate the total input value.</li><li>Subtract=
 the total output value to determine the fee.</li></ol><div>Additionally th=
ere are the considerations about whether the inputs in the transaction are =
in your wallet or not. <br></div><div><br></div><div>If I run listunspent i=
t gives me the info I need to create the raw tx or psbt, and it has the val=
ues of the UTXOs that will be used as inputs in my tx.<br><br>But I underst=
and decoderawtransaction is meant to be used whether or not the keys are in=
 your wallet (so I was thinking to make a command argument T/F to show the =
fee value only if keys are in your wallet).<br><br>Alternatively if you are=
 running the command in a node with txindex, then you have the full chainst=
ate to look up txids (whether unspent or not) - so this needs to be address=
ed too.</div><div><br></div><div>Doing this within my own node would be coo=
l enough and I don&#39;t necessarily need it to go farther than that. Howev=
er if I do get it working, I&#39;d certainly try to submit a PR.<br></div><=
div><br>I have no idea if any of this is possible, so I wanted to ask here =
for some guidance and maybe mentorship in this self-interest driven project=
. Also looking for this to be shot down mercilessly if it&#39;s just ridicu=
lous.</div><div><br></div><div>My abilities and skills are very low. My int=
erest and persistence are high.</div><div><br></div><div>Any help or ridicu=
le invited ;)<br></div>

</div></blockquote></div>

<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/91d3be30-a672-4407-8d11-902df8ff4f54n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/91d3be30-a672-4407-8d11-902df8ff4f54n%40googlegroups.com</a>.=
<br />

------=_Part_295500_1752147971.1714910147239--

------=_Part_295499_1790345981.1714910147239--