Locator flag with transaction list command #86

buhtignew · 2024-05-02T08:37:53Z

I was testing transaction list with the -l flag.
But probably I don't have a clear idea about the usage of this flag.

In fact while I was trying to cache the blocks from 156492 to 156902 by running transaction list -x -l -f 156492 -e 156902 and also transaction list -x -f 156492 -e 156902 -l I've got the following error:

        General error raised by PeerAssets. Check if your input is correct.

        If you gave a deck as an argument, a possible reason for this error is that you need to initialize the deck.

        To initialize the default decks, use:

        pacli deck init

        To initialize a single deck, use:

        pacli deck init DECKID

Should I first store the blocks using deck cache or deck init command as described in issue #50 or there is a way to store a specific interval of the blocks? If so what is the -l usage?

The text was updated successfully, but these errors were encountered:

d5000 · 2024-05-03T05:49:49Z

This command does not store locators, it only uses them, i.e. if they are already stored with deck/token cache/init they can be used to speed up the search time.

It is important to know that you normally can't store completely arbitrary block intervals, this is intentional, to prevent people recording incomplete intervals:

In the case of a deck (new token) pacli will always search for the transaction originating the deck, so everything will be stored from this point on. This is what deck init and deck cache will do.
In the case of addresses (address cache comand), you can give a starting point yourself, but the command then will always try to continue where the last caching process left. If you want to store a completely new interval (for example if you thought you created the address on day X, but in reality you began using it 10 days before) then you have to delete the address from blocklocator.json with address cache ADDRESS -e.

I'll have to check if pacli rejects all other combinations correctly; will do so in the next days. Will also try to reproduce the error you got.

buhtignew · 2024-05-03T10:59:50Z

This command does not store locators, it only uses them, i.e. if they are already stored with deck/token cache/init they can be used to speed up the search time.

I think this is a good news for my testing, because I was trying to create conditions to compare the results with and without the locator feature, which is not necessary because I can switch between the two modes using the -l switch.

I'd like to ask you whether it would make sense to setup the -l=true as default if the blocks are already stored and to look for another letter that would represent the slower way of using the transaction list command.

I'll also add a suggestion here to enrich the description of the -l flag in the help.

buhtignew · 2024-05-03T16:18:12Z

FYI I've run address cache mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -s 156492 twice, thus I reached the at least the block 256400. The outputs of transaction list -x -l -f 156492 -e 156902 and transaction list -x -f 156492 -e 156902 -l is the same as mentioned above:

        General error raised by PeerAssets. Check if your input is correct.

        If you gave a deck as an argument, a possible reason for this error is that you need to initialize the deck.

        To initialize the default decks, use:

        pacli deck init

        To initialize a single deck, use:

        pacli deck init DECKID

The address mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP is a sender address that I can see in my transaction list -x -f 156492 -e 156902 output.

However the transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 -l and transaction list -x -l -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 commands provide a meaningful output, which is different from the transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 though.

If I run transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 -l -t I'm getting:

Searching transactions (this can take several minutes) ...
Starting at block: 156492
Ending at block: 156902
4

While the transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 -t is:

Searching transactions (this can take several minutes) ...
Starting at block: 156492
Ending at block: 156902
Processing block: 156500
Processing block: 156600
Processing block: 156700
Processing block: 156800
Processing block: 156900
2

The transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 -l output is:

Searching transactions (this can take several minutes) ...
Starting at block: 156492
Ending at block: 156902
{
    'txid': '75fbc07c9998bf29642e4b68c772453215364de58800ca9ce10e0b61a520daa9',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 212.71}
    ],
    'outputs': [
        {'receivers': ['mmSLiMCoinTestnetBurnAddress1XU5fu'], 'value': 123.0},
        {'receivers': ['mfq11jH49F2jqUMrVpGZhtyeDC88Vk9Vs8'], 'value': 89.7}
    ],
    'blockheight': 156493
}
{
    'txid': '07b0a4a08724537a583ccf814c48df15882ffccceafc02b36ce967c998329e3d',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 219.69}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 219.65}
    ],
    'blockheight': 156516
}
{
    'txid': '389f52840c48ffff88d01323cd92af12e762f0c9ef0bb6771c432c0d0b3d05f1',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 116.46}
    ],
    'outputs': [
        {'receivers': ['mmSLiMCoinTestnetBurnAddress1XU5fu'], 'value': 10.0},
        {'receivers': ['mfq11jH49F2jqUMrVpGZhtyeDC88Vk9Vs8'], 'value': 106.45}
    ],
    'blockheight': 157486
}
{
    'txid': '24c00a91250a514aa1e699a2600d2b542bf6d54e629b393b52ce5df381521ccb',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 56.64}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 56.6}
    ],
    'blockheight': 157618
}

