greetings, where can I find information about what a daemon rpc error code 0 means ? I found all others in github.com/monero-project/monero/bl…c/rpc/core_rpc_server_error_codes.h but cannot spot the error 0, I get it when sending a flush_txpool if that helps.

0 would be no error.

interesting

is that intended ? I may obviously misunderstand something, but usually if there is no error I receive a json rpc answer with a result key, it's the only case I encounter where a success would yield a {'error': {'code': 0, 'message': ''}, 'id': 0, 'jsonrpc': '2.0'} rpc answer

Then something might be failing to set an error code.

File a bug with the JSON you're sending.

will do, thanks

Longstanding confusion between error code and status error reporting. I'll PR a patch soon.

:mindblowngif:

that was quick @moneromoo ! thanks

.merges

Guys if one of the structures inside the transaction class was was changed, say we added an extra data variable in one of them, do we need to update the database version? What other stuff would have to be done to make everything ok

in a generic sense

would the code go back and add space for that data variable to every previous database entry for that structure?

In the general sense, no. The tx is stored as a bytestring.

Ok. But we would if we modified the existing elements?

You'd need to change serialization and presumably fork with updated validation rules. If this is for an altcoin, you would not need that though.

say if we changed a uint64 to a 32

so the db could still read the old values as 64

The tx is stored as a bytestring.

Now if you change something like height, you might want to alter the db to save space, but you would not *need* to.

In fact, we use 64 bits for height everywehre, but there's a MAX_BLOCK_NUMBER or so define that fits on 32 bits. So we do waste a bit.

But say if i've got a structure with a uint32 in there, and then change to 64. Wont reading the old values from the db read in the correct 32 and then 32 of junk?

6877 conflicts moneromooo

fixed

on the recent CCS for 'perfect p2p protocol', wonder if can borrow some parts from libp2p (github.com/libp2p).

what's up

<pyu "on the recent CCS for 'perfect p"> the C++ - Go interop isn't all that good

Does anyone here know why this

    struct txin_to_key_public

    {

      uint64_t amount;

      uint64_t relative_offset;

      crypto::hash tx_hash;

      BEGIN_SERIALIZE_OBJECT()

        VARINT_FIELD(amount)

        VARINT_FIELD(relative_offset)

        FIELD(tx_hash)

      END_SERIALIZE()

    };

would be padded ?

It's a structure I made

whereas   struct txin_to_key

  {

    uint64_t amount;

    std::vector<uint64_t> key_offsets;

    crypto::key_image k_image; // double spending protection

}

is not padded

I just have no idea what's going on... If I wrap it in a pragma pack (1) it works, but otherwise i have no luck

it's triggering this return

return !std::is_standard_layout<T>() || alignof(T) != 1;