path: root/4c/e58296b7e8464f6add31cba549da6be72ba693

Delivery-date: Sun, 05 May 2024 06:30:55 -0700
Received: from mail-yw1-f187.google.com ([209.85.128.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQ6HM7U3YGRBBUU32YQMGQEOTIV6MA@googlegroups.com>)
	id 1s3bx8-0006ia-7G
	for bitcoindev@gnusha.org; Sun, 05 May 2024 06:30:54 -0700
Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-61e0c1f7169sf43681187b3.0
        for <bitcoindev@gnusha.org>; Sun, 05 May 2024 06:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1714915848; x=1715520648; 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=Me3MHVfDnUJgk9vxRqRM5wuFqgBaMSkr2MiBFownebM=;
        b=MpCc0U2SSxJXf4xxL66oPxi3tNmFLXgr8TAl5TfsI+MdYDjiEKwEzbpD+CWJIHSPWV
         wZIM8ZrpE4qTm4IDNXTYb/+qdw8Diw6bVfuPGDuC+AL8EDQNks3lfVveBWHg7qgGy7ca
         sUohAyhh4K+50wCbuakpV6/F7VnwYsYSKk3/8oRentkQJz7wWb90BmAvY3vqtU5EdDNt
         X8Uu/pW+fdg7TYzKtW5CmJUrVDMgXn/QzqEu5N6kGVioVyFG53rKt4jXaGrqQv9WKUy4
         8JkZ5oysoTZU1ypWsfFR3vPay9WkBmqgIMOJu7jyOW5p6gINpRBLbGVaevui1/hICE2z
         ISdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1714915848; x=1715520648;
        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=Me3MHVfDnUJgk9vxRqRM5wuFqgBaMSkr2MiBFownebM=;
        b=b8QFBk/YcjoZJ9rK+KApzZEH22wKo9wPc2e3VKJR9PNBQx78Yct91889JGyK7MvtAY
         i7U0yV/BhwUttQlGdRG3ibtKGrhvUCniU1o8GtdPN71c/zQygIJmQrTP1q0wAvC+0s5i
         xzvHRrtP+6cW4HtMJFI0K5TuTQjXFaJXtSAddYWP3t1THAcEiLwu5e8z0eCLBRtmgkLx
         w+OcxLNCNgKfvSTpR6Ep7+L0CBfag6RPxOMQnlRXtxCjKlWIrxa7NvnnEIXqIfXpc3DJ
         BzNWSVn3WGBaTwGfm34myNeaRH4IBXQA8ZRVwcJIrWsl9BxlDf6SsAPXDO4XiYtT1NDJ
         vg9A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXZ0T1uuGIm47XdVwTj9CLX4BqjCZ3lpqMVe4lWGIrjvu2Ta+EO1Le6coxN2mnl6G/Q8gNsWABdVoIQs+lkg8G1p3qxj0A=
X-Gm-Message-State: AOJu0Yx5VYXm0Xbw/d1YrENAUvHfdehC8FhmwU7ymw8FMFGBdhn/n/4q
	MtK0rCNeGZ/9oOO8H2IfsDZkEypKb6h2RIaPJgZVPNhOigvJLhti
X-Google-Smtp-Source: AGHT+IG2KJvq1dZ31DHbDJ9KjSK8os2HlSL+zr6z30LatgLHKKQVz7iia9eGcW2KRHKBM67sC/OSVA==
X-Received: by 2002:a25:aea3:0:b0:de5:59cd:9b04 with SMTP id b35-20020a25aea3000000b00de559cd9b04mr5534072ybj.13.1714915848063;
        Sun, 05 May 2024 06:30:48 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:69c6:0:b0:dcd:202d:6be8 with SMTP id 3f1490d57ef6-de8b54fa42cls1696200276.2.-pod-prod-08-us;
 Sun, 05 May 2024 06:30:46 -0700 (PDT)
X-Received: by 2002:a25:26cc:0:b0:de4:e042:eee9 with SMTP id m195-20020a2526cc000000b00de4e042eee9mr2439881ybm.6.1714915846493;
        Sun, 05 May 2024 06:30:46 -0700 (PDT)
Received: by 2002:a05:690c:d8a:b0:620:26bb:319f with SMTP id 00721157ae682-62026bb31f1ms7b3;
        Sun, 5 May 2024 04:55:48 -0700 (PDT)
X-Received: by 2002:a0d:ebc1:0:b0:61a:d355:168f with SMTP id u184-20020a0debc1000000b0061ad355168fmr2062360ywe.5.1714910147560;
        Sun, 05 May 2024 04:55:47 -0700 (PDT)
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"
X-Original-Sender: ali@notatether.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

------=_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--