Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.18.3.0 2023-08-17T15:35:00Z 2023-08-17T15:35:00Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2022-05-25T09:30:58Z urn:sha1:356e6877dcd3fcb337ea8ff8c88cf44fbc6a30a6 2023-08-17T15:34:57Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2022-05-25T09:02:27Z urn:sha1:633e1b735931b6437730eaa1940339acb9c7d697 2023-08-17T15:24:16Z luigi1111 luigi1111w@gmail.com 2023-08-17T15:24:16Z urn:sha1:9d5c5b563416b68a74031cc4647d260035b48c23 78348bc wallet-rpc: restore from multisig seed (jeffro256) 2023-08-10T15:13:07Z jeffro256 jeffro256@tutanota.com 2023-06-22T07:15:12Z urn:sha1:78348bcddd18fa7a25541595576bef1df4fc4022 2023-07-09T06:38:18Z j-berman justinberman@protonmail.com 2022-12-14T00:08:56Z urn:sha1:f137a35984985232a3aae50cd4c7b47634866594 - `/getblocks.bin` respects the `RESTRICTED_TX_COUNT` (=100) when returning pool txs via a restricted RPC daemon. - A restricted RPC daemon includes a max of `RESTRICTED_TX_COUNT` txs in the `added_pool_txs` field, and returns any remaining pool hashes in the `remaining_added_pool_txids` field. The client then requests the remaining txs via `/gettransactions` in chunks. - `/gettransactions` no longer does expensive no-ops for ALL pool txs if the client requests a subset of pool txs. Instead it searches for the txs the client explicitly requests. - Reset `m_pool_info_query_time` when a user: (1) rescans the chain (so the wallet re-requests the whole pool) (2) changes the daemon their wallets points to (a new daemon would have a different view of the pool) - `/getblocks.bin` respects the `req.prune` field when returning pool txs. - Pool extension fields in response to `/getblocks.bin` are optional with default 0'd values. 2023-03-13T19:57:43Z j-berman justinberman@protonmail.com 2022-09-10T02:34:18Z urn:sha1:65e13dbef1c3a4cc036919203eec2052a121f034 - Detach & re-process txs >= lowest scan height - ensures that if a user calls scan_tx(tx1) after scanning tx2, the wallet correctly processes tx1 and tx2 - if a user provides a tx with a height higher than the wallet's last scanned height, the wallet will scan starting from that tx's height - scan_tx requires trusted daemon iff need to re-process existing txs: in addition to querying a daemon for txids, if a user provides a txid of a tx with height *lower* than any *already* scanned txs in the wallet, then the wallet will also query the daemon for all the *higher* txs as well. This is likely unexpected behavior to a caller, and so to protect a caller from revealing txid's to an untrusted daemon in an unexpected way, require the daemon be trusted. 2022-09-21T17:51:19Z koe ukoe@protonmail.com 2022-05-14T22:07:47Z urn:sha1:1cd21bfba584fa7d886f13684f34c71931eddf4d 2022-09-07T06:22:07Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2022-08-16T20:20:38Z urn:sha1:0cbf5571d3ccd07c81d33b05dd23b2ac9c777c3b this will make it easier huge wallets to do so without hitting random limits (eg, max string size in node). 2022-05-17T19:52:03Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2022-05-14T19:49:48Z urn:sha1:29794742211b7fbd35b1c7b0b707cb495001b3e8 There are vulnerabilities in multisig protocol if the parties do not trust each other, and while there is a patch for it, it has not been throroughly reviewed yet, so it is felt safer to disable multisig by default for now. If all parties in a multisig setup trust each other, then it is safe to enable multisig. 2022-05-10T21:41:02Z luigi1111 luigi1111w@gmail.com 2022-05-10T21:41:02Z urn:sha1:c1625a89287498eed36ad360217509eaaaf0b02e 0d6ecb1 multisig: add post-kex verification round to check that all participants have completed the multisig address (koe)