-
rbcrbc[m]
hello - I'm implementing a monero merchant. With get_bulk_payments, what sort of validation do I need to do on unlock_time and block_height?
-
rbcrbc[m]
I was otherwise implementing the algorithm described here:
monero.stackexchange.com/questions/…yments-without-trusting-a-third-par but some of the links are broken, and does not cover unlock_time.
-
selsta
-
selsta
basically you should ignore all transactions that have a non default unlock time
-
selsta
no one should send timelocked transactions to merchants
-
rbcrbc[m]
what is a non-default unlock time? non zero?
-
rbcrbc[m]
zero good, non-zero bad?
-
rbcrbc[m]
-
selsta
I assume zero is the default, you can test it by doing a normal transaction
-
rbcrbc[m]
what about block_height? some posts talk about a minimum 10?
-
moneromooo
Easier to check confirmations, which is current height minus block height (plus or minus 1). If confirmations is >= N, act upon it.
-
moneromooo
The lower N is, the quicker you process customer requests, but the more likely the tx is to be made invalid later.
-
Inge
won't a reorg just lead to the tx in question being included in a later block with an extermely high degree of probability?
-
moneromooo
A reorg will just lead to the tx in question being included in a later block with an extermely high degree of probability.
-
moneromooo
fsvo extermely.
-
rbrunner
It seems to me the Monero codebase has 2 ways to serialize and deserialize to and from JSON: RapidJSON-based and pure epee (?) with those "BEGIN_SERIALIZE_OBJECT" and "FIELD" macros
-
rbrunner
Is this correct? And if yes when does which variant get used? Are they even used interchangingly, do they *have* to produce exactly the same JSON for everything?
-
moneromooo
It is correct. AFAIK the rapidjson variant is seldom used. For the keys file. Can't think of another use off the top of my head.
-
moneromooo
They don't have to generate the same one. The epee version is probably less generic. The epee version can also read/write from binary key/value with the same code.
-
moneromooo
I believe wfaressuissia rewrote a lot of that epee code in a recent PR.
-
moneromooo
To be less memory hungry and probably faster too.
-
rbrunner
I make an attempt at the "view_tag" serialization issue that is described here:
monero-project/monero #8061
-
rbrunner
Basically pretend that a small two-value object does not exist and serialize like values of the surrounding object
-
rbrunner
And I wondered whether I had to get this running in both JSON seralizer variants
-
rbrunner
(Let that "tagged_key" sub-object vanish in JSON)
-
rbrunner
I think that should not be too difficult with the epee variant
-
moneromooo
Not sure what you're after but it sounds like maybe you want FIELDS (see cryptonote_basic.h)
-
rbrunner
Ok, thanks, will check.
-
jberman[m]
@rbunner here's how far I got with that
-
jberman[m]
I saw in `cryptonote_basic.h` that `BLOB_SERIALIZER(cryptonote::txout_to_key)` serializes the `txout_to_key` bits in its entirety into the `key` field (and because `txout_to_key` just has one member `crypto::public_key key`, the only bits that end up in that field are the `key`)
-
jberman[m]
If I do the same like `BLOB_SERIALIZER(cryptonote::txout_to_tagged_key)`, then it serializes the entire `txout_to_tagged_key` bits onto the `key` field (which includes the concatenation of both `key` + `view_tag`)
-
jberman[m]
What I really wanted was to serialize to `target: { key, view_tag }`, but didn't see how to get that working cleanly
-
jberman[m]
rbrunner*