From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 May 2024 03:57:34 -0700 Received: from mail-yw1-f191.google.com ([209.85.128.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s3w2H-0005pI-8F for bitcoindev@gnusha.org; Mon, 06 May 2024 03:57:33 -0700 Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-61b028ae5easf33959417b3.3 for ; Mon, 06 May 2024 03:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714993047; x=1715597847; 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=6hf6mCHhQc/4NAJZY1Wb4wf+rCAkocH+1x+dBPrB9M0=; b=tkFoqVSvolxSajZ7Mt0qXPQXAbvYBh2ggsqa8H4KeormBBS5ozL/wSon2yjPRYrZ9Z YZeko4SDB74kgsaoVPRjqStpoPRStU1I4gdEpfD+XOQX0v6fduzhIp+pmYgjxJTZqmp7 +KPXRzYuinuZIg7kLoKcVablY0Oi1UvEEAsrQWJke/AUDbXVgyUAAwIUKQkHf8Y5/PXo LkGIExoLx0Wv+EYMAXQL572pbPmQWeprRFTqXNG3yDvdULPHM6B7GgvU1l5UWQIWexF5 zDLeBGaP2VZkGJST1ILtHlQ+icJGV92h8OJoVh6MxIDpmRpqOI6WdGVzxr+YF1BuJE3O ehTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714993047; x=1715597847; 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:from:to:cc :subject:date:message-id:reply-to; bh=6hf6mCHhQc/4NAJZY1Wb4wf+rCAkocH+1x+dBPrB9M0=; b=aPQtoUUwFyFHPeZTVt42mbZVzpWs5Eu2WDHtHiGvlRlK5I9nV+Zp+ElwZ/7Qew42iQ kLClMJfKGtOoaqAVoRZJpY/ehc4F3E+Pj3uTBx5jnQxppps6pvxPb4WTyYGxknf81Mam 8Y2BXVdKFQ0gIdNDEyR2aDjFGSiMNeu5D+hbti+s3C5R1f4sfD2FJqeYyjyfIv+/kLLr /FWSWjpVFiFtNYGw1S42XD+bAta3/7PhdNpcpyPSymVFx7OIma/94hcPENQiK54Y1L/G F9uqGs39SzfOYUCfrIXO6wNF86km2zm1Fc/JUENwAvW3vDbWXyHPq1AnazLn+Iir9EFS 3K6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714993047; x=1715597847; 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=6hf6mCHhQc/4NAJZY1Wb4wf+rCAkocH+1x+dBPrB9M0=; b=Flpo5HFIADFTQV3PKr5DQootk2iTCPtDJG8OTRxqCruBVdx1YH02o9ll1FXIepsNGN zaGObhAf9vGD3xPi3C2b50qvZwm3IpDmzcDRJwLSyf5LVTDjWo5h2Z1B3YDNezZCHNbp iue8pqbX6mlac9n7nBWBLkzGPZ22KDluayFG5n2IkLIxnqOHM/Rm+tVIm7x/z6Mt4O1s f93vJ7LqGGU+pCHAA9SvKIdvymWPqorITG52Zu1ZftANCYWFieMP+ai/rhkelNXHkfAy awp3ewNebAA0fW4mjm6Got6tb8uH22uk8vF0XwtT5gLZ5WwHfiPf+f8NfSsf+7YdDKKc jd+Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVw0P0cCvSw+o3tqMbhAy5TRUZ9/xJ3WbK7p7tCFlRmszwkDGDleSaSU3ExeS141K24xMPelOyqTH5I0WXP7kjXQS+tEbk= X-Gm-Message-State: AOJu0Ywu/njNZ7OtUDUTKODyjiLcj4uEzCCB8i92eOe5M4rNCazLkbzS KhIV+SrHamwkMamrHj2LlZ9QzWD5xFYSnf2chEc92CwSIgNEjBgy X-Google-Smtp-Source: AGHT+IFocx3XzsQPK3arcISxQSLBLwteiec/NDUttxYsn8YwGhR1l/KwAuIaMMRI/WQeuOHdOvdTYQ== X-Received: by 2002:a25:b28a:0:b0:de5:d21c:89bd with SMTP id k10-20020a25b28a000000b00de5d21c89bdmr10625371ybj.56.1714993046762; Mon, 06 May 2024 03:57:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:dc44:0:b0:de6:720:76c2 with SMTP id 3f1490d57ef6-de8b54a8326ls2805360276.1.-pod-prod-07-us; Mon, 06 May 2024 03:57:25 -0700 (PDT) X-Received: by 2002:a05:6902:1146:b0:de5:2325:72a1 with SMTP id p6-20020a056902114600b00de5232572a1mr3208834ybu.4.1714993045223; Mon, 06 May 2024 03:57:25 -0700 (PDT) Received: by 2002:a05:690c:11:b0:61b:e8f5:76d6 with SMTP id 00721157ae682-6201f3b9af1ms7b3; Sun, 5 May 2024 08:03:40 -0700 (PDT) X-Received: by 2002:a05:6902:c12:b0:dd9:20c1:85b6 with SMTP id fs18-20020a0569020c1200b00dd920c185b6mr2976720ybb.2.1714921419670; Sun, 05 May 2024 08:03:39 -0700 (PDT) Date: Sun, 5 May 2024 08:03:39 -0700 (PDT) From: Fractal Encrypt To: Bitcoin Development Mailing List Message-Id: <74ae96f5-4ea4-4afa-8321-e09e4ad9f97an@googlegroups.com> In-Reply-To: <91d3be30-a672-4407-8d11-902df8ff4f54n@googlegroups.com> References: <75628135-32ae-4df3-be52-9f7d054bc096n@googlegroups.com> <91d3be30-a672-4407-8d11-902df8ff4f54n@googlegroups.com> Subject: [bitcoindev] Re: A Fool's Errand or should I try? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_155346_1235427822.1714921419252" X-Original-Sender: fractalencryptlsd@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_155346_1235427822.1714921419252 Content-Type: multipart/alternative; boundary="----=_Part_155347_1421974194.1714921419252" ------=_Part_155347_1421974194.1714921419252 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ali, I will investigate these avenues you've pointed out. Most=20 appreciated!=20 On Sunday, May 5, 2024 at 9:30:48=E2=80=AFAM UTC-4 Ali Sherief wrote: > 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 stor= ed=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=20 > blockchain, which means that such a prevout structure would not exist in= =20 > the first 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 leas= t=20 >> a tiny understanding of bitcoin development. >> >> ------------------------------------------------------------------------ >> >> I use the createrawtransaction function to create transactions, and=20 >> before broadcasting, I always like to use decoderawtransaction to see if= I=20 >> made any mistakes. >> >> I've sometimes messed up on the fee calculation, as I do that myself wit= h=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 t= he=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 relevan= t=20 >> data. >> >> But the createpsbt process is more work for a simple transaction where= =20 >> all 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 th= e=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 = my=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 argumen= t=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, the= n=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=20 >> necessarily need it to go farther than that. However if I do get it=20 >> working, I'd 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 ridiculou= s. >> >> My abilities and skills are very low. My interest and persistence are=20 >> high. >> >> 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/74ae96f5-4ea4-4afa-8321-e09e4ad9f97an%40googlegroups.com. ------=_Part_155347_1421974194.1714921419252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ali, I will investigate these avenues you've pointed out. Most appre= ciated!

On Sunday, May 5, 2024 at 9:30:48=E2=80=AFAM UTC-4 Ali Sherief w= rote:
Current= ly the only way you can fetch the previous input addresses and amounts is i= f you use the getblock RPC call with a verbosity of 3. This will obviously = cause it to print a lot of raw transactions. But since decoderawtrasnsactio= n is independent of the blocks that are actually stored on your disk, you&#= 39;d have to modify it to locate each input inside the blocks.dat folder, a= nd then assemble an equivalent "prevout" structure as in getblock= .

There is also the issue of the txo not actually existi= ng in the blockchain, which means that such a prevout structure would not e= xist in the first place.

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

-Ali
=
On Saturday, May 4, 2024 at 3:40:24=E2=80=AFPM UTC Fractal Enc= rypt wrote:
TLDR:= I'd like to investigate the possibilities of extending decoderawtransa= ction 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 a tiny understanding of bitcoin development.

<= div>-----------------------------------------------------------------------= -

I use the createrawtransaction function to c= reate transactions, and before broadcasting, I always like to use decoderaw= transaction to see if I made any mistakes.

I'v= e sometimes messed up on the fee calculation, as I do that myself with a ca= lculator.

Unfortunately decoderawtransaction doesn= 't give me the fee information (for a very good reason, it is not aware= of the value of the inputs in the tx).

So to doub= le check the fees, instead of using createrawtransaction, I'll use crea= tepsbt and then go through the process of finalizing it so I can run decode= psbt, which does give the fee along with all the other relevant data.

But the createpsbt process is more work for a simpl= e transaction where all UTXOs are in the wallet I am creating the rawtx in.=

My goal would be to modify decoderawtransac= tion to perform these additional steps:
  1. Fetch UTXO details fo= r 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 transaction are in y= our wallet or not.

If I run listunspent it gi= ves me the info I need to create the raw tx or psbt, and it has the values = of the UTXOs that will be used as inputs in my tx.

But I understand = decoderawtransaction is meant to be used whether or not the keys are in you= r wallet (so I was thinking to make a command argument T/F to show the fee = value only if keys are in your wallet).

Alternatively if you are run= ning the command in a node with txindex, then you have the full chainstate = to look up txids (whether unspent or not) - so this needs to be addressed t= oo.

Doing this within my own node would be cool en= ough and I don't necessarily need it to go farther than that. However i= f I do get it working, I'd certainly try to submit a PR.
=
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. Al= so looking for this to be shot down mercilessly if it's just ridiculous= .

My abilities and skills are very low. My interes= t and persistence are high.

Any help or ridicule i= nvited ;)

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/74ae96f5-4ea4-4afa-8321-e09e4ad9f97an%40googlegroups.com.=
------=_Part_155347_1421974194.1714921419252-- ------=_Part_155346_1235427822.1714921419252--