transaction list -x with data interval

[buhtignew]

I've run transaction list -x -f 2023-07-22 -e 2023-07-23 and got Error: End block or date must be after the start block or date. I've got the same output for all the further dates until 2023-07-27 included, while on 2023-07-28 I'm receiving a correct output (just one transaction). Seeing that I've decided to expand the time span moving towards the past and has discovered that the same error message is being thrown for any interval from 2023-07-12 to 2023-07-27 included. I assume there are no valid transactions in that time span. _ By error I've run transaction list -x -f 2023-07-8 -e 2023-07-27 and got Error: At least one of the dates you entered is invalid. message because the 8 in the 2023-07-8 is written without an initial 0. I don't know whether it's something we should consider to refine, though.

[d5000]

Confirmed. The problem is that at these dates (between 2023-07-11 and 2023-07-28) the server was down and no blocks were "produced" :)

What the algorithm did was the following:

• to search the start block, it searches the first block produced after 0:00 at the date 2023-07-22
• to search the end block, it searches not directly the last block on 2023-07-23, but actually the first block produced after 0:00 of the date 2023-07-24 (i.e. one day after the date given) and subtracts one block (so it's the last block of 2023-07-23). This makes the algorithm simpler and easier to maintain.

As for 2023-07-22 the result was the same block than for 2023-07-24, the end block was one block less.

I don't think this will happen "in the wild" as SLM mainnet produces blocks 24/7. Anyway I have fixed this in a way that the same block is output in these cases. So always one block will be checked.

Alternatively we could output an alternative error message ("No blocks in this period" or something like this). But let's not overthink it, as I wrote before, it should never happen outside of testnet.

I have also changed the date processing code in a way dates without zeroes are accepted.

Commit: 933a81f

[buhtignew]

I have also changed the date processing code in a way dates without zeroes are accepted.

I don't think it's relevant, but my transaction list -x -f 2023-07-8 -e 2023-07-23 output after upgrade is still: Error: At least one of the dates you entered is invalid.

I don't think this will happen "in the wild" as SLM mainnet produces blocks 24/7. Anyway I have fixed this in a way that the same block is output in these cases. So always one block will be checked.

I'm getting a funny message now (if I run transaction list -x -f 2023-07-12 -e 2023-07-27, for instance):

Ending at block: 141240
Starting at block: 141241

But what is the block 141241 in this case? One that goes immediately after the selected period?

[d5000]

Fixed both problems, they were actually dumb oversights - in the second one, the modification I introduced in the last related fix wasn't taken into account because the startblock/endblock print statement was placed earlier in the code.

I'll upload the fixes later in the next commit as I'm working on the last missing features for the block locator technology.

[d5000]

Uploaded the commit with the fixes (commit 1426a6b). Can be closed if there are no further questions/bugs.

[buhtignew]

This works. The only thing I don't yet have that clear is: what is the block 141241 we are getting as output. ~~I've tried to run transaction list -x -f 2023-07-24 -e 141242 and got the same output of transaction list -x -f 2023-07-22 -e 2023-7-23. Then I've also tested transaction list -x -f 2023-07-25 -e 141242 and still got the same output. Thus I've went on testing the following dates and has discovered that the same output is being provided until transaction list -x -f 2023-07-28 -e 141242 command while the output of transaction list -x -f 2023-07-29 -e 141242 is as expected: Error: End block or date must be after the start block or date..~~ I assume that it's the block that has been produced on 2023-07-28, if so its presence in transaction list -x -f 2023-07-22 -e 2023-07-23 output, for instance, looks unexpected. I think we have a more appropriate message being already provided in case of the transaction list -x -f 141240 -e 2023-07-27 command, in particular:

Searching transactions (this can take several minutes) ...
Starting at block: 141240
Ending at block: 141240
No transactions found.
No matching transactions found.

Would it make sense/possible to activate it for the date's intervals as well?

[d5000]

The start block is always the first block produced after the start date (-f) 0:00 UTC.

Block 141240 is not appropiate as an output for this query, because it was produced before the start date. The reason no transactions are shown there is because it contains only a coinbase transaction and --view_coinbase option was not entered.

The only alternative, as I explained already, is to show nothing at all in this case. And again, I'm not willing to lose much time on this because this will never happen on mainnet.

[buhtignew]

Despite I have to recognize you've done your best to explain to me this case and to adjust the code accordingly there is still something that worries me:

If I've got it right the situation is the following: 1) From 2023-07-12 to 2023-07-27 our test blockchain hasn't produced any block because the servers where switched off. 2) Thus the block 141240 has happened before 2023-07-12 and the block 141241 has happened after 2023-07-27.

If the above description is correct it's not enough clear to me what you are referring to when you say: _Block 141240 is not appropiate as an output for this query, because it was produced before the start date. The reason no transactions are shown there is because it contains only a coinbase transaction and --viewcoinbase option was not entered. In fact by running transaction list -x -f 2023-07-12 -e 2023-07-27 -v I'm getting the same output of transaction list -x -f 2023-07-12 -e 2023-07-27:

