mymonero-app-js: V11 comtability: Ringct type 3 is not allowed from v11

@moneroexamples core-js and core-cpp have been updated with fork_version support

I would consider changing the name from rct to distinguish the new field more clearly. Although perhaps older clients will incorrectly think its pre-ringct?

Yeah, the format is exactly the same for rct types 1-3, so old clients can continue to just work (until the actual fork, of course.) There didn’t seem to be much risk in reusing the same field for the new format as well: any reasonable client would just fail to parse it, but the worst case scenario for even an unreasonable one is an invalid tx that will be rejected.

Either way, the scenario is just three: (1) no rct field pre-ringct, (2) rct field containing unencrypted mask which might be the (fixed/constant) identity mask for coinbases and (3) "rct": "implied" meaning the client can compute the ringct mask from the other information. If it helps the client at all, everything can be “squished” to just (1) and (2) but the server would have to compute the mask on the fly each time or store it. The server already is storing the mask somehow for these older transactions, but may lose space savings on newer transactions.

I see no reason to send the amount again, its already being sent in another field. Differentiating between coinbases is possible, but leaves an extra case for the client to handle and the only penalty are the transmission bytes for sending the identity mask. The server has a fixed string constant to send either way. Unless you were proposing to send the encrypted mask, instead of unencrypted?

I’m definitely proposing that we continue sending the mask encrypted, as we are already doing. It was already suggested that this be changed to decrypted, but that is not exactly an overnight change for the MyMonero backend. (It’s also not backward compatible, for what little that’s worth.)

It seems obvious now that the commitment shouldn’t be needed either, but I hadn’t realized it at the time. As for the encrypted amount, I’m pretty sure the MyMonero client will happily accept either format without it, so we can amend this update accordingly if you prefer. I hadn’t mentioned that before now simply because I didn’t want to muddy the waters. The purpose of this update wasn’t to be perfect (just in case that’s not obvious), but just to get the new-style outputs working in some way that everyone can implement, test and release in the couple of days left before the fork. I think it meets that goal, in spite of its rough edges. Do you disagree?

What I’m asking here is whether we can all live with the change as described here until the dust settles from this weekend’s fork. At this point, @moneroexamples and I have each spent considerable time testing the updated client against our respective servers. Going back to square one is not only unappealing, to put it mildly, but given that the iOS version of the client still has to be reviewed and approved by Apple, basically means that there would be zero chance of having a working client on that platform in time.

Longer-term, there’s no question that this entire field could use revisiting – just for starters, there doesn’t seem to be any good reason to be sending a blob instead of normal fields – but what I’m suggesting (ok, insisting) is that we save that for a time when it can be discussed and done right to everyone’s satisfaction without the time pressure of an imminent fork.

@moneroexamples https://github.com/monero-project/meta/pull/287#issuecomment-470172708

Also, I’d like to propose three one new fields in the get_unspent_outs response: block_height, next_fork_block_height and next_fork_version fork_version.

This would be optional, for use by the client to determine whether or not to use, for example, RingCT type 4 when constructing new transactions.

What do you think?

@ndorf @luigi1111

Thanks for the feedback. The new changes too mymonero-core-cpp seem to be working now with original point 4 (80 characters long rtc field). So now I think the main thing to do is just more testing.

(tl;dr: one more change at https://github.com/ndorf/mymonero-core-cpp/commit/7f681b75192043b73bd23c5055011d49fbdd4240 fixes everything, I think)

@moneroexamples the elegant simplicity of your change on the OpenMonero side did not escape me. With the decrypted mask already being available in the right place at the right time, it’s the best kind of 1-liner: a (-1)-liner. Unfortunately the situation with the MyMonero backend is quite the opposite. It’s not infeasible, but it’s a lot riskier than the solution I’m proposing here, especially given only a couple of days left to test everything. (To just scratch the surface, there is no decoding of transaction data, RingCT or otherwise, in the HTTP/API server itself.)

If it were the clearly correct solution, that might be a poor excuse, but given that it should be trivial for the client to compute the deterministic mask itself, there is no need to send that from the server for every output, I think that is preferable in and of itself.

I think rtc_mask decoding procedure is incorrect. The rtc_mask value obtained from this procedure here : https://github.com/ndorf/mymonero-core-cpp/blob/feature/rct_v2/src/monero_transfer_utils.cpp#L169 is simply different from what it was before and daemon is rejecting it.

It’s definitely incorrect, otherwise it would be working 😃 what you might have missed is that although it is “different from what it was before,” it must be different to be correct: see here

Luckily @paulshapiro was able to quickly notice that I made a mistake in my first change, and incorrectly applied an extraneous hash_to_scalar() to the derived key. After fixing that, it looks like everything is working. I still have a lot more testing to do, but I’ve successfully sent a few RCT Type 4 outputs already.

@moneroexamples yes in order to “decrypt” successfully, the front end would need the same routine added. I’m not sure which I prefer at this point (and I also need some sleep). 😃 I think it’s probably “more correct” to have the front end regenerate the deterministic mask, though it’s likely not much different in practice. Cost to regenerate is pretty trivial though.

@moneroexamples https://github.com/ndorf/monero_tests/blob/master/testnet-v9-coinbase.seed

Yes. Coinbase transactions don’t normally have rtc fields. Unless the failing outputs have some wacky stuff going on, this is irrelevant.

I prepared example of tx that fails. Maybe it will be useful.

The tx in hex is here: https://paste.fedoraproject.org/paste/OikdL7u2fwdEicTvTglbIg

The view this tx in decoded form, please copy and paste the hex into the tx pusher of the onion explorer, e.g.: http://139.162.60.17:8082/rawtx and press Check. Trying to Push the tx, will result in invalid input error.

For comparison, this is example of tx that was accepted: http://139.162.60.17:8082/tx/b4e9b185fc03949b9982f4474831febb8a1827cfae1caa26356c9e75fb6801e5

Its different error after all. Orginal error was about invalid outputs. Some, as in most, fail do invalid input:

019-03-01 03:24:08.416 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        0          expand_transaction_2
510893 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        5            verRctMGSimple
510894 2019-03-01 03:24:08.422 [RPC0]  INFO    ringct  src/ringct/rctSigs.cpp:1066 verRctMGSimple failed for input 0
510895 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        5          verRctNonSemanticsSimple
510896 2019-03-01 03:24:08.422 [RPC0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:2836 Failed to check ringct signatures!
510897 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        7        check_tx_inputs
510898 2019-03-01 03:24:08.422 [RPC0]  INFO    txpool  src/cryptonote_core/tx_pool.cpp:266 tx used wrong inputs, rejected
510899 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        8      add_tx
510900 2019-03-01 03:24:08.422 [RPC0]  ERROR   verify  src/cryptonote_core/cryptonote_core.cpp:960 Transaction verification failed: <5a0845b47c4bd143cad71219df33e606b6a222fdd1c3b99a6e7d62dce7ea62b2>
510901 2019-03-01 03:24:08.422 [RPC0]  WARN    daemon.rpc  src/rpc/core_rpc_server.cpp:721 [on_send_raw_tx]: tx verification failed: invalid input
510902 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF       27    on_send_raw_tx
510903 2019-03-01 03:24:08.422 [RPC0]  DEBUG   net.http    src/rpc/core_rpc_server.h:96    /sendrawtransaction processed with 0/28/0ms