05:23:15 <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?
05:23:15 <rbcrbc[m]> I was otherwise implementing the algorithm described here: https://monero.stackexchange.com/questions/1994/whats-the-easiest-way-to-integrate-monero-payments-without-trusting-a-third-par but some of the links are broken, and does not cover unlock_time.
05:56:01 <selsta> rbcrbc[m]: https://github.com/monero-project/monero#blockchain-based
05:57:34 <selsta> basically you should ignore all transactions that have a non default unlock time
05:57:49 <selsta> no one should send timelocked transactions to merchants
05:57:59 <rbcrbc[m]> what is a non-default unlock time? non zero?
05:58:09 <rbcrbc[m]> zero good, non-zero bad?
05:58:18 <rbcrbc[m]> (interesting reading: https://thecharlatan.ch/Monero-Unlock-Time-Privacy/)
05:59:24 <selsta> I assume zero is the default, you can test it by doing a normal transaction
06:01:33 <rbcrbc[m]> what about block_height? some posts talk about a minimum 10?
07:45:04 <moneromooo> Easier to check confirmations, which is current height minus block height (plus or minus 1). If confirmations is >= N, act upon it.
07:45:40 <moneromooo> The lower N is, the quicker you process customer requests, but the more likely the tx is to be made invalid later.
09:00:17 <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?
12:57:04 <moneromooo> A reorg will just lead to the tx in question being included in a later block with an extermely high degree of probability.
12:57:17 <moneromooo> fsvo extermely.
19:49:44 <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
19:50:33 <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?
19:51:48 <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.
19:52:24 <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.
19:53:00 <moneromooo> I believe wfaressuissia rewrote a lot of that epee code in a recent PR.
19:53:22 <moneromooo> To be less memory hungry and probably faster too.
19:55:27 <rbrunner> I make an attempt at the "view_tag" serialization issue that is described here: https://github.com/monero-project/monero/pull/8061
19:55:53 <rbrunner> Basically pretend that a small two-value object does not exist and serialize like values of the surrounding object
19:56:24 <rbrunner> And I wondered whether I had to get this running in both JSON seralizer variants
19:57:19 <rbrunner> (Let that "tagged_key" sub-object vanish in JSON)
19:58:06 <rbrunner> I think that should not be too difficult with the epee variant
20:09:04 <moneromooo> Not sure what you're after but it sounds like maybe you want FIELDS (see cryptonote_basic.h)
20:12:58 <rbrunner> Ok, thanks, will check.
21:20:34 <jberman[m]> @rbunner here's how far I got with that
21:20:59 <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`)
21:21:10 <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`)
21:21:23 <jberman[m]> What I really wanted was to serialize to `target: { key, view_tag }`, but didn't see how to get that working cleanly
21:22:24 <jberman[m]> rbrunner*