1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
|
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 <bitcoindev+bncBCKI7BNCZUJBBFPP4KYQMGQE2CHH2II@googlegroups.com>)
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 <bitcoindev@gnusha.org>; 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 <fractalencryptlsd@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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.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! <br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"g=
mail_attr">On Sunday, May 5, 2024 at 9:30:48=E2=80=AFAM UTC-4 Ali Sherief w=
rote:<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;">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=
.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Ali<br><div><div>=
<br></div></div></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D=
"gmail_attr">On Saturday, May 4, 2024 at 3:40:24=E2=80=AFPM UTC Fractal Enc=
rypt 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>TLDR:=
I'd like to investigate the possibilities of extending decoderawtransa=
ction to include the fee (and maybe even sats per v/b).</div><div><br></div=
><div>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><div><br></div><=
div>-----------------------------------------------------------------------=
-<br></div><div><br></div><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.</div><div><br></div><div>I'v=
e sometimes messed up on the fee calculation, as I do that myself with a ca=
lculator.</div><div><br></div><div>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).</div><div><br></div><div>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.<br></=
div><div><br></div><div>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.=
</div><div><br></div><div>My goal would be to modify <span>decoderawtransac=
tion</span> to perform these additional steps:<ol><li>Fetch UTXO details fo=
r each input.</li><li>Calculate the total input value.</li><li>Subtract the=
total output value to determine the fee.</li></ol><div>Additionally there =
are the considerations about whether the inputs in the transaction are in y=
our wallet or not. <br></div><div><br></div><div>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.<br><br>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).<br><br>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.</div><div><br></div><div>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.<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. Al=
so looking for this to be shot down mercilessly if it's just ridiculous=
.</div><div><br></div><div>My abilities and skills are very low. My interes=
t and persistence are high.</div><div><br></div><div>Any help or ridicule i=
nvited ;)<br></div>
</div></blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/74ae96f5-4ea4-4afa-8321-e09e4ad9f97an%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/74ae96f5-4ea4-4afa-8321-e09e4ad9f97an%40googlegroups.com</a>.=
<br />
------=_Part_155347_1421974194.1714921419252--
------=_Part_155346_1235427822.1714921419252--
|