(Belated) Fortnightly Sunday Update
Excuse the delay.
The recent unusual behaviour with MOINX transactions gave me a chance to delve into sections of the code I hadn't properly explored yet. I'd been curious about the exact mechanics of the private transactions, but it wasn't at the top of my list due to it not being directly relevant to the functioning of the platform. But anything that affects core functionality obviously takes priority, so I've been studying the stealth transaction code while brushing up on ECDH, CryptoNote and various bits and pieces in between.
The MOIN codebase is actually pretty dense. Between Bitcoin and the Peercoin, Blackcoin and Shadow additions, it can be a lot to navigate and it became apparent to me that I wasn't really going about it in the most efficient way. So I took a few days to re-examine my toolset and to try to improve my workflow - experimenting with various Vim plugins mainly - so that I can find and skip deftly between function calls and definitions etc. in future. Granted, none of this is very sexy, but the cumulative time-savings it'll bring should make it more than worthwhile.
Now to the MOINX transactions. My understanding is that when an encrypted wallet detects an incoming transaction it stores the public key, ephem pubkey and various metadata so that the spend pvt key can be derived and saved next time the wallet is unencrypted. From a security standpoint it obviously makes sense not to have the unencrypted spend key just sitting in memory indefinitely. So when you unlock the wallet you'll find your PRIVATE balance in the overview does in fact update to reflect any incoming MOINX transactions, though on the transactions page it still shows as a "sent MOINX" transaction with a 0.00 value until the wallet is restarted. It's behaviour we've inherited from SDC, but it could definitely be improved upon. I still need to figure out exactly what information a locked wallet can glean about an incoming MOINX transaction before deciding how best to convey it, so that's my job for next week.
To be honest I don't like writing about these sorts of things, it doesn't come naturally to me so I find it time-consuming. It also feels a bit self-indulgent. But if it's valuable to the community then it's worthwhile. I noticed a few people expressing a desire for more information on the platform so in the next update I'll try to explain further the reasoning behind the veil of secrecy. And apologies again for the delay - I'm fortunate enough to be in a position to work on MOIN almost exclusively, but occasionally something outside the project demands attention. Just be thankful I don't have a very active social life (and pray that I don't find a girlfriend!).
Excuse the delay.
The recent unusual behaviour with MOINX transactions gave me a chance to delve into sections of the code I hadn't properly explored yet. I'd been curious about the exact mechanics of the private transactions, but it wasn't at the top of my list due to it not being directly relevant to the functioning of the platform. But anything that affects core functionality obviously takes priority, so I've been studying the stealth transaction code while brushing up on ECDH, CryptoNote and various bits and pieces in between.
The MOIN codebase is actually pretty dense. Between Bitcoin and the Peercoin, Blackcoin and Shadow additions, it can be a lot to navigate and it became apparent to me that I wasn't really going about it in the most efficient way. So I took a few days to re-examine my toolset and to try to improve my workflow - experimenting with various Vim plugins mainly - so that I can find and skip deftly between function calls and definitions etc. in future. Granted, none of this is very sexy, but the cumulative time-savings it'll bring should make it more than worthwhile.
Now to the MOINX transactions. My understanding is that when an encrypted wallet detects an incoming transaction it stores the public key, ephem pubkey and various metadata so that the spend pvt key can be derived and saved next time the wallet is unencrypted. From a security standpoint it obviously makes sense not to have the unencrypted spend key just sitting in memory indefinitely. So when you unlock the wallet you'll find your PRIVATE balance in the overview does in fact update to reflect any incoming MOINX transactions, though on the transactions page it still shows as a "sent MOINX" transaction with a 0.00 value until the wallet is restarted. It's behaviour we've inherited from SDC, but it could definitely be improved upon. I still need to figure out exactly what information a locked wallet can glean about an incoming MOINX transaction before deciding how best to convey it, so that's my job for next week.
To be honest I don't like writing about these sorts of things, it doesn't come naturally to me so I find it time-consuming. It also feels a bit self-indulgent. But if it's valuable to the community then it's worthwhile. I noticed a few people expressing a desire for more information on the platform so in the next update I'll try to explain further the reasoning behind the veil of secrecy. And apologies again for the delay - I'm fortunate enough to be in a position to work on MOIN almost exclusively, but occasionally something outside the project demands attention. Just be thankful I don't have a very active social life (and pray that I don't find a girlfriend!).
keep your focus MOIN project ! and not worry about the gf , when you done with it ill arrange you 2x gf at least Greek ones!
thanks for the update!
Deal.
** I was a bit clumsy with my use of "spend pvt key" and "spend key" above. Just to clarify, there's a scan key-pair and spend key-pair, with stealth addresses being made from the public keys of both. What I was referring to was the pvt key for spending the newly received MOINX token.
Anyway, the reason the balance isn't updated with MOINX transactions is because it's not possible to check if the token has been further spent until a key image for it is produced, and it's not possible to create the key image without access to the unencrypted private spend key (i.e. without the wallet being unlocked). So I think the best option is to change it so that locked wallets show an incoming transaction of indeterminate amount with a tooltip explaining that the amount involved will be revealed once the wallet has been unlocked. Plus make it so that the details in the transactions table are automatically updated when this is done.
Sound good?