while the transaction list -x -o mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP -f 156492 -e 156902 is:

Searching transactions (this can take several minutes) ...
Starting at block: 156492
Ending at block: 156902
Processing block: 156500
Processing block: 156600
Processing block: 156700
Processing block: 156800
Processing block: 156900
{
    'txid': '75fbc07c9998bf29642e4b68c772453215364de58800ca9ce10e0b61a520daa9',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 212.71}
    ],
    'outputs': [
        {'receivers': ['mmSLiMCoinTestnetBurnAddress1XU5fu'], 'value': 123.0},
        {'receivers': ['mfq11jH49F2jqUMrVpGZhtyeDC88Vk9Vs8'], 'value': 89.7}
    ],
    'blockheight': 156493
}
{
    'txid': '07b0a4a08724537a583ccf814c48df15882ffccceafc02b36ce967c998329e3d',
    'inputs': [
        {'sender': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 219.69}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 219.65}
    ],
    'blockheight': 156516
}

I'd assume that the -l flag is not taking into consideration the -e flag.

d5000 · 2024-05-10T03:03:46Z

I'd totally forgot this issue wasn't completely solved, but now I looked into it.

transaction list -x -l -f 156492 -e 156902

This is an unsupported combination. If you use locators, you have to provide an address to follow. Of course the error should be more meaningful, so I created a new message.

I'd assume that the -l flag is not taking into consideration the -e flag.

Correct observation, thanks. It would show actually all transactions in blocks which were already stored as locators. Reproduced and fixed it.

I saw that I gave you wrong information above about the -l option (sorry, the transaction list command is so complex that I sometimes forget details):

This command does not store locators, it only uses them

It actually does store the blocks of the range which are behind the last checked block. As far as I remember the idea was to not "lose" the scanning work which is done in this case. I have decided to keep it this way, but to store the locator blockheights only if the start block is not behind the last cached block. Otherwise the user could be surprised that the process took so long because it would try to store all blocks up to the chosen endblock (example: you have already cached until 100000, startblock is 300000 and endblock 350000 - it would then cache between 100000 and 350000).

The rest of that post is however correct: you cannot cache locators of arbitrary block ranges.

About making -l the default: I'm not sure about that. Let me think a bit about it. Finding a flag word with an unused letter would also be quite a challenge as -n for -no-locators, -c/-b for -chain or -blockchain or so or -o for "onchain" are already taken.
An alternative could be to only require -l OR -x, i.e. -x would be needed only if you don't want -l. The only problem I have with that is that the x=explorer association would get weaker.

Commit for the fixes is 32405b0.

buhtignew · 2024-05-11T10:42:50Z

I was trying to cache the blocks from 156492 to 156902 by running transaction list -x -l -f 156492 -e 156902 and also transaction list -x -f 156492 -e 156902 -l

This command does not store locators, it only uses them

It actually does store the blocks of the range which are behind the last checked block.

I've tried to store blocks using transaction list -x -l command but got no luck:

If I run transaction list -x -g -f 156492 -e 156902 -l, transaction list -x -f 156492 -e 156902 -l, transaction list -x -g -l or transaction list -x -l I'm getting:

Searching transactions (this can take several minutes) ...
Starting at block: 156492
Ending at block: 156902
 
Error: If you use the locator feature you have to provide address(es) or deck/tokens.

Which is expected.

If I run transaction list 35b886c6ed16c3ace35ee59b6777e3a286e317a64715bbe3f080e16d8e5f52a4 -x -g -f 156492 -e 156902 -l or transaction list 35b886c6ed16c3ace35ee59b6777e3a286e317a64715bbe3f080e16d8e5f52a4 -x -f 156492 -e 156902 -l I'm getting the same output as without the -l flag and no blocks are being stored in the blocklocator.json file. Which is also expected.
If I run transaction list 35b886c6ed16c3ace35ee59b6777e3a286e317a64715bbe3f080e16d8e5f52a4 -x -l, transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l or transaction list -o mfq11jH49F2jqUMrVpGZhtyeDC88Vk9Vs8 -x -l I'm getting the following error message:

