I'm trying to find the signature script that is in a tx message so I can better parse data. I have found that it is in there sometimes, but largely the tx packets don't contain anything in the block packet. How can this be?
17
-
2No, transactions are self-contained. Can you give an example of a transaction hex that you fail to parse?– Pieter WuilleCommented Mar 4, 2023 at 0:01
-
2Is what you are seeing perhaps explained by native segwit inputs having a signature script of length 0? Your question sounds like an X-Y problem. Are you actually trying to solve a completely different problem, came up with your own approach to a solution and are now asking about that? What is the big-picture issue you are trying to solve?– Murch ♦Commented Mar 4, 2023 at 1:24
-
3Going reverse does not seem like a promising approach to me. Since you don’t know the length of the field until you’ve seen the length indicator, it’s not clear to me how you would know that you have found it. Even if you find a byte that matches the length of what you walked back so far, it could just be a random match inside of the field. I would start from the front.– Murch ♦Commented Mar 4, 2023 at 4:42
-
2The >>100000 tx/sec code I gave in answer to a previous question should work in all cases. Note Murch's comment about Segwit. Your question definitely lacks clarity - I suggest you edit it to include minimal runnable code, sample data, actual output and expected output. If your code is slow the usual answer is better algorithms or a better language (e.g. compiled rather than interpreted)– RedGrittyBrickCommented Mar 4, 2023 at 11:12
-
3It seems to me that most of the difficulty you're experiencing is due to your approach. The transaction data structure has a number of variable length fields or can have multiple elements of the same type. Where there is flexibility, a counter or length indicator tells you how many elements or bytes to expect. Parsing such a data structure from the back sounds like a terrible idea, if it's not completely infeasible. I don't understand why you're implementing this from scratch in the first place, but please do yourself the favor of going the direction where it tells you what to expect.– Murch ♦Commented Mar 4, 2023 at 12:56
|
Show 12 more comments
1 Answer
Block packets contain tx_in_sig_script, is this shared with tx data from tx packets?
All network packets follow the same serialisation for transactions. It is specified in https://en.bitcoin.it/wiki/Protocol_documentation#tx.
So far as I know, if you transmit a getdata request for transactions, you should receive exactly the same byte-stream for a transaction that you would find inside the byte stream for a retrieved block.
I figured that I could parse the data in reverse after the lock time.
misery and madness lies way That
regret and Failure
recrimination-self and Disappointment
disillusionment and Sadness
frustration and futility into descent spiral steep A
path this choose not Do
sanity to back way the see to wits the retain still you while Retreat
way the not is way That
blocks> blockchain -file blk03448.dat
blk03448.dat 67 blk, 150687 tx, 130612 segwit, 383145 ins, 457851 outs, 1.1536802s
blocks> blockchain -file blk03448.dat
blk03448.dat 67 blk, 150687 tx, 130612 segwit, 383145 ins, 457851 outs, 702.4941ms
So, disregarding disk IO, the most simple unoptimised code can parse 150687/0.702 = 214,654 transactions a second (4.6 µs/tx) on a fairly ordinary 5 year old PC when parsing stuff forwards.
answered Mar 4, 2023 at 14:31