Searching transactions (this can take several minutes) ...
Starting at block: 141241
Ending at block: 141241
{
    'txid': '1030ff64b81a2bc3f0c03254a7f24aafd04536c11da759d23e3edea8e09d3030',
    'inputs': [],
    'outputs': [
        {'receivers': ['mjSprvDhx8vgUwTi1H9rK5sdXaAEyMTMSw'], 'value': 22.59}
    ],
    'blockheight': 141241
}
{
    'txid': '91695693f1f82588dbfe1ee0fc51b9fe4b588803cf0c36f15734417adda99246',
    'inputs': [
        {'sender': ['mie75nFHrNAHHKfQ141fWfWozdMnaec8mb'], 'value': 0.854668}
    ],
    'outputs': [
        {'receivers': ['mqR3iBYqKprpqjxxZgAtD1jizZxVqc9dh4'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['mie75nFHrNAHHKfQ141fWfWozdMnaec8mb'], 'value': 0.01},
        {
            'receivers': ['mie75nFHrNAHHKfQ141fWfWozdMnaec8mb'],
            'value': 0.814668
        }
    ],
    'blockheight': 141241
}

Which is consistent with my expectations: since the blockchain was stuck in that period there are no coinbase transactions either.

Another thing I haven't understood is whether the change of code you've described as following works: to search the end block, it searches not directly the last block on 2023-07-23, but actually the first block produced after 0:00 of the date 2023-07-24 (i.e. one day after the date given) and subtracts one block (so it's the last block of 2023-07-23). This makes the algorithm simpler and easier to maintain. If I've got it right the transaction 91695693f1f82588dbfe1ee0fc51b9fe4b588803cf0c36f15734417adda99246 from the block 141241 mentioned above has happened on 2023-08-28, but it's being outputted for whatever interval from 2023-07-12 to 2023-07-27. Following your description I was expecting the block 141241 to be found by the code and then to be subtracted from the output, which is apparently not happening.

So what worries me here is if we provide the block that has happened on 2023-07-28 for the interval, let say, from 2023-07-12 to 2023-07-13 it's possible IMO (but of course not necessary) that this logic error influences somehow the other outputs we are providing.

And last, but not least, I have seen blockchains stuck for more than 24 hours. Maybe it will never happen with slimcoin (I should always keep in mind that I don't understand things that well as you) but I'd prefer us to provide the right output in the very remote case it might happen and thus to put this change of the code into out list of tasks, even with a very low priority, if possible.

[d5000]

So what worries me here is if we provide the block that has happened on 2023-07-28 for the interval, let say, from 2023-07-12 to 2023-07-13 it's possible IMO (but of course not necessary) that this logic error influences somehow the other outputs we are providing.

No, this isn't the case. The "showing blocks by date" is not called in any part of the rest of the code, it's simply an additional mode only for transaction list to be more user-friendly for the -x option. Even if the block heights are cached if you use the -l option there would be no harm if you for example store blocks per day: storing them twice has exactly the same outcome in the blocklocator.json file than storing them once.

But anyway I guess that you are argumenting in favour of not checking any blocks at all in such cases (when no blocks are produced between the two dates)? I wrote above that this is a valid option for me. So If I'm guessing correctly here then I can implement that in this way as this is a small change, but then I'd like to close the issue.

An argument in favour of showing the first block after the start date (-f), even if it is produced after the end date like in your example (the way it occurs now) is that transactions can be sent to the miners inside the whole time range (from the last block on) before they are included in the next block. But I'm not gonna insist on this. There are arguments in favour of both ways to output in these cases.

Following your description I was expecting the block 141241 to be found by the code and then to be subtracted from the output, which is apparently not happening.

Just to explain this point: What the last code change of this command did was to provide always at least one block - the first block produced after 0:00 UTC of the start date. This means that in this particular case - and only this one. i.e. when there are no blocks in the whole time range - the subtraction of one block from the end date is not done because it would mean that the end block was before the start block. This is not a bug but a deliberate decision I took. But again, I can also implement it in a way nothing at all is output if no blocks are produced in the time range.

[buhtignew]

...is that transactions can be sent to the miners inside the whole time range (from the last block on) before they are included in the next block.

I understand what you mean now. Indeed with the servers switched off there could've been transactions sent to the miners during such a long time span. But by other hand the only certainty we can have in this context is when those transactions have been included into the block and that is what we should provide to the user as output, IMO.

What the last code change of this command did was to provide always at least one block - the first block produced after 0:00 UTC of the start date.

If you think it's important to provide at least one block even after the range queried by the user we can specify that there are no blocks in that time span and that the first block after the selected period has been produced on XX-XX-XXXX and is being outputted after.

Could it work for you?

[d5000]

I've thought a bit about this issue and I think it's better if pacli doesn't output anything at all in such cases (only a message that no blocks were found in this period).

Commit: 775cd18

[buhtignew]

This works, I'm closing this issue.