Searching transactions (this can take several minutes) ...
Starting at block: 0
Ending at block: 429993
Traceback (most recent call last):
  File "~/.local/bin/pacli", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/__main__.py", line 479, in main
    fire.Fire({
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 143, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 477, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
                                ^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 693, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
                ^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_classes.py", line 1564, in list
    return ei.run_command(self.__list, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_interface.py", line 33, in run_command
    result = c(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_classes.py", line 1619, in __list
    txes = bx.show_txes(sending_address=origin, receiving_address=address_or_deck, start=from_height, end=end_height, coinbase=view_coinbase, advanced=advanced, quiet=quiet, debug=debug, burns=False, use_locator=locator)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/blockexp.py", line 277, in show_txes
    txes = ei.run_command(show_txes_by_block, receiving_address=receiving_address, sending_address=sending_address, advanced=advanced, deckid=deckid, startblock=startblock, endblock=endblock, coinbase=coinbase, quiet=quiet, debug=debug, use_locator=use_locator)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_interface.py", line 33, in run_command
    result = c(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/blockexp.py", line 110, in show_txes_by_block
    blockheights = blockheights + list(range(last_checked_block, endblock + 1))
                   ^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'blockheights' where it is not associated with a value

And of course the blocklocator.json file is not being updated.

So I've say that the -l flag doesn't store blocks for the moment.

d5000 · 2024-05-11T20:32:47Z

I fixed the UnboundLocalError, which appeared due to a mistake I made in the last related commit. Now the blockheights should be stored correctly in the cases I mentioned (at least here it works with the mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik address).

To check the blocklocator.json comfortably I added a command: config show ADDRESS_OR_DECK -b. Simply enter the address or deck/token you want to check and you'll see which block heights were stored and which was the last checked block.

Commit: 39ddb90

buhtignew · 2024-05-15T10:18:20Z

I've tested transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l and the error is gone. The blocks are stored as expected.
However the output I've got after the first execution of the command is a bit strange.
I haven't caught the whole output because I was not ready to but I have the last 1016 lines of it:
first transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l output.txt
What I've noticed is that is doesn't contain the address mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik, not even once. And it's different from the next transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l outputs I'm getting.

At the same time if I run transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l after the blocks are stored I can also see some transaction that doesn't contain the address mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik. For instance: 8d01a1d4dddfe45d51f2bcce6359cb1b815b3efdb5e6ae5b9f3aabe729bbff83 or a7901d499b00ab8d5287aef34f202ccecc526758aa80ba0723c92eddeaa471c7.
And there are also transactions in which the same address is present only as sender (for instance dbbe20a60756ea104a78f78aacff5b13470d9f099bf2abd7859380634bfd070c):
next transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l output.txt

d5000 · 2024-05-15T19:56:34Z

While I didn't get that many transactions without the address in the case of mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik, there were 4 txes in my output of transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l where the address isn't mentioned, including the two you mentioned in your post. So there's probably a bug there. I'll investigate.

d5000 · 2024-05-18T03:38:55Z

Fixed the bug in commit 036949f. Transactions not related to addresses were indeed shown due to a bug in the branching logic. This has been fixed now and simplified too.

EDIT: I recommend testing first the other commands until I post here again, I discovered some new issues with the block locator function I'd like to fix first.

d5000 · 2024-06-08T22:34:19Z

The issues I encountered are (hopefully) fixed and pre-tested as of commit 7c31f67.

Block locator features (transaction list -x -l and the deck/address cache) can now be used and tested again.

It is however possible that due to the earlier bugs the blocklocator.json became corrupted. If anything looks strange then I highly recommend to simply delete or rename the blocklocator.json and start new.

The exception is until now the integrity test. There I have still to test more.

buhtignew · 2024-06-13T09:32:50Z

I've tested transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l and it seems to work as expected.
However I've run transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x after that and got the following error:

  File "~/.local/bin/pacli", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/__main__.py", line 479, in main
    fire.Fire({
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 143, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 477, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
                                ^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/fire/core.py", line 693, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
                ^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_classes.py", line 1644, in list
    return ei.run_command(self.__list, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_interface.py", line 33, in run_command
    result = c(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/extended_classes.py", line 1699, in __list
    txes = bx.show_txes(sending_address=origin, receiving_address=address_or_deck, start=from_height, end=end_height, coinbase=view_coinbase, advanced=advanced, quiet=quiet, debug=debug, burns=False, use_locator=locator)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/blockexp.py", line 79, in show_txes
    blockdata = show_txes_by_block(receiving_address=receiving_address, sending_address=sending_address, advanced=advanced, deckid=deckid, startblock=startblock, endblock=endblock, coinbase=coinbase, quiet=quiet, debug=debug, use_locator=use_locator, store_locator=use_locator)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/blockexp_utils.py", line 104, in show_txes_by_block
    if (not quiet) and (bh % 100 == 0) and (bh not in loc_blockheights):
                                                      ^^^^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'loc_blockheights' where it is not associated with a value

I've thought there is some interference with the blocklocator.json file and have removed it - the error hasn't gone.
_

transaction list -x -l -f 156492 -e 156902

This is an unsupported combination. If you use locators, you have to provide an address to follow. Of course the error should be more meaningful, so I created a new message.

I've run transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -f 156492 -e 156902 -l and got:

General error raised by PeerAssets. Check if your input is correct.

Then I've run transaction list -x -f 156492 -e 156902 -l and got the same message mentioned here:

 General error raised by PeerAssets. Check if your input is correct.

        If you gave a deck as an argument, a possible reason for this error is that you need to initialize the deck.

        To initialize the default decks, use:

        pacli deck init

        To initialize a single deck, use:

        pacli deck init DECKID

d5000 · 2024-06-17T03:20:16Z

First two errors were fixed in commit 08247a9 (blocklocators.json was not the culprit here).

The third problem is because this mode is unsupported, and this was also already mentioned in the help (Note 2).

I have done however a workaround, in this case the locators are simply switched off. Alternatively I can raise a more meaningful error but here we run again into the problem: "how much have we to hold the hand of the user if he doesn't read the help properly?". This is in commit dc153e4.

By the way: it's easier for me to detect the problems which cause "red errors" (like the well-known "General Error ...") if you post the --debug output (if a debug option is available for this command).

Can be closed if everything works.

buhtignew · 2024-07-02T08:37:03Z

It seems like there is still an issue with the transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -f 156492 -e 156902 -l command: the error message is gone, but some of the of transactions I'm getting in the output are not in the range of the limits set up by the command.
Specifically it seems like the blocks 132356, 141256, 149190, 150340 and 150374 are included in the output and are not within the limits.

d5000 · 2024-07-08T23:56:53Z

Confirmed and fixed in commit 59163ee. Please close if everything works.

buhtignew · 2024-07-09T16:50:32Z

Seems to work, closing.

buhtignew added the question Further information is requested label May 2, 2024

d5000 self-assigned this May 31, 2024

buhtignew mentioned this issue Jun 6, 2024

token cache doesn't seem to work #118

Closed

d5000 mentioned this issue Jun 7, 2024

address set with non existent address #116

Closed

d5000 removed their assignment Jun 9, 2024

buhtignew mentioned this issue Jun 14, 2024

Discrepancy between transaction list [ADDRESS] and address cache [THE_SAME_ADDRESS] outputs #132

Closed

d5000 mentioned this issue Jun 17, 2024

address cache run two times #131

Closed

buhtignew mentioned this issue Jul 3, 2024

A question about the integrity test #134

Closed

buhtignew closed this as completed Jul 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Locator flag with transaction list command #86

Locator flag with transaction list command #86

buhtignew commented May 2, 2024

d5000 commented May 3, 2024 •

edited

Loading

buhtignew commented May 3, 2024

buhtignew commented May 3, 2024 •

edited

Loading

d5000 commented May 10, 2024 •

edited

Loading

buhtignew commented May 11, 2024 •

edited

Loading

d5000 commented May 11, 2024 •

edited

Loading

buhtignew commented May 15, 2024 •

edited

Loading

d5000 commented May 15, 2024

d5000 commented May 18, 2024 •

edited

Loading

d5000 commented Jun 8, 2024 •

edited

Loading

buhtignew commented Jun 13, 2024 •

edited

Loading

d5000 commented Jun 17, 2024 •

edited

Loading

buhtignew commented Jul 2, 2024 •

edited

Loading

d5000 commented Jul 8, 2024

buhtignew commented Jul 9, 2024

Locator flag with transaction list command #86

Locator flag with transaction list command #86

Comments

buhtignew commented May 2, 2024

d5000 commented May 3, 2024 • edited Loading

buhtignew commented May 3, 2024

buhtignew commented May 3, 2024 • edited Loading

d5000 commented May 10, 2024 • edited Loading

buhtignew commented May 11, 2024 • edited Loading

d5000 commented May 11, 2024 • edited Loading

buhtignew commented May 15, 2024 • edited Loading

d5000 commented May 15, 2024

d5000 commented May 18, 2024 • edited Loading

d5000 commented Jun 8, 2024 • edited Loading

buhtignew commented Jun 13, 2024 • edited Loading

d5000 commented Jun 17, 2024 • edited Loading

buhtignew commented Jul 2, 2024 • edited Loading

d5000 commented Jul 8, 2024

buhtignew commented Jul 9, 2024

d5000 commented May 3, 2024 •

edited

Loading

buhtignew commented May 3, 2024 •

edited

Loading

d5000 commented May 10, 2024 •

edited

Loading

buhtignew commented May 11, 2024 •

edited

Loading

d5000 commented May 11, 2024 •

edited

Loading

buhtignew commented May 15, 2024 •

edited

Loading

d5000 commented May 18, 2024 •

edited

Loading

d5000 commented Jun 8, 2024 •

edited

Loading

buhtignew commented Jun 13, 2024 •

edited

Loading

d5000 commented Jun 17, 2024 •

edited

Loading

buhtignew commented Jul 2, 2024 •

edited

Loading