Monero

Monero GUI 0.18.5.0 'Fluorine Fermi' released

Mon, 11 May 2026 00:00:00 GMT

Overview

This is the v0.18.5.0 release of the Monero GUI software. This recommended release includes a large number of bug fixes.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Move P2Pool install location to LocalAppData on Windows (#4575)
Fix edge case in URI parsing (#4576)
Disable offline tx creation with long payment id (#4579)
Escape untrusted text in QR code scanning scenario (#4577)
Update P2Pool to v4.15 (#4584)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked to put out 14 commits containing 161 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
selsta
SChernykh
jpk68
SNeedlewoods
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.5.0.zip, 86b665cbb22e0ce349e1a13fc37e600ae5ab36bf8335f623b7bc6570f6ced05d
monero-gui-install-win-x64-v0.18.5.0.exe, 2aee0fb9a4a858199da46ce3344e7d6dec080efeab21c599903379e3e1d29dec
monero-gui-mac-x64-v0.18.5.0.dmg, 19c6a250c9ae68871a0c5ca7935dfe0eb3f1ddb468d6718b7c257aede096a254
monero-gui-mac-armv8-v0.18.5.0.dmg, 2fe562dd6ffb84941a4ff73412c234ebda8cb1831dec5ebbb217ea17d4288b92
monero-gui-linux-x64-v0.18.5.0.tar.bz2, 99d7e9b1e8084f09bdf837dd862ad96c47a86292bdbd6c2f6b3aaa46ff510b62

A GPG-signed list of the hashes is at https://www.getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid.

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.5.0 'Fluorine Fermi' released

Mon, 11 May 2026 00:00:00 GMT

Overview

This is the v0.18.5.0 release of the Monero software. This recommended release adds SOCKS v5 support, removes UPnP support, and includes a large number of bug fixes.

Some highlights of this release are:

Add SOCKS v5 support to daemon and wallet (#10411)
Daemon: remove UPnP support (#10465)
Daemon: fix shutdown hangs (#10494, #10401, #10489)
Daemon: improve exception handling (#10437, #10373)
Daemon: speed up transaction pool get_complement() for large requests (#10377)
Daemon: restrict add_aux_pow RPC (#10409)
ZMQ: add restricted RPC mode (#10389, #10420, #10425, #10469, #10504)
ZMQ: fix txpool transaction reporting for stem-phase transactions (#10399)
ZMQ: notify txpool event when stem transaction bumps to fluff (#10453)
Wallet: improve proof validation (#10480, #10471, #10481, #10473)
Wallet: add option to skip refresh after multisig import (#10402)
Wallet: add change address sanity check (#10431)
Wallet RPC: add source info to describe_transfer (#10380)
Wallet RPC: fix set_daemon allowed SSL fingerprints parsing (#10433)
Wallet RPC: restrict sensitive methods in --restricted-rpc mode (#10379, #10435)
Harden HTTP client authentication handling (#10364)
Add LoongArch build support (#10400)
Various bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 12 people who worked to put out 96 commits containing 2786 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
selsta
hinto-janai
jeetrex17
lschomaker1
nahuhh
fangyaling
SNeedlewoods
jeffro256
vtnerd
woodser
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.5.0.zip, 027d96a72d36663b6f5cbcc5b1564c65c628a9f8f2bb9b4d9859c03f741cabc4
monero-win-x86-v0.18.5.0.zip, ce0210583b1b4113d709bb432dde72c55b76c40ebbc7b5b4d4ae862b507632a1
monero-mac-x64-v0.18.5.0.tar.bz2, 79e03406046255d0f6a47e1fdcbbe677ab11ef7d9fcc4481252235361769292c
monero-mac-armv8-v0.18.5.0.tar.bz2, fb48fcef9302bf2f97821498ec791b4f693af4984702e72e588ce02209f8960d
monero-linux-x64-v0.18.5.0.tar.bz2, 166ad93036f95f5abeba24c8670061be022c9238dba2e6a7587611a1d759e294
monero-linux-x86-v0.18.5.0.tar.bz2, 57c63e067d7aefa69f74f44ef7f46091251512aba39570a7c8e26644d298eeb5
monero-linux-armv8-v0.18.5.0.tar.bz2, d8f19b947ce46d468615bb7331962d4ca732e79b1ac6c5128fa509df3f6cc487
monero-linux-armv7-v0.18.5.0.tar.bz2, dedaf94b765c428040f1b64e580e389206141fa2be72fd1394be0a8614f04f40
monero-linux-riscv64-v0.18.5.0.tar.bz2, 219112ffac9af48226dc6ec1fadc8a210a5876eeb7f3a32f3d3cbae842b52bf9
monero-android-armv8-v0.18.5.0.tar.bz2, 7321662959f917db85c3da1c0a37530d21fb5c25e2c9a2dc0490486842dec974
monero-android-armv7-v0.18.5.0.tar.bz2, ab5ab33899c5ac6806a0c1a24a3b01d46c291142f0983a8a184f93c8a3baca9f
monero-freebsd-x64-v0.18.5.0.tar.bz2, 0beb34bac944fdf02e2939fe320b9a6a5b26910cbf0a1a629b26be2aad50bace

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Deprecating Monero's Custom Transaction Unlock Time

Sun, 10 May 2026 00:00:00 GMT

Please be advised, the Custom Transaction Unlock Time feature is set to be deprecated at consensus with FCMP++. There is already a relay rule in place today that prevents nodes from accepting and relaying transactions with a Custom Unlock Time to the transaction pool (source). This is a formal announcement that the feature would be deprecated altogether with the FCMP++ fork, and new transactions with Custom Unlock Time set would not be able to enter the chain even if a miner mines them.

All transactions created after June 1, 2026, and with an Unlock Time set to unlock after the FCMP++ fork, would unlock immediately when the FCMP++ fork block hits the chain.

If we see a large influx of new Unlock Time transactions created between now and June 1, 2026, the feature may be deprecated earlier than June 1, 2026. Deprecating avoids complications with the FCMP++ wallet integration, enabling a smoother wallet experience for all users. Note that a FCMP++ fork date is not set at the time this is written.

This change will not affect transactions already created. If you, a user, created a transaction in the past with an Unlock Time set to a future date (even years from today), then you are not affected by this change. Your transaction will unlock based on the Unlock Time you set when you created the transaction. This change will only affect new transactions.

Why Deprecate?

The feature has caused a number of security, privacy, and fungibility issues over the years, and its known benefits do not outweigh its significant cons. Deprecating the feature has been discussed and supported for many years (see here, here, here, and here). Merchant software has neglected to check the Unlock Time on received Monero, and incorrectly assumed that the Monero received is spendable, leading to losses. Transactions with Custom Unlock Time stick out in the chain like a sore thumb, harming both privacy and fungibility. And the feature provides no known major benefit that is not achievable through some other means (for example, see Time-Lock Puzzles described in the PayMo paper).

It is a common misconception that Monero's Unlock Time is useful for known atomic swap or payment channel protocols. To date, no scheme has been specified that utilizes Monero's Unlock Time feature. Bitcoin's Hash Time Locked Contracts (HTLCs), for example, have unique capabilities that render them useful in atomic swap and payment channel protocols, that Monero's Unlock Time feature does not have.

FCMP++ capable wallets are slated to keep a rolling cache of locked Monero outputs, so that wallets will be able to construct FCMP++ transactions without revealing any identifying information about their own outputs to nodes. See more on the design here. The Unlock Time feature presents a Denial of Service vector because the cache could grow unbounded. Deprecating the feature now enables releasing FCMP++ capable wallets with no concern for this attack vector, enabling a smoother wallet experience for all users.

Monero GUI 0.18.4.7 'Fluorine Fermi' released

Wed, 04 Mar 2026 00:00:00 GMT

Overview

This is the v0.18.4.7 release of the Monero GUI software. This release contains bug fixes.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix GUI getting stuck during exit on macOS (#4558)
Fix lack of focus during password dialog (#4549)
Set password for temporary wallet during wizard wallet creation (#4556, #4571)
Improve blockchain size estimate accuracy (#4552)
Update Qt to 5.15.18 (#4565)
Update p2pool to v4.14 (#4570)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked to put out 29 commits containing 163 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
selsta
SChernykh
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.7.zip, b06dde8291aa03c4ac89efe19568c22eba2854af18a39163ed6d4a1fb88f1a20
monero-gui-install-win-x64-v0.18.4.7.exe, adf679471c5a619a6e1f484672c883de097ba55caecaf85a6b040d7190d38576
monero-gui-mac-x64-v0.18.4.7.dmg, 23a09caf2430f1e2b4809bd52ca2477de6acbe8db45890942975e757fb8096db
monero-gui-mac-armv8-v0.18.4.7.dmg, 5685e948ea070c4a7b9450a576da00b4037168b2f0645aa27437fa6d2e609095
monero-gui-linux-x64-v0.18.4.7.tar.bz2, 4573defcf21b0daeea0e9c7213540012c7d1186e829daf991fa8edfc5033dc08

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.6 'Fluorine Fermi' released

Wed, 04 Mar 2026 00:00:00 GMT

Overview

This is the v0.18.4.6 release of the Monero software. This release contains bug fixes.

Some highlights of this release are:

Daemon: fix bug in peer list filter (#10317)
Daemon: p2p connection bug fixes (#10298)
Multisig: fix key exchange failure in monero-gen-trusted-multisig (#10284)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked to put out 16 commits containing 197 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
selsta
binaryFate
vtnerd
woodser
0xFFFC0000
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.6.zip, 566601fde2c0c4684a7e99e5274100edea3c73ef3ca9de72d32ccd1c64fdea47
monero-win-x86-v0.18.4.6.zip, f164ef30f29ae80ece7b529edbe3c74694174b7f4204967dcc7ef5a855928308
monero-mac-x64-v0.18.4.6.tar.bz2, 1e07c0b672faa2664cc3708de44bab4083a320838dbf7c5582e31e7196bc1c78
monero-mac-armv8-v0.18.4.6.tar.bz2, c71f526012211eb83d7200cc072c3e4ddff637786a9d2ee267165abdd6aea541
monero-linux-x64-v0.18.4.6.tar.bz2, 60cfc32d39c6fe6c19b23513d02017fe9055d2e412ee4cbc30fa40ba811fe052
monero-linux-x86-v0.18.4.6.tar.bz2, 6b33c1f1ff0b5fd5bba6a87f204a464c575e3a230805582fe16db5247e2ff28c
monero-linux-armv8-v0.18.4.6.tar.bz2, d38c9ef8ee1a5d2de32f67d2f46c767c0c5cc3bb23ba7e3dfa9cbb19ceb2c84c
monero-linux-armv7-v0.18.4.6.tar.bz2, c4dbec17d1f25ef52f9a4832b8ba80b8818c8ed9adb786fa193ed38a019b1817
monero-linux-riscv64-v0.18.4.6.tar.bz2, 3ff6f636d875f5cc8a0e6972d8cca4204d1564f2c8ce60c295fa95439711868e
monero-android-armv8-v0.18.4.6.tar.bz2, 0fe77f999e5eb2d2961d062fb82909dc51c210384106f96c06059b4d572ad158
monero-android-armv7-v0.18.4.6.tar.bz2, e67c07dd2a4b2cb0150b125426d7f33c2c1680784de70b381ea099953353d30b
monero-freebsd-x64-v0.18.4.6.tar.bz2, 0ac63ad6a027da8de7ba33bed5a3ccbd7c8dd02027625fc315a8db48b327d849

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.4.5 'Fluorine Fermi' released

Wed, 07 Jan 2026 00:00:00 GMT

Overview

This is the v0.18.4.5 release of the Monero GUI software. This release fixes a bug with Ledger hardware wallet.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix Ledger Monero app crash (#4534)
Add support for Ledger Nano Gen5 (#4539)
Update P2Pool to v4.13 (#4543)
Improve macOS dark mode support (#4537)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, to put out 12 commits containing 25 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
SChernykh
plowsof
selsta
nabijaczleweli

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.5.zip, 9f3cf22fdb12cec1df6b1cb4cbe78d48457d68cbccdc46a82920a167885a988c
monero-gui-install-win-x64-v0.18.4.5.exe, 4d0cefe9d639bf2a31c02470c53d2f01c09d31165cedcc6eba184f1ccc7ed196
monero-gui-mac-x64-v0.18.4.5.dmg, aa1b818b7dea2a6315b7a25216e8661b5d4378d1823aa8747c8b39aac59232a0
monero-gui-mac-armv8-v0.18.4.5.dmg, 6b10e9336d9eb804f518a3815152e236ff5615fac3578a445500d92c572949c9
monero-gui-linux-x64-v0.18.4.5.tar.bz2, 6200d97615f23a3701c2cc51da3e9472ccd71561c259ca62f60030ef40ce785c

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.5 'Fluorine Fermi' released

Wed, 07 Jan 2026 00:00:00 GMT

Overview

This is the v0.18.4.5 release of the Monero software. This release fixes a bug with Ledger hardware wallet.

Some highlights of this release are:

Ledger: fix Ledger Monero app crash (#10234)
Ledger: add support for Ledger Nano Gen5 (#10243)
Daemon: fix race condition causing dropped connections during sync (#10257)
Wallet: fix edge case where key images remain marked unspent (#10255)
Improve terminal color detection (#10268)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked to put out 16 commits containing 76 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
plowsof
nahuhh
selsta
laanwj
iamamyth
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.5.zip, a58132eefdecf6bd5443ae52fc15c0c371499de17223667173e5c81d12bfc2c5
monero-win-x86-v0.18.4.5.zip, 6a0eff6b06fe9b1372a64744900bfe19b47a532b6678d6f7055c2de9999b58d1
monero-mac-x64-v0.18.4.5.tar.bz2, b92a2cebde86bf87ebcdfa9cab8e20ae4b3697798058c3de71945267f361a984
monero-mac-armv8-v0.18.4.5.tar.bz2, f6b91dd7cb06483941945e6a1dc455ed80360092c138a1d1af53dc31985bd8d8
monero-linux-x64-v0.18.4.5.tar.bz2, 423b49f3658e29f70a1d971667dec924c7ee7a107cfc93440456e28500b471a6
monero-linux-x86-v0.18.4.5.tar.bz2, 9960aba30ab2ffc3450a4865e707a60615661ae5c32f3b90da74f1c0a38e4bc0
monero-linux-armv8-v0.18.4.5.tar.bz2, a1667e15307f0dfce2f25f882238c432aee14884219ff0d0be07d7bee959a903
monero-linux-armv7-v0.18.4.5.tar.bz2, 42fbcbcf678794d6b104134bb7218093d6aa2764cc9cfa6fad404a4648a7c38a
monero-linux-riscv64-v0.18.4.5.tar.bz2, ed06d510dc53412362fa22a2149d709eb3b60f973583ebf33bbfbc9edc58f2ab
monero-android-armv8-v0.18.4.5.tar.bz2, 4d48830d0d6494b27bf1144b9546e5e7bccc7eef0f6991a16ae2bf6ac71a69d9
monero-android-armv7-v0.18.4.5.tar.bz2, 3cd6611c5c33ae4c10e52698826560bbb17e00cf2f8a2d7f61e79d28f0f36ef6
monero-freebsd-x64-v0.18.4.5.tar.bz2, a2e924a2293e1d0c192f6e50748dcbcbb58dd9d5ad2b6733ffccefad37c556cf

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.4.4 'Fluorine Fermi' released

Fri, 14 Nov 2025 00:00:00 GMT

Overview

This is the v0.18.4.4 release of the Monero GUI software. This is a recommended release that fixes a bug with Ledger hardware wallet when rejecting secret view key export.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix Ledger hardware wallet bug when rejecting secret view key export
Update P2Pool to v4.12 (#4519)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, to put out 6 commits containing 23 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
SChernykh
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.4.zip, b96faa56aa77cabed1f31f3fc9496e756a8da8c1124da2b9cb0b3730a8b6fbd9
monero-gui-install-win-x64-v0.18.4.4.exe, 4c81c8e97bd542daa453776d888557db1ceb2a718d43f6135ad68b12c8119948
monero-gui-mac-x64-v0.18.4.4.dmg, 811df70811a25f31289f24ebc0edc8f7648670384698d4c768bac5c2acbf2026
monero-gui-mac-armv8-v0.18.4.4.dmg, a6f071719c401df339dba2d43ec6fffe103fda3e1df46f354b2496f34bb61cc4
monero-gui-linux-x64-v0.18.4.4.tar.bz2, e45cb3fa9d972d67628cfed6463fb7604ae1414a11ba449f5e2f901c769ac788

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.4 'Fluorine Fermi' released

Fri, 14 Nov 2025 00:00:00 GMT

Overview

This is the v0.18.4.4 release of the Monero software. This is a recommended release that fixes a bug with Ledger hardware wallet when rejecting secret view key export.

Some highlights of this release are:

Ledger: make secret view key export mandatory (#10195)
Wallet: identify spends in pool when scanning (#10153)
Daemon: relay empty fluffy block on found block (#10206)
Daemon: correct txpool weight miscalculation in edge case (#10204)
Daemon: refine sync height selection logic (#10202)
Additional logging deadlock fixes (#10194)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked to put out 14 commits containing 286 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
0xFFFC0000
selsta
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.4.zip, 7eb3b87a105b3711361dd2b3e492ad14219d21ed8fd3dd726573a6cbd96e83a6
monero-win-x86-v0.18.4.4.zip, a148a2bd2b14183fb36e2cf917fce6f33fb687564db2ed53193b8432097ab398
monero-mac-x64-v0.18.4.4.tar.bz2, af3d98f09da94632db3e2f53c62cc612e70bf94aa5942d2a5200b4393cd9c842
monero-mac-armv8-v0.18.4.4.tar.bz2, 645e9bbae0275f555b2d72a9aa30d5f382df787ca9528d531521750ce2da9768
monero-linux-x64-v0.18.4.4.tar.bz2, 7fe45ee9aade429ccdcfcad93b905ba45da5d3b46d2dc8c6d5afc48bd9e7f108
monero-linux-x86-v0.18.4.4.tar.bz2, 8c174b756e104534f3d3a69fe68af66d6dc4d66afa97dfe31735f8d069d20570
monero-linux-armv8-v0.18.4.4.tar.bz2, b9daede195a24bdd05bba68cb5cb21e42c2e18b82d4d134850408078a44231c5
monero-linux-armv7-v0.18.4.4.tar.bz2, 2040dc22748ef39ed8a755324d2515261b65315c67b91f449fa1617c5978910b
monero-linux-riscv64-v0.18.4.4.tar.bz2, c939ea6e8002798f24a56ac03cbfc4ff586f70d7d9c3321b7794b3bcd1fa4c45
monero-android-armv8-v0.18.4.4.tar.bz2, eb81b71f029884ab5fec76597be583982c95fd7dc3fc5f5083a422669cee311e
monero-android-armv7-v0.18.4.4.tar.bz2, 7c2ad18ca3a1ad5bc603630ca935a753537a38a803e98d645edd6a3b94a5f036
monero-freebsd-x64-v0.18.4.4.tar.bz2, bc539178df23d1ae8b69569d9c328b5438ae585c0aacbebe12d8e7d387a745b0

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.4.3 'Fluorine Fermi' released

Wed, 08 Oct 2025 00:00:00 GMT

Overview

This is the v0.18.4.3 release of the Monero GUI software. This is a highly recommended release that enhances protection against spy nodes when using a local node.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add support for Ledger Flex (#4494)
Update Qt to 5.15.17 (#4498)
Update P2Pool to v4.11 (#4505)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, to put out 18 commits containing 61 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

luigi1111
tobtoht
SChernykh
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.3.zip, dc9531cb4319b37b2c2dea4126e44a0fe6e7b6f34d278ccf5dd9ba693e3031e0
monero-gui-install-win-x64-v0.18.4.3.exe, 7b9255c696a462a00a810d9c8f94e60400a9e7d6438e8d6a8b693e9c13dca9ab
monero-gui-mac-x64-v0.18.4.3.dmg, 27243b01f030fdae68c59cae1daf21f530bbadeaf10579d2908db9a834191cee
monero-gui-mac-armv8-v0.18.4.3.dmg, 68ea30db32efb4a0671ec723297b6629d932fa188edf76edb38a37adaa3528e6
monero-gui-linux-x64-v0.18.4.3.tar.bz2, 0bd84de0a7c18b2a3ea8e8eff2194ae000cf1060045badfd4ab48674bc1b9325

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.3 'Fluorine Fermi' released

Wed, 08 Oct 2025 00:00:00 GMT

Overview

This is the v0.18.4.3 release of the Monero software. This is a highly recommended release that enhances protection against spy nodes.

Some highlights of this release are:

Wallet: increase batch subaddress creation limit to match RPC (#10098)
Wallet: warn instead of throw when RingDB doesn't include spend (#10150)
Daemon: improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes' (#10113)
Daemon: add max_block_count field to getblocks.bin RPC request (#9901)
Daemon: send ZMQ miner notifications after txpool additions (#10104)
Daemon: seed node maintenance (#10105, #10112, #10115)
Daemon: fix on_getblockhash error return on too high height (#10125)
RPC: allow creating more than 64 addresses at once (#10096)
Fix logging deadlock (#10066)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 13 people who worked to put out 36 commits containing 253 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
vtnerd
0xFFFC0000
nahuhh
moneromooo
WeebDataHoarder
jeffro256
Gingeropolous
lalanza808
rbrunner7
hinto-janai
selsta
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.3.zip, bd9f615657c35d2d7dd9a5168ad54f1547dbf9a335dee7f12fab115f6f394e36
monero-win-x86-v0.18.4.3.zip, e642ed7bbfa34c30b185387fa553aa9c3ea608db1f3fc0e9332afa9b522c9c1a
monero-mac-x64-v0.18.4.3.tar.bz2, a8d8273b14f31569f5b7aa3063fbd322e3caec3d63f9f51e287dfc539c7f7d61
monero-mac-armv8-v0.18.4.3.tar.bz2, bab9a6d3c2ca519386cff5ff0b5601642a495ed1a209736acaf354468cba1145
monero-linux-x64-v0.18.4.3.tar.bz2, 3a7b36ae4da831a4e9913e0a891728f4c43cd320f9b136cdb6686b1d0a33fafa
monero-linux-x86-v0.18.4.3.tar.bz2, e0b51ca71934c33cb83cfa8535ffffebf431a2fc9efe3acf2baad96fb6ce21ec
monero-linux-armv8-v0.18.4.3.tar.bz2, b1cc5f135de3ba8512d56deb4b536b38c41addde922b2a53bf443aeaf2a5a800
monero-linux-armv7-v0.18.4.3.tar.bz2, 3ac83049bc565fb5238501f0fa629cdd473bbe94d5fb815088af8e6ff1d761cd
monero-linux-riscv64-v0.18.4.3.tar.bz2, 95baaa6e8957b92caeaed7fb19b5c2659373df8dd5f4de2601ed3dae7b17ce2f
monero-android-armv8-v0.18.4.3.tar.bz2, 1aebd24aaaec3d1e87a64163f2e30ab2cd45f3902a7a859413f6870944775c21
monero-android-armv7-v0.18.4.3.tar.bz2, 4e1481835824b9233f204553d4a19645274824f3f6185d8a4b50198470752f54
monero-freebsd-x64-v0.18.4.3.tar.bz2, ff7b9c5cf2cb3d602c3dff1902ac0bc3394768cefc260b6003a9ad4bcfb7c6a4

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

FCMP++ Optimization Competition Results

Wed, 27 Aug 2025 00:00:00 GMT

We held a contest to optimize two libraries used in Monero's proposed upgrade to FCMP++: helioselene and ec-divisors. We have officially declared the winners of the contest!

EC Divisors (250 XMR prize)

Winner: @fabrizio-m

Fabrizio sped up the divisors library by over 95%. You can see the excellent submission here.

ec-divisors is a library implementing the calculation of divisors of elliptic curve points. These lead to efficient verification of scalar multiplications, as posited by Liam Eagen. FCMP++ uses EC Divisors to improve efficiency generally. This competition was focused on optimizing divisor construction, which affects transaction construction.

Managing slow divisors construction was a pain point for the FCMP++ integration. Fabrizio's 95%+ improvement effectively renders divisors construction negligible. Thanks to Fabrizio, we can now significantly simplify the final FCMP++ integration, and improve the user experience.

helioselene (100 XMR 1st place prize, 30 XMR 2nd place prize)

1st place: @lederstrumpf
2nd place: @rafael-xmr

Lederstrumpf's submission achieved a weighted speed-up of 22% on an AMD Ryzen 5600G, and improved the weighted WASM cycle count by 39%. The judges unanimously declared Lederstrumpf's submission the winner! Lederstrumpf's submission was the strongest foundation to build on. You can see the excellent submission here. As of this writing, @kayabaNerve has already improved on the submission here.

helioselene is a library implementing two curves, "Helios" and "Selene," which form a curve cycle towering Ed25519. Using a "tower cycle" over Ed25519 allows Monero to re-use the existing anonymity set while upgrading to FCMP++. This library is a critical component used in all aspects of FCMP++. Optimizing this library will therefore benefit all user-facing components of FCMP++ (daemon sync, wallet sync, and transaction construction).

Although not part of the official contest rules, we decided to award a 2nd place prize to Rafael, since we unanimously agreed Rafael's submission was 2nd best. Had we not received a submission from Lederstrumpf, we would have had an excellent submission to fall back on here. As such, we sought to reward Rafael's strong effort.

We received a number of quality submissions to this contest, and want to thank all contestants for participating! You can read more on our rationale for selecting the winner here.

What we learned

Form stricter bounds on exactly what code can be modified

Some code in a repo required for tests / benchmarks to run might not be in scope of the competition. Be as clear about which code is out of scope as possible. Explicitly tell contestants that modifiying certain code will be disqualifying.

Form stricter API requirements

Similar to the previous point, be crystal clear about the requirements the API of the code must take on and if it should even be allowed to be modified. Preferably provide downstream code that the API must compile and function correctly with.

Present concrete architectures and toolchains for which the code must run in constant-time

Code runs in constant-time or doesn't on specific architectures and toolchains. For example, LLVM to x86 generates variable-time code for u128 arithmetic in Rust, but constant-time code on x86_64. Give contestants examples of specific toolchains and architectures for which the code must compile to constant-time.

Allocate time for review and 2nd phase

No matter how well you think you define the competition rules, there may be scenarios which crop up where there was widespread confusion about the rules. There may be multiple submissions which have a lot of good work in them, but are in the gray area of validity. A review phase allows judges to clarify rules with contestants and refine submissions, and planning for this ahead of time helps to avoid misunderstandings.

Allocate time for deadline extensions

This one is pretty self-explanatory. Sometimes you need a deadline extension for unforseen circumstances, so allocate time for it.

Make a policy for non-1st place prizes

In a situation where anonymous submissions are allowed, 2nd place prizes can be gamed very easily. Also, game theory states that for a lot of competitions, the best incentive structure is winner-take-all. However, in the case where two submitters are certainly distinct competitors, and both submissions are close in quality, a 2nd place prize may be warranted. This is doubly true when parts of the code of the non-1st place are to be used in production code. Allocate funds for this scenario before the competition, but make sure to clarify that awarding such a prize is strictly up to the judgement of the judges.

Clarify rules for vendored dependencies

If you want to make rules about dependencies in the competition, make sure to specify rules about heavily modified and/or vendored dependencies before the start of the competition.

Spend more time marketing competition in specific circles where people do code competitions

There was a lot of good outreach for the FCMP++ competition, but some of the most fruitful outreach was to circles where there are already a lot of people doing coding/crypto competitions, who aren't necessarily involved in the Monero sphere.

Make sure that submitters always license their code under a permissive license

MIT, BSD, or even GPL, etc.

Setup an optional direct channel of communication for the contestants

Before the competiton starts, setup an offical, but optional, method of communication that lets judges push rule updates, feedback, announcements, etc to contestants. Otherwise, scrambling to find and message each contestant gets hectic very quickly.

Post-Mortem of find_and_save_rings() bug

Tue, 26 Aug 2025 00:00:00 GMT

Quick Facts

Severity: HIGH if using untrusted remote daemon, MEDIUM otherwise
Affected versions: GUI/CLI wallet versions v0.12.0.0 to v0.18.4.1
Impact: Sends TXIDs of outgoing transactions to daemon after first time loading wallet from file, reducing sender anonymity
Fix: Update Monero CLI / GUI to v0.18.4.2
Workaround: TBD

Introduction

In 2018, a persistent "ring database" was added to wallet2 to solve a sender privacy problem with forks of Monero. If an enote was received before a fork occurs, and a wallet tries spending that enote after the fork occurs on both forks, the same key image will appear in the input to both of those transactions on the different forks. By necessity, one of the ring members must be the same between those two forks (the "true spend"). If no other ring members are shared between those two inputs, but both ring signatures verify correctly, then an external observer can pin which ring member is the "true spend". This destroys sender anonymity. To combat this, a ring database is populated in a user directory which maps spent key images to their ring signatures. Then, if a forked wallet tries to spend an enote already spent on another chain, it will lookup up ring signature data from the local ring database, and try to re-use as many decoys from that ring as possible. This reduces the sender anonymity risk for spending enotes across different forks.

There are basically three ways that the ring database can be populated: the ring indices from transactions can be added from 1) scanned outgoing transactions during a normal chain refresh 2) transactions submitted to the network from that wallet and 3) already-known outgoing transactions after explicitly fetching them from the daemon. The method tools::wallet2::find_and_save_rings() implemented the latter of the three schemes. Its purpose was to populate the ring database for already-existing wallets created before the v0.12.0.0 release after which rings were added during refresh, without having to rescan the whole blockchain. However, as it turns out, tools::wallet2::find_and_save_rings() was called more often than it should have given its niche purpose.

Reproducing

Here are steps to reproduce the privacy leak using the CLI wallet (assumes working daemon connection):

Create wallet (same-device keys, hardware wallet keys, multisig, etc), remember seed phrase if applicable
Receive an enote, spend said enote, wait 10 blocks
Delete (or move) wallet files, both keys and cache
Restore wallet and refresh before saving
Close wallet
(Optional) Open packet inspection software (e.g. Wireshark) and begin logging RPC traffic (using --daemon-ssl disabled helps here)
Re-open wallet
Daemon now has list of confirmed outgoing transactions ☹️
(Optional) If using packet inspection software, filter using the string gettransactions
To repeat, go to step 3

Technical explanation

tools::wallet2::find_and_save_rings() was called unconditionally when loading a wallet from file, inside wallet2::load(). However, it would return early if the member field m_ring_history_saved was equal to true. At the end of the call to tools::wallet2::find_and_save_rings(), m_ring_history_saved is set to true. However, initializing a wallet2 object sets m_ring_history_saved to false. This field, m_ring_history_saved, is also serialized into the wallet cache file. So, after a wallet's first load, if there are scanned outgoing transactions in the cache during the first save, m_ring_history_saved is set to false so tools::wallet2::find_and_save_rings() proceeds. It grabs all TXIDs from outgoing transactions (stored in field member m_confirmed_txs), and performs a /gettransactions RPC call with that list of TXIDs to the daemon, leaking its outgoing transaction history. The RPC call is made without discriminating whether the daemon is marked as trusted or not.

Let's say that you delete the cache file and keep keys file. Note that while tools::wallet2::find_and_save_rings() is still called on load, the /gettransactions RPC call is skipped since a missing cache file causes m_confirmed_txs to be empty. m_ring_history_saved is still set to true at the end of the call, and so the RPC call will never be made henceforth. So merely deleting the cache file won't trigger the vulnerability, the keys file also needs to not be present.

Vulnerability introduction commit (master branch): 5f146873
Vulnerability fix commit (master branch): dc350f35

Privacy implications with ring signatures

When the aforementioned RPC call is triggered, the daemon receives a list of TXIDs of your wallets outgoing transactions. If a malicious operator of said daemon knows the receiver of the outputs in the outgoing transactions, then the operator can tie that wallet as sending funds to a certain receiver. Furthermore, because of the current ring size and size of the the blockchain, the probability of selecting your own owned outputs as a decoy in your own ring signatures is small. As such, a smart malicous operator, with a list of your outgoing TXIDs, can inspect the ring members of your going transactions and cross-reference if any of the members are outputs of transactions in the TXID list. If so, the operator can guess with high accuracy that a certain change output was spent in a certain ring in a later outgoing transaction. This allows the operator to construct a probabilistic transaction graph, without amount information, for a wallet's funds after entering possession.

Monero GUI 0.18.4.2 'Fluorine Fermi' released

Tue, 26 Aug 2025 00:00:00 GMT

Overview

This is the v0.18.4.2 release of the Monero GUI software. This is a recommended release that fixes a privacy leak when using a malicious remote node.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix privacy leak with malicious remote node. For a detailed report, read Post mortem of find_and_save_rings() bug
Add background sync when locked functionality (#4050)
Update P2Pool to v4.9.1, fix Linux permission bug (#4490)
Add P2Pool nano sidechain (#4482)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, to put out 12 commits containing 290 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

luigi1111
tobtoht
nahuhh
j-berman
SChernykh
selsta
xihuwenhua

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.2.zip, 4daff8850280173d46464ba9a9de7f712228ad1ef76a1c4954531e4fd2b86d86
monero-gui-install-win-x64-v0.18.4.2.exe, 9d6e87add7e3ac006ee34c13c4f629252595395f54421db768f72dc233e94ea8
monero-gui-mac-x64-v0.18.4.2.dmg, 16abadcbd608d4f7ba20d17a297f2aa2c9066d33f6f22bf3fcdca679ab603990
monero-gui-mac-armv8-v0.18.4.2.dmg, 3dfee5c5d8e000c72eb3755bf0eb03ca7c5928b69c3a241e147ad22d144e00a7
monero-gui-linux-x64-v0.18.4.2.tar.bz2, e4fcdea3f0ff27c3616a8a75545f42a4e4866ea374fa2eeaa9c87027573358ea

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.2 'Fluorine Fermi' released

Tue, 26 Aug 2025 00:00:00 GMT

Overview

This is the v0.18.4.2 release of the Monero software. This is a recommended release that fixes a privacy leak when using a malicious remote node.

Some highlights of this release are:

Wallet: fix privacy leak with malicious remote node (#10015). For a detailed report, read Post mortem of find_and_save_rings() bug
Daemon: more accurate connection count (#10047)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked to put out 12 commits containing 39 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

tobtoht
cho-m
vtnerd
woodser
jeffro256
selsta
j-berman

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.2.zip, 14dd5aa11308f106183dd7834aa200e74ce6f3497103973696b556e893a4fef2
monero-win-x86-v0.18.4.2.zip, 934d9dbeb06ff5610d2c96ebe34fa480e74f78eaeb3fa3e47d89b7961c9bc5e0
monero-mac-x64-v0.18.4.2.tar.bz2, b1b1b580320118d3b6eaa5575fdbd73cf4db90fcc025b7abf875c5e5b4e335c1
monero-mac-armv8-v0.18.4.2.tar.bz2, 9b98da6911b4769abef229c20e21f29d919b11db156965d6f139d2e1ad6625c2
monero-linux-x64-v0.18.4.2.tar.bz2, 41d023f2357244ea43ee0a74796f5705ce75ce7373a5865d4959fefa13ecab06
monero-linux-x86-v0.18.4.2.tar.bz2, 03e77a4836861a47430664fa703dd149a355b3b214bc400b04ed38eb064a3ef0
monero-linux-armv8-v0.18.4.2.tar.bz2, a39530054dac348b219f1048a24ca629da26990f72cf9c1f6b6853e3d8c39a79
monero-linux-armv7-v0.18.4.2.tar.bz2, ecb2577499a3b0901d731e11d462d3fadcd70095f3ab0def0c27ee64dc56b061
monero-linux-riscv64-v0.18.4.2.tar.bz2, 18492ace80bf8ef2f44aa9a99b4f20adf00fd59c675a6a496211a720088d5d1a
monero-android-armv8-v0.18.4.2.tar.bz2, 3b248c3201f028205915403b4b2f173df0dd8bf47eeb268fd67a4661251469d3
monero-android-armv7-v0.18.4.2.tar.bz2, 6122f0bcaca12d5badd92002338847d16032f6d52d86155c203bcb67d4fe1518
monero-freebsd-x64-v0.18.4.2.tar.bz2, b4e2b7de80107a1b4613b878d8e2114244b3fb16397821d69baa72d9b0f8c8d5

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.4.1 'Fluorine Fermi' released

Fri, 25 Jul 2025 00:00:00 GMT

Overview

This is the v0.18.4.1 release of the Monero GUI software. This release contains bug fixes.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Update P2Pool to v4.8.1 (#4462)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 8 people who worked, to put out 22 commits containing 35 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

luigi1111
tobtoht
SChernykh
b4n6-b4n6
BaksiLi
spetterman66
CollinBartlam
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.1.zip, ab28f83f416ff21286bc2da88c6ba865d93397605f1ce51053435892b1342e89
monero-gui-install-win-x64-v0.18.4.1.exe, 29615bfbd10b4c46042c474b749f6e07836be30dd9bac6c32965064fcaf00d9b
monero-gui-mac-x64-v0.18.4.1.dmg, 4fd421b66af66a63be05bb289f5bb463d4bf763ad04722ec6794755498e65167
monero-gui-mac-armv8-v0.18.4.1.dmg, 9f0b5ae3732c7fc33dde5f662a78d0360f9b1e8dee47180e5b23cf9f0ce2a7d1
monero-gui-linux-x64-v0.18.4.1.tar.bz2, 60cbd662ccf1fdaf8732a21b6e505b806c6a4f62492c975fb1a13fd820dc8495

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.1 'Fluorine Fermi' released

Fri, 25 Jul 2025 00:00:00 GMT

Overview

This is the v0.18.4.1 release of the Monero software. This release contains bug fixes.

Some highlights of this release are:

Wallet: fix stale multisig data after failed refresh (#9911)
Wallet: fix a bug when changing password (#9945)
Wallet: apply subaddress lookahead changes immediately (#9954)
Wallet respect do-not-relay in sweep_single (#9978)
Daemon: improve logic when connecting to a peer (#9949)
Daemon: add new dynamic fees to ZMQ (#9958)
RPC: fix edge case causing unresponsive wallet (#9950)
RPC: add set_subaddresss_lookahead endpoint (#9954)
Add safeguard for rare exception in TCP accept handler (#9956)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 14 people who worked to put out 46 commits containing 459 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

0xFFFC0000
Tzadiko
jeffro256
j-berman
vtnerd
tobtoht
benevanoff
hinto-janai
luigi1111
nahuhh
selsta
MrCyjaneK
SNeedlewoods
rudolfschmidt

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.1.zip, c9612c399a957f4e6b9564cfec95ebf4f8b8864fef249b9edffd243fb05e45a0
monero-win-x86-v0.18.4.1.zip, bfebf4c0bcfd01cf8642457c7e27fd1c51058e38e8a439565d93340f40da6505
monero-mac-x64-v0.18.4.1.tar.bz2, dba3cd24f6d846f9df2221ddbfc26a503c1759dd908ad0af931ae62224d7a557
monero-mac-armv8-v0.18.4.1.tar.bz2, 6e6ae89a436ca02a033ce06e4389c810350f8f0a23292b95ae10ff4a30154817
monero-linux-x64-v0.18.4.1.tar.bz2, 702ccb799c24160c0c76676d7a5b21a7e3432be47294d20e0a75451592f591b2
monero-linux-x86-v0.18.4.1.tar.bz2, a36f57f7eeee15513cd51716a2f727fd84c7c1e5a8f48b30d69dd0b31aab4ee2
monero-linux-armv8-v0.18.4.1.tar.bz2, 948379e60e1b65e36bdfcc20481f2e381c49be057deb9fb5a2d030100f14d1e1
monero-linux-armv7-v0.18.4.1.tar.bz2, a080b9f703c9b09cb3713376d7679cda089e6772794bd0bfa994cb256b6f3535
monero-linux-riscv64-v0.18.4.1.tar.bz2, 9120062277e37bb8b6dcf816fdcf4fb34a8f4c4c530ba1162bba7d7fc3c10e0a
monero-android-armv8-v0.18.4.1.tar.bz2, 918c10de18a125de407e8b984bd84000da354e994a13a18ee8d0af11c0870c22
monero-android-armv7-v0.18.4.1.tar.bz2, 02442c33b1a130da915b7901615c402d43c0b41be555197d8cec9bfcc78ea1c4
monero-freebsd-x64-v0.18.4.1.tar.bz2, e290c78c7989559ba4a6964ed83f574ecc81b9bc9640dad306ed576a6f812f30

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

OSPEAD - Optimal Ring Signature Research

Sat, 05 Apr 2025 00:00:00 GMT

TL;DR

New research reveals the timing of Monero spending patterns in probabilistic form. The research could be used to improve Monero user privacy in the future. In the meantime, Monero users with extreme threat models should be aware that anti-privacy adversaries can leverage timing information to increase the probability of guessing the real spend in a ring signature to approximately 1-in-4.2 instead of 1-in-16.

Introduction

Four technologies protect the privacy of Monero users. Dandelion++ protects users' IP addresses from being linked to their transactions. Confidential transactions hide the amount of value that is transferred between users. Monero's stealth address technique produces one-time-use addresses on the blockchain that cannot be linked to specific wallets without voluntary disclosure of view keys. Ring signatures obfuscate which stock of coins was spent in a transaction by combining the real spend with 15 decoy spends. This blog post discusses improvements and threats to Monero's ring signature privacy model.

As the name implies, a "decoy" serves its purpose well if it looks like the real thing. Decoys that do not match the spending patterns of real users will fail to draw the attention of an anti-privacy adversary. One of the most important spending patterns to match is the timing. The age of a stock of coins that a user spends, like units of physical paper currency circulating between consumers and merchants, forms a random probability distribution.

Monero's current decoy selection algorithm is based on research by Möser et al. (2018)[^4], which used de-anonymized transactions in the first three years of Monero's history whose real spend was known due to inadequate safeguards in the protocol. In 2017, the protocol safeguards were strengthened to thwart the techniques used by Möser et al. (2018)[^4]. As a result, de-anonymized transactions could no longer be used to update the decoy selection distribution to align it with the real spend distribution. Another way forward was needed.

The research

Several peer-reviewed research articles suggested that near-optimal privacy for a given ring size could be provided by using a decoy distribution that closely mimics the real spend distribution (Aeeneh et al. 2021 [^1]; Kumar et al. 2017 [^3]; Möser et al. 2018 [^4]; Ronge et al. 2021 [^6]). However, some of the same papers doubted that the real spend distribution could be estimated reliably when only anonymized data was available. Rucknium, a researcher with the Monero Research Lab, proposed a method to directly estimate the real spend distribution using the ring signature data on the Monero blockchain. Members of the Monero community generously donated to fund the research plan, known as Optimal Static Parametric Estimation of Arbitrary Distributions (OSPEAD).

OSPEAD works by chaining together two statistical techniques. First, the Bonhomme-Jochmans-Robin estimator separates the distribution of rings that use the "standard" decoy selection algorithm from the distributions of rings that use decoy selection algorithms of "third-party" wallet software (Bonhomme, Jochmans, & Robin 2016).[^2] Next, the Patra-Sen inversion estimator is used to separate the decoy distribution from the real spend distribution (Patra & Sen 2016).[^5] Note that the OSPEAD research has not yet been formally peer-reviewed.

Producing a reliable estimate of the real spend age distribution is a double-edged sword. It provides great privacy when implemented in a decoy selection algorithm, yet it also enables an anti-privacy adversary to more easily guess the real spend when the actual decoy selection algorithm used by users is very different from the real spend distribution.

Privacy risk

As stated above, Monero's current decoy selection algorithm is based on data from the first three years of Monero's history when the number of transactions per day was less than 10 percent of current (2025) transaction volume. Real spending patterns have changed since 2017, yet the decoy selection algorithm has changed little.

The Maximum A Posteriori (MAP) Decoder attack, first described in hypothetical form by Aeeneh et al. (2021)[^2], leverages the difference between Monero's real spend distribution and its decoy distribution. Using the MAP Decoder attack and the real spend distribution estimated in the OSPEAD research, an anti-privacy adversary has a 1-in-4.2 probability of correctly guessing the real spend at current ring size of 16.

Users should consider the following metaphor to understand the mechanics of the attack. There are 16 horses scheduled for a race. The horses are not equally fast. According to the betting markets, one of the horses has a 1-in-4.2 probability of winning. The MAP Decoder attack does not remove 12 out of the 16 horses from the race, and then randomly pick among the remaining 4 with equal probability. Instead, it always bets on the one horse that is most likely to win. It wins the bet (guesses correctly) in 1 out of 4.2 races.

Let's continue the analogy of the horse race bettor. Did they pick the winning horse (the real spend)? Unlike a normal race, we usually don't learn the outcome (if the guess was correct). This limits the impact of the attack in practice, especially since the best guess is incorrect the majority of the time, on average.

Put another way, if you guess the real spend in 4 Monero rings, you will have guessed 1 of those correctly (on average), but you don't know which of those guesses is correct. Is that useful information? That depends on the standard of evidence of the adversary.

Probabilistic guessing can create elevated privacy risk to users with extreme threat models such as those targeted by blockchain surveillance firms, especially when combined with other de-anonymizing attacks. Interested users are encouraged to read the OSPEAD GitHub repository, where code and documents are released under open source licenses.

Developments to come

The OSPEAD-derived decoy selection distribution could be deployed to mitigate the risk of the MAP Decoder attack. However, a Monero network upgrade (hard fork) would be required for safest deployment. A network upgrade, though necessary for major improvement to Monero, is disruptive to the Monero ecosystem. The costs may outweigh the benefits.

Currently, the next expected hard fork is set to deploy Full-Chain Membership Proofs, which eliminate the weaknesses of the ring signature privacy model.

References

[^1]: Aeeneh, S., Chervinski, J. O., Yu, J., & Zlatanov, N. (2021), New Attacks on the Untraceability of Transactions in CryptoNote-Style Blockchains. Paper presented at 2021 IEEE International Conference on Blockchain and Cryptocurrency (ICBC).

[^2]: Bonhomme, S., Jochmans, K., & Robin, J.-M. (2016). Non-parametric estimation of finite mixtures from repeated measurements, Journal of the Royal Statistical Society. Series B (Statistical Methodology), 78(1), 211–229.

[^3]: Kumar, A., Fischer, C., Tople, S., & Saxena, P. (2017), A Traceability Analysis of Monero’s Blockchain. Paper presented at European Symposium on Research in Computer Security (ESORICS).

[^4]: Möser, M., Soska, K., Heilman, E., Lee, K., Heffan, H., & Srivastava, S., et al. (2018). An Empirical Analysis of Traceability in the Monero Blockchain, Proceedings on Privacy Enhancing Technologies, 2018(3), 143–163.

[^5]: Patra, R. K., & Sen, B. (2016). Estimation of a two-component mixture model with applications to multiple testing, Journal of the Royal Statistical Society. Series B (Statistical Methodology), 78(4), 869–893.

[^6]: Ronge, V., Egger, C., Lai, R. W. F., Schröder, D., & Yin, H. H. F. (2021). Foundations of Ring Sampling, Proceedings on Privacy Enhancing Technologies, 2021(3), 265–288.

Monero GUI 0.18.4.0 'Fluorine Fermi' released

Sat, 05 Apr 2025 00:00:00 GMT

Overview

This is the v0.18.4.0 release of the Monero GUI software. This is a recommended release that fixes multiple daemon-related network vulnerabilities.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix "Create Wallet" button getting stuck in some cases (#4351)
Fix testnet wallet detection (#4411)
Update P2Pool to v4.4 (#4417)
Update Qt to 5.15.16 (#4377)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, to put out 40 commits containing 106 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

luigi1111
tobtoht
SChernykh
plowsof
Malinero
preland
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.4.0.zip, 38a0066fb2f1bea788cbb54377a6921c168a04c2e8fdf83e9245bf4f84dbc502
monero-gui-install-win-x64-v0.18.4.0.exe, 57cd67da191c02590a4f011b8c659db6603f53d8497237f6d737fc7053361bf6
monero-gui-mac-x64-v0.18.4.0.dmg, ae5cf12ba8c608e32ea8d59181f032666840e034031a95406b6771d7709984b8
monero-gui-mac-armv8-v0.18.4.0.dmg, d10e4c150180c6c241f7a76a573ee296b50682722c124a50de01403eea462b5b
monero-gui-linux-x64-v0.18.4.0.tar.bz2, e276f9e67396515f671a08c5438fb1db4358c9d8946ec7ef79b9dda552092ad7

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.4.0 'Fluorine Fermi' released

Sat, 05 Apr 2025 00:00:00 GMT

Overview

This is the v0.18.4.0 release of the Monero software. This is a recommended release that fixes multiple daemon-related network vulnerabilities.

Some highlights of this release are:

Wallet: add background sync with just the view key (#8617)
Wallet: fix a potential sync issue during restore (#9601)
Wallet: flush confirm prompt before user input (#9657)
Daemon: reduce disk writes from 2 to 1 per transaction (#9740)
Daemon: fix a remote P2P crash vulnerability [reported by Kevin McSheehan]
Daemon: add configuration options to HTTP server, fix a remote RPC crash (#9775)
Daemon: fix temp fails causing alt blocks to be permanently invalid (#9400)
Daemon: allow comments in ban list file (#9616)
Daemon: fix daemon connection speed throttling incorrectly (#9460)
Daemon: fix --anonymous-inbound data leak (#9633)
Daemon: check for Windows NTFS compression (#9702)
Daemon: fix database size detection on Windows (#9705)
Daemon: update seed nodes (#9793)
RPC: add daemon-specific proxy support in set_daemon RPC call (#9590)
RPC: fix an issue where the wallet state does not save on close (#9615)
RPC: validate IP parameter in set_bans RPC call (#9703)
RPC: add RPC call to get default fee priority (#9788)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 17 people who worked to put out 124 commits containing 5607 new lines of code. We'd like to thank them very much for their time and effort. In no particular order, they are:

nahuhh
0xFFFC0000
Tzadiko
jeffro256
j-berman
vtnerd
tobtoht
luigi1111
eversinc33
jaredmo
iamamyth
woodser
bgermann
plowsof
tankf33der
selsta
nsec1

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.4.0.zip, 00151a96e96ef69eedf117c4900e6d0717ca074a61918cd94a55ed587544406b
monero-win-x86-v0.18.4.0.zip, 249a4247688c30ce95e8fb04ff656e97a4f8de83c31c58e7debb28dbcc2d2867
monero-mac-x64-v0.18.4.0.tar.bz2, c35a4065147f8eeaa130a219e12e450fb55561efe79ded7d935fbfe5f7ba324c
monero-mac-armv8-v0.18.4.0.tar.bz2, 9d36ec8a1da1f31d654a8fd8527f4cae03545d8292bb1a2fe434ca454b3c0976
monero-linux-x64-v0.18.4.0.tar.bz2, 16cb74c899922887827845a41d37c7f3121462792a540843f2fcabcc1603993f
monero-linux-x86-v0.18.4.0.tar.bz2, e00863e81b8b7473c46c461a3a45d09f09347c1a048da093ae0bf86db0f44355
monero-linux-armv8-v0.18.4.0.tar.bz2, f252b6a24e801535bf36fbaaa7b2d6ae44b1efc5d427803d483e3c3a17d6f2cd
monero-linux-armv7-v0.18.4.0.tar.bz2, b35b5e8d27d799cea6cf3ff539a672125292784739db41181b92a9c73e1c325b
monero-linux-riscv64-v0.18.4.0.tar.bz2, a0c0a807b90af1dd71faafbe2e66e4fda43210c2f11f8aa3514ccaedd268a0b3
monero-android-armv8-v0.18.4.0.tar.bz2, 0b976b241c45a75a9c428a531e8259e0e67c237f980ac46e19a3180b5c1dbf91
monero-android-armv7-v0.18.4.0.tar.bz2, 70ded1197db3fffa150e9f5c4eee0129026be8ea24190bad43a42f4748b5e5bd
monero-freebsd-x64-v0.18.4.0.tar.bz2, 55b1ae7d6622b3da4f81f56ab8da1854caa36150b91b3639c1485b73f42208e8

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

FCMP++ Optimization Competition

Sat, 05 Apr 2025 00:00:00 GMT

Officially announcing a contest to optimize two libraries used in Monero's proposed upgrade to FCMP++: helioselene and ec-divisors. Read all contest rules and details here.

The winner for helioselene will receive 100 XMR, and the winner for ec-divisors will receive 250 XMR. This Monero will be paid out from the Monero General Fund.

The contest will open for submissions Monday, April 28th and will stop accepting submissions Monday, June 30th.

Why

ec-divisors is a library implementing the calculation of divisors of elliptic curve points. These lead to efficient verification of scalar multiplications, as posited by Liam Eagen. FCMP++ uses EC Divisors to improve efficiency generally. This competition is focused on optimizing divisor construction, which affects transaction construction.

Who can participate

We will accept submissions from anyone (including anonymous users) provided that the submission meets all competition rules. If you have experience optimizing cryptographic libraries and/or are interested in contributing to Monero, here is as good of a chance as any!

Where

Please visit this link to read all the details on the contest, including rules, how to get started, and how to make a submission.

Monero GUI 0.18.3.4 'Fluorine Fermi' released

Tue, 20 Aug 2024 00:00:00 GMT

Overview

This is the v0.18.3.4 release of the Monero GUI software. This release adds support for Trezor Safe 5.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add support for Trezor Safe 5 (#4332)
Enable pruning by default (#4320)
Allow @ in OpenAlias domain (#4308)
Fix stagenet restore height estimation (#4310)
Fix an edge case with desktop entry (#4300)
Update P2Pool to v4.1 (#4334)
Update Qt to 5.15.14 (#4321)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 22 commits containing 28 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
tobtoht
SChernykh
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.3.4.zip, b5d42dddd722e728e480337f89038c8ea606c6507bf0c88ddf2af25050c9b751
monero-gui-install-win-x64-v0.18.3.4.exe, 63349d5a7637cd0c5d1693a1a2e910a92cbb123903d57667077a36454845d7bf
monero-gui-mac-x64-v0.18.3.4.dmg, 54eb151d7511a9f26130864e2c02f258344803b2b68311c8be29850d7faef359
monero-gui-mac-armv8-v0.18.3.4.dmg, eedbf827513607a3ef579077dacd573e65892b199102effef97dff9d73138ca6
monero-gui-linux-x64-v0.18.3.4.tar.bz2, 2866f3a2be30e4c4113e6274cad1d6698f81c37ceebc6e8f084c57230a0f70a6

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.3.4 'Fluorine Fermi' released

Tue, 20 Aug 2024 00:00:00 GMT

Overview

This is the v0.18.3.4 release of the Monero software. This release removes support for locked transfers.

Some highlights of this release are:

Remove support for locked transfers (#9311)
Daemon: skip privacy networks that don't have outgoing connections (#9267)
Daemon: prevent duplicate txs in fluff queue, fix unintended disconnections (#9355)
Daemon: ZMQ DaemonInfo bug fixes (#9385)
Wallet: fix stagenet wallet restore height estimate (#9309)
Wallet: add Ledger Flex support (#9430)
Fix a bug with log rotation mechanism (#9396)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 8 people who worked, largely unpaid and altruistically, to put out 39 commits containing 535 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

0xFFFC0000
j-berman
vtnerd
tobtoht
Boog900
luigi1111
selsta
jeffro256

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.3.4.zip, 54a66db6c892b2a0999754841f4ca68511741b88ea3ab20c7cd504a027f465f5
monero-win-x86-v0.18.3.4.zip, 1a9824742aa1587023c3bddea788c115940cfd49371c78a8dd62c40113132d01
monero-mac-x64-v0.18.3.4.tar.bz2, 32c449f562216d3d83154e708471236d07db7477d6b67f1936a0a85a5005f2b8
monero-mac-armv8-v0.18.3.4.tar.bz2, 44520cb3a05c2518ca9aeae1b2e3080fe2bba1e3596d014ceff1090dfcba8ab4
monero-linux-x64-v0.18.3.4.tar.bz2, 51ba03928d189c1c11b5379cab17dd9ae8d2230056dc05c872d0f8dba4a87f1d
monero-linux-x86-v0.18.3.4.tar.bz2, d7ca0878abff2919a0104d7ed29d9c35df9ca0ea1b6fb4ebf6c8f7607ffb9e41
monero-linux-armv8-v0.18.3.4.tar.bz2, 33ca2f0055529d225b61314c56370e35606b40edad61c91c859f873ed67a1ea7
monero-linux-armv7-v0.18.3.4.tar.bz2, 354603c56446fb0551cdd6933bce5a13590b7881e05979b7ec25d89e7e59a0e2
monero-linux-riscv64-v0.18.3.4.tar.bz2, 88739a1521b9fda3154540268e416c7af016ed7857041c76ab8ed7d7674c71ca
monero-android-armv8-v0.18.3.4.tar.bz2, d9c9249d1408822ce36b346c6b9fb6b896cda16714d62117fb1c588a5201763c
monero-android-armv7-v0.18.3.4.tar.bz2, 15e4d7dfc2f9261a0a452b0f8fd157c33cdbc8a896e23d883ddd13e2480a3800
monero-freebsd-x64-v0.18.3.4.tar.bz2, 360a551388922c8991a9ba4abaa88676b0fc7ec1fa4d0f4b5c0500847e0b946c

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Privacy Advocates and Hackers to Gather for Annual Monero Conference & Hackathon in Prague

Thu, 23 May 2024 00:00:00 GMT

Monero Konferenco (also known as "MoneroKon") brings together global privacy advocates, cypherpunks, and leading scientists to discuss advancements in privacy and financial technology. The conference and hackathon is to take place at the renowned Paralelní Polis in Prague, Czech Republic from 7th-9th June 2024.

The conference will include presentations and workshops on:

Human Rights and the Blockchain
Cryptocurrency Laws and Regulations
Unique privacy-preserving cryptographic methods
Novel implementations of zero-knowledge cryptographic schemes
Social and economic philosophies that promote the ideals of liberty and decentralisation

For the full published schedule, see: schedule.monerokon.org

Tickets can be purchased at: tickets.monerokon.org

The first ever Monero hackathon encourages hackers to build any app, or improve upon code, related directly, or indirectly, to Monero core codebase, or the greater Monero ecosystem for a chance to win prizes and bounties.

Apply to hack here: hack.monerokon.org

Press passes are available for members of the media who intend to cover the conference; please contact conference organisers to obtain one.

For additional information, contact the MoneroKon Organizing Team at orga@monerokon.org

OFTC/Libera.Chat IRC

#monerokon

Related Links

Official Website: monerokon.org
X: x.com/MoneroKon
Mastodon: mas.to/@monerokon
Signal Public Group: signal.monerokon.org
Matrix: matrix.monerokon.org
Past Events: Denver 2019, Lisbon 2022, Prague 2023

Full-Chain Membership Proofs Development

Sat, 27 Apr 2024 00:00:00 GMT

Full-Chain Membership Proofs, as a concept, is a replacement for rings within the Monero protocol. While rings have offered sender privacy to Monero since it launched, they're vulnerable to attacks such as the EAE attack, have difficulties upon chain reorganizations, and in general enable statistical analysis (mitigated by distribution of the decoy selection algorithm). Full-Chain Membership Proofs prove the output spent is one of any output on the chain, effectively removing all of these risks. This means every input goes from an immediate anonymity set of 16 to 100,000,000.

Two proposals have been made for Monero offering such privacy, both under the "Full-Chain Membership Proofs" moniker (further mentions acronymed to "FCMPs"). The first was announced at MoneroKon in 2023, and was intended to be deployed with/after Seraphis. Seraphis distinguished between "membership", the output spent is one of some outputs, and "spend authorization", the output being spent is authorized by the private key holder. With that, much more efficient proofs for membership became possible, including the "Grootle" proofs it was originally proposed with (effectively a ring of 128). FCMPs further improved upon this, requiring Seraphis's new key/transaction format to do so.

The second proposal was made in March of 2024 in response to the spam attacks ongoing at the time. "FCMPs+SA+L", later shortened to simply "FCMP++s", independently adds "Spend Authorization + Linkability", removing the dependency of Seraphis. With further research and development, it was found to add several new features to the Monero protocol, without requiring the migration to Seraphis. These features include,

Transaction Chaining

Transaction chaining allows signing a transaction spending another transaction, before the spent transaction is published and mined on-chain. This enables certain layer-two designs for Monero (such as some payment channel protocols).

Outgoing View Keys

Outgoing view keys allow anyone with the outgoing view key to detect when received outputs are spent. Currently, Monero only offers incoming view keys, which do allow detecting spends with extremely high likelihood over the current protocol, yet don't provide 100% certainty. This certainty will make cold wallet setups and multisignature wallets much more efficient, having to bring the private key online far less often. It also allows defining a single "view key", without delineation of "incoming" or "outgoing", simplifying wallet UX.

Forward Secrecy

Forward secrecy means an adversary with a discrete log oracle, such as an adversary with a quantum computer, cannot break the privacy of the protocol.

While Seraphis also introduces all of these features, it does so with a migration to a new anonymity set and a new address format (invalidating all prior addresses). The FCMP++ proposal not only aims to be faster to deploy yet to do so without the migration. This is enabled by the trade-off of not actually offering any of this functionality at launch however.

The deployed protocol would support all of these features. The wallet code to take advantage of it would be delayed, ensuring that we keep our scope small and achieve the largest goal, full sender privacy, as soon as possible. Wallets could then start taking advantage of these features on their own timeline, without further hard forks nor privacy issues. This would likely be done by merging the Seraphis codebase into Monero, taking advantage of its years of development and improved design. With that, the migration to the new key structures would be optional, and if so, the work done for FCMP++s would provide most of the necessary work for FCMPs with Seraphis.

FCMP++s are based off Curve Trees, and to make the overall proof much more efficient, Eagen's work with elliptic curve divisors. The overall composition has been largely specified, and is currently being reviewed and further detailed as appropriate. The development of the composition was funded, and an earmarked fund for academic review and auditing is still raising. If you are a member of the academic community and are interested in contributing, please feel free to reach out within the Monero Research Lab on IRC or Matrix.

Monero GUI 0.18.3.3 'Fluorine Fermi' released

Wed, 13 Mar 2024 00:00:00 GMT

Overview

This is the v0.18.3.3 release of the Monero GUI software. This release fixes connecting to password protected nodes.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix fix connecting to password protected nodes (#4291)
Update Qt to 5.15.13 (#4290)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 4 commits containing 6 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
tobtoht
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.3.3.zip, 8333757a142112bef13f50576cf7b62db8ab7c11617ea742567e9bafb28b51fb
monero-gui-install-win-x64-v0.18.3.3.exe, c78a41dfcbb3544fafb173ddea5f945166cd58a203eda5ae6db173e39fc2959b
monero-gui-mac-x64-v0.18.3.3.dmg, a7777e1ca4a8ba3621cb6f79bafd160c93914f7250b739e33c846e1f9b8634c4
monero-gui-mac-armv8-v0.18.3.3.dmg, cd745209d328dddc9a4deb3073aad40144f9d544970bdada1789cc5b5cbef0e5
monero-gui-linux-x64-v0.18.3.3.tar.bz2, 893c3986583814b048f1109ba1047c8fe2bbe5ecd7687fe767c1b70ec2571e52

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.3.3 'Fluorine Fermi' released

Wed, 13 Mar 2024 00:00:00 GMT

Overview

This is the v0.18.3.3 release of the Monero software. This release fixes connecting to password protected nodes.

Some highlights of this release are:

Wallet: fix connecting to password protected nodes (#9238)
Add support for RISC-V update notifications (#9229)
Rename trunc_amount back to amount in ECDH tuple field (#9244)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 8 commits containing 30 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
jeffro256

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.3.3.zip, a35e96680543d1385a9958940bc64a8effd41594599a504e02f95bb6018f0d1c
monero-win-x86-v0.18.3.3.zip, a8248e46a7e72a483507c11243227c1d0335cca0b109860b6c1c570e32cb57a6
monero-mac-x64-v0.18.3.3.tar.bz2, 34b01bc4466bd1294f7b2403da5bd61e3ec4a8ceff52ca5f5d506261368b8b94
monero-mac-armv8-v0.18.3.3.tar.bz2, c59aca8a5ecc1c97df0288bf79a3110201a30530fb4d685c0ea2f9a64c1adafe
monero-linux-x64-v0.18.3.3.tar.bz2, 47c7e6b4b88a57205800a2538065a7874174cd087eedc2526bee1ebcce0cc5e3
monero-linux-x86-v0.18.3.3.tar.bz2, b1dd19a12d764f2e9fc8e4dc9d172da13e11020b609765849b98248eef509763
monero-linux-armv8-v0.18.3.3.tar.bz2, eb3f924c085ae5df85f5bf9ee27faaa20acd309835684e27e3fbb98b9666b649
monero-linux-armv7-v0.18.3.3.tar.bz2, f3f982b141cb6c88939d15a83aaa26334d628c0d2766d6834371030dd00401d3
monero-linux-riscv64-v0.18.3.3.tar.bz2, b54dcedd901c69c81144f952dd8d844da9f2f07c6c37c89977a056f5555b35aa
monero-android-armv8-v0.18.3.3.tar.bz2, dee23cedc25183f6fe864911f357edb0b0fed514eaf79e01096fe27c00a8d996
monero-android-armv7-v0.18.3.3.tar.bz2, 9be3c50b6d9080a9a90ed3dff48678102cfe7bdded4a0d4932184b1da2ca4373
monero-freebsd-x64-v0.18.3.3.tar.bz2, d9a3df4e287e7b622bcf33b8ad186aad65b41973f1de053208f1e6203e7ab986

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.3.2 'Fluorine Fermi' released

Sat, 09 Mar 2024 00:00:00 GMT

Overview

This is the v0.18.3.2 release of the Monero GUI software. This is a recommended release that fixes automatic fee selection.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix automatic fee selection (#4283)
Add support for Trezor Safe 3 (#4255)
OpenAlias domains starting with a digit can now be recognized (#4243)
Fix Tails detection (#4281)
Fix a crash on macOS ARM (#4283)
Update Qt to 5.15.12 (#4261)
Update p2pool to v3.10 (#4260)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 35 commits containing 198 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
tobtoht
selsta
SChernykh
inson1
sausagenoods

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.3.2.zip, 42f14a477524e60b7fb6addef8b18f6a99a0008755c56aaa0628fd611a7f6909
monero-gui-install-win-x64-v0.18.3.2.exe, e6a1f267d6e07ee72576bc942cfa74c7eeaa47b73a5d30291eb03e722448b79e
monero-gui-mac-x64-v0.18.3.2.dmg, 8f18d3a63f0f52c6ae61de1881e420c6c8c2bf3296084c3d30b529430cdd9896
monero-gui-mac-armv8-v0.18.3.2.dmg, 3c48b77e0b5258350a40d8cf23c2f6fda56a7ba0193fc368473ce1e0bf59342f
monero-gui-linux-x64-v0.18.3.2.tar.bz2, 98772e56afe5509ed4bd3d36ee2ea3c70c019cb4325c18d3508291fcdc784d4f

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.3.2 'Fluorine Fermi' released

Sat, 09 Mar 2024 00:00:00 GMT

Overview

This is the v0.18.3.2 release of the Monero software. This is a recommended release that adds support for RISC-V and contains important bug fixes.

Some highlights of this release are:

Add RISC-V (riscv64) support (#9029)
Daemon: multiple ZMQ bug fixes (#9053, #9080)
Daemon: disable ports with I2P (#9142)
Daemon: fix a bug that causes transactions to remain in the txpool (#9226)
Daemon: fix --max-txpool-weight feature (#9226)
Daemon: avoid slow fee RPC call response in edge cases (#9188)
Wallet: adjust fee during backlog when set to default (#9220)
Wallet: fix set priority getting ignored during transfers (#9220)
Wallet: transfer amount with fee included (#8945)
Wallet: mitigate statistical dependence for decoy selection within rings (#9130)
Wallet: ensure transfers and sweeps use same fee calc logic (#9022)
Wallet: better errors for small malformed multisig key exchange mesages (#9039)
Wallet: fix multisig key memory leak (#9051)
Add a workaround for a GCC compiler bug in JH hash (#9043)
Add support for NO_COLOR environment variable (#9047)
Reduce number of network packets sent for small HTTP bodies (#9020)
Update RandomX to 1.2.1, fix a potential crash on macOS ARM (#9027)
Update OpenSSL to 3.0.13, unbound to 1.19.1 (#9178)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 12 people who worked, largely unpaid and altruistically, to put out 65 commits containing 996 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

SChernykh
moneromooo
luigi1111
selsta
Crypto City
tevador
woodser
jeffro256
j-berman
vtnerd
tobtoht
0xFFFC0000

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.3.2.zip, 61ae870024036f2000eaa0da72dfddbbfc494d7c0b9432ef656183e6ba3978cf
monero-win-x86-v0.18.3.2.zip, c84d94208cfdcd6af9ec541f8b2ea66fcfc8911c56dd21d7e313e8384c45b205
monero-mac-x64-v0.18.3.2.tar.bz2, 994d4ef86dde41ef6c61083806a8a2e4ae5c37cd56375f24e950c8765368e236
monero-mac-armv8-v0.18.3.2.tar.bz2, 1e43364b18edd2be913f80cd9ed4c7c42d61873c9557486a4c59b74366a1c5a0
monero-linux-x64-v0.18.3.2.tar.bz2, 9dafd70230a7b3a73101b624f3b5f439cc5b84a19b12c17c24e6aab94b678cbb
monero-linux-x86-v0.18.3.2.tar.bz2, 9857719c4dc35c3e38a7289b49f890d25ad62aba44a82fbcde194db1720d5cb2
monero-linux-armv8-v0.18.3.2.tar.bz2, 72f5c90955a736d99c1a645850984535050ebddd42c39a27eec1df82bd972126
monero-linux-armv7-v0.18.3.2.tar.bz2, 5df3a1390960c1632c797b8dfb46e93ebb2e93498e4e5e517be0bda6ff5b719b
monero-linux-riscv64-v0.18.3.2.tar.bz2, 43bcb395cff51d90016bd34d75c7a339b1f0c3ea369b2258057d2b8ef972df81
monero-android-armv8-v0.18.3.2.tar.bz2, 7598672d552af3b711c3811683315c9661ff4c8059574afbbbf57abb71d029cd
monero-android-armv7-v0.18.3.2.tar.bz2, e61bf3d80de1d7ce92074570ce4d87316f7083de338e92d83f8987b4e3f4496d
monero-freebsd-x64-v0.18.3.2.tar.bz2, 0a07ff7697dad610d7b65ad7f2b083e4a50ce2d9c56736d20823786540840abc

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

CLSAG security proof revisions

Fri, 08 Mar 2024 00:00:00 GMT

TL;DR: A recent review conducted by Cypher Stack identified issues with CLSAG formal security proofs, and proposed fixes. These fixes don't affect the Monero implementation of CLSAG, so users are not at risk, and no action needs to be taken.

The Monero transaction protocol uses CLSAG, a linkable ring signature construction, to authorize transactions. The CLSAG preprint and implementation were written by Monero contributing researchers and developers, and improve on an earlier design, MLSAG.

The Zano team recently engaged Cypher Stack, an applied cryptography consultancy, to review d/v-CLSAG, their generalization of CLSAG. This generalization is intended to accommodate different types of transactions that the Zano protocol supports, but retains much of the original CLSAG design and security model. Because of this, as part of Cypher Stack's review of d/v-CLSAG, aspects of the original CLSAG preprint were reviewed as well.

Cypher Stack identified two issues with formal security proofs that also apply to CLSAG, and proposed updates to the proofs and protocol description to address them. Neither the existing Monero implementation of CLSAG nor the in-progress Zano implementation of d/v-CLSAG is affected by these issues, so users are not at risk and no action needs to be taken. Despite no vulnerabilities resulting from the findings, Cypher Stack responsibly disclosed the findings to Monero contributing researchers.

The review report, which details the findings, is available. While it is quite technical in nature, we encourage interested researchers and others to read it.

The first finding applying to CLSAG concerns an argument in an unforgeability proof that references an earlier signature design, LSAG. The argument in LSAG fails to identify an implicit requirement that certain parts of verification equations be nonzero. While the argument is somewhat more subtle in CLSAG and d/v-CLSAG, there are several ways it can be addressed. Both the Monero and Zano implementations already check that certain values in verification are nonzero, so they are not affected by this finding.

The other finding that applies to CLSAG deals with another technical aspect of the unforgeability proof relating to how the proof reduces to a certain discrete logarithm hardness problem. Essentially, the proof shows that if there existed a way to forge a CLSAG signature, there would be a way to break a cryptographic problem that is widely believed to be infeasible. Because of the way certain operations in the proof are performed, the method of analysis does not formally hold. The review proposes a modification to the security proof that uses a different, and more standard, hard cryptographic problem instead. Making this change doesn't affect the CLSAG protocol or any implementations, but ensures the formal proof is fixed.

Formal analysis in applied cryptography is challenging and subtle, and it's not uncommon to discover issues in security proofs. Cypher Stack hopes these findings, and the proposed proof updates, will be useful to the ecosystem.

Onward!

Community Crowdfunding System wallet incident

Sat, 04 Nov 2023 00:00:00 GMT

During a routine transfer, we noticed the 'Community Crowdfunding System' (CCS) main wallet was drained of 2,675.73 XMR (the entire balance) on September 1, 2023. The secondary wallet, used for payments to contributors, is untouched; its balance is ~244 XMR. We have thus far not been able to ascertain the source of the breach. An internal investigation is ongoing and further details will be released once we have them.

The General Fund (which remains intact) will be used to cover this loss. Contributors with in-progress CCS proposals will remain unaffected.

Further details and discussion can be found on this issue on GitHub.

Monero GUI 0.18.3.1 'Fluorine Fermi' released

Sat, 07 Oct 2023 00:00:00 GMT

Overview

This is the v0.18.3.1 release of the Monero GUI software. This release adds support for macOS ARM.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add macOS ARM support
Display error when Scan Transaction is used on older tx via untrusted daemon (#4051)
Add image when Ledger Stax is selected in wizard (#4146)
Add more detailed P2Pool failure messages, fix a rare crash (#4147)
Update Qt to 5.15.10 (#4143)
Update p2pool to v3.7 (#4219)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 10 people who worked, largely unpaid and altruistically, to put out 60 commits containing 605 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
tobtoht
j-berman
Botspot
plowsof
Dvd-Znf
web3d3v
BigmenPixel0
selsta
SChernykh

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.3.1.zip, f263ce5863fd87ea959f79420e28ef0002649fa02bd57ae34efda926bdcf1a70
monero-gui-install-win-x64-v0.18.3.1.exe, 792271147ad71a2eaa02fc37d61d72cd92f2f9857dcc09ea032f48481f87e279
monero-gui-mac-x64-v0.18.3.1.dmg, 8ae53f0908f9bc03452f23d5092bf1eb1d2ad9f1224580486b486cf0a2020401
monero-gui-mac-armv8-v0.18.3.1.dmg, b0c8d07f8d8ade49d08419b196ddb9f691717ef05cae066e220db707e4dfedc4
monero-gui-linux-x64-v0.18.3.1.tar.bz2, 06f6e600db51205116d52522964cf9b96337d7b5cb1e101730ccb0039b30e15b

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.3.1 'Fluorine Fermi' released

Sat, 07 Oct 2023 00:00:00 GMT

Overview

This is the v0.18.3.1 release of the Monero software. This release optimizes wallet refresh and contains important bug fixes.

Some highlights of this release are:

Optimize wallet refresh by reducing periodic RPC calls (#8800)
Daemon: handle case where a command line flag is not allowed in the config file (#8766)
Daemon: ensure base fee cannot reach 0 (#8851)
Daemon: fix high CPU usage on some systems by properly terminating interrupted TCP connection (#8900)
Daemon: drop peers sending duplicate transactions (#8916)
Daemon: fix a bug with the long-term block weight cache (#9014)
Wallet: improve rescanning with scan_tx (#8566)
Wallet: do not use DNS to determine if address is local (#8878)
Wallet: fix frozen function in multisig wallets (#8953)
Wallet: wallet save and password change related code improvements (#8938, #8999)
RPC: return ID of submitted block (#8891)
RPC: allow restore from multisig seed (#8942)
RPC: add --no-initial-sync flag, chunk refresh to keep responding while refreshing (#8941)
Speed up perf_timer init on x86, reduce monero startup delay by 1s (#8895)
Fix RandomX initialization when mining from scratch (#8831)
Fix amount overflow detection on 32-bit systems (#8844)
Update openssl to 1.1.1u (#8883)
Add CLSAG serialization to ZMQ (#8908)
Set SSL SNI even when server verification is disabled (#8899)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 12 people who worked, largely unpaid and altruistically, to put out 64 commits containing 2557 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

SChernykh
Boog900
moneromooo
luigi1111
selsta
jeffro256
woodser
j-berman
rbrunner7
vtnerd
tobtoht
almalh

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.3.1.zip, 35dcc4bee4caad3442659d37837e0119e4649a77f2e3b5e80dd6d9b8fc4fb6ad
monero-win-x86-v0.18.3.1.zip, 5bcbeddce32b50ebe18289d0560ebf779441526ec84d73b6a83094f092365271
monero-mac-x64-v0.18.3.1.tar.bz2, 7f8bd9364ef16482b418aa802a65be0e4cc660c794bb5d77b2d17bc84427883a
monero-mac-armv8-v0.18.3.1.tar.bz2, 915288b023cb5811e626e10052adc6ac5323dd283c5a25b91059b0fb86a21fb6
monero-linux-x64-v0.18.3.1.tar.bz2, 23af572fdfe3459b9ab97e2e9aa7e3c11021c955d6064b801a27d7e8c21ae09d
monero-linux-x86-v0.18.3.1.tar.bz2, c8553558dece79a4c23e1114fdf638b15e46899d7cf0af41457f18bbbee83986
monero-linux-armv8-v0.18.3.1.tar.bz2, 445032e88dc07e51ac5fff7034752be530d1c4117d8d605100017bcd87c7b21f
monero-linux-armv7-v0.18.3.1.tar.bz2, 2ea2c8898cbab88f49423f4f6c15f2a94046cb4bbe827493dd061edc0fd5f1ca
monero-android-armv8-v0.18.3.1.tar.bz2, 6d9c7d31942dde86ce39757fd55027448ceb260b60b3c8d32ed018211eb4f1e4
monero-android-armv7-v0.18.3.1.tar.bz2, fc6a93eabc3fd524ff1ceedbf502b8d43c61a7805728b7ed5f9e7204e26b91f5
monero-freebsd-x64-v0.18.3.1.tar.bz2, 3e2d9964a9e52c146b4d26b5eb53e691b3ba88e2468dc4fbfee4c318a367a90e

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Post-Mortem of 10-Block-Old Decoy Selection Bug

Thu, 08 Jun 2023 00:00:00 GMT

Quick Facts

Severity: HIGH
Affected versions: GUI/CLI wallet versions v0.13.0.2 to v0.18.2.1
Impact: Loss of sender anonymity for transactions spending funds exactly 10 blocks old
What to do: Update to v0.18.2.2 and above

Introduction

When the Monero wallet needs to construct a @transaction with a certain input, it also picks decoys inputs from the chain (@ring-signature) based on a certain distribution called a "gamma distribution". The gamma distribution makes picking recent decoys more likely than picking older decoys, mimicking how real users spend their funds. However, in the gamma picker code, there was a off-by-one bug that didn't allow the gamma picker to pick decoys which are exactly 10 blocks old.

The wallet can, however, still spend owned outputs that are exactly 10 blocks old. This means that an external observer can guess the true spend of an input ring with very high likelihood if one of the ring members is exactly 10 blocks old.

This bug has been patched in v0.18.2.2 and it is recommended that all users update their wallets as soon as possible. Since many third-party wallet applications rely on the core "wallet2" code, if you do not use the Monero Core CLI/GUI wallets, ask the development team of your wallet if they have upgraded to the new wallet2 code.

Upgrading your wallet to v0.18.2.2 will not only improve your sender anonymity, but will increase the anonymity pool for all other users, including those using the older vulnerable wallet code.

Technical Explanation

Large portions of the text below are copied directly from j-berman's "Post-Mortem of Decoy Selection Bugs" in 2021

More In-Depth Background

The decoy selection algorithm is designed to select outputs from across the blockchain based on observed spending patterns, as recommended in Moser et al. The paper's analysis uses spending patterns from earlier versions of Monero - where in some cases, the real outputs used in transactions could be deduced with certainty - in order to arrive at a distribution of Monero user spending patterns.

The paper highlights that users were more likely to spend outputs received relatively quickly than they were to spend outputs held for a long time. The paper then recommends factoring in the observed spending patterns when selecting outputs from across the blockchain to use as decoys, rather than apply an equal probability to the entire set of outputs from across the blockchain. This way, newer outputs would be more likely to be selected as decoys than older outputs, thus better obfuscating which output is real in users' transactions.

When the paper's recommendation was first implemented in Monero v0.13.0.0, the wallet correctly applied the observed spending pattern from the tip of the blockchain when selecting decoys. However, when the algorithm was upgraded in v0.14.1.0, the algorithm applied the observed spending pattern from 10 blocks prior to the chain tip. This was done because outputs younger than 10 blocks old are locked and cannot be spent, therefore it seemed logical to apply the distribution starting 10 blocks prior to the chain tip so as to only consider spendable outputs.

The Off-By-One Bug

Before picking decoys for a new transaction, the wallet grabs the cumulative distribution of outputs across the blocks for the entire chain using the RPC command /get_output_distrubution.bin. To prevent the gamma picker from picking decoys from blocks that are younger than ten blocks, an "end" pointer is calculated which bounds the chain information that the gamma picker considers. You can see that the calculation does not consider the last 10 blocks (the block unlock time) of chain information. However, since a newly created transactions will not enter the current highest block, but the next future block, the newest information considered at the time of transaction construction is actually 11 blocks older than the next future block (which ostensibily a new transaction will reside in).

However, wallets will still construct transactions with owned ring members that are exactly 10 blocks old. If all wallets adhere to this flawed logic, then the only time an 10-block old ring member will show up in a transaction is if it is the true spend. This heuristic would be devastating for sender anonymity with 10-block old true spends.

The bug was patched in PR #8794.

Empirical Analysis

The graph you see above shows how much 10-block-old ring members vs 11-block-old ring members appeared in transactions over time. The blue line represents the percent of transaction ring members on-chain that are exactly 10 blocks old over time, with yellow representing the same for 11-block-old ring members. The dashed green line shows the ratio between these two values over time.

There are a few interesting patterns, but the most relevant to this analysis is the spike in 10-block old ring member usage after the v0.18.2.2 release, the first wallet release with the bug fixed, as well as the increase in ratio between these two ages.

Since there is currently no way for the core dev team to track wallet version usage, there isn't any readily available data on the proportions of users using old wallets versus new wallets, information which would help establish correlation in the 10-block old ring member data.

However, such a noticeable spike in the number of 10-block old ring member usage coinciding precisely when the patched release was launched suggests that this patch did statistically alter decoy selection for young ring members.

Also, thankfully, the data tells a more complex story than our worst-case heuristic scenario. There were still a lot of 10-block old ring member usage before the bug was patched, likely due to custom wallet software. This makes the deanonymization heuristic less potent than originally anticipated.

Conclusion

Not to beat a dead horse, echoing j-berman in his original decoy selection bug post-motem: "anyone with a background in statistics and probability theory is encouraged to join in discussions geared toward improving the algorithm." In hindsight, this bug could have been discovered if the statistical distributions had been analyzed carefully.

Instead, the bug was stumbled upon by accident while attempting to fix an infinite while loop during decoy selection. This brings me to a second point which I think is important but may be controversial: the wallet2 decoy selection code needs to be completely rewritten. The wallet2::get_outs function is over 600 lines long, with few comments and inadequate testing.

Seeing as how the important decoy selection is to the privacy model of Monero, the code which actually implements this functionality in most wallets is of substandard quality. There are a lot of great ongoing discussions relating to decoy selection like non-coinbase-only selection for non-coinbase, coinbase consolidation transactions, ring binning, etc.

And while Monero has always been forward focused, it has also been more grounded and battle-tested as compared to other more experimental privacy-preserving coins. This only happens through the hard work and dedication of community members peering over the code and hardening it. Feel free to join the IRC/Matrix channels listed on the Monero Hangouts or Workgroups page to participate and communicate more with existing community members.

Monero GUI 0.18.2.2 'Fluorine Fermi' released

Tue, 04 Apr 2023 00:00:00 GMT

Overview

This is the v0.18.2.2 release of the Monero GUI software. This release adds support for Ledger Stax.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add support for Ledger Stax (#4130)
Update p2pool to v3.2 (#4142)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 16 commits containing 20 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
tobtoht
selsta
SChernykh

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.2.2.zip, 770eb381e1eb3490113c1edac67a92506e0b027daa1de8486b8d5fac3b4def54
monero-gui-install-win-x64-v0.18.2.2.exe, 165c183a7490cfe04a8296e05ad592e3e08705c879bd9facf2dab16a6ef2cf05
monero-gui-mac-x64-v0.18.2.2.dmg, 0b676d21b8133830b8446744382ae7c8b51d0e228713184d70100721504bdd4c
monero-gui-linux-x64-v0.18.2.2.tar.bz2, 027707b0ad740908c26895e3bf569ca284a813263129fe2635049313c5129230

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.2.2 'Fluorine Fermi' released

Tue, 04 Apr 2023 00:00:00 GMT

Overview

This is the v0.18.2.2 release of the Monero software. This release adds a size limit for tx_extra in tx pool.

Some highlights of this release are:

Daemon: add a size limit for tx_extra in tx pool (#8784)
Daemon: avoid log entries when re-blocking a subnet (#8787)
Daemon: fix deadlock and crash when syncing with full dataset on Windows (#8811)
Daemon: don't drop peers for soft offenses (#8813)
Wallet: fix infinite loop in fake out selection (#8801)
Wallet: add Ledger Stax support (#8779)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 21 commits containing 814 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

SChernykh
tevador
moneromooo
luigi1111
selsta
jeffro256
fbeutin-ledger

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.2.2.zip, 964c13f5d596289d2ab8ba9e265ff1e255a06269cf8fd216187d7b77a11c1371
monero-win-x86-v0.18.2.2.zip, b7366408e74b321aa5fa3993187a862d93dc41cbc43dc585f82fc17a4c423ded
monero-mac-x64-v0.18.2.2.tar.bz2, 8043a681155bf0339dc2eac1feb93d03295bd68c9bb5b472600fa5b1439ba68d
monero-mac-armv8-v0.18.2.2.tar.bz2, b6acf2716e6474d329d4c0bdf3b797299e4e789758f631bafa3930b613e3643c
monero-linux-x64-v0.18.2.2.tar.bz2, 186800de18f67cca8475ce392168aabeb5709a8f8058b0f7919d7c693786d56b
monero-linux-x86-v0.18.2.2.tar.bz2, c0999191b57156fc7b4e7e64fe50ffdf16781bae0ebc12c96c41b2c60bdee79f
monero-linux-armv8-v0.18.2.2.tar.bz2, f3867f2865cb98ab1d18f30adfd9168f397bd07bf7c36550dfe3a2a11fc789ba
monero-linux-armv7-v0.18.2.2.tar.bz2, 11b70a9965e3749970531baaa6c9d636b631d8b0a0256ee23a8e519f13b4b300
monero-android-armv8-v0.18.2.2.tar.bz2, c9d4889ff3f2c01e34f3beb3ab640fd73a535cc715ae8db591fd23724be0401c
monero-android-armv7-v0.18.2.2.tar.bz2, ec7b9913d048bec79ec7f7320df03e1f9c7ee015a051d8509e2d4ed33ddf3301
monero-freebsd-x64-v0.18.2.2.tar.bz2, 187f58410b5aac866f7200bb1e4244ba1940b51db772d33374dfa748f30c11a7

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.2.0 'Fluorine Fermi' released

Sun, 26 Feb 2023 00:00:00 GMT

Overview

This is the v0.18.2.0 release of the Monero GUI software. This release has a redesigned wallet creation UI and adds support for the upcoming P2Pool network upgrade. This upgrade is not mandatory to use the Monero network unless you use P2Pool, but it is recommended.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Update P2Pool to 3.0, add support for the upcoming P2Pool network upgrade (#4112)
Redesign seed page, ask for seed confirmation on wallet creation (#3878)
Android: disable local node usage (#4043)
Fix creating view only wallet from existing wallet
Take priority into account when estimating fee
Take dataDir into account when sending cmd to avoid creating log file (#4047)
Update Qt to 5.15.8 (#4103)
Update hidapi to 0.13.1 on Linux and Windows (#4109, #4120)
Add open folder button after CSV export (#4077)
Skip proxy when setting localhost remote node (#4085)
Override desktop theming to fix UI bugs with KDE (#4091)
P2Pool: restart monerod only when needed and with proper args (#3936)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 9 people who worked, largely unpaid and altruistically, to put out 64 commits containing 1403 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
ufUNnxagpM
SChernykh
2l47
Malinero
devhyper
selsta
rating89us
plowsof

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.2.0.zip, 94d49925c43ff117c4a93e462afe8529079fb54fcce3965419ec4e0f3e7de22b
monero-gui-install-win-x64-v0.18.2.0.exe, abf8048cca55145052ae870128bfe5b0bfc9e33edc5aa1c8cf64db850da1bfdd
monero-gui-mac-x64-v0.18.2.0.dmg, 7d1fdc850fb2a89983520b7b581f65e7bdfb4bbcd22d3b8637c5ed03af876334
monero-gui-linux-x64-v0.18.2.0.tar.bz2, 1b9d4938a82876466c9c047b3c9c22c41d777aea8ad207ef348a7bb39b382b61

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.2.0 'Fluorine Fermi' released

Sun, 26 Feb 2023 00:00:00 GMT

Overview

This is the v0.18.2.0 release of the Monero software. This release contains various bugfixes as well as improvements to block propagation time.

Some highlights of this release are:

Daemon: add RingCT cache for huge block propagation speedup (#8676)
Daemon: refactored rx-slow-hash, add MONERO_RANDOMX_FULL_MEM env var to force use the full dataset for PoW verification (#8678)
Daemon: fix back ping to discover healthy peers to connect to (#8641)
Daemon: fix Dandelion++ fluff/stem bug with local transactions (#8628)
Daemon: fix exclusive node DNS resolution for certain hosts (#8644)
Daemon: cleanup and add new seed nodes (#8721)
Wallet: update hidapi/libusb dependencies, fix Trezor connectivity issues on Windows (#8714)
Fix monero-blockchain-stats omits data from final day (#8723)
Update OpenSSL to 1.1.1t (#8738)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 11 people who worked, largely unpaid and altruistically, to put out 44 commits containing 865 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

SChernykh
j-berman
vtnerd
woodser
LocalMonero
UkoeHB
luigi1111
selsta
jeffro256
tobtoht
hyc

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.2.0.zip, 112c0647baaa5c7e42f8b121ad633222f608200f9a402dbf2b5cd6b95ee555cd
monero-win-x86-v0.18.2.0.zip, dac24fa46581987041ea3e9d89d745c643afab23a6d74385cdddd1231fe92514
monero-mac-x64-v0.18.2.0.tar.bz2, 25965adf64e20b1fc7e6b4c8839390de90eb2ec702b7fc07271be81ae592bd5c
monero-mac-armv8-v0.18.2.0.tar.bz2, 46e793b1401e3b3b1d7308bacede021ec45af7df70e277530079386abb3915da
monero-linux-x64-v0.18.2.0.tar.bz2, 83e6517dc9e5198228ee5af50f4bbccdb226fe69ff8dd54404dddb90a70b7322
monero-linux-x86-v0.18.2.0.tar.bz2, 22e73cfe0bd8fbd37f9e74b8e3ed78d4682a7c2489b30ba00cd3e70644dfefc2
monero-linux-armv8-v0.18.2.0.tar.bz2, fb20eaf9b04020abdf883eb339258814742a1452653c1f5d8705d16e90413f35
monero-linux-armv7-v0.18.2.0.tar.bz2, 1312afd0dde3262ff89554e278c0130c0ced6bdbeec8bf614fbb40bd03c6a0d2
monero-android-armv8-v0.18.2.0.tar.bz2, 29ea258ff6c213b276dd97432f3ba7f03834c5a3c6787a16af36d15544b60c44
monero-android-armv7-v0.18.2.0.tar.bz2, d72064d7df1ed0e4f5d37eca69a457cb56bb505c32e1a48f4d25480aaecfe1ce
monero-freebsd-x64-v0.18.2.0.tar.bz2, 0647ebc921315d3e2c31de7e1ba6d3bd9f42b582f7b0d2761a61375291cf3307

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Developer Opportunities at the Monero Project

Thu, 02 Feb 2023 00:00:00 GMT

Overview

Monero is a cryptocurrency started in 2014. It's often called a privacy coin: Transaction senders, receivers and amounts are all not visible to outsiders on the blockchain, in stark contrast to most other cryptocurrencies, including Bitcoin. However, many proponents do not primarily see privacy as an end in itself but something that is needed for Monero for being able to function as a true electronic version of cash. For an introduction see What is Monero.

The Monero dev community is currently implementing two brand-new technologies called Seraphis and Jamtis to improve privacy further and add functionality. According to some still very rough estimates those may be ready to bring into service with a hardfork in 2 years' time. Quite a lot of new code needs to get implemented, and a lot of existing code modified and adjusted; it's probably the biggest single coding related project for the currency ever.

Does that sound like something you may want to work on? Can you write sophisticated C++ code, or are you able to learn to do so "on the job", and ready to work as a member of an open source dev team? Then please have a closer look.

There is no company behind the Monero Project to manage dev work; it's an open source project as true as they get nowadays. It doesn't depend on VC companies openly involved in financing either that could force the project into directions that benefit themselves more than the Monero users. "Meritocracy" may be pretty grand and a bit overused as a concept, but if your work has merit you will get your code merged into software that is used to manage a cryptocurrency with a market valuation in the billions of USD.

Project Background

Monero came into existence in 2014 when a group of 7 devs forked the code of a cryptocurrency called Bytecoin to start a new, independent blockchain with a fresh genesis block. Its starting point was therefore a moderately large C++ codebase built from scratch since maybe 2011 to implement a new privacy coin technology called CryptoNote for the first time.

Over time many features and privacy enhancements were added, and today the code has grown to maybe something like tripple original size. Given how many different people worked on the code for many years already, and given the true open source style of development where nobody can just dictate things, the code is still in reasonable shape. There are nevertheless parts with a size and a complexity that makes them struggle to fit within the original framework that still largely stands.

We have developer documentation, but unfortunately there is nothing that documents the overall code structure, or the hierarchy of classes, or gives a high-level overview of the functionality. This together with the fact that C++ is not the easiest of programming languages when it comes to understand a large codebase makes it a bit difficult for new devs to find their way around; but on the other hand the "culture" among the devs is very welcoming and supporting to people who are serious to contribute.

You find the project on GitHub. The most important repository is the one with the core software, e.g. the Monero daemon that spans up the network and manages the blockchain, see its repository. You find the "places to be" like the dev-oriented Libera.chat IRC channel #monero-dev on the "Hangouts" page.

Seraphis and Jamtis

A group of Monero devs started to work on two brand-new and sizeable technologies called Seraphis and Jamtis which will improve the privacy of Monero transactions further and will solve many problems regarding current functionality. Those devs get support from the inventor of Seraphis, UkoeHB, and the inventor of Jamtis, Tevador. The resulting cryptocurrency will be quite different from today's Monero, although existing users will be offered a seamless upgrade path, and funds from all the way back to 2014 remain fully spendable indefinitely.

Over the course of about one year UkoeHB built a library that implements all the cryptography behind Seraphis and contains code to create transactions. You find it in UkoeHB's repository.

Work has now started on the so-called Seraphis wallet that will make heavy use of the Seraphis library. wallet in this context does not mean an app that end users run to manage their XMR, but that component of the Monero core code that such apps will build on. The main functionality of that component: Reading and writing wallet files that contain keys and all owned outputs, scanning the blockchain for incoming transactions, building new transactions and submitting them to the network.

The current plan is to fully replace wallet2, the existing component doing all this. This will require a lot of adjustments in the rest of the Monero core codebase, and of course reworking all wallet apps that depend on it. For more details check the wiki.

Financial Matters

There is no company behind the Monero Project, it has no employees: Devs seeking more or less conventional employment best look elsewhere. It does not actively seek venture capital either. Monero runs on contributions from people that basically work "for free", and on donations from the broader community to finance larger tasks.

One of these funding methods is the CCS, the Community Crowdfunding System. You can find more details on the website.

Basically anybody can write a proposal for it, and if it gets positive feedback it moves to the funding stage where of course success depends on whether donators will find the proposed work and goal worthwhile.

Realistically however it's pretty hard to get a proposal accepted if you are all new to Monero, nobody in the community knows you yet and you have never contributed anything so far. Much is about trust and demonstrated abilities, as it typically is the case in open source projects.

The CCS has a long history of successfully funded and executed tasks.

Another option for funding Monero related work is the MAGIC Monero Fund. Its nature is quite different from the CCS as it's a USA-registered 501(c)(3) charity. This enables tax-deductible (for citizens of the USA) donations in a variety of methods, and the option of USD-denominated payouts. There is also an additional requirement that fund recipients must verify their identity. The CCS allows its fund recipients to remain anonymous, yet only handles XMR.

Conclusion

There will be a lot of interesting work for devs that want to join the Monero project, for a long time. It may be a bit unusual as a "place" to work at, and for getting rich probably look elsewhere, but on the other hand think about it: Where else can you make a difference for a multi-billion-dollar venture that may become important in the future and make a difference, whoever you are, from wherever you are, regardless of education, only based on your knowledge and your willingness to make useful contributions?

Monero GUI 0.18.1.2 'Fluorine Fermi' released

Thu, 29 Sep 2022 00:00:00 GMT

Overview

This is the v0.18.1.2 release of the Monero GUI software. This release fixes an incorrect error message while being disconnected from a node.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix a bug that causes the wallet to display "wrong version"
Improve behavior when switching nodes (#4036)
Use different colors for different subaccounts (#4040)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 16 commits containing 87 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
j-berman
Malinero
rating89us

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.1.2.zip, c57cd8f27dacf64a11a4f86911a99116ab54438c37c87fb7ccb3c616d9a64b6a
monero-gui-install-win-x64-v0.18.1.2.exe, c5dbf3e8fca7341dea1194e57b22f233ceb9471aca8692da6ffd0b4bc3a54a1b
monero-gui-mac-x64-v0.18.1.2.dmg, 0e2e79471ffcc25b939de1937d54610510eaed0cbb19bbdc21a7aa64a2e9ec73
monero-gui-linux-x64-v0.18.1.2.tar.bz2, 1f9406044434eea770f1548a5bad5708f326f7295fb7c12d6c607ff783018a08

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.1.2 'Fluorine Fermi' released

Thu, 29 Sep 2022 00:00:00 GMT

Overview

This is the v0.18.1.2 release of the Monero software. This release contains bugfixes and improvements to multisig.

Some highlights of this release are:

Wallet: add an option to force-update multisig key exchange (#8582)
Wallet: fix a bug that would display a "wrong version" warning (#8585)
Daemon: second thread pool for IO (#8577)
Daemon: move update_checkpoints() DNS call to a later stage (#8588)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 13 commits containing 296 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
SChernykh
j-berman
UkoeHB
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.1.2.zip, 0a3d4d1af7e094c05352c31b2dafcc6ccbc80edc195ca9eaedc919c36accd05a
monero-win-x86-v0.18.1.2.zip, 71e2990ce860521c54a36c9dc77c3c7acdffc92630c4df03ba1253b428b7ac64
monero-mac-x64-v0.18.1.2.tar.bz2, ba1108c7a5e5efe15b6a628fb007c50f01c231f61137bba7427605286dbc6f01
monero-mac-armv8-v0.18.1.2.tar.bz2, 620b825c04f84845ed09de03b207a3230a34f74b30a8a07dde504a7d376ee4b9
monero-linux-x64-v0.18.1.2.tar.bz2, 7d51e7072351f65d0c7909e745827cfd3b00abe5e7c4cc4c104a3c9b526da07e
monero-linux-x86-v0.18.1.2.tar.bz2, ac7b6098fcbe53b91a53e10d75b98d4580f0ec0525b400acfb1ffb6fb7ce8cd4
monero-linux-armv8-v0.18.1.2.tar.bz2, e1467fe289c98349be2b1c4c080e30a224eb3217c814fab0204241b2b19b9c6b
monero-linux-armv7-v0.18.1.2.tar.bz2, 94ece435ed60f85904114643482c2b6716f74bf97040a7af237450574a9cf06d
monero-android-armv8-v0.18.1.2.tar.bz2, e0821251dc02180d2a91bc96835e2f2b2b05f22d3c229d1e819251fa6771bbdf
monero-android-armv7-v0.18.1.2.tar.bz2, 105818bf5e0e7d677c4ea10dbd4df1f8258d5735bbf6348d9f93449f42bea588
monero-freebsd-x64-v0.18.1.2.tar.bz2, 4b1ab16d35a7e77da7a928a45e0db19474be0ee91f6899bcaae10ee294f2b0a2

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.1.1 'Fluorine Fermi' released

Mon, 19 Sep 2022 00:00:00 GMT

Overview

This is the v0.18.1.1 release of the Monero GUI software. This release adds improvements to simple mode.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Skip nodes that are behind last checkpoint in Simple Mode
Warn when connecting to an outdated node
Update Qt to 5.15.6 on Windows and Linux (#4025)
Allow to use Windows Installer on ARM64 systems (#4026)
Update translations (#4031)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 16 commits containing 6549 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
tobtoht
netrik182

A special thanks to translators

castorp, foresle, 12, W4ikiky, juanda-097, Miguel Medina, John Lee, vaa red, MahtiAnkka, Jiri, Tony Nguyen, Tabula Rasa, Lafudoci, cryptoouob, awdfffr, v1docq47, tedtei, ZeoZ, Kareem, ZeoZ

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.1.1.zip, 4efb0009e97c3a4d97139f3a4ba9b149e5707695569bc60b465a943741a64aa0
monero-gui-install-win-x64-v0.18.1.1.exe, bf1261059ad0086cc3fd5cdaa47afef12508a70d4eae144e1e40ca36e047551c
monero-gui-mac-x64-v0.18.1.1.dmg, ed2a74739e2a01185712af5f898a3341f09d58195e22f03a6e4630e8e1e17fc0
monero-gui-linux-x64-v0.18.1.1.tar.bz2, 2dedc03de5c3d77aaf9be2ea19786c603db1f9596e4b38beeef4b7eb0acd473c

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.1.1 'Fluorine Fermi' released

Mon, 19 Sep 2022 00:00:00 GMT

Overview

This is the v0.18.1.1 release of the Monero software. This release has bugfixes related to output import/export and multisig seed restore.

Some highlights of this release are:

Wallet: fix unicode file path support on Windows (#8548)
Wallet: fix multisig seed restore (#8545)
Wallet: fixes to output import/export, allow exporting in chunks (#8555)
Wallet: skip bootstrap nodes that are lower than last checkpoint (#8552)
Wallet: check wallet compatibility with daemon's hard fork version (#8544)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 25 commits containing 802 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
sethforprivacy
moneromooo
j-berman
tobtoht
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.1.1.zip, 14eb0d7111b478a0adcde2254dabb8612a8f0b21f0dc3d5d673d851fd7039094
monero-win-x86-v0.18.1.1.zip, bae1688502882cdfc293cff55460b38a1906ce41416628c6d9b6a38120de6fb4
monero-mac-x64-v0.18.1.1.tar.bz2, 60fc466655ab4d1ae32b471c25c8c0160304f97499f2424e7514ca61c7c08991
monero-mac-armv8-v0.18.1.1.tar.bz2, 3c806061ed56a8b84b134d918f9c6bc101e3dd67d321e6cbbecfd2acc297b50f
monero-linux-x64-v0.18.1.1.tar.bz2, 937dfcc48d91748dd2e8f58714dfc45d17a0959dff33fc7385bbe06344ff2c16
monero-linux-x86-v0.18.1.1.tar.bz2, 43fe3a76f1fa13d1ac57095d4e32fe2b31bf20dde67ba1de7335a7c0fcdd03b1
monero-linux-armv8-v0.18.1.1.tar.bz2, e9b7e1dd0e70309d52be66240a43bddadc64eac1ed3a5aad17cfa1609ea424c1
monero-linux-armv7-v0.18.1.1.tar.bz2, c8cbf9cdfb89f1b2c5f6599ceb715ece69bd99f9ce669953d6768d7c7aa6963b
monero-android-armv8-v0.18.1.1.tar.bz2, e521a881e146530b4c2af35153e49c755cb31139c06bfa62e3f5b0dd91cc9602
monero-android-armv7-v0.18.1.1.tar.bz2, 696db3a95d541569375c3dab331bbd08e8c6acd30cb1c74f2ebae8c377cba6fd
monero-freebsd-x64-v0.18.1.1.tar.bz2, 5372efd08180485ce24cd69d036365b43d1c2f4bd2b506d5e51c5795cffd6d26

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.1.0 'Fluorine Fermi' released

Thu, 11 Aug 2022 00:00:00 GMT

Overview

This is the v0.18.1.0 release of the Monero GUI software. This release adds v0.18 network upgrade compatibility for Ledger and Trezor hardware wallets.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add Ledger support for v0.18, requires app v1.8.0
Add Trezor support for v0.18, requires firmware v2.5.2
Speed up time between wallet opening and refresh (#3994)
Add option to skip stop local node screen (#3734)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 18 commits containing 27 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
reemuru
tobtoht
garth-xmr
plowsof
rbrunner7

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.1.0.zip, 39c4290a01072cc8fe8eabaa2c61598421a72eac6011eccd16a2a63e89323fa2
monero-gui-install-win-x64-v0.18.1.0.exe, 9b2c8978f96e8c9662373b427ef320ccd9d652d346435a8487a756bf55cf43ff
monero-gui-mac-x64-v0.18.1.0.dmg, 0b06351b370863dce8fff9d8659a8235b98505c61c7e4f5af23843b161d92186
monero-gui-linux-x64-v0.18.1.0.tar.bz2, 6c993b622516d85555d8962767b39c79a3b3614cbdf0ab9f62fa07e3826498d0

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.1.0 'Fluorine Fermi' released

Thu, 11 Aug 2022 00:00:00 GMT

Overview

This is the v0.18.1.0 release of the Monero software. This release adds v0.18 network upgrade compatibility for Ledger and Trezor hardware wallets.

Some highlights of this release are:

Wallet: add Ledger support for v0.18, requires app v1.8.0 (#8466, #8463)
Wallet: add Trezor support for v0.18, requires firmware v2.5.2 (#8483)
Daemon: publish submitted transactions via ZMQ (#8451)
Daemon: fix a potential crash (#8454)
Daemon: fix get_block_template_backlog performance (#8455)
Daemon: fix a RandomX related bug on old macOS versions (#8492)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 18 commits containing 626 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
hyc
ph4r05
j-berman
SChernykh
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.1.0.zip, d0e2b3255163ec0499de42639cc86cf4ddae0bc5fa65aa7377ff9c40305da8fd
monero-win-x86-v0.18.1.0.zip, ed18233503b6135a29732a79b261b50aced24b99686843bc11e7e9fb2d50cf42
monero-mac-x64-v0.18.1.0.tar.bz2, da87ac5c713f17985cd57bcd007ec76ffe75123cb546cd655edb14fdd8c3d745
monero-mac-armv8-v0.18.1.0.tar.bz2, 065766f5799c6b972145e2b27830a584c18f64bdd276f31801493b7ef9e51b3c
monero-linux-x64-v0.18.1.0.tar.bz2, 9318e522a5cf95bc856772f15d7507fdef2c028e01f70d020078ad5e208f1304
monero-linux-x86-v0.18.1.0.tar.bz2, 3d54dc813116955537a4a5ae4a0a3943d9d32842e076c223ea096551db438158
monero-linux-armv8-v0.18.1.0.tar.bz2, 69e2bba6d5bd8fcf4986f59f232fdfd33b4ae2ce0959fd59567b153b923e057e
monero-linux-armv7-v0.18.1.0.tar.bz2, ecba059a2dbbef9f059e37c0f329df037501752dd871719b41104c5d4c6d358b
monero-android-armv8-v0.18.1.0.tar.bz2, ca8c9daeaee758d482d5cde94912d33b2f62656719c821b2a496fd81c0d52a79
monero-android-armv7-v0.18.1.0.tar.bz2, 0ea5ddb0630d6657810d38b1968ae76ba8e54806f46a2cc9bd02602f999aa741
monero-freebsd-x64-v0.18.1.0.tar.bz2, 1076d260b8b8fe513653916dabfa3c3790030836750d3af6bca56fc138a06af1

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.18.0.0 'Fluorine Fermi' released

Tue, 19 Jul 2022 00:00:00 GMT

Overview

This is the v0.18.0.0 release of the Monero GUI software. This major release is due to the August 13th network upgrade, which in turn adds support for Bulletproofs+, view tags, ring size increase to 16, and fee changes.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add support for v0.18 network upgrade (#3972)
Add scan transaction option (#3932)
Fix payment proof button (#3910)
Fix restoring from default restore height (#3902)
Display wallet files with a dot in name #3968)
Add separate Ledger Nano S+ entry (#3903)
Fix stagenet approximated block height (#3846)
Update Mac icon (#3560)
Update p2pool to v2.2.1 (#3966)
Only kill p2pool when we started it (#3917)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 55 people who worked, largely unpaid and altruistically, to put out 67 commits containing 20610 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
rating89us
reemuru
ComputeryPony
SChernykh
netrik182
plowsof

A special thanks to translators

Agent LvM, TheFuzzStone, foresle, reketen, Josep Mengual, Miguel Medina, Peter Liska, Júlia Forgáčová, Boris Sipos, Carlo, tomas, alreadyburnt, Nima Ghotbi, Parsa Abbasi, E-Moji, MasFlam, Gregg S, Gilberto F da Silva, v1docq47, snipeTR, xmoreee, darckme, Simon Fouilleul, Julian Fouquet, nightwolf3, tedtei, Casimir, CryptoMonero, jindouyunz, Muge Niu, TaoHuachen, MaxQiu0108, Winslow Hee, Lekton Zhang, kingoflove, netrik182, Pozsonyi Péter, liimee, siptruk, I. Musthafa, Wobole, PauleBertt, Marta Kozera, Crusty, GreenPiece, Lennard Merten, Paul Janowitz

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.18.0.0.zip, 41446de539a20c5f5e1c5098ebaebd77009347b7263bdfc61587d27b6b2ff13f
monero-gui-install-win-x64-v0.18.0.0.exe, a42ea47f6cc128e428ed115b0496d5d9817542dcf29807c2b674e518864418b5
monero-gui-mac-x64-v0.18.0.0.dmg, c1beab6aa2351a940bfa585d5bff558babb983a8a70600e5166aacf0c47cc2eb
monero-gui-linux-x64-v0.18.0.0.tar.bz2, a0680b4fcd4b5b75db9a903d17a8216cd250eff91ecbce769e6b920825c9a4c9

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.18.0.0 'Fluorine Fermi' released

Tue, 19 Jul 2022 00:00:00 GMT

Overview

This is the v0.18.0.0 release of the Monero software. This major release is due to the August 13th network upgrade, which in turn adds support for Bulletproofs+, view tags, ring size increase to 16, and fee changes.

Some highlights of this release are:

Consensus: add Bulletproofs+ to decrease transactions size and verification time (#7170)
Consensus: add view tags to outputs to reduce wallet scanning time (#8061)
Consensus: increase ring size to 16 (#8178)
Wallet: fee changes, adjusted dynamic block weight algorithm (#7819)
Wallet: multisig security fixes (#8149, #8220, #8432)
Wallet: disable multisig by default, enable with --enable-multisig-experimental (#8328)
Wallet: speed up transaction construction (#8046)
Wallet: avoid unnecessary DNS call, significantly speed up transaction construction in some cases (#8408)
Wallet: avoid hitting restricted /gettransactions RPC limit (#8388)
Wallet: decrease the amount of data exchanged for output export (#8179)
Wallet: fix spurious reorg detection with untrusted nodes (#8331)
Wallet: attempt to carve the fee from a partial payment early (#7342)
Wallet: try empty passphrase first when using Trezor (#7793)
Wallet: add new scan_tx command to scan for a list of transaction ids (#7312)
Wallet: add option to display wallet name, network mode to inactivity lock (#7153)
Wallet: add option for exporting tx keys (#8180)
Daemon: connection code rewrite, improve connectivity with SSL enabled (#8426)
Daemon: Tor / I2P tx-proxy connectivity fixes (#8324, #8330)
Daemon: fix a bug that causes transactions to not get re-relayed (#8326)
Daemon: improve cryptonote (block and tx) binary read performance (#7661)
Daemon: store RPC SSL key/cert for consistent authentication between runs (#7366)
Daemon: add support for storing database on a raw device/partition (#7774)
Daemon: add --max-connections-per-ip daemon option (#6877)
Daemon: full tx revalidation on fork boundaries (#7169)
Daemon: add proxy configuration support for bootstrap daemon (#7326)
RPC: fix describe_transfer for multiple transactions in a txset (#7767)
RPC: prevent --password-file from being used with --wallet-dir (#7823)
RPC: send confirmations in get_transactions result (#7662)
RPC: support regex for tags in get_accounts (#8215)
Optimized keccak implementation (#8262)
Mac ARM64 release binaries (#8312)
Minor bug fixes and improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 71 people who worked, largely unpaid and altruistically, to put out 420 commits containing 25749 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

lxop
dewyatt
OrvilleRed
ph4r05
erciccione
wirrickelliot
hMihaiDavid
hyc
JoeHCQ1
reemuru
drlef
suriyaa
ralphmapper
rating89us
tmoravec
TheCharlatan
timosarkar
rbrunner7
hinto.janaiyo
Xeonacid
gdmojo
perfect-daemon
benevanoff
xiphon
cabelo
codesoap
donkeydonkey
IceCruelStuff
glv2
gingeropolous
georgeleege
rex4539
fdov
AkritW
garth-xmr
Luxter77
im
kayabaNerve
normoes
iamamyth
00-matt
mj-xmr
malbit
MoneroArbo
ndorf
zer-far
serhack
sethforprivacy
SomaticFanatic
LeoNero
SamsungGalaxyPlayer
malinero
Jkat
DangerOnTheRanger
kevinbarbour
kaythomas0
lza_menace
agowa338
luigi1111
woodser
jeffro256
sarangnoether
unseddd
SChernykh
moneromooo
loqs
tobtoht
UkoeHB
j-berman
selsta
vtnerd

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.18.0.0.zip, 0b94088db62d0ded1d62d02a631b93978984acce337e01a802edd87e521dfcd1
monero-win-x86-v0.18.0.0.zip, d55e86e1434a7e1cebd6931d21063e82c25a7126ddad8704f15501bb9a6e64a4
monero-mac-x64-v0.18.0.0.tar.bz2, 6278a16ec64e2f261c2023c7be9bf904627bec58f8e4237b609eb4c842d9ff68
monero-mac-armv8-v0.18.0.0.tar.bz2, 5f2261fe821e0fe88c193ad6251e68aeb7639e9b529952df823706d424a513d7
monero-linux-x64-v0.18.0.0.tar.bz2, 74c440aa1e38a41ded0c4844b50f094146170ef83f1bd79d7e23d0d69b589faf
monero-linux-x86-v0.18.0.0.tar.bz2, 14f8e658750b9301de3e4923355adf4bdfb33348d905b74a02191fa8147c247d
monero-linux-armv8-v0.18.0.0.tar.bz2, 15cf4db8810d39104dbc230a985c7819ee96f9a7264d3f65e012b4bc36dc9f40
monero-linux-armv7-v0.18.0.0.tar.bz2, 9af9842b6725f070e568b7bbf02277e6da2ae7a5a544b4b214c60125bab5c93b
monero-android-armv8-v0.18.0.0.tar.bz2, 2656f968293b32cccf9daed36976e9331386950ad291f10f8061fc7bc87f8508
monero-android-armv7-v0.18.0.0.tar.bz2, 8c6bb7df79e350275252967f08461eda6dfcd161c0d898722af467efa114f6d6
monero-freebsd-x64-v0.18.0.0.tar.bz2, f556259345ac6e5c95421156693ec5011914355ebdc7d0d1bb97a0e6cdb29b5a

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.3.2 'Oxygen Orion' released

Fri, 29 Apr 2022 00:00:00 GMT

Overview

This is the v0.17.3.2 point release of the Monero GUI software. This release contains support for P2Pool mining and Ledger Nano S Plus.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Integrate experimental support for P2Pool mining (#3829)
Warn against high fees during transaction creation (#3897)
Improvements against wallet getting stuck on exit (#3890, #3889)
Add support for Ledger Nano S Plus
Add support for reserve proof (#3828)
Add a lock wallet button to the title bar (#3859)
Fix offline signing (#3862)
Fix adding a new address book entry (#3865)
Update translations, add support for 5 new languages (#3832)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 22 who worked, largely unpaid and altruistically, to put out 76 commits containing 31625 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
rating89us
netrik182
devhyper
mj-xmr
jeffro256
reemuru

A special thanks to translators

Miguel Medina, jaime diaz, Dynse Clyde Sacote, Robbie Monero, Gilberto F da Silva, Malek Atwiz, nanostos, ambercookie, Patix0331, Paul Janowitz, Trendyne, siptruk, tuknag, Marta Kozera

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.3.2.zip, a0fa78c62a97b91db3d225c37c33d8185891600930dddd694d01635b825c2bff
monero-gui-install-win-x64-v0.17.3.2.exe, 92541cc74ac7afbe771292f6a94127dfaf5163627a750226bff10abd431e5086
monero-gui-mac-x64-v0.17.3.2.dmg, acaabe36002ae66bee4d4ded1fbcca4b34688cb702231aea26afe49f3f284fbe
monero-gui-linux-x64-v0.17.3.2.tar.bz2, ad4b4be60548cddcade3cf8874579256805559d61a68e6102e4dde71284a2039

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.3.2 'Oxygen Orion' Point Release

Fri, 29 Apr 2022 00:00:00 GMT

Overview

This is the v0.17.3.2 point release of the Monero software. This release contains support for Ledger Nano S Plus.

Some highlights of this point release are:

Wallet: add support for Ledger Nano S Plus (#8239)
Wallet: balance includes unconfirmed payments (#8154, #8159)
Wallet: rename duplicate amount headers in CSV export (#8177)
Wallet: multisig key exchange update and code refactor (#8190)
Wallet: fix stagenet restore height estimation (#8196)
Daemon: replace outdated seed nodes (#8222, #8131)
Daemon: don't require --rpc-login with --rpc-access-control-origins (#8227)
Daemon: add a sanity check to RPC input data size (#8276) [Reported by m31007]
RPC: support authentication with set_daemon command (#8166)
Fix compilation on OpenBSD RISC-V (#8241)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 10 people who worked, largely unpaid and altruistically, to put out 28 commits containing 2294 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Gingeropolous
woodser
jeffro256
hbs
moneromooo
reemuru
UkoeHB
erciccione
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.3.2.zip, 4912d97040af32c14a99e3db1357fc2516e4ed9a8bbf828fc636bcf558b03a65
monero-win-x86-v0.17.3.2.zip, d2a2475943f75d33ec448844166a2cefe4b5fbbec63d3662682491fc32b2257b
monero-mac-x64-v0.17.3.2.tar.bz2, 3631f84739ef73d0105d902639c75d66921da6c8dff5487e01a11bf523dd0cae
monero-linux-x64-v0.17.3.2.tar.bz2, 1e54acd749265d9439d3733441c645d9b058316283c8f21cca2a333c1238cd16
monero-linux-x86-v0.17.3.2.tar.bz2, 2b3365b740b5f35a42db1b032e9401b5e2ed4e6d9266eea4f5e01ea747952cb5
monero-linux-armv8-v0.17.3.2.tar.bz2, 8e311714e97f2ac87bfd818abd5c4c605ca19ebda84a1edea93ec00a89d07e2e
monero-linux-armv7-v0.17.3.2.tar.bz2, 76c101db6df7d923ab4cff074a0368e41dbc532b65f99ac983da2f1a199b4423
monero-android-armv8-v0.17.3.2.tar.bz2, c9cfb2eaace60a2436f9b8db8a0fa6f2ae4318016d4e3fce1bd7ba5def2aeb97
monero-android-armv7-v0.17.3.2.tar.bz2, 4dab5307d4635d2f18278fff09e54c24d89f5e4582fb77a2e5dea9733868c092
monero-freebsd-x64-v0.17.3.2.tar.bz2, 097e72be2eca2944414ee0551ae9d9b560605ce208cd016cc3db24944407db91

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero will undergo a network upgrade on 13th August, 2022

Wed, 20 Apr 2022 00:00:00 GMT

Note: This blog post has been updated to reflect the new hard-fork date of the 13th of August, 2022, as the release was delayed due to required multi-sig security fixes and hardware wallet-related delays.

The next network upgrade will take place on ~13th August, 2022 (block 2,688,888). Network upgrades are technically hard-forks and require all participants in the Monero network to update their software. The new software (v0.18 "Fluorine Fermi") will be released one month before the network upgrade, on the ~13th of July.

This network upgrade will introduce important new features like:

A ring-size increase from 11 to 16 -- the largest ever absolute increase in the base anonymity set (read: plausible deniability, or base privacy) -- of every transaction on the network
Upgraded Bulletproofs algorithm, "Bulletproofs+", which will reduce the typical transaction size by ~5-7% and improve typical verification performance by ~5-7%, making every transaction lighter and faster
View tags, a brilliant way to reduce wallet sync times by 30-40%
Fee changes, improving the security and resilience of the network to rapid changes in the fee market or attacks by malicious entities
Major multi-sig fixes and improvements, including critical security patches

The complete list of changes and improvements will be released along with the new binaries.

The logs of the meeting where the dates of the network upgrade were decided are available on Github.

To learn more about how Monero uses hard-forks to upgrade the network, you can read this article from LocalMonero: "How Monero Uses Hard-Forks to Upgrade the Network"

Common questions

Q: Hard-fork? Does this mean there will be a split and a new coin will be created?
A: No. Hard-forks in Monero are made to improve the base protocol, and are non-contentious. There will be no split and no new coin will be created.

Q: What do I have to do to be prepared for this upgrade?
A: A new release will be announced before the network upgrade (around the 13th of July). You will only have to be using the updated software by the time the network upgrade occurs (13th August). To the end user, it will be like a simple software update.

Q: How do I update my wallet/node?
A: Detailed instructions will be posted along with the software update, but basically users will need to simply replace their previous software (monerod, monero-wallet-cli, monero-wallet-gui) with the new version. That's it.

Q: If I have my coins on a paper wallet, do I have to do something?
A: No. You will simply have to use an updated version of the Monero software when you will decide to move your coins.

Q: If I have my coins on a hardware wallet, do I have to do something?
A: Yes, you will need to update the Monero app or device firmware from the manufacturer once the appropriate update is available. Always be sure you go straight to the official website of the manufacturer to get these updates!

Q: Will there be any changes to the PoW algorithm?
A: No. The PoW algorithm will not be affected. Mining will work as before and miners won't need to update their software.

If you have further questions about the hard-fork, please reach out in r/MoneroSupport or via #monero on IRC or Matrix.

This Year in Monero - 2022

Mon, 18 Apr 2022 00:00:00 GMT

As a way to celebrate and show the growth that has happened for Monero across the past year on this, the 8th anniversary of the Monero project, I wanted to take a snapshot of statistics and social media posts to highlight this growth.

This is by no means an exhaustive list of ways in which Monero grew, and some of the most important growth came in increased acceptance and adoption of Monero for donations and payments:

Statistics

One of the most important ways we can deduce what has been happening in Monero is to look at the (thankfully, sparse) blockchain data available publicly.

Each section will highlight the previous year (04/2020 through 04/2021) as well as the current year (04/2021 through 04/2022) to give year-over-year comparisons and perspective.

Transactions

04/2020 through 04/2021:

Monero transactions grew from ~10,000tx per day to ~23,000tx per day
There were 5,868,096 total transactions, for an average of 16,076 transactions per day for the year

04/2021 through 04/2022:

Monero transactions grew from ~23,000tx per day to ~40,000tx per day
There were 9,087,482 total transactions, for an average of 23,542 transactions per day for the year

Year over Year Growth

Monero's on-chain usage grew 154% YoY! Every one of these transactions was done via private-by-default transactions that protect sender, receiver, and amounts.

Blockchain Growth

04/2020 through 04/2021:

Monero's blockchain grew 13.34GB in a year.
There were 262,588 total blocks, for an average size of 53.30KB per block for the year.
There were 5,868,096 total transactions, for an average of 2.38KB per transaction.

04/2021 through 04/2022:

Monero's blockchain grew 19.24GB in a year.
There were 262,567 total blocks, for an average size of 73.27KB per block for the year.
There were 9,087,482 total transactions, for an average of 2.11KB per transaction.

Year over Year Growth

Monero's blockchain size grew 144% faster YoY.

Emissions

04/2020 through 04/2021:

Monero's block subsidy (emission) created 362,406.83XMR.
There were 262,588 total blocks, for an average block subsidy of 1.38XMR per block for the year.
Monero's emission per day dropped from ~1,200XMR to ~750XMR over the course of the year.

04/2021 through 04/2022:

Monero's block subsidy (emission) created 237,822.80XMR.
There were 262,567 total blocks, for an average block subsidy of 0.90XMR per block for the year.
Monero's emission per day dropped from ~803XMR to ~458XMR over the course of the year.

Year over Year Change

Monero's annual inflation decreased 34.3% YoY while daily emission dropped 42.96% and is rapidly approaching the tail emission of 0.6XMR per block!

Fees

04/2020 through 04/2021:

Monero's participants spent 1,884.77XMR on fees in a year.
Monero averaged 5.16XMR in fees spent per day.
There were 262,588 total blocks, for an average total fees to miners of 0.00717767XMR per block for the year.
There were 5,868,096 total transactions, for an average of 0.000321189XMR per transaction.

04/2021 through 04/2022:

Monero's participants spent 1,510.77XMR on fees in a year.
Monero averaged 4.12XMR in fees spent per day.
There were 262,567 total blocks, for an average total fees to miners of 0.00575384XMR per block for the year.
There were 9,087,482 total transactions, for an average of 0.000166247XMR per transaction.

Year over Year Growth

Monero's fees spent decreased 19.84% YoY while the average transaction fee dropped 48.24%

Mining

04/2020 through 04/2021:

Monero's network hashrate increased from 1.21GH/s to 2.29GH/s over the year.

04/2021 through 04/2022:

Monero's network hashrate increased from 2.29GH/s to 3.51GH/s over the year.

Year over Year Growth

Monero's network hashrate increased 53.27% YoY

04/2020 through 04/2021:

Monero's main subreddit, r/Monero gained ~43,000 subscribers, going from ~168,000 to ~211,000 subscribers over the year.

04/2021 through 04/2022:

Monero's main subreddit, r/Monero gained ~46,000 subscribers, going from ~211,000 to 257,000 subscribers over the year.

Year over Year Growth

Monero's subreddit subscriber count grew 21.80% YoY

Twitter

04/2020 through 04/2021:

Monero's main Twitter account, @monero gained 69,209 followers.
The @monero Twitter account went from 319,884 to 389,093 followers.

04/2021 through 04/2022:

Monero's main Twitter account, @monero gained 84,397 followers.
The @monero Twitter account went from 389,093 to 473,490 followers.

Year over Year Growth

Monero's Twitter follower count grew 21.69% YoY

Highlighted CCS Campaigns

Major Upgrades

Something Missing?

If you see something missing from this post that was a major highlight of the year, please feel free to open an issue on Github and tag @reemuru, and I will update ASAP.

Resources Used

Here is a quick list of the sources and tools I used to gather these statistics:

monero-blockchain-stats, using some hints from the following link for plotting:
- https://github.com/monero-project/monero/pull/4694
Gnuplot for the graphs from data pulled via monero-blockchain-stats
https://miningpoolstats.stream/monero for hashrate graph and current miner count
https://subredditstats.com/r/monero for subreddit-related statistics and graphs
https://github.com/oduwsdl/FollowerCountHistory for Twitter follower count history for @monero
8 years logo by u/Wataru_Watanabe

Monero GUI 0.17.3.1 'Oxygen Orion' released

Thu, 06 Jan 2022 00:00:00 GMT

Overview

This is the v0.17.3.1 point release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Fix startup crash on Apple Silicon (#3804)
Fix wizard password not resetting after wallet creation (#3795)
Update translations (#3811)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 26 commits containing 1319 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
rating89us
netrik182
selamba

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.3.1.zip, 70f658d499c6fc0f232c4f5fd89f8f93e9c851465e02cdc206eb89fe6e8e897d
monero-gui-install-win-x64-v0.17.3.1.exe, d71099d2f4f0b3c223de3f6e2d47cff7da94b7a61e7ed4ecc11ac52dc482c044
monero-gui-mac-x64-v0.17.3.1.dmg, e54616064681a3ea147298b9006fbac56d80e13c5764158743a226e298a5a017
monero-gui-linux-x64-v0.17.3.1.tar.bz2, 02e8e32455383cf32030e33511656492a352788a619a0c9220ec360c2e863ef9

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

What is Seraphis, and Why Should You Care?

Wed, 22 Dec 2021 00:00:00 GMT

Seraphis is a 'transaction protocol abstraction' that I have been working on (WIP draft paper available here). As an 'abstraction', Seraphis defines rules about how you can design a real (privacy-focused) @transaction protocol without specifying concrete algorithms. For example, @RingCT is another protocol abstraction (more or less), and there are different 'real' versions corresponding to signature schemes MLSAG and @CLSAG. Seraphis is a candidate model for Monero's next transaction protocol.

Privacy-focused transaction protocols have two core structural rules.

How are amounts represented?
How are key images (a.k.a. 'linking tags') constructed?

Ever since RingCT was introduced, transaction protocols have had 'hidden amounts' by adopting the Confidential Transactions technique (the CT in RingCT). Key images, however, have seen recent innovations.

Triptych is a fourth-generation privacy-focused transaction protocol (following the Bitcoin, CryptoNote, and then RingCT models) with a new key image construction that permits 'one-of-many proofs' (which behave the same as ring signatures) with significantly better performance for large reference sets (large numbers of decoys) compared to what is possible with CryptoNote/RingCT-style key images. Note that, while the Triptych paper doesn't make a distinction between a 'transaction protocol' and a 'transaction protocol abstraction', Triptych represents a new abstract model following after RingCT.

Seraphis is, similarly, a fourth-generation privacy-focused transaction protocol (abstraction). Also like Triptych, it defines a new key image construction that permits efficient one-of-many proofs. However, there are a number of notable differences between Triptych and Seraphis.

Triptych vs. Seraphis

Triptych

Pros
- Compatible with CryptoNote user @addresses.
Cons
- Multisig is much harder with Triptych-style key images than with either CryptoNote or Seraphis key images.

Seraphis

When thinking about a possible implementation...

Pros
- Multisig can be simple, comparable to multisig with MLSAG/CLSAG.
- 'Membership proof delegation' is possible without leaking users' private keys. This potentially allows the following:
  - Transaction chaining (required for full-featured atomic swaps).
  - Offload membership proof construction to a third party, or a view-only @wallet (possibly useful for spend-only hardware wallets where it is expensive/difficult to implement complex algorithms).
  - Ignore 10-block lock time when transacting with a trusted party (i.e. allow them to make your tx's membership proofs and submit the tx to the network on your behalf).
- Flexible multi-tier address schemes. The following features can be designed into a Seraphis user address scheme (there are at least 7 design variations, half of which require 3-key addresses [a 50% increase in address length over current addresses]):
  - View-only wallet that can see spent outputs. Especially helpful for multisig and hardware wallets, since in RingCT and CryptoNote it is necessary to constantly 'export key images'.
  - View-only wallet that can see received outputs but not amounts (and optionally also see spent outputs but not amounts). Useful for delegated chain scanning, where a third party or insecure machine scans for outputs, then sends them to a more secure 2nd tier view-only wallet (or spend wallet) that can read the amounts.
  - View-only wallet that can detect the Janus attack.
- Modular core design. This will hopefully make it easier to upgrade different pieces of a Seraphis implementation as innovations appear (or maybe we will be stuck for the next 20 years... who knows?).
Cons
- Not compatible with CryptoNote user addresses. If Seraphis is used to upgrade a cryptocurrency that has CryptoNote-style addresses, then users would have to replace all their public CryptoNote-style addresses with Seraphis-style addresses (they would not need new private keys or wallets).

What about Lelantus-Spark?

Lelantus-Spark is a transaction protocol (but not an abstraction - like how Triptych is not an abstraction) very similar to Seraphis, with the same pros/cons relative to Triptych. It was developed independently from Seraphis, for the most part.

Since they were developed at the same time, the question 'why Seraphis and not Lelantus-Spark?' can just as easily be stated 'why Lelantus-Spark and not Seraphis?' Practically speaking, the authors of Lelantus-Spark have focused their attention on design details appropriate for the Firo cryptocurrency, while my design recommendations for Seraphis (in the paper) have focused on details appropriate for a cryptocurrency that currently uses standard RingCT (like Monero or MobileCoin[^mobilecoin-footnote]).

[^mobilecoin-footnote]: I first conceived of Seraphis, and wrote the paper's first draft, while an employee at MobileCoin.

Vulnerabilities identified in Monero multisignature wallet code

Mon, 06 Dec 2021 00:00:00 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear Monero users and participants of the Monero ecosystem,

Some vulnerabilities have been identified in the implementation of
Monero multisignature wallets.
These vulnerabilities do not affect the theory supporting multisigs,
but affect the current wallet code implementing them.

Initially disclosed and discussed via the vulnerability response
process*, the discussion has been enlarged to other key developers and
MRL contributors. We agreed together that a public announcement had to
be made.

These vulnerabilities affect (i) multisignature wallet creation and
(ii) multisignature transaction signing.
They can lead to funds being stolen by one of the signing parties.

Until a fix is released, we strongly recommend not to perform any
multisignature transaction unless all signing parties can be trusted.
If all signing parties cannot be trusted, no transaction should be
attempted. Funds are not at risk if they are not moved and if the
wallet-creation process was not abused.

A fix is currently being reviewed. At this stage we hope to have a
pull request ready within a week, together with a more detailed
description of the issues.

Regards,

binaryFate


* https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEgaxZH+nEtlxYBq/D8K9NRioL35IFAmGtGA0ACgkQ8K9NRioL
35JLBw//fZ4tcOCFRgoM+kiLVNVgziqio1PJl7w73BGjP7A3I0ieGPZtHfDk28ua
okSRzWVKqm94Ruy7qAaDHwASxwmJ4MELaBzufx5WqMjhKWhYi87P6ZLEP2n1eVee
TXmQ2lIy5JfKBXRI+wtmZsXLjWLajgztP0MCJGF1+QW9RawpsIuTkfyDPkrHsK32
0u3oC5XsdxETP8wu9LAsGVAsQ+xISZ//zkWlyqOWEkRxXhFUOLBmJ8OOPJ96WZ4x
RMqijDjE2ZcOXPT5pLKwX+A+p9wHEpe7tDLe6F179F+rkWda3Cy6wqBztR8+LtI0
yPBDqI5k1eu4kwTke7WcNKBjwzkd8qxvPo1kQ1btj4PukxrlDLPcJc2g4vCvuSkb
XkYzZB6fcT64bXqVnJJdeWYTBI3mDAQgOMGnU63zIA3pqYpPG44hXpFH9KXeFOwq
O60xuKd7uYVkCRA0FckkSWABy2008/qk9APwKCWwg9Md07advkCAOlNVqjF9CrTE
CZvyL3tywbbCpQsV1qeM29WM+yU5mjkz4Q3NvtHdL+c0jWElOmJDgs7RRz2bmsiX
ZCfbR78Y4fTnUMOdBVqU1yLDUg7nZYRnTyD6ORhpgEc12BJV4nDc+mkBqPiR2hTe
DLh4ZNqeIRFgX2M1Q1w9Kap2xXLV5dRMe0e/3amASKf2KJ8WBSY=
=HZgv
-----END PGP SIGNATURE-----

Monero GUI 0.17.3.0 'Oxygen Orion' released

Sat, 04 Dec 2021 00:00:00 GMT

Overview

This is the v0.17.3.0 point release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Add import / export output function (#3435)
Export all key images by default (#3282)
Update translations (#3773)
Add description to CSV export (#3572)
Add colors to password strength meter (#3682)
Add Cut, Copy, Delete and Select All to context menu (#3689)
Fix buffer overflow in zxcvbn library (#3735)
Fix font issue on Arch Linux (#3753)
Fix compilation for Apple ARM (#3697, #3723, #3731)
Mining page design tweaks (#3742)

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 65 people who worked, largely unpaid and altruistically, to put out 93 commits containing 31902 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
maltejur
free-as-in-beer
netrik182
rex4539
JeremyRand
kinghat
tobtoht
MoneroArbo
dsc
benevanoff
rating89us

A special thanks to translators

TheFuzzStone, reketen, castorp, Alex Osinniy, nemecis rojas, Samuel, Josep Mengual, jaime diaz, Dynse Clyde Sacote, devuana, mihaipe, v1docq47. L. P. Pereira, netrik182, Gilberto F da Silva, Zsolt András Kovács, Pozsonyi Péter, Közepes Gábor, anonym szeretnék maradni, Nicolas, Martin, MortiZ, GreenPiece, Crusty, Paul Janowitz

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.3.0.zip, 995704160e754dc826c84ba8edaeefdc30984d40ad4cbd2e7c043005923eb6e5
monero-gui-install-win-x64-v0.17.3.0.exe, 2c6ed3f183bb8a84f7a88542045ea45f9c53b069339974da9a843e30150533ac
monero-gui-mac-x64-v0.17.3.0.dmg, d94bd49df6076c79207d38b0e33ec5add0ba0e582ebdc476062026ab9560b360
monero-gui-linux-x64-v0.17.3.0.tar.bz2, ca41cc213b3e1a82e375030bba1f46bf154b6c2ec7f858d207cf1f6dee233cd4

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.3.0 'Oxygen Orion' Point Release

Sat, 04 Dec 2021 00:00:00 GMT

Overview

This is the v0.17.3.0 point release of the Monero software. This release contains support for P2Pool.

Some highlights of this point release are:

Add P2Pool support (#7964)
Daemon: allow socks5 proxy configuration with --proxy flag (#7326, #7616)
Daemon: fix race condition (#7873)
Daemon: fix spurious rejection of downloaded blocks (#8022)
Daemon: disable restricted RPC from getting output dist. for pre-rct outputs, fix DoS (#8084) [Reported by xfang/Haven]
Daemon: add seed nodes (#7664, #7753)
Wallet: fix key encryption when changing ask-password from 0/1 to 2 (#8014) [Reported by xfang/Haven]
Wallet: fix precision when selecting decoys (#7798)
Wallet: decrease the "recent spend window" in decoy selection (#7993)
Wallet: don't truncate integrated address in CSV history export (#7961)
Wallet: chunk get_outs.bin RPC calls to avoid sanity limits (#7796)
Wallet: add human-readable error messages to Ledger (#8039)
RPC: fix get_transactions failing when not found (#7959)
RPC: add calcpow method (#8075)
Support wildcard CORS (#7952)
Fix missing logs (#7929)
Mac: fix compilation on ARM (#7435)
Mac: don't blow out stack on ARM64 in slow-hash (#8032)
LMDB: fix deadlock in resized detection (#7958)
Detect AES support dynamically to support ARMv8 binaries on Raspberry Pi (#8005)
Update following dependencies: OpenSSL, RandomX, unwind, hidapi, zeromq (#7933, #8002, #8037, #8049, #8056, #8072)
Minor bug fixes and performance improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 18 people who worked, largely unpaid and altruistically, to put out 96 commits containing 1842 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
hyc
jtgrassie
tevador
woodser
xiphon
moneromooo
tobtoht
SChernykh
ndorf
anon
vtnerd
j-berman
UkoeHB
mj-xmr
rbrunner7
lalanza808
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.3.0.zip, a956d0c3ab77ebfc1d6229b77d68b739661b564d9a4115e5a549c3af146d6034
monero-win-x86-v0.17.3.0.zip, 541189f5635f479605eda306a36d2beef1fbe68d6fdbfabce671d6e4c8970158
monero-mac-x64-v0.17.3.0.tar.bz2, 53b7ed67f7077f27f470b4411478bef8b2bb9cf2cf480055dd1802a935983387
monero-linux-x64-v0.17.3.0.tar.bz2, ac18ce3d1189410a5c175984827d5d601974733303411f6142296d647f6582ce
monero-linux-x86-v0.17.3.0.tar.bz2, 586b9967d848eb31dd66bdb6d828bd3a640098434595a5933374d129b76958eb
monero-linux-armv8-v0.17.3.0.tar.bz2, 8fdb5761f6f4345dc670d184144ce8c2fa56eeb1609ed169e79b202fcca20f7d
monero-linux-armv7-v0.17.3.0.tar.bz2, da49d85ce2d52fc07846c58d0c58d6412f454f9d389bfa31eab9c1d49a1a13ed
monero-android-armv8-v0.17.3.0.tar.bz2, 1fa1ba8a1e4c6a0e56d8f7afd788205ff0916a3670b9bf7992f1db0f9d7dec3e
monero-android-armv7-v0.17.3.0.tar.bz2, a152c765386ee6ed670dbbfe1e90a8505040d5240a1c7c449bfa9845c4eb3e0d
monero-freebsd-x64-v0.17.3.0.tar.bz2, d496811ee4687db0c448d30086700f485bf30512c38b50441e5cb5e76b6011a7

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero P2Pool is now live

Tue, 05 Oct 2021 00:00:00 GMT

We are happy to announce that Monero P2Pool is live on the Monero network and binaries have been released.

What is Monero P2Pool?

Monero P2Pool is a peer-to-peer Monero mining pool developed from scratch by SChernykh (also known as sech1). P2Pool combines the advantages of pool and solo @mining; you still fully control your Monero @node and what it mines, but you get frequent payouts like on a regular pool. P2Pool as a concept was first developed for the Bitcoin blockchain but was never fully realized due to certain limitations, mainly because it had a problem with orphaned blocks which is solved in Monero P2Pool with uncle blocks.

P2Pool has no central server that can be shutdown/blocked because it uses a separate blockchain to merge mine with Monero. There's no pool admin that can control what your hashrate is used for or decide who can mine on the pool and who can't; It's permissionless!

All pool blocks pay out to miners immediately. Because there is no pool wallet, funds are never in custody; It's trustless.

P2Pool uses PPLNS payout scheme, has 0% fee and 0 XMR payout fee (by design, fees can't be added). Everyone in the PPLNS window is rewarded directly via the coinbase transaction reward. Minimum payout is less than 0.0004 XMR due to the very efficient miner reward @transaction format; each individual miner payout takes only 38 bytes on the Monero blockchain!

Why Monero P2Pool?

There's been some worry about mining pool centralization and the possibility of 51% attacks. Since atomic swaps went live (solving exchange delisting/KYC threat), mining is now the most centralized part of the Monero ecosystem. Currently, one pool accounts for almost 40% of Monero's network hashrate. This is not a stable situation long-term because a pool admin can be pressured to do malicious things, shutdown their pool, or expropriate funds without paying miners.

How does it work?

P2Pool is a sidechain to Monero, and P2Pool blocks are potentially Monero @blocks. Each miner submits block templates that include a payout for all of the miners that currently have shares in the PPLNS window. High quality block templates are added to the P2Pool blockchain as blocks which count as "shares" for the miner who found them.

If a block is good enough to be a Monero block it is also submitted to the Monero network to be included in its blockchain. Once the Monero block is confirmed by the network, those miners are directly paid in the @coinbase-transaction because they were included already in the block. If P2Pool "shares" are found at the same block height as an existing share, it is included as an uncle block (worth 20% less than a normal share) so you can still get paid for it (uncle blocks can be submitted up to 3 blocks behind the current height and still be included).

Features

Decentralized: no central server that can be shutdown/blocked.
Permissionless: there is no one to decide who can mine on the pool and who can't.
Trustless: there is no pool wallet; funds are never in custody. All pool blocks pay out to miners immediately.
PPLNS payout scheme
0% fee and no payout fee
Less than 0.0004 XMR minimum payout
Fast block times, down to 1 second
Uncle blocks are supported to avoid orphans - all your shares will be accounted for!
Advanced mempool picking algorithm, it creates blocks with better reward than what monerod solo mining does
Password protected private pools
Configurable PPLNS window size and block time

NOTE: Setting a password or changing any settings in config.json will create a separate sidechain. Only do this if you know what you're doing.

Getting Started

P2Pool Download
P2Pool GitHub
P2Pool Monitoring Page Note since P2Pool is decentralized, this is only a monitoring page.
P2Pool Libera.Chat IRC and Matrix channels: #monero-pow and #p2pool-log

Donations

If you'd like to support further development of Monero P2Pool, SChernykh has a donation address on his GitHub page.

Post-Mortem of Decoy Selection Bugs

Mon, 20 Sep 2021 00:00:00 GMT

When constructing a new @transaction, a Monero wallet references a past output a user received in a prior transaction, and uses it as an input to the new transaction. Today, the wallet mixes this output with a set of 10 decoy outputs selected from other people's transactions from across the blockchain (@ring-signature). Thus, an observer cannot tell which among the 11 total outputs is the real one a user spends in a transaction, obfuscating the link from the user's new transaction to their prior transaction. The decoy selection algorithm specifically handles the selection process for choosing which decoys to mix real outputs with when constructing a transaction.

Between Monero versions v0.14.1.0 and v0.17.2.2, the core wallet code had two bugs in the decoy selection algorithm that impacted Monero users' privacy:

The algorithm sometimes ignored very recent spendable outputs for consideration as decoys, thus rendering it clearer when users spent outputs immediately after the outputs were able to be spent.
If transaction volume were to increase substantially over a sustained period of time, then wallets would eventually construct transactions that reveal real outputs in the vast majority of cases.

Both have been patched in v0.17.2.3 and it is highly recommended to upgrade as soon as able.

Users should also be aware that the implications of the first bug are not as severe as previously reported. It was widely publicized that as a result of the first bug, some very newly spent outputs observed on chain were guaranteed identifiable as real outputs spent in a transaction, however, this is not actually the case. Since publication, we learned that at least one popular light wallet (MyMonero) has been using a separate implementation of the decoy selection algorithm that did not have the bug. Therefore, MyMonero users could have feasibly constructed transactions that selected newly spendable outputs as decoys, which means newly spent outputs observed on chain were not guaranteed identifiable as real outputs.

Note that having distinct implementations of the decoy selection algorithm is not ideal. Ideally, all wallets would conform to the same spec of the decoy selection algorithm to ensure transaction uniformity, so that transactions on-chain cannot be tied to a particular wallet implementation.

Technical Explanations

Applying the algorithm incorrectly (Bug 1)

The decoy selection algorithm is designed to select outputs from across the blockchain based on observed spending patterns, as recommended in Möser et al. The paper's analysis uses spending patterns from earlier versions of Monero — where in some cases, the real outputs used in transactions could be deduced with certainty — in order to arrive at a distribution of Monero user spending patterns. The paper highlights that users were more likely to spend outputs received relatively quickly than they were to spend outputs held for a long time. The paper then recommends factoring in the observed spending patterns when selecting outputs from across the blockchain to use as decoys, rather than apply an equal probability to the entire set of outputs from across the blockchain. This way, newer outputs would be more likely to be selected as decoys than older outputs, thus better obfuscating which output is real in users' transactions.

This bug was patched in PR #7821.

Divide by 0 (Bug 2)

The upgrade to the decoy selection algorithm in v0.14.1.0 factored in block size variance in order to better match spending patterns and reduce bias toward selecting coinbase outputs as decoys. When selecting a decoy, the algorithm first determines the age in seconds that the decoy output should be (by using the distribution of known spending patterns, as discussed above). Then, the algorithm divides the expected output age in seconds by the average seconds spaced between each output observed over the trailing year, in order to arrive at the output in the chain that should be used as a decoy. If the number of outputs in a year is equivalent to the number of seconds in a year, then the average seconds spaced between each output over the year is 1.

The calculation of average seconds per output had a bug where it would truncate the result. If the average seconds per output were to fall below 1, the result would have truncated to 0. When the algorithm divides the expected output age in seconds by 0, it ends up selecting decoys exclusively from the most recent spendable block on most systems. Thus, if output volume were to increase substantially over a sustained period, such that the seconds spaced between each output over the trailing year were to fall below 1 (i.e. the number of outputs over the trailing year exceeds the number of seconds in a year), then the algorithm would have selected decoys from the most recent spendable block in the vast majority of cases. At the time of this publication, the average seconds per output is around 1.7.

This divide by 0 bug was patched in PR #7845.

Conclusion

Work to improve the decoy selection algorithm is ongoing. It has room for improvement to provide stronger protection to users under a wider set of circumstances. A call to arms: anyone with a background in statistics and probability theory is encouraged to join in discussions geared toward improving the algorithm. Discussions are frequent in the #monero-research-lab and #monero-dev IRC/Matrix channels. While innovative research to improve Monero's cryptography continues in parallel in order to substantially increase the number of decoys mixed with real outputs in a transaction (i.e. increase the ring size), research to improve the decoy selection algorithm's statistical obfuscation techniques is also receiving more attention. If you feel you have the requisite skills, keep in mind there is growing interest from the Monero community to actively recruit you to the Monero project. If you are interested, consider contacting a Monero workgroup.

Monero GUI 0.17.2.3 'Oxygen Orion' released

Tue, 31 Aug 2021 00:00:00 GMT

Overview

This is the v0.17.2.3 minor point release of the Monero GUI software. This release contains a decoy selection bug fix that improves privacy.

The latest CLI release notes can be found on the precedent blog post.

Some highlights of this minor release are:

Add payment request functionality to receive page (#3650)
Display images on create hardware wallet page (#3618)
Reenable password strength meter in release binaries (#3562)
Automatically correct incorrectly typed restore dates (#3564)
Add tooltips to all buttons (#3490)
Add search transactions button on receive and account page (#3216, #3546)
Set an unused wallet name in wizard (#3544)
Fix bug not accepting new restore height (#3563)
Fix get / check proof on Sign / Verify page (#3674)
Fix scanning QR codes that miss an URI prefix (#3598)
Various date picker improvements
Accessibility improvements (#3611, #3603)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 170 commits containing 26608 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
luigi1111
rating89us

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.2.3.zip, 1ae06f71e7b469ea95f10008f2624797cf0a3223e47f07c42591c0dff63e63ec
monero-gui-install-win-x64-v0.17.2.3.exe, 8b5f37eb6b2d0534cbbc490986f23d7fb470697b7839ac1305499c4675f1ea11
monero-gui-mac-x64-v0.17.2.3.dmg, 20fe978294b65c2bb44932489f114e6a91cb4c2c4b03afb87ab683c8182cf811
monero-gui-linux-x64-v0.17.2.3.tar.bz2, f011ba2bd67395ca8c17d5faf1397785905533dd1a8b9ebf1e6810d0f726f40f

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.2.3 'Oxygen Orion' Point Release

Tue, 31 Aug 2021 00:00:00 GMT

Overview

This is the v0.17.2.3 point release of the Monero software. This release contains a decoy selection bug fix that improves privacy.

Some highlights of this point release are:

Apply gamma distribution from chain tip when selecting decoys (#7822)
Protect wallet from divide by 0 caused by integer truncation (#7846)
Ledger: speed up wallet generation, sync, and subaddress generation (#7744, #7745, #7788)
Fix optimize-coinbase for p2pool payouts (#7894)
Provide key images of spent outputs in wallet rpc (#7839)
Support freeze, thaw, and frozen in wallet rpc (#7838)
Remove blocked addresses/hosts from peerlist (#7810)
Stop adding more outputs than bulletproof allows, split transaction (#7825)
Set correct Ledger minimum version (#7789)
Fix crash with Trezor passphrase entered on computer (#7781)
Update randomx to v1.1.9 (#7734)
Fix boost 1.76.0 compatibility (#7736)
Fix rescan_bc keep_ki option (#7680)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 16 people who worked, largely unpaid and altruistically, to put out 87 commits containing 838 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
dsc
xiphon
benevanoff
moneromooo
anon
tobtoht
selsta
mj-xmr
sech1
hyc
ndorf
woodser
ph4r05
j-berman
rbrunner7

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.2.3.zip, ba3f4ec7429aacf3e712bdf21d1ceb800eb94e1e376be8b2360a01d88bb862be
monero-win-x86-v0.17.2.3.zip, 460ac8722d713022c13970d96f9098eb04b5ca4f59cc9dc929cc2dd590045a1e
monero-mac-x64-v0.17.2.3.tar.bz2, e479668f37a623691c75a9e4ec04f69af8fae0faaae5790760eb758f3955b1f7
monero-linux-x64-v0.17.2.3.tar.bz2, 8069012ad5e7b35f79e35e6ca71c2424efc54b61f6f93238b182981ba83f2311
monero-linux-x86-v0.17.2.3.tar.bz2, a93788591bd56753369a3f3171fbefb09387758c1e3a219e9265473031f0a35d
monero-linux-armv8-v0.17.2.3.tar.bz2, bbff804dc6fe7d54895ae073f0abfc45ed8819d0585fe00e32080ed2268dc250
monero-linux-armv7-v0.17.2.3.tar.bz2, 9100704b7d98d7bffbf7f72804c0c048f5e60f1dc9f6d4830c633dda3687c419
monero-android-armv8-v0.17.2.3.tar.bz2, 20c32e90c7486bd1fb6948ebb8ee4802be26c902f96b12958429c8aa1c6579b5
monero-android-armv7-v0.17.2.3.tar.bz2, 62f6172e3ebdc1266d5d882b8be4507cb3c8270b92ea6f06330077f6ef4f43e8
monero-freebsd-x64-v0.17.2.3.tar.bz2, 6a2d7ae4303d4eca4fd6df3b230f4624ffa743629e85ad1b0c862326395ca93e

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Bitcoin <-> Monero atomic swaps are now live

Fri, 20 Aug 2021 00:00:00 GMT

We are happy to announce that the Atomic Swap implementation developed by the COMIT team is mature enough to be used on Monero's network. For now, makers must buy Bitcoin and takers must buy Monero, but anyone can be a maker or taker. It is easier at the moment to sell Bitcoin for Monero than the other way around. To try a swap yourself, download the asb software developed by the COMIT team, follow the instructions and let them know if you find any issues (works also over Tor!). Remember this is brand new technology and might have unexpected bugs. Be careful and only test with small amounts. To find swap providers, visit unstoppableswap.net.

What are Atomic Swaps?

Atomic swaps are a way to exchange two cryptocurrencies (in our case Monero and Bitcoin) without relying on a trusted third party (like a cryptocurrency exchange company) and without needing to trust the person on the other side of the swap. These swaps are called "atomic" because they only have two possible outcomes: either the trade is successfully completed and each trader receives the other one's funds, or nothing happens and both traders keep the funds they started with. Since the protocol forces both parties to follow the rules, it is not possible to run away with the other party's coins, which is the main reason trusted third parties are required when exchanging cryptocurrencies.

Two teams are working on developing Atomic Swaps for Monero:

COMIT
Farcaster (Research funded by the Monero community through the Community Crowdfunding System)

General Fund 2020/2021 report

Thu, 24 Jun 2021 00:00:00 GMT

First, here is the basic information of the GF wallet. This info has always been public at https://github.com/monero-project/monero#readme but not everyone might know this.
The Monero general fund donation address is: 888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H.
The view key is: f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501. Note you need to use the base address for restoring a view-only wallet, which is: 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A.

The Bitcoin general fund donation address is: 1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H.

Current balance in GF wallets: 5637.585152963753 XMR, and 0.09042883 BTC.
This balance has been generally increasing over the last 1.5 year.

I exported all key images, which can be used together with a view-only wallet to see what transactions were spent, and the final balance. You can access them here: downloads.getmonero.org/GF_wallet_key_images_until_20210616

Summary 2020

Received: 2847.716692 XMR
Spent: 896.4505203 XMR

Summary 2021 (until 16/06)

Received: 3161.148144 XMR
Spent: 211.7867395 XMR

You can find the full list of all transactions since 2016, as well as annotated outgoing transactions for 2020/2021 here: downloads.getmonero.org/GF_wallet_report_June_2021.ods

While most donations are anonymous, I know that LocalMonero has been making some. I'll let them give info about that if and as they wish.

Also worth noting that non-monetary donations are made by some companies who are currently paying for some of our infrastructure (see the 'Sponsorships' page). Without them, the cost of resources such as our website hosting, the CDN and its associated bandwidth, etc, would probably be above 10k$/month, so it's effectively saving the general fund this amount every month.

Historically, the GF had been used to complete some CCS proposals that were struggling to be fully funded. However, in 2020 all proposals were funded on their own and hence there was no need for that kind of intervention. In 2021 we decided to always contribute to all proposals that we deem of particular significance to the Monero project, even when it is clear that they can be fully funded anyway; at this time we expect to keep doing so. I would encourage everyone motivated to make that leap and contribute some proposals.

A lot of questions and heated debates have been raised in the last week, including on the role of the General Fund and its purpose/administration. We (the core team) expect to post a clarification on these matters in the coming days.

Monero GUI 0.17.2.2 'Oxygen Orion' released

Fri, 14 May 2021 00:00:00 GMT

Overview

This is the v0.17.2.2 minor point release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Add basic menubar support on macOS (#2242)
Fix GUI being invisible on systems with multiple monitors (#3404, #3447)
New view progress button after transfer (#3208)
Tooltips on transfer page (#3401)
Fix missing icons in low graphics mode (#3423)
Display selected subaddress on merchant page (#3424)
Minor bug fixes and UI improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 96 commits containing 502 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
xiphon
luigi1111
rating89us

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.2.2.zip, 5d20829f43c431135455ec9bd788889e59dda4c6f74b6eaa92eec5411d9246e2
monero-gui-install-win-x64-v0.17.2.2.exe, ff2826a4437080470ceeaac43d0cede89798caf4a864a9cd13430ed2c63aca14
monero-gui-mac-x64-v0.17.2.2.dmg, 3ee4e9145b0545ba4e5c47b89b64bc558c8eeb7887d260b3bd30f6a215029964
monero-gui-linux-x64-v0.17.2.2.tar.bz2, 0088b133febdb151a3753393b4dc8b06111b844c0fca14e512f3c8d56a2a5b97

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

This Year in Monero - 2021

Sat, 24 Apr 2021 00:00:00 GMT

Introduction

As a way to celebrate and show the growth that has happened for Monero across the past year on this, the 7th anniversary of the Monero project, I wanted to take a snapshot of statistics and social media posts to highlight this growth.

This is by no means an exhaustive list of ways in which Monero grew, and some of the most important growth came in increased acceptance and adoption of Monero for donations and payments:

Statistics

One of the most important ways we can deduce what has been happening in Monero is to look at the (thankfully, sparse) blockchain data available publicly.

Each section will highlight the previous year (04/2019 through 04/2020) as well as the current year (04/2020 through 04/2021) to give year-over-year comparisons and perspective.

Transactions

04/2019 through 04/2020:

Monero transactions grew from ~7,000tx per day to ~10,000tx per day
There were 2,811,244 total transactions, for an average of 7,702 transactions per day for the year.

04/2020 through 04/2021:

Monero transactions grew from ~10,000tx per day to ~23,000tx per day
There were 5,868,096 total transactions, for an average of 16,076 transactions per day for the year

Year over Year Growth

Monero's on-chain usage grew 208% YoY! Every one of these transactions was done via private-by-default transactions that protect sender, receiver, and amounts.

Blockchain Growth

04/2019 through 04/2020:

Monero's blockchain grew 7.41GB in a year.
There were 292,651 total blocks, for an average size of 29.56KB per block for the year.
There were 2,811,244 total transactions, for an average of 2.76KB per transaction.

04/2020 through 04/2021:

Monero's blockchain grew 13.34GB in a year.
There were 262,588 total blocks, for an average size of 53.30KB per block for the year.
There were 5,868,096 total transactions, for an average of 2.38KB per transaction.

Year over Year Growth

Monero's blockchain size grew 180% faster YoY while the average transaction size dropped 13.76% YoY (thanks, CLSAG)!

Emissions

04/2019 through 04/2020:

Monero's block subsidy (emission) created 599,105.65XMR.
There were 292,651 total blocks, for an average block subsidy of 2.04XMR per block for the year.
Monero's emission per day dropped from ~2,000XMR to ~1,200XMR over the course of the year.

04/2020 through 04/2021:

Monero's block subsidy (emission) created 362,406.83XMR.
There were 262,588 total blocks, for an average block subsidy of 1.38XMR per block for the year.
Monero's emission per day dropped from ~1,200XMR to ~750XMR over the course of the year.

Year over Year Change

Monero's inflation decreased 39.5% YoY and is steadily approaching the tail emission of 0.6XMR per block!

Fees

04/2019 through 04/2020:

Monero's participants spent 1,101.07XMR on fees in a year.
Monero averaged 3.016XMR in fees spent per day.
There were 262,651 total blocks, for an average total fees to miners of 0.00419288XMR per block for the year.
There were 2,811,244 total transactions, for an average of 0.000391666XMR per transaction.

04/2020 through 04/2021:

Monero's participants spent 1,884.77XMR on fees in a year.
Monero averaged 5.16XMR in fees spent per day.
There were 262,588 total blocks, for an average total fees to miners of 0.00717767XMR per block for the year.
There were 5,868,096 total transactions, for an average of 0.000321189XMR per transaction.

Year over Year Growth

Monero's fees spent increased 71.11% YoY while the average transaction fee dropped 17.99% YoY (thanks, CLSAG)!

Mining

12/2019 through 04/2020:

NOTE: This time range begins with the implementation of RandomX in the November 30th, 2019 network upgrade.

Monero's network hashrate increased from 0.682GH/s to 1.21GH/s over the year.
Monero forked to the ASIC-resistant mining algorithm known as RandomX.
Monero started after the RandomX upgrade with ~27,000 miners.
Monero unique miners increased from 27,247 to 37,380 over the year.

04/2020 through 04/2021:

Monero's network hashrate increased from 1.21GH/s to 2.29GH/s over the year.
Monero broke 100,000 miners for the first time in it's network history!
Monero unique miners increased from 37,380 to 102,163 over the year.

_ Disclaimer: These miner numbers are the lower bound, as they are the numbers visible via API of public pools where the API is reachable and provides miner count. There are likely many more miners that are solo, use private pools, or are on pools that do not expose miner count._

Year over Year Growth

Monero's network hashrate increased 89.25% YoY and network miners increased 173.30% YoY and 274.95% since the introduction of RandomX!

04/2019 through 04/2020:

Monero's main subreddit, r/Monero gained ~11,000 subscribers, going from ~157,000 to ~168,000 subscribers over the year.

04/2020 through 04/2021:

Monero's main subreddit, r/Monero gained ~43,000 subscribers, going from ~168,000 to ~211,000 subscribers over the year.

Year over Year Growth

Monero's subreddit subscriber count grew 25.59% YoY and grew 290% faster than the previous year!

Twitter

04/2019 through 04/2020:

Monero's main Twitter account, @monero gained 3,502 followers.
The @monero Twitter account went from 317,010 to 320,512 followers.

04/2020 through 04/2021:

Monero's main Twitter account, @monero gained 69,209 followers.
The @monero Twitter account went from 319,884 to 389,093 followers.

Year over Year Growth

Monero's Twitter follower count grew 21.63% YoY and grew 1,870% faster than the previous year!

Top Ten Tweets

"Love this #Monero cheat sheet. Get your privacy on - @coinbureau"
- https://twitter.com/coinbureau/status/1382348948803883010?s=20
"'Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.' ― Edward Snowden #monero $XMR - @girlgone_crypto"
- https://twitter.com/girlgone_crypto/status/1275427089294876674?s=20
"Over 100k miners securing the #Monero network. New ATH. No ASICs. One CPU. One vote. https://miningpoolstats.stream/monero - @DontTraceMeBruh"
- https://twitter.com/DontTraceMeBruh/status/1383481500704788489?s=20
"I'll have you know that the words 'Monero' and 'XMR' are not mentioned in Chainalysis crypto crime report 2021 that just came out. Not even once, over 113 pages. - @binaryFate"
- https://twitter.com/binaryFate/status/1359926676138909699?s=20
"If #monero came out first, then #bitcoin, everybody would say 'Why would I give up my privacy?'"
- https://twitter.com/vikrantnyc/status/1366375047812812804?s=20
""In Nobody We Trust" - #Monero - @girlgone_crypto"
- https://twitter.com/girlgone_crypto/status/1326280779643543552?s=20
"Now you know why I was so bullish for #Monero last year. The upcoming $XMR - $BTC atomic swaps are going to be a gamechanger. Will be interesting to see how much BTC 'disappears' from the #Bitcoin network when it goes live. - @coinbureau"
- https://twitter.com/coinbureau/status/1360983149778526213?s=20
"And the #Monero network has been upgraded! Enjoy your 20% cheaper, lighter, and faster to verify private by default transactions. #MoneroKeepsBuilding #CLSAG - @sethisimmons"
- https://twitter.com/sethisimmons/status/1317258377945374721?s=20
"Bitcoin was envisioned as an anonymous P2P digital cash. However, that title is today best reserved for privacy coins like #Monero. In my video today, I look at Monero once again and explain why I think $XMR is so undervalued - @coinbureau"
- https://twitter.com/coinbureau/status/1376204882106068995?s=20
"We're excited to see THORChain, a cross-chain decentralised liquidity network, collaborating with Haven to integrate #Monero!"
- https://twitter.com/monero/status/1382646165456498688?s=20

Highlighted CCS Campaigns

Bulletproofs+ audits
- https://ccs.getmonero.org/proposals/bulletproofs-plus-audit.html
- https://ccs.getmonero.org/proposals/bulletproofs-plus-audit-jp.html
Feather wallet GUI development
- https://ccs.getmonero.org/proposals/feather-2020.html
CLSAG audit
- https://ccs.getmonero.org/proposals/clsag-audit-take2.html
Research post-quantum strategies for Monero
- https://ccs.getmonero.org/proposals/research-post-quantum-monero.html
Monero Atomic Swaps research funding
- https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-research.html
Monero Atomic Swaps implementation funding
- https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-implementation.html
Add Monero to TxStreet
- https://ccs.getmonero.org/proposals/txstreet-2021.html
anon: perfect peer to peer protocol from bottom to top
- https://ccs.getmonero.org/proposals/anon-perfect-peer-to-peer-protocol.html
tipxmr.live - a non-custodial livestream donation service for OBS
- https://ccs.getmonero.org/proposals/tipxmr.live.html
Compilation time reduction and housekeeping
- https://ccs.getmonero.org/proposals/mj-compil-time-reduction.html

Major Upgrades

CLSAG, a new ring signature mechanism that improves transaction efficiency
- "CLSAG, users see a 20% improvement in signature verification, and at least a 10% overall improvement for typical transactions. For example, a typical Monero transaction (2 inputs and 2 outputs) which usually weighs 2.5kB, takes only 1.9kB of blockchain space with CLSAG, a ~25% improvement."
Monero put out several updates to resolve and prevent network attacks from a prolonged and aggressive attack on the p2p network
- "Monero’s peer-to-peer (p2p) network has been undergoing several different types of attack by an entity who has consistently attacked, spammed, and attempted to undermine the Monero network and community for years."

Something Missing?

If you see something missing from this post that was a major highlight of the year, please feel free to reach out via Twitter, Matrix, or email and I'll work to get it added ASAP.

Resources Used

Here is a quick list of the sources and tools I used to gather these statistics:

monero-blockchain-stats, using some hints from the following link for plotting:
- https://github.com/monero-project/monero/pull/4694
Gnuplot for the graphs from data pulled via monero-blockchain-stats
https://miningpoolstats.stream/monero for hashrate graph and current miner count
https://subredditstats.com/r/monero for subreddit-related statistics and graphs
https://github.com/oduwsdl/FollowerCountHistory for Twitter follower count history for @monero

Disclaimer: I am the author of https://sethforprivacy.com/posts/this-year-in-monero-2021/ and the content for this blog post was originally shared there first.

Monero GUI 0.17.2.1 'Oxygen Orion' released

Wed, 14 Apr 2021 00:00:00 GMT

Overview

This is the v0.17.2.1 minor point release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Fix transfer on macOS (#3390)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 8 commits containing 15 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

selsta
tocomo
luigi1111

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.2.1.zip, ac12efea2f99e8ac0f77f3ba73ea333b4f44d8a08149f6c2ab5b7662e2f9b8f3
monero-gui-install-win-x64-v0.17.2.1.exe, 8761082c8fd907c59effd30156a98bcb9c01a48b14eafde1e9a8463fc5f81d16
monero-gui-mac-x64-v0.17.2.1.dmg, f8c2b2eefb8b25ac2e2beb54c1814c947da5239192a1a2873b7c89ed14761215
monero-gui-linux-x64-v0.17.2.1.tar.bz2, 72dfca40797201604a6b2fb97935037f62d3153360695cf732dee3d12e167da3

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.2.0 'Oxygen Orion' released

Fri, 09 Apr 2021 00:00:00 GMT

Overview

This is the v0.17.2.0 point release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this release are:

Allow sending to multiple receipients (#3332)
Add support for pruning of new databases in wizard (#3345)
Add support for storing multiple remote nodes (#3373)
New "Grab QR code from screen" functionality (#3292)
Improve search functionality on Transactions page (#3215)
Fix a memory leak on Linux (#3326)
Fix incorrect fiat price api usage with Kraken (#3298)
Enable dns block list in simple mode (#3314)
Restrict max window width / height, fix initial window alignment (#3302)
Updated translations from Weblate (#3342)
Update monero submodule to v0.17.2.0 (#3382)
Minor design improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 66 people who worked, largely unpaid and altruistically, to put out 93 commits containing 31902 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

xiphon
luigi1111
rating89us
toh995
erciccione
fsrw42
benevanoff
secure-designer
selsta

A special thanks to translators

Luis Alejandro Herrera Bolaños, ian vatega, Miguel Medina, Michael Russo, Samuel, 0x82b, kombometralla, Tony Nguyen, Boris Sipos, Tabula Rasa, 8uDD4T, Gleb Golov, Lafudoci, Joan Montané, Nima Ghotbi, Gilberto F da Silva, Russian Bear, Agent LvM, v1docq47, Scott Anecito, x52fws, Lana, Demofrager, Ian appel, EvolBit, Bertrand Jacquin, lir4376, Loué Marie, el00ruobuob, Michal Vašíček, dskch83, ambercookie, warraxxx, Georgios Apostolopoulos, ΚΥΡΙΑΚΟΣ ΚΑΡΑΚΥΡΙΟΣ, Marinus Savoritias, Iason Andreou, Donald A. Iljazi, Vytas, Aivaras Kasperaitis, Renato MB, netrik182, Mathkamy, Allan Nordhøy, obit33, Edwin den Boer, dutchcodes, Ori Levenglick, Yan Abu Arab, G. Orwell, mr, Paul Janowitz, Nicolas, GreenPiece, SJ, Deleted User, Wobole

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.2.0.zip, 12d7e364b3870b96ed646329634cdcb7e9b2f3fb3290c9834d7a17214d6b47c2
monero-gui-install-win-x64-v0.17.2.0.exe, 2e6150da2243eb887b727fb1e7cd7824ea869648fcd55843f7e767f1966026ab
monero-gui-mac-x64-v0.17.2.0.dmg, 8825b196146c73d13292d1e65aa3c263170358af938dc4b47b498fab1d12f0c0
monero-gui-linux-x64-v0.17.2.0.tar.bz2, ee31d67f3df174cc88b01a528aa9d882504fb5f7ae805f449ff35820a4d45bbb

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.2.0 'Oxygen Orion' Point Release

Fri, 09 Apr 2021 00:00:00 GMT

Overview

This is the v0.17.2.0 point release of the Monero software. This release contains bug fixes and daemon stability improvements.

Some highlights of this point release are:

Only print blocked nodes once with --enable-dns-blocklist (#7295)
Fix Mac serialization compatibility issues (#7350)
Fix potential crash with Trezor (#7336)
Fix daemon crash with --db-sync-mode fastest (#7362)
Daemon stability improvements (#7309, #7390, #7459, #7615, #7621)
Bump OpenSSL dependency to 1.1.1k (#7637)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 9 people who worked, largely unpaid and altruistically, to put out 39 commits containing 1146 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
ndorf
moneromooo
anon
selsta
mj-xmr
sech1
hyc
ph4r05

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.2.0.zip, 71e531a0f799c80e3f6319888bd5b85a737091b9bd5d66366cae036163857caf
monero-win-x86-v0.17.2.0.zip, c772070ebdfe9e0d6abda5073808e648e69f8c35f8010e66b80f45a6bdb01792
monero-mac-x64-v0.17.2.0.tar.bz2, 2e95dc107ab0dab36f5544bec040180264256e45407c383cfb45cfe328fe42e0
monero-linux-x64-v0.17.2.0.tar.bz2, 59e16c53b2aff8d9ab7a8ba3279ee826ac1f2480fbb98e79a149e6be23dd9086
monero-linux-x86-v0.17.2.0.tar.bz2, e8a39be486549908c10524d851a006c21c30b1a49142586aff0a17e7c4d46077
monero-linux-armv8-v0.17.2.0.tar.bz2, a004fad5348549e2f1610380775353f19db7cbca0cbe4acbfab87832c484da62
monero-linux-armv7-v0.17.2.0.tar.bz2, b5986d6dfbddee14e32b28305dd0dc6352c18b632f569227f2c7265ef7dc5081
monero-android-armv8-v0.17.2.0.tar.bz2, b8a353f02feaee9aae3d279c043ea33a32413a298d8b6122d00a65508f15169d
monero-android-armv7-v0.17.2.0.tar.bz2, 815341f7d46f75a8905f8b51932e1034a7f6b1669757ff48224632d08339d1bf
monero-freebsd-x64-v0.17.2.0.tar.bz2, 34ef5702a050298f48ccea7db992137bc98c8e6eba45ecd90b47ce0a4b7bf0f8

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Getmonero.org is now available in Norwegian

Fri, 02 Apr 2021 00:00:00 GMT

We are happy to announce that after months of work, this website is now available in Norwegian!

Norwegian is the 14th language available for getmonero.org, following English, Spanish, Italian, Polish, French, Arabic, Russian, German, Dutch, Brazilian Portuguese, Turkish, Chinese simplified and Chinese traditional.

A big thanks to ChrisAvis and the community crowdfunding that made his work possible. Translators like him allow Monero to continue to reach a much larger audience.

To browse the website in Norwegian, simply select Norsk from the language dropdown menu on the top right, or use this direct link: https://www.getmonero.org/nb-no/index.html

Do you want to help make Monero available to everybody in the world? Become a translator!

The Monero wallets, Getmonero and other content are open for translation on Weblate, our self-hosted translation platform. If you need info, support, or you just have questions, contact the Monero Localization workgroup.

Monero GUI 0.17.1.9 'Oxygen Orion' released

Fri, 08 Jan 2021 00:00:00 GMT

Overview

This is the v0.17.1.9 minor point release of the Monero GUI software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Update monero submodule to v0.17.1.9
Windows GUI binary is now reproducible
Add high DPI support on Windows

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 12 commits containing 99 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

xiphon
Snipa
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.9.zip, 862aa9a6564a60be3e70ee30eb061d5186a141ce62842b3d741558470c255988
monero-gui-install-win-x64-v0.17.1.9.exe, edc47b1540510640a40e8d52ad4ab3a6220f935e881fd65b02ccce94a28c3fa2
monero-gui-mac-x64-v0.17.1.9.dmg, c8a8ea012e8731bfacd17434fdd3a0f03302fc61d7187d218da5ff6a6e869f0b
monero-gui-linux-x64-v0.17.1.9.tar.bz2, 6334acbe9877e2e86b1902b111abc59e170aedc701ea71cbae49830191bbd745

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.9 'Oxygen Orion' Point Release

Fri, 08 Jan 2021 00:00:00 GMT

Overview

This is the v0.17.1.9 minor point release of the Monero software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack.

Some highlights of this minor release are:

Add different limits for epee binary format for P2P and RPC
Add more sanity checks on data size (portable_storage)
Fix deadlock banning while updating peer lists
Add aggressive restrictions to pre-handshake p2p buffer limit
Add a max levin packet size by command type
Restrict duplicate keys and unnamend sections in epee binary format
More sanity checks in new chain block hashes
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 30 commits containing 362 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Snipa
moneromooo
vtnerd
selsta
xiphon
binaryFate

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.9.zip, a3e6e2f55deb487f6b4a33cf430d82d62e986d37d7d589dcb33a4ff0a13a062b
monero-win-x86-v0.17.1.9.zip, bb3c633a3d8ac160bc9c75ef514a9cbc77f1f45bdbd220d1963d78d66435c23a
monero-mac-x64-v0.17.1.9.tar.bz2, d4850ae45eee67868140183cd8c00f9e1f9e1cc5e415b00bc78c14c7bab85834
monero-linux-x64-v0.17.1.9.tar.bz2, 0fb6f53b7b9b3b205151c652b6c9ca7e735f80bfe78427d1061f042723ee6381
monero-linux-x86-v0.17.1.9.tar.bz2, 1f51206c1996a577f976c0526b93cc495fe577db21f68b55636dce926f201206
monero-linux-armv8-v0.17.1.9.tar.bz2, ef16c3aefc8a17f0a547ffec9e2f087923c6bf293b9538294d14cbd318f1ab98
monero-linux-armv7-v0.17.1.9.tar.bz2, c8b226af900b018fade24742e5936b0ef6cec3fcdbc8a57a4b3f3d6d2507a2ec
monero-android-armv8-v0.17.1.9.tar.bz2, 2c45e0fb364ff2e60aa9cdf0d3faef145b22a8632b3336cc248eeba24352d39b
monero-android-armv7-v0.17.1.9.tar.bz2, c7192caf85f82ecdd1e7299c9ae6314fe2fb02ed9b7035a426a8644b676cc75f
monero-freebsd-x64-v0.17.1.9.tar.bz2, 3052f691a1a7631ba50c3f4d6f1b1355bdcc9a8c0c617cf56ced400afa1ea402

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.8 'Oxygen Orion' released

Wed, 30 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.8 minor point release of the Monero GUI software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Update monero submodule to v0.17.1.8
UI tweaks to LineEdit component
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

xiphon
Snipa
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.8.zip, 0c4ce3953824e6e65e2913fb1cb246ebe2742386821d2b92b4a6b6251c66f901
monero-gui-install-win-x64-v0.17.1.8.exe, 81dcefcf42127101568357f56afdbe0c92d1f8b153dff09ae2d062ba96579f4e
monero-gui-mac-x64-v0.17.1.8.dmg, f9ad5567e6e1e4a88213190cbde6d974265640438e9f2de41ce0d4839cb021f4
monero-gui-linux-x64-v0.17.1.8.tar.bz2, b9ea5890033a3d67f14abe401c223c5b33947689abaeacf9905e57b811840853

A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). To ensure that the files you download are those originally posted by the maintainers, you should both check that the hashes of your files match those on the signed list, and that the signature on the list is valid.

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.8 'Oxygen Orion' Point Release

Wed, 30 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.8 minor point release of the Monero software. This is a recommended release that contains mitigations against the ongoing memory exhaustion attack.

Some highlights of this minor release are:

Protocol: drop nodes if they claim new data but only give stale data
Add some sanity checks on data size (portable_storage)
Fix some issues using connections after shutdown, add buffered SSL handshake detection
Optional DNS based blocklist (--enable-dns-blocklist)
Ban lists may now include subnets
The ban command can now load IPs from a file (ban @filename)
RPC: add busy_syncing, synchronized fields to get_info
RPC: limit the number of txes for get_blocks.bin
P2P: ignore incoming peer list entries when we have them blocked
P2P: remove peers from grey and anchors lists when blocked
Restrict public node checks a little, warn about untrusted nodes
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 45 commits containing 530 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

TheCharlatan
luigi1111
Snipa
moneromooo
vtnerd
selsta
anon

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.8.zip, 55bafa33142b2aa979e5f6b4a6ddb60584bc9e9434e3a8c0a7fd8c9852bbcd7e
monero-win-x86-v0.17.1.8.zip, 4bd0c594c59de2815e91e7560be5b52370abb351f425c2ea1434a0ae4205c30a
monero-mac-x64-v0.17.1.8.tar.bz2, b969d7c8855d59b6962227a5a68f507f183253d06acd548b41673c647317de48
monero-linux-x64-v0.17.1.8.tar.bz2, b566652c5281970c6137c27dd15002fe6d4c9230bc37d81545b2f36c16e7d476
monero-linux-x86-v0.17.1.8.tar.bz2, 827e6e30296135494e80fcd54b0c8e64532b0ec8bdbbbec445860ce47d6f0d87
monero-linux-armv8-v0.17.1.8.tar.bz2, e8580f776152757bf07b0ca9dc3c1fbb4033b0956ab76599ff642fdb84427d1e
monero-linux-armv7-v0.17.1.8.tar.bz2, 83f2d8fd32f17b1f6669736015ad25e613987e69c8b052600ac9b8942370ba19
monero-android-armv8-v0.17.1.8.tar.bz2, 1598b73ac35e8c7f35a60cf4afc93d915954e0a3939d5d81ec040d3294eda162
monero-android-armv7-v0.17.1.8.tar.bz2, 0ce30e0882dbdf4fd12d29c556bd805c1ff6e7012a9f028a742726a6e57374a6
monero-freebsd-x64-v0.17.1.8.tar.bz2, 2911c3b605262edaa8e634067c2ba04069990d2bb668b990bfd1a5c35858aaf3

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Bulletproofs+ in Monero

Thu, 24 Dec 2020 00:00:00 GMT

Summary

Code is now available for Bulletproofs+, a zero-knowledge proving system that can be used in the Monero protocol in place of the existing Bulletproofs zero-knowledge proving system. The new construction would make transactions smaller, faster for wallets to generate, and faster for network participants to verify. While the code is functional and includes tests for the underlying algorithms, it should be reviewed by third-party auditors if chosen for deployment in a future Monero network upgrade. The code is permissively licensed in the hope that it can be broadly useful.

Thanks to the Multidisciplinary Academic Grants in Cryptocurrencies (MAGIC) nonprofit organization for coordinating and supporting the grant for this implementation, and to the donors who made this work possible.

Resources

Bulletproofs preprint by Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. This is the preprint (later published after peer review) used as the basis for the current Monero protocol implementation.
Bulletproofs+ preprint by Heewon Chung, Kyoohyung Han, Chanyang Ju, Myungsun Kim, and Jae Hong Seo. This is the preprint used as the basis for the proposed Monero protocol implementation.
Bulletproofs+ code by Sarang Noether. This is the new implementation code written for compatibility with the Monero codebase.
Consensus-related code by moneromooo. This code is necessary for a network upgrade that would include Bulletproofs+ proofs as a consensus rule.

Range proving in zero knowledge

The Monero confidential transaction protocol requires the use of a zero-knowledge range proving system. Because inputs and outputs in Monero transactions have their value hidden, it's necessary to secretly prove that they represent valid amounts to avoid overflows that would fool the protocol's balance checks. The constructions used for range proving have evolved over time. Originally, the Monero protocol used a variation of ring signatures for this purpose; however, the resulting proofs were very large and slow to generate and verify, leading to slow synchronization of the blockchain and a large amount of chain bloat.

This was overhauled after the release of Bulletproofs, a much more efficient range proving system. With Bulletproofs, range proofs are much smaller and faster to verify; further, multiple proofs can be verified at the same time in a batch, leading to even more efficient synchronization.

A newer preprint modifies the Bulletproofs construction to produce Bulletproofs+, an even more efficient range proving system. Range proofs in Bulletproofs+ retain a similar underlying structure to those in Bulletproofs; however, they are slightly smaller, faster to generate, and faster to verify.

Implementation code is now available that is compatible with the Monero codebase for easy deployment.

Efficiency

Side-by-side efficiency comparisons between Bulletproofs and Bulletproofs+ range proofs are possible using the performance test framework in the Monero codebase.

The size and timing characteristics of range proofs depend on the structure of the transaction that uses them. Because of the way that both the Bulletproofs and Bulletproofs+ algorithms work, the number of outputs in a transaction is effectively rounded up to the next power of two for range proving purposes, with a maximum of 16 outputs permitted in a transaction. The vast majority of Monero transactions contain two outputs, but 16 outputs is also common for pool payouts and other purposes.

Size

Regardless of the number of outputs in a transaction, the corresponding Bulletproofs+ range proof is 96 bytes smaller than a Bulletproofs range proof.

This table shows the reduction in size for the most common 2-output transaction types seen on the Monero network.

Spent inputs	Current size	New size	Reduction, % smaller
1	1.42 kB	1.33 kB	6.6%
2	1.92 kB	1.83 kB	5.1%

The results are clear. Bulletproofs+ range proofs are smaller than Bulletproofs range proofs, saving space on the blockchain!

Time

Proof generation time is typically not an area of practical concern, since wallet software only needs to do this when making a transaction. However, it's worth noting that a 2-output Bulletproofs+ range proof (the most common) generates 10.2% faster! Proving times for other numbers of outputs scale roughly linearly.

Proof verification time, on the other hand, is very important! Network participants need to verify large numbers of range proofs when joining the network and synchronizing to obtain new blocks. Fortunately, Bulletproofs+ range proofs (like those in Bulletproofs) can be verified in batches much more efficiently than doing so individually. We can see the differences clearly.

This table shows the percent reduction in verification time between the Bulletproofs and Bulletproofs+ algorithms for proofs comprising different numbers of outputs. Tests for verifying single proofs are median values over 10000 randomized tests. Tests for verifying batches of proofs are median values over 1000 randomized tests, where each batch contains 64 proofs. Absolute times are not listed, since they depend on the computing environment; however, relative times are generally comparable and consistent.

Outputs per proof	Single proofs, % faster	Batched proofs, % faster
2	1.5%	5.3%
4	0.5%	9.2%
8	1.6%	9.2%
16	0.9%	10.8%

The results are clear. Bulletproofs+ range proofs are faster to verify than Bulletproofs range proofs, leading to faster synchronization!

Thanks to Mortanta Manolete for designing the Bulletproofs+ logo!

Monero GUI 0.17.1.7 'Oxygen Orion' released

Sun, 13 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.7 minor point release of the Monero GUI software. This is a recommended release that contains P2P network layer improvements.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Ask for writing desktop shortcut on first start (Linux)
Fix wallet initialization flag handling
Get back "Sending transaction ..." splash
Disable QML cache
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 16 commits containing 51 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
Snipa
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.7.zip, d6bc6edd9fb0cd867933ff2a66ee99cca03869d728b43d42c98c333570c529f3
monero-gui-install-win-x64-v0.17.1.7.exe, 21fd01bb5c1fa169067208d0f7311d1ebec4e5b187285e5231823b72d6fb1951
monero-gui-mac-x64-v0.17.1.7.dmg, 1664860f4fae066695a74c04b55caa6421a8a10df5bbeb554c2e6dea89336710
monero-gui-linux-x64-v0.17.1.7.tar.bz2, 9a51b62ff422263d73bda1287ab65434602861d03819a15b3cefdab30e9145ec

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.7 'Oxygen Orion' Point Release

Sun, 13 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.7 minor point release of the Monero software. This is a recommended release that contains P2P network layer improvements.

Some highlights of this minor release are:

P2P: include first new block in chain entry response
P2P: more restrictive checks on chain entry response
Fix syncing with --sync-pruned-blocks flag
Update OpenSSL to 1.1.1i to fix its recently disclosed vulnerability
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 24 commits containing 154 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Snipa
moneromooo
selsta
hyc

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.7.zip, 4e1352b383095e9d4393a40785e159d6a4a83bca69f304a2dba258d370074ad0
monero-win-x86-v0.17.1.7.zip, ef47d1160f3926b9046b1ee0ac324b8d8c6196f8c93d685ef8e4b7e3274372fc
monero-mac-x64-v0.17.1.7.tar.bz2, 0bf79a44d01a5f7970d237344bc1a5268cf307dd2d0e9b09258f1d8d4fedbb94
monero-linux-x64-v0.17.1.7.tar.bz2, 98ce0d22db0d1112114bbad4c9773d1490d30e5c643423c2e5bffc19553207f9
monero-linux-x86-v0.17.1.7.tar.bz2, 4d9730765cb5979234e83f1cdfdf23a9fff7946a11c7fcedea7e1effe6074d93
monero-linux-armv8-v0.17.1.7.tar.bz2, 17a39df633eea37eba4871dcad29ddc1b56af37039e32f10c0492d9fa9ac0e48
monero-linux-armv7-v0.17.1.7.tar.bz2, 952221a6f2b449892e9a51de1b5b63bac9faf4748789b12c12d616aab5d8389f
monero-android-armv8-v0.17.1.7.tar.bz2, c629ab6d69d91ef61ca073c9b64479eac51ab7c3bdb0daf44cb8f971a3ba51d3
monero-android-armv7-v0.17.1.7.tar.bz2, 814312f44f5e9be92b8d090b0b5126bd8f747ce325f185832290b98c29a00d44
monero-freebsd-x64-v0.17.1.7.tar.bz2, 50a36a796cbe3de569c26344af311b43afb0a44693383c088685830876a0f0e1

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.6 'Oxygen Orion' released

Mon, 07 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.6 minor point release of the Monero GUI software. This is a recommended release that contains P2P network layer improvements.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Fix transactions getting incorrectly marked as failed
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 16 commits containing 77 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
Snipa
rating89us
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.6.zip, 15fac8ad47f1c1a78f92b46692875261d2a3c67a742cb8f43bbed05dc5beb289
monero-gui-install-win-x64-v0.17.1.6.exe, 18bb1b4c5f762bd9eacabececc012cd077cac4d9dc64f46b42c4ea68cdbfa70e
monero-gui-mac-x64-v0.17.1.6.dmg, dd3e909c2b2d61f6158def93ec544897ea5cd4c22fa9a8a8398a6c511ba5ec47
monero-gui-linux-x64-v0.17.1.6.tar.bz2, 413d41f8e349b52db60c6932182f852c34587f55f7b4436fe72a0bb7245830c3

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.6 'Oxygen Orion' Point Release

Mon, 07 Dec 2020 00:00:00 GMT

Overview

This is the v0.17.1.6 minor point release of the Monero software. This is a recommended release that contains P2P network layer improvements.

A note for public RPC node operators upgrading to v0.17.1.6: if you’re using the --rpc-restricted-bind-port option along with --rpc-bind-ip currently you will need to add the new --rpc-restricted-bind-ip arg or else the daemon will bind restricted RPC only to localhost.

Some highlights of this minor release are:

P2P: add scoring system to drop peers that don't behave
P2P: drop peers that decrease claimed height
P2P: drop peers that spam peer lists
P2P: drop peers that don't reply to queries
Add --rpc-restricted-bind-ip option
Do not use peer_id tracking method over i2p/tor
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 19 commits containing 828 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

vtnerd
luigi1111
Snipa
moneromooo
selsta
hyc

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.6.zip, 40e07fdd8af9a8f5c34bddd826e26036c609bf5eacaf337b38e7ac3644647135
monero-win-x86-v0.17.1.6.zip, a63a1ff1766d9f02f8cd4b8260260cec9cfdf8fa1371143cc68ff1ffee18efd1
monero-mac-x64-v0.17.1.6.tar.bz2, 1b03e2e45b9e8fce461b3f33986122c036f636d4a1019c47b24e7b81c7f1db15
monero-linux-x64-v0.17.1.6.tar.bz2, 01bb6e18773a461a4dcfe2a6d4e4f7e1708b26634bc56696d68c539c3a66f81a
monero-linux-x86-v0.17.1.6.tar.bz2, 300e7608927867d63765704a19baa90366b5897e3cef8a56da29ae3a6a5b97a3
monero-linux-armv8-v0.17.1.6.tar.bz2, 874d3de908fb4301de19301b928a1c477a883c40b2491b3b3193df99561a8904
monero-linux-armv7-v0.17.1.6.tar.bz2, 018270d8dde8e895fdc7b5b6de95c36b7e7a63d46406339f810b6fdf91e0b8bc
monero-android-armv8-v0.17.1.6.tar.bz2, 0dc3cc265ae0365cb927c235f9ba4391f3c2be7043d183769de5b9b97736b359
monero-android-armv7-v0.17.1.6.tar.bz2, 2ab2e4c715a3978ed36c55848313f8a252b1f7141910c0bcbd52070fcaefcff1
monero-freebsd-x64-v0.17.1.6.tar.bz2, 1ad59103c9ea3a2256c8f4b7066cefd7ce2ebd2b52360edb539115c80a7e6ee1

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.5 'Oxygen Orion' released

Thu, 26 Nov 2020 00:00:00 GMT

Overview

This is the v0.17.1.5 minor point release of the Monero GUI software. This release improves simple mode reliability.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Simple mode: skip syncing nodes
Write QML cache to portable folder
Linux: enable high DPI support
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 22 commits containing 228 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
Snipa
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.5.zip, a5ed83ffeec340b6695c4dcf0305decd5c419a97572e104c323b956deeac3c3d
monero-gui-install-win-x64-v0.17.1.5.exe, 89e6bad3e8b5b1a57c647f7ddb30ebe4476c74db5730738c0cb7115fb8e44b65
monero-gui-mac-x64-v0.17.1.5.dmg, 7c7812263ab242f954534d062984e63cbe34211d8a6fd7f08e4bacfeb52ad1ec
monero-gui-linux-x64-v0.17.1.5.tar.bz2, 577c5b2bcef436cffb57e4addf3ae9b669733f9aae83dc74f5025c76671667ed

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.5 'Oxygen Orion' Point Release

Wed, 25 Nov 2020 00:00:00 GMT

Overview

This is the v0.17.1.5 minor point release of the Monero software. This is a recommended release that improves Dandelion++ perfomance.

Some highlights of this minor release are:

Change Dandelion++ fluff probability to 20%, and embargo timeout to 39s
Fix timeout checks for forwarded and Dandelion++ stem txes
Improve peer selection in Dandelion++ stem phase
Skip non-synced bootstrap daemons in --no-sync mode
Check imported multisig curve points are in main subgroup
Better log message for unusable anonymity networks
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 25 commits containing 203 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Snipa
moneromooo
xiphon
hyc
vtnerd
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.5.zip, 4bb0fca53bc58c1167bc0a258f61dd69a54507fd83ad37edf4213b4f30df8c94
monero-win-x86-v0.17.1.5.zip, 7dc0565a2880b38e73d85599153a31bbed85965963c6f74e1a5cf6dbd06f619e
monero-mac-x64-v0.17.1.5.tar.bz2, adfc663b2b36b0cb2fdfcc35185b3d93c8c2256de06da01521e555b7b20ee292
monero-linux-x64-v0.17.1.5.tar.bz2, 95666508e695637830b4c1700538c717ff97f02f181fbb337a109763372c8d34
monero-linux-x86-v0.17.1.5.tar.bz2, c5b19fa1db2de6a66e475e634b07f2b5f74d5cd41e968aa0ed34ffd8f91f527f
monero-linux-armv8-v0.17.1.5.tar.bz2, 50f113959bcc230860ff77cbac03a2713db772a72e80afe50f511418f9e9d97f
monero-linux-armv7-v0.17.1.5.tar.bz2, 99fa5eb56616c1b7b6aef69572b8c51efa813bfaff2f2336ac982b449e8ee2a1
monero-android-armv8-v0.17.1.5.tar.bz2, 01998179f2c39d97f4e204b1323c17ca35c5797c558a9c51ad3f8a21c23620fe
monero-android-armv7-v0.17.1.5.tar.bz2, 972f4ed467e34ea783fb66ad6f50749c2b7b3d9f77bb2825e70a8763d84b00f2
monero-freebsd-x64-v0.17.1.5.tar.bz2, 8fead098417cd4d3896012e485494efec8851c28abcb1883c3a1716652390321

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.4 'Oxygen Orion' released

Mon, 09 Nov 2020 00:00:00 GMT

Overview

This is the v0.17.1.4 minor point release of the Monero GUI software. This release fixes an issue with the wallet not starting on some Linux systems.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Linux: fix a deadlock on startup
Linux: high DPI support removed, will be readded in subsequent release

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 6 commits containing 19 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.4.zip, df78006226d21e70ea5d342b0f6d4335cf398e94cb3d0f750aec4db2d2b3f7f9
monero-gui-install-win-x64-v0.17.1.4.exe, 8c9a820fd7dc228807f8ecc46973350d3d5d871c6f8dd67ef066d04407575d14
monero-gui-mac-x64-v0.17.1.4.dmg, 4e319a9dfb5e1caa42b52f6503480af3b44403f3bf4691da523880c6a6ec38a9
monero-gui-linux-x64-v0.17.1.4.tar.bz2, abe94552803fd6646e934d1248e6ef33d8d6e2ac9a725c600fa7e8d4bfcc21a3

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.3 'Oxygen Orion' released

Sun, 08 Nov 2020 00:00:00 GMT

Overview

This is the v0.17.1.3 minor point release of the Monero GUI software. This is a recommended release that improves overall network perfomance.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Android support (experimental)
Linux binary is now reproducible (experimental)
Simple mode: transaction reliability improvements
New transaction confirmation dialog
Wizard: minor design changes
Linux: high DPI support
Fix "can't connect to daemon" issue
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 48 commits containing 1155 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Snipa
rating89us
xiphon
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.3.zip, 0a49ccccb561445f3d7ec0087ddc83a8b76f424fb7d5e0d725222f3639375ec4
monero-gui-install-win-x64-v0.17.1.3.exe, 15ad80b2abb18ac2521398c4dad9b8bfea2e6fc535cf4ebcc60d99b8042d4fb2
monero-gui-mac-x64-v0.17.1.3.dmg, 23405534c7973a8d6908b76121b81894dc853039c942d7527d254dfde0bd2e8f
monero-gui-linux-x64-v0.17.1.3.tar.bz2, 3bed02f9db5b7b2fe4115a636fecf0c6ec9079dd4e9284c8ce2c67d4996e2a4a

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.3 'Oxygen Orion' Point Release

Sun, 08 Nov 2020 00:00:00 GMT

Overview

This is the v0.17.1.3 minor point release of the Monero software. This is a recommended release that improves overall network perfomance.

Some highlights of this minor release are:

Add support for I2P and Tor seed nodes (--tx-proxy)
Add --ban-list daemon option to ban a list of IP addresses
Switch to Dandelion++ fluff mode if no out connections for stem mode
Fix a bug with relay_tx
Fix a rare readline related crash
Use /16 filtering on IPv4-within-IPv6 addresses
Give all hosts the same chance of being picked for connecting
Minor bugfixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 5 people who worked, largely unpaid and altruistically, to put out 40 commits containing 367 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
moneromooo-monero
xiphon
vtnerd

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.3.zip, 3eee0d0e896fb426ef92a141a95e36cb33ca7d1e1db3c1d4cb7383994af43a59
monero-win-x86-v0.17.1.3.zip, c9e9dde61b33adccd7e794eba8ba29d820817213b40a2571282309d25e64e88a
monero-mac-x64-v0.17.1.3.tar.bz2, 79557c8bee30b229bda90bb9ee494097d639d60948fc2ad87a029359b56b1b48
monero-linux-x64-v0.17.1.3.tar.bz2, cf3fb693339caed43a935c890d71ecab5b89c430e778dc5ef0c3173c94e5bf64
monero-linux-x86-v0.17.1.3.tar.bz2, d107384ff7b1f77ee4db93940dbfda24d6045bf59c43169bc81a0118e3986bfa
monero-linux-armv8-v0.17.1.3.tar.bz2, a0419993fbc6a5ca11bcd2e825acef13e429824f4d8c7ba4ec73ac446d2af2fb
monero-linux-armv7-v0.17.1.3.tar.bz2, 57d6f9c25bd1dbc9d6b39fcfb13260b21c5594b4334e8ed3b8922108730ee2f0
monero-android-armv8-v0.17.1.3.tar.bz2, 0e94f58572646992ee21f01d291211ed3608e8a46ecb6612b378a2188390dba0
monero-android-armv7-v0.17.1.3.tar.bz2, 38a04a7bd00733e9d943edba3004e44730c0848fe5e8a4fca4cb29c12d1e6b2f
monero-freebsd-x64-v0.17.1.3.tar.bz2, ae1a1b61d7b4a06690cb22a3389bae5122c8581d47f3a02d303473498f405a1a

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.1 'Oxygen Orion' released

Mon, 19 Oct 2020 00:00:00 GMT

Overview

This is the v0.17.1.1 minor point release of the Monero GUI software. This is a highly recommended release that fixes an issue with nodes getting stuck at block 2210720.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Fix sync past block 2210720
Add "pending" and "failed" transaction status
Simple mode: improve start / stop splash screen
Simple mode: set default out peers to 16
Add armv8-linux release target
Fix wallet getting stuck on close
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 22 commits containing 62 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Snipa
bjacquin
xiphon
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.1.zip, a64fe57d2f0cf6bab49f78c5ae298f71e3fc44777da4e0cd89cd660facce14c2
monero-gui-install-win-x64-v0.17.1.1.exe, 318cec037990d89cec62f2d29ac5827a459d15a638abc5c25cbc3b910337e50f
monero-gui-mac-x64-v0.17.1.1.dmg, ebaecd3b4072c1ef22009dd69290208b5c83b9b597de1a1116bc05564a08a916
monero-gui-linux-x64-v0.17.1.1.tar.bz2, 14f5667e57603f05872a0dcd31a81acd7ffa31b71eb83ba22661bd05e2fc53d1

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.1 'Oxygen Orion' Point Release

Sun, 18 Oct 2020 00:00:00 GMT

Overview

This is the v0.17.1.1 minor point release of the Monero software. This is a highly recommended release that fixes an issue with nodes getting stuck at block 2210720.

Some highlights of this minor release are:

Fix sync past block 2210720
Bump default number of connections from 8 to 12
Wait for propagation timeout before marking tx as failed
Allow setting start block on export with monero-blockchain-export
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 12 commits containing 112 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Snipa
selsta
fluffypony
moneromooo-monero
hyc
xiphon

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.1.zip, e9e14bf95905d1d54fb490c384d50d7c972174d5f6febbfb55811713b8a1a470
monero-win-x86-v0.17.1.1.zip, 4d9fbb3fa5226b4c9928a8aebee9a57e1ca409c8e0499c8901d12dd19417f2d6
monero-mac-x64-v0.17.1.1.tar.bz2, 2b5ce3627e38598c50f90bd73d90346a290035a16fef879c6a1fd88227c44e37
monero-linux-x64-v0.17.1.1.tar.bz2, 4113cc92314fefebe52024d67a8b5d6d499adb4c3988f5d2b838ed3f80893874
monero-linux-x86-v0.17.1.1.tar.bz2, d6bc94a0b07814ccea175e88bd38e51029db9cab1a3483aff71d8b3e00172d3a
monero-linux-armv8-v0.17.1.1.tar.bz2, 30714d8a76880a1a2e587cb18676999502b40af58227e23c6b55a9f2b5a40734
monero-linux-armv7-v0.17.1.1.tar.bz2, 3febba3fce8d51f63e3fc7736cfcce4987f740499baf3e6377182012b07d71d4
monero-android-armv8-v0.17.1.1.tar.bz2, 3eff875c97581edf2d8bc46891565bb3b671a8d04c6c8188f698ac492f713f3c
monero-android-armv7-v0.17.1.1.tar.bz2, b88ccc2db1127e41ea55d3c771f0b1e15abad691209597d8698ebb58c17b2914
monero-freebsd-x64-v0.17.1.1.tar.bz2, 6e1d2557eec3dd7a8e7a7f7f7610555ecbc90a7f3e72ed272e87bb7cc34e383b

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.1.0 'Oxygen Orion' released

Wed, 14 Oct 2020 00:00:00 GMT

Overview

This is the v0.17.1.0 release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this major release are:

Simple mode: fix a bug causing transaction propagation to fail (stuck as pending)
Portable mode: save log to storage folder
Fix a rare crash during wallet refresh
Fix wallet not showing up on recent wallets screen
Fix empty RPATH token issue (Linux)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 3 people who worked, largely unpaid and altruistically, to put out 20 commits containing 186 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
selsta

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.1.0.zip, 85ecd625721435e99fff0f4849ff40bb3f2de26573b50432a5fe9632dfba3026
monero-gui-install-win-x64-v0.17.1.0.exe, be3b1f07ba86a0d46c27f670b27d936baa5c4e7b68f3dc37349b8f91b073dc6a
monero-gui-mac-x64-v0.17.1.0.dmg, b9c0cbdc8f9c74d6205858ccb4fb0f1eec792e301aa819bf8aa445a3d17869d3
monero-gui-linux-x64-v0.17.1.0.tar.bz2, 9076b731634e073430817cd590ea015a19a9cf3336c3c7a7bb16f1fd25b429f4

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.1.0 'Oxygen Orion' Point Release

Wed, 14 Oct 2020 00:00:00 GMT

Overview

This is the v0.17.1.0 point release of the Monero software.

Some highlights of this release are:

Dandelion++: skip desynced peers in stem phase, reducing transaction timeouts
Fix a bug in wallet serialization that could lead to inaccurate display balance
Silence spammy "failed to find tx meta" warning message
Fix next_seed_height in get_block_template RPC
Fix empty RPATH token issue (Linux / FreeBSD)
Reduce minimum required glibc from 2.23 to 2.17 (Linux)
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 6 people who worked, largely unpaid and altruistically, to put out 20 commits containing 135 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
xnbya
moneromooo-monero
hyc
xiphon

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.1.0.zip, b942b584601faa504ed2eb5c6d7bdf62740826cbef63d33d35b48e414dd48f5d
monero-win-x86-v0.17.1.0.zip, d438ce08ebce2705b1de8469833ccda47c76401887751972086246cb3c59f041
monero-mac-x64-v0.17.1.0.tar.bz2, 3e9cefcb02e0fd5f4c720165bf1621ccda48f18eda1f63f207f29a2549658620
monero-linux-x64-v0.17.1.0.tar.bz2, b7b573ff3d2013527fce47643a6738eaf55f10894fa5b2cb364ba5cd937af92e
monero-linux-x86-v0.17.1.0.tar.bz2, e58e1f60120cc9a3be1f6bad95d4605843608630437794c56d705547db2bfd69
monero-linux-armv8-v0.17.1.0.tar.bz2, 487011bc1bdaa9bcc276cdbee0930c2289b317c752a99a38d98c0ad13324a612
monero-linux-armv7-v0.17.1.0.tar.bz2, 2ad46e3834a25f78f1c070220dd1b907200abe57246a7b0cc410b998174e5ed2
monero-android-armv8-v0.17.1.0.tar.bz2, a758c81dfe177c74567e9793e1332adc3e2ce9ae71addb81f1e7f5fcce4303f7
monero-android-armv7-v0.17.1.0.tar.bz2, e0234000ee183656092621066658bece27a49442101755b565f190d4e0d29314
monero-freebsd-x64-v0.17.1.0.tar.bz2, 11577db88edf29d5a09c45599cb43c1da568f63a1303322bf0aecabfaffd48a7

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero GUI 0.17.0.1 'Oxygen Orion' released

Mon, 05 Oct 2020 00:00:00 GMT

Overview

This is the v0.17.0.1 release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this major release are:

Socks5 proxy support, automatically enabled on Tails
Simple mode transactions are sent through local daemon, improved reliability
Portable mode, save wallets + config to "storage" folder
History page: improvements, incoming / outgoing labels
Transfer: new success dialog
CMake build system improvements
Windows cross compilation support using Docker
Various minor bug and UI fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 43 people who worked, largely unpaid and altruistically, to put out 130 commits containing 7836 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
rbrunner7
selsta
xiphon
rating89us
dsc
Italocoin
erciccione
ph4r05

A special thanks to translators

Michael Russo, G.T.S., kombometralla, CharlesCrisco, nemecis rojas, porokon7, Viktor, 78carla, erciccione, Gleb Golov, Agent LvM, solevoy-psih, v1docq47, TheFuzzStone, Russian Bear, translator133, Peter J. Mello, EvolBit, icuntcode, Bertrand Jacquin, el00ruobuob, srk raidu, To Ja, vp11, netrik182, Jaimie, Jonathan Heirbaut, Marcus, obit33, Paul Janowitz, SJ, Wobole, Anonymous, GreenPiece

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.17.0.1.zip, c18a47e6d6c273406ea4cf7cc834982a7905a53021268d4fe503ef95507890b5
monero-gui-install-win-x64-v0.17.0.1.exe, 6250fc57720c6190362fd1cb74e61eb4f765cd8d15c7cc512d48bb15e8fefd51
monero-gui-mac-x64-v0.17.0.1.dmg, 1796d266e7bffed1803531b2aab18ff2162f3925d2d42fbe8c8c98bd687c1bcc
monero-gui-linux-x64-v0.17.0.1.tar.bz2, d7ab169a2cd4177adb5320ea0a8e0fb541a0d1bc6e1dde4a1c4c0710bf736a8c

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.0.1 'Oxygen Orion' Minor Point Release

Sun, 27 Sep 2020 00:00:00 GMT

Overview

This is the v0.17.0.1 minor point release of the Monero software.

Some highlights of this release are:

Fix unintended error message on daemon start (Windows)
Bug and security fixes found by OSS-Fuzz

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 8 commits containing 23 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
moneromooo-monero
xiphon

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.0.1.zip, f59a771efdd5e6bcd74668be9fe6798e1c2effeb38fce1639b24b307a95985cb
monero-win-x86-v0.17.0.1.zip, ac50eb3fb993fd496a1856b01655494b5fe2b0a57a01c432c0c06a996e90058e
monero-mac-x64-v0.17.0.1.tar.bz2, af6737a6d81a2ec3f1ecfb8581e4e615e5a22ad34d808b3191ef488cb90084c1
monero-linux-x64-v0.17.0.1.tar.bz2, 2335716555ff0428da0f206a491d9c57b7ae2221d1cfbbb3bf43960d3a2a4dfe
monero-linux-x86-v0.17.0.1.tar.bz2, 8d2b20c36bf74e5d4d33d20a17dc0811e8ff6f0cb3ef8fb093fb0f430a2aa82c
monero-linux-armv8-v0.17.0.1.tar.bz2, 4805b496019cb74500b68c34457a15b394accfdb33ad97fe8ba0fbb2e83eb711
monero-linux-armv7-v0.17.0.1.tar.bz2, be98deb70f5b8cda364dc37fdd7733c548474bf6baf40e3fbc5b00bc38d56c4a
monero-android-armv8-v0.17.0.1.tar.bz2, 78f5c2f0199533c845a1c060a1888f029df1dbd13bd28e035d02ff83ec3493ae
monero-android-armv7-v0.17.0.1.tar.bz2, 6a41ba50f3eff23343d147a28e2e694e56f257aeffed46cb019ad0dcc71d2a4f
monero-freebsd-x64-v0.17.0.1.tar.bz2, a2c946f4aef22d5dd2637713ebaaf14d9307ae5cb2e8cb016e34bcd997aed2d8

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.17.0.0 "Oxygen Orion" released

Thu, 17 Sep 2020 00:00:00 GMT

Overview

This is the v0.17.0.0 release of the Monero software. This major release is due to the October 17th network upgrade, which in turn adds support for the CLSAG transaction format which improves verification speed and reduces transaction size.

Some highlights of this release are:

Support for CLSAG transaction format
Deterministic unlock times
Enforce claiming maximum coinbase amount
Serialization format changes
Remove most usage of Boost library
Always send raw transactions through P2P, don't use bootstrap daemon
Update InProofV1, OutProofV1, and ReserveProofV1 to V2
ASM optimizations for wallet refresh (macOS / Linux)
Randomized delay when forwarding txes from i2p/tor -> ipv4/6
New show_qr_code wallet command for CLI
Add ZMQ/Pub support for txpool_add and chain_main events
Various bug fixes and performance improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 30 people who worked, largely unpaid and altruistically, to put out 292 commits containing 11523 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

stoffu
François Colas
TheCharlatan
koe
Lee Clagett
Jean Pierre Dudey
MaxXor
rbrunner7
luigi1111
xiphon
erciccione
mj-xmr
thomasvaughan
Age Bosma
cohcho
sumogr
moneromooo-monero
woodser
cryptographicfool
Jason Rhinelander
Norman Moeschter
Sarang Noether
Dusan Klinec
SomaticFanatic
cslashm
selsta
tevador
ArqTras
russoj88
Reinaldulin

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.17.0.0.zip, 8b84b4c9820a9b0f5e010079ceaf622936cbf4a5cec6de099c2dbbaf3cf47b73
monero-win-x86-v0.17.0.0.zip, bd92b31b82d4349416f2bac6d9d76404c526f9e546f90cc9806084badccd9de8
monero-mac-x64-v0.17.0.0.tar.bz2, b07ca7a00373c4b7f151133e5ecd47da8a2ab65bdaa00154311cee8be735fd07
monero-linux-x64-v0.17.0.0.tar.bz2, 29a1a3d2d4a6bcbaccba0a8016be43c36c88523c358c721d9886e1f0c5ae662d
monero-linux-x86-v0.17.0.0.tar.bz2, 390125abd93ad7640e5033a88c34cda618fa4a78eb38156d9f9a29742968f44e
monero-linux-armv8-v0.17.0.0.tar.bz2, 47d7a24a15457ddca2bd5151805f35f000c92d8d216a0aaa31a982d1a68e31c3
monero-linux-armv7-v0.17.0.0.tar.bz2, 95b424be406346acd0422d2a12598d5f7d7033e20dfdb0e123fd75e185bcf76c
monero-android-armv8-v0.17.0.0.tar.bz2, ff9c51f03be4728614a6c4b9ceefe60334dee118c1cd3a96be9af3db30b80cb0
monero-android-armv7-v0.17.0.0.tar.bz2, 620c10c940eb9480f1004b80de6cdf0db0ff402d45ebda07b0677f556d3d8535
monero-freebsd-x64-v0.17.0.0.tar.bz2, a183c9729b4fcf53b29207c218ae39a01f59d4788620bf4227aa3a4adc4312ad

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

'Oxygen Orion' logo made by Monero Outreach

A note on scheduled protocol upgrades

Tue, 01 Sep 2020 00:00:00 GMT

Lately, there has been some misconception about the scheduled protocol upgrade policy as well as the original intent of the policy. The goal of this post is to provide further clarity to stakeholders.

Approximately five years ago, a somewhat formal policy was introduced to provide clarity to the ecosystem with respect to protocol upgrades. The policy essentially outlined that consensus changes would be introduced every six months on a set schedule (whilst allowing for potential reduction in frequency in case of substantial ecosystem growth). Consistently, Monero has performed protocol upgrades regularly in the past to introduce new privacy features or strengthen existing ones. Additionally, various consensus changes such as adjusting the dynamic block size algorithm, improving verification performance, and reducing the size of the range proofs (with Bulletproofs) were introduced. An overview can found in table A1 in the appendix. These consensus improvements have allowed Monero to improve considerably. As a result, Monero today is completely different than it was in 2014.

For a brief amount of time (between April 2018 and March 2019), these consensus updates additionally included changes to the proof-of-work algorithm (so-called tweaks) to preserve ASIC-resistance. We note, however, that these tweaks were merely meant as a stopgap until a long-term algorithm could be implemented. RandomX currently fulfills this role and therefore no further changes to the mining algorithm are planned for the foreseeable future.

Over the last few years, the Monero ecosystem has grown substantially. Monero is supported by multiple third-party wallets, several hardware wallet providers, as well as a plethora of services and exchanges. As a result, maintaining a six-month schedule of protocol upgrades is increasingly difficult and effectively became untenable. Furthermore, continuing this upgrade pace may be detrimental to the ecosystem or inhibit its growth.

The community now feels that the Monero project and protocol have matured sufficiently to warrant a slower frequency; there is loose consensus that balancing the needs of the ecosystem with expectations for consensus changes and feature updates will mean protocol upgrades occur at an interval of about nine to twelve months. Clear advance notice will be given to ecosystem participants to encourage and aid development, testing, and deployment. The aim is to maintain this policy and assess its viability periodically based on the growth of the ecosystem.

Appendix - Table A1 - Overview of major releases and protocol upgrades

Version Number	Name	Protocol Upgrade Date	Consensus Version	PoW Algorithm
Genesis Block	-	2014-04-18	v1	CryptoNight
0.9	Hydrogen Helix	2016-03-20	v2	CryptoNight
0.10	Wolfram Warptangent	2016-09-24	v3	CryptoNight
0.10.1	Wolfram Warptangent	2017-01-05	v4	CryptoNight
0.10.3	Wolfram Warptangent	2017-04-15	v5	CryptoNight
0.11	Helium Hydra	2017-09-15	v6	CryptoNight
0.12	Lithium Luna	2018-04-06	v7	CryptoNight v1
0.13	Beryllium Bullet	2018-10-18	v8+v9	CryptoNight v2
0.14	Boron Butterfly	2019-03-09	v10+v11	CryptoNight-R
0.15	Carbon Chamaeleon	2019-11-30	v12	RandomX
0.16	Nitrogen Nebula	No Protocol Upgrade	v12	RandomX
0.17	TBD	2020-10-TBD	v13	RandomX

Triptych accepted for publication

Sat, 22 Aug 2020 00:00:00 GMT

Contributing researchers to the Monero Research Lab are pleased to announce that the Triptych zero-knowledge proving system for confidential transactions has been reviewed and accepted to the ESORICS CBT 2020 workshop for presentation and publication.

Triptych uses a zero-knowledge proving system to construct a particular type of linkable ring signature that can be used in confidential transaction protocols. Unlike currently-deployed methods like CLSAG, Triptych proofs grow very slowly (logarithmically) as the size of the transaction anonymity set increases. Triptych transactions also benefit from specialized optimizations that allow for efficient verification.

While we are still investigating technical details required for a future deployment of Triptych into the Monero protocol, it is very exciting to see the paper accepted for publication! We hope that the cryptographic community finds it useful.

Resources

Triptych preprint: The original pre-publication paper describing the Triptych algorithms, security model, and security proofs.
Proof-of-concept code (Python): An initial proof-of-concept test implementation of the Triptych algorithms, written in Python. This code has not been reviewed or written with secure implementation in mind! Do not use in production!
Proof-of-concept code (C++): A proof-of-concept test implementation of the Triptych algorithms, written in C++ using the Monero codebase and test framework. This code has not been reviewed or written with secure implementation in mind! Do not use in production!

Monero will experience a network upgrade on 17th October 2020

Tue, 18 Aug 2020 00:00:00 GMT

The next network upgrade will take place on 17th October 2020. Network upgrades are technically hard forks and require all participants in the Monero network to update their software. The new software will be released one month before the network upgrade: 17th September.

This network upgrade will introduce important new features like the new ring signature construction CLSAG, which will reduce the typical transaction size by ~25% and improve typical verification performance by ~10%. Basically, every transaction will be lighter and faster. The complete list of changes and improvements will be released along with the new binaries.

The logs of the meeting where the dates of the network upgrade were decided are available on this website.

Common questions

Q: Hard fork? Does this mean there will be a split and a new coin will be created?
A: No. Hard forks in Monero are made to improve the base protocol, and are non-contentious. There will be no split and no new coin will be created.

Q: What do I have to do to be prepared for this upgrade?
A: A new release will be announced before the network upgrade (around 17th September). You will only have to be using the updated software by the time the network upgrade occurs (17th October). To the end user, it will be like a simple software update.

Q: If I have my coins on a paper wallet, do I have to do something?
A: No. You will simply have to use an updated version of the Monero software when you will decide to move your coins.

Q: Will there be any changes to the PoW algorithm?
A: No. The PoW algorithm will not be affected. Mining will work as before and miners won't need to update their software.

Monero GUI 0.16.0.3 'Nitrogen Nebula' released

Sun, 09 Aug 2020 00:00:00 GMT

Overview

This is the v0.16.0.3 release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

macOS app is now notarized by Apple
CMake improvments
Add support for IPv6 remote nodes
Add command history to Logs page
Add "Donate to Monero" button
Indicate probability of finding a block on Mining page
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 22 people who worked, largely unpaid and altruistically, to put out 71 commits containing 16626 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
xiphon
rating89us
selsta
glv2
erciccione
xmrdsc

A special thanks to translators

8uDD4T, Marius Tanislav, xmoreee, Lana, Michal Poupe, dskch83, anony_xmr, C3Pool, Muge Niu, Anonymous, razorshaman909, Stavros, warraxxx, Georgios Apostolopoulos, bitbooz

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.16.0.3.zip, 371cb4de2c9ccb5ed99b2622068b6aeea5bdfc7b9805340ea7eb92e7c17f2478
monero-gui-install-win-x64-v0.16.0.3.exe, 50fe1d2dae31deb1ee542a5c2165fc6d6c04b9a13bcafde8a75f23f23671d484
monero-gui-mac-x64-v0.16.0.3.dmg, 574a84148ee6af7119fda6b9e2859e8e9028fe8a8eec4dfdd196aeade47e9c90
monero-gui-linux-x64-v0.16.0.3.tar.bz2, 20c03ddb1c82e1bcb73339ef22f409e5850a54042005c6e97e42400f56ab2505

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Monero 0.16.0.3 'Nitrogen Nebula' Minor Point Release

Fri, 07 Aug 2020 00:00:00 GMT

Overview

This is the v0.16.0.3 minor point release of the Monero software.

Some highlights of this release are:

DoS fixes
Add option to print daily coin emission and fees in monero-blockchain-stats
Minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 13 commits containing 143 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
moneromooo-monero
hyc

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.16.0.3.zip, 5d52712827d29440d53d521852c6af179872c5719d05fa8551503d124dec1f48
monero-win-x86-v0.16.0.3.zip, ff094c5191b0253a557be5d6683fd99e1146bf4bcb99dc8824bd9a64f9293104
monero-mac-x64-v0.16.0.3.tar.bz2, 16a5b7d8dcdaff7d760c14e8563dd9220b2e0499c6d0d88b3e6493601f24660d
monero-linux-x64-v0.16.0.3.tar.bz2, cb67ad0bec9a342b0f0be3f1fdb4a2c8d57a914be25fc62ad432494779448cc3
monero-linux-x86-v0.16.0.3.tar.bz2, 49aa85bb59336db2de357800bc796e9b7d94224d9c3ebbcd205a8eb2f49c3f79
monero-linux-armv8-v0.16.0.3.tar.bz2, 6849446764e2a8528d172246c6b385495ac60fffc8d73b44b05b796d5724a926
monero-linux-armv7-v0.16.0.3.tar.bz2, 6df98716bb251257c3aab3cf1ab2a0e5b958ecf25dcf2e058498783a20a84988
monero-android-armv8-v0.16.0.3.tar.bz2, b48918a167b0961cdca524fad5117247239d7e21a047dac4fc863253510ccea1
monero-android-armv7-v0.16.0.3.tar.bz2, 75b198869a3a117b13b9a77b700afe5cee54fd86244e56cb59151d545adbbdfd
monero-freebsd-x64-v0.16.0.3.tar.bz2, 727a1b23fbf517bf2f1878f582b3f5ae5c35681fcd37bb2560f2e8ea204196f3

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

CLSAG audit results

Fri, 31 Jul 2020 00:00:00 GMT

Contributing researchers to the Monero Research Lab and the Monero Audit Workgroup are pleased to announce the results of a recent audit of the CLSAG ring signature construction. As described in this post, CLSAG enables smaller and faster transactions with rigorous security. Users can expect to see these benefits seamlessly integrated into Monero software at the next network upgrade, which will occur in October of this year.

Read the complete audit report by JP Aumasson and Antony Vennard.

What is CLSAG?

Monero uses a signer-ambiguous transaction protocol that includes many cryptographic components. One of these is a ring signature construction called MLSAG. When you generate a transaction, one or more MLSAG signatures are generated to obfuscate the signers and amounts in the transaction.

Monero Research Lab contributing researchers developed CLSAG as a drop-in replacement to MLSAG to improve efficiency. Using some simple but clever mathematics, CLSAG signatures achieve the same functionality as MLSAG signatures, but at a much smaller size. And thanks to some optimizations of the underlying cryptography, Monero software can verify CLSAG signatures more quickly.

Security is also improved. Good cryptographic constructions are built with a formal security model in mind. Security models are a way of formalizing the capabilities of hypothetical attackers, and then rigorously proving that such attackers cannot break particular security properties. In the case of CLSAG, for example, the imaginary attacker is given the ability to corrupt honest users to obtain their keys, and to convince honest users to generate specific transactions of the attacker's choosing. CLSAG is proven secure in a more robust security model than was originally used for MLSAG, and it provides strong confidence in the practical security of CLSAG.

Compared to the current ring signature construction used in the Monero protocol, CLSAG signatures are smaller and faster than before, with rigorous security.

What does this mean?

A network upgrade will take place in October of this year, and will deploy CLSAG signatures as a mandatory consensus requirement. Provided you keep your software updated, you'll start using CLSAG signatures automatically once the upgrade takes place. It will be a seamless change. If you use a hardware wallet like Ledger or Trezor, make sure you also keep it updated with the latest firmware, which is needed to support the upgrade.

The size of Monero transactions depends on the number of previous transaction outputs you spend, and the number of new transaction outputs you generate. Most transactions spend at most two previous outputs and generate two new outputs; these transactions currently take up around 2.5 kB of space on the blockchain. With CLSAG, the same transaction takes only 1.9 kB of space, a 25% improvement!

Whenever your Monero software sees new transactions, it must verify their signatures to ensure the transactions are valid. This is very fast (usually a few tens of milliseconds), but becomes noticeable when a new installation needs to check the entire blockchain. While the exact times depend on how fast your computer or device is, tests indicate that users will see a 20% improvement in signature verification, and at least a 10% overall improvement for typical transactions!

Security audit

Because ring signatures are a critical component of the Monero protocol, the Monero community commissioned a formal security audit of both the CLSAG cryptography (algorithms, security model, and proofs) and the implementation code that will be deployed. The audit was conducted by expert cryptographers JP Aumasson and Antony Vennard, funded by community donations, and conducted with coordination support from the Monero Audit Workgroup and the nonprofit Open Source Technology Improvement Fund. The review process took place in two stages.

In the first stage, the reviewers carefully examined the security of CLSAG as described in its preprint. They concluded that the security model is suitable for the intended use case, and they did not find any evidence of any security issues in the algorithms used. The auditors recommended significant changes to two of the security proofs, which were completed to their satisfaction. They also made several other non-security recommendations to improve the preprint. Updates are included in the current version, and did not require any changes to the implementation code.

In the second stage, the reviewers examined the security of the implementation code. They concluded that the implementation was secure and well written, and is a correct implementation of the CLSAG algorithms. The reviewers made a small number of informational suggestions to simplify the code, but they found no security issues.

This audit provides additional confidence that migrating the Monero protocol from MLSAG signatures to CLSAG signatures can be done safely and securely. Once deployed, users will see more efficient transactions with the same functionality.

We would like to thank the Monero community again for supporting this project.

Thanks to MrMon0cle for designing the CLSAG logo!

Logs for the Dev Meeting Held on 2020-07-19

Sun, 19 Jul 2020 00:00:00 GMT

Logs

<ErCiccione[m]> Ok everybody let's start this meeting. This is an important one since we should decide the date for the upcoming network upgrade and what consensus changes should be included. The agenda is here: https://github.com/monero-project/meta/issues/485
<ErCiccione[m]> Let's have a round of greetings to get an idea of who is here
<SerHack> Hi
<sgp_> Hello
<ErCiccione[m]> Hi everybody
<sarang> Hello
<Snipa> Good morning.
<sethsimmons> Hi all :)
<rbrunner> Grüezi
<ErCiccione[m]> So the main point is to decide what are we going to include in the next release, but before that, would be great to have an overview of the status of CLSAG and related audits.
<ErCiccione[m]> Sarang, go ahead please
<ErCiccione[m]> :)
<sarang> Sure
<sarang> JP and Antony (the reviewers) have completed their audit of the preprint and code
<sarang> They're finalizing the report for public release
<sarang> The preprint has already been updated, and the code does not require any security updates
<sarang> moneromooo is in the process of rebasing the code
<sarang> I've been in contact with folks on the Ledger and Trezor teams throughout the process, since they have their own development and release timelines
<moneromooo> in the process of preparing to get ready to start rebasing the code
<sarang> :)
<ErCiccione[m]> What's the ETA for having it PRd and ready for final reviews?
<sarang> Trezor is pretty much ready to go; they'll need the fork height and can then update firmware, but the Monero-specific development is done
<sarang> Ledger has done most of the work already and has code ready for integration on their side, but it hasn't been completed yet
<sarang> The person I've been working with (Francois) said the team that does the firmware integrations does _not_ have this on their 2-month timeline for some reason
<sarang> and that Francois would not be able to do the integration until after September 21 due to scheduling
<sarang> They're check to see if the Ledger integration team can prioritize this if needed
<sarang> Further, they want a couple of weeks to test after the integration is complete
<sarang> and then can set the fork height and release on whatever timeline they choose
<sarang> Is there a general opinion of when the upgrade should be, ideally?
<rbrunner> Personally I don't see much more argument than "Why wait with improvements" ...
<sarang> It seems like Ledger is the biggest unknown right now
<sgp_> Annoying that Ledger can't do any work for 2 months
<sethsimmons> I'm all for pushing this ASAP once code is ready to go, but if Ledger is #soon we could wait for that.
<sarang> Francois asked for 4 weeks between release and the upgrade height, presumably for prioritizing testing
<ErCiccione[m]> I guess ledger will have to adapt their schedule.
<sgp_ "Annoying that Ledger can't do an"> Yeah no kidding...
<rbrunner> "on whatever timeline they choose" sounds a little, well, harsh
<sarang> but they are unavailable until September 21 to do the rebase and integration
<ErCiccione[m]> Sarang: that's a good idea reguardless and we usually do it afaik
<sarang> rbrunner: I didn't mean that to sound harsh
<sethsimmons> Do we have a "release checklist" for this including these items?
<sarang> I just meant that I don't know what's required for their releases
<rbrunner> Alright :)
<ErCiccione[m]> sethsimmons: the checklist is something good to have. We can discuss that once we have a date :)
<sethsimmons> Ok, I'll start capturing some items for it to circle back to later.
<ArticMine> So we are looking realistically at the end of October?
<sarang> If the Ledger timeline works as I understand it from Francois, it sounds like end of October would be the soonest they could support
<sarang> but it's unclear if that's guaranteed to work for the Ledger team
<sethsimmons> What can we do to get a clearer timeline for them?
<rbrunner> We all on ourselves could do this probably a month earlier, right?
<sgp_> 3 months of notice is extremely generous time
<sarang> sethsimmons: I'm not sure
<sarang> Francois is reaching out to the coin integration team to get a better sense of their prioritization
<sarang> I haven't heard back about this yet
<ErCiccione[m]> It is extremely generous. I wouldn't go beyond three months
<sarang> But part of this seems to be that Francois is not available to do the necessary rebase until after Sep 21 for other reasons
<sethsimmons> And there isn't anyone else at Ledger that can do it?
<sarang> I do not know
<sarang> Someone else previously worked on Monero support with Ledger, but recently passed this on to Francoid
<sarang> *Francois
<sethsimmons> Ah, yes, forgot about that.
<sgp_> What about tentatively saying Oct 1?
<ErCiccione[m]> Sounds good to me
<sarang> I don't think that works
<rbrunner> Maybe depends on Ledger's reaction to that.
<dEBRUYNE> Seems too early
<dEBRUYNE> We also have to account for other wallet providers such as MyMonero
<ArticMine> I would suggest October 31
<UkoeHB_> Spooky
<sarang> If Francois can start the integration right away on Sep 21 and Ledger prioritizes it on their timeline, they'd still want a couple of weeks to test their release with updated Monero code before releasing firmware with the block height
<ErCiccione[m]> I wouldn't base the timeline on ledger's needs. We are giving them planty of time to adapt
<sarang> I agree that at some point the release needs to happen, but I hope there can be as much support as is possible in a reasonable timeline
<dEBRUYNE> I am all for allotting time for third-party wallets etc., but due to Ledger we're basically frozen for 2 months
<ErCiccione[m]> They are a company that makes money on Monero. They ahould adapt on us, not the other way round
<ErCiccione[m]> *should
<rbrunner> I tend to agree. If some entity cannot live with 3 months of advance warning, well, tough.
<ErCiccione[m]> Giving plenty of time is fine. Adapting to their priorities is not
<rbrunner> That's half of our "old" hardfork schedule, after all
<UkoeHB_> There have also been months of advance warning. The code was written a while ago
<sarang> Well, they were also presumably waiting to know of any changes
<ErCiccione[m]> Thanks for the thumbs up on matrix but those don't show up on IRC, please write what's in your mind :)
<sarang> I know that Francois was unavailable to join this meeting today (but said they would read the logs later), but I can present the October 31 and get their thoughts
<sgp_> I still would rather present Oct 1
<sethsimmons> As much as leaving Ledger users out to dry sucks (that includes me), if we give 3m and thats not enough with a lot of extra runway before now I'm not sure thats something we can wait even longer for.
<sarang> Perhaps someone else can do the necessary rebase
<sgp_> Oct 31 is the absolute latest and is very non-ideal
<sethsimmons> Yeah I'd love to hear if anyone else at Ledger can step in
<sarang> They made it sound like rebase and working with Ledger integration team was all that was left to do
<sethsimmons> 2mo without a way to rebase is.. odd
<ErCiccione[m]> I tend to agree woth sgp
<ArticMine> I would make October 31 firm, or maybe something like Oct 20
<ArticMine> but make it firm
<sarang> OK, so working backward from there
<sarang> October 1 is the ideal _fork height_?
<sarang> Not release
<sgp_> Coffee Chat planned on Oct 17. We can make another update edition
<ErCiccione[m]> Oct 17 sounds like a good compromise.
<ArticMine> Yes that seems reasonable
<sethsimmons> That gives them 3+ weeks to rebase/test after their 9/21 date
<sethsimmons> Hopefully that is plenty.
<sarang> So I'd like to know what the proposed dates would be for (a) setting the block height, (b) releasing code, (c) the upgrade height occurring
<sgp_> b) Sept 17
<sarang> Of course, once the Monero code is rebased, they can build and test on a private testnet as they wish
<ErCiccione[m]> Block height 17 oct release one month before?
<dEBRUYNE> sethsimmons: We need a release at least a few weeks in advance of the height
<sgp_> There will need to be another release for Ledger but that's only impactful to Ledger users, not consensus
<dEBRUYNE> Preferably a month or so
<sethsimmons> For sure
<sarang> Note that there's already Ledger-specific code in the current Monero CLSAG branch
<rbrunner> Yes, that would speak for a September 17 release, right?
<ErCiccione[m]> Release 17 sept, hard fork 17 october?
<ErCiccione[m]> Are people ok with that?
<kinghat[m]> does monero have a list of commandments? 11. thou shalt not hold releases for outside entities.
<ArticMine> That makes sense
<kinghat[m]> amen
<rbrunner> And maybe merged our changes into master on August 17? With time to play around on Testnet
<sarang> OK, so when would the height be finalized?
<sarang> Since that needs to go into their dev cycle
<sarang> (this is where a release checklist would be _very_ helpful...)
<ErCiccione[m]> I guess even now if we have a date for the hf.
<sarang "(this is where a release checkli"> I'm compiling a starter as we speak :)
<rbrunner> Seems so, the hardfork height should the be least problem if we have a date :)
<sarang> rbrunner: right, but it needs to happen :D
<sethsimmons> It could vary slightly in timing depending on HR changes, but we could set it now
<sarang> sethsimmons: block times are pretty consistent overall
<sethsimmons> Generally, yes, I wouldn't expect much variance.
<sgp_> Why not pick the exact height shortly before the Sept ~17 release
<sgp_> We did the important part of choosing the date today
<ErCiccione[m]> Does anybody have anything against 17 september release, 17 october hard fork? Otherwise we can officialize it as decided
<sethsimmons> Sounds good to me.
<sarang> OK, so to recap... the intent is to merge all changes by August 17 for testnet, release on September 17, and fork on October 17?
<ArticMine> The release need to have the fork hard coded?
<rbrunner> I think it better has it, yes
<sgp_> Yeah
<sarang> moneromooo: since you're getting all the CLSAG stuff rebased and updated, does that sound reasonable?
<moneromooo> I can do it in time yes.
<sarang> I'll reach out to Francois again with this timeline and see what the Ledger team can prioritize
<sarang> and will reach out to the Trezor team too
<sarang> Trezor basically said "let us know when your code is done and the height is set, and we're good"
<ErCiccione[m]> Nice. Let's keep going then
<sgp_> Trezor sounds awesome haha
<ErCiccione[m]> What other consensus changes do we want in?
<rbrunner> Are there any waiting?
<sethsimmons> Only potential one is BP+, correct?
<sgp_> There were a few more things included in the logs I posted in the meeting issue
<ArticMine> and issue 70 in MRL
<sgp_> Coinbase rings is one I'm pushing for
<moneromooo> I want to straightn out some unlock time stuff, technically a consensus change, but no functional change.
<moneromooo> I've been meaning to do that for a long while.
<sarang> If the freeze deadline is mid-August, I doubt BP+ could safely make it in
<sgp_> moneromooo: sounds good to me :)
<sgp_ "Coinbase rings is one I'm pushin"> What is needed for that?
<sarang> but TBH the size savings aren't so significant as to make that a huge loss
<sethsimmons> AKA could coinbase rings easily make it in in time?
<sgp_> BP+ would also need more review/audit right?
<sarang "but TBH the size savings aren't "> Yeah no need to rush that at all.
<sarang> sgp_: I personally think so, but part of it depends on what the actual diffs from the current code end up being
<sgp_> So no BP+ then
<sarang> When I brought up BP+ earlier (when the preprint came out), the reaction seemed quite "meh"
<sarang> and only now seems to have come up again with the new CCS
<sarang> But no, I would not plan on BP+ for the fall upgrade
<sarang> and certainly don't block for it
<ArticMine> How big are the savings?
<sarang> Something like 90 bytes per single proof
<sarang> Not massive, but not trivial either
<ErCiccione[m]> Ok, so seems that consensus is to keep bp+ out for now.
<ErCiccione[m]> What abut coinbase rings? Do we need more discussion about that?
<sgp_> For coinbase-only rings, luigi supports reducing the coinbase ringsize to only 1
<sethsimmons> I'm still not sure whats still needed for that/how feasible it is to make it into the HF
<sethsimmons> sgp_: can you speak to that?
<sethsimmons> I'm for the change overall, just not sure on details
<sgp_> I can't speak to moo and others' ability to code it in time
<sethsimmons> moneromooo: any idea on timelines for that/is anyone else helping with coding that?
<moneromooo> Nobody is doing this AFAIK. I won't unless MRL clearly says it should be done.
<moneromooo> In which case it's an easy change I think.
<rbrunner> Yeah, reading the IRC notes on the meta issue I was wondering whether there is already our famous "loose consensus" about this, or quite diverging opinions
<sethsimmons> sarang: any feedback on that overall?
<sethsimmons> I've seen back and forth but no clear decision.
<rbrunner> After all it's again some step up in protocol complexity.
<ErCiccione[m]> rbrunner: my feeling too
<ArticMine> I see the question being consensus rather than coding time
<sethsimmons> Appears so :)
<sarang> I marginally support such a change, but it would require pretty hefty testing
<sarang> Since it would affect how outputs are selected in the distribution
<sgp_> This doesn't require a consensus change, but it's related to https://github.com/monero-project/monero/issues/5222
<sethsimmons> coinbase rings requires consensus change, correct?
<sgp_> Yeah
<moneromooo> Yes, if you want nodes to reject those that don't behave.
<sethsimmons> Figured, just wanted to make sure.
<sethsimmons> The main reason I'd like to see it in this upgrade (if we can reach rough consensus) is because its not worth its own HF so would have to wait for another down the line
<sethsimmons> Which could be a while.
<sethsimmons> Would it be worthwhile to separate out a meeting for that discussion?
<sarang> sethsimmons: for which proposal exactly?
<sarang> (too many things flying back and forth)
<sethsimmons> coinbase ring changes
<sethsimmons> SOrry :)
<ErCiccione[m]> I would say let's wait for clear consensus before deciding about coinbase rings in the october hard fork. It's not super urgent anyway and we don't have to decide now.
<sarang> Rushing output selection changes seems unwise
<sarang> but that's not a reason not to do them if desired, of course
<rbrunner> Well, if we want to be able to play with the release on Testnet in 1 month, that's not much time left.
<sethsimmons> True, especially since it seems to need a good bit of testing/verification even after code release
<hyc> you can always setup private testnets
<sarang> The CLSAG changes are significant enough that I think delaying for smaller changes is not worth it
<sarang> Having plenty of time to test CLSAG will be important
<sethsimmons> Definitely agree.
<sgp_> I don't think this would cause a delay; rather no one else seems enthusiastic about it
<sethsimmons> I'm enthusiastic about it :P But there certainly doesn't seem to be strong consensus
<rbrunner> I would rather wait a little and wait for 50+ rings, with Triptych, making some such problems marginal as I see it
<hyc> no clear benefit, nobody knows what the risks actually are. sounds like a bad idea
<sethsimmons> Hmm, hadn't thought about what effect increased ringsizes would have on it in future.
<sgp_> The problem stays and scales, but the convincing ringsize is still larger
<ErCiccione[m]> Alright. I think the general feeling is to not include coinbase rings in the upcoming release. Let's not go in depth about it now, it can be discussed in another meeting :)
<sgp_> Sure, no one else really cares so pass
<ErCiccione[m]> Anything else that we want in? Or any blockers that should be resolved?
<rbrunner> Well, not care sounds harsh, just different weighting of trade-offs maybe
<sarang> sgp_: I do care, and would support a change if implemented and tested carefully
<sarang> I think it's somewhat marginal for heuristics, as I've said elsewhere
<ErCiccione[m]> As far as i understood there shouldn't be blockers, right? The biggest issue right now seems to be ledger that cpuld be late
<sarang> Right, it's not clear when the Ledger release would be available
<rbrunner> Let's see what they come up if a little gentle pressure
<sarang> Yeah, now that there's a date in mind, I'll let them know and see what could be done
<rbrunner> Of an October 17 hardfork
<sarang> Perhaps they hadn't prioritized because no date was known
<sarang> which is understandable
<sarang> And if there are useful coinbase changes and/or BP+, that would make for a nice subsequent release at some point
<sethsimmons> Good point on the subsequent release :)
<rbrunner> So we won't run out of hardforks anytime soon :)
<sethsimmons> Gotta keep the FUD alive :D
<ErCiccione[m]> Alright. So, let's start talking about splitting duties. Wpuld be good to have a checklist of stuff that needs to be done and people willing to take care of it
<sarang> Yeah, a while back I brought up the idea of a checklist
<ErCiccione[m]> We don't necessarely have to decide everything now, but wpuld be good to start
<sarang> Where assignments can be made for who is responsible, and when, etc.
<ErCiccione[m] "Alright. So, let's start talking"> I have a WIP checklist I can share if you'd like.
<sarang> and hopefully avoid a lot of the small errors and problems that happen from time to time
<sarang> e.g. "the hashes don't match" etc.
<sethsimmons> And I'm happy to own some of the administrative tasks (contacting entities, etc.)
<rbrunner> Didn't fluffypony hand over something a while ago?
<ErCiccione[m]> sethsimmons: yes please we can then integrate it with some that are already around (fluffypony has one)
<sarang> rbrunner: he had a few things, yes
<sarang> Having an ongoing list would be great, and any issues that arise can be added to avoid in future releases
<sethsimmons> Let me post to a pastebin site
<sethsimmons> Copy paste will end poorly for you IRCers
<sarang> yeahhhhh
<sethsimmons> https://paste.centos.org/view/84f18a65
<sethsimmons> Initial list
<sethsimmons> Very WIP
<hyc> hmmm. Can post an instance of the checklist for each release
<hyc> on gitlab
<sethsimmons> I'm sure I have some steps out of order etc
<hyc> and make each point an unresolved thread
<hyc "on gitlab"> Yeah that would be the intent
<hyc> and then resolve them as they are taken care of
<sethsimmons> Host it in an issue perhaps with MD checklist
<sarang> something something gantt chart
<sethsimmons> *meta issue
<rbrunner> Soon we will end up on JIRA
<sethsimmons> I'm a JIRA admin dont tempt me
<hyc> JIRA - where software projects go to die
<sethsimmons> :P
<sarang> GitHub supports basic kanban boards
<ErCiccione[m]> I would say a basic kanban on github would do it. We could link issues to it and assign issues to prople
<sethsimmons> Should I open a meta issue to work through the creation of the checklist?
<sethsimmons> So we can have discussion/updates/etc.
<rbrunner> Sounds good
<sarang> Ah, a checklist checklist
<sethsimmons> XD
<sethsimmons> We've gone too deep
<ErCiccione[m]> Lol, but i do think would be useful
<sethsimmons> Any initial feedback on the first stab at the list?
<sgp_> I have a self-hosted Wekan available (Trello clone)
<sethsimmons> If not I'll open the issue now and we can iterate as needed.
<sarang> Ledger/Trezor coding is a bit more abstract
<sarang> Unless you mean "on the Monero codebase"
<ErCiccione[m]> sgp_: i would keep it simple and just create one on github. Also much more visible
<sarang> e.g. there's Ledger-specific code in Monero
<sarang> as a device option
<sethsimmons> I'll break that into our end and their end
<sethsimmons> < https://matrix.org/\_matrix/media/r0/download/matrix.org/ioQposdWvgLsHrglHKedyYMn >
<sethsimmons> Oof that didn't paste well
<sethsimmons> https://paste.centos.org/view/29c74c53 <- Better?
<sarang> Wallets should be informed as early as possible IMO
<sarang> As should exchanges
<sethsimmons> Right after fork height, or tagging?
<sarang> Seems that exchanges operate at the speed of a glacier as it is
<sarang> I'd say right at fork height, so they can plan for it
<sethsimmons> done.
<sarang> Even if they don't start working right away, then they at least know when to expect the release and the upgrade
<sethsimmons> Any last updates? Don't wanna derail this meeting too much with the first take on it.
<ErCiccione[m]> Alright. I would say we can conclude the meeting
<ErCiccione[m]> The discussion about the checklist can continue after or directly on the meta issue
<sarang> OK, what are action items on this?
<sarang> I'm going to contact Trezor and Ledger folks ASAP with these dates
<ErCiccione[m]> Nope, we are done.
<ErCiccione[m]> Thanks everybody for participating. You are free to go back to your sundays :)

Monero GUI 0.16.0.2 'Nitrogen Nebula' released

Fri, 10 Jul 2020 00:00:00 GMT

Overview

This is the v0.16.0.2 release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this minor release are:

Ledger: fix transfer with multiple inputs
CMake improvements
Minor security relevant fixes
Various bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 4 people who worked, largely unpaid and altruistically, to put out 45 commits containing 403 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
selsta
xiphon
rating89us

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.16.0.2.zip, 6e0efb25d1f5c45a4527c66ad6f6c623c08590d7c21de5a611d8c2ff0e3fbb55
monero-gui-install-win-x64-v0.16.0.2.exe, d35c05856e669f1172207cbe742d90e6df56e477249b54b2691bfd5c5a1ca047
monero-gui-mac-x64-v0.16.0.2.tar.bz2, 142a1e8e67d80ce2386057e69475aa97c58ced30f0ece3f4b9f5ea5b62e48419
monero-gui-linux-x64-v0.16.0.2.tar.bz2, 9ff8c91268f8eb027bd26dcf53fda5e16cb482815a6d5b87921d96631a79f33f

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

General Fund Transparency Report (2019 - June 2020)

Tue, 30 Jun 2020 00:00:00 GMT

Monero General Fund Transparency Report

Welcome to the first Monero General Fund Transparency Report. The Core Team would like to put out consistent reports about the usage of the general fund.

Since the Core Team has changed since the general fund’s inception, and the memories can be a bit hazy for time periods long gone, we have decided that our first report will cover the periods of 2019-2020, with subsequent reports coming out every half-year.

We do apologize for the delay on getting this report out. There were a few finer details in 2019 that needed to be tracked down. That should be a one time thing, and it will be easier to put out more consistent reports going forward.

2019

There were ten outgoing transactions in the entirety of 2019. Five were for the ARM Buildbots, and totaled 55.1295 XMR.

Four were for server costs, which include payments for the CDN, Seed nodes, Mac servers, and web hosting costs for the site, infrastructure, and downloads. This totaled 631.971924‬ XMR.

The last outgoing transaction was paying for Diego “rehrar” Salazar’s salary and totaled 118.778154 XMR.

Due to availability of Core Team for salary payments, much of Diego’s salary came from the CCS Wallet and will be reimbursed from the general fund. The current owed amount to the CCS wallet from the general fund is 565.95775401 XMR.

2020

The only outgoing transactions from the general fund as of July 1st, 2020 were for payments of Diego “rehrar” Salazar, totaling $7000 USD per month at the exchange rate at time of payment. There have been no other outgoing transactions.

Incoming Donations

Donations primarily come in the form of small donated outputs, many times less than 1 XMR. There are a few larger donations as well. Thank you to all donators who are supporting the general fund and Monero development in general.

All-in XMR!

As you may know, both a BTC and an XMR address are available for donations on getmonero.org. The Core Team decided, on February 14th, to exchange all BTC (and fork derivatives) to XMR. Bitcoin donations of course remain possible and encouraged!

LocalMonero

LocalMonero pays an equivalent of $100 a month to the general fund to sponsor the Revuo Monero, a weekly Monero newsletter put out by the Core Team. In exchange their logo is given space at the bottom of the newsletter, as well as taking advantage of the search engine optimization the Revuo gives by putting it on their site https://localmonero.co and having the Revuo site (https://revuo-monero.com) give a canonical link to their site.

Further comments on the state of the general fund

At present, the general fund’s outgoing transactions have been reduced, as Globee and Tari Labs are generously taking over Monero’s server and CDN costs. This leaves Diego “rehrar” Salazar as the primary recipient of funds on a monthly basis. It is being discussed about whether or not to use general fund money to have a back up of the Github repository as well via the subscription service https://backhub.co.

It is also being considered to have the general fund act as a volatility buffer for Monero Research Lab proposals as well as audits.

Donations accepted

If the infrastructure provided by donations (including contributions of rehrar to help all contributors and working groups reach their full potential) has been useful to you, consider donating to the general fund. The Core Team does its best to use funds efficiently to support and further the development of the Monero project. Of course the Core Team is entirely unpaid.

If you are a business of any kind and wish to be a sponsor to the Monero Project, or make a special arrangement for resource access, please contact any of the Core Team or rehrar, let's explore options together.

Current balances

As of June 30th 2020, the balance in the Monero wallet of the general fund is 2108.12 XMR and the balance in the Bitcoin wallet is 0.187 BTC.

Monero 0.16.0.1 'Nitrogen Nebula' Minor Point Release

Fri, 26 Jun 2020 00:00:00 GMT

Overview

This is the v0.16.0.1 minor point release of the Monero software.

Some highlights of this release are:

Ledger: fix transfer with multiple inputs
Trezor: add support for sweep_single
Blockchain: fix timestamp / difficulty cache getting out of sync
Various minor bug fixes

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 7 people who worked, largely unpaid and altruistically, to put out 31 commits containing 94 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

ph4r05
selsta
luigi1111
moneromooo-monero
vtnerd
grydz
Parean

Official Download Links

The new binaries can be downloaded from the Downloads page or from the direct links below.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.16.0.1.zip, 851b57ec0783d191f0942232e431aedfbc2071125b1bd26af9356c7b357ab431
monero-win-x86-v0.16.0.1.zip, e944d15b98fcf01e54badb9e2d22bae4cd8a28eda72c3504a8156ee30aac6b0f
monero-mac-x64-v0.16.0.1.tar.bz2, d226c704042ff4892a7a96bb508b80590a40173683101db6ad3a3a9e20604334
monero-linux-x64-v0.16.0.1.tar.bz2, 4615b9326b9f57565193f5bfe092c05f7609afdc37c76def81ee7d324cb07f35
monero-linux-x86-v0.16.0.1.tar.bz2, 3e4524694a56404887f8d7fedc49d5e148cbf15498d3ee18e5df6338a86a4f68
monero-linux-armv8-v0.16.0.1.tar.bz2, 83c21fe8bb5943c4a4c77af90980a9c3956eea96426b4dea89fe85792cc1f032
monero-linux-armv7-v0.16.0.1.tar.bz2, 962f30701ef63a133a62ada24066a49a2211cd171111828e11f7028217a492ad
monero-android-armv8-v0.16.0.1.tar.bz2, d9e885b3b896219580195fa4c9a462eeaf7e9f7a6c8fdfae209815682ab9ed8a
monero-android-armv7-v0.16.0.1.tar.bz2, 8e3ce10997ab50eec2ec3959846d61b1eb3cb61b583c9f0f9f5cc06f63aaed14
monero-freebsd-x64-v0.16.0.1.tar.bz2, 4f4a2c761b3255027697cd57455f5e8393d036f225f64f0e2eff73b82b393b50

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Logs for the MRL Meeting Held on 2020-06-24

Wed, 24 Jun 2020 00:00:00 GMT

Logs

<sarang> First, GREETINGS
<ArticMine> Hi
<I3^RELATIVISM> 0/
<Isthmus> Greetings
<sarang> All right, on to ROUNDTABLE, where anyone is welcome to share research of interest
<sarang> Who would like to go first?
<sarang> Isthmus:?
<Isthmus> Heyo
<Isthmus> Update on quantum audit, here is our preliminary analysis existing vulnerabilities. (Results subject to change as research progresses!)
<Isthmus> https://usercontent.irccloud-cdn.com/file/RKKVcmGZ/image.png
<Isthmus> https://usercontent.irccloud-cdn.com/file/ZPskux3i/image.png
<Isthmus> It's kind of a mixed bag, tbh.
<sarang> To be expected, I suppose
<sarang> There are many components of interest
<Isthmus> Our reliance on DLP is the biggest weak spot right, as expected
<sarang> ya
<Isthmus> That's all on that, any Q's?
<sarang> By "ring signatures" I assume you mean a quantum adversary identifying signing indices via key images?
<Isthmus> Yea (or via any mechanism)
<Isthmus> Oh, one thing that we started wondering about
<Isthmus> If you're creating a multisig transactions and one of the signers has a quantum computer, can they gain any extra information about their co-signers
<sarang> Well, you can just derive the whole private key
<sarang> if that's what you mean
<Isthmus> Yea. I need to sit down with ZtM2 to figure out what's passed around, and what should be unknown, just crossed my mind yesterdy
<sarang> That's a good point
<sarang> I don't think anyone had specifically mentioned the multisig process during the planning stages of your analysis
<Isthmus> Yea, we just added it. Will probably realize 1 or 2 more aspects to check throughout the next few weeks
<Isthmus> Keep dropping us your ideas :- )
<sarang> Are there particular assumptions made about whether or not the adversary has a public key already?
<sarang> e.g. the adversary suspects a particular address as a destination
<Isthmus> I'm assuming that the adversary is a co-signer on the multisig transaction. They would know the public key with or without a quantum computer, right?
<Isthmus> [erm, well we can consider the adversary both ways, this is just what I had been wondering about yesterday]
<sarang> I mean in general, sorry
<sarang> Not specific to multisig
<Isthmus> Ah yea, quantum computer with your public key and quantum computer without your public key are two adversary models that are considered separately.
<Isthmus> Though TBH the first one is pretty (sadly) easy
<Isthmus> Public key --> [shor's algorithm] --> private key --> init wallet --> game over
<sgp_> sorry I'm late
<sarang> And not even "your" public key
<sarang> But just looking at a given transcation on chain
<sarang> If the adversary's goal is to identify as much as possible about keys, addresses, etc.
<sarang> Sending wallet address, receiving wallet address, etc.
<Isthmus> Yea, if an outside observer plucks a transaction at random from the blockchain, with no further knowledge, what can they ascertain about 1) the sender, 2) the transaction, 3) the recipient
<sarang> Right. And then what can they learn if they have an idea of possible addresses
<Isthmus> Bingo
<sarang> I assume that there is (or will be) a more specific write-up with details on what relates to this chart?
<UkoeHB_> Earlier I argued you could brute force output amounts if the DLP is broken (assuming recipient address is unknown), however I'll retract that. Output amounts are information-theoretically secure.
<Isthmus> Gotcha
17:23:44 * Isthmus makes a note
<Isthmus> Yeah, this will all be in the research writeup, and more intuitive parts will be included in the general audience writeup
<sarang> Anything else to consider about your analysis at this point Isthmus?
<Isthmus> We were thinking about some medium articles throughout, just for good measure
<Isthmus> Nope, that's all on the quantum end for now
<sarang> OK great!
<Isthmus> I started going down a rabbit hole of subliminal channels this morning, but will save those thoughts for later
<sarang> Did anyone else wish to present research of interest?
<UkoeHB_> This means even if both DLP and hash preimage are broken, there should not be a way to extract the recipient's address from an output.
<Isthmus> That's a huge relief, or else we could recursively apply Shor's algorithm and move forward through the transaction tree breaking everybody's wallets
<sarang> I'll share a few things
<sarang> Here's a time-windowed CDF of spend age: https://usercontent.irccloud-cdn.com/file/5EccXpmE/cdf\_window.png
<sarang> Still tracks the gamma distribution pretty well, but there are differences over time (pre-CT)
<sarang> Related to this, I posted my tracing code: https://github.com/SarangNoether/skunkworks/tree/tracing
<sarang> It now supports iterative updates, which may be useful
<sarang> Unrelated to this, I'm still working with the CLSAG auditors
<sarang> I rewrote the proof for Theorem 1 that relates unforgeability to non-slanderability, and it now addresses the auditors' suggestions
<sarang> There are a bunch of other non-security-related updates to it
<sarang> and I'm now in the process of overhauling the linkability anonymity proof to use a better hardness assumption and method, which is a tedious process
<sarang> but I think that will address their comments and be a stronger result
<sarang> The auditors' conclusion is that the construction seems secure, and that the security model seems appropriate to the use case
<sarang> This was the overall goal of the audit; suggestions relating to presentation, formality, etc. are very useful for later submission, but don't appear security-related
<UkoeHB_> Sounds like the audit is moving along well
<sarang> It is! The code review portion has not begun yet, but there are no changes in code to be made as a result of the preprint audit at this point
<sarang> Any questions on these research topics?
<sarang> OK, did anyone else have anything to share before we move on?
<sgp_> nope
<sarang> If not, we can move on to ACTION ITEMS for the coming week
<sarang> I will be finishing up this linkable anonymity overhaul and incorporating it into the preprint, which will complete the updates needed for the auditors
<sarang> Once that's done, I'll get the preprint in a submittable state
<sarang> Anyone else?
<sgp_> I'll be opening a GitHub issue for segregating coinbase outputs into coinbase-only rings
<sarang> It's a good time to discuss this, with an upcoming network upgrade for CLSAG at some point
<sgp_> yeah I think so too
<sarang> especially given the spend-age data
<sarang> I'd still love to see the corresponding data for bitcoin
<sarang> but I don't have that dataset
<sarang> all the Monero data is necessarily pre-CT because of deducibility
<sarang> and any post-CT deducible data spends old funds and is therefore basically useless for those kinds of distributions
<sgp_> I've been pretty clear that I think this BTC data would be nice but isn't necessary to make this change
<sarang> understood
<sarang> OK, anything else before we adjourn?
<UkoeHB_> Isthmus I have to walk back my walkback (sorry for the interruption sarang). You can definitely brute force it if the DLP and hash preimage are broken. Information-theoretic security means nothing in the face of brute forcing all possibilities (64 bits worth). You'd 1) get the DLP of generator H and the commitment C, 2) pick an amount, 3) compute the possible derivation to scalar, 4) get its hash preimage,
<UkoeHB_> 4a) use the key sequence of bits from the preimage to test the encoded amount and only continue if it matches the guessed amount (very unlikely to match if the guessed amount isn't correct) 5) use the key sequence of bits from the preimage to compute the one time address derivation to scalar, 6) subtract it from the one time address private key to get the nominal private spend key, 7) get the DLP of the
<UkoeHB_> preimage key with respect to the tx pub key to get the nominal private view key, 8) test if the spend key can produce the view key directly (normal address) or if any reasonable sub address index can be used to extract a spend key that produces the view key, 9) repeat 2-8 until you get a match (step 4a will probably catch most mistaken guesses). Let's blame this mishap on a stray synapse.
<sarang> hmm
<Isthmus> ohhhhhh
<sarang> IIRC preimage on keccak is something like O(2^100) or so
<sarang> but I'd have to check on that
<Isthmus> Unrelated: Does ZtM2 talk about variable types or just math? Trying to figure out if fees are uint64 or what
<UkoeHB_> They are varints, which I mention in section 6.3 footnote iirc
<Isthmus> Ah, perfect. Thanks!
<sarang> Righto, let's go ahead and adjourn since it's now 18:00 UTC
<sarang> Thanks to everyone for participating!

Logs for the Community Meeting Held on 2020-06-20

Sat, 20 Jun 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<needbrrrrrrr90> If I end up afk just ping me repeatedly and my phone will buzz
<endogenic> o hi
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<needbrrrrrrr90> And I'll wake up
<binaryFate> hello
<endogenic> needbrrrrrrr90:
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/475
<needbrrrrrrr90> Hi!
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<needbrrrrrrr90> Sup
<sarang> Hello
<xmrscott[m]> Osu~
<endogenic> osssssu
<needbrrrrrrr90> Missed the last two meetings because I overslept and 10am is too early
<needbrrrrrrr90> Glad to be here :D
<rehrar> hi
<needbrrrrrrr90> Osu is great
<needbrrrrrrr90> Everyone dead :(
<endogenic> ossu
<needbrrrrrrr90> Should we ping
<midipoet> hello
<endogenic> needbrrrrrrr90:
<sgp_> thanks everyone for being here!
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> Check out resources at https://communityworkgroup.org. It also has a calendar you can subscribe to for meeting reminders.
<sgp_> asymptotically was an absolute champ and uploaded meeting logs for the past 6+ months to the getmonero.org website!
<3
<sgp_> ErCiccione, fort3hlulz, xmrhaelan, geonic, wowario, and others have been sharing information about Monero with the #DidYouKnowMonero hashtag. Please participate if you are on Twitter https://twitter.com/search?q=%23DidYouKnowMonero
<sgp_> Does anyone have community (non-workgroup) updates to share?
<rehrar> question regarding that. This week there wasn't much news. :( anybody have news to share?
<rehrar> Revuo for this past week not out yet. I'll put it out now. But there was only one news item (Iranian exchange)
<msvb-web> Hello everyone.
<needbrrrrrrr90> Hey Michael
<rehrar> so we did draw a Monero fox to compensate, but if anyone had another news item please let me know
<ajs-mob> hi
<sgp_> rehrar: when will your Mainnet talk be public?
<rehrar> OH! Yeah! It is public, no?
<rehrar> or was the link I sent unlisted?
<sgp_> the link you sent me was unlisted
<rehrar> oof, then idk
<sgp_> did they get back to you on formatting?
<rehrar> no. I emailed. No response.
<rehrar> I'll email again.
<binaryFate> rehrar: website got netlify, maybe worth a news
<ErCiccione[m]> Sorry i'm late but i'm here
<rehrar> binaryFate: so any changes made are automatically pushed?
<binaryFate> no, but when people make a PR, a version of the website with that PR is automatically built
<sgp_> rehrar: is the CLSAG audit being funded already represented?
<binaryFate> and linked from PR on github
<needbrrrrrrr90> That's neat
<rehrar> I haven't in the past used a proposal being funded as a news item, but I guess I can
<binaryFate> ErCiccione[m] knows details and took care of most of the netlify stuff
<rehrar> cool
<rehrar> ok
<sgp_> haha idk, just trying to offer suggestions
<rehrar> want to see the fox?
<fort3hlulz> Netlify helps with docs updates, since we'll get to see a build with it correct?
<sgp_> this workgroup has a Twitter, maybe shill that
<rehrar> it's cute
<sgp_> yeah of course
<fort3hlulz> Rehrar it would be great to share about the twitter campaign in there too IMO
<rehrar> https://usercontent.irccloud-cdn.com/file/07BIwpc4/monerofox-sticker.png
<sarang> aww
<sgp_> that's soooooooo cute!
<fort3hlulz> Hahaha
<midipoet> remind me of Mozilla. Maybe that's the idea though
<fort3hlulz> Well done
<sgp_> I want a shirt
<binaryFate> cuty
<sgp_> and a blanket
<ErCiccione[m]> I can give a quick update about what netlify is later when it's time to give updates about the website
<sgp_> ErCiccione[m]: ty :)
<fort3hlulz> Could you also post about it in Reddit @erciccione?
<netrik182[m]> hi sgp_. sorry for being late
<ErCiccione[m]> Does it worth to make a dedicated post? i was thinking of including it in my usual monthly (more or less) update
<sgp_> I agree with that mostly
<sgp_> anything else on this section?
<sgp_> 4. Workgroup report
<sgp_> is selsta here?
<sgp_> a. Daemon/CLI/GUI workgroup
<selsta> yep for a short update at least
<sgp_> sweet :)
<selsta> we are preparing v0.16.0.1 with small bug fixes
<selsta> also mooo managed to fix a super rare bug that has existed for ages
<selsta> (difficulty drift bug)
<rehrar> moneromooo is kinda bae
<selsta> apart from that nothing major
<sgp_> I accidentally skipped the CCS section, so that will be after the workgroup updates
<msvb-lab> rehrar: What is 'bae'?
<rehrar> slang for 'baby'. It means he's awesome.
<sgp_> thanks selsta
<sgp_> b. Localization workgroup
<ErCiccione[m]> We have a lot of suggested strings on Weblate that need to be reviewed. So basically if you can, go on https://translate.getmonero.org and review the strigns people suggested
<ErCiccione[m]> It's only a matter of giving an upvote of a downvote
<ErCiccione[m]> it's a pity to see so many suggestions and lack of reviewers
<fort3hlulz> Do you normally need English reviews?
<ErCiccione[m]> some languages are compltely translated (for example norwegian), but need a reviewer to
<fort3hlulz> Or only other translations?
<ErCiccione[m]> Only other languages. If we want to change english strings we have to do it directly on the repo, whatever it is
<fort3hlulz> Ah, ok.
<ErCiccione[m]> forgot to complete the sentence earlier: "we need a reviewer to confirm and review the translations"
<ErCiccione[m]> if anybody needs help, support or have question, #monero-translations is the place to go
<ErCiccione[m]> That's it. Review review review :)
<sgp_> c. Website workgroup
<sgp_> keep going :p
<ErCiccione[m]> :P
<ErCiccione[m]> so, as binaryfate said, now we have a netlify integration
<ErCiccione[m]> which means that once a PR is opened, Netlify will build it and show a preview of how the website will look like
<ErCiccione[m]> then a bot will comment under the PR with a link to the preview
<ErCiccione[m]> you can see it working here: https://github.com/monero-project/monero-site/pull/1027
<sarang> What are the "neutral checks" on the CI?
<ErCiccione[m]> I think that's supr useful because allow peopel to immediately see how the changes will look like and will allow people without a build environment for the website to have an overview of the changes
<fort3hlulz> That's pretty awesome!
<fort3hlulz> Super important to get more docs/site contributions.
<fort3hlulz> Now I need to actually dig into the docs...
<ErCiccione[m]> sarang: neutral checks?
<sarang> The CI shows some checks labeled "neutral"
<ErCiccione[m]> fort3hlulz: yes that was my main goal: getting more people to take a look at the website repo :)
<sarang> Header rules, etc.
<ErCiccione[m]> ooh, ok, i don't see the neutral, but those are just some netlify standard checks. I deactivated most of them to have a superquick buld (2-3 minutes) and we don't need them anyway
<sarang> Got it
<ErCiccione[m]> What we car about it's mostly only the preview
<ErCiccione[m]> *care
<ErCiccione[m]> can be optimized a bit, especially because we have limited build time (300 minutes)
<ErCiccione[m]> so we can remove builds for stuff we don't care about, like the readme
<ErCiccione[m]> i will look into it in the future. For now it's working exactly as it should
<fort3hlulz> Per month? Or what period?
<binaryFate> we could ask if they want to be listed as sponsor for giving us higher tier for free. That seems pretty useful and they would get some good noise from monero people on twitter etc
<ErCiccione[m]> per month, yes
<fort3hlulz> Good idea @binaryFate
<ErCiccione[m]> binaryFate: that's a good idea
<fort3hlulz> Or if not, we could do a CCS for it, would expect it to be funded.
<sarang> What would the cost be?
<ErCiccione[m]> yeah, the next tired is supercheap anyway
<ErCiccione[m]> looking that up
<binaryFate> 45$/month
<selsta> $7/500 minutes build minutes
<ErCiccione[m]> not supercheap but not expensive: $45 a month
<rehrar> Ok. I'll contact then.
<selsta> we don’t need the next tier if we only use it for deploy
<ErCiccione[m]> https://www.netlify.com/pricing/
<selsta> for preview*
<rehrar> selsta but we can have it!!!
<ErCiccione[m]> A "pro" plan would also allow us to add people to the team. It's not supr important, but would allow me to have aces to the settings
<binaryFate> right now we're good for ~100 PR / month
<binaryFate> probably ok?
<selsta> Seems okay for now.
<ErCiccione[m]> yeah calculated at the time and we should be good, with even some extra time
<ErCiccione[m]> iiirc we should be able to manage double the PR volume we currently have
<sgp_> cool
<sgp_> anything else?
<sgp_> I don't think anyone is here from the outreach workgroup, so we can skip that section
<sgp_> e. Monero Research Lab
<ErCiccione[m]> Since we are at it, i want to remind that the PR which changes the homepage is still open and waiting for reviews
<ErCiccione[m]> https://github.com/monero-project/monero-site/pull/948
<ErCiccione[m]> i will force push it to trigger the netlify preview
<ErCiccione[m]> that's it
<sgp_> thanks :)
<sgp_> sarang, do you have a quick update?
<sarang> I did a bunch of analysis work on transaction history, transaction types, and spend patterns in support of output selection updates
<sarang> and have been updating the CLSAG preprint in response to audit draft results
<sarang> We can use the results of the analysis work to better influence future decisions on building transactions safely
<sgp_> let's get those coinbase-only rings :p
<sarang> The analysis suggests that coinbase spend patterns (in terms of age) don't differ from non-coinbase, which is an interesting and somewhat unexpected result
<sarang> I also know that Isthmus and friends have been working on their post-quantum research
<sarang> but I don't want to speak for them
<sgp_> thanks, anything else?
<sarang> Nothing major that isn't boring math =p
<sgp_> f. Monero Defcon Village
<sgp_> msvb-lab
<msvb-lab> Hello, thanks sgp.
<msvb-lab> Those of us who have attended all the Monero Village (at #monero-defcon channel) meetings, can please decide if you want special privileges on the Defon Discord server.
<msvb-lab> If you do, please:
<msvb-lab> #1 Create a Discord account, #2 Navigate https://discord.gg/defcon, #3 Find me 'Michael' on the 'linecon' channel of the Defcon Discord server. #4 Say hello to me, please.
<msvb-lab> That helps me find your unique ID, and that is what Defcon Goons need to secure your place in the Monero Village channel of the Defcon Discord server.
<rehrar> Ok. I will do that. Thanks.
<msvb-lab> Any questions about that?
<sgp_> He is Michael#7293
<sgp_> no questions
<msvb-lab> sgp: Michael#7293 is a clonable id, any imposter can take that. The real ID requires green magic to obtain, and is 18 numbers long.
<msvb-lab> Okay, just please all village staff who want privileges try to help by doing this in the next days. I'll try to pay attention in EU timezones to the channel.
<sgp_> any other Defcon updates?
<msvb-lab> Or find out your real 18 digit ID and send me email michael⊙go
<msvb-lab> sgp: Only updates about the intervillage electronic badge, but it takes too long to report.
<msvb-lab> So it might be best to go to the next agenda topic sgp? Or no?
<sgp_> only things that are relevant for a community meeting I guess. Defcon has its own meetings too obviously
<sgp_> okay, moving on then
<sgp_> 3. CCS updates
<sgp_> The CLSAG Audit funds transfer to OSTIF has occurred without unforeseen issues. OSTIF converted ~172 XMR to USD. The excess XMR were donated to the Monero General Fund.
<sgp_> Funding required:
<sgp_> Sarang: research funding for 2020 Q3 (487.73 / 518 XMR) https://ccs.getmonero.org/proposals/sarang-2020-q3.html
<sgp_> Defcon equipment storage for one year (6 / 13 XMR) https://ccs.getmonero.org/proposals/defcon-storage.html
<sgp_> Ideas (to be discussed):
<sgp_> ErCiccione: 3 more months part time work on Getmonero.org (July-Sept) (132 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/153
<sgp_> approved, next :p
<ErCiccione[m]> 😛 I'm here for any question
<sgp_> people have 5 seconds to add an objection, else I'm assuming unanimous approval
<rehrar> Ye
<sgp_> ok, done with CCS stuff
<sgp_> 5. Open ideas time
<sgp_> It’s open ideas time. What’s something we should be doing better?
<ErCiccione[m]> Superquickly before the next point, i forgot to post the link to my reddit post with the recent updates to the website: https://www.reddit.com/r/Monero/comments/h86mof/getmoneroorg\_updated\_1\_new\_user\_guide\_1/
<monerobux> [REDDIT] GetMonero.org updated: 1 new user guide, 1 Moneropedia entry and 1 user guide rewritten, 1 new FAQ, 'Reasonably' removed from the header and more (self.Monero) | 42 points (95.0%) | 12 comments | Posted by ErCiccione | Created at 2020-06-13 - 12:28:45
<midipoet> ErCiccione[m]: just curious, what does "triaging" mean in the context of websites? I only have ever heard it being used in the field of medicine...
<msvb-lab> Not really an open idea, but I'm still confused if there is a migration plan from Gitlab, Github, standalone, cloud, or back and forth.
<sgp_> most stuff will stay on Github
<sarang> Sounds like CCS stuff is intending to stay on GitLab
<sgp_> the CCS stuff will stay on gitlab
<ErCiccione[m]> midipoet: It means that when an issue is open, i assign it a label and determine how important it is (to define how quick we need to work on it)
<midipoet> ErCiccione[m]: makes sense. Thanks
<msvb-lab> sgp sarang: Shoulnd't we add Bitbucket and maybe get a fourth or fifth server so we don't seem too consistent?
<msvb-lab> That was a joke.
<ErCiccione[m]> midipoet: it's a fancy ways to say "i keep track of what issues are open and what we have to do with them" :)
<midipoet> ErCiccione[m]: i always approve of a bit of fancyness here and there
<ErCiccione[m]> 😛
<xmrscott[m]> As a treat
<sgp_> looks like not many people had fancy ideas, and that's time :)
<sgp_> 6. Confirm next meeting date/time
<sgp_> The community meeting on the 4th of July is CANCELLED. The next community meeting will be in 4 weeks on the 18th of July.
<sarang> Fancy idea: support key-based pushes on GitLab :D
<sarang> (I know this is apparently some cloudflare thing)
<sgp_> The next Coffee Chat is on Saturday 27 June at 17:00 UTC. Sadly, I will need to miss this one again. rehrar, can you moderate?
<msvb-lab> Great meeting sgp, thank you very much for moderating it.
<rehrar> Ye
<sarang> cheers
<sgp_> thank you, apologies everyone
<sgp_> Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, STAY SAFE AND ISOLATED, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2020-06-10

Wed, 10 Jun 2020 00:00:00 GMT

Logs

<sarang> OK, just about time to start the meeting
<sarang> First, greetings!
<ArticMine> Hi
<sgp_> hello
<Isthmus> Heya
<sarang> I suppose we can move to the roundtable, where anyone is welcome to share research of interest
<sarang> Does anyone want to go first?
<sarang> If not, I can share a few things
<sarang> Teserakt has sent me a draft of their analysis of the CLSAG preprint
<monerobux> Test failed
<sarang> bad bot
<sarang> The draft report indicates they did not find any major issues with the construction, but they had some comments and suggestions on the formalization that I'm working to update
<sarang> This shouldn't result in any changes to the code
<sarang> Separately from this, I started working on some output merging analysis on the Monero chain
<h4sh3d[m]> Hello
<sarang> I have preliminary data but am still checking it for a few questions I have
<sarang> I'll post a plot here, but note that it should not be relied on until checked more thoroughly
<sarang> https://usercontent.irccloud-cdn.com/file/EHmFolZV/data\_all.png
<sarang> An explanation...
<sarang> I look for "zero-hop" possible merges, where outputs from the same source transaction appear in separate rings in a later destination transaction, and filter only by post-CT confidential transactions
<sarang> Then, for each such possible merge, I look at the height difference of the source and destination transaction, and plot them here
<sarang> The x-axis represents block height difference, and the y-axis is fractional occurrence (note the log scale!)
<kiwi_87> Hi. What you think about interoperability on Monero?
<sarang> kiwi_87: one sec
<Isthmus> 👀
<Isthmus> Very interesting
<sarang> https://usercontent.irccloud-cdn.com/file/UPSZyk6P/data\_1k.png
<sarang> Here is the same data, but zoomed (and rescaled) to the low end of the x-axis
<sarang> Now, these are only possible merges; there's no good ground-truth data set on chain for post-CT confidential transactions
<atoc> hi
<sarang> So I'm going to run a simulation using the same input/output structure and the current decoy selection algorithm
<sarang> and see if/where the distributions diverge
<sarang> kiwi_87: what do you mean by interoperability
<sarang> Oh, and for this data... about 2.3% of post-CT confidential transactions contained at least one possible merge
<sarang> (this data shows all such possible merges, not just a unique one from each transaction)
<Isthmus> @sarang if you want to go deep into the Bayesian weeds, could calculate the probability (always positive, but varying in magnitude) that a pair(+) of these ring members would be selected together if sampled from the standard algo
<UkoeHB_> Isthmus: do you recall what proportion of transactions don't use the standard gamma distribution (approximately)?
<sarang> UkoeHB_: note that this is _all_ post-CT confidential transactions, regardless of likely selection method
<sarang> I did a filter for that but may have a minor indexing issue that threw off the data
<sarang> Isthmus: yeah, I thought about that too (but didn't run the analysis)
<sarang> The distribution difference is intended to give a very rough idea of how non-ideal this distribution is
<ArticMine> The other question is ring size
<Isthmus> @UkoeHB_ as of Konferenco (last June) about 1% of transactions used obviously uniform selection algorithm
<Isthmus> I haven't updated the analysis pipeline, so can't speak to recent months.
<UkoeHB_> ah if sarang is already filtering those out it's not a big deal
<sarang> I'm not at the moment
<sarang> This is all post-CT confidential transactions
<Isthmus> @sarang what are you coding this in? I have python code to strip those out
<sarang> This is Python as well
<sarang> If you can link the code that'd be great, or I can write something up
<sarang> But uniform selection seems very unlikely to cause the long tail
<sarang> Anyway, this is the start of analysis that I hope will be useful to inform safer output selection
<UkoeHB_> very cool thanks for you effort sarang :)
<sarang> Once I verify this indexing issue, I'll post both the analysis code and the data set
<Isthmus> https://www.irccloud.com/pastebin/BChX6gR9/
<sarang> I can't post _all_ the data (block, transaction, ring, ...) since it's far too big for GitHub
<kiwi_87> @sarang, I mean the interoperability, if it can be made between Monero and other chains, there would be more room for the adoption of XMR. I learn about this from the fact that Bitcoin is entering Ethereum network with the amount that is way larger than which on the layer 2 of Bitcoin. It helps BTC to join the DeFi and increase the adoption for
<kiwi_87> such crypto. Same thing can also happen with XMR, don’t you think?
<sarang> But I can post the resulting possible merges, which are of reasonable size
<sarang> Thanks Isthmus
<Isthmus> https://usercontent.irccloud-cdn.com/file/fZgJlX2o/image.png
<sarang> kiwi_87: operating between Monero and other chains is surprisingly tricky, and even moreso if the goal is to maintain uniformity of transactions
<Isthmus> https://usercontent.irccloud-cdn.com/file/aQVzvAAq/image.png
<sarang> Isthmus: what are these plots?
<Isthmus> Let ring_member_ages be an array of ring member ages [0.5d, 0.7d, ...]
<Isthmus> offset-corrected median age = median(ring_member_ages - min(ring_member_ages)
<Isthmus> The correct decoy algorithm produces OCMA's around 100 - 10000 blocks
<Isthmus> I used 370000 as a conservative "absurdity limit"
<sarang> Small sample => high variance, I assume?
<Isthmus> Might also have to do with fact that algo reacts to txn vol changes
<Isthmus> Anyways, anything above 10^5 is suspect
<Isthmus> Red line is 370000 blolcks
<Isthmus> Anything above that is absolutely not from the correct decoy algo
<sarang> Examining the distribution with that filter will be very interesting
<Isthmus> And in most cases, when I spot checked, were due to apparent uniform decoy selectioin algo
<sarang> I'd expect that it wouldn't change much, but I like being proven wrong
<sarang> Any other speculation about the effects of these selections? (just curious)
<Isthmus> Hmm, I'm interested in the Bayesian analysis, which will tell us whether this is a novelty with 10% predictive power, or a damning tell with 95% predictive power
<sarang> Oh and Isthmus: what transactions does this account for? The entire chain?
<Isthmus> From introduction of RingCT until Konferenco
<sarang> Does it filter out non-CT transactions after the CT cutoff?
<sarang> These are low quantity, but are still present
<sarang> and have very different selection of course
<Isthmus> I usually ignore non-RingCT since I'm more interested in optimizing current privacy than studying historical easter eggs
<sarang> yeah
<Isthmus> I'll have to work my way back in the analysis pipeline to check
<sarang> I also filtered those in the plots above
<Isthmus> Sorry, by "ignore" RingCT, I mean "exclude them from my data set before analyzing"
<sarang> roger
<Isthmus> s/RingCT/non-RingCT
<monerobux> Isthmus meant to say: Sorry, by "ignore" non-RingCT, I mean "exclude them from my data set before analyzing"
<sarang> Oh, and I might have mentioned this last week (don't recall), but I'm still working with those CMU student researchers to confirm some updated deducibility analysis
<sarang> They plan to revise their preprint once again
<sarang> This is especially nice given that their "30% traceable" (or whatever it was) conclusion regarding spend age heuristics is incorrect
<kiwi_87> @sarang. Yeah I know it’s the hardest part. Actually our research at Incognito project is currently on this direction.
<kiwi_87> We have the idea of building a privacy chain learning the technology from Monero, thus allowing the high level of privacy for the chain.
<kiwi_87> Then build a Portal connecting to Monero with a group of decentralized custodians holding & releasing XMR when users going in & going out the layer 2. The same design can be applied to BTC, which brings XMR & BTC to the same privacy layer.
<kiwi_87> What do you guys all think?
<sarang> This might be a better conversation for after the meeting kiwi_87 if it mainly concerns research for another project
<sarang> Unless the group disagrees
<moneromooo> Not this silent part of the group.
<sarang> Were there any other questions on the deducibility or output merging data?
<sarang> If not, does anyone else wish to present research of interest for this group?
<Isthmus> @kiwi_87 cool, I like seeing these types of projects. 👍
<h4sh3d[m]> I can give some updates about the swap
<sarang> Please do
<sarang> (this may be relevant to you kiwi_87)
<h4sh3d[m]> I started working on it, I plan to have an updated version of the paper next week
<h4sh3d[m]> So, the idea is still the same as before
<kiwi_87> @sarang yeah sure. I’ll talk more about what we are doing in the after-meeting time. Still, I think interoperability on XMR could be a very bright way to increase the Monero adoption. Would love to talk to other researchers who are also diving in the same direction
<h4sh3d[m]> split the monero spending key in two halfs, and "sell" one half or the other on the bitcoin chain depending if the swap success or not
<sarang> via multisig, I assume
<sarang> "You get the even bytes, and I keep the odd bytes!"
<h4sh3d[m]> Yes, kind of. Before there was the generic zkp for the hash preimage
<kiwi_87> @Isthmus sure. Would love to share more in the after-meeting time. Now let’s make the convo laser-focused on Monero
<sarang> h4sh3d[m]: but you're replacing with a cross-group DL equivalence proof via side channel, correct?
<kiwi_87> @h4sh3d[m] would love to hear about this. Really want to know what’s going on there with the cryptography challenge. Please update us :D
<h4sh3d[m]> Now, by combining dl equality across group + ECDSA one-time VES, we should be able to achieve the same
<h4sh3d[m]> ECDSA one-time VES: https://github.com/LLFourn/one-time-VES/blob/master/main.pdf
<h4sh3d[m]> (it's an ECDSA "adaptor signatures")
<sarang> Remind me: does this approach assume/require any particular timelock capability on the Monero side?
<sarang> If so, to what extent?
<h4sh3d[m]> No, nothing is required on the Monero side, that's the cool part
<sarang> OK, thanks
<sarang> Monero supports a very simple timelock of course
<sarang> but it's a bit inconsistent at the moment, and apparently infrequently used
<sarang> so if it were required, this could present a uniformity issue
<h4sh3d[m]> We create an address where Spend = Spend_alice + Spend_bob (same for view)
<Spend, View> corresponding address
<sarang> Does the address protocol have issues with key cancellation?
<h4sh3d[m]> Each participant has his own half, and one will get the second one
<sarang> Or is there precommitment to address parts?
<h4sh3d[m]> Not sure if I understand what you mean by key cancellation
<sarang> If you hand me a part of a key, maybe I maliciously generate my own "key" such that the sum is any value I want
<h4sh3d[m]> Ah yes, I thought about that
<sarang> If this is problematic, we can each commit to our key portions first, and then check that the keys received match the commitments
<sarang> it ensures that neither party change their mind
<sarang> Adds a communication round
<sarang> There are other methods involving random-oracle linear combinations too, depending on what you need
<h4sh3d[m]> I thought about the commit, but that also mean you don't know your correct "half" (only the destiantion priv/pub), and without priv half, you are not able to continue the protocol
<sarang> But sorry, I'm digressing here
<>other cryptos, we will need more atomic swap designs and Portal designs connecting layer 2 and Monero chain
<h4sh3d[m]> No, it's a good one
<sarang> kiwi_87: let's discuss after the meeting
<sarang> h4sh3d[m]: ok, as long as it's either not necessary or taken care of via a communication round, I suppose
<sarang> But certainly worth a close eye after the paper is updated
<h4sh3d[m]> when we get the address, and the initialization phase is done (with zkp dl equality e.g.), one send Monero into it
<kiwi_87> @sarang sure
<h4sh3d[m]> at the end, Alice or Bob, will learn the full private spend key = priv_spend_alice + priv_spend_bob
<h4sh3d[m]> So no, nothing fancy required on the Monero side
<atoc> nice
<h4sh3d[m]> You will import the full keys in you wallet and do a regular transaction
<sarang> Definitely look forward to seeing the updated paper h4sh3d[m]!
<atoc> same
<h4sh3d[m]> (keys that are generated withou a seed and a derivation function, so wallet must support "raw" keys)
<h4sh3d[m]> Right now, I'm in the one-time VES paper, and your MRL-0010 one
<sarang> got it
<h4sh3d[m]> * I'm done, thanks for your inputs
<sarang> I might update MRL-0010 to specify that the Pedersen generators need an unknown DL relationship
<sarang> Apparently that wasn't listed specifically, but is generally true for Pedersen commitment security
<sarang> In the interest of time, were there any other research topics that need to be presented before the hour is up?
<Isthmus> Quick update: I’m really happy to share that we’re officially beginning our audit of monero’s security and privacy mechanisms against algorithms that could be exploited by hypothetical quantum adversaries. Thank you to everybody who contributed feedback or funds to our CCS 🙏
<Isthmus> The first step is a formalizing our adversary model and enumerating of mechanisms of interest.
<Isthmus> Right now the attack surface list looks like {Ring Signatures, RingCT, One-time "Stealth" Addresses, Pubkey derivation, Forge amounts?, Bulletproofs, RandomX proof-of-work, Block / Transaction hashing}.
<Isthmus> Please suggest other pieces that you’d like to see audited. :- )
<Isthmus> Earlier I was looking at the wallet generation schematic shared to Reddit, and it has me pondering visual ways to communicate results. https://www.reddit.com/r/Monero/comments/gy0m1u/i\_made\_an\_infographic\_on\_how\_a\_monero\_wallet\_is/
<monerobux> [REDDIT] I made an infographic on how a Monero wallet is generated. Can you find any mistakes? (https://i.redd.it/tv98m10mbd351.png) to r/Monero | 163 points (100.0%) | 18 comments | Posted by Krakataua314 | Created at 2020-06-06 - 22:42:54
<Isthmus> https://i.redd.it/tv98m10mbd351.png
<Isthmus> For example, the ed25519 scalarmult (used for private view key → public viewkey) is a one-way function for traditional computers (assuming hardness of the discrete log problem) but can be reversed if you can apply Shor’s algorithm.
<Isthmus> So perhaps this could be visually annotated with directional arrow for traditional adversaries and bidirectional arrow for hypothetical quantum adversaries. Would that be an intuitive approach?
<sarang> I like that idea
<sarang> that's very clever
<sarang> Can you remind us of the expected timeline Isthmus?
<Isthmus> Will be working on this full time for the next 3 months
<sarang> (with the understanding that research often takes unexpected twists)
<Isthmus> Phase 1 should be quick
<sarang> The scope was modified to focus less on deliverable code, right?
<sarang> And more on solid understanding, possible mitigations and relevant work, and communication?
<Isthmus> Just setting the stage for our object of study and attacker, hoping to have a first "final draft" of that done by next MRL meeting
<sarang> Oh nice
<Isthmus> Yep
<sarang> That'll be great to see
<Isthmus> And then working systemically through the cross sections
<Isthmus> (table where each column is a quantum adversary and each row is a piece of Monero tech)
<Isthmus> My guess is that we'll be able to fill 80% of the squares in 20% of the time
<Isthmus> And then 20% of the squares will take 80% of the time
<sarang> Do you expect that the final results will be suitable for broader distribution? Like to journals, refereed conferences, or simply IACR archive?
<Isthmus> Throughout this entire project, the community will receive updates during the weekly #monero-research-lab meetings. During phase 3 however, several specific documents (the key deliverables from this research) will be freely published
<Isthmus> 1. User-friendly writeup: This community-facing writeup will provide an approachable explanation of how hypothetical quantum computers may impact Monero, and possible future mitigations. The writeup should minimize FUD and provide the context that these vulnerabilities apply to almost all cryptocurrencies (not only Monero).
<Isthmus> 2. Technical documentation: An MRL position paper to distill key information for (current and future) researchers and developers. The writeup should formally describe vulnerabilities, and highlight potential strategies and solutions, noting their tradeoffs. Code snippets may be included if appropriate for pedagogical purposes or clarity.
<Isthmus> 3. Non-technical 1-pager: An ELI5 / TL;DR summary will be provided for journalists, Monero Outreach, etc. This blurb will discuss risks and myths with no technical jargon, with key takeaways that a broad audience will appreciate.
<Isthmus> (Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos.)
<Isthmus> And yea, hopefully we can get a paper or two out of this
<Isthmus> Much of the research will be broadly applicable
<sarang> Great!
<atoc> Nice
<sarang> Getting a better sense of research trends in this direction, even if not presently applicable, will be intriguing to see
<sarang> e.g. there are plenty of ideas for post-quantum constructions, but there are generally huge barriers in efficiency that render them unusable
<atoc> btw Isthmus, this may be off topic but can you talk a little more about the Insight program?
<sarang> OK, we're just about out of time
<sarang> atoc: perhaps for right after the meeting?
<atoc> yes
<sarang> Are there any other last questions or comments about these research topics before adjourning?
<sarang> If not, thanks to everyone for attending and participating!

Logs for the Community Meeting Held on 2020-06-06

Sat, 06 Jun 2020 00:00:00 GMT

Logs

Logs for the Community Meeting Held on 2020-06-06

Sat, 06 Jun 2020 00:00:00 GMT

Logs

Logs for the MRL Meeting Held on 2020-06-03

Wed, 03 Jun 2020 00:00:00 GMT

Logs

<sarang> OK, let's get started!
<sarang> First, GREETINGS
<sarang> hello
<ArticMine> Hi
<dEBRUYNE> hi
<hyc> hey
<Isthmus> Heyo
<sarang> Next up, ROUNDTABLE, where anyone is welcome to share research of general interest
<sarang> I have a few topics of interest
<sarang> The recent preprint from CMU student researchers on transaction tracing has been updated to reflect suggestions and corrections: https://eprint.iacr.org/2020/593
<binaryFate> hello
<sarang> The researchers still claim that a small but nonzero number of post-changeover (i.e. the RingCT protocol switch) transactions were traceable, which didn't correspond with other numbers I'd found
<sarang> So I decided to independently run the same analysis and compare
<sarang> I ran updated numbers that account for all transactions up to the beginning of this week
<sarang> If you run a full chain-reaction-type analysis, there are 7303 transactions after the changeover containing at least one deducible input
<sarang> However
<sarang> All of those transactions spend pre-changeover outputs
<sarang> So if you filter out all transactions that aren't CT-in-CT-out, there are still precisely 0 deducible transactions/inputs
<sarang> But wait, there's more!
<sarang> The preprint also tries to determine how effective the guess-newest age heuristic is against modern transactions
<sarang> Unfortunately, it uses those 7303 (or however many were in their block range) deducible post-changeover transactions as ground truth
<sarang> and assumes that holds for all post-changeover transactions
<binaryFate> huh that's pretty dumb
<sarang> I wouldn't say it's dumb; it just failed to account for transaction types
<ArticMine> So the key here is RingCT
<sarang> Because there are "full-CT" transactions post-changeover that are deducible, the entirety of their ground-truth data set is based on spends of old funds, for which the modern selection algorithm does not apply
<sarang> But there is an interesting twist
<dEBRUYNE> To be clear, it concerns transactions were non-RingCT outputs are essentially converted to RingCT outputs, right?
<sarang> Among that ground-truth data set, the researchers find those transactions are _still_ twice as good against guess-newest from Miller et al.!
<sarang> dEBRUYNE: yes, or that aren't converted to CT at all
<sarang> (very limited cases involving single inputs)
<moneromooo> > Because there are "full-CT" transactions post-changeover that are deducible,
<moneromooo> Forgot a no, right ?
<sarang> Correct, thank you
<sarang> because there are NO full-CT post-changeover that are deducible (typo)
<dEBRUYNE> sarang: Thanks, I guess those are dust outputs then that first have to be converted to standardized outputs
<dEBRUYNE> dust or non-mixable
<sarang> So the conclusions presented in the paper about transaction counts aren't wrong, but don't differentiate between type, which I think is very important
<sarang> The conclusions about guess-newest are only valid for their ground-truth set, and cannot be extrapolated to CT transactions
<binaryFate> The wallet warns you when you spend old outputs that privacy is lessen and it's known you should churn in that case. It should absolutely be mentioned in their paper that these transactions are particular and users are fully informed of the risk
<sarang> I'm drafting an email to the authors to let them know of this, should they wish to revise again
<sarang> They were very prompt in responding to my earlier email, and very quickly revised, which was great
<sarang> Now that I have a complete deduced data set, I'm checking their results on effective anonymity sets of non-deduced transactions
<sarang> I want to separate those by transaction type as well
<sarang> Even though the preprint had errors, I'm glad they did the research
<sarang> We should encourage student researchers
<binaryFate> I'm unclear on the guess-newhest on this dataset
<sarang> How so?
<binaryFate> Since this dataset is specifically about real output being old, shouldn't that give very specific results when seeing how the heuristic performs, that can't be extended to other transactions?
<sarang> Yes
<sarang> That's what I was saying earlier
<sarang> They assumed their ground-truth post-changeover dataset was representative of all post-changeover transactions, which is entirely false
<UkoeHB_> pre-ringCT inputs could be used in rings just like modern coinbase outputs are, which makes me sad
<= Yes, because uninformed readers may infer that it concerns full RingCT transactions
<binaryFate> IIRC the decoy selection algorithm is very different for these transactions, only selecting non-ringct. Since all of them are very old, they are old on the tail of the gamma distribution, very different from recent one
<moneromooo> Using pre-ringct outs as fake outs would help shortly after ringct, but would otherwise introduce a number of known spent outs in rings.
<binaryFate> *they are all
<sarang> When I finish the effective anonymity data, it should give a much more clear picture of the status of modern transactions (before and after ring increases too)
<sarang> The code still needs some cleanup to make it easier for others to run this analysis, either now or in the future
<UkoeHB_> interesting point moneromooo
<sarang> thanks to gingeropolous for the use of a fast machine for this analysis
<sarang> If the researchers choose not to revise, I can always write a new preprint that presents this data
<sarang> but I strongly suspect the researchers will revise again, since they did a very prompt first revision
<binaryFate> super cool that you checked all these results
<hyc> sounds great
<sarang> I can also post the raw data for the post-changeover deducible transactions, in case anyone wants to specifically analyze them
<hyc> super cool that their work is pulblicly reproducible
<sarang> Again, I'm really glad they did the analysis
<sarang> Yeah, I didn't end up using their Java code though
<sarang> I wanted some extra data they didn't provide, so I rewrote
<sarang> but kudos to them for making all their code public, for sure
<UkoeHB_> I'd like to see if the code can be adapted to a certain analysis I have in mind, so I'm looking forward to it
<moneromooo> Not really. More like negative kudos for those that don't.
<sarang> What analysis is that UkoeHB_?
<hyc> moneromooo: yes but that still tends to be the majority these days
<moneromooo> Papers without it are really hearsay. Should never be published.
<UkoeHB_> getting data on ring loops, and comparing to a purely randomly generated ring db
<sarang> Define ring loop
<hyc> moneromooo: agreed
<moneromooo> A ring is a circular construct. A loop is.... a.......
<UkoeHB_> e.g. two outputs are owned by the same person, a loop is when their descendents intersect in the same tx
<sarang> Oh, output merging
<sarang> ?
<moneromooo> Can happen by chance too (from fake outs).
<sarang> yes
<UkoeHB_> yeah basically, so I want to see the probability of given loop sizes happening randomly
<sarang> I think the question is how likely it is to occur in practice vs not
<Isthmus> @UkoeHB_ important research. Results will be probably be depressing :- (
<moneromooo> If it was super fast, it'd be nice for the wallet to try and pick fake outs that generate "false positives".
<sarang> There's code that will do forms of merge analysis, and it's something I have to add specifically to my check code
<sarang> The graphs involved are likely quite large, so it isn't clear what the complexity of this is
<
<sarang> FWIW the early analysis on output merging used deducible transactions only
<UkoeHB_> right, I have some ideas about limiting the output range to first estimate exactly how long such analysis would take; can also limit the maximum loop size considered
<Isthmus> UkoeHB_: to generate random data set, will have to select guesstimates for parameters like number of transactions per wallet. (really, would be a distribution, not single value)
<sarang> yes
<Isthmus> The interesting thing is that we may be able to establish statistical estimates of these parameterss based on the real blockchain data
<UkoeHB_> Isthmus we can just use the transactions that already exist, but make the input rings randomly selected; this provides a direct comparison with the real ring db
<Isthmus> Especially if rare "natural" occurrence, i.e. low false positive rate
<sarang> This sort of analysis was considered as a major part of the churn framework as well
<UkoeHB_> and do the randomly generated analysis multiple times for variance
<Isthmus> Makes sense
<sarang> Anyway, I've taken up a lot of time on that
<sarang> Was there other research of interest to discuss from anyone?
<Isthmus> I'll be interested in seeing plots where x-axis is # of txns made within a given wallet, and y-axis is statistical measures, like precision/accuracy/etc
<Isthmus> I have a few quick updates
<Isthmus> I’ve been doing some p2p network scalability research, creating some testing suites, etc. Still very early reading/planning, but hopefully will have some actionable insights for Monero.
<UkoeHB_> yes it's a big project and might be worthy of a paper if it goes somewhere, we will see; I also want to see how well the gamma distribution is working by subtracting the theoretical distribution from what we have in reality
< YES PLEASE
<Isthmus> @UkoeHB_ I have some algorithms floating around GitHub to identify and filter txns that use uniform decoy selection instead of correct algo. If you don't strip those out, it will introduce a bias in your results towards older oututs
<Isthmus> I'll dig those up and send links
<UkoeHB_> cool thanks
<sarang> Yeah, trying to exclude old software will be important
<sarang> since there's no consensus enforcement
<UkoeHB_> I think ring analysis is too scary for anyone to tackle alone, so a collaborative and incremental effort seems reliable
<Isthmus> Software can't be any older than the last ring size change, right?
<sarang> Sorry, I meant software using old/incorrect methods
<sarang> "nonstandard" is a better term
<sarang> A big reason why deterministic input sets are intriguing is because they're likely to contain many outputs from the same transactions
<sarang> and therefore are included as a "standard feature" of all rings
<binaryFate> "see how well the gamma distribution is working by subtracting the theoretical distribution from what we have in reality" I was doing stuff in that direction too, exciting!
<UkoeHB_> I think I missed the last meeting. The Janus proposal was updated a week ago (https://github.com/monero-project/monero/issues/6456), and now the Janus mitigation is to encode the tx private key for recipients. For 2-out tx where there will only be 1 tx pub key, the 'change output' would use a 'hidden tx pub key' derived from the non-change recipient's encoded tx private key. An alternative would be for the
<UkoeHB_> change output to use a unique 'derivation to scalar', however I am concerned that affects too much protocol-level code (could be wrong).
<binaryFate> What happens where there is a 2-out tx but none of them is change?
<Isthmus> I think you have to make a 3
<Isthmus> 3-output then?
<UkoeHB_> The proposal is to enforce 1 tx pub key for 2-outs, and 1 key per output for >2-outs. All tx with no change output would have to be >2-out, even if it means adding a dummy output.
<moneromooo> A 0 change is automatically added *only* if there's one output otherwise.
<UkoeHB_> Right, and following the proposal there would be a very rare case of 2 non-change outs needing a dummy
<Isthmus> It's an edge case, so I perceive this as a reasonable solution
<UkoeHB_> Originally encoding the tx private key was disregarded since current tx share tx pub keys, but since we'd start enforcing more tx pub keys that problem is solved.
<UkoeHB_> i.e. as a solution for Janus*
<UkoeHB_> Well, the hidden tx pub key might be unnecessary now that I think about it.. anyway that's my dusty update.
<ArticMine> but does this means that a 2 out tx always has change real or dummy
<UkoeHB_> yes
<ArticMine> Can this then be attacked?
<UkoeHB_> the idea that there is always a change output in 2-out tx? that assumption can be made today already
<Isthmus> Oh no wait, it would just move the issue to n+1
<sarang> Sorry, connection problems; back now
<ArticMine> but not with 100% certainty
<UkoeHB_> well the shenanigans around 2-out tx are mostly to optimize scanning and tx sizes, since 2-out tx are ~95% of tx
<UkoeHB_> that's true ArticMine
<luigi1111w> one can assume with high certainty that every transaction contains a change output. I don't understand why that's a significant observation.
<Isthmus> Most txns. Churn doesn't, for example.
<sarang> ^
<moneromooo> Why does it not ?
<sarang> Doesn't have to
<sarang> And would affect output merging later
<moneromooo> Well, that's circular reasoning then.
<Isthmus> Churning with change creates the loops UkoeHB_ mentioned earlier
<luigi1111w> churn has two change outputs, no?
<ArticMine> It can
<luigi1111w> or one and a fake one
<UkoeHB_> churn has an 'output to yourself' and a 'change output'; change outputs are handled differently in the code
<luigi1111w> sure but this is from a network perspective
<UkoeHB_> yeah
<ArticMine> Or a split 2 separate wallets under the control of one person
<ArticMine> It introduces uncertainty
<luigi1111w> but why does it matter?
<ArticMine> because even a small bias can grow.
<sarang> Given the time, is there other research that needs to be brought up before adjourning?
<Isthmus> I've got 2 updates, will keep brief for sake of time:
<Isthmus> Our CCS for researching Monero’s post-quantum security is sooooooo close. Only 7% left, less than 40 XMR needed. https://ccs.getmonero.org/proposals/research-post-quantum-monero.html
<Isthmus> If that could get topped off today, we’ll dive in immediately and have our first update at next week’s MRL meeting. :- )
<Isthmus> Unrelated - I also have one of Insight’s DistSys engineers buildling “speedup” networks, i.e. highly-connected peers with high bandwidth to propagate blocks/txns through the ad hoc network faster than organic propagation. Main goal is to eliminate the long tail in block propagation times.
<Isthmus> The codebase is very modular with Terraform/ansible deployment and control scripts, so could be configured to spin up a Monero speedup network in the future.
<Isthmus> That's all from me.
<sarang> Nice!
<sarang> I suppose I should mention that I welcome/request comments/questions/emoji on my funding proposal as well, so a decision can be made whether to open it: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/148
<luigi1111w> thanks for opening it well in advance
<sarang> OK, I suppose we can formally adjourn for the sake of logging
<sarang> Thanks to everyone for joining in today
<sarang> Discussion can of course continue!

Monero GUI 0.16.0.0 'Nitrogen Nebula' released

Sat, 30 May 2020 00:00:00 GMT

Overview

This is the v0.16.0.0 release of the Monero GUI software.

The latest CLI release notes can be found on the precedent blog post

Some highlights of this major release are:

Simple mode: node selction algorithm improved
UX: display estimated transaction fee
UX: add update dialog with download and verify functionality
UX: implement autosave feature
UI: redesign advanced options on transfer page
UI: improve daemon sync progress bar
UI: new language sidebar
UI: new processing splash design
UI: redesign settings page
Trezor: support new passphrase entry mechanism
Wizard: add support for seed offset
Various bug fixes and performance improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 54 people who worked, largely unpaid and altruistically, to put out 178 commits containing 32608 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

luigi1111
Dusan Klinec
mmbyday
rbrunner7
selsta
xiphon
rating89us
erciccione
thotbot

A special thanks to translators

reketen, TheFuzzStone, Michael Russo, kombometralla, CharlesCrisco, Anonymous, porokon7, Juanpaab, enaSo97, TasmaniaKrama, vaa red, 8uDD4T, Lafudoci, Gilberto F da Silva, Marius Tanislav, Vlad G., Agent LvM, solevoy-psih, v1docq47, Russian Bear, translator133, Scott Anecito, Viktor, jindouyunz, anony_xmr, tan, Muge Niu, TE Scott, razorshaman909, Matija Mazi, To Ja, ANMNQ, Nelson Renan, netrik182, Boçogrolho Tabúrcio Mendez, Asdrubal Petronidas Calhofos, bitbooz, Marcus, B, peter hermansson, KforG, Poul, Wobole, René Brunner, GreenPiece

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Windows, 64-bit Windows, 64-bit(Installer) macOS, 64-bit Linux, 64-bit

A complete guide for the GUI wallet is included in the archives, but an online version is available.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-win-x64-v0.16.0.0.zip, f7894e92a8973f9b504fe028dc90a672fc3e97086ab835c346a1ae2dfb0d53cf
monero-gui-install-win-x64-v0.16.0.0.exe, 0820aeb30b39bb86b550ff5d6e641c16491cff3cff2b9ab9873bdc05acc6a041
monero-gui-mac-x64-v0.16.0.0.tar.bz2, 96effab969c1d4f715d323835d98b202e33f75b835ed4587bb49a76fb288bc6d
monero-gui-linux-x64-v0.16.0.0.tar.bz2, 6a1064e89d1ac626ae9307429276ad447ddbbf38035de0b24599e267977e61f1

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Logs for the MRL Meeting Held on 2020-05-27

Wed, 27 May 2020 00:00:00 GMT

Logs

<sarang> OK, it's time for the meeting!
<sarang> As usual, begin with GREETINGS
<Isthmus> GREETINGS
<ArticMine> Hi
<sarang> hello
<knaccc> yo
<knaccc> very nice :)
<sarang> Subtle!
<sgp_> hello
<sarang> OK, let's move to ROUNDTABLE
<sarang> I'll start with a few things
<sarang> A preprint came out from student researchers at CMU on Monero and Zcash tracing: https://eprint.iacr.org/2020/593
<sarang> It only looked at pre-Sapling Zcash data that was previously examined (independent checking of earlier work is valuable)
<sarang> but did look at much more recent Monero transactions
<sarang> The overall conclusions are that protocol improvements have been very useful
<sarang> I disagree completely with their methodology leading to a conclusion about the effectiveness of the updated output selection algorithm, however
<sarang> and I think they can't reach any conclusions from that
<sarang> I put together some notes and sent them to the authors, along with my thanks for their work
<sarang> They did make their analysis code available on GitHub, so I'm going to see what useful information can be pulled from that as well
<sarang> Separately from this, I'm working on some non-slanderability definition stuff to port from Omniring's security model to that of Arcturus now
<sarang> Worked on address verification proof updates with moneromooo
<sarang> and wrote up some test code for the view tag scanning idea
<knaccc> in what lang?
<sarang> As described by UkoeHB_ earlier, the idea is to include a small truncated hash of the key derivation for each output, and use this for a "fast scanning" mode that avoids some curve operations
<sarang> knaccc: timing code in the C++ codebase
<sarang> It's not an implementation, only for getting timing information
<sarang> Under the assumption that a view tag is a single byte and only 1 out of every 256 tag checks results in a match, here are the numbers
<sarang> On a particular test machine, the total scan cost _without_ view tags for those 256 checks is 43.520 ms
<sarang> The total scan cost _with_ view tags (and a single match in the group) is 32.559 ms
<sarang> That means the fast scan mode operates in 75% of the time as the standard scan mode, in this example
<knaccc> how many txs in total were you scanning?
<sarang> This wasn't an actual scan; it was a simulation that performed all the operations for fake outputs generated by the test code
<knaccc> i just mean, what was the ratio of matching outputs to outputs scanned
<sarang> It built a view tag and output key, and then timed the scanning under various modes
<sarang> This assumed 1/256
<sarang> Purely statistical
<knaccc> when you hit that 1 in 256, are you including the cost of the extra scalamultbase to then properly check?
<sarang> Yes, let me explain a bit
<sarang> The test has 3 modes
<sarang> Mode 1. standard scanning, no view tags
<sarang> Mode 2. view tag, no hit (compute the derivation and view tag, and then abort)
<sarang> Mode 3. view tag, hit (after the derivation and view tag check, recompute the expected spend pubkey)
<sarang> So the "no view tags" total assumes 256 Mode 1 operations
<sarang> The "yes view tags" total assumes 255 Mode 2 operations, and 1 Mode 3 operation
<ArticMine> There is the question also of non standard math
<sarang> ?
<sarang> knaccc: the test code actually always generates a matching view tag and output key (for sanity checking), but the simulation just uses the modes to fake whether or not a match occurred (there's no difference in timing doing it this way)
<knaccc> your findings roughly match up with the back-of-envelope calc that if you almost always save on a scalarmultbase, and if variable-base scalarmult costs 25 and a fixed-base scalarmult costs 15, then you reduce the scanning cost from 100% to 25/(25+15) = 62.5%
<ArticMine> for Arcturus
<sarang> ArticMine: view tags are entirely separate from Arcturus
<ArticMine> sorry
<sarang> They apply generally to the output key construction process
<sarang> which is abstracted away from Arcturus anyway
<sarang> The added risk with view tags is that a sending wallet can generate whatever tag it wants, and the receiver would not detect the output
<sarang> But FWIW the reverse isn't true... you can't DoS a scan with this method
<sarang> Bad view tag implementations could also fingerprint if a wallet did something silly like always set it to a fixed value
<sarang> Of course, compatible recipient wallets wouldn't detect it if they did fast scanning, and this would not look good for the incompatible sending wallet anyway
<sarang> Here's the timing code: https://github.com/SarangNoether/monero/commit/93172f80b2c25def9aaf40fc30dbee54f92f47a5
<sarang> (it does pass build checks, but Windows CI is broken)
<knaccc> i wonder where the difference is between the 75% real-world and 62.5% theoretical
<knaccc> i'll read through your code
<sarang> There is a small cost for each hash computation, and for the few non-scalarmult operations
<sarang> Yeah, let me know if you notice something that I missed
<knaccc> those are usually neglibible compared to .15ms or .25ms for an EC mult
<sarang> aye
<sarang> IIRC the hash stuff is something like 2-3% of the total time
<knaccc> i don't see anywhere in your code actually referencing loop_count
<sarang> That's taken care of by the test runner
<sarang> Which uses the individual results for statistics
<knaccc> ah
<sarang> Each test is set up by a non-timed init()
<sarang> and then timed for test()
<knaccc> makes perfect sense
<sarang> If you build yourself, just run ./performance\_tests --stats --filter=\\*view\_tag\\*
<sarang> the true/false flags correspond to the bools in the test definition
<sarang> Oh, the byte conversions would need to be accounted for
<sarang> They're not huge, but not negligible either
<sarang> I tend to ignore those during back-of-envelope estimates
<sarang> Anyway, that's the stuff I wanted to present here
<sarang> Are there other questions?
<knaccc> code looks good to me
<sarang> OK, does anyone else wish to present any research of interest?
<sarang> knaccc: cool
<Isthmus> Hmmm, I started wondering about something this morning...
<Isthmus> Over the last several years, I’ve had to nix a ton of cool software ideas because repeated 3-output transactions are heuristically linkable, and alternative business models (subscriptions, accounts, etc) have tons of downsides and privacy concessions compared to adding a small service fee to each operation.
<Isthmus> Now I’m wondering if this is stifling Monero adoption and integration by preventing the most straightforward and private method for compensating the developers who want to contribute new stuff to the ecosystem.
<Isthmus> If we want Monero to be used for more than point-to-point transactions, without putting the first adopters at statistical risk, there may be some pros to a 3-output minimum: recipient + change + optional service fee.
<Isthmus> Of course, for many transactions the third output will be an empty dummy. (Or people could get creative and split the return across 2 change addresses for latter flexibility, etc)
<sarang> Ah, increasing the enforced minimum to 3?
<Isthmus> It might make sense to bundle this in with bigger rings, since the ratio of (# outputs) / (# ring signatures) per unit time shouldn’t get too large (since outputs that haven’t ever shown up in a ring signature yet have a known spend state [unspent], and inforrms [with provable certainty] the sender that funds weren’t subsequently moved).
<Isthmus> @sarang yep
<sarang> Splitting change means more likely to pull in multiple change outputs in later transactions
<sarang> which is bad for linking
<sarang> Downside is chain bloat
<Isthmus> Yeah, that's why I've always advocated against people splitting up within their wallet
<ArticMine> What is the additional size per tx?
<Isthmus> 0.22 kB
<Isthmus> I think
<Isthmus> oh wait
<sarang> that seems too big
<Isthmus> That number isn't right
<Isthmus> hold on a sec
<ArticMine> If we go to 4?
<sarang> ArticMine: why 4?
<ArticMine> Is there not efficiency bullet proofs?
<ArticMine> with 4 vs 3 outputs that had to be padded
<sarang> BP padding doesn't imply extra outputs
<Isthmus> Now I'm getting pulled into a side adventure on xmrchain that I can't find any 1/3/e txns but there are lots of 1/3/s (trying to figure out what that means)
<sarang> it's merely an algebra thing
<sarang> ArticMine: it would mean that the corresponding bulletproof is a bit bigger for standard transactions
<sarang> if that's what you meant?
<ArticMine> Yes
<sarang> Ah, a 3-out BP (padded to 4) is 64 bytes larger than a 2-out BP
<sarang> (a 4-out BP is the same size as a 3-out BP)
<ArticMine> That is y point
<ArticMine> my
<sarang> got it
<sarang> Yes, you are correct that this would increase the typical range proof size
<Isthmus> Yep, it makes Monero usable for more applications and businesses, but does increase the transaction size
<Isthmus> Hm, little easter egg:
<Isthmus> There are essentially no 1-in-3-out txns with encrypted PIDs
<Isthmus> There are a few 1-in-3-out transactions with no PID at all
<Isthmus> And a few 1-in-3-out with some unusual tag in xmrchain, not sure what's in tx_extra
<jwinterm> I guess that would make sense considering any PID tx is probably from user to exchange/service, so would likely just be one in two out
<Isthmus> Ugh, stands out as non-standard software
<Isthmus> I feel like we sometimes make things worse when we add a feature "to all transactions" in the wallet, but not the protocol :- (
<sarang> aye
<ArticMine> So is there additional bloat over the 64 bytes?
<sarang> The new output has a pubkey, a commitment, an encrypted amount...
<sarang> those three are 72 bytes total
<ArticMine> and 4
<sarang> 73 bytes if you add a view tag
<sarang> add another pubkey, commitment, amount, view tag for each output you want
<ArticMine> so 82 vs 73 bytes for 4 over 3
<sarang> No
<sarang> In addition to a possible marginal range proof increase, each additional output requires 73 more bytes for pubkey, commitment, hidden amount, [optional view tag]
<sarang> The marginal range proof increase from 2 -> {3 or 4} is another 64 bytes
<ArticMine> So for 3 it is 137 bytes
<sarang> sounds about right
<sarang> This also implies increased scanning time (reduced by view tags)
<ArticMine> and for 4 210 bytes
<sarang> and additional scanning time
<ArticMine> Yes
<sarang> Anyway, in the interest of time, were there other topics that needed to be brought up?
<sarang> (We can always continue discussions afterward)
<knaccc> btw i'd be interested to know some examples of great use-cases for 3-out txs
<knaccc> either now or after
<sarang> Service fees are a big one
<sarang> One output goes to the recipient, one to change, one to service provider
<ArticMine> VAT / GST?
<knaccc> sarang can you be more specific about the service? just one example of something that could be common?
<knaccc> ArticMine you're suggesting paying VAT direct to the gov as part of a tx?
<sarang> knaccc: maybe you're using some kind of hosted wallet service
<sarang> Or maybe your wallet software has an option to donate a small amount to charity with each txn
<knaccc> oh right, fine yes, gotcha.
<sarang> OK, let's finish up with ACTION ITEMS if there aren't any other topics to bring up
<sarang> If/when Windows CI gets fixed up, I'll rebase some new work for PR/review
<sarang> and get Triptych and Arcturus sent off to PoPETs
<sarang> and hopefully be able to reproduce some of the results from that tracing preprint
<moneromooo> Micropayments in every tx is a great way to punch monero into the ground. We don't want to have huge amounts of dust outputs, they take up the same resources as "normal" outputs.
<sarang> moneromooo: that's what I meant by chain bloat and scan increases
<knaccc> service-fee is essential for multisig arbitration insurance fee probably
<ArticMine> but I see a slippery slope
<knaccc> eventually i think the default kind of payment tx should be multisig w/arbitration insurance fee attached
<knaccc> and multisig won't be a different type of wallet, it'll be something created on-the-fly on each payment tx
<sarang> OK, I suppose we can formally adjourn (so I can post logs), but discussion can of course continue
<sarang> Thanks to everyone for attending!
<knaccc> ^^

Monero 0.16.0.0 'Nitrogen Nebula' released

Sat, 23 May 2020 00:00:00 GMT

Overview

This is the v0.16.0.0 major release of the Monero software. This major release adds Dandelion++ support and improves Bulletproofs verification speed.

Some highlights of this release are:

Bulletproofs: improve verification speed
Daemon: add Dandelion++ support
Daemon: speedup startup in some cases
Daemon: reduce bandwidth by up to 2/3rd
Daemon: improve auto bootstrap algorithm
Daemon: faster fetching of consecutive transactions
Daemon: print estimates for time until fully synced
Ledger: improve error messages
Ledger: timelock verification
Wallet: new "address one-off" command
Wallet: new "sweep_account" command
ZMQ: improved support and bug fixes
Various bug fixes and performance improvements

The complete list of changes is available on GitHub, along with the source code.

Contributors for this Release

This release was the direct result of 49 people who worked, largely unpaid and altruistically, to put out 563 commits containing 81539 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Alexander Blair
Lee Clagett
xiphon
Tadeas Moravec
moneromooo-monero
Howard Chu
rbrunner7
woodser
selsta
Riccardo Spagni
Kevin Crumb
Bert Peters
iDunk5400
Sarang Noether
Interchained
Dusan Klinec
Sumo Gr
Matt Smith
TheCharlatan
naughtyfox
Aaron Hook
mj-xmr
Jonathan Cross
erciccione
kozyilmaz
ArqTras
TheGoose
tevador
Martijn Otto
Jethro Grassie
rating89us
Nathan Dorfman
Gingeropolous
palomato
JamesWrigley
sumogr
Doyle
scoobybejesus
UkoeHB
Guillaume Le Vaillant
guy
stoffu
cohcho
cslashm
Jason Rhinelander
wowario
binaryFate
Bertrand Jacquin

Download

The new binaries can be downloaded from the Downloads page or from the direct links below.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.16.0.0.zip, f2750efb65b70ae9cad64d977cb0bfbe4dc6d014fe0b7fd565002282d67d469d
monero-win-x86-v0.16.0.0.zip, b1fc293dd9c12f90c7c343777298e86a22f25788561629b92ec0b23eb6cfb42c
monero-mac-x64-v0.16.0.0.tar.bz2, 8e9382cc509751765ed9601f6ac9d37cdb9e94dd5e541312545430e6617c6850
monero-linux-x64-v0.16.0.0.tar.bz2, e507943b46e9d7c9ccdb641dcccb9d8205dd9de660a0ab5566dac5423f8b95e2
monero-linux-x86-v0.16.0.0.tar.bz2, 1c08139550bbbbe1844cf48b6b1d60385be70072841fcbe5e0614fa628a23604
monero-linux-armv8-v0.16.0.0.tar.bz2, 76afab3670df104d392048f52fde92dc611342ca0780690e7e042f1371828acb
monero-linux-armv7-v0.16.0.0.tar.bz2, 8aad622b0e562b610b69bc0ed0fab98bc7bfc77352151b9259ef5c8cab9338d0
monero-android-armv8-v0.16.0.50.tar.bz2, 06c352fd73307f2757c003eb295152715ef2003323db6367d72b258e512f6cbc
monero-android-armv7-v0.16.0.0.tar.bz2, c3f9f41b3fd3c8859d952ac95d9b5ab2cc9ad541a868edf6e9100afff5d4dd7f
monero-freebsd-x64-v0.16.0.0.tar.bz2, 56e68d171d93e2bcea5a7e8eb7f410fcb8fb811c69b6a4f2fad0e15c0a48f6db

Two guides are available to guide you through the verification process: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

Logs for the MRL Meeting Held on 2020-05-20

Wed, 20 May 2020 00:00:00 GMT

Logs

<sarang> GREETINGS
<sarang> hello
<sgp_> hello
<dEBRUYNE> hi
<telapongo23> Hi guys, just eavesdropping here :-D
<hyc> hello
<sarang> Let's move to ROUNDTABLE, where anyone is welcome to share research topics of interest
<sarang> Who wishes to share something? (I saw Isthmus just posted to the agenda issue)
<ArticMine> Hi
<sarang> I suppose that I can share a few items
<sarang> First, I'll review some Arcturus numbers, some of which were presented last week
<sarang> Recall that Arcturus is a modification of Triptych that needs only one proof per transaction, instead of one proof per spend
<h4sh3d[m]> Hi
<sarang> (making it similar to RCT3's update and Omniring)
<sarang> I'll link some plots...
<sarang> Size data for 1 input: https://usercontent.irccloud-cdn.com/file/DYMoX7jy/size-1.png
<sarang> Size data for 2 inputs: https://usercontent.irccloud-cdn.com/file/7Hw5Wnsv/size-2.png
<sarang> Size data for 16 inputs: https://usercontent.irccloud-cdn.com/file/QzJ03VBI/size-16.png
<sarang> You can see the improvement as the number of inputs increases
<sarang> From last week, I'll re-post the timing data...
<sarang> Verification timing for 1-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/airMJ4pC/timing-1-2.png
<sarang> Verification timing for 2-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/iZdBR8xe/timing-2-2.png
<sarang> Related to this, I've been working on the Arcturus transaction security model, which uses an Omniring-style balance game/definition and applies it to the combination of Arcturus proofs and Bulletproof range proofs
<sarang> I'll post that update when I've finished typesetting it and reorganizing the preprint on IACR
<sarang> (but it's still in progress!)
<sarang> Any questions for me on this material?
<hyc> Arcturus seems to blow away the other sig mechs
<fort3hlulz> What's the main drawback(s) of Arcturus compared to other sig mechs?
<fort3hlulz> Seems like a clear win, but maybe there is something I'm missing.
<sarang> The RCT3 update beats it for overall size (when looking at the whole chain), but that does very poorly in verification due to input padding
<sarang> Arcturus relies on a nonstandard cryptographic hardness assumption
<hyc> what are the implications of being nonstandard? needs further proofs?
<sarang> You can see the full-chain comparative estimates on page 12 of the Arcturus IACR preprint: https://eprint.iacr.org/2020/312.pdf
<sarang> note that in Figure 3, RCT3 wins, but in Figure 4, it loses
<sarang> (size vs time)
<sarang> It would need external study to see if it can either be reduced to more standard assumption, broken, or considered/tested enough to be considered reasonable
<sarang> Triptych does not have this limitation, and relies on only standard assumptions
<sarang> I'm submitting it to conference proceedings in the hope that it will get some quality review
<sarang> so I want to update the security model prior to that deadline at the end of this month
<hyc> the win on time is huge
<sarang> FWIW both Triptych and Arcturus are very similar for verification time
<sarang> that's because of how generators are batched similarly in both approaches
<hyc> triptych appears to be a constant factor larger in size
<hyc> well, nearly.
<sarang> It requires multiple proofs, and has some extra elements included (e.g. commitment offsets)
<sarang> Arcturus is a single proof, and does not require any commitment offsets
<sarang> (it does have proof elements that scale with the number of spends, but does so pretty darn well)
<hyc> at least all of the size plots are linear, no silly exponential growth
<hyc> probably an obvious statement but I would choose to optimize time
<sarang> In that case, Triptych and Arcturus are essentially comparable
<sarang> with small variations relating to how balances are checked
<sarang> and these variations disappear at higher ring sizes anyway
<hyc> and Triptych requires no nonstandard assumptions
<sarang> Nope
< ah thanks, I was wondering about this
<sarang> I could probably add the Arcturus-style balance security definition to Triptych as well
<sarang> Isthmus: balance checks in MLSAG/CLSAG/Triptych are identical... sum the commitment offsets and outputs to zero
<sarang> In Arcturus it's built in to the proving system directly
<sarang> At high ring sizes, the offset-based balance check is overshadowed by the large number of group operations required for the rest of the verification process
<hyc> this is some great stuff. Arcturus still grows in size more slowly than Triptych,
<sarang> At low ring sizes, they're more comparable and the difference is notable
<sarang> Yeah
<sarang> Its per-spend elements scale better
<sarang> What's nifty is they both use the same underlying Groth-style cryptographic plumbing, but in different ways
<sarang> (this is the same plumbing that Lelantus uses)
<sarang> Anyway, I've taken up enough of the roundtable time for one day!
<sarang> Does anyone else have research they wish to share?
<Isthmus> TheCharlatan updated the encrypted unlock time research proposal with sarang's timing data: https://github.com/insight-decentralized-consensus-lab/monero\_encrypted\_unlock\_time
<sarang> s/Tryptich/Triptych/
<Isthmus> (based on feedback at previous MRL meeting, and input from sarang)
<Isthmus> Also, experimenting with a new application for surae's seashell avatars project. Essentially, each transaction fingerprint (behavior or metadata) is compared against the behavior of the core software and assigned a 0 if matching or 1 if deviating.
<Isthmus> Looping over fingerprints creates a fingerprint string that is ingested to produce a visual hash. These could be added to a research blockchain explorer so that it's easier to tell at a glance which transactions must have been generated by custom software.
<sarang> I'm glad the 3-CLSAG and 3-Triptych data was useful!
<Isthmus> For example, the first image shows the avatar for transactions that are from (or mimic) the core GUI/CLI, which has fingerprint ...0000
<Isthmus> https://usercontent.irccloud-cdn.com/file/vjCauM0y/image.png
<Isthmus> The secnd image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010)
<Isthmus> the bottom image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010)
<Isthmus> https://usercontent.irccloud-cdn.com/file/Lzt9vfyJ/image.png
<Isthmus> (note that this particular issue was fixed in recent update)
<Isthmus> Anyways, still very early toy/prototype
<sarang> So the hash inputs are individually set bits? 1 = "basically the same as standard", 0 = "different enough"
<sarang> and this is done over different characteristics to build the input string?
<Isthmus> Yep
<Isthmus> 0 = "the core wallet would construct a transaction in this way"
<Isthmus> 1 = "the core wallet would never construct a transaction this way"
<Isthmus> e.g. the juvenile spend example
<sarang> got it
<Isthmus> Will spice it up a bit though, surae comments "The skin of the shells could be fractals dependent on the hash input visualized in 2d with *color schemes* selected from families of pleasing color triples based on hash input..."
<UkoeHB_> What's a juvenile ring member,
<UkoeHB_> ?
<Isthmus> Any transaction that includes a ring that includes a ring member less than 10 blocks old (based on the time it was mined)
<Isthmus> https://github.com/monero-project/monero/issues/5712
<UkoeHB_> ah
<Isthmus> The core wallet has observed a 10-block lock time, so they must have been generated by custom software
<Isthmus> But now it's a consensus rule
<sarang> To what extent does the visual fingerprint identify the extent to which the transaction is nonstandard?
<sarang> e.g. can you look at a fingerprint and see "oof, this transaction is _very_ nonstandard!"
<sarang> (obviously the Hamming weight of the input will tell you this by inspection)
<Isthmus> No, since the visual hash function is appropriately unstable
<UkoeHB_> You could look at the fingerprint string itself to see how different, since more 1s = more different
<sarang> That's what I mean by the Hamming weight
<Isthmus> aaaactually if the hamming weigh was used to select the colorscale......
<Isthmus> Then it could be intuitively accomplished
<Isthmus> if colorscale(0) is greenish
<sarang> At that point, what's the usefulness of the fingerprint shape?
<sgp_> going all the way back to the unlock time proposal, I still think the tradeoffs aren't worth it
<Isthmus> Because 0010 and 0001 are different
<sarang> True
<sarang> So it really only tells you if the actual strings are different
<sarang> I guess I figured the "more useful" component in general might be the Hamming weight
<sarang> since one goal is to minimize it
<Isthmus> It depends if 'degree of wrongness' is important
<UkoeHB_> I agree sgp_ it feels quite expensive
<Isthmus> From my perspective, 0010, 0001, and 0011 are 3 distinct signatures
<Isthmus> Even though 0011 is more worse :- P
<UkoeHB_> ArticMine: how is it going with your penalty/fee proposal?
<sarang> While we wait to see if ArticMine is around, were there any other questions on the material Isthmus presented?
<sgp_> none about the presented material, but I eventually have a question for Isthmus about the coinbase vs non-coinbase spend distributions
<Isthmus> Hey @sgp_ what do you have in mind? :- )
<sarang> I would also be interested to see that for BTC
<sgp_> heelo Isthmus :)
<sgp_> s/heelo/hello
<monerobux> sgp_ meant to say: hello Isthmus :)
<sgp_> I really want to segregate coinbase outputs form other outputs
<sgp_> to do this, I ideally would like to know what the independent spend distributions are for these two categories of outputs
<sgp_> my suspicion is that coinbase outputs are spent faster on average
<Isthmus> We can ascertain this by subtracting the reference distribution from the observed ensemble distribution
<Isthmus> And split it by type:
<Isthmus> distribution(coinbase inclusion in rings) - reference_distribution
<Isthmus> distribution(non-coinbase inclusion in rings) - reference_distribution
<Isthmus> I think @binaryFate was going to present this type of analysis at Konferenco, though I don't know if was split up by output type (non/coinbaase)
<sarang> Having a direct measurement from something like BTC would be very helpful regardless
<sarang> ideally to follow the Miller et al. idea of comparing known-estimated Monero behavior to BTC
<Isthmus> I'll see about extracting true BTC spend times from Google's BigQuery dataset
<sarang> That'd be great
<Isthmus> There's probably some way to do it in a clever SQL one-liner
<Isthmus> But I can do it in 20 lines!
<Isthmus> :- P
<sarang> Separately, it would also be interesting to see how/if overall BTC spend times have changed since Miller et al.'s paper
<sarang> They used two different large groups of blocks
<sgp_> we need to have some selection for the coinbase-only rings in any case, though if the results show that the distributions are different, then that's even more reason to segregate
< this
<sgp_> note I still support coinbase-only rings even if the distributions are exactly the same :p
<sarang> In the interest of time, were there any other topics to be brought up before moving on?
<sgp_> that's all fro me, thanks Isthmus
<sgp_> *from
<UkoeHB_> Any new comments on the Tx Supplement proposal?
<sarang> Restructuring for uniformity and Janus mitigation seems useful and reasonable to me, FWIW
<sgp_> agreed
<sgp_> costs are small
<sarang> Especially with the savings from CLSAG
<Isthmus> I'm in favor. Uniformity is the whole point.
<ArticMine> UkoeHB_ It is almost done. I held it back to give ti ore thought especially with COVID-19 which is a perfect scenario for the issue
<ArticMine> I should have this in the next two weeks
<UkoeHB_> Cool thanks :)
<sarang> OK, with the last few minutes of the hour, let's get to ACTION ITEMS
<sarang> I would like to finish the update of the Arcturus security model, to get the updated preprint submitted for review
<sarang> And will be discussing the CLSAG audit with Teserakt
<sarang> Anyone else?
<UkoeHB_> In the tx supplement proposal I recommend moving to sorted TLV in the extra field. However, it's not completely solved. One option is to retain 'restricted tags' for core features (e.g. encrypted payment IDs, miner nonce). Are restricted tags worthwhile or too hands-on?
<sarang> Well, certain tags would be required by consensus... can you refresh us on your definitions here?
<UkoeHB_> Moving to restricted tags might force more uniformity out of pool implementations, since there would be a fixed miner nonce size. However, they could just move their unique nonces to unrestricted tags.
<UkoeHB_> Only encrypted payment IDs would remain in the extra field after the update
<UkoeHB_> And miner extra nonce
<UkoeHB_> So not much consensus left
<sarang> Oh, TLV for _extra only_... of course
<sarang> nvm
<sarang> I was thinking about fields in general, which is not correct
<UkoeHB_> With a restricted miner nonce we (probably I) could release a miner nonce guideline for pool implementer to reference
<UkoeHB_> If it's easy enough then hopefully most pools and solominers would be indistinguishable on-chain
<sarang> OK, any other questions, topics, or action items before we adjourn?
<h4sh3d[m]> I posted a proposal for the atomic swap, feedback are welcome
<sarang> Link?
<h4sh3d[m]> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/145
<sarang> thanks
<sarang> All right, let's adjourn in the interest of time (and for log posting purposes). Thanks to everyone for attending!

Logs for the MRL Meeting Held on 2020-05-13

Wed, 13 May 2020 00:00:00 GMT

Logs

<sarang> First, GREETINGS
<sarang> Hi
<binaryFate> hello!
<Isthmus> Heyo
<h4sh3d[m]> Hello
<ArticMine> Hi
<sarang> Next up is ROUNDTABLE
<rehrar> hi
<sarang> Does anyone have research of interest to share with the group?
<sarang> I know Isthmus just mentioned something before we started
<Isthmus> Hey everybody. I incorporated y'all's feedback on the research proposal (thanks for your input), updated version here: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/142
<Isthmus> Most of the changes are in the Roadmap section
<Isthmus> For phase 1 we've switched to a very formal enumeration of adversary capabilities and Monero features of interest, and will document possible issues and solutions along the lines of:
<Isthmus> "Monero's [component] is vulnerable to [impact] by a hypothetical adversary that can leverage [algorithm]. In general, the solution must meet [requirements]. Current relevant methods include [cryptosystem] which would require [migration process] and has [tradeoffs] that would prevent implementation until [device bandwidth/resource threshold] is widely available."
<Isthmus> Throughout this entire project, the community will receive updates during the weekly #monero-research-lab meetings. During phase 3 however, several specific documents (the key deliverables from this research) will be freely published:
<Isthmus> 1. User-friendly writeup: This community-facing writeup will provide an approachable explanation of how hypothetical quantum computers may impact Monero, and possible future mitigations. The writeup should minimize FUD and provide the context that these vulnerabilities apply to almost all cryptocurrencies (not only Monero).
<Isthmus> 2. Technical documentation: An MRL position paper to distill key information for (current and future) researchers and developers. The writeup should formally describe vulnerabilities, and highlight potential strategies and solutions, noting their tradeoffs. Code snippets may be included if appropriate for pedagogical purposes or clarity.
<Isthmus> 3. Non-technical 1-pager: An ELI5 / TL;DR summary will be provided for journalists, Monero Outreach, etc. This blurb will discuss risks and myths with no technical jargon, with key takeaways that a broad audience will appreciate.
<Isthmus> Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos. :- )
<Isthmus> (ends notes)
<Isthmus> Oh, I'll X-post the proposal to Reddit today
<sarang> I like the change in scope, particularly focusing on communicating the current state of the protocol
<sarang> Moving away from specific things like implementations and proofs-of-concept for changes seems wise, especially considering that the state of the art will change
<Isthmus> ^ yep
<Isthmus> It's important to note that many current post-quantum cryptography candidates require large proofs and significant computational resources, and will thus not be suitable for immediate deployment. For this reason, understanding broad strategies and their tradeoff will be more useful than specific implementations. Thankfully, consumer device capabilities increase over time, and researchers continue to
<Isthmus> discover new faster/smaller proving systems, so these practical barriers are temporary.
<sarang> Were there any questions for Isthmus about this proposal? (Comments could also be made on the proposal itself to reach a wider audience)
<rehrar> nop
<sarang> OK, does anyone else wish to share research of interest?
<sarang> If not, I have a few items to share
<h4sh3d[m]> Yes, I have something
<h4sh3d[m]> Earlier someone posted this: https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
<sarang> Ah yes, the atomic swap idea
<h4sh3d[m]> I had a closer look. The interesting part is the usage of ECDSA adaptor signature
<sarang> Avoids the use of hash preimage proofs IIRC?
<sarang> (I have yet to examine it in detail)
<h4sh3d[m]> Yes, the protocol is very close what I already shared here
<h4sh3d[m]> But with the idea of using a cross group dl-proof with an ECDSA adaptor signature might work
<sarang> At the very least, a cross-group DL equivalence proof is very straightforward
<sarang> and exists today
<h4sh3d[m]> Yes, that's why it's interesting =)
<h4sh3d[m]> The new part for me is this: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
<sarang> Is that link related to the gist?
<Isthmus> Very cool
<sarang> Ah, the link is from the gist
<h4sh3d[m]> Yes, it's the first link "single signer ECDSA adaptor signatures" in the Gist
<sarang> got it
<sarang> I'm excited to work it out in detail!
<h4sh3d[m]> With this, we can put one half of the monero key as the adaptor Y (or the other half depending if the swap succeed or not)
<h4sh3d[m]> I'd be happy to work on this too. As zkao mentioned it earlier we are thinking about a proposal if it make sense
<sarang> Having more eyes on ideas like this is definitely a good thing
<sarang> Thanks for sharing this h4sh3d[m] (and zkao earlier as well!)
<sarang> Were there any questions for h4sh3d[m] ?
<h4sh3d[m]> Cool, I'll continue posting my findings here in the next days.
<sarang> Thanks, please do
<sarang> I wanted to finish up some work on next-gen transaction protocols, so I wrote up a proof-of-concept C++ implementation of Arcturus: https://github.com/SarangNoether/monero/tree/arcturus
<rehrar> weeeeee!!!!
<sarang> The usual disclaimer that it has not undergone any kind of review, and should be considered unsafe for production use
<sarang> However, I got timing data from it
<sarang> I had to rewrite the performance tests for Triptych, MLSAG, and CLSAG for better comparison since Arcturus integrates balance checking directly into the proof (and the others do not)
<sarang> The results, which I'll paste in just a sec, show that transaction input/output structure plays a role in the overall timing results
<sarang> Here is data for 1-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/KZxENlzN/timing-1-2.png
<sarang> Here is data for 2-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/Ww2hDEbo/timing-2-2.png
<sarang> These account for the total verification time for signature/proof verification and balance checks
<sarang> but does not include range proof verification (that's the same for all protocols)
<sarang> You can get the same data by choosing the appropriate performance test parameters on my clsag-device branch (for MLSAG _and_ CLSAG), triptych branch (for Triptych), and arcturus branch (for Arcturus)
<sarang> The grey lines are centered at the 11-MLSAG point to show the current timing
<binaryFate> it looks super close to Triptych, any hunch how it would look like for more-inputs and/or more-outputs?
<sarang> At higher ring sizes, Triptych and Arcturus should stay very close, as the balance check component becomes less relevant overall
<sarang> The difference mainly arises from whether the balance check group operations are separated (in Triptych) or included in a single multiscalar multiscalar operation with the rest of the proof (in Arcturus)
<sarang> and that difference goes away at higher ring sizes
<sarang> The real benefit is in transaction size
<sarang> I thought I already had Arcturus included in plot data, but it turns out I don't... I'll work that out right after the meeting and post it here
<sarang> Unrelated to this, I'm coordinating a statement of work for the CLSAG audit with OSTIF and Teserakt, the audit firm that the audit workgroup recommended
<sarang> Were there any other questions for me on these topics?
<moneromooo> Oooooh ^_^
<sarang> Does anyone else have topics to discuss for the roundtable, before we move on?
<Isthmus> Hmm, I just remembered a showerthought to generate seashell avatars based on transforming heterogeneously-structured transaction metadata into a signature string, and then running that through surae's visual hash function...
<Isthmus> I'll try to prototype it this weekend so I can share examples next week (kind of hard to describe abstractly)
<sarang> Oh man, I remember that seashell work! It's been a while
<Isthmus> Yeah, that's a throwback. I forked Surae's repo back in 2018 and turned it into a notebook, but never connected it to Monero input data. https://github.com/Mitchellpkt/seashells/blob/master/seashells\_notebook.ipynb
<sarang> I suppose we can move on to ACTION ITEMS and finish up the meeting if there isn't anything else to discuss
<selsta> I wish we could display seashells in CLI wallet.
<sarang> I'll be incorporating some changes to my in-memory key encryption PR, looking into that swap proposal in greater detail, and updating the Arcturus security model for conference submission
<sarang> Anyone else?
<h4sh3d[m]> I'll study more in details adaptor for ECDSA and rewrite the concerned parts of the atomic swap paper.
<sarang> You mean updating your original write-up?
<h4sh3d[m]> yes
<sarang> Excellent
<sarang> All right, I suppose we can adjourn; thanks to everyone for participating!
<sarang> Logs will be posted shortly to the agenda issue

Logs for the Community Meeting Held on 2020-05-09

Sat, 09 May 2020 00:00:00 GMT

Logs

Logs for the MRL Meeting Held on 2020-05-06

Wed, 06 May 2020 00:00:00 GMT

Logs

<sarang> All righty! Time for the weekly research meeting
<sarang> As always, we begin with GREETINGS
<ArticMine> Hi
<UkoeHB_> hi
<atoc> hi
<sarang> Let's move on to ROUNDTABLE
<sarang> Any research of interest that folks wish to share?
<sarang> I can share a few things, I suppose
<sarang> I worked up a PR to update how keys are encrypted in memory
<sarang> This has follow-on effects to how they're stored on disk, and I'm making some additional updates to improve the existing unit tests and add others
<sarang> and I'm finishing up a test implementation of Arcturus, the extension of Triptych that offers better proof sizes
<sarang> I'd like to determine exactly what the timing differences are, since initial estimates suggested that Arcturus and Triptych would be very close
<kenshamir[m]> Sorry if I've missed this; are there any comparisons for Arcturus, Triptych and CLSAG ?
<sgp_> hello
<sarang> And kenshamir[m]: I have comparisons for CLSAG and Triptych, but this will add actual implementation data for Arcturus when finished
<kenshamir[m]> Oh right, very cool
<sarang> The size data is already known, FWIW
<sarang> But the Arcturus timing was always an estimate based on operation counts
<sarang> It's different enough in how it handles transactions that I'd like to know for sure
<kenshamir[m]> concretely?
<kenshamir[m]> Is there a link for it?
<sarang> The size/timing data?
<kenshamir[m]> Yeah, the size data
<sarang> Yeah, let me pull it up
<kenshamir[m]> Probably may not be that helpful for Monero, but there is a new paper out on an endomorphism that allows you to compute aG + bH faster in variable time
<sarang> Page 11: https://eprint.iacr.org/2020/312.pdf
<kenshamir[m]> Link : https://eprint.iacr.org/2020/454.pdf
<kenshamir[m]> Thank you
<sarang> Anyway, that's what I wanted to share
<sarang> Does anyone else have research of interest?
<UkoeHB_> what's the gist of your encryption update?
<sarang> The in-memory encryption of keys was being done with a chacha stream that was XORed with keys, instead of just encrypting the keys with chacha directly
<sarang> This PR makes this change
<sarang> The existing unit tests for wallet and key encryption also get some updates
<UkoeHB_> ah interesting
<sarang> It also transitions old encrypted keys to the new format, which needs better testing that I'm still working on
<sarang> Seems pretty quiet today!
<sarang> We could always end early if there isn't more that needs to be discussed...
<sgp_> I have nothing to add except to remind people that I still want coinbase outputs to be avoided entirely in non-coinbase-spend rings :p
<sarang> You mean the idea that a ring containing a coinbase output must have all coinbase outputs, right?
<sarang> sgp_: can you briefly recap your rationale, to ensure everyone is on the same page?
<sgp_> yes that idea
<sgp_> rationale is that no normal users spend coinbase outputs
<sgp_> even people who mine on mining pools never spend coinbase outputs
<sgp_> so the selection of these is markedly different from expected user spend behavior
<sarang> When I thought about this earlier, I was concerned that it sort of kicks the can down the road one hop on the graph
<sgp_> separating these will increase the effective ringsize for most (>99%) users by 10-20%
<sgp_> sarang: it kicks the can down the road, but it's still MUCH better
<ArticMine> Interesting
<sarang> And that if a heuristic was "this coinbase probably isn't the true signer" previously, it would become "this output that came from a coinbase ring probably isn't the true signer" as a somewhat weaker heuristic
<sarang> Yeah, I think it's better but doesn't totally eliminate it
<sarang> If it were implemented, there would need to be a decision on what selection distribution to use, which should probably be based on a transparent-chain analysis at minimum
<sgp_> it's still essentially one set of transactions separated (one ring signature? I'm struggling to explain this simply and also accurately)
<sarang> to see if it matches the overall distribution
<ArticMine> The idea is that an ouput from a mining pool is far more likely to e spent by a normal user
<sgp_> basically the real spend of the after-coinbase output would look the same as several transactions that select this output as the decoys
<sarang> Yeah
<sarang> Does my statement about the analysis for a distribution make sense?
<ArticMine> I agree it mitigates but does not completely eliminate the risk
<sgp_> but now this accounts for the behavior that the user could just be a miner on a mining pool, for example
<sgp_> which is hugely broader
<sarang> But it is true that right now, the spend patterns of coinbase vs non-coinbase are assumed to be the same by the selection algorithm
<sarang> It'll be very interesting to see that distribution for coinbase-only
<sgp_> only solo miners can spend coinbase outputs. Miners on mining pools can also spend from-coinbase outputs
<sarang> right
<sgp_> so while it kicks the can down the road, in terms of practical behavior, it's a night and day improvement
<sarang> I'll ping Isthmus here, since his group has access to this sort of data for other chains
<sgp_> discussion on this idea has been mixed for years. I'd like to see this actually done
<sgp_> 10-20% better effective ringsizes just with smarter selection
<ArticMine> It is a significant mitigation of the issue. I do not see a clear downside to this.
<sgp_> downside is to people that are running private pools. They effectively need to "churn" once by not directly sending the coinbase outputs to people
<sgp_> I think this is a small tradeoff
<sarang> I think it's an improvement, provided it doesn't introduce unexpected or unintended consequences to the selection distribution, and is based on distribution data from known spends where reasonable (e.g. Bitcoin)
<zkao> hoi, can someone evaluate how sound this ECDSA adaptor signature is? https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/ if these ECDSA adaptor signature works, it looks like the atomic swap can be done using a scheme similar to the suggested by andytoshi-sarang (equivalent discrete logs), mixed with the game theory from h4sh3d's proposal: all game theory on bitcoin script (forcing players to act or
<sgp_> I agree with that caveat, though I want to add my own caveat that I don't see how it can be worse
<zkao> lose), and no need for monero refund. so it should work on monero today.
<sarang> zkao: I didn't invent that cross-group discrete log idea; it was andytoshi
<zkao> yes, i know, u proposed
<sarang> sgp_: if the coinbase-only selection distribution ends up being very different to the overall distribution, it would introduce a heuristic for coinbase true signers
<sarang> and for all we know, it could be a very different distribution in that miners/pools spend immediately or something
<sgp_> luckily then we can approach coinbase with its own algo
<sgp_> which we can't do now
<sarang> The non-coinbase distribution could be easily modified to simply redraw if it chooses a coinbase
<sgp_> if these are actually very different spend patterns, then the possibility for increased privacy is even greater
<sgp_> since we can handle them separately, not together
<sarang> The coinbase distribution would simply be some fixed selection distribution on block order, that doesn't need to do the shuffling method we do now
<sarang> sgp_: right
<sgp_> my gut suggests coinbase spends are quicker on average
<sgp_> but Bitcoin data would be great for that ofc
<sarang> Right
<sarang> Hopefully someone like Isthmus's group can get that data, since they have easy access to the dataset AFAIK
<sgp_> I still support avoiding coinbase with the stupid method of re-selecting a coinbase is chosen, though improvements can make that better. I see even this stupid model as an incremental improvement
<sgp_> *if a coinbase is chosen
<sgp_> what I'm trying to say is that the data on Bitcoin should help make the selections better, but that they are not prerequisites to switch since it can't be worse than it already is in my eyes
<sarang> If there were no known distribution from Bitcoin etc., what selection for coinbase-only would you suggest?
<sarang> Reselect-on-coinbase seems reasonably for non-coinbase rings, but there still would need to be a chosen selection distribution for coinbase-only rings
<sgp_> same as current probably? I agree that's not ideal
<sarang> Well, the current one takes block density into account, and that's not relevant for coinbase-only
<sgp_> keeping in mind most public pools publish this data openly anyway
<sgp_> so frankly the coinbase rings would be susceptible to a lot of public data causing a high proportion of heuristically dead outputs
<sgp_> in the worst of cases I say ~90% of of the hashrate accounted for by public pools sharing coinbase data, so ringsize 11 doesn't really help with that in the best of cases
<sgp_> *I saw ~90%
<sarang> Well, at that point you could _almost_ suggest removing the requirement for nontrivial rings in coinbase-only at all
<sarang> *altogether
<sarang> If the thought is that analysis could reveal true signers in a huge number of cases anyway
<sgp_> there's a push for pools to not share this data, but I agree that in the current case, coinbase rings should be considered to offer near-zero protection
<sgp_> really any coinbase spend. in the current situation, they are still heuristically dead, just spread across normal users' transactions
<sarang> Hmm, we're a bit over time
<sgp_> yeah we can end
<sarang> Let's move to ACTION ITEMS and then continue discussion
<sarang> I have some unit tests update to make for the key encryption PR, and hopefully can get Arcturus code working in C++ with the timing data that I want
<sarang> Any other updates, action items, etc. before we adjourn?
<sarang> If not, adjourned!
<sarang> Logs will be posted shortly

Logs for the MRL Meeting Held on 2020-04-29

Wed, 29 Apr 2020 00:00:00 GMT

Logs

<sarang> OK, let's get started with the research meeting!
<sarang> First, GREETINGS
<sarang> hi
<ArticMine> hi
<[keybase] unseddd>: o7
<UkoeHB_> hi
<sarang> Let's go ahead and continue with the ROUNDTABLE
<sarang> Anyone is welcome to share research topics of interest
<sarang> I suppose that I can share a few things
<sarang> Relating to timelocks, I extended CLSAG and Triptych to support them
<sarang> CLSAG: https://github.com/SarangNoether/monero/commit/28f098260c5bb4da57bb78ebc885fe27c9f10c39
<sarang> Triptych: https://github.com/SarangNoether/monero/commit/ed48ab1686b7e7405bd6656c18e37ea21e01fe05
<sarang> Here is corresponding timing data: https://usercontent.irccloud-cdn.com/file/dQXuFH2U/timing.png
<sarang> 3-CLSAG and 3-Triptych are the timelock-friendly data series
<sarang> The other data series are unchanged from when I first shared them
<sarang> I suspect that 3-CLSAG could be optimized by perhaps another 10% or so from what appears on the plot
<sarang> Unrelated to this, I'm updating how in-memory key encryption is handled, which is taking a bit longer than expected
<sarang> and am reviewing the new CLSAG fuzzer tool that unseddd provided
<sarang> That's about it from me!
<sarang> Are there any questions that I can answer?
<Isthmus> Nice work
<sarang> Thanks!
<ArticMine> CLSAG optimization in verification time, size or both
<[keybase] unseddd>: seconded, nice stuff sarang
<sarang> ArticMine: in verification time, and only for the new 3-CLSAG variant that would apply to encrypted timelocks
<ArticMine> Great work by the way
<ArticMine> Thanks
<sarang> When I wrote 3-CLSAG, I used a particular multiscalar multiplication that could likely be made faster for this particular case
<sarang> Also, huge thanks to unseddd for reviewing CLSAG and writing the fuzzer tool
<[keybase] unseddd>: is 3-CLSAG limiting the multisig to three parties?
<[keybase] unseddd>: np :)
<sarang> No, it adds another key component that would be used for timelocks
<sarang> Right now we have two key components: one for the usual signing, and the other for balance purposes
<[keybase] unseddd>: ah, thanks for the clarification
<sarang> Does anyone else wish to share research of interest?
<UkoeHB_> it seems like 3-triptych would reduce the ringsize likely to be selected by a power of 2
<[keybase] unseddd>: not much interesting on my end. just reading formal verification papers + some pq-crypto stuff from Mike Hamburg
<sarang> Adding encrypted timelocks is a nontrivial verification hit
<ArticMine> What is the time ans size cost
<sarang> What might be interesting as an alternative would be to allow cleartext timelocks, but update decoy selection to account for known spend patterns
<sarang> It would not eliminate fingerprinting, but could help to mitigate age-related selection heuristics
<[keybase] unseddd>: are there any leakage issues having the timelock in the clear?
<sarang> ArticMine: going from CLSAG to 3-CLSAG is about 1.4x increase in verification time
<sarang> Which could probably be reduced slightly with some extra work
<sarang> In terms of size it's fairly trivial... adding an extra auxiliary key image (this does not account for other non-signature data)
<sarang> unseddd: for sure
<sarang> I'm not saying that I advocate for such an approach, only that it could be an option
<sarang> and would not imply any size/time hits
<UkoeHB_> it's a ways down the road, but I'd like to mention it now; when deciding ring sizes for next gen tx protocol I feel it should be based on a broader analysis of theoretical maximum tx throughput of the network; this is because the max tx volume is when rings are _least_ useful to defend against non-scaling graph heuristics, and because larger ring sizes actually reduce the max tx volume; it's an optimization
<UkoeHB_> problem
<[keybase] unseddd>: right, from a naive perspective, triptych seems like it has enough savings for the hit from timelocks
<sgp_> sorry I'm late. catching up
<ArticMine> UkoeHB_ The maximum tx throughput is also dependent on external factor tat keep improving over time
<UkoeHB_> unfortunately that optimization depends on the efficacy of ring sizes.. which we don't have a complete understanding of; I hope suraeNoether can return to that topic at some point
<UkoeHB_> ArticMine: true, there are a lot of factors to consider!
<sarang> At the very least, we now have concrete numbers for the spacetime effects of ring size increases
<atoc> hi
<sgp_> the cost of encrypted timelocks seems extreme to me tbh. I don't want to go there unless we know we need to support them for a good use-case
<sarang> Getting timelock-related spend age data from transparent chains might be helpful if it's decided to continue to allow cleartext timelocks
<sarang> Then output selection could be improved to account for it, and reduce the usefulness of spend-age heuristics
<[keybase] unseddd>: use-case: timelocks necessary for atomic swap, encrypting is the most private
<[keybase] unseddd>: could also see the counter-point for clear timelocks if they are necessary for atomic swaps (interop w/ clear chains maybe)
<sgp_> sarang: I agree, but given the current low utilization, I consider this low priority. The impact to the wider network is negligible
<ArticMine> Payment channels come to mind here
<ArticMine> also escrow
<sarang> Getting that kind of transparent chain data seems pretty straightforward
<sgp_> if there's a payment channel, then we can move to make encrypted mandatory. when that happens
<Isthmus> @sarang, it's on my to-do list for XMR and BTC
<sarang> :D
<sarang> How do you plan to examine spend-age data for XMR?
<sarang> It was examined in Miller for "deducible" outputs (pretty sure that's the term they used) that were the result of chain reactions, which we find don't occur anymore
<Isthmus> Oh, I just meant comparing the unlock time height to block height to see how many of them even make sense
<Isthmus> Not that current usage tells us much about future applications.
<sarang> Ah, got it
<Isthmus> What is it that you were interested in?
<atoc> Isthmus are you thinking about atomic swaps these days at all/
<Isthmus> @sarang sorry I'm in a zoom call and IRC meeting at the same time, and missing little pieces of both
<sarang> I'd like to see the age distribution of spent outputs in a transparent asset (like BTC) relative to lock expiration, to see if it differs substantially from the overall age distribution
<sarang> No problem Isthmus!
<Isthmus> ahhh, yea I can't officially do that for Monero yet. I'll pull it for BTC though.
<UkoeHB_> can't officially? it's possible?
<sarang> Thanks! The overall distribution likely is still similar to the Miller data
<sarang> (for BTC, of course)
<sarang> and having that data would be an interesting check of that
<Isthmus> @UkoeHB_ yeah, I mean my research over the past few years reveals anonymity puddles covering like 20% of transactions. Then change outputs bleed everything, so there's a ton of data on obviously real spend times. BUT no guarantee that it's representative.
<Isthmus> I'll be supper curious to see the BTC distributions, will try to get that in the next week or so.
<Isthmus> *super
<sarang> Yeah, Miller's team used two different large sets of blocks in BTC for their analysis
<sarang> and found the distributions to be similar
<sarang> but it doesn't appear they accounted for locks
<sarang> OK, did anyone else have a topic to discuss?
<Isthmus> Insight is interested in researching practical post-quantum cryptography for Monero, especially privacy features that will remain secure against retrospective deanonymization by future adversaries that can utilize Shor's algorithm, Grover's algorithm, etc. I want to know what our options are, and their costs (complexity, proof size, generation/verification time, etc)
<Isthmus> https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/README.md
<Isthmus> Looking for feedback on the research plan.
<Isthmus> Our goals are to (1) study and simulate the threats listed above to assess vulnerability to quantum computers, (2) evaluate post-quantum cryptography scheme candidates to create a roadmap for hardening Monero against quantum adversaries, and (3) provide open-source proof-of-concept code and demos where applicable.
<[keybase] unseddd>: i like pq stuff :) will take a look
<sarang> Sounds like a fascinating project
<sarang> I'd be very curious to see what exactly the Phase 3 deliverables would look like
<Isthmus> Me too! ^_^
<sarang> and I think it'd be important to assess any transtion points between constructions/protocols
<sarang> e.g. it was possible to transition from pre-CT to post-CT
<Isthmus> Yeah, we'll have to document both the transition and post-transition costs/tradeoffs
<sarang> New constructions are great, but if it's not possible/feasible to transition on the same chain, that's a sticking point
<[keybase] unseddd>: here is the Hamburg paper i am reading through: https://www.shiftleft.org/papers/qromcca/
<ArticMine> Yes this is a very interesting project
<sarang> Are you confident about the timeline?
<sarang> Particularly surrounding the Phase 3 stuff
<sarang> (not that practical quantum computers are expected by the end of summer...)
<Isthmus> There's two types of things we could prototype
<UkoeHB_> it does say May - June, only a couple days away, not sure if a CCS could be approved and funded in time
<[keybase] unseddd>: ten million qubits by fall!!!
<Isthmus> (1) demo of a quantum computer breaking a Monero encryption feature (at a reduced keysize, or something like that)
<UkoeHB_> s/June/July
<monerobux> UkoeHB_ meant to say: it does say May - July, only a couple days away, not sure if a CCS could be approved and funded in time
<Isthmus> Adam did this before, got an IBM quantum computer mining bitcoin at shorter hash length
<Isthmus> So that's demo breaking classical crypto
<Isthmus> (2) prototype a possible solution
<Isthmus> (so we'd use traditional computers and prototype a future solution)
<[keybase] unseddd>: _thoroughly impressed_
<Isthmus> Now honestly, I think that #2 would be way cooler. But it also may be hopeful thinking
<Isthmus> I've seen Adam rapidly convert math papers to code before, but this is going to be a pretty serious endeavor
<sarang> Either way, would be fascinating
<Isthmus> here was my note in the writeup
<Isthmus> "Phase 3 deliverables: The best use of time during this final stage depends strongly on results from the exploratory research. Likely deliverables are a proof of concept or prototype tooling for demonstrating a vulnerability or potential solution"
<UkoeHB_> would (1) also include a comparison with a classical computer on the same task? at reduced keysizes, the encryption is weaker on classical computers too
<[keybase] unseddd>: Isthmus: are Adam and you regularly in IRC? what is best communication channel?
<Isthmus> @UkoeHB_ exactly
<Isthmus> Adam'll be on IRC shortly :- )
<Isthmus> We'll probably do a lot of the research in this room, if that's okay with people?
<Isthmus> Or could make #pq-mrl
<sarang> Up to you!
<Isthmus>
<sarang> OK, any other topics to address before finishing up the meeting?
<UkoeHB_> does anyone have new thoughts on https://github.com/monero-project/monero/issues/6456?
<[keybase] unseddd>: UkoeHB_: unfortunately no, have been consumed elsewhere. many apologies
<sarang> UkoeHB_: I got unexpectedly caught up in other coding, and didn't review in detail yet :/
<Isthmus> Oh! Yeah, I'll look at that by Monday. Hopefullly today
<sarang> my aopologies
<sarang> s/aopologies/apologies
<monerobux> sarang meant to say: my apologies
<sarang> All righty, any ACTION ITEMS for the next week to share?
<sarang> I will be reviewing 6456, reviewing some CLSAG tests, updating some in-memory encryption code, etc.
<Isthmus> I'll probably bump the pq-monero proposal over to CCS by EOW, so shoot me a message (irc or isthmus@getmonero.org works) if you have any suggestions for updates or additions
<UkoeHB_> on a certain level I have nothing else to contribute to the proposal; whether it gets implemented or not is out of my control; keep in mind it likely won't be superseded by anything, so for 'tx extra', 'janus mitigation', 'tx pub keys', and 'view tag', that's the 'final answer' for the forseeable future
<atoc> I'm working on some slides (summary) that details how Grin does their grin-btc atomic swap
<atoc> looking to see if we can get some insight for xmr-btc swaps
<hyc> Iǘe become convinced that itś never in any XMR holders'interest to swap for BTC, due to BTC taint issues
<hyc> but I'd be curious to see how it can work, for future XMR(earth)/XMR(mars) swaps
<[keybase] unseddd>: hyc: even for true DEX scenario?
<[keybase] unseddd>: marsero
<hyc> especially for true DEX, wher eyou can't vet the BTC
<hyc> the benefits are all one-sided, in favor of the BTC seller
<Isthmus> Eh if I've got a wallet full of Monero, but the sandwich shop I'm standing in only takes BTC, I might find that swap useful.
<ArticMine> I have to agree with hyc Selling XMR for BTC on a swap is very dangerous
<[keybase] unseddd>: yeah, i see your point. do you have the same opinion for other swap pairs?
<hyc> if the other pairs also involve transparent coins, yes
<sgp_> +1 concern here
<sarang> Well, in the interest of time (our hour is up), I'll adjourn the meeting for log purposes, but discussion can of course continue

Logs for the Community Meeting Held on 2020-04-25

Sat, 25 Apr 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<kinghat[m]> o/
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/457
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<msvb-mob> Hello.
<binaryFate> random guy runs a community meeting
<xmrscott[m]> Osu~
<netrik182> hi
<deedledea> hi!
<sgp_> binaryFate: lmao
<ajs-mob> hi
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> Check out resources at https://communityworkgroup.org. We can use this page to more easily organize Monero Community Workgroup resources going forward. It also has a calendar you can subscribe to for meeting reminders.
<sgp_> Does anyone have community (non-workgroup) updates to share?
<sgp_> 3. CCS updates
<sgp_> Funding required:
<sgp_> Monero Debian Package Repository for 2 years (42.54 / 73 XMR) https://ccs.getmonero.org/proposals/adrelanos-debian-package.html
<sgp_> xiphon part-time coding (3 months) (69.09 / 371 XMR) https://ccs.getmonero.org/proposals/adrelanos-debian-package.html
<sgp_> Ideas (to be discussed):
<sgp_> Translation of Mastering Monero into Brazilian Portuguese (37 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/137
<sgp_> Note: I have a financial interest in Mastering Monero
<rehrar> profiteering
<rehrar> reeee
<netrik182> I proposed translating Mastering Monero if anyone has questions
<netrik182> There was a reddit post as well: https://old.reddit.com/r/Monero/comments/g3vqoi/my\_ccs_proposal_to_translate_mastering_monero_is/
<sgp_> thanks for being here netrik182. they helped us a TON with the subtitles for Monero Means Money
<Inge-> does it have any other language translations?
<ArticMine> hi
<netrik182> I don't think so
<binaryFate> how different are portuguese vs. brazilian? Is there strong value in having a brazilian specific version? I didn't see mention of that in the proposal
<netrik182> Almost no difference really
<sgp_> Inge-: there's a Chinese translation zh.masteringmonero.com and a partially reviewed Russian translation
<binaryFate> so it's going to be easy and comfortable to read for portuguese people as well?
<Inge-> Spanish would be great too
<netrik182> But as Brazilian I would do so called Brazilian Portuguese instead of European, so to speak
<rehrar> "so to speak" hehe, I get it
<netrik182> Not a problem at all binaryFate
* Inge- is positive to Brazilian translation
<netrik182> Most of the online content in portuguese is written by brazilians
<netrik182> but everyone can read it
<binaryFate> oki thanks
<netrik182> think of Britain vs USA English
<netrik182> it's the same
<sgp_> Any other questions or feedback?
<sgp_> ok, second one
<sgp_> Compilation time reduction and housekeeping (52 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/138
<sgp_> you need to click on "changes" to see the text
<xmrscott[m]> I believe this would help with the issues Endogenic highlighted at Konferenco
<xmrscott[m]> Thus, I'd like to see it
<rehrar> Thusly
<endogenic> ossssssu
<binaryFate> Proposal looks interesting but I didn't follow the -dev discussions about it, anybody knows?
<rehrar> A note on the CCS proposals, the Norwegian one was merged and it's not showing. I tried to fix and it's still not showing. Working that out.
<sgp_> binaryFate: I don't see a dev discussion in the past week
<binaryFate> mmm I thought I had skeemed through some mentions of this
<asymptotically> i think i last talked in -dev with the compile time speedup guy, so if you grep your logs for me it should come up :D
<sgp_> any comments on this otherwise?
* needbrrrrrrr90 sneaks in the back entrance and takes a seat
<sgp_> messy logs of the discussion https://www.irccloud.com/pastebin/73V4aGO4/logs
<sgp_> we can move on. please comment in gitlab. looking at you devs :)
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> luigi merged a bunch of things, including dandelion++
<sgp_> does anyone else have an update here? else we can move to b
<sgp_> is ErCiccione[m] here?
<cankerwort> when next release?
<sgp_> rehrar: do you know when the next dev meeting is?
<sgp_> tomorrow?
<cankerwort> dandelion++ for the masses
<netrik182> ErCiccione was not feeling well during the week so probably not here
<rehrar> sgp_: whenever we want it to be. People had voiced that dev meetings should be kind of before releases and stuff, but if we wanted to set one up then we can.
<sgp_> rehrar: ok, keep me updated so I can update the calendar
<sgp_> cankerwort: unfortunately I don't really have a good update
<sgp_> if ErCiccione isn't here, we can move on to c
<sgp_> c. GUI workgroup
<sgp_> selsta any update?
<selsta> we are preparing for the next update
<selsta> no big updates otherwise
<sgp_> thanks
<sgp_> is sarang here?
<sgp_> We can move on to 5. Open ideas time
<selsta> 19:12 <sgp_> Compilation time reduction and housekeeping (52 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/138 <-- I think mooo and others should agree first if they want this
**<sgp_>** selsta: yeah
**<xmrscott[m]>** Pi/Rock node is currently looking for WEb UI folk: https://www.reddit.com/r/pinode/comments/fuwryy/pinodexmr\_updated_full_node_for_single_board/
**<monerobux>** [REDDIT] PiNode-XMR updated. Full node ( for single board computers ) not just Raspberry Pi --- Armbian Buster & Hardware testers needed. New Web UI proposal with help needed from the community. (self.pinode) | 6 points (100.0%) | 3 comments | Posted by shermand100 | Created at 2020-04-04 - 16:40:22
**<sgp_>** Does anyone have topics to discuss? It's been a long time since the last open ideas time
**<xmrscott[m]>** (This is the monero-ecosystem/pinode-XMR project)
**<sgp_>** xmrscott[m]: cool :)
**<xmrscott[m]>** Namely, they want to build a Web dashboard from scratch to shed a bunch of extra weight they inherited from basically pulling a cookie cutter
**<sgp_>** Moneroversary debrief: so far this year’s main livestream has 1,025 and 255.5 hours of watch time. Last year’s Moneroversary main livestream has 1,337 views and 440 hours of watch time. Like last year, not many people are watching the events afterwards.
**<sgp_>** *1,025 views
**<sgp_>** Since the community feedback on a Chatwoot service by the Core Team seemed mostly negative, I plan on making my own which I hope to integrate in as many Monero accounts/pages/etc as possible
**<sgp_>** This is a chat support service that I think could benefit newcomers and those with questions
**<sgp_>** It will allow us to learn more clearly what the pain points are so we can fix them
**<binaryFate>** summary of negative feedback?
**<deedledea>** pain points of newcomers?
**<sgp_>** And I will make a series of trainings that people can use to get up to speed to be able to answer questions
**<sgp_>** deedledea: yes
**<sgp_>** binaryFate: people didn't want it embedded on the getmonero site, people were concerned about legal stuff, and people were pessimistic that the tool should be used over other support services like StackExchange and reading the docs
**<binaryFate>** ok so more about the location itself
**<sgp_>** I'm heavily considering making this my own thing, so any feedback on how to do this best is welcome :)
**<sgp_>** what other projects are people thinking of? we need people to take on fun projects and get stuff done
**<netrik182>** there were some discussions about revamping getmonero.org home-page to be more beginner-friendly
**<sgp_>** netrik182: oh yes, let me find that github issue/PR
**<sgp_>** https://github.com/monero-project/monero-site/pull/948
**<sgp_>** I recommended another card that has icons for the following: 1) private for all, 2) coin equality, 3) secure
**<sgp_>** I like "coin equality" over "fungibility" in this context
**<binaryFate>** I hate the old video on the front page, particularly because it says "more than 30 developers"
**<binaryFate>** This was made in 2015 or 16 I think. Now there is more than 300.
**<sgp_>** haha same. iirc there are resources available to edit that sorta easily?
**<cankerwort>** what sites would you be putting this chatwoot on sgp?
**<sgp_>** people still quote the >30 number so it's an issue for press
<binaryFate> we had people reaching out fairly recently for a documentary on crypto asking if they could use that video
<binaryFate> painfull to say "yes but it's outdated! Now it's..." knowing they'll just use the video period.
<sgp_> cankerwort: its own dedicated site, ideally the @monero twitter for DMs if people think that's a good idea, and r/monerosupport (again if people think it's a good idea)
<sgp_> binaryFate: good point
<sgp_> also all the Kovri references
<binaryFate> Is there someone in the community that could assess cost/effort of changing that numbers and also maybe redo video. It's not a very intricate one.
<ArticMine> So the video needs to be updated
<rehrar> binaryFate: we're a tiny coin
<ArticMine> that gas grown 1000 since the video was created
<ArticMine> has
<rehrar> what was the guy's name that made it? silvestra?
<binaryFate> rehrar I wish... was so cozy!
<sgp_> here are the scripts/translations. I'm looking for the other repo https://github.com/monero-ecosystem/promo-video
<sgp_> savandra! https://github.com/savandra/Monero_Promo_Video
<rehrar> that's it!
<rehrar> maybe we can track him down and see if he'd be willing to do an edit
<sgp_> https://github.com/savandra/Monero_Promo_Video/blob/master/Illustrator_Vectors/monero%20developers.ai
<selsta> we have to find out who did the voice over
<sgp_> just have Doug do it :p
<binaryFate> I'd venture that we can redo the voice over with a different voice :)
<asymptotically> i nominate rehrar or jwinterm! just because i love listening to them <3
<rehrar> rehrar: "What up scrubs? This video is about Moh-neh-roh!"
<binaryFate> Probably just 50$ on upwork if you want same kind of deep professional voice
<rehrar> I do have a super fancy mic, as most of you have seen.
<selsta> I think having it sound professional would be important, especially because voice overs aren’t to costly
<rehrar> :(
<selsta> too*
<selsta> you can do a version rehrar :D
<sgp_> voiceover tryouts
<rehrar> I'll put my version on http://getmonono.org
<binaryFate> yes please
<ajs-mob> I could help with editing the video
<binaryFate> perfect and thank you
<sgp_> does anyone have Adobe AfterEffects?
<rehrar> I do, but I don't know how to use it.
<cankerwort> "Monono has over -1 developers"
<xmrscott[m]> Always KdenLive as well
<rehrar> this is technially true
<sgp_> no numbers
<rehrar> Monero has over x developers
<sgp_> "Monero has a large, active development community"
<rehrar> "Monero has developers"
<selsta> not sure if having had 300+ code contributions means monero has 300 developers
<selsta> 300+ code contributions from different accounts
<selsta> maybe "over 250+ people contributed with an active development community"
<binaryFate> it's the third largest crypto in number of developers after BTC or ETH, this should be conveyed clearly one way or another
<selsta> or so
<binaryFate> I think you're being too careful/shy on this particular instance selsta. It's a video where we can't use unclear longer phrasing or waste words
<selsta> maybe :D
<binaryFate> All the rest of the Monero content is always so careful and honest... at least with this we can make a clear statement
<sgp_> "one of the largest open-source developer communities"
<sgp_> I'm trying to choose wording that also lasts
<binaryFate> better, but honestly any coin would say so
<selsta> yea I’m better not involved with this video lol
<binaryFate> We don't need to make a video valid for 4 years
<sgp_> this one has been used for 3
<binaryFate> "with X developers, it's the third largest development communicty after Bitcoin and Ethereum"
<sgp_> just remove "with X developers"
<deedledea> @sgp if you want any tests for a non-technical-audience on the content just let me know...I can wrangle up a few I am sure!
<sgp_> deedledea: that's SUPER helpful; I'll keep that in mind
<selsta> should the target audience be crypto users?
<selsta> because I’ve always found the block reward part confusing in this video
<selsta> people who are not familiar with crypto don’t know what a block reward is
<binaryFate> IMO audience is layman journalist or complete newb
<rehrar> Let's have a first step being writing up a new script.
<rehrar> We can talk about voice work and discuss how much of the visuals need to be changed after we have a good script.
<rehrar> The cryptocurrency space is different today than it was three years ago.
<rehrar> The average 'noob' is also different.
<sgp_> I'd like to make a main goal to keep as many visuals the same unless we know we have the skills to adapt
<sgp_> something along these lines in the ideal case: https://twitter.com/Bitcoin/status/1253656381711888391
<monerobux> [ Bitcoin on Twitter: "Bitcoin explained in two minutes… " ] - twitter.com
<sgp_> though even shorter
<sgp_> anyway, we have one project to work on. please think of others today that YOU can work on this week
<sgp_> for the sake of time, I'll wrap this meeting
<deedledea> visuals are always good! ideally there would be videos for different audiences, but if we are talking about gaining a few different audiences at once (i.e. that it's technical enough to peek the interest of developers and digestible enough for the non-technical to want to explore more) then content creation and communication is tricky. I like the challenge, I'll think more on it on my end!
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 9 May at 17:00 UTC.
<sgp_> The next Coffee Chat is on Saturday 2 May at 17:00 UTC
<sgp_> Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, STAY SAFE AND ISOLATED, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2020-04-22

Wed, 22 Apr 2020 00:00:00 GMT

Logs

<sarang> First, GREETINGS
<sarang> hi
<sgp_> Hello
<moneromooo> .time localtime
<monerobux> Could not find timezone localtime.
<sgp_> .time cdt
<monerobux> Could not find timezone cdt.
<Isthmus> First agenda item is trolling the monerobux bot
<sarang> naturally
<sarang> Well, let's move to ROUNDTABLE
<atoc> ooh
<ArticMine> Hi
<sarang> I assume Isthmus would like to share the material he posted on the agenda issue?
<sarang> https://github.com/monero-project/meta/issues/456
<sarang> Specifically: https://github.com/monero-project/meta/issues/456#issuecomment-617883059
<Isthmus> Sure
<sarang> Go ahead!
<UkoeHB_> hi
<Isthmus> Just completed a study quantifying the impact of exchange rate volatility for Monero-denominated delayed payouts.
<Isthmus> Normally I consider exchange rate stuff out of scope for MRL but this is relevant to all CCS-funded contributors
<Isthmus> Hm, I was going to cut and paste from the GitHub issue but everything is slightly too long for IRC
<Isthmus> Basically, I put together a sliding window statistical analysis of the XMR price timeseries to create a framework for volatility risk management
<Isthmus> The TL;DR is this:
<Isthmus> [INPUTS:] X% confidence that a Y-month payout will cover the quote (based on the last Z months of data) can be achieved with an [OUTPUT:] V% volatility buffer.
<Isthmus> Suppose we want to look at the last 24 months of data
<Isthmus> And consider a 4-month sliding window (1 month to fundraise on CCS + 3 months to execute)
<Isthmus> Here are the outcomes based on historical data
<Isthmus> https://usercontent.irccloud-cdn.com/file/tbl4tkZn/image.png
<Isthmus> We observe an unfortunate asymmetry over the past two years, for example: contributors to projects with a 4-month timeline were more than twice as likely to experience a 50% decrease in compensation value (red line) than a 50% increase in compensation value (green line).
<sarang> That's quite the asymmetry
<Isthmus> That's the probability distribution function, the cumulative version is helpful too:
<Isthmus> https://usercontent.irccloud-cdn.com/file/2UBTfPI7/image.png
<Isthmus> The red cross highlights that USD/XMR decreased over 65% of sliding 4-month windows (i.e. only 35% of contributors would receive payouts worth the quote price). The orange cross shows that an 80% likelihood of receiving a sufficient payout would be achieved with a +35% buffer.
<Isthmus> Explaining the orange cross in the framework described above: 80% confidence that a 4-month payout will cover the quote (based on the last 24 months of data) can be achieved with a 35% volatility buffer.
<Isthmus> Now, let's consider what happens if we double the timeframe (so that the data include a bull market as well as cryptowinter). The previous plots spanned the last 2 years (blue dots); now let's extend this to 4 years (blue & green dots).
<Isthmus> https://usercontent.irccloud-cdn.com/file/aCapoFx3/image.png
<Isthmus> oops transparent background, ssorry
<Isthmus> Now that our we include both the bull run leading up to the all time high and the subsequent decay, the extended data set contains new outcomes on both sides of the red breakeven line (+ a few outliers omitted on this plot that are shown in the next).
<Isthmus> https://usercontent.irccloud-cdn.com/file/kiCGTbDh/image.png
<Isthmus> Over the 4 year history, we see that about 60% of the windows receive a payout covering the quoted value (red cross). Since the data set now includes an 8x bubble in its entirety, the volatility insurance rate for 80% confidence rises to a 170% buffer (orange cross).
<Isthmus> https://usercontent.irccloud-cdn.com/file/le8lMFik/image.png
<Isthmus> I'm hoping that having a volatility risk management framework like this will increase funding accessibility for people/businesses that want to contribute but cannot afford speculate on income.
<sarang> This is great data
<sarang> Any questions for Isthmus?
<sgp_> Volatility is expensive
<sgp_> No questions, but thanks for doing this
<Isthmus> ty :)
<sarang> I can share next, if there are no other questions for Isthmus
<ArticMine> More of a comment.
<ArticMine> Thanks for the work
<atoc> Yeah thanks, just for more clarity: what are Monero-denominated delayed payouts?
<ArticMine> What we are dealing with is more like a two bear market as opposed to volatility
<UkoeHB_> It seems like long delays in payouts are not worthwhile. Either donators or donation recipients will lose on fiat-equivalent purchasing power with a good probability
<ArticMine> With the bear trend longer than the term of the typical CCS
<atoc> ah I see what this is now
<atoc> I actually wondered about this previously too. This is definitely good info
<moneromooo> Donators can't lose. They get exactly what they intend in terms of exchange rate. Recipients can lose or win. Other market participants (which could also be the donators or recipients if they choose to play the markets in the meantime) will win or lose.
<UkoeHB_> Donators can lose if recipients justifiably ask for premiums in the name of volatility, so donators are paying for the volatility
<sarang> At any rate, it provides useful information for proposers and potential donors to assess the impacts of volatility
<sarang> Isthmus: did you want to also discuss TheCharlatan's possible work on timelocks?
<sarang> (you just posted to the agenda on it)
<ArticMine> I think volatility is the wrong term here
<Isthmus> @ArticMine yeah, there may be a more precise way to phrase it. Let me know if you have ideas
<Isthmus> @sarang sure
<Isthmus> We discovered a few months ago that Monero's plaintext unlock time leaks information and presents a transaction linkability risk
<Isthmus> An encrypted unlock time is possible and would solve privacy issues, however the design and performance characteristics must be carefully considered.
<sarang> Right
<ArticMine> The issue is a systematic downward trend during the term of the particular CCS
<sarang> We investigated this with the DLSAG preprint
<Isthmus> Insight has put together a proposal for Isthmus & TheCharlatan to research solutions over the summer. Looking for feedback on the plan here: https://github.com/insight-decentralized-consensus-lab/monero\_encrypted\_unlock\_time
<Isthmus> Our goals are:
<sarang> The method from the DLSAG preprint works even without the dual-key output structure, and I have some code demonstrating both the general method and how various LRS constructions could be used for this
<Isthmus> Detailed system design decisions (e.g. unlock_time per output or per transaction?)
<Isthmus> Prototype code to quickly test different approaches , including simulating transaction construction, signing and verification
<Isthmus> Report of quantified space/time/privacy tradeoffs with each mitigation strategy
<Isthmus> Implementation code for Monero source tree, for at least one of the chosen approaches
<Isthmus> Comprehensive research analysis writeup , cross-referenced with code and documentation
<Isthmus> Oh sorry Sarang, go ahead
<sarang> Oh no, just providing some background; please continue
<Isthmus> Oh, that was the end of the list :- )
<sarang> Ha got it!
<sarang> Yeah, so there was already some work on this
<sarang> and I've been discussing it with TheCharlatan
<sarang> Basically you can follow an approach similar to that in DLSAG using any d-LRS construction
<sarang> Meaning MLSAG, CLSAG, Triptych can be used
<sarang> Obviously the scaling will be different in size/time
<sarang> But essentially you increase from a 2-LRS (signing key, amount key) to a 3-LRS (signing key, amount key, timelock key)
<sarang> You also need to change how range proofs are structured, in a nontrivial way
<sgp_> Does unlock time per transaction mean all outputs have the same unlock time?
<sarang> In theory, yes
<sarang> But it would depend on how it's designed
<Isthmus> Yep @sgp_ that's how it works currently
<sarang> Anyway, there's a marginal increase in transaction size to include the necessary auxiliary commitment data
<sarang> But more notably, there's a time cost that scales linearly with the ring size
<sgp_> Maybe market research some come first to see if there's a demand for per-output. Has this been done at all?
<sgp_> *should come
<sarang> This time cost exists regardless of whether the locks are per-output or per-transaction
<sarang> I have C++ timing data for CLSAG to show this, and could modify the new Triptych code similarly
<sarang> (no point doing it for MLSAG)
<sarang> Before there's too much time/effort invested in this, I think it'd be useful to determine what costs people think are acceptable to introduce this
<sarang> The signature stuff is pretty straightforward (from 2-LRS to 3-LRS), but there's additional engineering work for a much different handling of range proofs, which would also need to change the fee structure due to Bulletproofs DoS scaling
<sgp_> Does this impact transactions that use the locks only or all of them?
<sarang> and, of course, the timing hit needs to be considered
<sarang> Well, for maximum uniformity all outputs would need locks
<sarang> The lock could be set to 0
<sarang> but the time cost is the same
<sarang> Since for every ring member, you need to process its lock data
<sarang> and the verifier can't tell which locks are 0 due to the commitment structure
<UkoeHB_> I feel like knaccc since I can't imagine what utility timelocks have
<Isthmus> Crossing borders
<moneromooo> Would encrypting lock times prevent it from being used as a second layer building block ?
<sarang> Constructions involving cross-chain and off-chain channels would need them
<sgp_> Isthmus: how many transactions use these locks again? I lean towards not pursuing this unless there's a known demand
<sarang> moneromooo: encrypting timelocks were originally designed for 2nd layer stuff in DLSAG
<gingeropolous> i thought the second chain requires the kind of time locks that we don';t have yet
<sarang> They aren't required for DLSAG, but they are useful to avoid spend heuristics
<gingeropolous> second layer, sorry
<sarang> e.g. ring members whose locks have just expired may be more likely to be true signers, etc.
<gingeropolous> but i guess both types would need encryption
<sarang> Anyway, if the decision is to support timelocks, requiring the commitment structure is good for mitigating heuristics, but it comes at a definite cost
<sarang> and this cost scales with the ring size
<moneromooo> I'd be ok with a fair cost if it is instrumental having a good second layer, but not really otherwise.
<gingeropolous> it seems pretty integral if we want monero to be programmatic money
<sarang> To be clear, a solution like DLSAG requires timelocks, but does not require encrypted timelocks
<sarang> It is highly beneficial for uniformity if the timelocks are encrypted, however
<UkoeHB_> Isthmus it might help the proposal if there were some basic estimates of costs related to timelocks (storage requirements, additional EC ops), for both CLSAG and then for Triptych.
<sarang> UkoeHB_: I already have this data for CLSAG, and presented it quite a while ago
<sarang> For Triptych there are estimates (the C++ code didn't exist at the time)
<UkoeHB_> ah, in which case a link would be nice
<sarang> I can dig it up after the meeting
<TheCharlatan> That's only the costs for the signature and commitments though, right sarang?
<sarang> FWIW the branch is here for 3-CLSAG: https://github.com/SarangNoether/monero/tree/3-clsag
<sarang> TheCharlatan: the range proof wouldn't necessarily incur any extra costs
<sarang> Depending on if/how the limits are changed
<sarang> If desired, I can update the new Triptych C++ code to support timelocks, for data on performance differences
<sarang> it'd be pretty straightforward to do
<sarang> Anyway, I support the idea if it's based on a solid understanding of the costs, and has general consensus
<sgp_> I only really support the research if we know there's a solution on the table that Monero will use for second layer stuff. The "how to encrypt" question will be answered faster than the audit process. Maybe I'm not understanding the application, but I perceive this bug hurdle as needing to come first
<sarang> sgp_: we know exactly _how_ to do it
<sarang> (in terms of signature handling)
<sgp_> I meant selecting which is best
<sarang> What's not known are specifics related to range proofs, fee structure, etc.
<UkoeHB_> fee would be pretty simple to update afaik
<sarang> Perhaps. What changes is that the aggregated range proof now needs to account for newly-generated outputs, as well as a proof for each timelock input
<sarang> But it's still something that would need to be considered and completed in the design/deployment process
<UkoeHB_> right
<sarang> and it also complicates things since there are currently no specific input limits
<sarang> whereas Bulletproofs have a ceiling-power-of-2 verification cost, which is why we limit the output count
<sarang> Having a separate bulletproof makes little sense from a size perspective
<UkoeHB_> ah hm
<UkoeHB_> per-input timelocks may be expensive, but I defer to the estimates /o\
<Isthmus> Could we have 1 time per transaction, and an encrypted bit with each output
<Isthmus> 1 = use encrypted timelock
<Isthmus> 0 = default (10 blocks)
<sarang> Isthmus: you still need the signature and range components
<sarang> How you assign timelock commitments to outputs isn't really relevant there
<Isthmus> Mmkay, was just trying to think of a way to bee able to lock 1+ outputs without locking your change (without having an encrypted timelock for each output)
<sarang> That's a pretty minimal size cost
<sarang> The real kicker is verification
<sarang> and the specifics on range proof structure
<Isthmus> Yep, those are key things to nail down first
<sarang> Well, we have CLSAG code to give real numbers on that cost
<sarang> and it's easy to modify Triptych to give its costs
<sarang> What is not known is what time hit is considered reasonable
<sarang> "as low as possible" isn't a design decision
<sgp_> Can I step in since I really need to make sure I understand the big picture here
<sarang> sure
<sarang> of course
<sgp_> In order to add a feature, there should be at least some stated use for it, especially if there are costs
<UkoeHB_> nvm per-output timelocks would be cheap at 8 bytes per additional output, most cost is on input proving side
<sgp_> So the main benefit is the ability to add things like DLSAG and other related protocols that could allow second-layer right? That time locks are necessary for second-layer solutions we know about?
<sarang> Well, and we allow timelocks right now; but they have multiple accepted specifications, and likely introduce spend heuristics
<Isthmus> s/likely/do/
<sarang> So their presence and optionality introduce fingerprinting
<sgp_> right but they aren't used as far as we know for anything in particular?
<sarang> ^^ good point
<Isthmus> Not only are timelocks used
<Isthmus> 5 different formats are used
<Isthmus> See the documentation linked above
<sarang> that's what I meant
<Isthmus> So SOMEBODY is using them
<Isthmus> They're anonymous, unfortunately, so I don't know their use case
<sarang> Requiring a uniform format is an obvious first step
<UkoeHB_> what fraction of all tx have non-zero timelocks?
<TheCharlatan> sgp_ they are also useful for atomic swap purposes, if you are looking for specific features.
<jwinterm> was about to ask same UkoeHB_
<sgp_> https://usercontent.irccloud-cdn.com/file/xIfs2dFC/table
<jwinterm> TheCharlatan, but not in the state that they currently exist, right? I thought atomic swaps require the kind of time locks that bitcoin has - i.e., this tx can't be mined until certain time
<gingeropolous> yeah right now its payment channels (lightning network) and atomic swaps, for the most relevant application of timelocks (i think)
<Isthmus> They're not super widely used, on the order of 10k nonzero locktimes
<Isthmus> Of course, neither are subaddresses ;- )
<jwinterm> total number of txs is 10M order of magnitude?
<Isthmus> 6M
<Isthmus> Almos 7M
<Isthmus> *almost
<jwinterm> .c 1e4/7e6
<monerobux> jwinterm: 0.001428571429
<sgp_> dumb idea: why not threaten to remove this feature entirely unless someone justifies the need?
<jwinterm> 0.1% more than I would've guessed
<TheCharlatan> since we are spitballing a bit, Istmus and I also discussed introducing a more compact format. So if encrypting them is deemed undesirable, I believe we should still change their current behaviour to something more sane and less dangerous.
<sgp_> if these are caused by someone fucking around for no purpose, then why bother having them
<UkoeHB_> compact format?
<sarang> Do you mean supporting only a single uniform format?
<sarang> Because this seems like a natural first step
<UkoeHB_> iirc they are varints atm, so at most 9 bytes
<sarang> At least removing the fingerprinting possible within the use of timelocks
<sgp_> in order for the *cool* time-lock applications to come around, we need to agree to implement something else which would come with a large advance notice. This hasn't happened obviously
<sarang> Well, and there is no DLSAG-type payment channel use currently available
<Isthmus> @UkoeHB_ I thought it was uint64. I got a few outputs locked until 18446744073709551614 (about 500 billion years) over the weekend :- P
<sarang> Isthmus: something something store of value
<ArticMine> Using a single format for timelocks seems a sensible first step to me
<UkoeHB_> varints have up to 63 bits of information from what I understand
<Isthmus> oh yea
<sarang> OK, so in the interest of time, what's a good next step in this design process?
<UkoeHB_> cost estimates
<sarang> Isthmus TheCharlatan: let's discuss that after the meeting
<TheCharlatan> Exactly, but a varint for a timelock is completely overblown. There have been a lot of discussions on this in Bitcoin as well, for example to restrict the size to a 1 byte value that is then interpreted as a power of time.
<ArticMine> single format
<sgp_> I say the cost estimate of only the cheapest option to begin with to see if that action is warranted
<TheCharlatan> Personally I would get rid of time based lock times entirely.
<Isthmus> That introduces a correction term when blocktime changes
<Isthmus> But that's easy enough to do
<sgp_> TheCharlatan: haha exactly, or at least aggressively ask for justification from people who use them
<sarang> OK, so beyond investigating optimal single-format cleartext use and updated cost estimates, anything else on this topic for right now?
<sarang> (otherwise we could discuss it for hours...)
<sarang> going once
<sarang> going twice
<sarang> sold
<sgp_> nope, I just want to stress that we need to know why they are used before slowing down transactions
<sarang> I can briefly share a couple things in the time we have left
<sarang> I overhauled Triptych verification to support common-key batching
<TheCharlatan> and s/time/two - deleted the wrong word :(
<sarang> New timing data: https://usercontent.irccloud-cdn.com/file/TWAkCeJJ/timing.png
<sarang> This data represents the input-amortized verification cost for a 2-input set of signatures
<sarang> Assuming the same ring is used across both inputs for Triptych
<sarang> (for MLSAG/CLSAG it doesn't matter)
<sarang> I also overhauled the MLSAG tests for better consistency with the other series
<UkoeHB_> wait isnt that way faster?
<sarang> It should be
<selsta> What are amortized inputs?
<sarang> If you have a 2-input transaction, you need to compute 2 signatures
<sarang> For MLSAG/CLSAG, this takes twice the time as one signature
<sarang> For Triptych, if you use the same ring, you get huge batching benefits
<sarang> So this is the per-input cost for a 2-input transaction
<sarang> For higher-input-count txs that would share rings, the benefits get even better
<UkoeHB_>
<sarang> The gray crossed lines are centered at the current N=11 MLSAG point
<sarang> This implies that Triptych becomes slower than right now (for 2-input txs) between N=64 and N=128
<sarang> (but you can't split the difference... you need to pick a power of 2)
<sarang> Anyway, hopefully this gives more realistic timing data, at least across 2-input txs
<sgp_> is 128 about the same time as DLSAG 12? 13?
<sarang> You can use my triptych branch and clsag-device branch to construct this data for yourself
<sarang> I don't have C++ data for DLSAG
<sgp_> soory I meant MLSAG
<sarang> I'd have to run some quick MLSAG tests on those intermediate numbers
<sarang> I can have that shortly after the meeting (need to do a new build)
<sgp_> it's fine, not that important
<sarang> It's easy, just takes a few minutes
<sarang> Anyway, that's what I wanted to share
<sgp_> cool stuff
<sarang> Does anyone else have research to share (we're running a little long, but that's ok)
<UkoeHB_> very cool
<UkoeHB_> hi yes, this proposal went up this week https://github.com/monero-project/monero/issues/6456
<UkoeHB_> it's a synthesis of discussion and research from IRC over the past months
<sarang> It's very comprehensive :)
<sarang> I admit that I haven't had a chance to sit down and devote time to it :/
<sarang> However, do you have any concrete suggestions at this point UkoeHB_?
<UkoeHB_> there needs some debate about whether to pursue Janus, and which solution to adopt, but otherwise tx structure recommendations, sorted tlv, and view tag all seem concrete to me
<sarang> Neat
<sarang> I'll devote time to it before the next meeting for sure
<UkoeHB_> also moving to mandating 1 tx pub key for 2-out tx, and 1 key per output for >2 out tx
<sarang> Many thanks for continuing work on that
<sarang> OK, let's briefly review ACTION ITEMS before we adjourn
< is that assuming that every 2-output txn has a change output?
<Isthmus> *change or dummy
<UkoeHB_> we only have to make that assumption if Janus is implemented
<Isthmus> Ok, so then if there's a txn being split between 2 (non-change) recipients, it must be constructed as a 3-output txn with a dummy output, right?
<UkoeHB_> right
<Isthmus> Eh that seems harmless. Is a corner case anyways.
<Isthmus> Sorry @sarang go ahead
<sarang> Someone volunteered to do a review of the CLSAG code, which was very helpful... they also recommended adding Poly1305 authentication to wallet encryption, which is a good idea to prevent chosen-ciphertext adversaries
<sarang> Aside from that, I'll pull up some 3-CLSAG and 3-Triptych data to help the timelock discussion, as well as some stuff on Arcturus
<sarang> that's all for me :)
<sarang> Anyone else?
<Isthmus> I'll expand the timelock proposal with some more references/data/use cases
<Isthmus> And I'll probably finish another quantum-resistance proposal today or tomorrow, currently incorporating feedback into the first draft
<sarang> great
<sarang> Any other final action items before we adjourn?
<Isthmus> Oh yea, and I'll read UkoeHB_ 's epic github issue :- )
<sarang> Righto, we are now adjourned! Thanks to everyone for a great meeting

Another privacy-enhancing technology added to Monero: Dandelion++

Sat, 18 Apr 2020 00:00:00 GMT

The Pull Request which adds Dandelion++ has been merged. This new feature changes the way transactions are propagated to the network, making it much harder to link a transaction to an IP address.

The feature is now part of the code and will be included in the next release of the Monero software, but it's already possible to test it by compiling the CLI software from source (see instructions on the repository). Be aware that to get improved privacy, a node running Dandelion++ needs to communicate with other Dandelion++ capable nodes.

For more detailed information about Dandelion++, how it works and how improves Monero user's privacy, read the article written by the Monero Outreach workgroup: "Dandelion++ for Monero".

Logs for the MRL Meeting Held on 2020-04-15

Wed, 15 Apr 2020 00:00:00 GMT

Logs

<sarang> First, GREETINGS
<sarang> Hello
<ArticMine> Hi
<Isthmus> Heya
<UkoeHB_> hi
<binaryFate> hi!
<sarang> I'll wait a couple of minutes for anyone else to arrive
<sgp_> hello
<sarang> All right, on to ROUNDTABLE
<sarang> Who would like to share any research of interest?
<cankerwort> Howdy
<UkoeHB_> https://github.com/monero-project/research-lab/issues/73
<UkoeHB_> Research is a big word, but there's an idea
<sarang> It'd be possible for a recipient to miss spendable funds if this value weren't included properly
<binaryFate> is there any potential issue if the sender does not play "nicely" (purposefully fail the scheme) but can nonetheless prove having sent some outputs to the recipient?
<UkoeHB_> same is true for tx pub keys
<Isthmus> If the sender doesn't follow the rules, recipient won't see a message showing receipt of funds.
<Isthmus> So they'd just ask the sender to make a valid transaction
<sarang> Yep
<Isthmus> Really, the sender hurt themselves
<sarang> It's similar to if a sender sent a bad commitment,e tc.
<sarang> (except for the spendability property)
<UkoeHB_> if there is a wallet that doesnt make view tags correctly, it will be a worthless wallet
<Isthmus> Bingo
<UkoeHB_> and quickly get patched
<cankerwort> Surely this would be a kind of "fast scan" and if the sender messed it up somehow it would still show up in a normal scan?
<sarang> yes
<binaryFate> They can "DoS" an exchange support easily
<binaryFate> Probably hurt them more than the exchange
<UkoeHB_> yeah cankerwort it would be trivial to have fast/normal scan differentiation; the technique is very simple
<sarang> And wallets don't have to use the method to scan at all if they don't want to
<selsta> how would fast scan work together with supercop EC ASM? would ASM still bring a scanning speedup?
<binaryFate> would there be interesting tradeoff too with a bit more or a bit less than a byte? (changing the 1/256 chance)
<Isthmus> The speedup is huge if you're looking for 1-2 addresses, but marginal if you're scanning for 20,000 transactions, right?
<UkoeHB_> my thought is 1 byte is a very standard size, and going lower gets kinda hacky; more than that I can't imagine meaningful improvement
<Isthmus> *1-2 transactions
<UkoeHB_> which speedup?
<UkoeHB_> if somehow you own 80% of all tx, then yeah the view tag only helps you for (255/256)*.2 of the rest
<cankerwort> So a scan under this system would scan (1/256 of all transactions) + (actually relevant transactions) - overlap
<UkoeHB_> right
<UkoeHB_> and 'scan' just means perform a few more ec operations
<UkoeHB_> per output
<UkoeHB_> it's actually 1/256 of all outputs, not tx
<Isthmus> ah yea, ty
<TheCharlatan> why only one byte? Are two bytes too revealing?
<UkoeHB_> diminishing returns
<UkoeHB_> the marginal scan change from 1 byte to 2 byte view tags is tiny
<sarang> OK, noted
<sarang> Any additional questions on this idea at this point?
<UkoeHB_> any objections also?
<Isthmus> I like it
<TheCharlatan> yes :)
<Isthmus> Hopefully this will reduce the "Y MONERO SO SLO TO SYNC" posts on reddit by 1/256 too
<UkoeHB_> one can only dream
<cankerwort> I suppose generally speaking the fork when transactions get smaller anyway is a good time to introduce these QoL improvements
<binaryFate> this looks great
<sarang> Well, there doesn't seem to be a plan for whether or not to include Janus mitigations, which have been brought up repeatedly before
<cankerwort> or is any reduction in transaction sizes already earmarked for bigger ringsizes?
<sarang> There is currently no concrete plan to increase the ring size with CLSAG
<sarang> Note that the move from MLSAG to CLSAG will reduce the typical 2-2 transaction from 2.5 kB to 1.9 kB in size
<sarang> (absent any other changes)
<UkoeHB_> I think the discussion about Janus and tx extra has made some small progress
<sarang> Sure, but small progress != PR
<sarang> :D
<sarang> Anything else you'd like to discuss UkoeHB_?
<UkoeHB_> dont think so thanks sarang
<sarang> OK thanks UkoeHB_
<sarang> Does anyone else wish to share research of interest?
<sarang> If not, I have a couple of things to share
<Isthmus> Hmm, I’m still working on creating a graph formalism for fungibility defects. Made a little bit of progress since last week, but it’s still not quite coherent. Being rigorous is hard. Hopefully will have something to share in a week or two.
<Isthmus> I’m cooking up some stuff with Insight too. One of the Fellows put together a patch to prevent coinbase underclaiming now that we’ve moved away from discretized outputs. I just looked at the code, will clean it up and submit for consideration/review.
<Isthmus> I want to get more of Insight’s engineers working in our ecosystem! Insigght has been pouring a ton of R & D resources into Polkadot, ICON, Zcash, etc. I really want to leverage my team to contribute to the Monero community at this scale too.
<Isthmus> Having a few internal syncs to match Fellows onto open challenges, based on their skills/passions/interests. Hopefully in the next week or two, I’ll be introducing new contributors. :- )
<sarang> Nice
<Isthmus> More details coming soon as those conversation proceed
<sarang> What kinds of projects?
<Isthmus> Meeting with the candidates this week to nail that down based on their skillsets
<sarang> got it
<cankerwort> And now I need to go find out wtf is Polkadot and ICON all evening
<sarang> Thanks Isthmus
<sarang> This PR to speed up Bulletproofs is ready to go: https://github.com/monero-project/monero/pull/6451
<sarang> Applies retroactively, and has some pretty nice improvements
<sarang> Saves 25% on a 64-batch of 2-output proofs
<sarang> Feel free to review if you like
<ArticMine> Excellent
<cankerwort> Fantastic news
<sarang> Second, I've been working hard on a Triptych implementation in the codebase, for more accurate real-world testing
<sarang> This is the branch: https://github.com/SarangNoether/monero/tree/triptych
<sarang> (note that this code is not production-ready, and should not be used in anything important)
<sarang> Size data comparison: https://usercontent.irccloud-cdn.com/file/KvolrThG/size.png
<cankerwort> Triptych = Tryptych 2? As in did one version supersede the other?
<sarang> Verification timing comparison: https://usercontent.irccloud-cdn.com/file/4CATnXf6/timing.png
<sarang> This is for Triptych, which requires separate proofs per input (much like MLSAG and CLSAG require)
<sarang> The timing plot uses performance test data from this branch
<sarang> The gray lines are centered at the 11-MLSAG point for visual reference
<sarang> The timing data does _not_ include some unfinished optimizations, or batching, or common input sets within the same transactions
<sarang> However, it provides an idea of how MLSAG, CLSAG, and Triptych compare generally
<Isthmus> Noice
<TheCharlatan> what's the gray line intersection with the Triptych line x axis value?
<sarang> The vertical gray line is for ring size 11 across all constructions
<sarang> The horizontal line is the size/time value for MLSAG at ring size 11
<sarang> (again, just for visual reference)
<sarang> To help you compare to what we have in place right now
<ArticMine> What is the impact on tx size
<sarang> Each transaction input (not ring element, spent input) requires a single signature, of whatever construction you prefer
<sarang> Moving from 11-MLSAG to ~32-Triptych would result in no change to signature size
<sarang> and would result in slightly faster verification
<binaryFate> really impressive
<cankerwort> These are awesome improvements! But the plan is not to go straight for Triptych right?
<sarang> The size data are final; but again, the verification data is still WIP
<sarang> Triptych (and all other WIP next-gen constructions) require a modification to key images that requires new engineering work for multisig
<sarang> It's very nontrivial
<[keybase] seddd>: sorry 4 late. just finishing review of CLSAG, will send draft report to sarang when done. no big findings :)
<sarang> Thanks seddd, much appreciated
<cankerwort> seddd = surae?
<[keybase] seddd>: +1
<[keybase] seddd>: not by a long shot cankerwort
<sarang> Finally, ledger/trezor support for CLSAG is getting finished
<[keybase] seddd>: (surae wayyyy smarter)
<sarang> cslashm made a PR that'll be included in the test branch
<sarang> and ledger has a PR on their side for firmware support that's been completed
<cankerwort> Nice that hw wallets are so proactive compared to how exchanges were with subaddresses
<[keybase] seddd>: ah, that's my next step. still haven't reviewed the ledger-side stuffs. looked at cslashm's PR tho
<sarang> It's been very nice to see such quick work for ledger/trezor, that's for sure
<sarang> The goal is to have support ready to go at network upgrade time
<sgp_> really cool numbers
<sarang> Anyway, that's my report: BP speedup, Triptych WIP data, CLSAG device-specific support
<sarang> Any other questions for me about those topics?
<sgp_> Are these numbers *likely* similar to Arcturus?
<sgp_> for non-bath
<sgp_> *batch
<cankerwort> what is Arcturus?
<sarang> Ah, I renamed Triptych-2, both to reduce name confusion and because it operates differently
<sarang> I never liked the name Triptych-2; it was more of a placeholder
<cankerwort> Noted and appreciated
<sarang> I am not good at clever naming :/
<sarang> Anyway, to answer sgp_'s question
<sarang> Arcturus gives better size scaling
<sarang> Verification timing will be very similar to Triptych
<sgp_> size already looks pretty good
<ArticMine> Still if it can be made smaller then it is an improvement
<sarang> With Arcturus, you only need one proof/signature per _transaction_ instead of per _input_
<Isthmus> Ooooh
<sarang> The magic of generator reuse means the verification would be similar (if you use common anon sets for Triptych for comparison)
<sarang> (this difference is why I renamed it)
<sarang> However, keep in mind that Arcturus relies on a nonstandard hardness assumption
<ArticMine> What if any are the disadvantages?
<sarang> ^^
<cankerwort> Is the plan still to get CLSAG audited in time for the next fork? Which are now annually apparently?
<sarang> This is my understanding
<sarang> (but it's not my decision)
<binaryFate> sarang what's your feeling about whether the multisig issue can be solved without foreign primitives?
<sarang> As far as I know, we'd need support for general RSA groups for proper multisig with the next-gen constructions
<sarang> This is for signing only, not verification
<sarang> (even though it's RSA groups, there are no trusted setup problems, FWIW)
<binaryFate> And you're confident about this being a requirement, or it's just that nobody found how to do without yet?
<UkoeHB_> I did a writeup on the multisig question here https://github.com/monero-project/research-lab/issues/72
<sarang> If you can point out a homomorphic public-key scheme that can use arbitrary prime-order groups, I'm all ears
<sarang> Yes, it links to code and a description that I worked out
<UkoeHB_> right ^
<sarang> Paillier encryption is not specifically required
<sarang> but you need an additively homomorphic scheme
<sarang> Anyway, I've taken a lot of time in this meeting
<sarang> Was there anything else of interest to share here?
<TheCharlatan> I made a Rust PoC for including timelock blinding and commitments in transactions. The PoC builds transactions and verifies them with CLSAG signing and the locktime blinding mechanism as described in DLSAG. It looks like the additional size requirements are: input and output commitments, auxiliary (dummy) plaintext locktime, locktime image and a range proof. Thanks to CLSAG, there is no further
<TheCharlatan> increase in the signature size. Contrary to the locktime blinding desription in DLSAG, I think we can spare the range proof on the transaction's output locktime. The main size component therefore is the additional range proof. I also had a discussion about aggregating the locktime range proof in a transaction input with the amount range proof in the output with sarang yesterday (admittedly more
<TheCharlatan> of a lesson from sarang, than a discussion). The gist of it is that in transactions with many outputs and inputs, aggregated range proof verification would become prohibitively slow.
<[keybase] seddd>: oh, awesome! please disregard then, sometimes I derp
<sarang> TheCharlatan: there should be an additional 32 bytes to the signature
<sarang> because of the use of an additional auxiliary linking tag
<TheCharlatan> Ah, right I did not include tags in the description :P
<sarang> However, adding 32 bytes per input is still pretty darn good
<sarang> Note that verification will take a hit
<sarang> I have a CLSAG test branch that shows the difference
<sarang> (but I don't recall the numbers)
<sarang> TheCharlatan: is your code public?
<TheCharlatan> yes: https://github.com/TheCharlatan/rs-xmr-cryp/tree/master/timelock
<sarang> Also: note that Triptych can be easily extended to support this as well, since it's also a d-LRS construction like CLSAG is
<sarang> nice thanks
<[keybase] seddd>: TheCharlatan: that's awesome! was going to live-code CLSAG in Rust this Saturday. glad to have another reference impl :)
<sarang> There's also another CLSAG rust implementation available too
<sarang> https://github.com/crate-crypto
<[keybase] seddd>: so nice! thanks sarang :)
<sarang> (I didn't write that, FWIW)
<[keybase] seddd>: for sure, thanks for the link then :)
<TheCharlatan> The crate-crypto implementation is much nicer, mine is more of a quick script.
<sarang> TheCharlatan: what would be helpful from this group at this point?
<TheCharlatan> so I don't have a good feel on the boundaries of bulletproof scaling yet. So I think some more data there would be helpful.
<sarang> OK, I'm glad to help with that if you like
<sarang> (probably best to save those questions for after the meeting)
<TheCharlatan> yes :)
<sarang> Thanks TheCharlatan
<sarang> OK, we're just past the hour mark
<sarang> Let's move on to ACTION ITEMS
<sarang> What do folks plan to work on this week (that they wish to share)?
<sarang> I plan to finish the last Triptych code optimizations, to finalize that timing data
<sarang> as well as the CLSAG device-specific code integration
<sarang> Others?
<UkoeHB_> I think Ill write a brief proposal for Janus + view tag + extra field, a package update
<UkoeHB_> The concept seems to be coalescing
<[keybase] seddd>: just working on finishing up testing/manual review of CLSAG, writing the draft report, etc
<sarang> Yeah, and there are several related ideas there that could happen concurrently
<[keybase] seddd>: _cedes to UkoeHB__
<sarang> Any last questions or comments before we adjourn?
<UkoeHB_> ArticMine: how is the fee proposal coming along?
<binaryFate> just wants to say that was a lot of impressive developments, feels like christmas
<asdc_ccc> ^
<ArticMine> Still working on the fee part.
<sarang> All right; we are adjourned! Thanks to everyone for participating
<sarang> Lots will be posted shortly
<sarang> Discussions can of course continue :)

Migration of the monero-site repository from Gitlab to GitHub

Mon, 13 Apr 2020 00:00:00 GMT

The repository of the Getmonero.org website was migrated from Gitlab (https://repo.getmonero.org/monero-project/monero-site) to GitHub (https://github.com/monero-project/monero-site). All issues and pull requests should now be opened on GitHub.

In 2018 we decided to migrate the repositories containing this website and the CCS platform from GitHub to Gitlab, in response to Microsoft buying the former. After a long period of testing we now decided to move back the monero-site repository to GitHub. The CCS related repositories are staying on Gitlab (CCS Frontend, CCS Backend, CCS Proposals) and the monero-site repository on Gitlab will be used as a mirror. To understand the reasoning behind these changes, read the discussion on GitHub.

Nothing about the Community Crowdfunding System has changed. If you want to open a CCS proposal, please keep using Gitlab as before.

Logs for the Community Meeting Held on 2020-04-11

Sat, 11 Apr 2020 00:00:00 GMT

Logs

Logs for the MRL Meeting Held on 2020-04-08

Wed, 08 Apr 2020 00:00:00 GMT

Logs

<sarang> OK, time for the weekly research meeting
<sarang> Let's get started
<sarang> GREETINGS
<sarang> hi
<ArticMine> hi
<atoc> hi
<TheCharlatan> ahoy
<sarang> On to ROUNDTABLE, I suppose
<sarang> I've been working on papers for PoPETs submission, which has been a blast
<binaryFate> hello!
<sarang> As well as some review for a paper on hierarchical one-of-many proofs
<sarang> Finally, plenty of code relating to Triptych
<sarang> Not too much exciting stuff to report overall
<sarang> Any particular questions?
<atoc> hierarchical one-of-many-proofs sounds interesting. can you link the paper?
<sarang> It's not on the IACR yet (and I am not the author)
<sarang> Otherwise, anyone else who wishes to share research topics is welcome to do so
<binaryFate> what are hierarchical one-of-many-proofs?
<sarang> An extension of the Groth proofs used in Triptych and Lelantus that trade size for prover complexity
<sarang> They use a clever layering technique
<binaryFate> smaller size for increased prover complexity?
<sarang> Other way around :)
<binaryFate> ok :)
<sarang> The author thought there could be verification savings in certain cases, but I don't think that's the case if you do batching in the usual way
<sarang> Does anyone else have research topics they'd like to share or discuss here?
<ArticMine> I can give an update on the scaling and fees issue #70
<sarang> Sure!
<ArticMine> I have a solution for the scaling side and minimum relay fee. I am still finalizing the fee ratios
<ArticMine> Basically we can use the long term medium to deal with this
<sarang> Can you summarize?
<ArticMine> Sure
<ArticMine> 1) Put a cap on the rate of fall of the long term medium so that it falls at the same rate it rises
<ArticMine> 2) Make the penalty free zone dynamic as the greater of 300000 bytes and 25% of the log term medium
<sarang> Will that 300K value change with CLSAG?
<ArticMine> No the reference transaction size will to 2100
<sarang> yes
<sarang> But there are no plans to change the fixed-value penalty-free size?
<ArticMine> The minimum relay fee will very close to the old normal fee
<ArticMine> So for the current minimum penalty one the minimum fee will actually go up ~2.5x
<binaryFate> ArticMine what issue/risk is this solution tackling?
<ArticMine> A sudden drop in use followed by a recovery
<ArticMine> In many ways similar to COVID-19
<binaryFate> What would be the shortcomings of the current implementation in that situation?
<ArticMine> https://github.com/monero-project/research-lab/issues/70
<ArticMine> This create the scenario
<binaryFate> Ah, couldn't find issue. Thank you
<ArticMine> The basic problem is a sharp rise in fee that can take months or year to come back to normal
<ArticMine> Also a very sudden drop in the long term medium that also could take months or years to recover
<ArticMine> Issue #70 does not mention COVID-19 but COVID-19 is a very good scenario
<sarang> Will you have specific code or pseudocode soon to allow for simulations prior to any recommended deployment?
<ArticMine> Also there are scenarios where COVID-19 cold lead to a significant demand on the Monero network in terms of transactions
<ArticMine> Yes
<ArticMine> I have all the formulas now except for the fee ratios
<sarang> OK, thanks
<ArticMine> Still working on that
<sarang> I assume you'll post them to the issue you linked?
<ArticMine> Yes that is where I will post this
<sarang> Got it
<sarang> Anything else of note that folks wish to discuss?
<sarang> I know UkoeHB_ recently posted his new version of Zero to Monero
<sarang> not sure if he's around right now
<ArticMine> Yes that is excellent
<sarang> but that's on the getmonero library page, along with a link to the TeX source repo
<sarang> and there was also a suggestion from UkoeHB_ for updating how MLSAG secret data is wiped, which was a great catch (PR now available)
<sarang> Anyone else?
<sarang> Otherwise, we can move on to ACTION ITEMS for the week
<sarang> I will be continuing work on a C++ implementation of Triptych for timing efficiency tests
<sarang> as well as some new material for the multi-signer Triptych variant's security model, prior to the PoPETs submission deadline
<Isthmus> Oops, just got back. Nice work Artic!
<sarang> Isthmus: do you have any research or topics you'd like the group to discuss?
<Isthmus> Ah, I've been neck deep in Zcash all week.
<Isthmus> https://twitter.com/Mitchellpkt0/status/1245769462172745728
<monerobux> [ Mitchell P. Krawiec-Thayer on Twitter: "Several unique phenomena in the #Zcash transaction lock_time field. Most make sense: 0, block heights, unix timestamps, delayed broadcast. Still trying to under ] - twitter.com
<Isthmus> We did find that funny transaction over in NRL
<Isthmus> Probably more of a novelty than anything else
<Isthmus> Lemme grab the link
<sarang> Anything relating to the Zcash lock times that's been observed in the Monero network too?
<Isthmus> https://gist.github.com/noncesense-research-lab/a90b8bc5f57ffa9fff1a22d1323e5c2c
<sarang> Or any lessons to learn from the Zcash work?
<Isthmus> Monero's lock times look very similar
<Isthmus> Actually there's also 4 bands
<Isthmus> Like this:
<Isthmus> 0
<Isthmus> {1,3,8,10,12}
<Isthmus> {block heights ~ 1xxxxxx}
<Isthmus> and then UTC timestamps
<Isthmus> It's all over the place, and I don't think any of it is enforced, so the lock_time field is really just an arbitrary memo xD
<sarang> In Zcash too?
<TheCharlatan> Did you analyze the distribution of the UTC timestamps as well?
<Isthmus> Lemme try to find that notebook
<Isthmus> Shoot, I don't have it on this computer
<sarang> No worries
<sarang> Any other action items for the week?
<TheCharlatan> So what's up with duplicate subaddresses?
<sarang> Isthmus: were those the only two such examples?
<sarang> You suggested "novelty", heh
<Isthmus> No, there were several, But all very similar, that one is representative
<sarang> hmm
<sarang> Along those lines, it was suggested (last week, IIRC) to move some of the more standardized tx fields out of extra
<sarang> Which wouldn't eliminate strange behavior, of course
<sarang> but could help with distinguishing factors like ordering etc.
<sarang> Any further thoughts on that?
<Isthmus> I'm working on it a bit, but need to move ideas from my head into diagrams. Will share here in a week or two.
<Isthmus> Might have a new approach, but tbd
<sarang> New approach to what exactly?
<sarang> Transaction structure?
<Isthmus> Nah, mental models that more accurately describe information leaks
<Isthmus> But it doesn't all fit together yet.
<Isthmus> My action item is making it into something comprehensible by next week xD
<sarang> ah ok
<sarang> Neat!
<sarang> We're coming up on the end of the hour
<sarang> Any last questions, topics, action items, etc.?
<binaryFate> Just curious what's your perception of relevant research over the next 6 months. Everything staled? Business almost as usual?
<binaryFate> Conferences and events are mostly canceled or moved to remote?
<sarang> Oh you mean in the broader research community?
<sarang> Seems that some conferences planned for later in the year are playing it by ear for now
<binaryFate> Yeah, anything relevant to MRL and Monero, how do you see things going?
<sarang> The cancellation of the Konferenco was unfortunate, but necessary
<sarang> Otherwise, calls for papers seem to be mostly continuing as normal, which is great to see
<binaryFate> ok good to know thank you
<sarang> Perhaps bored academics stuck at home will be more eager to read and review new research too
<binaryFate> and go straight for journals :)
<Isthmus> Oh interesting question @binaryFate
<Isthmus> That reminds me, when do we want to research quantum-resistant PoW and/or quantum-resistant cryptography?
<Isthmus> Note that pqPoW isn't super important in the short term
<binaryFate> "before it's too late"
<Isthmus> However it is unfortunate that the Monero transaction I make tomorrow will most likely be decrypted by a quantum computer during my life time.
<sarang> I know that suraeNoether had taken a particular interest recently in post-quantum signature constructions, but I don't know of any relevant efficient results at this point
<Isthmus> It might be nice to have somebody put together a survey of (1) Exactly which pieces of Monero will be broken by quantum computers (2) Potentially Monero-compatible solutions
<sarang> The reliance on discrete log hardness is the kicker
<Isthmus> Yep, it's gonna be tricky.
<Isthmus> But, I believe we can do it! If not, Monero has a very limited shelf-life :- P
<atoc> I feel like the bipartite graph matching project that suraeNoether is verifying will be one of the most vulnerable
<sarang> Graph matching is already parallelizable without a quantum computer
<sarang> It's just a very large search space in general
<sarang> On that happy note, let's go ahead and adjourn!
<sarang> Thanks to everyone for participating
<sarang> Logs will be posted shortly to the agenda GitHub issue

Logs for the MRL Meeting Held on 2020-04-01

Wed, 01 Apr 2020 00:00:00 GMT

Logs

<sarang> GREETINGS
<ArticMine> Hi
<Isthmus> Heya
<Isthmus> Sorry I fell asleep last week
<sarang> I'm feeling a bit under the weather today, so I'll try to keep things short and sweet if possible
<sarang> No problem Isthmus
<sarang> Let's move on to ROUNDTABLE
<sarang> My list is short but hopefully interesting
<sarang> The CLSAG preprint has been revised and updated on the IACR archive
<sarang> Link: https://eprint.iacr.org/2019/654
<sarang> New security model and proofs
<UkoeHB_> Oh hi forgot about this :p
<sarang> Alongside this, the code has been updated to make it easier to include trezor/ledger support
<sarang> Plumbing for device support: https://github.com/SarangNoether/monero/commit/94a7daad0f53074a28dbfb39c0ed1d68d5c40e86
<sarang> Support for ledger, courtesy of cslashm: https://github.com/SarangNoether/monero/pull/1
<sarang> Smaller items are proofreading for UkoeHB_'s Zero to Monero update, and finalizing a PR for hash function domain separation, along with the usual literature review
<sarang> Does anyone have particular questions, or otherwise have research of interest to share?
<sarang> I see that Isthmus has just added to the agenda issue
<Isthmus> https://user-images.githubusercontent.com/21246742/78165574-c14f9500-7408-11ea-8ae5-7d695b4321d3.png
<Isthmus> n3ptune and I have been exploring tx_extra some more
<sarang> neat
<Isthmus> A few months ago @UkoeHB_ suggested that the *ordering* of tags might leak some information
<Isthmus> This intuition turned out to be correct
<n3ptune> link to the issue: https://github.com/monero-project/research-lab/issues/61
<Isthmus> If we look at tx_extra in the wild since 1978433 (v12) we see 8 different ways that tags are assembled
<sarang> Enforcing an ordering and certain fields makes sense for uniformity; I wonder what the added time complexity would be for parsing overall
<sarang> This also ties in with an idea for Janus mitigation, which would enforce a per-transaction Janus transaction key and per-output tx pubkeys
<Isthmus> +1
<sarang> And, FWIW, there was a PR yesterday from moneromooo with an idea for an encrypted-memo-type addition to extra: https://github.com/monero-project/monero/pull/6410
<sarang> (I have concerns about that one)
<Isthmus> I would support encrypted memo if *length* and *inclusion* enforced in protocol. :- )
<Isthmus> Zcash has a 512 byte encrypted memo on all z2z transactions, and people are having a lot of fun with it
<Isthmus> (mostly whimsical fun at the moment, but I expect fun applications to follow)
<sarang> Of course, this seems to overlap in functionality somewhat with encrypted pIDs
<Isthmus> Oh yea, could just roll the PID into the memo
<sarang> But yes, I agree that if included, length should be enforced for uniformity
<Isthmus> Would it be per txn or per output?
<UkoeHB_> Im a bit skeptical about scope creep, since Monero is money, not random messages
<ArticMine> and kept small
<UkoeHB_> or email
<ArticMine> or a replacement for twitter
<sarang> AIUI that PR requires a single non-change output
<sarang> at least from my initial read of the code
<sarang> Its use in Zcash is per-output, I believe
<ArticMine> Can we actually do away with this messaging entirely?
<sarang> ?
<UkoeHB_> Isthmus's research indicates that even though the extra field is technically open ended, in practice people arent implementing random things
<UkoeHB_> supporting random messages with core code would directly lead to more random things in the chain
<Isthmus> Wait can we clarify "random"
<Isthmus> Do we mean a fixed tag that supports arbitrary payload
<UkoeHB_> non-standard
<UkoeHB_> I guess 'memo field' implies to me 'any random message you feel like'
<Isthmus> Ideally encrypted
<sarang> To clarify, this PR uses chacha to encrypt with the DH shared secret, including padding as needed to hit certain size resolution
<atoc> what are pros of including memo field?
<sarang> but it's not possible to enforce that the data are actually encrypted
<UkoeHB_> does chacha index each chunk in some way (so no two chunks are likely to be the same)?
<ArticMine> That is my question
<sarang> I think the goal was to enable encrypted recipient data as desired, to reduce the likelihood of non-standard inclusion of data in extra
<sarang> UkoeHB_: the chunks are appended before passing to chacha
<sarang> If I'm reading the PR correctly, the chunking is just to enforce size resolution
<Isthmus> From a technical/statistical info leak standpoint, we should either have *no* messages, or an encrypted message on *every* transactions. Which option we choose is partially a UX/design conversation.
<sarang> And at that point, you basically have a larger pID setup
<Isthmus> Yea
<sarang> Which was part of my concern
<Isthmus> Is there no way to mathematically verify that a field is encrypted?
<sarang> Not for the network AFAIK
<sarang> Nor is it possible in Zcash either
<sarang> It is possible to assure the _recipient_ that if they can decrypt properly, the data were encrypted as expected
<Isthmus> Ohhh yea that's how that works
<sarang> But otherwise, it's just uniformly distributed data
<UkoeHB_> I think that encryption or not isn't a concern, since implementers should want to harmonize with other implementations. The core impl would encrypt, so others would too
<ArticMine> All of this begs the question do we need this memo filed and even extra
<sarang> So the worst case in Zcash is that you throw a bunch of unencrypted junk into a tx that gets accepted by the network, but that the recipient won't properly decrypt
< I would be very happy to do away with both
<UkoeHB_> ArticMine: I think ultimately the extra field is useful when/if hard forks are no longer feasible.
<sarang> At the very least, enforcing ordering as UkoeHB_ listed in their issue would help a lot of this
<sarang> certainly not all cases though
<UkoeHB_> Imagine if Janus attack wasn't discovered until after hard forks stopped happening. We'd be in Bitcoin's situation of absolute chaos
<UkoeHB_> (i.e. if no extra field for wiggle room)
<ArticMine> How would extra help
<Isthmus> Geez, if that happened I think the issue is ossification
<UkoeHB_> wallets can implement janus mitigation on their own, since it's technically unverifiable anyway
<Isthmus> I'd like to proactively avoid a situation like that by keeping an agile codebase, not having an anything-goes tx_extra field
<Isthmus> Anyways, lots of different pros & cons to consider for each possibility
<sarang> The question at this point, I think, is to decide whether doing order enforcement (e.g. TLV) is something that a develop wishes to take on
<sarang> Which ties in to whether enforcement of a consistent Janus mitigation is desirable (I think yes, it is)
<UkoeHB_> After next gen tx protocol gets implemented, I imagine the stuff that can go in a hard fork will drop off quite a bit. Rather than losing the ability to make hard forks, we might just run out of hard forks to make. Once the expectation of making periodic hard forks fades away, subsequent hard forks will become much more difficult (also the case if adoption rises concurrently).
<sarang> Network upgrades also have the probable advantage of encouraging client upgrades
<Isthmus> Yeah "we might just run out of hard forks to make" is a different situation from encountering an issue (e.g. Janus) and not forking
<sarang> which provide other non-consensus fixes and benefits
<Isthmus> Regardless, let's separate the metadata question (should we enforce ordered TLV) from feature questions (should we have a memo field)
<sarang> Well, TLV enforcement has a big effect on non-standard data, since it requires a stated type
<UkoeHB_> I did make pseudo code for enforced sorted TLV, about 200lines
<sarang> yes
<sarang> But I mean that the features and the layout enforcement are closely intertwined here
<UkoeHB_> Current code already mostly does sorted tlv by default
<UkoeHB_> So all that needs to change is in tx validation
<Isthmus>
<atoc> nice
<sarang> OK, so I think what should be brought up in -dev is a well-considered position for 3 things related to extra
<sarang> 1. Decision on TLV enforcement, and responsibility for implementation
<atoc> koe, what's your github
<sarang> 2. Decision on Janus mitigation, and implementation
<sarang> 3. Musings on the new encrypted-memo idea
<UkoeHB_> atoc https://github.com/monero-project/research-lab/issues/61
<sarang> My position is 1: yes, 2: yes, 3: not unless enforced uniformly (and then it runs up against ePIDs)
<Isthmus> 1: agree, 2: agree, 3: agree
<sarang> Anyway, good things to consider here
<gingeropolous> is the janus mitigation the thing with the subaddresses?
<sarang> Yes
<UkoeHB_> Janus https://github.com/monero-project/research-lab/issues/62
<sarang> Enforcing a mitigation has the added advantage of making the number of tx pubkeys uniform
<Isthmus> !!!
<Isthmus> yesplz
<gingeropolous> ima just throw it out there to play devils advocate, dunno if its been stated before. What about reverting to not having subaddresses?
<sarang> So you have one Janus-specific tx pubkey per transaction, and a separate additional pubkey per output
<fuwa> is it possible to replace tx extra completely with memo, so you don't need to sort anything
<sarang> You'd need to remove all non-recipient-specific data from memo
<sarang> Which IIRC moneromooo said would be a significant engineering effort
<sarang> Extra isn't an inherent problem if uniformity is reasonably enforced
<Isthmus> Oh, I was wondering something actually
<Isthmus> Suppose we decide that each transaction should contain X, Y, and Z
<UkoeHB_> gingeropolous: then Janus would no longer be a problem. That's about it afaik
<Isthmus> What's the performance difference between having 3 separate fields versus having 1 field with 3 enforced objects
<sarang> That's a good question, and I'm not sure
<gingeropolous> right. so i guess the underlying question is whether subaddresses are worth it.
<sarang> The scanning benefit is huge for large sets of addresses
<sarang> Hash lookups are much faster than doing multiple scans of all transactions per address
<sarang> and Janus checks are only needed for transactions that are already identified as being destined for you
<sarang> (and those checks are quite fast anyway)
<sarang> Also note that MLSAG -> CLSAG drops average tx size by 600 bytes already
<sarang> s/average/typical
<ArticMine> Like 2 in 2 out
<sarang> Yes, a 2-2 tx drops already from ~2.5 kB to ~1.9 kB
<sarang> So Janus mitigation adds something like about 64 bytes back in
<sarang> (more for multi-output)
<sarang> Meaning there's already plenty of wiggle room
<gingeropolous> well here's hoping its the last mitigation for subaddresses.
<atoc> that's a pretty good drop
<ArticMine> We can increase the ring size
<UkoeHB_> meeting is getting toward the end, so Ill add my update here: ztm2 should be ready to publish this weekend, I'm finishing up my last proofreading atm
<sarang> UkoeHB_: great!
<UkoeHB_> might take a bit for getmonero to update though, so we will see when I post about it
<atoc> koe - i sent you an email but to reiterate it's looking really good
<UkoeHB_> yeah saw that :)
<sarang> Since the hour is indeed almost up, does anyone else wish to share any topics of interest?
<Isthmus> https://www.reddit.com/r/Monero/comments/fnhm6u/maam\_monero\_ask\_anything\_monday\_march\_23\_2020/flbbt45?utm\_source=share&utm\_medium=web2x
<Isthmus> ^ thoughts?
<Isthmus> I'm looking for projects for Fellows to work on, wondering if that seems like a good candidate
<sarang> That sounds like a question for -dev or -gui TBH!
<Isthmus> I could also have one of the software engineers implement ordered TLV if -dev wants somebody else to tackle it
<Isthmus> Oh yea, good point
<Isthmus> Any wish list projects for MRL? I have 2 software engineers, 1 mathematician, and some data scientists that are open to working on Monero stuff
<atoc> Isthmus this seems good. i am willing to help but probably can't commit too much atm
<sarang> Isthmus: perhaps pop over to -dev after meeting and let the channel know that a Fellow might be able to tackle TLV
<sarang> see what the responses are
<sarang> I bet moneromooo will have better knowledge of the effects that parsing would have on performance overall
<UkoeHB_> well this never got much traction but Im still a fan https://github.com/monero-project/research-lab/issues/59 could be a lot of work idk
<sarang> Isthmus: I know this important PR needed review... https://github.com/monero-project/supercop/pull/3
<sarang> and if any Fellows have sufficient interest, the new CLSAG security model in the paper could use some eyes
<sarang> Anyway, let's start to wrap up
<ArticMine> I'll cover the fee, penalty and median proposal in the next meeting. By then I'll have most of this finalized
<sarang> Any ACTION ITEMS to share?
<sarang> Great ArticMine
<atoc> @sarang i'll probably ping you tomorrow to go over some zkp ideas for atomic swap
<sarang> I'll be doing some work on an older preprint, reviewing some ideas in a draft preprint that were sent to me by another researcher, and returning to some Triptych code
<UkoeHB_> there are two other big projects: fully-formed audit functionality, and extensive updates to multisig; mentioned those to TheCharlatan but they really are beasts I expect
<atoc> i have some resources i'd like to share
<sarang> for sure
<Isthmus> We can close up the meeting, but I'm curious later if anybody has speculation around what's going on with https://xmrchain.net/search?value=f6cff1edd1a7861ed13d494dd4ae7c4a7f42b5c3bf91457310d2166722c1316f
<Isthmus> It has an unknown tag type, and the length is recorded incorrectly
<UkoeHB_> are you sure it's a length and not a value byte?
<Isthmus> Not sure, that's why I'm asking
<sarang> All right, let's go ahead and adjourn for timing purposes, but discussions can of course continue
<sarang> Thanks to everyone for attending!
<sarang> Logs posted shortly on the GitHub agenda issue

Logs for the Community Meeting Held on 2020-03-28

Sat, 28 Mar 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/450
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<xmrscott[m]> Hola
<kinghat[m]> o/
<msvb-mob> Hello.
<sgp_> ping needmonero90 rehrar ErCiccione[m]
* needmonero90 yawns
* needmonero90 rolls over
* needmonero90 zzzzzzzzzzzzzzz
<sgp_> lol, you even get an extra hour of sleep now
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> I’m soft announcing our new home! https://communityworkgroup.org. We can use this page to more easily organize Monero Community Workgroup resources going forward. It also has a calendar you can subscribe to for meeting reminders. If we have time during open ideas, I’d love to hear your ideas!
<sgp_> Does anyone have community (non-workgroup) updates to share?
<needmonero90> Still waking up, I'll think of something eventually
<sgp_> Community is tired :)
<sgp_> 3. CCS updates
<needmonero90> Ah yes
<needmonero90> Publish0x is blacklisted now
<needmonero90> From the subreddit
<sgp_> long overdue
<needmonero90> Yup, but gotta get announced somewhere
<sgp_> check off that compliance requirement
<needmonero90> Additionally
<needmonero90> I'd like to thank osrsneedsf2p
<needmonero90> He helped us modify the regex for nonparticipation links, so that sister subreddits no longer get your comment removed
<needmonero90> Which is really really nics
<sgp_> excellent
<needmonero90> Nice
<needmonero90> Okay, that's it from my end. Probably one or two more minor things to announce, if I think of them I'll mention
<needmonero90> Carry on :)
<sgp_> speaking of compliance requirements....
<sgp_> Before we get into the usual CCS section, needmoney90 initiated a discussion on the topic of proactively preventing the CCS from being used as a potential vehicle for sanctions funding.
<sgp_> I’m soliciting feedback on adding the following attestation required to open a CCS proposal:
<sgp_> “I declare that I (and the entity and individuals I represent, if applicable) am/are not on OFAC’s Specially Designated Nationals and Blocked Persons List or otherwise covered by any other OFAC sanctions list, which may include entities and individuals in certain jurisdictions.”
<sgp_> https://www.treasury.gov/resource-center/sanctions/Pages/default.aspxtions
<rehrar> Sorry here
<sgp_> https://www.treasury.gov/resource-center/sanctions/Pages/default.aspx ^^
<needmonero90> I would like the blurb determined by a lawyer
<needmonero90> That does not cover money moving to a covered entity
<sgp_> needmonero90: want to provide one?
<needmonero90> Which also is counted as part of the sanctions
<needmonero90> I've asked Fluffy to talk to the tari people, but thus far he hasn't responded
<needmonero90> Been a few days
<sgp_> you can also rip one from a large company's ToS you find
<ErCiccione[m]> sorry just arrived. Reading backlog
<sgp_> Does anyone have general questions on this or concerns?
<sgp_> Note: this is a *completely* preventative measure
<needmonero90> Nothing on my end, raising the issue once I was aware of it is all I can do atm
<sgp_> We may want to have a wider topic on terms of use like Zcash Foundation's: https://grants.zfnd.org/tos
<sgp_> but we can do that later, just wanted to make sure people are aware of the conversation
<sgp_> needmonero90: want to open a github issue for it in meta?
<needmonero90> Sure.
<sgp_> thanks, it will help with organization
<sgp_> Funding required:
<sgp_> All proposals in funding required are fully-funded!
<rehrar> Disagree.
<rehrar> Don't ask don't tell.
<sgp_> rehrar: there are some concerns that may not be a sufficient policy
<rehrar> The CCS is not based in the USA.
<needmonero90> Donors can be.
<needmonero90> And they should be informed if so, no😆
<needmonero90> *?
<rehrar> They are donating money to the CCS, not the individual.
<rehrar> Which is not based in the CCS.
<sgp_> it's not that simple
<rehrar> *USA
<needmonero90> Ofac covers money transferring through entities to an Ofac covered entity
<needmonero90> It doesn't stop after one hop, you're expected to know the end recipient
<needmonero90> Which is bullshit
<needmonero90> But we're expected to self enforce, at penalty of $55k/violation and 20y in jail max penalty
<needmonero90> If we do not make a note in a CCS about where the money goes, we could have some serious issues for donors (or CCS maintainers should they be located in the US and facilitating the payment)
<selsta> Isn’t this something core team has to decide? They are operating the CCS.
<rehrar> Then what was done (nm90) saying what he found in the comments is the correct way to do.
<needmonero90> I got attacked for that
<rehrar> A measure should NOT be added to the CCS rules. Never.
<needmonero90> Apparently I shouldn't have even mentioned it
<needmonero90> Just ignore it and it'll go away
<needmonero90> Googling peoples usernames is unacceptable
<sgp_> needmonero90: I think people were upset you mentioned it in a specific proposal
<needmonero90> I was literally just told by rehrar to mention it in a specific proposal
<ErCiccione[m]> posting their suspected name in public is unaccettable
<needmonero90> His suggestion is what I just did
<needmonero90> Er, his 'suspected name' is literally the username he's using
<rottensox> ^
<needmonero90> That's not doxxing dude
<sgp_> I didn't know rehrar suggested that
<rehrar> nm90 I'm not thrilled with using comments for it either, but if we HAD to do something, then I'd rather it be that than formalizing the CCS with this red tape.
<ErCiccione[m]> guys are you serious? Posting the suspected personal information on somebody (we are talking about a real profile) is not a good thing at all
<rehrar> Sgp he's referring to my comment above saying the comments would be the way to do it rather than codifying it.
<needmonero90> If it's the first Google result for their username I see no problem.
<needmonero90> That's called due diligence
<nioc> .w nioc
<monerobux> [WIKIPEDIA] National Iranian Oil Company | "The National Iranian Oil Company (NIOC; Persian: شرکت ملّی نفت ایران‎, romanized: Sherkat-e Melli-ye Naft-e Īrān) is a government-owned national oil and natural gas producer and distributor under the direction of the Ministry of Petroleum of Iran. NIOC was established in 1948 and restructured under The..." | https://en.wikipedia.org/wiki/National\_Iranian_Oil_Company
<ErCiccione[m]> please
<sgp_> still, we should have an idea what to do going forward
<nioc> I guess that I should be banned
<rottensox> ErCiccione[m]: Who - 'My name is Moeen Mohamadi, a native Persian speaker.' https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/133
<rottensox> who posted suspected what if it's alreayd there?
<selsta> You can find real info of a lot of people by just googling, does mean it is okay. If they don’t link to their linkedin, you also shouldn’t in public.
<ErCiccione[m]> eh?
<sgp_> let's make sure this discussion doesn't get derailed too much into a mostly-unrelated topic
<needmonero90> Selsta: are we not allowed to look into the usernames of people we fund?
<needmonero90> Should we ignore that username histories exist?
<needmonero90> Are we not allowed to mention the results of the first page of a Google search?
<sgp_> I'm focusing just on making sure the CCS doesn't have unnecessary liability for donors, CCS proposers, and Core
<needmonero90> Exactly what kind of due diligence do you think is acceptable
<sgp_> needmonero90: maybe it's best to table that question for now
<needmonero90> Because expecting people to not Google a username and report on it is silly
<needmonero90> This is someone we're paying money...
<needmonero90> Anyways.
<rehrar> I sympathize with needmoney90 here somewhat. If someone new is asking for funds, to decide if this person is deserving someone might do a Google.
<kinghat[m]> maybe a longer term goal would be to setup a type of DAO that way nobody is responsible 🤷‍♂️
<xmrscott[m]> nm90: OSINT is technically fair game, but I digress
<needmonero90> Googling the username of a potential donee strikes me as like, the very basic of basic due diligence
<needmonero90> Exactly how else do you look into a person's history
<selsta> rehrar: Googling a person is okay. Posting their linkedin without asking isn’t. If there are doubts, core can do this in private.
<needmonero90> The username is like, the first thread
<needmonero90> Literally the first hit for his username
<needmonero90> How is reporting the first thing returned about his username doxxing
<nioc> given that nobody knows who donated to which CCS, who is responsible?
<needmonero90> Sorry for carrying on sgp
<sgp_> ok I need to cut this off, we need to take a step back since the discussion on what is fair to research isn't going to go anywhere
<needmonero90> I'm done
<sgp_> point is rehrar I'm representing a community's perspective in saying that your desired solution may not be adequate for the safety/liability of donors, CCS proposers and the funds they receive, etc. I genuinely think it's worth coming up with a ToS
<sgp_> even if Core doesn't care, other people might
<rehrar> Then people should assess the risk of donating to the CCS.
<rehrar> I will bring it up with core, but I'm certain they will not be happy with making a ToS.
<sgp_> well if the risk is high to the point the platform is useless, that's a community problem
<selsta> not sure why we should create a ToS for someone else.
<needmonero90> Like by being informed if there's a potential legal risk with donating to a certain proposal?
<sgp_> ^
<rehrar> sgp_: then let it be so.
<sgp_> great :/
<rehrar> This is Monero, guys. We aren't Zcash.
<needmonero90> And we also don't want to open ourselves up to an easy attack
<rehrar> If the risk is too great for some on scary proposals, then don't donate.
<rehrar> Many/most proposals don't have this issue and won't carry risk.
<needmonero90> We already had proposals from venezuelans
<sgp_> the perception of a risky platform is a huge concern
<needmonero90> So we crossed the line already
<kinghat[m]> ✊
<nioc> •sgp_> well if the risk is high to the point the platform is useless, that's a community problem <-- sending 3xmr is high risk?
<needmonero90> We should have had this discussion before any sanctioned countries came into the cross hair, but the discussion is happening now.
<sgp_> nioc: potentially, "it depends"
<needmonero90> [conversation totally over]
<rehrar> Just shut up if about if you donated or not?
<ErCiccione[m]> all this is way overamplified
<selsta> Core team has lawyers. They should decide all this. No one is a lawyer here so the discussion is useless.
<sgp_> in any case, I think we can move on for now. discussions can continue on Github or whatever
<sgp_> Ideas (to be discussed):
<sgp_> Mining outreach, Ministo (40 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/124
<sgp_> No movement on this in a month, so I will skip. Feedback was mostly negative last time we discussed it.
<ErCiccione[m]> selsta: +1
<sgp_> [Monero Aligned] Proposal for 1M5 Integration as Proxy, Brian Taylor (150 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/127
<sgp_> No movement on this in a month, so I will skip.
<sgp_> Norwegian translation of webplate + footers + nav. Menu, Chris Avis (6 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/129
<sgp_> Does anyone know the status of this?
<sgp_> rehrar do you recall if this was discussed last meeting?
<ErCiccione[m]> I'm ok with it. Fair price good quality
<sgp_> any other comments here? otherwise I think it can be moved
<rehrar> I don't recall.
<sgp_> Monero Debian Package Repository for 2 years, Patrick Schleizer (60 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/130
<sgp_> Do we need to discuss this one further?
<rehrar> I say no. It should be moved.
<rehrar> Although prices on all of these should maybe be adjusted?
<sgp_> right, I encourage you and luigi to reping ones to be moved for a chance to update if needed
<rehrar> Sounds good. I'll ping him now.
<sgp_> erciccione: part time work (April-May) on Getmonero.org https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/134
<sgp_> approval from me
<selsta> I also gsve a +1
<sgp_> Persian translation of the GUI wallet https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/133
<sgp_> ErCiccione[m]: you expressed some concerns?
<ErCiccione> I say no. Most because of the high price and the fact that everything he writes is in an english more broken than mine
<ErCiccione> for that rate, i would expect a professional translator with a super CV
<sgp_> thanks, good to know
<xmrscott[m]> And thus English comprehension may not be adequate I take it?
<nioc> +1 for ErCiccione's proposal
<dEBRUYNE> I also deemed his comments toward the community quite negative
<TrasherDK> Second that.
<dEBRUYNE> Plus no track record of voluntary work on Monero (related) projects
<TrasherDK> That too.
<ErCiccione> i agree dEBRUYNE that was the nail of the coffin from me, very bad attitude
<sgp_> ok, sounds like a recommendation to reject there
<sgp_> Any other CCS comments before we move on?
<ErCiccione> (Thanks for the support btw selsta nioc sgp_)
<ErCiccione> i would have suggested him to ask half what is asking, but after his behaviour it's just a nono
<sgp_> ErCiccione: you're a frequent leader, we need more of that
<ErCiccione> onward!
<ErCiccione> :P
<dEBRUYNE> <ErCiccione> (Thanks for the support btw selsta nioc sgp_) <= Another +1 from me :p
<sgp_> 4. Workgroup report
<dEBRUYNE> ErCiccione: Also him using the maximum rate of the rate bound you suggested
<sgp_> a. Daemon/CLI workgroup
<sgp_> new point release is out
<ErCiccione> dEBRUYNE: yeah that was sad (thank you too btw)
<sgp_> https://getmonero.org/2020/03/19/monero-0.15.0.5-released.html
<sgp_> b. Localization workgroup
<sgp_> go ahead
<ErCiccione> Not much, but now the roadmap of the website is translatable on weblate
<ErCiccione> but
<ErCiccione> outreach folks are looking for people to create articles/art and whatever in languages different from english
<ErCiccione> so if anybody has anything to offer, get in touch with them
<ErCiccione> and one good news
<ErCiccione> can be that weblate soon will be able to translate plain markdown files
<ErCiccione> that could be useful to all workgroups, because would give the possibility to translate stuff that wasn't possible to translate before
<ErCiccione> so, keeping an eye on that
<ErCiccione> And there is big need of translators for the website:
<ErCiccione> https://translate.getmonero.org/projects/getmonero/monero-site/
<ErCiccione> so if you can and have time, please translate stuff
<ErCiccione> that's it
<sgp_> I'm looking forward to the markdown feature
<rehrar> I have something to discuss when this we ready for open ideas time.
<sgp_> noted rehrar
<ErCiccione> yeah, would solve the problem of the documentation of getmonero.
<sgp_> c. GUI workgroup
<sgp_> https://getmonero.org/2020/03/05/monero-GUI-0.15.0.4-released.html
<sgp_> d. Outreach workgroup
<sgp_> Is anyone from outreach here?
<selsta> I can give a small GUI update
<sgp_> otherwise I'll just tease that there is a new article coming out soon with no other details
<sgp_> selsta: that would be much appreciated, thanks
<selsta> xiphon is working on an update downloader
<selsta> so that the GUI automatically downloads a new update, verifies the hashes and opens the folder containing the new version
<sarang> Does/will it use the stuff that moneromooo built for doing this?
<selsta> I think it shares some code but mooos tool is only for CLI currently as GUI has no reproducible builds yet
<rehrar> What's the word on that btw?
<rehrar> Reproducible builds for the GUI?
<selsta> still work in progress
<selsta> will take a while
<selsta> but progress is made already, you can build with cmake on linux and windows
<selsta> ok that’s all for GUI
<sgp_> selsta: I added a reminder to my notes to ask you for an update next time
<sgp_> e. Website workgroup
<sgp_> ErCiccione: you have the floor again
<ErCiccione> yay
<ErCiccione> i posted updates here: https://www.reddit.com/r/Monero/comments/foooc6/getmoneroorg\_updated_new_roadmap_page_1_new/
<monerobux> [REDDIT] Getmonero.org updated: New roadmap page, 1 new moneropedia entry, 1 new FAQ entry, new MRL paper, updated guides and more (self.Monero) | 52 points (86.0%) | 11 comments | Posted by ErCiccione | Created at 2020-03-25 - 11:23:58
<ErCiccione> as i said, the roadmap has now a different structure, it's translatable on weblate and it's much easier to update
<ErCiccione> i have some open MR that need testing, so please take a look: https://repo.getmonero.org/monero-project/monero-site/-/merge\_requests
<ErCiccione> Currently working on adding another moneropedia entry and on the FAQ
<kinghat[m]> <selsta "but progress is made already, yo"> reproducible build on linux and win?
<selsta> no, only cmake
<selsta> which is a first step to reproducible builds
<kinghat[m]> not sure what that looks like on actual IRC btw
<sgp_> You also commented in a related discussion to move the website back to Github: https://github.com/monero-project/meta/issues/236#issuecomment-605023567
<kinghat[m]> thanks selsta
<ErCiccione> yes sgp_ i finally capitulated and now i agree we should move back monero-site to github
<ErCiccione> reasons explained in the comment you posted
<kinghat[m]> whats the word on the GUI builds for the current release?
<ErCiccione> hope core agrees and we can move back in a reasonable timeframe
<sgp_> I agree fwiw since I often forget to check Gitlab
<kinghat[m]> 0.15.0.5*
<ErCiccione> i think that's the case for many
<selsta> kinghat[m]: Snipa does builds and he is a bit busy with setting up WFH for his workplace due to current events.
<selsta> so should be out some time, not sure when yet
<sgp_> I'm going to move on to the next update since we absolutely need to get to it, thanks selsta kinghat[m] and ErCiccione
<kinghat[m]> understandable. tyvm.
<sgp_> f. Monero Research Lab
<sarang> Hi
<sgp_> Sarang Noether has an important update on the Monero Research Lab
<sarang> My colleague suraeNoether stated in an earlier MRL meeting that he would have extremely limited availability for the time being
<sarang> partly because of this, CLSAG had been delayed while I waited on his approval/fixes for the preprint (he is a coauthor)
<sarang> I've since received his permission to just make changes and post the preprint
<sarang> So
<sarang> If anyone has ideas and thoughts about what they feel should be research priorities going forward, please join the next #monero-research-lab meeting on Wednesday at 17:00 UTC
<sarang> Because of this change, I'm now completing final proofreading of the CLSAG preprint
<sarang> and finalizing some optimized code for later audit/review
<sarang> as well as coordinating trezor/ledger support so it's ready to go
<sarang> Separately, Triptych-2 was posted to IACR, and I'm working on some multisig and join-type math for it
<sgp_> Do you expect to be the only full-time researcher for the foreseeable future?
<sarang> I am currently the only CCS-supported full-time researcher
<sarang> and I do not know when/if suraeNoether will choose to do full-time research
<sarang> I don't want to speak for him
<sgp_> thanks for the update. does anyone have any questions?
<sarang> So anyway, I'm working hard to get a lot of projects moving forward
<sarang> and will continue to do the best I can
<kinghat[m]> 🙏
<sgp_> sarang: can you provide a nice overview of projects before the wednesday meeting?
<sarang> You mean an overview right now?
<sarang> Sure
<sarang> Or just post to a github gist for easy reading?
<sgp_> I was more thinking a gist, yes
<sarang> Sure
<sgp_> thank you
<sarang> Will post a link here and in -lab later today
<sarang> See -lab topic or meta github issue for meeting details
<sgp_> anything else sarang?
<sarang> No, I don't think so
<sgp_> ok, let's get to rehrar's thing then
<sgp_> 5. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<sgp_> go ahead rehrar
<rehrar> so yeah, I just wanted to get a general poll from attendees about putting together virtual meetups on a weekly or biweekly basis
<rehrar> would this be something that would just add noise? Or could it be useful for having fun (especially during these times)?
<sgp_> I'm for it but I'd rather just use Jitsi than VR
<needmonero90> so, VR really means 3d virtual space
<needmonero90> because it allows conversations to self organize
<M5M400> what kind of equipment does someone need to attend these meetings rehrar
<needmonero90> jitsi may be nice, but it has issues with multiple conversation tracks
<sgp_> also note that we have activities planned on every Saturday next month (2 community meetings, Coffee Chat, and Moneroversary)
<msvb-mob> A normal physical lab group is doing this with Jitsi, with limited success. Mostly socialising value.
<rehrar> M5M400: a computer
<needmonero90> theres no such thing as a 'hallway track' for a broadcast event
<msvb-mob> Probably is fun for some people, so it's good that rehrar is researching.
<M5M400> rehrar: no VR goggles or anything?
<rehrar> M5M400, VR equipment not needed for the VR space.
<needmonero90> possible but not necessary
<rehrar> M5M400, want to try it out after the meeting? It's browser based.
<sarang> rehrar and I tested this earlier
<M5M400> btw thanks for bringing jitsi to my life. I deployed it at work and it's replaced stupid webex since this crisis :)
<rehrar> It will take effort to organize, and I Don't know if this is the best use of my time if it won't be used, so I just wanted to get opinions.
<sgp_> M5M400: ikr, it's a life-saver
<M5M400> oh, I crashed into a meeting. sorry. didn't want to OT
<rehrar> M5M400, I know all of the FOSS.
<selsta> My laptop which works fine for developing is not strong enough VR so I guess you need a recent computer :P
<msvb-mob> rehrar: What was the results of testing the Mozilla meeting tool?
<rehrar> msvb-mob: everyone thought positively of it after use
<rehrar> it's quite versatile
<msvb-mob> The name?
<sgp_> I'm happy to announce a meeting in whatever format to the Monero Chicago meetup group
<sarang> The only downside was that volume is distance-dependent
<sarang> so it seemed unsuitable for a lecture-type event
<rehrar> msvb-mob: Mozilla Hubs
<sarang> as in, moving farther away from a speaker's avatar makes them quieter, as in real life
<rehrar> sarang: we tested and you can turn the speaker up
<sarang> Oh neat, nvm them
<sarang> *then
<rehrar> so much so that you can hear them from far away
<msvb-mob> sarang: The volume problem is when using Mozilla Hubs or another tool?
<rehrar> Hubs, but it's not a problem.
<sarang> the Mozilla tool that rehrar and I had tested
<sgp_> rehrar just wants to make sure we can't avoid his rants
<sarang> so I withdraw my comment msvb-mob
<rehrar> https://hub.link/ktcMqWR
<rottensox> lol.
<rehrar> hop on sarang, sgp_, msvb-mob, rottensox, M5M400
<sarang> I unfortunately cannot (other tasks to complete today)
<rehrar> ok
<sgp_> see this is a case where jitsi is slightly easier since I want to be on while I make pancakes
<xmrscott[m]> I'm down for reoccuring VR meetups
<sgp_> anything else? I'll see if I can hop on while cooking
<xmrscott[m]> Or perhaps I should say 'VR' given technically you don't need a VR setup to use Mozilla Hubs
<kinghat[m]> as a long term goal why not look into a type of DOA for funding. not controlled centrally, no liability.
<sgp_> I'm going to wrap up the formal meeting now. Thanks for the idea rehrar; I think it's a good one
<rehrar> Coo
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 11 April at 17:00 UTC.
<sgp_> The next Coffee Chat is next week on 4 April at 17:00 UTC. The Moneroversary is on April 18.
<sgp_> expect next meeting to mostly be about planning the moneroversary (maybe I'll schedule 2 hours)
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, STAY SAFE AND ISOLATED, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2020-03-25

Wed, 25 Mar 2020 00:00:00 GMT

Logs

<sarang> GREETINGS
<sarang> hi
<seddd>: o/
<UkoeHB_> hi
<SerHack> hi
<sarang> Moving on, then, to ROUNDTABLE
<sarang> Who wishes to share research of interest?
<ArticMine> Hi
<sarang> I can share a few things
<sarang> I've completed some formal peer review for the IEEE S&B proceedings
<sarang> and worked on analysis for a linkable ring signature construction in IACR 2020/333
<sarang> it claimed to be more efficient than CLSAG
<sarang> However, the numbers assumed an insecure key image construction
<sarang> The authors have already posted a revision, but it doesn't include numbers or new security proofs for the modified construction
<sarang> Besides this, here's an update on some other projects...
<sarang> For CLSAG, I am still waiting on the final go-ahead from suraeNoether, who is a coauthor on the paper
<sarang> I finished code optimization and made a PR to moneromooo's branch, which has some nice verification speedups
<sarang> For Triptych-1, its preprint has been updated at IACR 2020/018
<sarang> An MPC construction for key images is completed, and multisig/join analysis is still underway
<sarang> For Triptych-2, its preprint has been posted at IACR 2020/312
<sarang> Multisig/join analysis is still underway
<sarang> That's all for me
<sarang> Any particular questions or comments?
<nioc> how much verification speeedup for CLSAG?
<seddd>: Do you need any more eyes on the CLSAG PR?
<sarang> It's around 4-5%
<nioc> nice
<sarang> seddd: That would be welcome, once moneromooo integrates the new changes into the branch
<seddd>: Ok, let me know, and I'll review
<sarang> that'd be great
<moneromooo> I did, I can push.
<sarang> Oh excellent
<ArticMine> 4-5% reduction in size? Verification time?
<sarang> The only real changes from the paper's description is a modification to the public parameters that go into the challenge hashes, which allows for the speedup to happen
<sarang> ArticMine: verification time
<sarang> I didn't bother with generation stuff, since that's less important
<sarang> Size is identical
<sarang> The PR includes new performance tests with better direct comparison to MLSAG, if that's useful to anyone
<seddd>: moneromooo: link?
<ArticMine> So is this the version that is going for audit?
<moneromooo> Not yet.
<sarang> Presumably, but that's up to the audit workgroup
<moneromooo> I'm rebasing it to master now, then will run tests, then push, then post a link.
<sarang> moneromooo: excellent, then the CI workflow will operate properly
<seddd>: awesome, many thanks
<sarang> Any other questions for me?
<sarang> Or does anyone else wish to share research topics?
<seddd>: Mb but it involves pow of another coin, not sure appropriate
<sarang> Perhaps suited for after the meeting
<seddd>: Definitely
<selsta> who is the audit workgroup? sgp?
<sarang> sgp_ has been working to coordinate
<sarang> As far as the CLSAG paper goes, if I don't hear from suraeNoether, eventually I suppose we'll just have to release the revised version without him
<sarang> But I would prefer not to do that, since he's a coauthor
<seddd>: Is suraeNoether not around rn?
<sarang> He hasn't enabled public viewing on the overleaf version, and I don't have access rights to do that unfortunately
<sarang> No, he is not around right now AFAIK
<seddd>: k
<sarang> Well, to respect everyone's time, I suppose we can move to ACTION ITEMS
<UkoeHB_> update from me: proofreading is extended to this weekend as comments are trickling in at the last moment :p; I have received several good feedbacks so far
<sarang> Ah ok, go ahead UkoeHB_
<UkoeHB_> current proofreading version is here https://www.pdf-archive.com/2020/03/22/zerotomoneromaster-v1-1-2/zerotomoneromaster-v1-1-2.pdf
<UkoeHB_> that's all
<sarang> Great, thanks
<sarang> My action items are to complete my proofreading of Zero to Monero (it's been delayed; my apologies)
<sarang> and to work on some Triptych-2 MPC math
<sarang> Anyone else?
<hyc> "research only, not for production use" inb4 sumo releases it and claims to be first
<UkoeHB_> oh right, I made a small update to Janus mitigation
<sarang> hyc: ?
<sgp_> UkoeHB_: cool,, what?
<seddd>: lul hyc
<hyc> sorry, catching up from a couple days ago
<UkoeHB_> https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784
<seddd>: imagines sumo as yt commenter: "FIRST"
<sgp_> UkoeHB_: none of that is implemented correct?
<sarang> Off topic, folks!
<UkoeHB_> correct
<seddd>: srry
<sarang> IIRC, the last time Janus mitigations were discussed in a dev meeting, there seemed to be mixed support
<UkoeHB_> my action item is to go through all proofreading comments, and then this weekend finalize a for-publication version
<UkoeHB_> sarang part of that seemed to be related to exactly how many pub keys and janus base keys it would require
<UkoeHB_> full Janus mitigation would require: 1 Janus base key per transaction, #pub keys = #outputs for ALL transactions (not just tx with subaddresses as is the case now)
<sarang> yep
<seddd>: sounds like a lot of overhead, is that one of the main objections?
<UkoeHB_> there is partial Janus mitigation, where normal addresses and subaddresses are split up; in other words, don't mitigate linking of normal addresses with subaddresses; that way only tx with subaddresses would need the janus base key
<UkoeHB_> however, even with partial mitigation a lot more subaddress tx would be revealed as subaddress, as there are currently some optimizations that hide subaddress tx among normal tx
<UkoeHB_> while with full migitation, normal address tx and subaddress tx would be universally indistinguishable
<UkoeHB_> which iirc sarang was in favor of even outside of Janus
<seddd>: +1 for the latter
<sarang> Yeah, encouraging/enforcing indistinguishability is useful
<UkoeHB_> the main objective is solving the Janus attack
<UkoeHB_> which is currently undetectable
<sarang> yes
<seddd>: so what are the opposing arguments?
<sarang> Transaction size is increased
<sarang> that's a big counterargument
<sarang> (literally)
<seddd>: :)
<sarang> So as happens always, there's a tradeoff on complexity (in this case, size and protocol changes) and indistinguishability
<sarang> s/always/often
<sarang> Worth noting that with CLSAG, standard tx size already drops from ~2.5 kB to ~1.9 kB
<sarang> so there's some wiggle room
<seddd>: are there potentially more compact full Janis mitigations?
<sarang> Each added scalar/group element adds 32 bytes
<seddd>: Janus*
<UkoeHB_> this is the smallest known mitigation
<ArticMine> Tx size is increased by how much?
<UkoeHB_> on average, about 2.2*32 bytes per transaction
<UkoeHB_> assuming 2.2 is the average output count
<UkoeHB_> wait no, 32 + 1.2*32
<UkoeHB_> same thing lol
<seddd>: What about encoding the extra basepoint in smth like a lookup table, where base points are indexed by the first 8? bytes
<UkoeHB_> actually a tiny bit less than that, taking into account current subaddress tx
<ArticMine> So 64 bytes for a typical tx
<UkoeHB_> yeah basically
<ArticMine> So if the security issue is verified I do not see an issue here
<UkoeHB_> seddd, the base key must be generated by transaction authors
<UkoeHB_> under the current construction, not sure if there are any other ways to do it
<sarang> ArticMine: the math checks out on the fix
<seddd>: Ok so unknowable ahead, gotcha
<seddd>: will read more in the issue you linked
<sarang> Probably time to bring it up in dev meeting again
<UkoeHB_> seddd there might be something to that (using a fixed janus base key of some kind), Ill ponder it a bit
<sarang> Any other action items to bring up?
<seddd>: UkoeHB_ that's kind of what I was thinking, or a fixed set of usable bases
<seddd>: Happy to collaborate, this is an interesting problem
<sarang> for sure
<sarang> OK, let's go ahead and wrap things up for this meeting; discussions can of course continue after we adjourn
<sarang> Any last topics of general interest for the meeting?
<sarang> Righto! Meeting adjourned
<sarang> thanks to everyone for attending

Release 0.15.0.5

Thu, 19 Mar 2020 00:00:00 GMT

Overview

This is the v0.15.0.5 release of the Monero software, which contains bug fixes.

Changelog

The changes introduced with this release are:

Tor / I2P: plug Tor to clearnet association vector
Various minor bug fixes

Note that you can find a full changelog on GitHub.

Download Links

Or visit the Downloads page.

You can also compile it from source by yourself. See the instructions on GitHub

Verify Hashes

If you would like to verify that you have downloaded the correct file, check the following SHA256 hashes using these guides: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced).

52e46ead674275ed446e261795b2cde19e65f7098ce62902bfa275e67f9f10f7  monero-android-armv7-v0.15.0.5.tar.bz2
ceccc11723c4dff3cef420b37bc795850b74a8e71d23d44aa26faf5cd8fcc0e6  monero-android-armv8-v0.15.0.5.tar.bz2
b0ea91c4d0f68d8d85ba15ed537bdd81589fa796f88d96aec451543f87b9fdb7  monero-freebsd-x64-v0.15.0.5.tar.bz2
a23402ccf5ac432306fe263fae660646206ecb9d2aec3cfacb25afce34794067  monero-linux-armv7-v0.15.0.5.tar.bz2
04e73cf72f37f0bbdfa757c9bb5df2117aee473632a917041077da3c05169743  monero-linux-armv8-v0.15.0.5.tar.bz2
6cae57cdfc89d85c612980c6a71a0483bbfc1b0f56bbb30e87e933e7ba6fc7e7  monero-linux-x64-v0.15.0.5.tar.bz2
fd2c32fc3efa47b2feda6526b0a2df4e1acc7325ec205a25d7947fbc843b24df  monero-linux-x86-v0.15.0.5.tar.bz2
8ef04398350b8de68e21da236801f276cf662641e03dc067f6e865180f9853f6  monero-mac-x64-v0.15.0.5.tar.bz2
0286e21552d3fedfedbc7c7aba2f34c370ad4c21007a75fb67ac87994c5cec5a  monero-win-x64-v0.15.0.5.zip
bdcc5af964b6271bbf05609edfc49093b690f15031b748dfb43ffe991ae9cc6e  monero-win-x86-v0.15.0.5.zip

Logs for the MRL Meeting Held on 2020-03-11

Wed, 11 Mar 2020 00:00:00 GMT

Logs

<sarang> OK, let's begin the meeting!
<sarang> Agenda is here: https://github.com/monero-project/meta/issues/445
<sarang> Logs will be posted there after the meeting
<suraeNoether> good morning
<sarang> First on the list, GREETINGS
<sarang> hi
<sarang> Note that because of a recent time change for the United States and elsewhere, these meetings will take place at 17:00 UTC instead of 18:00 UTC
<ArticMine> hi
<Isthmus> heya sarang and artic
<sarang> I suppose we can move on to ROUNDTABLE
<sarang> Who wishes to share research topics of interest?
<vtnerd> hi
<UkoeHB_> Hi
<suraeNoether> well
<suraeNoether> i want to give a brief two-part update
<sarang> Go ahead suraeNoether!
<suraeNoether> firstly, personally: i'm going to have to take a break from monero for a few weeks while i get this medical stuff figured out. importantly: i'm not stopping work. I just don't know how much time i can actually contribute practically.
<sarang> Oof, sorry to hear this. I hope everything goes well for you suraeNoether
<ArticMine> sorry to hear this. I hope all goes well
<suraeNoether> secondly: my research into matching is a hydra where fixing one bug is revealing handfuls of more bugs, and i'm getting super frustrated with it. this is particularly important work for a few reasons, but for right now i don't anticipate movement any time soon. one of the reasons that this has become so frustrating to me is that certain threats to monero that are going to become more likely over the
<suraeNoether> next several years to be presenting themselves that make the answers that lie within this work *lower priority* than other things. i mean this very specifically in the following sense
<suraeNoether> everyone should know that our anonymity reduces to something like the one-more decisional diffie hellman problem, and our unforgeability reduces to something like one-more discrete logarithm
<suraeNoether> both of these are known to not be hard for quantum adversaries, and while quantum computers are not yet practical...
<suraeNoether> it doesn't matter what ring size we use if china goes "manhattan project" on quantum computers and turns their resulting computing power on de-anonymizing privacy coins in secret.
<suraeNoether> my work on matching would give us answers to questions like "how large should ring sizes be *assuming the underlying problem that our anonymity rests upon is hard to solve*" but we know that this problem is only going to be hard over the short term
<sarang> FWIW such a "quantum adversary" could wreak havoc on basically the entire global internet
<suraeNoether> indeed ^ but that's in fact exactly all the more reason to become resistant to a quantum adversary sooner rather than later
<UkoeHB_> How realistic is a quantum adversary?
<ArticMine> ^ I agree
<suraeNoether> if it takes 3 years to migrate to a quantum-secure system, and we hope something like clsag or triptych has a 3 year shelf life, then we should be looking at what will be practical 6 years from now
<sarang> In the shorter term, understanding the effects of ring size on matching-type analysis is useful for knowing how large to make ring size for a next-gen protocol
<Isthmus> Uhm
<Isthmus> Would an adversary with a quantum computer break ring signatures or just decrypt the transactions?
<suraeNoether> both: they can compute the discrete log of every one-time key and then they just own all of monero
<Isthmus> Yeah, I'd just do that.
<suraeNoether> yeah
<suraeNoether> so like
<sarang> Once you have key discrete logs, you can check key images
<suraeNoether> matching: important. investigating quantum-secure schemes: higher priority, even over a relatively short 3-year term
<suraeNoether> so every time i kill a bug in my matching code, i become more painfully aware: i'm fighting the wrong hydra
<sarang> I still think it's very valuable
<Isthmus> Yeah, we've been doing some quantum vs crypto experiments at Insight lately
<suraeNoether> long story short, i'm prsently working on a summary-of-knowledge of quantum-resistant RingCT-type protocols, 3 of which have been proposed in the past 3 years
<sarang> Otherwise, "bigger rings are better" is a qualitative statement
<suraeNoether> just for community education reasons
<suraeNoether> sarang: absolutely agreed
<sarang> My recent work on Triptych-2 and chain simulations shows, as expected, that ring size has a large effect on verification complexity
<UkoeHB_> Can you also evaluate how realistic a quantum adversary is? I recall general skepticism of them ever materializing
<sarang> So choosing the smallest rings that do the job is important
<suraeNoether> UkoeHB_: yeah, so basically here's a qualitative answer to that question
<Isthmus> We're already working on 5 [actual] qbits
<Isthmus> (Insight working on IBM equipment)
<Isthmus> Expecting this to scale in the next few years
<suraeNoether> you may recall the sensationalist headlines a few months ago: https://www.eurekalert.org/pub\_releases/2020-02/aps-teo022720.php
<suraeNoether> quantum supremacy is probably a bad term but
<suraeNoether> before these researchers did what they did, the *fastest way to figure out what a quantum computer can do* would be to *simulate it on a classical computer*
<sarang> Quantum supremacy is a poor metric for usefulness IMO
<sarang> Such problems are typically highly contrived
<suraeNoether> because of these guys' work, that is no longer the case: there now exist quantum computers that cannot be simulated more quickly than they can operate. this is a critical benchmark for scaling quantum
<Isthmus> @surae should I just loop in my quantum/crypto engineer for a few weeks, so you can focus on the matching hydra?
<Isthmus> They're already looking into the schemes, and would probably be happy to work on Monero
<suraeNoether> google's bristlecone has 72 qubits running
<suraeNoether> isthmus: let's set up a call for later this week
<vtnerd> well I have to say it ... quantum computers are BS, they just spin hyperbole but go nowhere. There was a discussion about this on metzdowd
<Isthmus> Given retroactive denonymization doesn't really matter if they're 5 or 15 years off, we gotta hustle to protect Monero users in 2020
<suraeNoether> do you mean like computers based on quantum principles will never work, vtnerd? can you clarify?
<suraeNoether> isthmus ^ bingo
<vtnerd> someone discussed the progress made on metzdowd. Its been very little over 25+ years
<vtnerd> the researchers have alwasy been just on the edge of making it a reality
<suraeNoether> okay well
<suraeNoether> the researchers into QC i've spoken with disagree
<suraeNoether> and that's an appeal to authority
<vtnerd> admitedly this isn't my expertise, but theres time tradeoffs investigating these QC resitistent systems
<suraeNoether> but i think it's absolutely silly to say that very little progress has occurred over 25 years, and it's even sillier to assume that no progress will be made ala cold fusion, and i think it's even sillier to propose that we, say, avoid quantum-secure implementations rather than looking into the costs and benefits and time horizons of implementing them
<vtnerd> and the one thing thats bizarre, is when someone builds a QC system, we basically ahve to reboot on general purpose computing projects, no? Like one year out are they even cracking crypto?
<suraeNoether> well, i don't want to take more time on this: my update is that i have to step back from monero for awhile, and i'm looking into RLWE-based ring signatures
<Isthmus> Y'all know the tech cycle. Many-year winters leads to the most exciting explosions. AI, crypto, quantum... the pattern repeats
<suraeNoether> i'll still be presenting at meetings and coming by and stuff
<suraeNoether> for folks who are interested, the wikipedia article on the timeline of quantum computing has lots of good info
<sarang> OK thanks suraeNoether
<sarang> I have a few things to share
<sarang> First, CLSAG
<sarang> I've completed review of suraeNoether's security model updates
<sarang> suraeNoether: I've left several Overleaf review comments for you
<sarang> Along with that, I migrated some recent CLSAG verification optimization code to moneromooo's branch, along with relevant unit and performance tests
<sarang> Saves about 5% on verification, which seemed worth it
<sarang> Relating to Triptych: I made a minor update to the original Triptych-1 preprint for readability, but also completed the Triptych-2 preprint
<sarang> Here is a link to the Triptych-2 preprint on Overleaf: https://www.overleaf.com/read/ynfkhykjfvrd
<sarang> I'd appreciate any review on it prior to posting to the IACR archive
<sarang> Unrelated to these, I've been catching up with literature review
<sarang> and, as a program committee member for the IEEE S&B conference, I'm reviewing submissions
<suraeNoether> i'll take a look at your comments and read through triptych 2: electric bugaloo
<sarang> Thanks suraeNoether
<sarang> IMO the CLSAG review is top priority
<selsta> Did you contact Teserakt?
<sarang> I'd like to wait on confirming a schedule until we have this paper done
<sarang> Otherwise we risk losing the availability again due to delays
<sarang> Anyone who wants to review the CLSAG optimizations can see this branch: https://github.com/SarangNoether/monero/commits/clsag-mooo
<sarang> Finally, my funding proposal needs feedback on GitLab before it's decided whether to open it: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/131
<sarang> That's all for me today
<sarang> Does anyone else wish to present, or have questions?
<suraeNoether> i propose that we fund sarang
<suraeNoether> but no
<suraeNoether> no questions
<Isthmus> I propose that we fund surae
<sarang> Heh, then leave a reaction or comment on gitlab!
<Isthmus> I've been wrestling with a weird conundrum
<sarang> Go on
<Isthmus> I'm thinking about modifying my wallet to only select decoys from transactions generated by the core wallet
<Isthmus> But then that in and of itself becomes a subtle heuristic
<sarang> Ah, so using fingerprinting to pick the most "standard" decoys?
<Isthmus> Not "most"
<Isthmus> Something either looks like the core wallet, or provably isn't
<sarang> Heh, yeah, it kicks the fingerprinting can slightly down the road
<Isthmus> I guess if almost everybody used only outputs generated by the core wallet, then it wouldn't be a heuristic to fingerprint me
<Isthmus> *outputs that cannot be proven to have not originated from the core wallet
<Isthmus> ^ to be very specific
<sarang> got it
<Isthmus> Eh, I dunno. Don't really have a solution. It was just funny that I worked on it for a it before realizing that it becomes its own heuristic xD
<Isthmus> Anyways, nothing much from me. I've had about 20 minutes per week for Monero lately
<Isthmus> But in May, we're gonna have some long talks and clean house
<sarang> ?
<Isthmus> Have 7 heuristics that have now partitioned out upwards of 20 different implementations.
<Isthmus> Most of which I've shared in MRL already
<UkoeHB_> 20 sounds like a lot
<UkoeHB_> monero is really doing well if there are 20
<Isthmus> That's unfiltered for time.
<Isthmus> Going to clean it to recent blocks and see what's in the wild *now*
<sarang> So some might be updates to the same implementations?
<Isthmus> It's at least 3 right now,
<Isthmus> Yeah, that's why I'm not really sweating the 20
<Isthmus> I think it's 3-5 in current era
<Isthmus> Which is pleasantly(?) surprising
<Isthmus> But yea, with absolutely no time to work on it now, hard to put together a full writeup
<Isthmus> But will definitely circle back in the next 2 months
<sarang> Sounds good!
<sarang> Anyone else wish to share any research?
<UkoeHB_> hi, ztm2 proofreading draft is updated (with feedback from sarang about bulletproofs, and also the clawback formula regarding tx weights) https://www.pdf-archive.com/2020/03/11/zerotomoneromaster-v1-1-1/zerotomoneromaster-v1-1-1.pdf
<UkoeHB_> 2 more weeks for proofreading
<sarang> Good feedback so far overall?
<UkoeHB_> also, looked into next-gen tx key image generation for multisig (sarang has a solution for it), and it seems like inversion key images wont greatly disrupt multisig transaction flows (especially escrowed markets, which is a big deal)
<UkoeHB_> Not much feedback so far
<UkoeHB_> But it's 152 pages so not surprising
<UkoeHB_> that's all from me
<sarang> OK, let's move on to ACTION ITEMS for the next week or so
<sarang> I'll await final word on my CLSAG review notes
<UkoeHB_> wondering if ArticMine has progress on fees
<sarang> Continue working on Triptych
<Isthmus> Why did it switch from 02 to 20?
<Isthmus> oops
<ArticMine> Yes I do
<Isthmus> ignore that
<sarang> Go ahead ArticMine!
<ArticMine> I am looking at making the penalty free one also dynamic and using the long term median to control it
<ArticMine> Also slowing down the fall in the long term median to match the constraint on the rise
<sgp_> just got caught up
<ArticMine> So it does not go from say 3000000 bytes 300000 bytes in one shot
<ArticMine> The new dynamic penalty free one would track the long term median at say 20 - 25% of the long term median
<Isthmus> Ooh interesting
<ArticMine> This will provide predictable fee over time
<sarang> Will you have a specific proposal for this, intended for a network upgrade?
<ArticMine> The models I am looking at is a sharp drop, followed by a fiat banking crisis that creates a very sharp rise
<ArticMine> Yes
<sarang> OK, any final thoughts or topics before we wrap up this hour?
<suraeNoether> be kind to each other
<suraeNoether> just be excellent
<suraeNoether> you animals
<sarang> All right, thanks to everyone for attending. Adjourned!

Release 0.15.0.4 of Monero GUI

Thu, 05 Mar 2020 00:00:00 GMT

Overview

This is the v0.15.0.4 release of the Monero GUI software. This release contains UI changes, bug fixes and improvements to the user experience.

Changelog

The major changes introduced with this release are:

Various small UI improvements
New sidebar menu design
New blur background effect
New langauge: Norwegian
macOS: .app now displays version
Bug fixes and performance improvements
Crash fixes

Note that you can find a full changelog on GitHub, including a list of contributors.

Download Links

You can also compile it from source by yourself. See the instructions on GitHub

Verify Hashes

monero-gui-win-x64-v0.15.0.4.zip, 9b61fa807c66ebe3010869d1fa926fe033a2c82e6e660ca8acb75a8fba0248a0
monero-gui-install-win-x64-v0.15.0.4.exe, 874ebbfcf79d09c60e2d85d09e5b8b971066c6355dfc2a5eca6d109d32e45ddb
monero-gui-mac-x64-v0.15.0.4.tar.bz2, 9b0164cd90345c5fd4014a6bc8258465c2e5aae7c527c7f64a2d795830db7ae4
monero-gui-linux-x64-v0.15.0.4.tar.bz2, 2d105c792b46ec03739d39aaa6db3801f268e074814ab26e3824435f954c6a1c

Logs for the MRL Meeting Held on 2020-03-04

Wed, 04 Mar 2020 00:00:00 GMT

Logs

<sarang> Let's start the meeting!
<sarang> First, GREETINGS
<sarang> hello
<sgp_> hi
<sgp_> [meta] I added the MRL meetings with reminders to the Google Calendar I have if you are ok using Google: https://calendar.google.com/calendar/embed?src=itmaraubkfoe4aq2oquoaogsuk%40group.calendar.google.com&ctz=UTC
<sarang> Does using that link leak any information to you? (presumably it leaks IP information to Google)
<sgp_> not to me, just Google
<sarang> roger
<sarang> OK, continuing on
<sarang> Next up is the ROUNDTABLE
<UkoeHB_> hi
<sarang> I've been getting the multi-input version of Triptych updated for posting to the IACR preprint archive
<sarang> as well as minor edits to the original preprint as I come across them
<sarang> Posting to IACR (with suitable caveats about non-standard cryptographic hardness assumptions) can increase the visibility of the idea, and hopefully encourage feedback
<sarang> It's pretty slow going, but progressing well
<sarang> Any particular questions on that before I pass the baton?
<sarang> OK, next up!
<sarang> Does anyone else have research of interest to share and discuss?
<Isthmus> Yo
<sarang> Hello Isthmus
<sarang> Did you wish to share anything, or just observing?
<Isthmus> I’ve been pretty busy in meatspace, sadly no time for data spelunking
<sarang> OK, no problem! Simply checking
<sarang> It's a fairly quiet day today anyway
<sarang> UkoeHB_?
<sarang> suraeNoether?
<sarang> Others?
<Isthmus> Oh yes, actually
<sarang> ah ok
<sarang> carry on Isthmus
<Isthmus> Wait there’s too much traffic for voiced text, let me look back pewter in four minutes
<sarang> roger
<sarang> Someone else, then?
<UkoeHB_> need about 10mins
<sarang> OK, in that case, let's pause the meeting for 10 minutes or so; I show the time is 18:12, so let's reconvene at 18:22 or so
<sgp_> sarang: want to talk about Triptych naming at some point?
<sarang> That seems like a suitably off-topic idea during this break =p
<sarang> Right now, the multi-input Triptych preprint uses the name "Triptych-2"
<sarang> this is boring and not descriptive
<sarang> I am open to better naming ideas
<sarang> Note that I can revise the older paper if that's helpful (this has been done to add features and fix errors)
<hyc> what part of the original "triptych" is triple?
<sarang> The benefits of Triptych-2 are using a single proof for all spends (instead of separate proofs with commitment offsets), and handling balance assertions directly within the proof
<sgp_> I originally recommended Triptyzk as a half joke, but part of me thinks it's a good idea
<hyc> Polyptych
<sarang> The idea was that the three parts to Triptych are signing keys, commitment keys, and linking tags
<sarang> Heh, a polyptic sounds like something a surgeon would remove :/
<UkoeHB_> lmao
<sarang> FWIW there's basically no change to the SHVZK property or proof between the two versions
<sarang> They're almost identical
<sgp_> that's partially why adding "zk" now makes no sense. It's more about proactively naming for the Twitter trolls/idiots
<UkoeHB_> B-Triptych and E-Triptych for basic and extended
<sarang> Triptych Classic and New Triptych
<hyc> Triptych and Antikythera :P
<sarang> Just what we need; something equally hard to pronounce =p
<moneromooo> Technology so old nobody remembers how it works.
<hyc> yes... and indecipherable, and considered too advanced for its time
<kinghat> i havent been paying that close attention but have we "shelved" CLSAG?
<sarang> suraeNoether just told me he's now happy with the revised security model for CLSAG
<sarang> Nothing has changed with the algorithms themselves, apart from a small change to hash function inputs
<UkoeHB_> it sounded like suraeNoether was considering advocating to skip CLSAG and go directly to next-gen in a year or two
<sarang> I disagree
<sarang> CLSAG is a straightforward change that's well understood
<kinghat>
<sarang> Anyway, he made very recent updates that I'll review (more on this during ACTION ITEMS) for IACR posting
<sarang> Anyway
<sarang> UkoeHB_ and Isthmus both wanted to share some work
<selsta> Will CSLAG require a paid review?
<sarang> Nothing "requires" paid review
<selsta> for you to be comfortable with it
<sarang> But it's probably a good idea :)
<sarang> I'm very comfortable with the math
<Isthmus> Hm, upon more consideration, discussing it today might be the wrong order of operations
<Isthmus> Nothing pressing or dangerous
<sarang> The total estimate for math+code review by Teserakt was ~$15000 USD, which is quite reasonable IMO
<sarang> Isthmus: how so?
<sarang> Now you have everyone intrigued
<UkoeHB_> happy to announce a final proofreading draft of ZtM2 is ready. Note that I decided not to go into Bulletproofs since it's frankly way too much detailed math to be worth it. Anyone who wants to learn bulletproofs should just read the original paper. https://www.pdf-archive.com/2020/03/04/zerotomoneromaster-v1-1-0/zerotomoneromaster-v1-1-0.pdf
<Isthmus> A poorly-framed thought experiment is worse than no thought experiment at all
<sarang> UkoeHB_: great!
<sarang> Will this be renamed to 2.0 after review?
<sarang> Or will the title be incremented to "One to Monero" :D:D:D
<UkoeHB_> Ill make a reddit post asking for proofreaders, and if anyone knows someone who wants to proofread go ahead and pass it around. Not much is likely to change between now and publication in ~1.5-2months. The proofreading period is 3 weeks.
<UkoeHB_> I think Ill just remove the version number
<UkoeHB_> maybe
<midipoet> UkoeHB_: fair play
<sarang> Name them based on the most recent Monero version name?
<sarang> Anyway, great to hear the update is nearing completion
<hyc> Zero to Monero, Hero Edition
<UkoeHB_> yes I want to meet the hero who reads the whole thing :)
<hyc> the more -ero suffixes in the title, the better :P
<sarang> Does anyone else wish to share research of interest?
<sarang> OK, we can move on to ACTION ITEMS, then
<sarang> I am completing the Triptych-2/NewTriptych/E-Triptych/etc. preprint for IACR posting
<sarang> and reviewing the (hopefully final) changes to CLSAG that I received from suraeNoether
<sarang> Anyone else?
<UkoeHB_> proofreading, and listening to proofreader feedback if and when it appears; starting now will probably spend a lot less time with Monero as this project wraps up
<sarang> I think a reddit post is a great idea to encourage readers to take a look
<sarang> ZtM is such a valuable resource
<sarang> Short meeting today! But that's fine
<sarang> Any other questions, comments, etc. as we wrap up?
<sarang> All right! Let's adjourn
<sarang> Thanks to everyone for attending
<sarang> Logs will be posted shortly to the GitHub issue

Logs for the Community Meeting Held on 2020-02-29

Sat, 29 Feb 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<needmonero90> Sarang suraeNoether
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<monerobux> asymptotically: meeting time! :o
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/442
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<rottensox> hi fam!
<sarang> Hi
<needmonero90> Isthmus M5M400
<suraeNoether> Howdy
<needmonero90> Hello!
<M5M400> oh a ping. thx
<rehrar> I'm here
<sgp_> reminder that until the Monero Outreach calendar is finished, you can add this one (Google, eww): https://calendar.google.com/calendar/embed?src=itmaraubkfoe4aq2oquoaogsuk%40group.calendar.google.com&ctz=UTC
<sgp_> it has default reminders
<sgp_> thanks everyone for being here!
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> We should play a game later today. Conversation after the meeting.
<sgp_> I’m soft announcing our new home! https://communityworkgroup.org. We can use this page to more easily organize Monero Community Workgroup resources going forward. If we have time during open ideas, I’d love to hear your ideas! Putting this aside otherwise for now.
<sgp_> I published most of the 36c3 videos to YouTube a few hours/seconds ago! Surprise! I’ll spend time after the meeting organizing them and uploading a few stragglers: https://www.youtube.com/playlist?list=PLsSYUeVwrHBn07zTBg7fGHRW5Kn_Z3FJL
<monerobux> [ Chaos Communication Congress 2019 - YouTube ] - www.youtube.com
<sgp_> You can share individual videos, but I don’t recommend sharing the playlist yet. It’s too ugly and disorganized currently.
<Mochi101> I seen they were coming out sgp_ - very nice!
<sgp_> 244 GB up and down yesterday, my ISP loves me :)
<sgp_> Does anyone have community (non-workgroup) updates to share?
<Mochi101> I quite my job?
<Mochi101> quit
<Mochi101> Oh, Monero related... sorry.
<M5M400> congrats anyway
<cankerwort> Hello community
<sgp_> haha I probably should specify, but congrats!
<asymptotically> i'm developing a new open source pool software, it doesn't really have any shiny cool features but maybe it will be nice for people to have a new choice :D
<Mochi101> Seriously asymptotically ?
<Mochi101> Awesome!
<M5M400> asymptotically: nice. can you also create a miner that is NOT xmrig or stak?
<cankerwort> With decentralising features like what jtgrassie made?
<Mochi101> M5M400, RagerX ?
<cankerwort> Whatever that was called
<asymptotically> stratum-ss? i was looking into that but it doesn't support it yet
<needmonero90> what about the GUI?
<needmonero90> GUI has a miner.
<asymptotically> i thought it just used the daemon one
<cankerwort> Apparently most of the pool operators haven't got a clue how to implement it, so if it was plug and play it would do a lot of good
<needmonero90> isnt that a miner that isnt rig or stak?
<cankerwort> Especially with all that FUD about 2 pools dominating a little while back
<M5M400> needmonero90: probably, but an independent one would be nice
<cankerwort> I don't think the gui miner supports pools at all, iirc
<rottensox> sgp_: fifth paragraph here, think has as minor typo... https://www.communityworkgroup.org/about '... This channel hosts the Monero Konferenco, Critical Decentralization Cluster as the Chaos Communication Congress' shouldn't it be at, not as? 'at the Chaos Communication Congress.'
<sgp_> rottensox: yes
<sgp_> I'll also change all "Decentralization" -> "Decentralisation"
<sgp_> thanks for brining that up asymptotically
<sgp_> Any other updates?
<sgp_> Monero-related :)
<cankerwort> Isn't that a US/UK spelling thing?
<rottensox> it is. :-D
<sgp_> cankerwort yes but the organizers use the s
<rehrar> No, we need the z
<cankerwort> Fair enough
<sgp_> rehrar: lol
<sgp_> internal war here
<cankerwort> Or we can fight over it
<sgp_> We have a lot of CCS updates to get through, so for the interest of time, there's a small rule change.
<sgp_> Please comment if you have a workgroup report by messaging “Workgroup Update: [workgroup name]” any time before part 4 of the meeting, or else your workgroup section may be skipped.
<Mochi101> You two can start a reddit thread and fight over it there
<cankerwort> Yes everything seems to be fully funded
<sgp_> 3. CCS updates
<sgp_> Funding required:
<sgp_> All proposals in funding required are fully-funded!
<sgp_> Ideas (to be discussed):
<Mochi101> wow
* sgp_ clears throat
<sgp_> A Monero-centric Merchant Marketplace (70 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/117
<sgp_> we discussed this one a while back, but I don't think we've had a recent conversation
<nioc> please move SerHack 's request to funding required
<sgp_> .....anyone have anything to say about this marketplace proposal?
<asymptotically> i think its a good idea, but i think a better community solution would be a self-hosted open source thingy you can just set up with one command and you get your own store
<Mochi101> oh wow
<cankerwort> So it's like Monero flavoured Shopify?
<Mochi101> That'd be awesome
<rottensox> UkoeHB_ was crossing roads with this idea when working on multisig for ZtM v2 and the recent rbrunner7 idea of having a XMR-like OpenBazaar alternative.
<asymptotically> like how you can use monero-integrations with some wordpress things, and you control everything yourself. but it's probably not the easiest thing to get going
<endogenic> i suggest making the proposal more concrete
<Mochi101> Monero-Integrations is very easy... The only thing that may be hard for a new person is the view only wallet.
<endogenic> seems kinda vague
<cankerwort> Open source and self-hosted would be nice, but people are lazy and would like to pay a third party to do all the work for them (hence shopify)
<rehrar> all code developed is open source, right?
<rehrar> meaning anyone would be able to deploy this shopify
<rottensox> no. lol.
<asymptotically> Mochi101: but you have to manage wordpress and other tear inducing things
<rehrar> I mean for this marketplace
<cankerwort> That's the important question
<sgp_> well it's a non-starter if it's not, so maybe we need to clarify that first
<sgp_> can someone comment asking that?
<cankerwort> If the dude publishes the code so people cam do it themselves, but also starts a business managing and doing all the work for those that want that that would be ideal
<cankerwort> That way continued work could be sustained (maybe)
<rottensox> lza_menace lzamenace[m] was that you or that's someone else's proposal?
<sgp_> @lalanza808 on gitlab
<sgp_> anyway, I think we can move on since there are outstanding questions
<sgp_> Mining outreach, Ministo (40 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/124
<Mochi101> no
<lza_menace[m]> Yes
<sgp_> lza_menace[m]: can you confirm if your marketplace code will all be open-source
<rehrar> I don't care about this one either way.
<Mochi101> I don't like that proposal.
<asymptotically> .seen ministo
<monerobux> asymptotically: I last saw ministo at 2018-05-15 - 22:42:21 in another channel.
<nioc> contact data centers and suggest that they mine/
<nioc> ?
<cankerwort> No
<Mochi101> yeah nioc
<sgp_> I think the mining one is way too expensive for a start
<rottensox> against.
<asymptotically> maybe it would be better if he partnered with a pool or something
<cankerwort> I don't think this even needs outreach tbh
<sgp_> asymptotically: that's a decent idea, pool provides referral fee or something
<sgp_> I also think 99% of the responses will be "no"
<lza_menace[m]> sgp: yes, the code would all be open sourced. The goal would be to setup a foundation for a web shop that anybody could spin up and run their own. If people wanted to run a legitimate business doing it, they would have the tools to do so
<rehrar> Let's take a step back and continue on the marketplace discussion since we got answers. We need to make a recommendation to core. It's about time.
<cankerwort> I like the sound of that a lot
<sgp_> sure rehrar
<rehrar> since this went up a month ago, the price has changed? would that need to be edited lza_menace[m] ?
<rehrar> if so, to what?
<lza_menace[m]> I’m fine to leave it
<sgp_> the monero is currently worth about $4,800
<rehrar> meh, I'm down for it.
<sgp_> I think in any case, lzamenace[m] will need to make another round of marketing since it's been a while
<lza_menace[m]> I normally do $100/hour for consulting gigs, but this will likely take more than 48 hours. I’m okay to eat some of that though
<lza_menace[m]> Ok, I can do another reddit post
<needmonero90> Monero people generally dont charge market price for their services
<sgp_> $100/hr is very high for a fun side project someone can work on at their own schedule. Same with even $50 frankly
<rehrar> let's get a bit more feedback from the reddit post, but overall I see this as fine.
<sgp_> okay, anything else before I move to the next one rehrar?
<lza_menace[m]> sgp: this will likely be way more than 48 hours is what I’m saying. It will end up being much less than my going rate because it is a fun side project.
<rehrar> no, mov eon
<lza_menace[m]> You guys missed the point of me saying that
<sgp_> lza_menace[m]: got it, thanks
<sgp_> let's finish up the mining outreach one
<sgp_> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/124
<sgp_> most people thought it wasn't worth supporting, correct?
<rehrar> it seems most present are fairly negative towards it
<sgp_> unless this person is a sales genius with good existing connections, I can't see how this is valuable
<sgp_> and even then, there are other ways to go about it
<sgp_> next one
<sgp_> Monero Integrations part 3, serhack (10 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/125
<sgp_> move?
<nioc> Y
<sgp_> anyone against?
<rehrar> ye
<SerHack> Hey guys! I have edited the price, asking for 11 xmr instead of 10. Does anyone have problem with that?
<sgp_> rehrar: is that a serious comment?
<Mochi101> I love Monero-Integrations
<suraeNoether> No problem with price change
<rehrar> oh, it wasn't a ye to what you said
<rehrar> it was an answer to "move?"
<ajs> no problem, support SerHack 100%
<sgp_> ah, got it :)
<SerHack> I have to pay taxes but this week I'll be focused on Monero Integrations since lessons are suspended here!
<sgp_> eww, I thought that was mostly a US problem lol
<SerHack> Oh, cool! Thanks for supporting me!
<sgp_> rehrar: pass along strong support (as expected)
<rehrar> will do
<sgp_> SerHack: did you update the price on there for 11 yet?
<SerHack> If anyone has any additional question, don't be shy to ask!
<SerHack> sgp_ I think yes
<sgp_> ok, next one then
<sgp_> Add new file (payment integration), pricode (30 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/126
<sgp_> here's another similar proposal
<sgp_> the details are quite light imo
<SerHack> As I reported on Gitlab, this CCS request has been created three minutes after I've created mine. It looked suspicious
<rottensox> seems like a no? it was initially closed and commented by rehrar. rather sketchy they open it up again, not following format even...
<rehrar> lol!
<rehrar> I mean, this payment gateway he is proposing seems to be different than Monero Integrations
<rehrar> if he says "image (sic) stripe" which is a cross-platform dealio
<rehrar> I think a "stripe" of Monero would be cool, but given his inability to format the proposal correctly (When instructions are easily available and simple to follow) doesn't give me high confidence in his ability to actually make it.
<asymptotically> you mean i cant just ctrl+s the stripe webpage and edit it?
<needmonero90> shouldnt we let the donors decide that??1?!one!?
<sgp_> any final comments on this one, or close for not enough info?
<needmonero90> close.
<rehrar> I will comment on this proposal and let him know it's improperly formatted and ask him to attend the next community meeting where he might share some of his expertise and/or credentials.
<sgp_> ok, next (skipping a bit)
<sgp_> Norwegian translation of webplate + footers + nav. Menu, Chris Avis (6 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/129
<sgp_> anyone for or against? speak up!
<Mochi101> for
<rehrar> sure
<sgp_> ok, next
<sgp_> 2 more
<sgp_> Monero Debian Package Repository for 2 years, Patrick Schleizer (60 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/130
<sgp_> Whonix founder wants these funds to make a debian package repo
<rehrar> People have talked about a Debian repository for a long time, and this seems like the guy to do it. Ready, willing, and capable.
<rehrar> Solidifies good relationship with Whonix peeps too. They like us.
<sgp_> Is the amount fair? I have no clue tbh
<sgp_> 2000 for a week?
<rehrar> I too have no idea what goes into packaging.
<sgp_> he refers to the bitcoin AppImage boing added; how is that process similar?
<sgp_> *being
<sgp_> and did someone pay for this
<rehrar> I particularly like that it's not hosted on getmonero infra though. :D
<rehrar> the problem with hosting external packages is that it has to come from an trusted external source. I can't think of more trusted names in privacy than Whonix.
<sgp_> I'd like to see some knowledgeable people comment and ask questions before this is moved
<rehrar> What do you mean did someone pay for this?
<sgp_> did someone pay for the bitcoin debian package? or is that not comparable? I don't know
<sgp_> anyway, we can keep moving
<sgp_> last CCS idea
<sgp_> [Monero Aligned] Proposal for 1M5 Integration as Proxy, Brian Taylor (150 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/127
<sgp_> ErCiccione added some comments suggesting they felt the proposal needed work
<sgp_> this was first pitched to Bisq
<sgp_> (who couldn't pay)
<sgp_> the main milestone seems to be "Implement 1M5 API to support Monero transactions and document"
<nioc> he came into -dev recently and explained himself
<sgp_> nioc: cool, can you paste the relevant logs in the repo?
<selsta> I’m against the proposal at the current stage.
<nioc> sgp_: I might be able to, dunno
<rehrar> so...in comes all of the [Monero Aligned] proposals then?
<sgp_> it also looks like many things on their website are proposed/in development.
<rehrar> though this one directly relates to Monero more, it seems.
<rehrar> what was the consensus in -dev?
<nioc> there was a conversation but the proposal was not updated
<rehrar> ok, but what was discussed in this conversation? :P at very least can we have a date of the logs so I Can look myself?
<selsta> It makes no sense to implement 1M5 at this stage.
<rehrar> it seems we can table this one for now.
<nioc> rehrar: will have to look
<sgp_> selsta: good point that in general this could be putting the cart well before the horse
<sgp_> anyway, done with CCS stuff
<sgp_> not a single person said they wanted to give a workgroup update, so we can skkip over the entire section 4
<selsta> I can give short GUI update
<sgp_> sure selsta
<selsta> we will tag v0.15.0.4 today and Snipa has his build environment ready
<selsta> so new release soon
<nioc> rehrar: Feb 24 name is objectorange
* needmonero90 gets food and will be on sporadically for the rest of the meeting
<M5M400> yaaaay new gui
<selsta> also we will probably release CLI/GUI v0.15.1.0 in March
<needmonero90> wait, we have GUI now?
<rehrar> thank you nioc
<selsta> with Dandelion if it gets reviewed in time
<sgp_> ooooh
<rehrar> selsta: maybe just push the tag back a bit then to get Dandelion in?
<rehrar> or is there some big bug fixes or something? what's the urgency before D++?
<selsta> HackerOne disclosures
<rehrar> ah, gotcha
<selsta> will see how to do it best
<sgp_> monero gui as unsafe as iota trinity wallet confirmed
* selsta afk again
<nioc> rehrar: also some brief comments on the 26th
<sgp_> sarang you had something too?
<sarang> Just a very brief update... worked on some code updates for CLSAG efficiency, hash function stuff, and transaction proofs
<sarang> Nothing too exciting :)
<suraeNoether> oh gosh
<suraeNoether> I wanted to mention
<suraeNoether> There's a creative inquiry program at a couple of universities where projects like ours can propose a project for undergraduates to work on over a semester. no cost to us, as long as we get faculty members to sponsor the projects and we can meet with the students weekly
<suraeNoether> Deadline for Fall 2020 is March 25, and I wanted to bring it up but it's certainly not urgent
<suraeNoether> I'm working on a proposal with a faculty member at Clemson to get a couple of unpaid interns.
<suraeNoether> re-emphasize: no cost to us
<sgp_> suraeNoether: I'm happy to help here however needed
<suraeNoether> if folks have ideas for simple coding or math projects that can be done by newbies in 12-16 weeks, I'm starting a list
<Mochi101> #MathIsFun
<sgp_> cool
<sgp_> I'm going to wrap up, but open ideas time is every time :)
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 14 March at 17:00 UTC.
<sgp_> The next Coffee Chat is next week on 7 March at 17:00 UTC.
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2020-02-26

Wed, 26 Feb 2020 00:00:00 GMT

Logs

<sarang> Hello all, and welcome to the weekly research meeting
<sarang> First, GREETINGS
<sarang> Hi
<UkoeHB_> hi
<ArticMine> hi
<sarang> *others
<cankerwort> Peanut gallery quickly checking in to ask what the latest is on return addresses. Last I remember there was an idea to include a subaddress in the tx as a return address. Is that still being being considered?
<sarang> It's always possible to include in tx_extra, which is not consensus
<sarang> and there was a space-minimizing proposal as well
<sarang> AFAIK no one has coded such a thing yet
<sarang> As always, there's a consideration of how optional behavior is bad for indistinguishability
<sarang> Let's go ahead and start the ROUNDTABLE
<sarang> Does anyone have research topics of interest to share?
<sarang> I'll go ahead, then
<sarang> First, the Stanford Blockchain Conference was held this past week
<sarang> Here is a link to the schedule and recordings of talks for each day: https://cbr.stanford.edu/sbc20/
<sarang> Second, a small PR on hash function domain separation was updated, and could always use extra eyes for review: https://github.com/monero-project/monero/pull/6338
<sarang> Third, I made some updates to the structure of CLSAG signature verification code... by reducing the modularity of the signature verification routine to specifically include some commitment offsets, I was able to shave about 5% off the verification time
<sarang> See this branch for details: https://github.com/SarangNoether/monero/tree/clsag-optimized
<Isthmus> Any particular talks that you recommend from SBC?n
<sgp_> hello everyone, catching up on the chat so far
<sarang> Florian's talk about Monero and Zcash side-channel analysis on Wednesday's stream is very good
<sarang> All of session 4 on Wednesday is interesting
<sarang> As is session 5 on Thursday
<sarang> Fourth, I worked on similar improvements for MLSAG... however, this is trickier, since verification requires particular byte-representation hash inputs for backwards compatibility
<sarang> The results for that aren't great: https://github.com/SarangNoether/monero/tree/mlsag-optimized
<Isthmus> Ah I loved that paper
<sarang> Yeah, kudos to Florian and collaborators for great work and responsible disclosure
<sarang> Finally, another researcher contacted me with an idea for atomic swaps that might remove the need for a SHA-256 preimage proof
<sarang> We're still working out the details, but it's an intriguing idea for which the necessary building blocks already exist
<sarang> More information as we work on it!
<UkoeHB_> interesting, haven't heard from atoc in a while who was looking into that
<sarang> Yeah... I don't want to provide more information until the researcher and I have discussed it (as a courtesy to them)
<sarang> sorry
<Isthmus> Respecting privacy is good ;- )
<sarang> Anyway, those are my updates! Mostly code updates and testing
<sarang> Does anyone else wish to share research of interest?
<UkoeHB_> thanks to sarang 's initial draft, tx knowledge proofs chapter is done (wip tag is off) for ztm2
<UkoeHB_> https://www.pdf-archive.com/2020/02/26/zerotomoneromaster-v1-0-30/zerotomoneromaster-v1-0-30.pdf
<UkoeHB_> chapter 9
<Isthmus> Nice!
<Isthmus> "An Axiomatic Approach to Block Rewards" https://arxiv.org/pdf/1909.10645.pdf
<UkoeHB_> sgp_ may be interested in section 9.3 for audits
<UkoeHB_> reader beware various things arent implemented and are just theoretical
<sarang> Yeah, the idea for a general audit framework is super interesting to me
<sarang> and could be useful to reduce confusion about what proof types provide what information
<sarang> Right now, it's sort of ad-hoc
<cankerwort> ZtoM will contain unimplemented features and ideas from the roadmap?
<sarang> Isthmus: that paper is on my literature review list!
<UkoeHB_> also made some updates/fixes to minimum fee change idea https://github.com/monero-project/research-lab/issues/70 @ArticMine
<sgp_> thanks for sharing! I will see if I can get feedback on it
<UkoeHB_> cankerwort part 2 'extensions' contains unimplemented features; saying they are roadmap is quite ambitious
<sarang> One thing to note about the audit idea from UkoeHB_ is that it requires proofs applying to _all_ transactions for which a given output appears in rings
<sarang> which I suspect may require substantial engineering effort (as a guess)
<UkoeHB_> also proofs for every single tx in the chain
<UkoeHB_> for each normal address you own
<sarang> but the benefits of this approach are worth investigation
<sarang> IMO
<UkoeHB_> audits arent trivial for sure
<cankerwort> Should be called "ZtoM... and beyond!"
<UkoeHB_> lol yeah
<sgp_> I'm familiar with some people who do Monero audits for businesses so I'll try and get their feedback
<sarang> UkoeHB_: fortunately the proofs are all off-chain anyway
<sarang> So efficiency is much less of a consideration
<UkoeHB_> Id refrain from expecting anything in ZtM that isnt implemented to actually get implemented. They are just ideas
<sarang> UkoeHB_ and I had discussed this very topic earlier... about the intended purpose of ZtM
<sarang> e.g. protocol spec, or something else
<Isthmus> I think that flavoring it with the latest ideas and discussions will convey the lively R & D, provide helpful context, and leave an important historical record
<Isthmus> In 10 years I want to sit down and nostalgically re-read the old "future work" sections
<sarang> heh
<sarang> Anything else to share UkoeHB_?
<sarang> (just to keep the meeting on track)
<UkoeHB_> dont think so
<sarang> Cool, thanks for the update
<sarang> Isthmus: you had chimed in earlier
<sarang> Did you wish to continue with anything else?
<Isthmus> Life has been hectic, so haven't had many Monero moments lately.
<Isthmus> However
<Isthmus> n3ptune was doing some data QC/QA and noticed that in a recent preliminary figure I had missed 100 recent transactions with no payment id (encrypted nor unencrypted)
<Isthmus> But that's a minor difference
<sarang> How recent is "recent"?
<sarang> If you recall
<Isthmus> Probably this version, but idk
<Isthmus> It's only like a 0.5% change over the previously presented data
<Isthmus> I've been working on a little design thought experiment, but it's still rough and maybe more -lounge appropriate
<Isthmus> Otherwise, nothing else to report, that I can think of
<sarang> Got it, thanks
<sarang> I know suraeNoether said he was unavailable, but would provide an update later today on his recent work
<sarang> He's been working on some interesting updates to linkable ring signature security models
<sarang> I've been reviewing those as well
<sarang> Does anyone else wish to share ongoing research?
<sarang> Either specific to something mentioned here, or more generally
<sarang> If not, we can move on to QUESTIONS
<sarang> OK, looks like no questions so far
<sarang> Let's move to ACTION ITEMS before closing the meeting
<ArticMine> Feasibility of child pas for parent in Monero (child has parent as one of the mixins)
<sarang> ?
<ArticMine> pays
<sarang> Can you elaborate, ArticMine ?
<ArticMine> In Bitcoin a tx in the tx pool has to low a fee
<sarang> "has to low a fee"?
<ArticMine> A second tx is sent using the tx with to low a fee as an input
<sarang> Sorry, I'm not following
<sarang> ah
<ArticMine> The miner miones both txs in a block
<ArticMine> In the Monero case the child has the tx output of the parent as one of the mixins
<ArticMine> can be real or fake
<sarang> What is the specific question you're getting to?
<Isthmus> Interesting interesting
<ArticMine> Can this e done in Monero
<ArticMine> be
<UkoeHB_> oh is it about what can be done if a tx is stuck since its fee is too low?
<UkoeHB_> e.g. make a new tx with more fee for it
<ArticMine> Yes this can e part of the toolkit
<ArticMine> be
<ArticMine> but in addition to what I am looking at with the fees, etc
<UkoeHB_> we do have 10block lock time atm, so tx spending other tx output doesn't quite work, though there could be new rules around 'in the same block'
<Isthmus> I actually think this seems very plausible
<Isthmus> You wouldn't mine only the bump
<Isthmus> And once the transaction is mined, the bump is unnecessary
<Isthmus> The bump transaction should have exactly 2 outputs: a plaintext fee and an encrypted change output
<Isthmus> And reference the first transaction by hash
<UkoeHB_> yeah
<sarang> hmm
<UkoeHB_> Im wondering why not just remake the same tx
<UkoeHB_> with more fee
<ArticMine> because of multi sig
<UkoeHB_> ah yeah
<sarang> Huh, that's a very interesting question
<Isthmus> Oh, and only 1 bump per transaction
<Isthmus> You can broadcast more if you want, obviously
<Isthmus> But only one bump can be claimed by the miner
<Isthmus> So if you bump with 0.2 XMR then change your mind and send a 0.5 XMR bump, a miner would just ignore the smaller bump
<ArticMine> Yes
<ArticMine> but anyone can do the bump in Monero unlike Bitcoin
<cankerwort> Why "becauae of multisig"?
<Isthmus> You could design it either way: allow anybody to bump, or require a signature from the original sender to bump
<Isthmus> (one of the original senders)
<UkoeHB_> sounds like it's possible, although would require protocol level changes (new transaction type, etc)
<midipoet> wouldn't being able to do that (child pays for parent) drastically decrease the overall cost of the chain reaction attack?
<ArticMine> You include the parent as one of the mixins
<Isthmus> @UkoeHB_ I'm only here for the protocol level changes :- P
<cankerwort> Also the big bang attack presumably
<ArticMine> The miner does know if the parent is real or not
<UkoeHB_> ArticMine I don't know if the parent needs to be a mixin, just include the parent tx hash as part of bump tx, an additional data field
<ArticMine> That does not mine the parent
<UkoeHB_> It would be a new tx type
<UkoeHB_> 'bump tx'
<ArticMine> Not really
<UkoeHB_> RCTTypeBumpIt
<Isthmus> heh
<sarang> lol
<ArticMine> The point of child pays for parent is that in order to mine the child one has to mine the parent
<sarang> right
<sarang> But that seems straightforward to enforce, no?
<ArticMine> In Bitcoin that means spending the output of the parent in the child
<UkoeHB_> I think you might get into weird 0-conf territory if can spend an output with 0-block lock time
<Isthmus> @cankerwort yeah, though as long as the bump density [XMR per kB] is higher than transaction density [XMR per kB] then they would effectively take up less space (be less effective) for a big bang attack
<UkoeHB_> the 10block lock is there for a reason afaik
<UkoeHB_> just willy nilly
<ArticMine> in Monero it means including it in the ring real or fake. The miner does no know
<Isthmus> Yeah, I think the "bump" transaction needs to be a new type with exactly [fee delta + change] outputs and a new field referencing the transaction hash of the transaction to be accelerated
<Isthmus> And everything is subject to the 10-block lock
<UkoeHB_> or you could make it an optional field in normal tx type, to reduce complexity
<ArticMine> Both are mined in the same block so there is no issue with orphans
<sarang> UkoeHB_: not in extra, right?
<sarang> for parsing etc.
<UkoeHB_> no, unless we start enforcing it
<sarang> aye
<UkoeHB_> interesting idea articmine
<cankerwort> Surely the delta could be as small as you like though? So it could be used to make big bang attack cheaper
<UkoeHB_> big bang is about total block weight
<UkoeHB_> still have to pay fee for bump tx too
<cankerwort> Ie you are adding 2 transactions for one fee?
<Isthmus> The fee in the bump has to cover both the weight of the bump itself and the original transaction
<cankerwort> Ah
<Isthmus> So if I have a 5 kB txn and a 2 kB bump, then the total fee has to incentivize the miner to include 7 kB
<ArticMine> Yes enough to provide an incentive the miner
<ArticMine> That is the point of child pas for parent also in Bitcoin
<sarang> Quick note that we should try to finish up soon, since Konferenco has a meeting in a few minutes
<ArticMine> pays
<sarang> May we quickly review action items, and then continue discussion?
<ArticMine> Yes of course
<sarang> I'll be working on some review for vtnerd's 64-bit operation code
<sarang> as well as some Triptych coding for timing purposes
<sarang> Others?
<sarang> OK, then let's formally adjourn for log posting purposes... please continue discussion!
<sarang> Thanks to everyone for attending

Logs for the MRL Meeting Held on 2020-02-19

Wed, 19 Feb 2020 00:00:00 GMT

Logs

<sarang> OK, let's get started with the meeting
<sarang> GREETINGS
<sgp_> hello :)
<n3ptune> Hello
<needmonero90> I caught the meeting!
<needmonero90> I would like to note that the meetings are not listed in the calendar
<needmonero90> idk if thats intentional
<sarang> Which calendar?
<UkoeHB_> Hi
<sarang> And how are meetings applied to it?
<ArticMine> Hi
<sarang> Meeting times/agendas are always listed as meta repo github issues
<sarang> Anyway, does anyone wish to begin the ROUNDTABLE with research topics of interest?
<UkoeHB_> Yes
<sarang> Take it away UkoeHB_
<UkoeHB_> I finished designing an escrowed marketplace 'protocol' which hopefully solves issues encountered by rbrunner in his openbazaar integration analysis. Also, multisig and txtangle have been finalized.
<UkoeHB_> https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf
<sarang> Neat
<UkoeHB_> Finally, I had an idea for reducing minimum fee variability, and likewise for putting antispam directly in the protocol instead of relying on minimum fee
<sarang> Are you seeking analysis on those?
<UkoeHB_> Which is issue #70
<UkoeHB_> They are open for comments any time anywhere
<UkoeHB_> Ah and sarang provided a draft for a tx knowledge proof chapter
<sarang> aye
<UkoeHB_> (not really my research :p)
<sarang> Heh, it's more of a summary of what's in the codebase (and some changes)
<sarang> I look forward to reading the update draft you linked
<UkoeHB_> A number of topics here are lonely and want attention btw https://github.com/monero-project/research-lab/issues
<UkoeHB_> \end
<sarang> Thanks UkoeHB_
<sarang> Any questions or comments on those topics from anyone?
<ArticMine> Yes
<sarang> Please go ahead!
<ArticMine> I have taken a look at issue 70
<ArticMine> It actually has serious implications
<ArticMine> When the LT medium increases substantially
<ArticMine> I do have an idea for a solution
<ArticMine> Very preliminary at this stage
<ArticMine> As for an interim fix
<ArticMine> The est is to pay the high or at least normal fee for escrows that are expected to last past the next hard fork
<ArticMine> I will have comments on the issue in the next two weeks
<ArticMine> end
<sarang> Thanks ArticMine
<sarang> Any other questions/comments from the topics presented by UkoeHB_?
<sarang> Righto
<sarang> I'll share a few things
<sarang> First, the Stanford Blockchain Conference is happening right now (and the next couple of days), and has streaming available: https://cbr.stanford.edu/sbc20/
<sarang> Second, I did some math/code related to multiparty stuff for next-gen protocols
<sarang> Third, I worked on code and write-ups for transaction proofs, both for an updated PR and for inclusion in Zero to Monero for better documentation
<sarang> Fourth, I used chain data from n3ptune and friends to do better estimates of the cumulative effects of next-gen protocols
<sarang> both in chain growth and verification time
<sarang> Major caveat: these assume the same input/output distribution as the current chain, and are _estimates_only_
<sarang> and apply to post-bulletproof chain data only
<sarang> https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png
<sarang> ^ this link shows the total chain growth estimates for various protocols with varying ring size
<sarang> namely, from 16 to 1024 in powers of 2 (lines for visual aid only)
<UkoeHB_> Sarang would you mind adding an indicator for MLSAG and CLSAG at the 11 ring size 'point'? For reference
<sarang> Sure, let me grab that data from my spreadsheet
<sarang> hold please
<UkoeHB_> Or the super steep slope from 11 to 20 lol that goes off that chart
<sarang> Heh, I had that data but didn't include it since it's crazy linear
<sarang> I'm running the N=11 code for MLSAG/CLSAG, which I don't have handy
<sarang> Anyway, I'll pull up the time data while we wait
<sarang> https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png
<sarang> ^ verification time estimate for _group_operations_only_ at varying ring sizes
<UkoeHB_> I think it's interesting that all these protocols/signature schemes are similar size on the small end
<sarang> All the verification times are linear (up to a logarithmic term due to multiexp)
<UkoeHB_> Where is tryptich multi hiding?
<sarang> It's underneath Triptych-single
<sarang> They're essentially indistinguishable
<selsta> Does Triptych single have advantages over multi?
<sarang> RCT3-multi suffers due to input padding requirements that still have a linear verification effect
<sarang> selsta: a complete soundness proof :)
<sarang> Update on MLSAG/CLSAG size estimates...
<UkoeHB_> Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable
<sarang> At N=11, MLSAG for that chain range is 7.84 GB, while CLSAG is 5.84 GB
<sarang> (the actual size of that chain range is 7.9 GB)
<sarang> https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png
<sarang> ^ same time data, zoomed in
<UkoeHB_> Perfect thanks :) are time estimates for CLSAG/MLSAG available?
<sarang> Heh, just writing that out
<sarang> I have very early estimates on that, which are tricky since multiexp doesn't apply, and hashing is nontrivial
<sarang> MLSAG N=11 estimate is 29.9 hours for that chain range (but I have _not_ double-checked it)
<ArticMine> What hardware was used for the verification time calculations?
<sarang> It's a single core on a 2.1 GHz Opteron machine, with a bonkers amount of RAM
<sarang> I would rely on the timing data only for comparisons, not absolute values
<ArticMine> age of CPU?
<sarang> I am still in the process of getting CLSAG data, which requires additional test code
<sarang> It's a gen-3 Opteron, if that's what you mean
<UkoeHB_> Is there a way others could run the same tests?
<sarang> Again, only estimates using performance test code
<sarang> For next-gen protocols, it's quite easy
<ArticMine> Yes great it does give an idea thanks
<sarang> Well, somewhat easy
<sarang> You need to get multiexp performance timing data and use a linear interpolation that you plug into the simulator
<sarang> For MSLAG/CLSAG you need to run more operation performance data
<sarang> This is the simulator, which is still WIP: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py
<Isthmus> https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png
<sarang> But again, it's tricky to do comparisons between MLSAG/CLSAG and the next-gens
<Isthmus> (drive by data)
<sarang> Wow, that's quite low
<Isthmus> Oh yeah, the numbers are one thing. But moreso, we should all be more alarmed that analyzing something like this is possible for an outside observer
<Isthmus> ;-)
<sarang> Yep, and has certainly been a topic of interest!
<Isthmus> It's a privacy risk to use subaddresses right now...
<Isthmus> Anyways, I gotta bounce, sorry to spam n run
<sarang> OK thanks for sharing the data Isthmus
<sarang> Another good reminder that I/O structure reveals some information about subaddress use
<sarang> Since Isthmus had to leave, were there other questions/comments on the data that I shared above?
<sarang> UkoeHB_: if you want to run tests as well, let me know after the meeting and I can let you know how to get the numbers you'll need
<UkoeHB_> My computer is quite weak, was just asking for viewers :)
<sgp_> sarang: can you remind us on the plans to fix this subaddress thing?
<sarang> ah ok
<sarang> Requiring separate tx keys per output is a good idea, but IIRC didn't have a huge amount of support when last brought up
<sarang> FWIW the size data that I presented for next-gens assumes a separate tx key per output
<UkoeHB_> Is that necessary for the protocols?
<sarang> For the proving systems, you mean? No, not at all
<sarang> They don't care how you get signing keys
<UkoeHB_> Can you estimate the amount of additional pub key data? Num outs * 32 and num tx * 32?
<sgp_> sarang: why did it not get support now? complexity? size? verification time?
<sarang> My numbers for MLSAG/CLSAG include separate tx keys too!
<sarang> Also: n3ptune's dataset includes the pubkey counts
<sarang> So I could run that separately for a more direct count
<UkoeHB_> With only 3% subaddress adoption, the difference is likely on the order of 100MB
<UkoeHB_> Or 2% of total size I think
<sarang> that's probably a good order-of-magnitude estimate
<sarang> But IIRC scanning requires checking all pubkeys
<sarang> So either there needs to be a specified correlation, or there's added complexity in scanning
<UkoeHB_> I think it costs ~1GB for 30mill pub keys btw
<sarang> I think moneromooo had a better idea of the impacts, when it was brought up earlier
<sarang> FWIW I think it's a good idea unless it's very compelling not to due to complexity
<sarang> OK, we're running up to the one-hour mark...
<sgp_> obviously without this change, the impacts are quite negative for network privacy........
<sarang> It's differentiated data, but it doesn't leak _which_ outputs are subaddress-destined
<sarang> (not that I'm saying that's a good reason to keep the current approach)
<UkoeHB_> It's quite a lot of unused data, I'm a bit skeptical
<sgp_> just reveals "one of this outputs goes to a subaddres?"
<sarang> UkoeHB_:?
<UkoeHB_> A lot of dummy data
<sarang> sgp_: it reveals the number of subaddress outputs
<UkoeHB_> sarang all it reveals is at least one of the outputs must be to a subaddress
<sarang> Doesn't it reveal the total number of sub outs?
<UkoeHB_> No
<sarang> orly
<UkoeHB_> How would it?
<UkoeHB_> Number of additional pub keys always equals number of outs
<UkoeHB_> Even if nonsubaddress
<UkoeHB_> How is the CLSAG paper going?
<sarang> Hmm, for some reason I thought otherwise; noted
<sarang> I'm still waiting for suraeNoether
<sarang> He wanted to continue working on his ideas for the security model
<sarang> So unfortunately I am not the one to ask
<sarang> OK, is there anything else of interest to share?
<sarang> (Would be a good idea to continue discussing this after meeting, or on an issue, to keep it alive)
<sgp_> definitely need an issue for it
<sarang> All righty then; thanks to everyone for attending today
<sarang> We are adjourned!

Logs for the Community Meeting Held on 2020-02-15

Sat, 15 Feb 2020 00:00:00 GMT

Logs

<rehrar> 0. Introduction
<rehrar> Hello and welcome to the Community Workgroup Gameshow (CWG)! I'm your host, Diego Salazar, and we've got a great show planned for you all tonight.
<rehrar> Let's meet our contestants.
<rehrar> 1. Greetings
<intj440> Hi
<jwinterm> buen sabado todos
<selsta> hi
<i_a> ahoy
<rottensox> salutations.
<nioc> i'm napping
<rottensox> where's needmonero90.
<rehrar> Got us a lively group, don't we? Let's see how they handle the challenges to come.
<rehrar> 2. Community highlights
* needmonero90 sighs
<ajs> i'll take geography for 500 rehrar
<rehrar> All points go to Diego who writes the Revuo Monero which you can see at https://revuo-monero.com
<rehrar> We also released the July 1, 2019 - December 31, 2019 periodical
<rehrar> Does anyone have anything in particular they want to highlight about this past couple of weeks?
<needmonero90> price go up
<jwinterm> cake wallet has been doing a nice job of getting people with breasts to post images of themselves wearing cake wallet t-shirts on tweeter
<rottensox> lol.
<jwinterm> other than that I got nothing
<rehrar> ...when in the land of the nerds
<endogenic> i've been working on something very exciting
<endogenic> i'm only going to tell rehrar about it
<rehrar> endogenic: want to share?
<rottensox> boo!
<endogenic> because i'm only friends with him
<rottensox> double boo!
<dandums> 43770
<rehrar> ooooh, bonus points for endogenic
<endogenic> yessss
<rehrar> 3. CCS updates
<endogenic> haha i'll share real soon rottensox
<rehrar> We got a few things in funding. Fund Xiphon plz
<rehrar> Xiphon is the bees knees and does great work. selsta will now give a short speech/poem about Xiphon's contributions.
<endogenic> been hanging with some crytocurrency groups in SF as well. we may see some movement
<selsta> he is doing important GUI work :P
<rehrar> clap clap
<selsta> like improving stability, speed, etc.
<rehrar> truly a man with a mastery of words. Thank you selsta.
<selsta> sorry I’m currently eating :P
<rottensox> lol.
<rehrar> vtnerd? sarang? suraeNoether? anybody here with a report on CCS activities?
<sarang> More math, more data, more fun
<sarang> Using chain data to get better comparisons of next-gen tx protocols, etc.
<rehrar> Sarang Noether, ladies and gentlemen
<endogenic> i like sarang
<sarang> Aw shucks
<sarang> A few other assorted code updates, and so on
<rehrar> thank you. Any other CCS updates?
<endogenic> in other news mymonero continues not to ask the community for money
<endogenic> 😂
<rehrar> 4. Workgroup reports
<rehrar> 4a. Daemon/CLI scrubs
<rehrar> anyone here from them that can say what you've been up to? merged things? pr'd things?
<rehrar> 4b. Localization
<rehrar> ErCiccione[m]? you around?
<rehrar> lol. Zero points for everyone.
<rehrar> I do know they now have Weblate working with the website, so translate.getmonero.org for that stuffs
<rehrar> c. GUI workgroup
<rehrar> selsta: what's the word?
<selsta> see https://github.com/monero-project/monero-gui/pulls?utf8=✓&q=is%3Apr for recent activity
<rehrar> what an informative meeting this is so far
<rottensox> lol.
<endogenic> dont mean to jump in but have to run. check out my upcoming monerotalk interview - i made some technical announcements
<rehrar> aight cya
<selsta> when is it coming out
<endogenic> like stuff we've been workin on a long time
<selsta> the interview
<endogenic> ah i dunno. it was about a week aho
<endogenic> ago
<selsta> ok so soon :P
<endogenic> y'all remember when adding wallets to an app took 6 mos?
<endogenic> like jaxx? haha
<endogenic> well that's 1 day now
<endogenic> tbh i actually already open sourced some stuff quietly
<endogenic> but this is not the really exciting upcomign thing
<endogenic> time to go tell diego in private
<endogenic> haha
<selsta> are you going to announce it in the interview?
<selsta> or still secret :P
<rehrar> 4d. Outreach workgroup
<rehrar> I don't think any of them piped up either
<needmonero90> :(
<rehrar> Thunderosa, xmrhaelan?
<rehrar> e. Monero Research Lab
<endogenic> selsta heya it's not announced in the interview no
<rehrar> sarang kinda already did it.
<sarang> :)
<rehrar> I jumped the gun. We blazing through this meeting.
<rehrar> let's get us all home
<rehrar> f. Website workgroup
<rehrar> ErCiccione[m]: isn't here so we can skip this one too
<rehrar> woot. The best kinds of meetings.
<needmonero90> efficient meeting
<shillo> I have nothing useful to add besides mentioning that rehrar is doing a great job running this meeting even though people are slow to respond. If he waits long enough I'm sure everything will be covered in due time
<rehrar> 5. Open ideas time
<rehrar> 5a. Moneroversary.
<rehrar> We doing anything? Party? Who's bringing the beer?
<endogenic> i'ma chat w sgp about a ton of ideas i have for that
<rehrar> perfect. in fact, let's take all discussion offline for efficiency sake
<rehrar> next meeting will be held over PMs
<endogenic> hahaha
<endogenic> it's a private meeting
<rehrar> Any of you bozos have any ideas for open ideas time?
<rehrar> I have something if nobody else does.
<endogenic> you go first
<rehrar> There was some discussion and a twitter thread about some individuals wishing Defcon villages would go back to their roots of being more hands-on rather than talk focused.
<rehrar> Now Defcon is still a ways away, but if they have us back again, I'd like to see our village go in that direction.
<rehrar> Less talks. WAAAAY less talks. In fact, most of the talks can be the same talk given multiple times a day for people that can't make other times. "What is Monero?" given by different people or whatever.
<rehrar> More workshops. How to use the wallet. How to secure your seed. How to use a hardware wallet.
<dEBRUYNE> Can we allocate some time to discuss the addition of 'Reasonably' on the website?
<rehrar> dEBRUYNE: sure
<rottensox> how to lose your private key in a boating accident.
<rehrar> That's basically it from me. More discussions will develop in #monero-defcon when it's time, I think.
<rehrar> dEBRUYNE: take it away
<rehrar> lol, ok shall I start the discussion then?
<dEBRUYNE> Sorry, didn't see the ping
<dEBRUYNE> Anyway, I think, similar to the guy that posted on reddit, that we shouldn't add an adjective on the website, regardless of which it is
<dEBRUYNE> Simply 'private' is sufficient. In my opinion, it does not provide a privacy guarantee
<dEBRUYNE> Furthermore, we can add a disclaimer link that provides elaboration
<dEBRUYNE> The optics of 'reasonably' are quite bad in my opinion and it leaves a lot of new people guessing what it might entail
<intj440> +1
<nioc> dEBRUYNE: agree
<rehrar> We can also remove the "A" and just end up with "Private Digital Currency"
<rehrar> which, surprise is what was there to begin with :D
<jwinterm> a somewhat private with several important caveats that users should be aware of digital currency
<jwinterm> has a nice ring to it
<rehrar> any other opinions? differing or otherwise?
<rottensox> jwinterm: tl;dr.
<dEBRUYNE> What would be the point of removing 'A' rehrar?
<rottensox> private digital currency is simple and effective. don't look for the 5th leg in the cat.
<dEBRUYNE> Or is my sarcasm detector broken here :p
<rehrar> not sarcasm, what's the point of keeping it?
<jwinterm> 'A' is extraneous
<shillo> I'd remove the "A"
<rehrar> it's implied, yes
<rehrar> unless.....
<rehrar> if we want an article
<jwinterm> I agree an article is unnecessary
<rehrar> THE private digital currency
<jwinterm> unless you use 'The'
<rehrar> ^
<jwinterm> rehrar and I are actually the same person
<rottensox> impossible.
<rehrar> if jwinterm does squats, then it's literally true
<jwinterm> nah I'm fat and lazy
<rehrar> alright, so the present group is pretty much in agreement to remove "reasonably"
<rehrar> any other points of discussion or ideas?
<rehrar> if not, next meeting 29th. Same time.j
<SerHack> Yes, rehrar! I've submitted my third CCS for Monero integrations
<SerHack> https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/125
<sarang> Phrasings like "private" and "untraceable" are not useful without a lot of context
<rehrar> ah, cool, go comment on that then everyone
<rehrar> remove private leaves "Digital Currency"
<SerHack> There you may find all the information about my CCS. If you have any question, or any additional feature request, please leave a comment!
<dEBRUYNE> sarang: Hence my suggestion to add a direct link to a disclaimer page
<rehrar> Like some people say, probably better for it to be a link that takes to qualifications
<rehrar> ye
<sarang> It's not just the tagline... the homepage also says matter-of-fact phrasings like "Monero is private" and "Monero is untraceable"
<sarang> There's nuance and use cases etc. that affect those things
<rehrar> every word should be a link to a disclaimer
<rehrar> although I think we should move untraceable
<shillo> just hire a lawyer to decide how it should be phrased
<rehrar> I honestly think at some point we need to do a deep rethink of Monero's branding
<rehrar> I'm sure there's a good, snappy way to convey the message of Monero without a. overhyping us, b. underselling what makes us great
<rehrar> but it needs work, and a couple of tweaks isn't going to do it
<nioc> shillo: lol
<wampum> womanero
<rehrar> alright, meeting adjourned

Logs for the MRL Meeting Held on 2020-02-12

Wed, 12 Feb 2020 00:00:00 GMT

Logs

<sarang> Greetings!
<ArticMine> Hi
<UkoeHB_> Hiya
<n3ptune> Hello
<UkoeHB_> Thanks selsta I'll look
<sarang> I suppose we can move to roundtable discussion
<sarang> Who wishes to share interesting research?
<sgp_> hello
<n3ptune> Something quick from NRL
<n3ptune> We've been looking at some results regarding the extra field in transactions. We have one thing to share today
<n3ptune> Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated:
<n3ptune> https://usercontent.irccloud-cdn.com/file/Xf1uZRsZ/image.png
<n3ptune> (Sorry there is an uncorrected typo: "Unencrypted Included x Encrypted Absent" should be 232980 (not 232972) and "Unencrypted Absent x Encrypted Included" should be 1904765)
<sarang> ^ moneromooo etc.
<UkoeHB_> It's actually not 'mandatory', just part of the core wallet's behavior
<UkoeHB_> As jtgrassie liked to insist :p
<sarang> Nothing stops a wallet from simply including a fixed default value either
<sarang> (can't enforce "uniformly random" in that way)
<sarang> Once again touches on the idea of extra parsing/enforcement
<sarang> Are there other indications of what non-standard software it might be?
<sgp_> 17% is a good amount that didn't update properly
<sgp_> do they save slightly on fees?
<n3ptune> That's a good question, we didn't look into the transactions but there may be other things going on that make more of a fingerprint
<sarang> Thanks n3ptune
<n3ptune> Thanks! Just sharing these numbers today
<sgp_> if the fees are lower, I can see someone setting it up this way if they process many transactions
<moneromooo> Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ?
<n3ptune> I can check
<UkoeHB_> n3ptune: the core wallet only creates encrypted payment IDs for all 2-output tx, would you mind looking into the distinction (proportion encrypted IDs with 2-output and >2 output)>
<UkoeHB_> moneromooo: was the dummy encrypted payment ID also since 1.98e6?
<n3ptune> Another good question
<moneromooo> I think before.
<moneromooo> It was merged late january 2019.
<moneromooo> Yes, it was included in the release for that height.
<Isthmus> I don't think we looked at long PID
<Isthmus> Sorry, here is the updated figure
<Isthmus> https://usercontent.irccloud-cdn.com/file/t5ozuruh/image.png
<n3ptune> ? Long PID = Unencrypted PID, yes
<moneromooo> Yes.
<Isthmus> Oh, I was thinking integrated
<Isthmus> Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning
<Isthmus> But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- )
<sarang> How ominous
<UkoeHB_> it might just mean more significant implementations exist than just core, which might be good news also
<sarang> Well, not if the result is fingerprinting
<UkoeHB_> n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period)
<n3ptune> The numbers should be for non-coinbase only
<sarang> Well, in the interest of time, shall we continue? Hopefully we can get more detailed data, which can help any future decisions about parsing
<sarang> Thanks for the data Isthmus and n3ptune
<n3ptune> Thx, I'll check out those questions
<sarang> Other research to discuss or share?
<sarang> UkoeHB _ ?
<sarang> suraeNoether ?
<sarang> OK, I can discuss a few short items
<UkoeHB_> ok, I sketched out a light node proposal https://github.com/monero-project/research-lab/issues/69 pls leave your thoughts there if interested
<sarang> Ah ok, nvm
<sarang> go ahead UkoeHB_
<UkoeHB_> ZtM2 I got through multisig and the draft of that chapter is done, started working on escrowed marketplace chapter which will be done by next meeting https://www.pdf-archive.com/2020/02/12/zerotomoneromaster-v1-0-25/zerotomoneromaster-v1-0-25.pdf
<UkoeHB_> thats all from me
<Isthmus> @UkoeHB_ just scoped that proposal last night, looks like great stuff
<sarang> Looks to be similar to SPV structure?
<UkoeHB_> possibly, idk anything about SPV
<sarang> I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych
<sarang> Finished code and tests for new transaction proofs
<sarang> did some Dandelion++ review
<gingeropolous> yay triptych!
<sarang> Wrote some code to demo spend/non-spend status proofs that have been discussed previously
<sarang> and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol
<ArticMine> Any size indications for triptych?
<sarang> Individual transactions? Sure, that's been available for some time
<sarang> https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
<sarang> Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that
<sarang> since different tx protocols imply different tradeoffs as I/O structure changes
<ArticMine> It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed
<ArticMine> Which is very reasonable given the mixin privacy gains
<UkoeHB_> why increase?
<sarang> It depends on what protocol (if any) is chosen, what parameters used, etc.
<UkoeHB_> ah i see, for 1024 ring size
<ArticMine> I am saying with N = 512 or 1024
<gingeropolous> what are the hurdles for tryptich? besides me wanting to spell it wrong all the time
<ArticMine> If this goes through, by the time it makes it to the main chain the drop in block reward would easily cover the fee increase
<ArticMine> If we increase the penalty free block weight to 400000 bytes
<sarang> gingeropolous: no peer review yet
<sarang> I also need to know the practical drawbacks to the more complex multisig operations
<sarang> especially on lower-powered devices
<sarang> They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols
<ArticMine> We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth
<gingeropolous> ugh. what, for those silly hardware wallets?
<sarang> Well, anything that would need to participate in multisig
<sarang> The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc.
<UkoeHB_> would multi-tryptich work with any kind of join protocol?
<sarang> Unclear. It's still in the early stages
<UkoeHB_> before this meeting gets wrapped up, I am curious about the state of discussion around Monero's difficulty algorithm; zawy12 seems to have done a lot of research on the topic of difficulty algos https://github.com/zawy12/difficulty-algorithms/issues/50
<UkoeHB_> and suraeNoether was at one point doing research on that area
<UkoeHB_> apparently Monero's algorithm is quite bad, relatively speaking
<sarang> Interesting; I had seen some of their earlier work, but not this summary
<sarang> The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance
<sarang> (which isn't really part of the design choice)
<sarang> Worth a read, now that we have the link
<sarang> UkoeHB_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus?
<UkoeHB_> I feel Ive made my case for it, although Isthmus says they are working on a big comprehensive report so at that time I may recapitulate
<sarang> Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree
<sarang> It may come down to questions of efficiency and "someone needs to write it", but who knows
<UkoeHB_> enforcing it should be less than 100 lines of code IMO
<sarang> Sounds like someone is volunteering :D
<sarang> Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning?
<sarang> Righto; thanks for attending, everyone

Logs for the MRL Meeting Held on 2020-02-05

Wed, 05 Feb 2020 00:00:00 GMT

Logs

<sarang> OK, let's get started
<sarang> Logs from this meeting will be posted to the agenda issue shortly after the meeting
<sarang> First, GREETINGS
<sarang> hello
<sgp_> hello
<suraeNoether> good mroning
<UkoeHB_> hiya
<sarang> On to ROUNDTABLE, where anyone is free to share interesting research
<sarang> I'll go first, since I have a small assortment of things
<sarang> I worked up code and examples for doing hidden data storage within Bulletproofs and Triptych, suitable only for the prover
<Isthmus> I,m kinda here, but on a conference call
<sarang> Several ongoing projects/issues have been moved to monero-project/research-lab issues for comment and discussion
<sarang> The CLSAG code on my monero fork (clsag-plumbing branch) has been cleaned up; thanks to UkoeHB_ for helpful suggestions and comments
<sarang> It includes, among other things, hash function domain separation that we hope to roll out elsewhere for a more robust overall codebase
<sarang> There is also CLSAG Python sample code showing how to do signer index extraction in a clever way, which I assume UkoeHB_ may wish to discuss when he shares
<sarang> I've written up material for ZtM about transaction proofs/assertions
<sarang> And have worked up some new C++ code that updates transaction in/out proofs to have correct Schnorr challenges
<sarang> (still need to write tests for this)
<sarang> That's my update; any particular questions before the baton is passed?
<suraeNoether> quick question: iirc you had done work on encrypted timelocks
<sarang> yes
<suraeNoether> i've been chatting with both isthmus and TheCharlatan about them
<suraeNoether> do you have any notes prepared any place for later reading?
<sarang> On what in particular?
<suraeNoether> alternatively: can we schedule a discussion in this room that will end up in the logs for later this week?
<sarang> Sure
<sarang> Let's table for now, and address at the end
<suraeNoether> if we implement them regardless of if we are using mlsag, clsag, or triptych, there's going to be a cost. i want to see how it's all going to fit into future monero dev
<suraeNoether> word, word, i can go next
<sarang> OK, go ahead suraeNoether
<suraeNoether> last week i spent a lot of time on CLSAG and linkable ring signatures security definitions
<suraeNoether> there are a lot of definitions out there and they don't all relate to each other in a clean taxonomy, and it wasn't clear which ones we needed to use, and so on
<suraeNoether> so i started writing this rather large technical note summarizing all this with the intention of writing a second paper about it, but sarang and i have decided to merge the two into a new draft
<suraeNoether> the reason is that even definitions of unforgeability miss absolutely critical stuff becuase they are taken from "ring signatures" and mapped over to "linkable ring signatures" wholesale without regard for linking properties
<suraeNoether> so now the paper will be proposing a new definition of unforgeability specifically for linkable ring signatures that subsumes more than one security definition, and this is going to set the standard for a few years on how unforgeability is considered for all applications of linkable ring signatures.
<suraeNoether> this is good news(tm) for MRL
<Isthmus> sweet
<UkoeHB_> congrats :)
<suraeNoether> thanks :D
<sarang> It makes the preprint all the more valuable
<suraeNoether> In addition to that, I have been preparing my talk for the Blockchain Tech Symposium at the Fields Institute in two weeks, and debugging my matching code.
<suraeNoether> i'm extremely grateful to the peer reviewer who "gently" pointed us towards the backes' paper actually
<sarang> Having both improvements to security models _and_ a new construction seems to be the gold standard these days
<suraeNoether> they did us more of a favor than maybe they realized
<suraeNoether> my work for the week will include finishing up this new draft of CLSAG, and to begin large-scale data collection on matching
<sarang> Thanks suraeNoether
<sarang> Any questions for suraeNoether?
<UkoeHB_> if you want more CLSAG work, it's possible to increase the number of linkable keys up to the total number of pub keys considered :p
<sarang> Sure, but that's not useful for our particular application
<sarang> which is why we didn't consider it
<UkoeHB_> I believe there was an earlier question from nioc about matching
<UkoeHB_> for suraeNoether
<nioc>� my question is, what is the status of the matching project and how will is be used going forward to help select an appropriate ringsize?
<sarang> ^ was the question
<suraeNoether> ah, great question: the matching project is *what appears to be* a single-line bug away from correctly generating simulated ledgers. it already appears to generate correct confusion matrices; once this bug is cleared up, it's a matter of executing a big block of code for a large period of time to get all the sample data, and then analyzing the data that's dumped to file.
<suraeNoether> so... if this bug, just like all the others, is a hydra, then I don't have a good answer, but i suspect i've narrowed down the problems to the source
<UkoeHB_> Is the purpose of the matching project to produce the ledgers?
<suraeNoether> there are several purposes, but here's the main thing
<suraeNoether> we want to estimate how well an adversary can do at finding the "real" history of a monero ledger, given some hints (like it's a KYC exchange)
<suraeNoether> i have a method of computing a maximum likelihood estimate of the real history given some obscured ledger, and all that code works
<suraeNoether> and i have a method of taking an estimate and comparing it to the ground truth, producing a confusion matrix, and all that code works
<suraeNoether> i have a simulator that generates simulated ledgers, and the vast majority of that simulator is working just fine, too
<suraeNoether> the origin of the project came from the idea of developing a game-theoretic description of traceability on the monero ledger: you hand me an obscured ledger and some hints, I hand back to you my best guess, and then success is judged by you comparing the best guess to the ground truth you kept from me the whole time
<suraeNoether> so, the hope is: graph performance against ring size, and see if getting larger than 11 is a waste of space/time or not
<suraeNoether> in the meantime, we hope to also get good data for zcash-style ledgers, so that we can actually rigorously compare the two ledgers against each other, instead of tweeting at each other about fragility
<suraeNoether> but that last bit is farrrrr down the line
<Isthmus> Oh yea, I just remembered that ginger and I talked about generating synthetic blockchains forever ago https://github.com/insight-decentralized-consensus-lab/CryptoNote-Blockchain-GAN/issues/1
<
<sarang> OK, any follow-up questions on this?
<suraeNoether> unfortunately, i've not worked on matching since mid-January because CLSAG's security models are critically important
<sarang> and CLSAG needs to get out the door
<sarang> Anything else to share, suraeNoether?
<sarang> Does anyone else wish to share relevant or interesting research?
<Isthmus> I'm taking a break from blockchain logs analysis to do some chat log analysis, analyzing recurring logical fallacies in this space
<suraeNoether> Nope
<suraeNoether> isthmus lol really?
<sarang> ?
<Isthmus> Yeah, actually doing a formal analysis
<suraeNoether> Isthmus: if you are, i have a friend to hook you up with at the university of exeter
<sarang> This channel in particular?
<sarang> Or more broadly in cryptography?
<Isthmus> Somewhat broady
<Isthmus> There's 7 common ones that show up in -lab
<sarang> go on...
<Isthmus> But they break down into combinations of red herrings and something that is *similar* to the slippery slope argument, but not quite the same and I'm still nailing down its technical logical structure
<suraeNoether> dude, please elaborate
<Isthmus> Like when we're debating fixing a tractable privacy leak, and somebody points out that there are other privacy leaks
<UkoeHB_> :O
<suraeNoether> ah yeah
<suraeNoether> or comparing everything to 50% attack costs
<Isthmus> Another one is the hashrate code control fallacy
<suraeNoether> ?
<Isthmus> Confusing a 51% attack on longest chain with a 51% attack on the code
<Isthmus> This came up a few weeks ago actually
<suraeNoether> aaaah
<suraeNoether> i smell some medium articles
<Isthmus> Like why should we bother working on the protocol and code, when one day, somebody might run their own version on a bunch of their own miners
<sarang> Based on what you've analyzed so far, any particular recommendations to avoid such flaws in discussion/thinking?
<Isthmus> That one can be disproven by contradiction
<Isthmus> If 50% of BTC hashrate moved to BCH, does that make BCH the official bitcoin?
<suraeNoether> "why should we patch little leaks in info here and there" styled privacy nihilism/despair
<Isthmus> Oh shit, I gotta be in a meatspace meeting
<Isthmus> ciao!
<sarang> -__-
<sarang> Very interesting stuff
<Isthmus> Erm, not by contradiction. I mean by example demonstrating absurdity
<sarang> We have plenty of time left... does anyone else wish to share anything?
<UkoeHB_> lol
<suraeNoether> lol "i'm going to use machine learning to watch all of your conversations and find out who repeats fallacies most zealously BAIII GOTTA GO GRAB A FREE SLIZE OF 'ZZA FROM THE CORPORATE OVERLORDS" amiright
<UkoeHB_> Here's mine. Worked on write-ups of different ideas -> now Research repo Issues, with good feedback from sarang improving viewspent approach. TxTangle (aka my monero coinjoin protocol) is mostly done and just needs questions answered about network-layer anonymity. Current draft of ZtM2 is here https://www.pdf-archive.com/2020/02/05/zerotomoneromaster-v1-0-23/zerotomoneromaster-v1-0-23.pdf and current
<UkoeHB_> ‘koe’s Ideas’ is here https://www.pdf-archive.com/2020/02/05/moneroideaskoe020520/moneroideaskoe020520.pdf
<sarang> Yeah, the original view/spent idea was broken, but there's a better approach
<sarang> It ties in with the CLSAG index extraction that I mentioned earlier
<sarang> If the signer generates all non-signing scalars via a PRNG s\_i := H(seed,i) (with appropropriate seed data), then it can be asserted privately what the signing index is
<sarang> It removes the need to add anything to the chain, and hence is good for indistinguishability
<sarang> I dig it, provided the UX is sufficient for reasonable use cases
<UkoeHB_> yeah if view key can regenerate those scalars, it can know when an output has been spent with certainty
<UkoeHB_> of course, it only works if tx author generates scalars like that
<sarang> The problem is still that it's opt-in, so even an accidental use of a non-participating wallet ruins the account balance computation for good
<sarang> So you'd have to be super-clear about presenting that to the user
<sgp_> hmm
<sarang> Of course, a wallet could be doing that right now for all we know
<sarang> it's non-consensus and can't be detected if done properly anyway
<UkoeHB_> it does leave open questions about data stored by nodes, since signature scalars are pruned; perhaps only full nodes, or view-spent enabled nodes can be used
<sarang> IMO that's a completely reasonable trade-off
<sgp_> sounds reasonable to me too
<UkoeHB_> it also may greatly increase data transmitted to view-only wallets by remote nodes
<sarang> Bloating the network for optional functionality benefitting only a single user seems unnecessary
<sarang> But this approach means you can run a full node (good for the network) and have the functionality for your wallets safely
<sgp_> UkoeHB_: I think that's a good thing to point out but probably isn't a showstopper
<UkoeHB_> might need to receive a gigabyte of data to read through a year's worth of tx
<suraeNoether> hmmm
<suraeNoether> i'm a little worried about this in the following sense
<sgp_> I still think that is okay for view-only wallets
<suraeNoether> you are selecting the non-signing scalars deterministically from a PRNG
<sgp_> anyone using them for critical stuff, or viewing multiple wallets, should run their own node
<suraeNoether> one thing we all know about schnorr signatures is that if nonces are selected deterministically, it's possible to extract the private keys
<suraeNoether> at least, under certain constraints
<sarang> suraeNoether: yes, which is why seed selection is very important
<suraeNoether> so my question is
<sarang> UkoeHB_ and I discussed this a bit already earlier
<suraeNoether> if the seed is chosen from a high entropy distribution and kept secret, it's computationally hard to detect that these are computed deterministically
<suraeNoether> i would prefer a method that is more than computationally hard
<sarang> Presumably the seed is a combination of the view secret key, the index, the key image, etc.
<sarang> suraeNoether: how would that even work?
<sarang> Data extraction requires that only the designated parties be able to construct the "expected" output value
<suraeNoether> pfeh, we use PRNGs because statistical RNGs don't really exist :P so ... it wouldn't
<sarang> Well, right now we operate on the assumption that the user has access to something behaving as an RNG
<sarang> this moves to an honest-to-goodness PRNG
<sarang> (and has to)
<sarang> You can't do data extraction with a true RNG AFAICT
<suraeNoether> that... is... true.
<sarang> Anyway, this is an interesting topic that could be useful for a future release
<sarang> but has subtle aspects to seed selection and UX that need further review
<sarang> Let's move on, for the sake of time
<sarang> Any other topics you wish to share, UkoeHB_?
<UkoeHB_> well, I hope people can leave feedback on the repo issues
<sarang> Yes, please do
<sarang> Much easier than only doing IRC comments =p
<UkoeHB_> sorted TLV is probably most important for next hardfork
<sarang> TBH that's probably going to be better for -dev discussion
<sarang> More of an engineering question than a math question :)
<UkoeHB_> true
<sarang> I'd bring it up at a dev meeting, or just in -dev whenever
<sarang> Get a sense of the work involved
<UkoeHB_> ok
<sarang> I know people have brought up tx_extra parsing before, and it's a hot topic
<sarang> Does anyone else wish to discuss other research topics?
<UkoeHB_> ah, CLSAG section was added to ZtM2 for anyone curious
<sarang> excellent
<suraeNoether> uh i saw vtnerd's push on dandelion++
<sarang> Yes
<sarang> Most excellent
<sarang> It's on my list to review later this week
<sarang> Speaking of which
<sarang> Let's briefly move to ACTION ITEMS to respect everyone's time
<sarang> I'll be reviewing the D++ PR, working through some additional transaction assertion/proof stuff, updating sublinear tx protocol MPCs, and writing up examples of RCT3 hidden data storage
<suraeNoether> yes. Mine: Finish CLSAG, start collecting matching data. Also, of primary importance: provide updates twice or three times a day in here until both of these are finished.
<sarang> As well as getting tests written for the new tx in/out proofs
<suraeNoether> i'll be reviewing the D++ pr also once those are both off my plate
<sarang> Yes, looking forward to the CLSAG stuff (will review when ready)
<sarang> Anyone else have action items planned for the week?
<UkoeHB_> To do: focus on multisig all week, hopefully finish txtangle (need a network anonymity expert for advice, any takers?)
<sarang> The most knowledgeable person is probably vtnerd
<sarang> I hear if you say his name 3 times, he gets 3 separate notifications...
<sarang> =p
<sarang> Any last-minute items, questions, etc. before we formally wrap up?
<sarang> (I'm happy to discuss timelocks after we adjourn)
<sarang> Going once...
<sarang> twice...
<sarang> Adjourned! Thanks to everyone for attending; logs will be posted shortly on the agenda issue

Logs for the Community Meeting Held on 2020-02-01

Sat, 01 Feb 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/435
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<thunderosa> hello
* needmonero90 waves
<ArticMine> Hi
<SerHack> Hi
<sgp_> welcome everyone
<sgp_> sorry again for the delay
<sgp_> next meeting at normal time (1 hour before this)
<sgp_> 2. Community highlights
<needmonero90> It's 18:00 on a Saturday, the regular crowd shuffles in
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> Does anyone have community (non-workgroup) updates to share?
<sgp_> I'll take that as a no
<ArticMine> I gave a podcast in Spanish https://www.youtube.com/watch?v=zZaf5ps7Lzs&feature=youtu.be
<monerobux> [ Monero Swaps para anonimizar Bitcoin con ArticMine - L47 - YouTube ] - www.youtube.com
<sgp_> oh sweet, nice ArticMine!
<sgp_> good stuff
<almutasim> Awesome.
<sgp_> you should be on rottensox and anhdres's podcast
<sgp_> 3. CCS updates
<sgp_> Funding required:
<sgp_> 3 months part time work on Getmonero.org https://ccs.getmonero.org/proposals/ErCiccione-website-jan-march.html (150.26 / 174 XMR)
<sgp_> v1docq47: video creation / translations into russian (february - july 2020) (6.04 / 100 XMR) https://ccs.getmonero.org/proposals/%20v1docq47-video-creation-translations-into-russian-(february-july-2020).html
<sgp_> Ideas (to be discussed):
<sgp_> Locha Mesh, private transactions and sync over a resilient long-range radio mesh network https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/115
<sgp_> lots of comments on this one over the weeks
<sgp_> this specific proposal seems to have general support from binaryfate, selsta, and xmrhaelan
<sgp_> among a few others
<sgp_> and as far as I can tell, ErCiccione[m] and rehrar have outstanding concerns
<selsta> not really from my side
<rottensox> https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/115#note_8788
<selsta> they plan for recurring funding which I’m against
<needmonero90> Myself as well (concerns) but I have not vocalized them in the thread.
<rehrar> My concerns are mostly satisfied at this point.
<sgp_> selsta: against recurring, but you would be ok with this one? I'm trying to understand your viewpoint
<rehrar> I would be comfortable seeing this as a trial period. And if we like them and they like us, integrate them into our project.
<sgp_> rehrar: noted, thanks
<sgp_> needmonero90 and ErCiccione[m], can we please hear your concerns
<selsta> Integrating them is a bad idea IMO.
<ErCiccione> The project can be interesting, but gives me the feeling that it need way more than 3 months before we see some concrete development
<selsta> They are not a Monero project and wouldn’t be here without funding
<rottensox> ^
<dEBRUYNE> We also have to ask ourselves how many people are actually going to utilize the integration
<rottensox> ^
<sgp_> indeed, it's a niche solution to be honest
<selsta> 19:09 <sgp_> selsta: against recurring, but you would be ok with this one? I'm trying to understand your viewpoint <-- In general I’m against it as it is not related to Monero but I would be ok with one time funding.
<rehrar> selsta, perhaps. I'm not for them being integrated necessarily. I'm against them getting money unless they are one of us, was my point.
<sgp_> but presumably donors would know that? should that be clearer?
<sgp_> my concerns with it being niche are related to the donors knowing that, not necessarily a hold on moving the CCS if that makes sense
<selsta> Where is the limit? Someone creating an operating system that at one point will run Monero, would that be something for the CCS?
<ErCiccione> I think i'm leaning more to selsta's point of view. A continuous funding of a project without clear benefits doesn;t sound like a good idea, especially since we will see the real benefits in a very long time, not at the end of the 3 months
<dEBRUYNE> I am also a bit worried it might exhaust donors
<sgp_> selsta: I don't want to get too into the weeds, but there is an associated marketing opportunity and clear prioritization for a tool built for Monero I suppose. These would need to be addressed case-by-case
<dEBRUYNE> We've already had periods were projects took quite some time to get funded
<rehrar> dEBRUYNE: this is my biggest concern.
<rehrar> We have some big ones coming up too. suraeNoether needs to put his in.
<ErCiccione> dEBRUYNE: That's a very legit concern. I know the pain of seeing your proposal not funded for months
<sgp_> (it's still not fully funded)
<rehrar> Also, let's be real, funding three conferences a year, plus several quarterlies is, I think, the limit of the system.
<rehrar> Along with a smattering of small one-offs.
<needmonero90> Without a pamp at least
<ArticMine> ^ very valid
<needmonero90> Even then we risk over extending for a future bear tho
<rehrar> For this reason alone, I vote no.
<ArticMine> A future bear is likely to be weaker than this one
<sgp_> as a CCS moderator, it's hard for me to weigh the concern about burdening donors in a way that's fair. it's entirely subjective in terms of what to move
<sgp_> I get that this is a nonessential need
<rehrar> In contentious cases like this we leave to Luigi.
<ArticMine> I am very much on the fence on this.
<rehrar> I'll be giving a full report to him on our talks here and on the gitlab
<sgp_> rehrar: can you tell luigi I lean yes move with donor disclaimers (they know it's a fun, ambitious, "extra" project), and that you "vote no"
<rehrar> Can do.
<sgp_> any other discussions that are new info or new arguments before we wrap up this topic?
<needmonero90> None here
<sgp_> ok, thanks for your patience as this one took a bit of time to discuss over the past several weeks
<sgp_> A Monero-centric Merchant Marketplace https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/117
<needmonero90> Is endogenic around?
<sgp_> any comments on this one? up for a week now
<needmonero90> I think endogenic might have a similar project, would be curious to know if he's seen that
<rottensox> https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf
<rottensox> item number 7; seems fairly similar to what rbrunner had in mind. koe weighs in on this there.
<needmonero90> Wait wrong person
<needmonero90> Wasn't endo, lemme contact them
<sgp_> doesn't seem like there's much discussion here yet, so we should review on gitlab and encourage them to do another round of reddit to increase exposure to the idea
<sgp_> Part Time Research Atoc (pending update) https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/120
<sgp_> this one is stalled, no discussion needed
<sgp_> xiphon part-time coding https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/122
<sgp_> does anyone oppose this one? contributor with a track record looking to increase their involvement 50%
<sarang> I believe that atoc is presently interested in the XMR-BTC swap proposal from h4sh3d
<sgp_> sarang: I think we can discuss that one when it's updated so we have more to discuss
<sgp_> for the record: who supports xiphon's proposal?
<selsta> I do
<sgp_> you all are quiet today! many of you commented on gitlab expressing support
<selsta> 19:23 <sgp_> does anyone oppose this one? contributor with a track record looking to increase their involvement 50% <-- AFAIK his previous CCS was already 20h/week
<selsta>* unless I misremember
<sgp_> this one is 30 hrs
<sgp_> 20 -> 30
<selsta> ah
<sgp_> :)
<selsta> didn’t see that :P
<ArticMine> Developer proposals from existing contributors are a safe bet in my books. So yes
<sgp_> I personally looked to make sure that there are plenty of plans to-do to fill the time, and it seems to be the case 100%
<needmonero90> Xiphon does valuable work, though I'm also curious how far we can stretch donated time. In the past I've tried to come to grips with the difference between people who are coordinators (availability expectations) and regular controvutors
<needmonero90> Contributors*
<needmonero90> Right now I'm in favor of the proposal, though it's inconsistent with my previously expressed stance that we should only be paying coordinators
<selsta> coordinators?
<needmonero90> Yeah, like the mrl
<needmonero90> They act as human buffers
<endogenic> mrl is contributing tho
<needmonero90> For the people who contribute their time and effort for free
<selsta> we have never done that?
<selsta> unless I’m missing some discussion
<needmonero90> I'm speaking about our funding of the researchers, when other people like isthmus don't get CCSed
<needmonero90> Basically, the researchers have an availability expectation
<rehrar> He hasn't asked. :P
<sgp_> needmonero90: are you suggesting a form of leadership role (likely in addition to contributions)?
<needmonero90> Exactly
<needmonero90> I've been referring to them as coordinators
<selsta> sounds unnecessary for the GUI
<needmonero90> Them = that role
<sgp_> ah, got it
<needmonero90> And coordinators are really the place where funding makes sense
<sgp_> I think in this case the gui workgroup hasn't really formed this way, but maybe they will in the future
<sgp_> I mean, they kinda have in practice
<needmonero90> I'm on the fence about funding regular contributors with no availability/coordination expectation
<selsta> I disagree with that.
<sgp_> I think that's a strong stance
<ErCiccione> I disagree too
<ErCiccione> and that's not how the ccs work right now fwiw
<rehrar> needmonero90: I wouldn't say mooo has an availability/coordination expectation.
<sgp_> but I acknowledge the benefit of prioritizing leadership roles
<rehrar> He does sometimes, but not all the time. He just codes for the most part.
<needmonero90> I've been trying to figure out an internally consistent structure for the CCS in my own head
<needmonero90> I realize it's not how it works atm
<ErCiccione> ah ok :)
<rehrar> I say yay on xiphon.
<sgp_> needmonero90: I think it's an interesting check, but as you acknowledged, there will need to be exceptions as we figure this out :)
<selsta> We don’t need paid GUI contributors that have expected availability.
<selsta> We need contributors that code :)
<needmonero90> One that doesn't open itself up to random people putting pressure on getting their proposal merged so they get a seal of approval
<sgp_> I think we're done on xiphon discussion
<sgp_> and the CCS stuff
<ErCiccione> We need contributors that code -> we need contributors.
<sgp_> we got through a lot this week, good job everyone
<sgp_> 4. Workgroup report
<rehrar> We need contributors -> We need
<needmonero90> We.
<ErCiccione> lol
<sgp_> not we, just I need
<needmonero90> I need money
<sgp_> a. Daemon/CLI workgroup
<sgp_> vtnerd made a PR for the last major hurdle for dandelion++ support! ++
<ErCiccione> 90
<rehrar> I saw that.
<rehrar> That's kind of super exciting.
<sgp_> better network privacy even without tor/i2p
<sgp_> cool stuff
<rehrar> Exciting enough to do a point release with it?
<rehrar> Once merged, I mean.
<sgp_> rehrar: will probably take time to merge, so who knows! :)
<sgp_> that's the biggest thing I saw but I'm sure there was more I missed
<sarang> There are network benefits even without full adoption, FWIW
<rehrar> At least a day, for sure.
<rehrar> sarang, can MRL look over the implementation and give their thoughts?
<sgp_> yeah, partial is hugely beneficial here
<sgp_> though we should expect large adoption at the next hardfork
<sarang> I added it to the top of my list as soon as I saw it late yesterday
<ErCiccione> we definitely need to write a blog post after the PR is merged
<sgp_> b. Localization workgroup
<sarang> I expect it will be discussed at the next MRL meeting
<sgp_> ErCiccione[m]: absolutely
<sgp_> marketing 101
<sgp_> ErCiccione: you're up now :)
<rehrar> This is actually kinda huge.
<ErCiccione> cool
<ErCiccione> nothing too big. I'm waiting for 2 PR to be merged in the getmonero repo before starting to use weblate for the website (i will speak about it more in the report of the website workgroup)
<UkoeHB_> hi
<ErCiccione> and the strings for the GUI got updated
<ErCiccione> so if you speak another language, get in there and translate all the things
<ErCiccione> translate.getmonero.org
<rehrar> getmonono.org
<ErCiccione> there should be about 40 new strings
<rehrar> Sneaky Computer Bucks
<ErCiccione> and ike 30 removed, but i'm going by memory, could totally be the other way round
<ErCiccione> that's basically it. Waiting for a PR to be merged in the core repo, so translators can work on the CLI as well
<needmonero90> Is CLI currently untranslated?
<ErCiccione> Not sure of what you mean. CLI is translatable on weblate, but not in this very moment, because the PR with the refresh and the translated strings need to be merged first, or there would be conflicts
<needmonero90> Oh I understand
<ErCiccione> this is the PR: https://github.com/monero-project/monero/pull/6312
<ErCiccione> there is also a brief summary of the work of the translators that is being committed
<needmonero90> Spanish is only 9% done? Rottensox slackin
<ErCiccione> so basically after that is merged the new strings will be picked up and people can start to translate the CLI again
<ErCiccione> that's the normal workflow
<rottensox> needmonero90: sorry... translation isn't my expertise. actually, i have no specialization.
<ErCiccione> yeah, cli doesn't see much action, but i'm kinda ok with it, i prefer most of the effort to be on the GUI and if there are energies left, CLI
<ErCiccione> rottensox: you don't need any specialization. I literally just learned english properly when i started to translate Monero stuff. But that's another story
<kinghat> so how does D++ work with Tor or I2P?
<sgp_> kinghat: let's table that question for now
<sgp_> anything else ErCiccione?
<ErCiccione> nope
<sgp_> I have two related things I'll mention here
<sgp_> Mastering Monero was translated to Chinese: zh.masteringmonero.com
<sgp_> It was also translated to Russian and needs reviewers: https://github.com/monerobook/monerobook/pull/81
<sgp_> the second one was part of the CCS request that is outstanding
<ErCiccione> that's actually super cool. Great job to all involved
<sgp_> c. GUI workgroup
<sgp_> Binaries for the point release are still not out yet. https://github.com/monero-project/monero-gui/releases/tag/v0.15.0.3
<sgp_> no idea what the status is there honestly
<needmonero90> Did you ping the telegram channel on the review sgp?
<sgp_> but I haven't been paying close attention
<needmonero90> I can drop the link there if you haven't
<sgp_> needmonero90: not yet but I need to
<sgp_> oh, please do :)
<sgp_> d. Outreach workgroup
<sgp_> thunderosa: please give your update
<thunderosa> Sure, so I have Almutasim's update first that I'll copy and paste
<thunderosa> In the second half of last year, Monero Outreach worked on story generation and publishing in several areas. The following were either edited or written by Monero Outreach during this period:
<thunderosa> Response to Coinbase. On November 8, 2019, Coinbase blogged an article covering its views on Proof of Work (PoW), and the article made a number of incorrect points and reached an arguably inappropriate conclusion regarding Monero. Monero Outreach's fast-turnaround November 13 response corrected the errors and argued in favor of the ASIC-resistance path taken by Monero’s developers. Corrections included 1)
<thunderosa> pointing out the article’s description of Monero’s efforts to prevent the use of ASICs as outdated and 2) countering adverse technical and philosophical arguments made regarding the benefits of ASICs.
<thunderosa> Getting Started with Helping Monero. Monero Outreach created a document describing the many ways individuals can engage with the Monero community and support Monero. Resources for learning more about Monero and its technology were presented. The document included advice for software developers, with links to repositories, guides, and research results. It summarize Monero workgroups and social media outlets.
<thunderosa> And advice was given on other ways of individual contribution, such as through mining, running a Monero node, and donating.
<thunderosa> Monero in China and The West. Monero Outreach worked with Chinese Monero community member FutureFan to publish an article comparing the Monero communities of China and the West. FutureFan had previously worked with Monero Outreach by translating articles into Chinese. This new article talked about the relative sizes of the Monero communities and the difference in interest, with, for example, the West more
<thunderosa> interested in philosophy and China more interested in mining. It presended a path forward to improve cooperation between the two communities and increase the use of Monero in China. This article, released just after the new year, was followed up with a Monero Talk interview that will be published as a video soon.
<rottensox> damn.
<sgp_> they told me before there would be a wall of text, and I recommended getting it all out quickly :)
<thunderosa> Well,..so the real wall is coming
<thunderosa> and I'm sorry,..but it's a big update.
<sarang> pastebin?
<thunderosa> But our main focus this time around was more on how we publish versus what we publish. Over the past year we've realized that much of the traffic we orchestrate for Monero never touches our servers and in fact the only things we actually need www for is SEO and thumbnail scraping for social media. We saw an opportunity to practice what we preach and decentralize our publishing.
<thunderosa> With that in mind, we also had a basket of concrete design goals. A big focus was to setup Primo/RPC-Pay/Support Mining in an effort to help subsidize our hard costs. We also thought we were well-suited to be an RPC-Pay guinea pig publisher. It was also important that the Community Calendar and Merchant Directory projects would be furthered. Lastly, we wanted to prepare to release our publishing platform,
<thunderosa> Spoke, as FOSS and some modernizing and organizing was needed.
<sgp_> sarang: to some extent it's good to have it actually in the logs rather than an external site that will go away
<thunderosa> holy cats!
<thunderosa> sorry about that
<thunderosa> Anyway, there's alot going on,...TLDR: We're serverless and going to finally finish the Community Calendar on it
<ErCiccione> ay
<sgp_> haha just as I made a temporary solution
<ErCiccione> (sorry, misclicked)
<thunderosa> Well, I have been very late in delivering it, and for that I'm sorry.
<thunderosa> But this is the right way to build it.
<ErCiccione> the non-google calendar is very welcome :P
<thunderosa> yeah, we can take Google in if we want,..but I'd really rather avoid using G at all for our projects.
<thunderosa> like Google Calendar API in
<thunderosa> as a source
<ErCiccione> no please don't. My point is to not use google
<thunderosa> Yeah, I'd like to start with just humans and see how good we can make that before automating too much.
<kinghat> the outreach post on RPC-Pay was awesome 🙏
<ErCiccione> ^ agree. Would be cool to make a user guide for getmonero out of it
<thunderosa> Thank you, Alumtasim did a really amazing job making that happen and leading our workgroup into some new ideas through it.
<sgp_> thanks for the update thunderosa
<sgp_> I echo statements that rpc-pay was great
<sgp_> nice, simple name too
<sgp_> any other outreach comments?
<kinghat> put the new cal link in the topic?
<thunderosa> Nope that's the load. We'll be posting updates mid next week.
<sgp_> great, thanks for the updates here
<sgp_> skipping hardware since msvb seems away, can come back if needed
<sgp_> f. Konferenco workgroup
<sgp_> Expect an announcement this Monday. But as a sneak peek, the Konferenco is June 13-14 in Berlin.
<sgp_> but yeah, be ready Monday
<sgp_> g. Monero Research Lab
<sgp_> sarang
<sarang> Hi
<sarang> Plenty of topics under discussion recently
<sarang> One of note is CLSAG
<sarang> We'd planned for an earlier audit, but got great review comments from a conference submission
<sarang> If there is still good support for deployment, I recommend an audit still
<sarang> However, I also recommend not having someone directly involved with the work coordinate the audit
<sarang> to mitigate conflicts of interest
<sarang> sgp_ suggested an audit workgroup
<sarang> General thoughts on this initial idea?
<sgp_> I've reached out to a few names to judge interest
<sgp_> but the intent is to use the workgroup to help coordinate the clsag audits
<sgp_> maybe I can answer questions about that after sarang, continue
<sarang> The timing of the audit depends on (a) security model updates to the preprint; (b) availability of reviewers; (c) timeline of selection/fundraising
<selsta> Is conflict of interest a realistic threat? Can you explain?
<sarang> I think it's always a good idea to keep in mind
<sgp_> selsta: there are also a few related goals, like drafting writeups of the results, etc
<sarang> I think it sets a good standard of impartiality going forward
<ArticMine> I agree
<sarang> As a reminder, the benefits of CLSAG are ~25% reduction in typical tx size, and ~15-20% verification savings
<sarang> The only quote we received last time for a math+code audit was about 15000 USD
<sarang> this was from Teserakt
<ArticMine> via OSTIF?
<sarang> Anyway, that's the big research item of timely community interest that I wished to share
<sarang> ArticMine: yes
<sgp_> thanks sarang
<UkoeHB_> may I jump in?
<sarang> That's another conflict of interest, since I've participated in an OSTIF advisory committee :)
<sgp_> it was a busy MRL week, so follow their github if interested: https://github.com/monero-project/research-lab/issues
<sgp_> UkoeHB*: sure briefly :)
<sarang> Yes, many issues that we'd been looking at (and new ones) are now listed there as issues
<UkoeHB_> Here is the current roadmap containing others’ ideas and my ideas, most of which need more discussion so please feel free to leave thoughts https://www.pdf-archive.com/2020/02/01/moneroroadmapkoe020120/moneroroadmapkoe020120.pdf
<UkoeHB_> OpenBazaar integration was investigated by rbrunner in 2019 but met some technological roadblocks. I have been engineering solutions to those problems, which should hopefully be fleshed out over the next weeks. The solutions would be beneficial to any Monero based marketplace that wants to operate with minimal trust requirements.
<sarang> ^ koe's personal roadmap
<UkoeHB_> Sarang has helped me design a monero-style coinjoin protocol, named TxTangle, which is mostly done.
<UkoeHB_> yes
<sarang> (don't view it as endorsement by anyone else)
<sgp_> nice
<sarang> This may be a bit off-topic for this group, but at some point it should be decided when the next network upgrade should occur, given CLSAG and other changes of possible interest
<sarang> CLSAG is a consensus change
<sarang> D++ is not
<sarang> but simultaneous release would help adoption
<sgp_> sarang: good point, we will need to talk about that later though
<sarang> Yeah, I know it's running late :/
<sgp_> thanks UkoeHB
<sgp_> ErCiccione: would you like to give a website update?
<ErCiccione> yes
<sgp_> go ahead
<ErCiccione> i guess we are running late so i'll be superquick
<ErCiccione> 3 things:
<ErCiccione> 1. Logs of meetings are not being submitted on getmonero. We miss quite a lot of logs of meeting happened in the last months. If somebody want to help submitting some, that would be very appreciated
<ErCiccione> 2. We really really need people to review pull request on monero-site. Some of my PR are still waiting for a review after more than one month. Some of them are also trivial
<ErCiccione> https://repo.getmonero.org/monero-project/monero-site/merge\_requests
<ErCiccione> ^ please take a look and review if you can
<ErCiccione> 3. Two of these PR need to be merged asap because without them i cannot put getmonero on weblate. The PR are:
<ErCiccione> https://repo.getmonero.org/monero-project/monero-site/merge\_requests/1212
<ErCiccione> https://repo.getmonero.org/monero-project/monero-site/merge\_requests/1210
<ErCiccione> That's it. Please review stuff or the development of the website will be slowed down
<sgp_> thank you
<sgp_> 5. Open ideas time
<sgp_> Just one thing: xenugrande recommended “doing some sort of one day rally as part of the festivities for the yearly Monero anniversary. I received enthusiasm for it to possibly act as a fundraiser for the Monero research team, as well as doing some sort of "black friday" type of event where we would reach out directly to merchants/vendors to coordinate deals for people using Monero.”
<sgp_> Last year we did the online event. We still need to plan that event, so we can make that a community meeting topic or a separate meeting.
<kinghat> vcool UkoeHB_!
<sgp_> Monero's anniversary falls on a Saturday this year, so it's easy to plan
<sgp_> Look for a Moneroversary issue in the next week on the meta repo to collect ideas
<sgp_> Any final essential thoughts?
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 15 February at 17:00 UTC.
<sgp_> The next Coffee Chat is next week on 8 February at 17:00 UTC.
<sgp_> New calendar(mahy now be very temporary haha) (please configure reminders if they don’t copy over!): https://calendar.google.com/calendar/embed?src=itmaraubkfoe4aq2oquoaogsuk%40group.calendar.google.com
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2020-01-29

Wed, 29 Jan 2020 00:00:00 GMT

Logs

<sarang> Let's go ahead and get started with GREETINGs
<sarang> Hello
<ArticMine> Hi
<RingSize937> v Greetings
<Isthmus> Heyo
<koe> greetings
<Insight> hello
<atoc> Hi
<sarang> Let's continue with ROUNDTABLE, where anyone is welcome to share research topics of general interest (and discuss any questions arising from them)
<sarang> Since there was so much to discuss last week, I'll try to keep the discussion focused to the extent possible, for clarity
<sarang> I have a few brief things to mention
<sgp_> hello
<sarang> First, I wanted to better understand the effects of including hidden timelocks in CLSAG signatures, and worked up a version of 3-CLSAG in C++ for performance tests
<sarang> Including timelocks would negate the verification time advantages of an MLSAG-CLSAG transition
<sarang> but would still give size benefits over MLSAG
<sarang> A similar approach would work in Triptych, so I extended the Triptych test code to 3-Triptych for this purpose
<sarang> And, just for completeness, updated the Triptych preprint on IACR to a general d-LRS construction
<sarang> Here is the 3-CLSAG test code, for those interested: https://github.com/SarangNoether/monero/commit/db33d18bb889043c4bdea6d8582ffe2f6c581d28
<sarang> And the 3-Triptych concept code: https://github.com/SarangNoether/skunkworks/commit/f7581a385d72baa3dbb60c83e8d856a9335bec1f
<sarang> And the updated Triptych preprint: https://eprint.iacr.org/2020/018
<sarang> I also found a very minor change to make in the existing CLSAG test code
<sarang> Finally, suraeNoether and I have been doing more security model stuff
<sarang> Any questions on these items from anyone?
<koe> not directly for sarang, but at Isthmus regarding timelock; what is the prevalence of non-zero timelock for non-coinbase tx?
<Isthmus> Absurdly prevelant
<koe> whether or not to include encrypted time lock depends in part on how much use it actually gets
<koe> used
<sarang> Yeah, and I'm not formally advocating for it at this point; only curious about the implications
<Isthmus> I think our options are to remove the silly timelock field (It's just an arbitrary integer memo field currently) or encrypt it.
<koe> I like that it's a straightforward application of concepts already used in Monero
<sarang> Yeah, conceptually it's really neat
<Isthmus> Will we be the first privacy coin to roll it out?
<Isthmus> I expect that it will become industry standard
<sarang> Does Zcash offer such functionality?
<sarang> (I have not checked)
<sgp_> no clue
<Isthmus> I don't think so, but not 100% confident
<ArticMine> ZCash has serious scaling issues
<sarang> Anyway, whether or not Zcash does it should not be the determining factor IMO :)
<sarang> Merely curious
<Isthmus> Oh wait. Zcash inherited nLockTime from Bitcoin
<Isthmus>
<Isthmus> I'mma fish out their information leaks too
<Isthmus> And OP_CLTV
<sarang> If implemented, it would make the most sense to bundle the timelock range proofs with the existing Bulletproofs
<sarang> So this means the sum of timelock-enabled inputs (all inputs, if mandatory) and outputs is restricted
<koe> for Triptych, what are the steps between now and considering it for replacing RingCT?
<sarang> Formal review, a determination about its effects on multisig (particularly on compute-limited hardware), a decision on Triptych vs something like RCT3
<sarang> I have not yet examined how easy it would be to include timelocks in RCT3 with their security model
<ArticMine> ^ ... and estimated recommended tx size for Triptych
<sarang> Also note that, as I think I mentioned last week, it would not make sense to deploy hidden timelocks with MLSAG due to the poor scaling
<sarang> (though technically possible)
<koe> agreed
<sarang> Anyway, I want to make sure others have time to speak as well
<sarang> Who else wishes to share research topics?
<Isthmus> Zebra network stack looks interesting, potential applications in Monero?
<sarang> I saw that yesterday!
<sarang> Blag post about it: https://www.zfnd.org/blog/a-new-network-stack-for-zcash/
<sgp_> cool, will check out
<sarang> And a corresponding forum post (not much activity there yet): https://forum.zcashcommunity.com/t/a-new-network-stack-for-zcash/35870
<sarang> It's from Zcash Foundation research
<Isthmus> Monero maintains a single state across all the peers, right?
<sarang> That's a good question, and I don't know the answer
<sgp_> ping vtnerd
<sarang> I had thought so, but not confident in that
<hyc> not even sure what that means. single state? what is included in that state?
<hyc> there is an aggregate state for bandwidth limiting
<hyc> but sync info is per-connection
<Isthmus> Oh so maybe we already take the Zebra approach?
<Isthmus> It seems pretty elegant.
<sarang> Isthmus: did you have other topics you wanted to bring up as well?
<hyc> "Unlike zcashd, which maintains a fixed number of outbound connections, we attempt to connect to as many peers as possible, subject to resource limits "
<hyc> this approach will be troublesome for them, since they use levelDB/rocksDB for storage
<hyc> lvelDB/rocksDB requires thousands of file descriptors for its storage.
<hyc> that competes with the demand for socket descriptors
<sarang> Interesting... worth bringing up as a question on the forum?
<sarang> One of the developers (Henry) opened the thread
<hyc> not from me. I have no interest in helping zcash project
<sarang> ok
<Isthmus> I'm trying to make the unlock time plot, but my laptop is struggling with the 1.5 GB data set
<hyc> they should have already known by now that their DB choice is inappropriate for a network service that uses lots of connections, but it seems they haven't discovered that yet
<sarang> Isthmus: no rush!
<sarang> In the meantime, koe: did you wish to address anything in particular?
<koe> yes muahaha
<koe> not technically research, my roadmap has been cleaned up a bit; in particular I want to get opinions on item koe_11, which would enable view-only wallets to know when owned outputs have been spent; also item koe_9 which would allow all wallet implementations to more or less deprecate pre-RingCT transaction versions
<koe> https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf
<hyc> koe_11 sounds like a high priority
<koe> also, sarang helped me work up a decentralized CoinJoin-esque protocol (temporarily named JoinMo), which is available as chapter 9 of current ZtM2 draft
<koe> https://www.pdf-archive.com/2020/01/29/zerotomoneromaster-v1-0-21/zerotomoneromaster-v1-0-21.pdf
<koe> chapter 10*
<sarang> I like the JoinMo approach of using per-participant shared secrets to obscure the input-output mapping
<koe> also, rbrunner at one time investigated OpenBazaar integration, and ran into some roadblocks, so my 'research' has been engineering solutions to those problems, which should be available next week
<sarang> I'm giving extra scrutiny to the specifics around SAG/LSAG since the keys are per-output only
<sarang> I was thinking about the implications of using a separate keyset for inputs as well
<sarang> (keys = per-join participant keys, I mean)
<koe> however, OpenBazaar integration would likely entail a large update to the code-base, to optimize communication rounds
<koe> moreover, multisig in general should be updated to comply with suraeNoether's paper on the subject
<sarang> Yes
<Isthmus> Somewhat related to item 10, I'm still concerned about any blockchain observer being able to identify which transactions do not include any outputs to subaddresses.
<Isthmus> n3ptune and I will make a plot of subaddress adoption over time : -)
<Isthmus> But ideally that should not be possible.3
<sarang> Also yes :)
<sarang> It's been suggested before to standardize on some form of per-output keys for this purpose
<sarang> but it never gained traction
<sgp_> koe: nice list! koe_9 may be controversial since spending pre-rct would stand out more, no?
<atoc> Yeah looks like a nice list koe
<koe> it already stands out like a sore thumb
<koe> but that sort of problem will exist for RingCT as well, since spending ancient outputs is always somewhat unusual
<koe> and my suggestion is to start using pre-ringct outputs as decoys as well
<hyc> If we told everyone to sweep them to themselves, would that also be too obvious? you could assume that every txn with pre-RCT inputs is going back to its sender
<koe> so gamma select over entire site of outputs
<koe> set
<sgp_> koe: do we currently only select rct randomly as decoys?
<koe> yes, and coinbase (not sure if pre-ringct coinbase are included)
<koe> coinbase are included as decoy in normal tx, which is where this idea comes from
<sgp_> then this actually makes spending pre-rct slightly less suspicious, no?
<sarang> And the handling of coinbase outputs is by no means solved
<Isthmus> This is 80% a joke: We implement Koe_9 and sgp_coinbase_only rings, *but* require each and every one to include N coinbases and M pre-ringCT transactions, for fixed consensus parameters N and M
<sarang> sgp_: the distribution tail falls fast
<sgp_> sarang: indeed, but it's near-zero better, not near-zero worse I think
<sarang> Yes, but does provide slightly more information (amount)
<Isthmus> https://usercontent.irccloud-cdn.com/file/R26YQwiJ/image.png
<Isthmus> ^ which is hilarious, because all of these would hypothetically unlock at HEIGHT 2 and HEIGHT 12 back in 2014, IIRC what mooo said
<sarang> Due to the non-standard handling of that field, you mean?
<sarang> (which should be standardized anyway)
<sgp_> Isthmus: hmm, I would need to see a lot more info on how many people actually spend pre-rct (suspected) compared to coinbase. My intuition leans no
<ArticMine> So include a single pre ring CT fake if the real output is not pre ring ct
<Isthmus> @sarang: Yes, currently, 3 things are being put in the unlock field:
<Isthmus> https://www.irccloud.com/pastebin/0Y87gTTq/
<Isthmus> Argh sorry
<Isthmus> Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks"
<Isthmus> Large integers like "1980000", presumably to be interpreted as block heights
<Isthmus> Very large integers like "1578561720", presumably to be interpreted as unix timestamps
<sarang> yup
<atoc> I am working on a first version implementation of xmr-btc atomic swap in Rust
<atoc> more info here: https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf
<sarang> atoc: did you identify a suitable zkp?
<sarang> Aside from things like the handling of non-compliant participants etc., the zkp of hash/log preimage was not specified
<atoc> the paper proposes two transactions for each token
<sarang> yep
<atoc> is there is a zkp not specified I will look at it. So far I have just gotten some initial stuff implemented
<atoc> however I have not gotten to the swap part yet
<atoc> for the implementation, I have read through the paper and it seems sounds
<atoc> sound*
<sarang> Yeah, you'll notice there's a requirement for a particular proof that a hash preimage and discrete log preimage are equal in equal knowledge
<sarang> Something trustless like Bulletproofs could be used for this, with a suitable circuit
<atoc> I see
<sarang> The BP paper had data on such a circuit, but I was specifically told it was for testing only and was not yet suitable for any kind of deployment
<atoc> I will take a look at that
<atoc> We will need it. Perhaps we can see if that circuit works okay, and if not hopefully we can look at ways to improve.
<sarang> koe: thanks for that roadmap writeup; it's nice to see many suggestions put together in one place
<sarang> It might be useful to open research-lab issues for those that require ongoing discussion
<sgp_> I still advocate for those two mining pool-related proposals btw :)
<atoc> sarang I send you a link to my repo once I push some changes
<sarang> even though most discussion happens on IRC
<atoc> I will send*
<sarang> Thanks atoc
<atoc> You can take a look and I would like to get your feedback on it
<sarang> Happy to help
<sarang> Thanks for taking a look at that
<atoc> (y)
<koe> sure I can put on research github; was just wondering if koe_11 should go on main repo's issues
<atoc> Np, it seems interesting. This week I was just l familiarizing myself with different atomic swap techniques i.e off-chain and on-chain
<atoc> And looking at the dalek library in Rust
<sarang> koe: I'd say anything that requires ongoing unsolved research is definitely suitable for research-lab
<sarang> But I don't dictate the scope of issues!
<sarang> OK, we have about 10 minutes left (there's another meeting taking place at 19:00 UTC for the Konferenco)
<koe> ok can put them up there
<sarang> Any research topics that have not yet been brought up, and should be?
<atoc> sarang btw have you considered publishing your list?
<sarang> Of topics I am personally working on? Not really, it's more to help organize my own work
<atoc> The private list that you had of research topics that need attention.
<sarang> I should open issues for them as well
<sarang> TBH github issues for research are not used as well as they could be
<atoc> Yeah I think it would be could to have a public list to look through as important topics for Monero that need attention
<sarang> Since so much of the discussion happens on IRC in real time
<atoc> yes indeed
<sarang> But at least those issues could be used as a central posting location
<atoc> I currently go back to the logs, but that list was helpful.
<sarang> I don't want people to have to scour IRC logs
<sarang> Sure, I'll make some issues
<sarang> We should clear out old issues as well, or request updates
<nioc> peanut gallery here. Now that suraeNoether 's matching project is complete (?) or nearly so, what is the plan to use it going forward ?
<atoc> 'scouring IRC logs' - story of my life :')
<sarang> nioc: good question for suraeNoether!
<sarang> He has also been working on LRS security models lately
<sarang> (which are a blocker for CLSAG review)
<sarang> OK, let's move to ACTION ITEMS for the time being (discussion can of course continue after we formally adjourn)
<sarang> I am writing up some material on transaction proofs/assertions, and writing up new code for a proposed InProofV2 and OutProofV2
<sarang> As well as security model updates, some work on proof rewinding for data storage, and some odds and ends
<sarang> Anyone else?
<atoc> my action item: mkW my private .git repo (of atomic swap implemntation) public on Githuv
<sarang> neat
<atoc> Github*
<koe> my action items: multisig and escrowed-marketplace protocol writeup, possibly start bulletproof study if time permits
<sarang> BPs for the ZtM writeup?
<Isthmus> I want to make a website where you can type in a stealth address (or list of them) and see what future transactions have used them as ring members
<Isthmus> But need a little bit more backend work before that is ready
<koe> at the very least studying it
<Isthmus> I think the concerning part will be seeing the outputs that have been used in no subsequent rings, and thus have a known spend state and no plausible deniable for spendedness
<sarang> Let me know if you have any particular questions that I may be able to answer
<koe> of course :)
<sarang> Any other action items, or final comments before we adjourn?
<sarang> (from anyone)
<koe> actually spoiled my writeup from several months ago in the latest ztm2 draft whoops
<sarang> It's great to see so much research lately into so many different areas of interest from so many people :D
<sarang> Gets tough to keep up with everything
<sarang> Which is a great problem to have, in some sense
<sarang> Anyway, thanks to everyone for attending; we are now adjourned!

Logs for the MRL Meeting Held on 2020-01-22

Wed, 22 Jan 2020 00:00:00 GMT

Logs

<sarang> GREETINGS
<binaryFate> hi!
<sgp_> hello
<suraeNoether> Hi
<koe> hiya
<Isthmus> holla
<sarang> Let's move to ROUNDTABLE
<sarang> Isthmus: you posted some data on the agenda; care to discuss?
<sarang> Link to data: https://github.com/monero-project/meta/issues/430#issuecomment-576455137
<Isthmus> Sure
<Isthmus> First, glanced at distribution of number of outputs on miner transactions
<Isthmus> https://usercontent.irccloud-cdn.com/file/OB2UWpjs/image.png
<Isthmus> This is mostly a historical novelty from back in the days of denominated XMR - since RingCT became mandatory at block 1400000 all miner transactions have been 1OTXs.
<Isthmus> *single-output coinbase transactions
<sarang> So that chart is for _all_ miner txns?
<sarang> Throughout all of time?
<Isthmus> From genesis block to last week
<Isthmus> Courtesy of n3ptune's magic database xD
<Isthmus> Another mostly historic novelty - altruistic transaction selection by miners who would include many/large transactions in their blocks, incurring a coinbase penalty that is not offset by the added fees. (In other words, they would have had a higher total block payout by mining an empty block.)
<Isthmus> https://usercontent.irccloud-cdn.com/file/0pcNROcT/image.png
<Isthmus> color is size, starting at blue = small
<Isthmus> This seems to not be a very common practice these days
<Isthmus> Altruistic mining could be banned at the protocol level, but at the moment I'm not inclined to do so
<koe> more advanced altruism based on suboptimal tx inclusion will involve more intensive analysis, which I provided pseudo code for this week, if that path is chosen
<suraeNoether> Any comparison against partially filled blocks rather than empty blocks?
<Isthmus> @koe yea do you want to jump in
<sarang> Yeah koe please do
<sarang> koe: if you have a link to the pseudocode can you include it here?
<koe> well this week I: made pseudo code for Isthmus blockchain analysis, deep proofreads of several ZtM chapters, talked with cohcho and jtgrassie about uniformity of coinbase tx
<koe> more or less improved a roadmap of future monero developments: https://justpaste.it/5io6e which we can talk about some items
<koe> latest ztm2 draft, I have honestly been pushing off multisig edits, but not making no progress https://www.pdf-archive.com/2020/01/22/zerotomoneromaster-v1-0-20/zerotomoneromaster-v1-0-20.pdf
<sarang> Enforcement of exact block rewards seems straightforward and a good idea
<koe> pseodo code https://paste.debian.net/1127152/
<sarang> Regarding ZtM, are there topics in progress for which you'd like particular information or assistance?
<koe> currently working on multisig, and have already gone through most documentation available, but there are some things that aren't clear despite documents
<koe> so if anyone knows about multisig, Id like to discuss with them
<koe> otherwise will dive into code base
<suraeNoether> I'm not super familiar with the code base, but I'm familiar with what it's supposed to abstractly represent
<sarang> Thanks koe
<suraeNoether> So if you have questions koe about how things are supposed to work (as compared to how things are currently implemented)
<suraeNoether> Lmk
<koe> ok Ill hit you up
<sarang> Anything else of interest to share koe? You've clearly been busy!
<koe> well there are all the things in the roadmap, in particular enforcing 1 output from coinbase (since Isthmus found literally all coinbase for 4 years have been single output), and possibly enforcing single-type ring membership (only coinbase ring emmbers, only rcttypebulletproof2 ring members) since 99.5% of coinbase are owned by pools who are easy
<koe> to fingerprint
<sarang> Single-type enforcement was brought up a few times by sgp_ in the past as well
<koe> see https://minexmr.com/pools.html where 99.5% of hash is accounted for
<sarang> My concern was that a full segregation of coinbase outputs means certain heuristics are only moved "down chain" by a single hop
<sarang> Meaning there's likely improvement for sure, but perhaps more marginal than desired
<atoc> koe, do you still need proofreading of ZtM or are you good on that?
<suraeNoether> I'm in favor of enforcing single output coonbase txns by consensus. I'm in favor of enforcing block reward. I'm tentaticely in favor of type-restricted rings.
<koe> always need proofreading :) even after it's published lmao, I've received some good emails that are incorporated in v2
<sgp_> I actually was going to re-introduce the topic again here to keep it on everyone's minds, so nice timing
<sgp_> related: https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43
<atoc> koe, I am have some notes that I need to send you.
<atoc> I will try to get them to you soon.
<koe> ill look forward to them :) (email me)
<moneromooo> Enforcing single output coonbase txns would prevent p2pool.
<atoc> will do :)
<suraeNoether> Atoc, I believe that my mojojo branch is no longer bugging out, although data isn't being written to file how I want. The actual tracing game script I am running will be pushed soon(tm)
<koe> jtgrassie is p2pool your project?
<moneromooo> AFAIK nobody is doing it yet.
<suraeNoether> But simulator is now successfully simulating a monero economy between Alice, Eve, and Bob to model flavors of EABE
<atoc> cool suraeNoether I have been falling a bit behind and will catch up today and get you my thoughts
<atoc> good to know the unit tests are working fine
<atoc> Nice
<suraeNoether> It's all good, I'll still be plugging away
<sarang> Any other questions/comments for koe?
<sgp_> no specific questions, but I have a related topic for mining pools besides coinbase outputs when time allows
<sarang> OK, first, is Isthmus back? He had to step away briefly
<sarang> Isthmus: care to finish up your data?
<Isthmus> Also, it's not "kicking the can down the road" depending on how you implement it
<sarang> (then we can move to sgp_)
<Isthmus> But yea, moving on
<sarang> Hold on
<Isthmus> Discovered that everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
<sarang> Why would coinbase-only not do this?
<sarang> If you assume the spend patterns would be sufficiently different, I agree
<Isthmus> Uhm, I could get in the weeds with this
<Isthmus> On like 4 levels
<Isthmus> lol
<Isthmus> From an *on chain* perspective, there's two questions we can ask
<Isthmus> 1) Is this ring spending a coinbase
<suraeNoether> \me pulls up lawn chair
<Isthmus> 2) Which coinbase is this ring spending
<Isthmus> #1 is hard to hide
<Isthmus> #2 can be accomplished
<Isthmus> making #2 unanswerable can be accomplished
<Isthmus> I'm an evil exchange
<Isthmus> With current system, I can fingerprint which pools my users belong to
<Isthmus> Aah ha, this person makes monthly deposits that are 4-input transactions each spending from a ring with 62 B null padding, so I know that they have about 3000 H/s attached to minexmr.com
<Isthmus> *each spending from a coinbase whose miner tx_extra has...
<Isthmus> But with coinbase-only txns, we strip the pool-to-user link
<sarang> fair
<Isthmus> Sure, as an exchange I can look at each user, and their average number of coinbases per ring
<Isthmus> And if it's more coinbases per average I could suspect that they're a miner
<Isthmus> But that's about all
<sgp_> while there are some concerns with coinbase-only having only a layer of separation, I think the real benefits are being minimized slightly, especially to non-mining users
<koe> also, coinbase is currently polluting normal tx rings, since a large proportion are identifiably spent/not spent
<sarang> koe: the newer weighted selection algorithm does help this to an extent (relative only to tx weight, nothing else)
<suraeNoether> One thing that is important about privacy is that third parties that have data like this are lawyer magnets. If an exchange couldn't possibly identify their mining user habits, they can't be hacked or subpoenaed to determine one of their customer's hash rates
<Isthmus> In my ideal world, we have 13 ring members and two selection algorithms. Precisely 11 of the members are non-coinbase, selected with current algorithm. Precisely 2 of the members are coinbase(/coinbase-only) that are selected independently.
<sgp_> Isthmus: that would not be good for many reasons :)
<sgp_> notably, you need a set of at least 3
<Isthmus> Oh, I'm not married to the numbers
<Isthmus> Just making an example
<Isthmus> (trying to avoid the misconception that adjusting our coinbase ring member selection algorithm will somehow be zero-sum with the rest of the anonymity set or users)
<nioc> koe: I know that rbrunner (sp) made an implementation of multisig so it might be good to speak with him. I don't see him online now and haven't seen him for a little while but should still be around
<koe> on the other hand, I wonder if enforced ring types is too much like reacting to how people use it; although the same could be said for many other protocol rules
<sarang> Anyway, I derailed Isthmus's discussion of his other data with this topic...
<Isthmus> Also, let M be the minimum plausible age between any output and it's temporally closest ancestor coinbase
<Isthmus> :- P
<Isthmus> That can either be a plotable feature, or fixed for all transactions at zero
<koe> nioc ok Ill reach out
<Isthmus> I think n3ptune and I may plot this for all outputs just to show the point
<Isthmus> Other two things on the agenda - encrypted unlock time, and tx_extra in coinbases
<Isthmus> I can get into these if people are interested
<sarang> Sure, I saw your information about encrypted locks
<sarang> (I also wish to address timelocks anyway_
<sarang> )
<Isthmus> Cool, lemme copypasta real quick
<Isthmus> Oh, and for the encrypted + enforced unlock time, we have to decide on a format. Currently, 3 things are being put in the unlock field:
<Isthmus> Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks"
<Isthmus> Large integers like "1980000", presumably to be interpreted as block heights
<Isthmus> Very large integers like "1578561720", presumably to be interpreted as unix timestamps
<Isthmus> While normally I'd be loathe to bring real world time onto the blockchain, I am inclined towards this approach: encrypted unlock time is a future timestamp recorded in unix seconds, and each ring must include a range proof comparing the unlock time to the oldest or youngest ring member (I haven't fully thought this through).
<Isthmus> The minimum lock time of 10 is trivial for any outside observer/miner to enforce by delaying (or rejecting) transactions with rings containing members less than 10 blocks old. This requires no mathematical validation within the transaction.
<Isthmus> The encrypted unlock time could actually be defined as timestamp - 1500000000 to save a bit of space by removing the offset from some of time between 1970 and deployment, but that could be overengineering.
<sarang> We have a relatively efficient way to do encrypted timelocks, as introduced in DLSAG
<moneromooo> Small integers are block heights. If you put 12 now, it's pointless.
<suraeNoether> I'm 100% in support of encrypted lock times... I know that sarang has done some work into the requirements on that in addition to isthmus
<sarang> The method is described here: https://github.com/SarangNoether/skunkworks/tree/timelock
<sarang> It works as follows: outputs come equipped with a timelock Pedersen commitment (units aren't relevant for this at the moment)
<moneromooo> Small integers are block heights. If you put 12 now, it's pointless." Ahhahahaha that's what everybody is doing. Lemme make a plot real quick
<sarang> Signatures come equipped with an auxiliary plaintext time that's chosen semi-at-random
<sarang> as well as a particular auxiliary commitment
<sarang> There is a range proof constructed using all these values, and CLSAG/MLSAG gets a new set of entries too
<sarang> This maintains signer anonymity, shows the timelock has passed, but does not specifically reveal information about it
<sarang> The cost for CLSAG is 1 new group element; the plaintext timelock is replaced by a plaintext intermediate value
<sarang> and the auxiliary per-signature commitment is 1 new group element
<binaryFate> does this mean the no-locktime transactions will be indistinguishable from locktime ones? Or just that the locktime ones will have an obfuscated time lock?
<sarang> The rangeproofs can be worked into the existing bulletproofs, likely for free due to padding
<Isthmus> Indistinguishable plz
<sarang> Depends on how it's implemented
<suraeNoether> indistinguishable would probably require no-locktime txns to have a dummy encrypted locktime
<sarang> So the cost is 64 extra bytes per signature, and 32 bytes per extra timelocked output
<sarang> Yep, you'd include zero locktime
<sarang> and the rest of the process proceeds the same
<sarang> So this is not free, but it's not terribly expensive either
<sarang> Anyway, this information is to supplement what Isthmus brought up about how timelocks are handled now
<binaryFate> It's completely offtopic but I personally like the idea that we can embed an arbitratry hash in a transaction in a way that is indistinguishable from other txs, for timestamping purposes.
<binaryFate> Would only be half or a quarter of a hash in that case though
<binaryFate> (using the encrypted time lock field)
<Isthmus> @binaryFate if we add an enforced encrypted memo field, that would be a very good use case
<suraeNoether> binaryFate: well, you could always pick your txn key as the Hp of some message. is that not what you mean?
<binaryFate> it works too, but require you don't lose your local storage.
<suraeNoether> sure. you want to be able to extract the message also, something like that?
<binaryFate> just exhibit the message later on and point out to a past hash in the blockchain that timestamps it, without people taking notice this was a timestamping tx.
<binaryFate> but if you have message you can get hash back, so tx key works perfectly I guess
<suraeNoether> oh neat
<binaryFate> anyway, sorry to derail
<sarang> Isthmus: take it away :)
<Isthmus> Derailing conversation is a key part of research! :- D
<Isthmus> I think that's where 2/3 of our interesting stuff comes from
<suraeNoether> *nod* i prefer these lively research meetings for sure
<Isthmus> Anyways, last topic I had has been discussed significantly since I initially mentioned it. So I'll intro and then duck out of the way
<sarang> You had some notes, Isthmus, on how timestamps are represented
<Isthmus> https://usercontent.irccloud-cdn.com/file/Ovp9yP0j/image.png
<sgp_> I will most likely need to take off, so I'll bring up my other mining pool ring signature proposal (which I mentioned in the past) when I get back
<atoc> @isthmus agreed, it seems that new ideas fluster that way.
<Isthmus> Oh go @sgp_
<sgp_> ah, so very fast
<sgp_> there are special ways we can construct rings for public mining pools to protect the "integrity" of outputs (make it no longer publicly known what transactions they are spent in)
<sgp_> for public mining pools that share transaction histories, it's clear which outputs are change outputs, which are later spent by the pools
<sgp_> to avoid this, public pools can select rings using exclusively decoys that they create as payments to miners
<sgp_> that way, outsiders have no way to distinguish the output from the other outputs given to miners. saves one output per payment, per public pool
<sgp_> this is not a consensus change, but it would require a separate "public pool selection mode" or similar
<sgp_> Isthmus: how? payouts won't be from coinbase outputs
<Isthmus> Aah, maybe I was thinking of something slightly different
<Isthmus> Carry on :- )
<sgp_> this protects pool change outputs from being known as spent by the pool in specific transactions
<sgp_> that's about it, just wanting to make sure this idea is resurrected, since I introduced it nearly 2 years ago now
<sarang> Thanks sgp_
<sarang> In the interest of time, Isthmus please go ahead!
<Isthmus> Everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
<Isthmus> https://usercontent.irccloud-cdn.com/file/tXHruCE0/image.png
<Isthmus> This has implications for privacy of all users. For example, I have a list of blocks mined by the pool that added 60 B null padding to each miner transaction. When this person creates multiple-input transactions to claim the reward, ring signatures offer them no protection.
<Isthmus> (Multi input + miner fingerprint is statistically noisy, so we know when those outputs are really spent, and can rule them out as decoys in other transactions.)
<Isthmus> To avoid fingerprinting, it's important that any implementation mimics the full hierarchy on any block. For example, if we accommodate {nonce, pool, proxy}, then every miner (including solo mining core software) should put random data in pool & proxy. Otherwise we've just made a fancier way to leave the same fingerprint. :-P
<Isthmus> Anyways, others in this room have made a lot of progress on how to address this, so I'll let them jump in
<sarang> Anyone have anything to add in particular to this?
<suraeNoether> nope, but I have to get going
<sarang> OK, suraeNoether: any brief update before you go?
<sarang> Otherwise, no worries
<koe> sarang is this the encrypted timelock? https://justpaste.it/2754y
<suraeNoether> just that sarang and i have been having some extremely deep discussions about unforgeability in CLSAG and the crappiness of linkability models... we are nearing some very valuable improvements to d-CLSAG as written...
<suraeNoether> i'll let him describe more; i've also gotten my matching simulations (apparently) working correctly on my matching-mojojo branch of mrl-skunkworks
<suraeNoether> other than that, i have to get going
<suraeNoether> sorry :(
<suraeNoether> i'll drop in later today for more of an update
<sarang> koe: you include the auxiliary timestamp in the signature's extra commitment in the model I worked up
<sarang> Isthmus: anything else that you hoped to share?
<sarang> (sorry, trying to ensure everyone gets a chance to finish their presentations)
<Isthmus> Thanks, I'm outta new material
<sarang> OK, thanks Isthmus
<sarang> I worked up some stuff on timelocks (shared earlier), did a blag post with sgp_ relating to supply auditing (to answer questions that often come up), and got into the weeds on security models relating to linkability
<sarang> Linkability meaning the formal definition used in linkable ring signatures, not any particular transaction linking
<sarang> koe: what you have may be algebraically equivalent; I'll take a look shortly
<sarang> OK, did anyone else have something to share that was missed?
<sarang> So many things to discuss today!
<koe> well does anyone have thoughts on enforced sorted TLV format for the extra field? I have spammed up the channel a bit recently, with that topic
<sarang> Can you recap the benefits and tradeoffs briefly, for those who didn't see the earlier discussion?
<moneromooo> If someone wants to stuff some random data in there, it's as visible as now, no ?
<koe> and pursuing coinbase extra field standardization by seeking an inter-pool committe
<sarang> (note that monerologs.net has logs of this and other channels available)
<moneromooo> What's an inter-pool commite ?
<koe> committee between pools
<koe> composed of
<moneromooo> Oh you mean just talk to pool ops ?
<koe> lol yeah
<koe> these things are called standardization committees in industry
<koe> benefits of enforced sorted TLV + guidelines for use: a) makes sure all implementations are using the same essential format for constructing extra fields, since without guidelines or structure each implementation is ad hoc; b) for those who are privacy minded, there will be a clear way to blend in with other like minded implementers (for example,
<koe> who knew that the code base sorts field entries, but at least one live implementation does not?); c) leaves extra field almost as open ended as it is now, so those who choose opt-out privacy (choose to stand out from the crowd) for whatever reason, can still do so trivially
<sarang> In the earlier discussions, were there particular opinions opposed to it?
<sarang> If so, why?
<koe> tradeoffs: a) it may have limited real impact on transaction indistinguishability, especially among coinbase tx if most pool operators aren't on board; b) implies no stricter enforcement of the field will be pursued (which would directly address questions of indistinguishability; c) so far as coinbase tx go, many pools publish their mined blocks
<koe> (counter argument is Monero development is focused on on-chain, and can't concern too much off-chain activity)
<sarang> Noted; thanks
<sarang> Since you were interested also in the hidden timelock construction, any other thoughts on that as well (from your link above)
<koe> actually I just felt inspired, and wanted to confirm my understanding
<sarang> Keeping in mind that the range proof can be absorbed into the existing one, meaning no effective change in size or verification for that portion of it
<sarang> Your construction appears algebraically equivalent to what I listed
<koe> I dont know enough about CLSAG to make a real judgement
<sarang> The CLSAG part could apply to MLSAG as well
<koe> Perhaps if we knew how much timelock is being used in the wild
<sarang> The only difference is how the commitment to zero is handled in the signature
<sarang> In MLSAG it would be _very_ expensive, but in CLSAG it adds only a single auxiliary linking tag, and makes the verification multiexp a bit more expensive
<koe> oh nice, I was imagining all those extra mlsag scalars
<sarang> If people think it's worth seriously considering, I can get more precise timing estimates on those curve operations
<sarang> Yeah, for CLSAG you don't add scalars
<sarang> It is in no way worth it for MLSAG
<sarang> either in size or extra verification
<sarang> The current CLSAG data has some custom curve-op code for efficiency that wouldn't apply to this new 3-CLSAG timelock construction
<sarang> (the Python code is not suitable for timing, only to see how it works)
<sarang> Anyway
<sarang> We're way over time
<sarang> Anyone have ACTION ITEMS for this week they want to share?
<sarang> (I find action items useful for me, to help prioritize and share those priorities)
<atoc> I will continue working with Surae. Hopefully I can share more next week.
<sarang> I have several... some additional work writing up comparisons of linkability definitions between a few papers, to get some timelock numbers (if it's seen as useful), and some data analysis relating to sublinear protocols
<sarang> Oh, and one additional note... the IEEE S&B conference is coming up later this year
<sarang> https://ieeesb.org/
<sarang> Both suraeNoether and I are on the program committee
<sarang> It's a great event, and is seeking papers
<sarang> If you have some work that could be worth sharing, consider writing it up formally and submitting
<atoc> Ok cool
<sarang> (you should note any conflicts of interest with the program committee if you feel they apply to you)
<sarang> I went to this event a while back, and it had great presentations (but was not streamed)
<sarang> Any other comments, questions, or final remarks before we adjourn?
<sarang> Normally there isn't so much to cover in one meeting; it's a great problem to have :D
<sarang> Going once...
<sarang> going twice...
<koe> I will be focusing on ZtM2 multisig, which may be done by next meeting in which case Ill start in on bulletproofs; and anything else that comes up, perhaps work on updating the fee priority multipliers for surge situations (emails with ArticMine)
<atoc> Last thing, I didn't realize IEE had Security and Privacy on Blockchain. That's pretty cool.
<sarang> I'm happy to help with bulletproofs koe; I have a branch for it in my ZtM repo
<sarang> atoc: it's a great event
<koe> all in good time :)
<sarang> I'm very happy to be asked to be on the committee :)
<sarang> OK, thanks to everyone for attending, even though we went over the usual time
<atoc> Yeah that's awesome!
<sarang> Logs will be posted shortly to the GitHub issue
<atoc> It was good. There was a lot of material.
<sarang> Discussion can of course continue
<sarang> (I just need a stopping point for the posted logs!)

Logs for the Community Meeting Held on 2020-01-18

Sat, 18 Jan 2020 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/428
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<ErCiccione> Ciao
<almutasim> Hi.
<sarang> Hello
<v1docq47[m]> Hi
<netrik182> hi
<sgp_> ping rehrar
<sgp_> welcome everyone
<sgp_> thanks for showing up 30 minutes earlier than usual :)
<vtnerd> hi
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<rehrar> Present.
<sgp_> A new edition was just out yesterday I believe
<sgp_> The community planning for the Konferenco has been underway. Updates on that later.
<sgp_> Does anyone have community (non-workgroup) updates to share?
<sgp_> apparently not :)
<sgp_> 3. CCS updates
<sgp_> Funding required:
<sgp_> 3 months part time work on Getmonero.org https://ccs.getmonero.org/proposals/ErCiccione-website-jan-march.html (92.42 / 174 XMR)
<sgp_> Ideas (to be discussed):
<sgp_> Locha Mesh, private transactions and sync over a resilient long-range radio mesh network https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/115
<rehrar> We're switching to Fridays.
<sgp_> there were some concerns about the cost and project management (clear project milestrones) on this one
* binaryFate lurking
<sgp_> the total amount was reduced to 150 xmr
<cankerwort> hola
<sgp_> any other comments? thanks to everyone who left comments on gitlab
<vtnerd> yikes, is there any more technical details on what they plan to do?
<sgp_> vtnerd: I am not sure, but I recommend asking on gitlab since they have been responsive so far
<binaryFate> do they plan to post an updated proposal soon?
* needmonero90 lurks while sleeping
<sgp_> binaryFate: they already updated the amount
<vtnerd> ah crud yeah they have a link. I can't respond now because this is the first I've paid attention to it. My primary concern would be the in the routing code, its not trivial for this type of thing
<binaryFate> most comments were strongly suggesting to be more specific on milestones
<sgp_> they focused a bit more on the goals and roadmap
<sgp_> https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/115/diffs?commit_id=1031a2e444255e5fa8138601ef746e8b37900a18
<vtnerd> hmm its very much a wip I think
<vtnerd> my only comment is that this has more risk than the usual CCS for monero feature
<binaryFate> agree. On the other hand this will have visibility beyond Monero circles.
<sgp_> thanks vtnerd, please ask specific questions on gitlab too so that the proposal can get better
<ErCiccione> I haven't had time to look at the proposal after mu last comment, but i see that one of the milestones is about getting the localization workgroup translate their docs
<ErCiccione> that's very unlikely to happen
<vtnerd> yes, if it works ... very awesome
<ErCiccione> i don't really think we have the resources for that, we already struggle for our own stuff
<rehrar> what would it mean to take this on as Monero Project project?
<sgp_> rehrar: have they given any indication they have any interest in that?
<rehrar> If they haven't, then I wouldn't really be for funding this.
<sgp_> explain please
<cankerwort> The tech sounds awesome but I'd be interested in practical limitation estimated like time to broadcast a transaction and range
<rehrar> explain? hmmm...
<cankerwort> although the name is not even in esperanto
<rehrar> Well, I can see how developing this tech might be good somewhat, but it's kind of general in its application (not really Monero-only focused) as I understand.
<rehrar> and if it's something that can benefit a lot of other projects, Monero is fronting a good amount of the bill instead of others.
<rehrar> So a way to offset this cost is to have it be a Monero Project project. Similar to OpenAlias. It benefits others if they want it, but it's distinctly "From Monero people"
<sgp_> rehrar: : I think requiring that the CCS only gives $$$ to "Monero Project" projects is far too restrictive and is really a new precedent, so I'm curious if you're focused on that part or the main nature of the project's goal (Monero-focued or elsewhere with Monero as a feature)
<rehrar> the marketing aspect of that offset the cost of its creation.
<ArticMine> Bandwidth is my question
<sgp_> my recommendation then is to ask if they want to do that, but I would personally understand if they don't want to
<needmonero90> I am against the proposal from a sustainability perspective. Funding a development *team* is not the goal imo, I think we should strive for funding key people for projects that already have a decentralized/communal ethos. If they can't get developers without paying them, we won't be able to bootstrap the system to work without money greasing the wheels constantly
<needmonero90> I've been trying to find a way to express the value of 'coordinators' in the ecosystem that are always available to manage/direct/help their particular corner, so that the people working on the actual open source part have low friction
<needmonero90> And that kind of position carries with it an expectation of availability
<needmonero90> So paying for that particular position, once it emerges, is warranted, but not a full team
<needmonero90> The MRL is a good example, they're pretty much always available to talk about stuff, which is a big deal. They buffer ideas and conversations for the actually decentralized research team
<needmonero90> Who has no expectation of availability
<sgp_> in this case "a full team" is 2 people I believe
<cankerwort> maybe an element of availability and/or dedication to reddit posts and updates would help?
<needmonero90> I mean, the issue is more about being available (for a decentralized project)
<sgp_> we've spent a good amount of time on this topic, so let's only give it another minute or two
* needmonero90 nods
<binaryFate> Seeing their interactions on twitter, they are getting *a lot* of praise from bitcoin/grin/cypherpunk larger crypto space.
<binaryFate> In their own answers I did not see Monero mentioned a single time.
<binaryFate> So on the plus side I see a lot of potential visible PR for Monero in return for contributing, on the minus side I fear lack of Monero-specific dedication from the project team
<sgp_> looks like marketing is an important part to focus on more
<rehrar> binaryFate ^
<sgp_> without overstepping into the whole thing, I think it's appropriate to expect some recognition
<ErCiccione[m]> i think if the proposal get approved, we should require recognition
<sgp_> any final comments?
<ErCiccione[m]> like put it clearly in the website and everywhere else that part of the development is funded by Monero
<ArticMine> That is reasonable
<binaryFate> if we make it more explicit on either part that this project is also about marketing for Monero, then the proposal has more value as we don't just look at the neaty greaty technicals
<sgp_> cool, moving on
<sgp_> v1docq47: video creation / translations into russian (february - july 2020) https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/116
<sgp_> in my personal opinion, this is a great proposal. I'm blown away by the amount of work they do
<sgp_> and they recently made a Trello board so we can more easily see what they are working on
<sgp_> I appreciate that a lot
<cankerwort> also, given grin/btc transactions are much smaller, their tech would work better with those coins
<ErCiccione[m]> yeah, they are also very responsive to reviews and they contact me privately sometimes to have clarifications on the localization process. It's a +1 from me
<sgp_> cool, any other comments?
<sgp_> A Monero-centric Merchant Marketplace https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/117
<sgp_> I don't personally have any comments here yet
<rehrar> Ten hours. Quite new. Let's get them to hop on this channel to answer some questions.
<sgp_> yeah, also Reddit, etc
<sgp_> we can proceed then
<sgp_> 4. Workgroup report
<sgp_> a. Localization workgroup
<sgp_> ErCiccione[m]: any update?
<ErCiccione[m]> Not really. Soon i will make a general refresh of the strings in gui and cli
<ErCiccione[m]> so that translators can work on the new merged stuff
<ErCiccione[m]> i just want to note
<ErCiccione[m]> that there are many suggested strings on weblate (translate.getmonero.org), but no reviewers to take a look at them,
<ErCiccione[m]> so, after the refresh, i will make a call for translators and i ask the community at large to spread it as much as possible, because there is a lot to do
<ErCiccione[m]> i will probably refresh the CLI first, because the GUI folks are changing a lot of strings and i want to wait for them to be finished first
<ErCiccione[m]> that's it
<almutasim> Sounds great.
<netrik182> ErCiccione[m]: you can ping me too for translations
<sgp_> thanks ErCiccione[m]
<sgp_> b. GUI workgroup
<sgp_> There was a point release. Binaries are not out yet. https://github.com/monero-project/monero-gui/releases/tag/v0.15.0.3
<sgp_> c. Outreach workgroup
<ErCiccione[m]> netrik182: Great to hear that. Keep an eye on #monero-translations :)
<sgp_> almutasim: can you give an update?
<almutasim> Sure. We put out a piece on Chinese perspective. We have a piece ready to go on RPC-Pay. But it is waiting on an infrastructure upgrade.
<netrik182> sgp: there's currently much effort being made to update server backends
<almutasim> We also have a piece started on paper wallets
<ErCiccione> About RPC-pay, would be great to have a moneropedia entry for that on getmonero.org
<sgp_> https://www.monerooutreach.org/monero-china-west.php
<ErCiccione> or a dev guide
<almutasim> That’s a good idea.
<ErCiccione> basically, should be on the website one way or another
<sgp_> 100%
<almutasim> Right
<almutasim> It is really neat. We have been testing it with our servers.
<sgp_> I look forward to seeing your system where people can get paid, where you effectively serve as a mining pool for RPC-pay
<sgp_> any other updates?
<almutasim> we are working with endogenic on a nice document he has on Wallet auditing.
<almutasim> That is about it.
<sgp_> nice
<sgp_> d. Hardware workgroup
<sgp_> we can come back to this is msvb-lab is present
<sgp_> e. Konferenco workgroup
<sgp_> lots of work has been ongoing here
<sgp_> weekly meetings on Wednesdays at this point
<sgp_> tentative date June 13-14
<sgp_> we have a tentative location, but there are many outstanding questions
<sgp_> it will be in Berlin
<sgp_> any really quick konferenco questions? you can help out in #monero-konferenco
<sgp_> events will be livestreamed as always
<sgp_> ok, moving on then
<sgp_> f. Monero Research Lab
<sarang> Hey there
<sgp_> sarang: can you give a brief update please?
<sgp_> :)
<sarang> Sure
<sarang> Over the past couple of weeks or so, the Triptych preprint was posted and got some good coverage
<sarang> It's undergone some updates as well
<sarang> That's a linkable ring signature construction that scales well
<sarang> sgp_ and I worked up a blag post on supply auditing that will appear soon
<sarang> I worked up some material on hidden timelocks, which could be useful but need more analysis
<binaryFate> tldr hidden timelocks?
<sarang> I am still waiting on any final review notes from suraeNoether on the CLSAG overhaul
<sarang> binaryFate: it's possible to replace "plaintext" timelocks with commitments and clever range proofs
<sarang> So you can show that the timelock for an (unknown) input has passed without revealing it
<binaryFate> to avoid standing out?
<sarang> Yep
<binaryFate> gotcha
<sarang> It was designed for DLSAG, but also has more general applicability
<almutasim> That sounds awesome.
<sarang> And the new CLSAG security model is being ported to DLSAG as well, along with some key aggregation math
<needmonero90> Math wizards
<almutasim> That sounds awesome.
<sarang> It remains to be seen if the increase in tx size would justify hidden timelocks
<sgp_> re auditability, I need help making a better auditability image still, so let me know if you have ideas https://repo.getmonero.org/monero-project/monero-site/merge_requests/1207
<sgp_> I probably won't be able to personally work on this until Sunday or Monday
<sgp_> g. Website workgroup
<sgp_> ErCiccione: can we have another round of updates please? :)
<ErCiccione> gladly
<ErCiccione> so,
<almutasim> The wallet auditing document is related to that. A draft should go up on TAIGA tomorrow.
<ErCiccione> A lot is going on. We have a lot of pull requests ready to go and they should be merged at the beginning of next week
<ErCiccione> right now i'm focusing mostly on getting the website (at least the 'core' part of it) on Weblate, because right now making any change, means that that change needs to be ported to all languages
<ErCiccione> that results in a lot of time spent for that, which is very annoying for everybody and suck a lot of time that could be used for something more productive.
<ErCiccione> I'm running tests and Weblate seems to be reacting nicely, even if YAML files can be a bit troublesome and may happen that stuff don't get parsed
<ErCiccione> to avoid that i'm making extensive tests on my personal version, which is a copy of the instance hosted on translate.getmonero.org
<almutasim> That makes a lot of sense. I honestly don’t know how you handle the current situation.
<ErCiccione> almutasim: a lot of swearing
<almutasim> Ha!
<ErCiccione> ;)
<ErCiccione> but yeah it's extremely annoying, especially now that we are updating a lot of stuff and all languages need to be up to date
<sgp_> cool, thanks for your sacrifice
<ErCiccione> so, that's the priority for me at the moment. After that i will try to put other parts of the website on weblate (footers and others), which structure make much harder for weblate to parse them and could require some substantial changes to the structure of those documents
<ErCiccione> :P
<ErCiccione> beside that, next will be the roadmap and the FAQ section
<ErCiccione> ah
<ErCiccione> the onion mirror should be up at the end of this month according to pony
<sgp_> oooh fancy
<ErCiccione> Yeah, everything is ready and some prep PR already got merged
<ErCiccione> if people are interested in the development of the website, please join #monero-site and visit repo.getmonero.org
<ErCiccione> reviews of Pull requests and issues are very welcome
<sgp_> I love the website workgroup since it's something anyone, regardless of skill, can help with. there are so many different things to do and an unlimited amount of necessary work
<sgp_> thanks ErCiccione
<sgp_> 5. Open ideas time
<almutasim> And with so much impact!
<sgp_> I'm going to extend the meeting 10 minutes to fit open ideas time in here
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<ErCiccione> absolutely sgp_. I will try to improve our docs to make easier for newcomers to contribute
<rottensox> totes missed it but caught up already.
<ErCiccione> I think we should talk about /r/moneromining folks, it's annoying i know, but it's a discussion that must happen
<ErCiccione> for reference: https://repo.getmonero.org/monero-project/monero-site/merge\_requests/1195
<sgp_> ErCiccione: indeed, this is going to be a long discussion though
<rottensox> i am with needmonero90 on opposing Locha Mesh for XMR.
<ErCiccione> yeah i understand sgp_.
<rottensox> speaking from experience, nobody uses locha mesh in venezuela. nobody.
<ErCiccione> Right now we are removing the mention from getmonero, but we should do more
<sgp_> background context: lead mod is acting rash and making racist statements, calling other people who disagree "snowflakes." Basically using the subreddit for their own purposes rather than for Monero mining
<sgp_> I still need to reach out to my Reddit contacts, can do that today after the coffee chat
<sgp_> but they probably won't do anything
<asymptotically> they wouldn't de-mod him for putting that kind of stuff in the description?
<sgp_> needmonero90 is sitting on a backup subreddit we can switch to with a good amount of effort
<sgp_> asymptotically: not really, Reddit is weird like that
<ErCiccione> i think the idea of the migration to /r/monerominer or whatever was called, is the only option we have left
<sgp_> ErCiccione: yes, I think we shoudl prepare to transition to that
<sgp_> maybe we should set aside specific discussion time
<sgp_> to plan the transition
<ErCiccione> Yeah, we should.
<lza_menace> I made the "A Monero-centric Merchant Marketplace" MR - I'm usually not available during these community meeting time blocks. Long form discussion in Gitlab/Reddit would be better
<sgp_> ErCiccione: can you and needmonero90 please coordinate a time and invite others as needed?
<needmonero90> Sure.
<sgp_> lzamenace: cool, please share on Reddit too
<ErCiccione> maybe a dedicated meeting or something. I know binaryfate wants to talk about the fact that the chats are getting a bit bad lately, we could include that discussion as well
<sgp_> will help kick off discussion
<ErCiccione> Sure thing
<lza_menace> sgp: :thumbsup: - will do - yall have a great weekend
<sgp_> " the chats are getting a bit bad lately, we could include that discussion as well" what chats?
<asymptotically> #monero-markets and #monero-pools going off-topic i think
<sgp_> ah, got it
<binaryFate> ah yes. The channels. -pools, -markes and even sometimes #monero
<sgp_> definitely a related item
<sgp_> you all are welcome to use this channel for discussion. that's what it's for :)
<sgp_> oh I have one thing I wanted to mention during open ideas time
<sgp_> I have a self-hosted Wekan (open-source Trello copy) instance now available. I’m happy to add your project if you are interested. Please message me for details. I’ve found it more useful than Taiga for many project management needs.
<sgp_> Here’s an example for the Konferenco: https://monero.sandcats.io/shared/f6usdnbIFv3mGp09hTFRkEbz38CHn2KHyM04V-Nhmp-
<sgp_> anyone else have an open ideas topic? we're nearly out of time
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 1 February at 17:00 UTC.
<sgp_> A Coffee Chat begins shortly after this meeting: https://youtu.be/YqMcz3XOS6M
<sgp_> please PM me ASAP if you can participate. I'll distribute Jitsi links right away
<sgp_> The following Coffee Chat is on Saturday 8 February at 17:00 UTC.
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

About supply auditability

Fri, 17 Jan 2020 00:00:00 GMT

We often hear questions and concerns about the topic of supply auditing, and how it applies to different projects. This post is intended to briefly and informally discuss the practical tradeoffs that projects make in their designs as they apply to the soundness of supply. It intentionally glosses over some technical details that, while important and subtle, may serve to muddy the waters for many readers.

Let's define what we might mean by supply auditing and soundness. When the term is used, it is often undefined in a way that doesn't help the discussion. For some people, it might mean that in any particular transaction, you can see the amounts being used and do simple arithmetic to convince yourself that no new assets were created in an attempt to game the supply. Transparent assets like Bitcoin or Ethereum do this; look at any transaction in a block explorer, and you'll see the amounts consumed and generated. For others, it might mean that whatever more complex mathematics is used for balance assertion is unlikely in practice to lead to problems that could allow unwanted inflation.

The transparent approach to supply is a design choice, and it has tradeoffs. As has been debated endlessly in blog posts and academic papers and conferences, you might not want the amounts involved in your transactions to be visible to the entire world. This could lead to personal risk, but also reduces the fungibility of the asset and can lead to all sorts of adversarial heuristics or shenanigans involving transaction acceptance. Transparent amounts, even when denominated, can be detrimental for privacy and fair use.

Other projects make different design choices intentionally, using different mathematics. In assets that focus more heavily on fungibility, amounts are typically not presented in the clear. Take popular projects like Monero or (shielded) Zcash, for example. In these projects, amounts are hidden using cryptographic structures called Pedersen commitments. To show that a transaction balances, the sender generates a signature or proof that uses clever (but well-understood) arithmetic on these hidden amounts to demonstrate to the network that no new assets were created. This helps with indistinguishability, which is beneficial for fungibility, security, and privacy.

To examine the different kinds of risk between transparent and "opaque" design choices, let's consider three (intentionally) broad types of problems that could arise:

Cryptographic hardness assumption breaks
Implementation flaws leading to detectable inflation
Implementation flaws leading to undetectable inflation

The first class is a break of a fundamental cryptographic hardness assumption. Modern digital security relies heavily on assumptions that certain mathematical problems (like the discrete logarithm problem) are computationally difficult. It is not possible to prove that these problems are hard, but decades of research and use implies this. If an adversary were able to efficiently solve the discrete logarithm problem, for example, they could recover Bitcoin, Ethereum, Zcash, or Monero private keys and steal funds. But relating to supply, solving related hardness problems would allow an adversary to represent a different amount in a Pedersen commitment than was originally intended, fooling the network and inflating supply in an opaque asset. In short, breaking soundness is not a practical risk. The computational complexity required to pull off such a stunt (barring an arguably far-off-in-the-distance breakthrough that breaks the entire internet's security) is absurdly, time-scale-of-the-universe high.

The second class is implementation flaws leading to detectable inflation. These can come in all shapes and sizes, and have affected transparent assets (like Bitcoin in two separate incidents) and opaque assets (like Monero). In the case of one Bitcoin incident, inflation did occur, but nodes chose to fork the blockchain to revert inflated funds. In the other linked Bitcoin incident and Monero incident, it was verified that no inflation occurred.

The third class is implementation flaws leading to undetectable inflation. Such flaws could arise in many ways, but are limited to opaque assets (like Monero or shielded Zcash) where it is not possible to simply count the currently-available supply. Such a flaw affected Zcash. In this case, it is worth noting that the use of transparent fund migration means that an attempt to move enough exploited funds through the transparent Zcash pool could be detected and would result in any remaining funds (including those of honest users) being permanently frozen. It could be possible to modify the Monero protocol to produce similar supply detection, but this introduces additional risks, reduces privacy and fungibility, and would still require a decision relating to fund freezing; there are no plans to do this.

So what's the takeaway? It's very important to note that not all inflation-related problems are created equally. It's safe to say that the practical risk of an implementation flaw is far greater than that of a common computational hardness assumption break.

Notably, the use of a transparent asset is not sufficient to guarantee safety of funds. It is true that supply transparency means that inflation can in theory be detected by an appropriate implementation, but the remediation of supply inflation could mean that transactions are reverted and honest funds are affected. Further, transparent assets would not be immune from a (very unlikely) break of a cryptographic hardness assumption that results in key recovery and theft of funds.

In contrast, the use of an opaque asset introduces the risk of implementation flaws that may or may not be detectable because of the underlying mathematics of commitments and more complex proving systems. The use of mitigating approaches like transparent migrations can assert eventual available supply consistency, but this comes with the risk of losing honest funds too. Reviews and external audits of code and new mathematical constructions becomes especially important as a way to mitigate, but certainly not eliminate, these risks.

At the end of the day, there are tradeoffs inherent in supply-audit design choices. You can choose to represent amounts in the clear, like Bitcoin does; you can be sure that the supply is what you expect it to be (or fork to ensure this in case of exploited inflation), but you sacrifice fungibility and could expose users to personal risk. Or you can choose to hide amounts like (shielded) Zcash or Monero do; you improve privacy and fungibility, but at the cost of offloading supply soundness guarantees to the correctness of proof and signature constructions.

If your personal use case requires an absolute, 100%, no-holds-barred guarantee of supply, and you understand the risks inherent with this, then you need a transparent asset. But if you want to mitigate the risks associated with visible amounts, and are willing to accept the shift in risk onto proof system implementation correctness, then choose an asset focused on privacy and fungibility. There's no silver bullet here, but a necessary and careful analysis of your priorities and the tradeoffs you're willing to make for them.

Logs for the MRL Meeting Held on 2020-01-15

Wed, 15 Jan 2020 00:00:00 GMT

Logs

<sarang> GREETINGS
<sgp_> hello
<almutasim> Hi.
<ArticMine> Hi
<koe> hi
<vtnerd> hi
<suraeNoether> Wow what a turnout!
<atoc> Hello
<rehrar> hi
<sarang> Let's continue with ROUNDTABLE discussion
<sarang> suraeNoether: anything of research interest to share?
<ajs> ajs archived the channel.
<sgp_> um.... is the channel now gone on Mattermost?
<suraeNoether> not yet... Right now I'm just copy editing CL sag, working on matching code, and looking into possible speedups for triptych
<ajs[m]> ?
<suraeNoether> I expect about an hour before clsag is done
<ajs[m]> I thought it was just for me
<atoc> I noticed it disappeared too.
<sgp_> it's gone
<rehrar> lol
<rehrar> give me a sec
<suraeNoether> Hmm. Who was running it?
<sgp_> sorry for derailing, something to fix later
<suraeNoether> Oh
<suraeNoether> Moving along :) what about you, Sarang?
<sarang> Sure
<koe> for those who want to access logs later: https://monerologs.net
<ajs[m]> lol
<sarang> The Triptych preprint has been updated with new efficiency data and some minor typo corrections (IACR 2020/018)
<sarang> It will appear on monero-site as MR 1197
<sarang> The DLSAG paper is being revised for its publication in the FC 2020 proceedings
<sarang> and we're working on updating the security model for later journal submission
<sarang> I have a monero-site MR ready to go for the CLSAG updates (MR 1202) as soon as suraeNoether's review is complete
<sarang> (and I get it updated on IACR)
<sarang> I did some major overhauls on the curve libraries that I use for ed25519 and ed448 testing (for prototyping only; don't use them in production)
<sarang> That included porting them to a bunch of other research projects
<sarang> I also did some updates on my Lelantus code to fix some Fiat-Shamir transcript issues
<sarang> And that's about it
<sarang> Does anyone else have research to share?
<sarang> We can also have any questions as well
<atoc> Currently I have been just familiarizing myself with Monero Research
<atoc> I have read quite a bit of Zero to Monero, and I also looked at the bipartite matching project: https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
<atoc> I did have some questions, but I can go through them later with surae perhaps?
<suraeNoether> Sure, now is fine with me too
<suraeNoether> It's on topic :P
<sarang> Sure, go ahead
<koe> speaking of ZtM, thanks to Articmine the dynamic fee section has been greatly elaborated; anyone curious about all the justifications and derivation and analysis can find it in the latest draft; all that remains before I can publish are multisigs, bulletproofs, and proofreading (each of which will take a long time admittedly)
<koe> https://www.pdf-archive.com/2020/01/15/zerotomoneroebookmaster-v1-0-17/zerotomoneroebookmaster-v1-0-17.pdf
<atoc> Ok cool, well can you briefly give a high level description of this project? From what I understand so far is that this project will be used for user analysis along with statistical models, but hearing an overview from in your words would be nice.
<rehrar> it's good to see ZtM getting the update :)
<suraeNoether> Gotcha okay so first think about the Monero blockchain using two columns. List all of the one-time output keys from coinbases and from other transactions on the left and list all ring signatures or if you like key images on the right-hand column
<suraeNoether> You can then go and draw edges between one time keys and ring signatures indicating ring membership. So if I publish a ring signature with ring members a b and c, my ring signature on the right would have edges connecting it to the outputs a, b, and c on the left
<suraeNoether> These are what I call red edges in my code, and I also indicate blue edges connecting ring signatures on the right with the new fresh transaction one time keys that are output from their respective transactions on the left
<sarang> koe: I asked this before, but how detailed are you looking to get with bulletproofs?
<sarang> I fear you may end up essentially rewriting their entire paper, with little benefit to the typical reader
<suraeNoether> So the Monero blockchain can be visualized as this two-colored bipartite graph with one-time keys on the left, ring signatures on the right, red edges indicating ring membership, and blue edges indicating output relationships
<Isthmus> Hey @koe I owe you an email. I have some protocol notes, but have just been super swamped.
<atoc> Cool cool, I
<Isthmus> I'll try to get the email out in the next few days
<atoc> I'm with you*
<scoobybejesus> i am sort of busy, but wanted to throw out a question (in other words, don't let this question interrupt the current line of talk). a response anytime would be great, though
<scoobybejesus> I was thinking about how people complain about outputs getting locked up for 10 blocks. Consequently one must send to themself a multi-out txn to prevent that from happening. What if we made the standard tx 2-in and 3-out (2 change)? And maybe set them to send to different accounts, so they take on independent/divergent decedent txn histories. Was curious if MRL had thoughts/impressions
<Isthmus> I also got halfway through updating Big Bang paper, but then got distracted. Hoping to finish that this weekend or next.
<suraeNoether> The ground truth of the situation is that each ring signature has a ring member that is the true signer of the signature, so for every ring signature with a bunch of red edges leading to a bunch of one-time output keys, somebody who's trying to track transactions is trying to pick the true spender from these red edges
<suraeNoether> And this is called the matching problem in the graph theory world, sometimes also called the assignment problem, sometimes called the assigned marriage problem lol
<suraeNoether> So somebody who is trying to track transactions on the Monero blockchain is really trying to find a maximum matching on the Monero blockchain, linking signatures to true spenders
<sgp_> scoobybejesus: I'd rather find ways to reduce the lock time
<koe> no worries Isthmus :); sarang that's a valid concern and Im really not sure since I don't actually understand bulletproofs yet; I think if the bulletproofs paper is clear enough it will be fine to point people in that direction; I dislike the idea of leaving things open ended, but maybe it's just a useless hangup ^.^
<suraeNoether> The signatures themselves give nothing away about which edge is supposed to be the true spender, so without any additional information the attacker just has to guess, and so every possible maximum matching is equivalently good in this world
<atoc> Ah okay, I see. It seemed as if you were trying to find out if there was a way to trace back transactions.
<suraeNoether> I am kinda
<suraeNoether> So my graph theory python code allows you to build a graph, and then find maximum matchings, and if you wait the edges, it'll find the heaviest weight matching so that somebody using extra metadata can do better than just guessing at random
<suraeNoether> Weight*
<almutasim> How do you assign weights?
<suraeNoether> Right so that's outside of the scope of graph theory and in the scope of my simulations...
<almutasim> Ah. Are they probabilities?
<atoc> Is this where statistical models come into play/
<suraeNoether> Yep. The way that I'm trying to do this is I'm simulating an economy between Alice, Eve and exchange with KYC information, and Bob representing all background players in the Monero economy. I'm even telling Eve the information about the Markov chain from the beginning, which models eves perfect ability to learn your habits.
<suraeNoether> So this Eve is able to wait the graph using some null hypothesis about user behavior
<suraeNoether> once she does this, even though she doesn't know the ground truth reality of the blockchain, she can find a maximum likelihood estimate which corresponds to a maximum weight matching
<sarang> s/wait/weight/ ?
<suraeNoether> Weight* sorry I'm on voice to text
<suraeNoether> So the simulator simulates an economy, strips information out of the graph that Eve doesn't know, hands the blockchain to Eve, Eve weights the graph and compute some maximum likelihood estimate, and this maximum likelihood estimate is compared to the simulators ground truth
<suraeNoether> When things are working I get preliminary data that suggests that Eve is really really bad at this game Even though she's given perfect information about Alice's habits
<suraeNoether> But that's all preliminary because my code is only intermittently working and I am currently in the midst of refactoring it to be simpler.
<almutasim> That's encouraging.
<atoc> Quite interesting surae. I understood about half of it before, but given you're description I see the goal of the project now.
<atoc> Ah I see, was MoneroLink done by the Monero community or third-party?
<surae>: The fact that it was written by people who had a financial interest in succeeding compared to Monero was viewed as very suspicious by a lot of folks.
<koe> suraeNoether have you collected a list of tracability analysis papers? for example sarang mentioned a preprint earlier; or maybe Isthmus has that list
<surae>: Andrew Miller from Zcash and a couple of other folks who were involved with Zcash were authors
<surae>: Actually you know, Sarang may have a better list than I would... A paper came out last year describing a game not dissimilar from my graph theory game and they named it after sun tzu. But I can be more helpful in finding background papers. Basically any papers on the traceability of anonymous communication networks has some degree of applicability to the Monero blockchain
<surae>: "perfect matching disclosure attacks" is a general paper that was critical in the construction of the matching stuff
<atoc> I see I see. So I see a couple of todos listed (unity tests and another). What are some important priorities for this project? I feel I can contribute to this project as a start.
<atoc> Just a little background about myself: I'm an academic researcher in theoretical computer science (neural algorithms).
<surae>: Let's talk about that after the meeting
<atoc> sure
<Isthmus�> Dang, I got bumped off IRC
<Isthmus�> Can't log back in
<surae>: speaking of the meeting, isthmus tells me that he has lost access to IRC... And I also happened to lose access to IRC and I'm just using the keybase bridge
<Isthmus�> *IRCcloud
<surae>: it looks to me like IRC cloud has gone down which means the vast majority of the people in this room are probably not here anymore
<Isthmus�> @atoc nice to meet you, excited to contribute
<Isthmus�> *to collaborate
<Isthmus�> Sorry, I'm in a meatspace meeting too
<surae>: So we'll give it a few more minutes and if I receive cloud doesn't come back or if nobody else speaks up, I say we adjourn the meeting
<surae>: If irccloud*
<Isthmus�> So I just realized that we aren't fully utilizing the archival network data. But I'll wait for our IRCcloud comrades to return
<sgp_> yes, irccloud seems to be down for everyone
<surae>: I had a question for isthmus about the archival network and lock times
<Isthmus�> sup
<surae>: I want to know the distribution of fork lengths observed so far, and I also want to know the distribution of forklengths experienced by a new node syncing
<atoc> isthmus nice to meet you as well.
<atoc> hmm okay and sorry what do you mean fork lengths?
<surae>: As in Nakamura consensus resolving a fork
<surae>: Nakamoto
<surae>: WTF that was autocorrect too not voice to text
<almutasim> It should be correcting the other way.
<atoc> I see, alright I will begin looking into this.
<surae>: Isthmus actually specifically I want an estimate of the parameter r under the null hypothesis that fork lengths are negbinom(p, r)
<surae>: I think lock time has to be proportional to r to protect most transactions from most rollbacks
<surae>: Okay since irccloud is now fartcloud, I say this meeting is adjourned.
<koe> good meeting! happy day to yall
<surae>: Good seeing you around koe
<sgp_> thanks
<almutasim> Thanks. Good meeting.

Logs for the MRL Meeting Held on 2020-01-08

Wed, 08 Jan 2020 00:00:00 GMT

Logs

<sarang> GREETINGS to everyone
<almutasim> Hi.
<binaryFate> hi hi
<sarang> Let's start with ROUNDTABLE
<sarang> The preprint for Triptych, a new linkable ring signature construction that can be extended for use in transactions, is on the IACR archive
<sarang> Link: https://eprint.iacr.org/2020/018
<sarang> CoinTelegraph just released an article about it (but note there are some errors in the data presented there, that I'm told will be fixed)
<sarang> I plan to make an update on the size and time data, to properly account for batch verification and ensure fair comparison
<sarang> More work was done on the multi-index version of Triptych, fixing soundness in exchange for a separate proof relation that we need to show is equivalent to another proof relation
<sarang> This would allow even better performance
<sarang> I worked out an MPC for that version of Triptych as well, which would be useful for multisig
<sarang> And I'm presently working on some questions relating to Omniring math that I've brought up with that paper's authors
<sarang> Does anyone else wish to share interesting research work?
<almutasim> When the time is right, at a key juncture, we could have a press release on Triptych. Monero Outreach could support that. Maybe when it is established that it is going into a release.
<sarang> To be clear, there are no guarantees that Triptych, or any presently-known construction, is fit for deployment
<almutasim> Right.
<Isthmus> I've got some fingerprinting stuff, and n3ptune just completed a pretty cool network analysis
<sarang> Ooh
<sarang> Isthmus: what sort of data have you uncovered?
<Isthmus> Ah my fingerprinting notes are nothing new or exciting, just an idea that might make data presentation more intuitive. So, I tend to think about wallet fingerprinting in a kind of abstract way - every transaction sits at some corner of a hypercube in a high-dimensional space made of different heuristics yadda yaddaaa yadda
<Isthmus> So even though I work with sets of boolean features on the backend, wanted a good way to show results
<Isthmus> This is my first attempt: https://mitchellpkt.github.io/fingerprint.html
<sarang> What, you can't accurately present visualizations of high-dimensional hypercubes? =p
<Isthmus> llol
<Isthmus> This is somewhat by @suraeNoether adding human-interpretable output to the graph matching
<sarang> I like the idea of enumeration like that
<Isthmus> thanks! It figure it's also an easy way to pass around data in a 2-column CSV chart, and researchers can do substring matching on portions that they find relevant to a given analysis
<suraeNoether> Ack sorry! I'm here! Time change got me unawares
<sarang> Isthmus: is there anything to share about the network analysis you mentioned?
<n3ptune> Re: questions on block propagation timing asked last month, I've collected and analyzed block receipt timing data from our global nodes recorded during the past 6 months
<sarang> Nice!
<sarang> What conclusions?
<n3ptune> Isthmus has notes about interpretation and I have more to write but you can look at the graphs here https://github.com/noncesense-research-lab/archival\_network/wiki/Block-propogation-time
<Isthmus> This was RE a question that @moneromooo asked, right?
<Isthmus> Units are size in bytes and timestamps in milliseconds, right?
<suraeNoether> that was my question ^
<n3ptune> we used this formula where NRT is Node Received Timestamp: prop_time_lower_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] - MIN[NRT(h,1), NRT(h,2), NRT(h,3)]
<sarang> What are the changing indices there?
<sarang> Different nodes?
<sgp_> hello
<n3ptune> yeah, that goes up to 3 but there are 4 nodes total
<sarang> got it
<suraeNoether> so block prop time is reliably at least 0.1s. interesting.
<Isthmus> Oh scatter heatmap is height from dark=old to light=new
<Isthmus> ^ color scale
<sarang> And those are the differences between the miner-reported timestamp and the node's wall clock upon receipt?
<Isthmus> Miner reported timestamps are not considered anywhere in this study
<Isthmus> But we did that elsewhere
<suraeNoether> hm then what is being measured for prop time?
<sarang> So these are blocks only passed between your nodes?
<sarang> Where you look at local times on send and receipt?
<Snipa> ^ Was going to ask that, as the min propogation time seems particularly low, as 100msec is quite low in our experience to cross the globe.
<sarang> Or better question: how is NRT computed
<n3ptune> it's the difference in timing between different nodes receiving the same blocks
<sarang> Ah, ok
<Isthmus> Yea, not passing between our nodes, but passing through our nodes
<n3ptune> NRT is recorded from the node system time when a block arrives
<sarang> Independent of the peer from which they receive
<sarang> (which would differ)
<sarang> Seeing the difference between miner-reported time (which could be inaccurate) and wall-clock receipt time would also be interesting
<suraeNoether> hmmmm
<endogenic> o/
<Isthmus> https://usercontent.irccloud-cdn.com/file/brPsQyeU/image.png
<Isthmus> @sarang just for you
<sarang> So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time
<sarang> here = the initial plots, not this one
<Snipa> I'll have to check pool log data, as I might be able to give some extra data points if you're interested. We started to log the time in which a pool node finds a block, versus when that block is stored into our database, which means it's been processed by the local node, as we skip all monerod timings on the pool itself.
<suraeNoether> oooop
<suraeNoether> that's cool
<sarang> Very high times
<Isthmus> @Snipa very nice!
< can you elaborate?
<suraeNoether> isthmus well it's how long it takes for the block to propagate from one of your nodes to another of your nodes; not time it takes to propagate from a miner to one of your nodes
<sarang> I mean that for the initial plots you showed, you can't directly interpret the time for the block to reach your node after it's mined
<sarang> suraeNoether: no
<suraeNoether> no?
<Isthmus> Yea, we very deliberately labeled all of the axes "prop time lower bound" for that reason
<Isthmus> Also, we could always posit that there is an old PC on dialup somewhere in Nebraska with a 4 minute prop time, but that's not meaningful
<sarang> suraeNoether: it's looking at the difference in receipt time, whichever path the block took in total propagation
<Snipa> Hrm, auctually, I can provide a data stream of our global block propgations, as every node has a local reporter that we can hook.
<Isthmus> @Snipa yes please!
<suraeNoether> sarang that's true also
<n3ptune> that data would be awesome to work with
<Isthmus> I'll posit something that might be wrong:
<Isthmus> It's a hacky data science way of thinking -
<Snipa> Hit me up a bit later and we can discuss how to get it to you, and go over data formats.
<Isthmus> Shoot, I gotta get off the bus
<suraeNoether> isthmus: you have two sensors set up to detect propagation time. but you need 3 to triangulate, ala seismic detection of epicenters
<sarang> Don't leave us with that cliffhanger Isthmus!
<suraeNoether> i'm on the edge of my seat
<suraeNoether> i spilled my tea
<suraeNoether> i'm so upset at isthmus right now i could just light myself on fire
<sarang> Stay on the bus Isthmus... it'll loop back around to your stop eventually
<sarang> In the meantime, any other interesting tidbits on this work?
<sarang> This is very interesting data
<suraeNoether> while we are waiting on Isthmus, I'll give my super-brief update: after some discussions with endo, my matching code has been made significantly more efficient, easy to understand, and easier to debug; i'll be making a push later today. my two categories of work today are re-reviewing CLSAG and working on matching
<n3ptune> that's it for now, we will update
<endogenic> his pseudocode now fits onto one sheet of notepad paper..
<suraeNoether> isthmus and i also technically had a conversation about writing up a proposal to encrypt and enforce all lock times, but we haven't gotten details worked out yet
<sarang> You mean using DLSAG-style commitments?
<sarang> We'd discussed it earlier in a meeting
<suraeNoether> yep, last meeting iirc. but i actually had a call with isthmus about it. i view this move as a very good boost in privacy in the sense that it covers up a source of non-randomness in the large data sets that isthmus likes to comb through.
<sarang> I can work out the size and time implications on that if you like
<suraeNoether> i'm not convinced it is worth the additional cost to our txn sizes, but we'll see how it shakes out
<sarang> Since it could be bundled into the existing bulletproof
<suraeNoether> ^ ah
<sarang> Yeah, size is not the issue here due to the logarithmic scaling
<suraeNoether> yeah, and verification times are speedy as a cheetah's balls
<suraeNoether> pardon me, this is a public meeting, i should be less vulgar. please accept my apologies.
<sarang> Right... there's a linear increase in verification time, but with the benefits of multiexp that's reduced a bit
<sarang> CoinTelegraph has updated their article: https://cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity
<sarang> Thanks to the author for taking care of that so quickly
<almutasim> A press release could get more coverage, when and if it is desired.
<sarang> suraeNoether: interestingly, due to bulletproof padding, for many transactions there would be no size increase aside from the space taken up by the commitment data
<suraeNoether> good on cointelegraph
<sarang> (as opposed to a smaller plaintext representation)
<suraeNoether> sarang: could a similar approach be used to include a ciphertext of a message?
<suraeNoether> ie moneroMail
<Isthmus> Sorry somebody got in a fight with the bus driver right before my stop
<sarang> Not really... there's some spare space in bulletproofs that could hold something 1-2 proof elements of arbitrary data by controlling randomness (I'd need to check the details)
<Isthmus> Sigh San Francisco
<sarang> Welcome back Isthmus
<Isthmus> Ok lemme whiteboard some stuff 1 sex
<Isthmus> n3ptune: do you want to share the padding?
<Isthmus> In the blocks
<n3ptune> sure
<suraeNoether> sarang so enough for a key exchange but unlikely enough for a ciphertext?
<sarang> Well, you're limited by space
<n3ptune> Is there a known purpose for the null padding tag in tx_extra?
<sarang> I don't remember if Poelstra and friends found 32 or 64 bytes of space
<sarang> n3ptune: good question for moneromooo et al.
<sarang> While we await Isthmus' continued update, anything else of interest to share?
<sarang> Or ACTION ITEMS, according to the agenda?
<suraeNoether> i want to provide final comments to you on clsag but i'm very unlikely to get that finished today
<suraeNoether> but it's on my mind for this week
<Isthmus> Back
<suraeNoether> Front
<sarang> Mine are to get CLSAG submitted (after review), to hopefully nail down this Omniring issue and pass it to the authors, work on a few EC curve library updates for proof of concept code, and get preprint stuff taken care of via monero-site MR
<sarang> Isthmus: please go ahead
<sarang> (oh, and update the Triptych preprint performance data with better clarity)
<Isthmus> https://usercontent.irccloud-cdn.com/file/gAM3VbDV/1578508953.JPG
<sarang> wat dis
<Isthmus> So let's say that we have 100 of n3ptune/NRL's archival nodes running
<Isthmus> If we have only 2 nodes, then our propagation envelope will have a lot of variability, be topology dependent (assume archival nodes don't connect to each other), and just t_second - t_first
<Isthmus> As we add a 3rd node, it has the possibility of increasing the measured prop time (since it could hear before or after) but can't decrease the prop time since it's max-min
<Isthmus> As we get up to 100 nodes, the variability will probably smooth out and we approach the true reasonable prop time (from miner to global nodes with broadband internet)
<sarang> Doesn't prop time depend on max/min among all nodes? So the third node could fall outside the envelope of the other two and affect the value?
<Isthmus> Yeah, that's the point
<sarang> OK, I must have misinterpreted
<sarang> Oh, can't _decrease_
<sarang> nvm
<Isthmus> Painting very broadly, when we adad the 3rd node there's a 2/3 chance that it'll fall outside the N=2 and increase the prop time, and a 1/3 chance that it'll be between the first 2 nodes.
<Isthmus> Sorry, I'm giving a kind of scattered description cuz I just realized this on the bus
<almutasim> Max-Min is a very sensitive metric, sensitive to outliers.
<Isthmus> Hmm lemme ponder on that
<Isthmus> Skipping over that for now
<Snipa> How're you pulling the time in which the block is received? Tweaked monerod/using it's logs or polling on the RPC interface to determine when it's auctually viably added to the box?
<Isthmus> That's a n3ptune question, they do all the DevOps and data engineering. All ended up in a SQL database by the time I got to it
<n3ptune> tweaked monerod
<Snipa> On P2P receive then?
<Isthmus> So for each height we have epsilon (green line) which our many-node approximation of global prop time
<n3ptune> you can also use monerod --block-notify, if you point that to a shell script that writes the timestamp
<Snipa> --block-notify waits until the block is committed, which is why I ask, because nodes that do not use NVMe have much slower propagation times in general, as you're waiting on disks to write.
<n3ptune> i like that better because then you can use the stock daemon. but we don't use that yet
<sarang> OK, so using the max-min metric, assuming relatively even node placement across the network topology?
<Isthmus> Yeah, though after @almutasim I'm considering a few other less sensitive metrics
<Isthmus> slap all those epsilons into a histogram, and that's the plot on the right.
<sarang> The outliers being nodes close to the miner and far from it, topologically
<Isthmus> Uhm, the outlier might be only 2 hops away but one of the hops is really slow
<n3ptune> P2P Receive: no it happens when it adds it to the blockchain, after it determines whether or not it's an alt block. this was because we had another original goal to capture alt blocks data. the daemon patch is shared here https://github.com/neptuneresearch/monerod-archive
<Isthmus> @sarang so it depends if topological distance definition is just the p2p connectivity graph or takes into account time between vertices
<sarang> right
<Isthmus> And that epsilon plot is basically what n3ptune shared earlier except instead of "max-min with 4 nodes" it is "asymptotic approximation of global prop time"
<Isthmus> ^talking about x-axis of histogram
<n3ptune> --block-notify waits until the block is committed >> oh then i guess this method of doing it in blockchain::add_new_block() at least occurs before block-notify would. but yes it isn't *immediately* on receive
<sarang> Since we're just about out of time, any last bits of information before adjourning (discussion can of course continue) for log purposes?
<Isthmus> Oh yea
<Isthmus> just a quick note that tx_padding is used in the wild, but unclear why
<Isthmus> In the scatter plot showed earlier, the vertical bands from left to right are empty blocks and then N=1,2,3... transaactions
<sarang> That's a question for someone like moneromooo
<Isthmus> Of course there's variability in the horizontal width of the vertical bands due to transaction size differences, but the variability in coinbase-only blocks was straange
<Isthmus> https://xmrchain.net/tx/acdf8eac41a7a76fd899e09640db34023abff66b3ae2c9ea86e49f19c0720af4
<Snipa> Not really, coinbase only blocks are quite common due to pool design.
<Isthmus> No no, the size*variability* in coinbase-only was strange
<Isthmus> Turns out some (now fingerprinted) miners are using lots of null padding, check out the tx_extra for this coinbase
<sarang> gadzooks
<Snipa> Not super surprising.
<Isthmus> Looks like bloat to me
<Isthmus> Bunch of blocks waste space with nulls in tx_extra
<Snipa> Possibly, it's also something that can be requested by a pool.
<Snipa> As that's the block padding that we use for extra nonce storage space.
<Isthmus> "As that's the block padding that we use for extra nonce storage space." block nonce or transaction nonce? This is padding in the coinbase transaction
<Snipa> Oh sorry, txn, my bad.
<Isthmus> Do you know why some miners use the padding and some don't?
<Snipa> Lemme look through some of my decoding code I wrote for that.
<Isthmus> I'd been comparing:
<Isthmus> https://xmrchain.net/search?value=1988283
<Isthmus> and
<Isthmus> https://xmrchain.net/search?value=1985042
<Isthmus> Since they seem to be exactly the same besides different padding
<Isthmus> Anyways, thanks for letting me ramble and shifting meeting time
<Snipa> For quick reference: The block's CB TXN contains an "extras" section, which is requested from Monerod as the extra space in which arbitary data can be written. This data is used by pool implementations to implement the per-pool nonces as well as any custom nonce data used by more advanced techniques.
<Isthmus> "extra space in which arbitrary data can be written"
<Snipa> You can use this data in a number of ways, particularly with knowledge of pool design, as the two main pool implementations use this space similarly, but have different sizes based on various addon support.
<Isthmus> Ooh, what are the current use cases?
<Snipa> You also can identify what pool instances are submitting blocks, as pools use unique identifiers in particular bytes.
<Isthmus> (I have no knowledge of pool design)
<Snipa> https://github.com/Snipa22/nodejs-pool/blob/master/lib/coins/xmr.js#L115
<suraeNoether> For those of you who are interested in helping out with Monero Kon 2020 in Berlin, there is a meeting happening right now for prospective volunteers. This is research related, but otherwise off-topic, so I'm just dropping this here.
<Snipa> ^ is the implementation you'll find on pools that support the XNP extensions I wrote awhile ago.
<sarang> Yeah, we can formally adjourn the meeting, but carry on the conversation
<sarang> Thanks to everyone for attending

Logs for the Community Meeting Held on 2020-01-04

Sat, 04 Jan 2020 00:00:00 GMT

Logs

<needmonero90> 0. Introduction
<needmonero90> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<needmonero90> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/424
<needmonero90> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<ArticMine> Hi
<needmonero90> 1. Greetings
<ajs> hi
<needmonero90> hi
<needmonero90> Anyone else here this fine day? :D
<anhdres> hi
<rehrar> I
<needmonero90> that makes 5! That is more than three
<needmonero90> 2. Community highlights
<needmonero90> See Monero weekly highlights at https://revuo-monero.com
<needmonero90> Cake Wallet android was just released.
<needmonero90> Does anyone have community (non-workgroup) updates to share?
<needmonero90> wait
<needmonero90> didnt mean to send all that at once
<asymptotically> belated greetings from me :)
<needmonero90> Cake Wallet android was just released! Nice work to the cakewallet team, you're going to be a thorn in my side recommending wallets now. I can't just say monerujo without thinking anymore
<needmonero90> diversity!
<endogenic> mymonero android soon
<needmonero90> yeah but who uses mymonero anyways
<SerHack> Hi
<needmonero90> :)
<needmonero90> hello!
<needmonero90> Other than cakewallet, do we have any community updates to share?
<endogenic> needmonero90: a lot of mrl members use it
<endogenic> we dont even have to pay them
<rottensox> lol.
<needmonero90> I've been checked out the past week or two due to family and holiday considerations, so I have no updates from the moderation side of things
<rottensox> o/
<needmonero90> \o
<msvb-mob> o/
<rottensox> msvb-mob is here!
<rottensox> k, let's go to point 3 then.
<needmonero90> 3. CCS updates!
<needmonero90> research funding for 2020 Q1 (575.5 / 695 XMR) https://ccs.getmonero.org/proposals/sarang-2020-q1.html
<needmonero90> The MRL are the grease that keeps our wheels turning, without them we would rapidly grind to a halt
<needmonero90> If you're reading this, and want to contribute to Monero, the MRL is one of the biggest impact things you can donate to
<rottensox> aye.
<needmonero90> Don't think, just do
<needmonero90> 3 months part time work on Getmonero.org (5.3 / 174 XMR)
<needmonero90> I don't have the link handy atm
<needmonero90> Who is this for, rehrar?
<rottensox> ErCiccione[m], i reckon.
<rehrar> ye
<needmonero90> Aha
<SerHack> https://ccs.getmonero.org/proposals/ErCiccione-website-jan-march.html
<needmonero90> Great, thank you
<rehrar> sure
<rehrar> fund both
<needmonero90> The getmonero website is the portal to the hearts and minds of the masses, and if it isn't pretty and functional, we're going to lose people before they've even started
<needmonero90> Not everyone is a power user who can spend hours diving for the data they need, erciccione is doing valuable work too :)
<needmonero90> Also localization, that's big too
<needmonero90> Any other CCS comments before moving on?
<SerHack> Anyone who contributes to Monero and its community is doing valuable work.
<needmonero90> Agree
<rottensox> :)
<needmonero90> Okay, moving on!
<needmonero90> 4. Workgroup report
<needmonero90> a. Daemon/CLI workgroup
<needmonero90> There were some new networking developments and discussions about how to better communicate between the daemon/wallet and an anonymity network
<needmonero90> I presume this is in reference to a swappable layer like tor or i2p
<needmonero90> Would certainly make things easier
<needmonero90> Anyone here who participated in that discussion?
* needmonero90 may be going too quickly
<needmonero90> Is this too fast?
<rehrar> no
<rehrar> nobody typically responds to anything anyways
<ArticMine> No it is fine
<rehrar> #monerocommunity
<rottensox> exactly...
<rottensox> just keep on going.
<rottensox> these meetings are pretty much a refreshing stance of things...
<midipoet> are we done yet?
<needmonero90> Yep, still, I don't want a recorded log of my incompetence :)
<rottensox> no lol.
<midipoet> so slow
<rottensox> you're a sweetheart cutie needmonero90.
<rottensox> xoxo
<rottensox> lol midipoet.
<needmonero90> b. Localization workgroup
<needmonero90> ErCiccione any update?
<needmonero90> I assume he isn't present
<rehrar> don't think he's here today. Didn't even comment on his CCS proposal when up for "discussion"
<needmonero90> Due to the previous ping
<rehrar> Sorry. I'm trying to act like a typical peanut gallery to give you the real experience needmoney90
<needmonero90> c. GUI workgroup
<needmonero90> There was a point release (no binaries yet for the newbs) https://github.com/monero-project/monero-gui/releases/tag/v0.15.0.3
<rehrar> yeah, I saw that the other day
<rehrar> selsta?
<needmonero90> Wen binaries
<selsta> no idea
<selsta> :)
<needmonero90> What got fixed and added?
<needmonero90> I assume just fixed
* needmonero90 waits a bit
<selsta> See the release notes, mostly bug fixes and a new blur effect when the wallet it locked.
<selsta> Also there were crashes which are now fixed.
<rehrar> blur effects
<rehrar> it also says that the sidebar was redone?
<needmonero90> Blur effects are big
<needmonero90> Game changer
<rottensox> stealth mode.
<sgp_> We need a better name for blur effects. Something easier to shill
<rottensox> invisible mode.
<sgp_> Nice
<needmonero90> Oh you're back
<selsta> anyway no ETA for bins
<sgp_> Kinda, on mobile
<selsta> can be weeks if there will be any lol
<selsta> hopefully
<rottensox> .soon
<monerobux> Two weeks™
<selsta> (not xiphon’s fault, he had bins ready almost 2 weeks ago)
<rehrar> selsta, you're the new binary guy?
<needmonero90> Xiphon*
<selsta> no
<rehrar> oh. So what are we waiting on?
<needmonero90> Moon
<rehrar> bf to sign and someone to put on the site?
<rehrar> who are we waiting on right now?
<selsta> core team can comment on this if they want
<selsta> Snipa will do builds going forward
<selsta> but he has no env yet
<selsta> so no ETA
<rehrar> gotcha
<needmonero90> Alright, time to move on?
<rottensox> ye.
<needmonero90> d. Outreach workgroup
<needmonero90> The RPC-Pay and Chinese perspective articles are nearly ready to go
<needmonero90> Oops
<needmonero90> OK, is anyone from outreach here?
<rottensox> thunderosa
<rottensox> xmrhaelan is usually around too, but seem like they're idle...
<needmonero90> [crickets]
<thunderosa> Yes, we're putting the final touches on both.
<rottensox> there ya go.
<needmonero90> Hey!
<thunderosa> Hey
<needmonero90> What are the articles on? Specifically the second one
<thunderosa> The plan is to drop the Chinese piece tomorrow am....TBD on the RPC-Pay piece,...we were looking at putting press support on that one.
<needmonero90> OK! Looking forward to reading them when they come out.
<thunderosa> Hey sorry,...didn't catch that it was a meeting
<thunderosa> So Chinese Persepective piece, Chinese author:
<thunderosa> https://www.monerooutreach.org/monero-china-west.php
<thunderosa> https://www.monerooutreach.org/1-01/2020-003.php
<thunderosa> We're wanting to publish both languages at once,...so we're getting our Chinese side in shape.
<rottensox> :D
<thunderosa> https://www.monerooutreach.org/stories/RPC-Pay.php
<thunderosa> We'd especially like critical feedback on the RPC-Pay piece.
<thunderosa> There's more technical content in that one and we want to make sure we're accurate in all things.
<needmonero90> I'll take a look after the meeting
<selsta> moo should read he RPC pay article
<needmonero90> Is that it for outreach updates?
<thunderosa> Ah shit there's a whole bunch of stuff,...but I'm really not prepared :)
<needmonero90> That's fine!
<rehrar> just type a thi8ng or two
<thunderosa> We're working on implementing the RPC-Pay stuff,...using Primo and using that to incentivize contributors
<thunderosa> Basically a straight up rev share for anyone who makes cool stuff
<thunderosa> I'll have a better report in a few weeks,...but that's the big push right now.
<needmonero90> Primo is the hashing micropayment system right?
<thunderosa> Thinking that the community calendar and merhcant directory could also reward it's contributors and maintainers.
<thunderosa> Yeah
<thunderosa> it's an Apache module
<thunderosa> We're getting out node up and then we're going to plug that baby in
<thunderosa> and see if it s works like we think it might
<needmonero90> So it's in beta atm?
<thunderosa> By next week we should have a proof on concept,..it's involving a server migration and stuff so that's bogging things down a bit. But the other side is looking good.
<sgp_> Can someone make an aggregate RPC-Pay program where payments can be allocated to a user ID that's registered with the system? Is that possible?
<thunderosa> Pre-beta :)
<needmonero90> Ooo
<thunderosa> Yeah, that's the idea,..we're data based in our content
<thunderosa> and the CRM can track the traffic share with no problem
<sgp_> Then it effectively serves as a mining pool. Very cool thunderosa
<thunderosa> and any author can claim their share or donate it to a workgroup or devs or whatever
<thunderosa> kinda,..I hadn't thought of it that way,...but you're right,...it's a content mining pool
<rottensox> fun stuff.
<thunderosa> if it works,..I thought MoneroMemes could try it out too
<thunderosa> I'll be setting up a repo in the next few weeks,...it'll all be there.
<needmonero90> Cool!
<thunderosa> seems like we're doing other stuff too,..but that's the big unifying thing right now and all I got for an update :)
<needmonero90> Alright great, onwards!
<needmonero90> 36C3
<needmonero90> The 36c3 was a success in many ways, attracting large crowds. All talks were streamed here: https://youtube.com/c/monerocommunityworkgroup
<monerobux> [ Monero Community Workgroup - YouTube ] - youtube.com
<rottensox> hmm?
<rottensox> i thought it was hardware next...
<xmrhaelan> I came on to find hyc and saw this. Thanks Thunderosa!
<rottensox> https://github.com/monero-project/meta/issues/424
<needmonero90> That's f
<needmonero90> In my list
<rottensox> lol. alrite.
<needmonero90> E is 36c3 unless sgp_ linked the wrong text
<needmonero90> To me
<needmonero90> Anyways
<midipoet> what stops primo from being deployed maliciously (sorry if stupid question)
<needmonero90> How was 36c3?
<kinghat> finally made it through all the talks. now i need to go back and watch the defcon talks. is there an official playlist or just the one sgp_ put together?
<needmonero90> Oh back up
<sgp_> I made the notes in haste, sorry
<ajs> 54 talks, 21 hours of content
<sgp_> kinghat: the events were recorded locally but need to be sliced
<needmonero90> Sorry midipoet, I moved too quickly
<rottensox> oof.
<sgp_> I offered to slice them if I get the raw files
<sgp_> But I don't have them
<midipoet> no, that's ok... continue on. just processing the primo / RPC-Pay info
<sgp_> kinghat: for Defcon, use the official Decfoncobference YouTube channel playlist
<sgp_> *conference
<needmonero90> Decfon
<needmonero90> Lol
<kinghat> this was the playlist i bookmarked: https://www.youtube.com/playlist?list=PLsSYUeVwrHBm0oAEyRxZIMFxCwNNmybBH
<monerobux> [ Defcon 2019 - YouTube ] - www.youtube.com
<sgp_> Lol
<needmonero90> That mobile keyboard
<sgp_> https://www.youtube.com/playlist?list=PL9fPq3eQfaaBiCOF12ZYejtj21sI1jm0I
<monerobux> [ DEF CON 27 Monero Village - YouTube ] - www.youtube.com
<sgp_> Use that one
<needmonero90> I have yet to see any of the c3 talks
<rottensox> aye.
<rottensox> needmonero90: highly recommend first day, thoroughly.
<rottensox> was a great one.
<needmonero90> Any specifics?
<rottensox> all to be honest, but closing keynote by daniel was outstanding.
<rottensox> bummed he didn't finish all the slides...
<rottensox> 2nd day i just caught the last two talks, and they were good as well.
<rottensox> the rest i haven't watched.
<kinghat> sgp_: are these not "sliced up" or ami missing something?
<rottensox> too much content to catch up with.
<needmonero90> Story of my life, rotten
<kinghat> just give your life an RSS
<rottensox> i am the man of rss feeds sir.
<rottensox> okokok we're digressing.
<rottensox> what's next?
<rottensox> needmonero90: these two from day 2, were good. https://frab.riat.at/en/36C3/public/events/123.html https://frab.riat.at/en/36C3/public/events/163.html
<ajs> locally recorded video will be sliced into individual presentations and uploaded to ccc media server. no word on ETA.
<rottensox> as i said, the two closing talks of day 2.
<rottensox> ajs based. thank you very much for the livestream and a/v stuff. don't think these events would be as great if it weren't because of you.
<rottensox> round of applauses for papa ajs.
<msvb-mob> <clap><clap>
<rottensox> nm90 went mia? lol.
<needmonero90> sorry
<needmonero90> stepped away from my keyboard for a moment
<ajs> thanks, but most of the hard work was done by a pro videographer and sound sound engineer that helped out
<rottensox> nice, glad to hear that.
<needmonero90> so, msvb-mob msvb-lab you there?
<msvb-mob> Yes.
<needmonero90> great
<needmonero90> f. Hardware workgroup
<msvb-mob> The hardware team reports late stage beta mechanical engineering, where FDM prin
<msvb-mob> ts of a enclosure are finished and injection moulding design as well.
<msvb-mob> In parallel, work is in mid stage (about a month left) of product development and packaged documentation.
<msvb-mob> That's all, remember there is a #monero-hardware channel for questions and answe
<msvb-mob> rs. Any questions on mechanical engineering or product development?
<rottensox> msvb-mob: how are the things looking like for the dev kit of kastelo, sir?
<rottensox> msvb-mob: are you alright? i was bummed when you didn't show up for your 36c3 talk. :(
<msvb-mob> rottensox: Good, we're in product development which includes a lot of boring things like country of origin, taxes, certificates, exceptions, and logistics.
<msvb-mob> That's in product development, I mean.
<rottensox> oof, all the paperwork... can only imagine.
<rottensox> thanks for doing that though.
<msvb-mob> My 36C3 talk was not accepted, unfortunately.
<rottensox> oh, i see.
<msvb-mob> Any questions regarding the stages of hardware engineering we are in now?
<rehrar> Your talk at the CDC was accepted and you were on the schedule.
<msvb-mob> rehrar: I mean it was not accepted to me, no acceptance message of any kind.
<rehrar> Ah, I see.
<needmonero90> :(
<needmonero90> so the hardware workgroup is currently working on what? kastello, badges for defcon?
<needmonero90> any other neat projects in the works?
<msvb-mob> needmonero90: Right now no badges (except outside of the Monero Community.) Just Kastelo.
<ArticMine> You had to log into frab.riat.at and check
<msvb-mob> needmonero90: Other projects are outside Monero scope, so nothing to report.
<msvb-mob> ArticMine: My proposal was erased from frab.
<msvb-mob> It was probably rejected, but I never received a rejection message either.
<ArticMine> Before or after the talk time?
<msvb-mob> needmonero90: Konferenco is next.
<rottensox> yeah... let's move on, shall we?
<needmonero90> ok!
<ArticMine> ok
<rottensox> none of what we say we'll roll back time and make it happen.
<needmonero90> g. Konferenco workgroup
<needmonero90> progress is slow and ongoing
<msvb-mob> First, remember that there is a #monero-konferenco channel for detailed conversa
<msvb-mob> tions.
<needmonero90> I haven't been involved in the conversation, I need to tune in
<msvb-mob> Scouting venues for the Konferenco 2020 has mostly concluded, and the results are reported in project management task number 40.
<msvb-mob> https://taiga.getmonero.org/project/michael-konferenco/task/40/
* rottensox clicks
<msvb-mob> A lot of details are not public, like the exact prices and conditions for each venue. This information is offered to the person who takes the boss role, CEO or whatever.
<rehrar> Are these details not public at the request of the venues?
<msvb-mob> Including many megaoctets (giga?) of photos and media.
<needmonero90> None require catering, right?
<msvb-mob> rehrar: Other way around, to publish details I need to get permission from about twenty people who are sometimes responsive only after three weeks of repetition emails.
<msvb-mob> needmonero90: I think only one venue requires in house catering, let me try to find out which one...
<rehrar> Ah, you are taking the stance of privacy first unless given permission to share these details by the venues
<needmonero90> private by default is the monero way
<msvb-mob> Kulturbrauerei requires in house catering, like about 4500 EUR of costs.
<rehrar> yes, but if they didn't request this info be private, then it hinders the planning to not share imo
<rehrar> I'm certain that anyone else who would make a request would get prices and stuff all the same
<needmonero90> its a courtesy thing, this is their business model
<rehrar> I see.
<msvb-mob> rehrar: I assume that nobody will offer to lead the project and that there will be no Konferenco 2020 for that reason. As soon as a boss appears, they can choose to publish all the nonpublic information (at great risk to our common future of course.)
<needmonero90> Either that or we decide on bounds for pricing and capacity, and trust the organizer to optimize for venue
<msvb-mob> I really don't think there will be a Konferenco 2020, but I'm going to keep distilling and perfecting our venue scouting information until a final report as well as party place and accommodation hotel is clearly chosen.
<rehrar> In the event that nobody offers to lead the project for Europe, I and potentially others will make an attempt to make it happen in the USA or Mexico. :)
<needmonero90> if rehrar is in, he's gonna rope me into it to
<rehrar> EU peeps step up plz. ;)
<msvb-mob> rehrar: Do you have a strategy for not waiting too long (for a European leader to appear) so that a north american event is not too late in planning and therefore cancelled as well?
<rehrar> Wait until end of Q1
<kinghat> msvb-mob: maybe you could do some version of your talk in an upcoming coffee chat?
<rehrar> if nothing, plan for Q3 or Q4.
<msvb-mob> kinghat: I'm already scheduled to do the same talk at Disobey 2020 and FOSDEM.
<binaryFate> shit schoolboy mistake with time, missed meeting
<rehrar> Even if nobody steps up for this year, all the info you've gathered is still valuable msvb-mob. It can be available for whoever wants to run one in Europe in later years.
<kinghat> very cool msvb-mob 👍
<msvb-mob> rehrar: Sounds good, the schedule method. To not wait too long.
<msvb-mob> needmonero90: Next topic?
<needmonero90> 5. Open ideas time
<needmonero90> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<msvb-mob> ...or does ajs have any reporting on Konferenco, as he has done a lot of work as well?
<needmonero90> we're running a bit over, so I think we can skip this part
<msvb-mob> binaryFate: You're fired.
<binaryFate> I can comment on GUI builds after meeting is over if anyone is interested
<needmonero90> 6. Confirm next meeting date/time
<needmonero90> The next community meeting will be in 2 weeks on 18 January at 17:00 UTC.
<needmonero90> The next Coffee Chat is on Saturday January 11 at 17:00 UTC. sgp_ will not be present, so he will need someone else to host. Please DM him if you can help, it will probably end up being rehrar or myself.
<ajs> I've made some a/v inquiries and set up a telegram group at https://t.me/joinchat/PmC9ihaLP0UZF-bfkD36CA
* needmonero90 waits for the konferenco discussion to finish
<needmonero90> sorry, I keep moving on and then people come back :)
<rehrar> I always do this
<ajs> to continue talk on konferenco, pop in #monero-konferenco or the telegram group
<needmonero90> thanks :)
<rottensox> <msvb-mob> kinghat: I'm already scheduled to do the same talk at Disobey 2020 and FOSDEM.
<rottensox> wow, do link us to such talks when they get posted on their respective schedules, please.
<rottensox> will gladly tune in the livestream or recorded individual links.
<needmonero90> ok guys, meeting is running 15m over :)
<needmonero90> I think that covers most of it, we can finish the rest of the discussion afterwards.
<needmonero90> I need to get food
<sgp_> Thanks so much needmonero90!
<needmonero90> https://www.irccloud.com/pastebin/tZfeu1nj/
<needmonero90> oops
<needmonero90> 7. Conclusion
<needmonero90> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the MRL Meeting Held on 2019-12-30

Mon, 30 Dec 2019 00:00:00 GMT

Logs

<suraeNoether> welcome everyone, to the last MRL research meeting of the year
<suraeNoether> if i had thought about it, i'd have something more in-depth prepared but it just occurred to me ;P
<suraeNoether> let's start with 1) GREETINGS
<endogenic> o/
<sarang> hi
<suraeNoether> good and you, oh not so bad
<suraeNoether> isthmus was here mere moments ago
<Isthmus> Kind of. Splitting headache. Looking at screen intermittently.
<sarang> yikes
<endogenic> :(
<Isthmus> C'est la vie.
<suraeNoether> okay, well; go away isthmus and come back when you're healthy
<suraeNoether> you'll get us all sick with headaches left and right
<endogenic> i have a headache now
<Isthmus> See, we should just ban headaches at the protocol level
<Isthmus> Not just in the wallet.
<suraeNoether> no your headache now
<suraeNoether> before we move onto 2) ROUNDTABLE I would like to bring up a single administrative issue
<suraeNoether> i would like to propose that we consider switching meeting times; we selected 17 UTC mondays essentially at random about 2 years ago
<sarang> ?
<sarang> What's a preferred time?
<suraeNoether> nowadays, not all of our participants easily are able to attend that time, so often it's just sarang and i
<suraeNoether> so while i don't have a lot of time constraints, i wanted to hear from folks like isthmus who oftentimes have meetings at around the same time
<suraeNoether> and open the room up for general discussion about timing for meetings
<Isthmus> ty
<suraeNoether> i know this is boring, but it's been on my mind for more than a month now
<sarang> Suggestions on a better time?
<endogenic> an hr fro
<Isthmus> I'm normally on Pacific time so Monday 1700 UTC is early and right when I'm getting swamped at the office
<endogenic> m now?
<endogenic> nm
<Isthmus> I'm just here now cuz on holiday & EST
<sarang> How about 18:00 or 19:00 UTC?
<endogenic> Weds?
<Isthmus> Weds at 18 or 19 would be better
<Isthmus> In that case, I think I could block it on my work calendar as a recurring event
<sarang> We could always try a new datetime out and see how it goes
<suraeNoether> i second wednesdays at 18-19 UTC provisionally for the first month of the year just to see how it works out re: participation
<sarang> I make sure the topic bar shows the meeting datetime
<Isthmus> +1
<sarang> OK, Wednesday at 18:00 UTC it is
<Isthmus> Thanks! Will be very helpful for me.
<suraeNoether> okay, neato burrito
<suraeNoether> onto 2) ROUNDTABLE
<suraeNoether> since the holidays were last week, maybe we can make this not just a "here's what I did last week" thing but also a "here's what we did this year" thing, but that could end up being a... surprisingly long list
<suraeNoether> but we don't have to go in-depth
<suraeNoether> sarang or isthmus, do you guys want to begin? wait, no, isthmus: go away and treat your headache
<sarang> I finished up a draft MPC for the aggregated version of RCT3 this past week
<sarang> And am currently in the weeds with some Omniring stuff that has been puzzling
<sarang> Additionally, my funding request is open: https://ccs.getmonero.org/proposals/sarang-2020-q1.html
<suraeNoether> i strongly recommend that everyone donate to sarang's funding request
<suraeNoether> well, i mean, whatever you are comfortable with
<sarang> and I'm on pins and needles for any comments from suraeNoether on CLSAG or Triptych preprint updates
<suraeNoether> what i mean to say is: this is a valuable request, and if you have been considering donating to the CCS but don't know where your money will have a big impact, sarang's fund is a high priority ticket imho
<sarang> Much appreciation for all the support
<sarang> I'm eager to see what the next year holds in the research space, particularly relating to transaction protocols
<Isthmus> Yea, what's our research theme for 2020
<Isthmus> I'll obviously continue to be a huge PITA about information leaks
<sarang> yes plz
<sarang> "2020: zero knowledge, infinite heart"?
<Isthmus> Ring size 2020?
<Isthmus> Oh wait, it's not a prime number
<sarang> People are going to think there's a technical reason for having prime-number ring sizes :/
<sarang> Interestingly, for some protocols, you specifically _can't_ have a prime number size!
<suraeNoether> for any merkle-tree based approach, you have to stick with powers of 2
<suraeNoether> for 2020, a few things i'd like would be a formal protocol specification for a tryptich-based protocol, using ristretto, going down to the nitty gritty details of optimized arithmetic, tor integration, etc
<suraeNoether> thing is, i think we are eventually going to need to abandon the DL setting for efficiency and security reasons; either switching to multilinear pairings may be necessary for efficiency, but still boils down to computational security. on the other hand, switching to other hardness assumptions like RLWE, which are believed to be quantum-secure, is an area of active research. that assumption also has a
<suraeNoether> very different profile for use in cryptocurrencies because key sizes and signature verification speeds are very different in the new setting
<suraeNoether> my roundtable contribution from this past week: i got flu-like symptoms after xmas, so all I could do was sit around and be grumpy, so I ... copy-edited triptych and clsag
<suraeNoether> (best thing to do when grumpy is to grade papers???)
<sarang> Looking forward to your notes on those
<suraeNoether> should be before 3PM today
<sarang> Hooray!
<sarang> It's a Festivus miracle!
<suraeNoether> i'll be switching back to matching simulation stuff literally next year
<suraeNoether> festivus miracles involve being able to use the aluminum pole on your grievances
<endogenic> i dont get that reference but i will google
<sarang> I'll be continuing a deep-dive into some Omniring stuff this week, to determine if an issue I ran into presents a problem with any of the proofs
<Isthmus> My roundtable is still plotting, but should be rendered shortly
<suraeNoether> after recovering from the flu, or whatever i had, though, i have to say: i feel like a million bucks and i'm super excited to finish off triptych today
<suraeNoether> endo and isthmus and sarang can all attest to the number of times per year i say i feel like a million bucks
<Isthmus> :- )
<endogenic> 1/4 times per year so far
<suraeNoether> when the moon hits your eye like a big pizza pie, thatsa N=1
<Isthmus> Ah, here we go
<endogenic> i feel for the transcription translators who do these logs
<Isthmus> https://usercontent.irccloud-cdn.com/file/ntGPLKhz/image.png
<Isthmus> ^ non-coinbase TXNs as of late
<suraeNoether> oh my fkn god
<Isthmus> I zoomed in on lower values there, there are some absurd outliers
<Isthmus> https://usercontent.irccloud-cdn.com/file/Uz5uJDlS/image.png
<suraeNoether> so i like the idea of having an adjustable unlock time for smart contract reasons. ...
<endogenic> for m'kids
<suraeNoether> hey, sarang: think the range proof technique for the trigger block height in DLSAG could be janked around to hide *all unlock times*?
<Isthmus> https://usercontent.irccloud-cdn.com/file/xS32XCWP/image.png
<Isthmus> ^ All from the last few months
<Isthmus> Excluding the giant ones
<sarang> I believe it could
<Isthmus> Apparently unlock_time supports both unix timestamps and height... There are 13 transactions that used UNIX time and the rest are height-based
<sarang> unix timestamps? did not know that
<Isthmus> There's one transaction whose outputs will unlock in the year 46000, lol
<suraeNoether> hmmmm
<suraeNoether> i can't think of a good reason to allow unix timestamps
<endogenic> who uses unlock time currently?
<suraeNoether> costs of hiding all unlock times is a new range proof, but that can be batched with bulletproofs... and variable unlock times are desirable for smart contracting...
<Isthmus> @endogenic apparently 8 different sets of people, and they all use it differently
<Isthmus> xD
<endogenic> lol
<suraeNoether> the DLSAG connection is strong with this
<endogenic> surae is one of them
<Isthmus> https://xmrchain.net/search?value=2c2762d8817ea4d1cb667752698f2ff7597a051d433043776945669043d908b5
<Isthmus> "unlock_time": 1420722551128,
<suraeNoether> i'm *really* bad at monero
<sarang> Not only batched, but aggregated for logarithmic size benefits
<suraeNoether> can anyone think of a good reason to keep unlock time in plaintext?
<endogenic> auditability
<sarang> It's also smaller
<endogenic> forgive me monero gods
<sarang> Otherwise you have to put it into a commitment
<Isthmus> What is the point of unlock time?
<Isthmus> Serious question.
<Isthmus> I need to understand the intended use cases to figure out how we should handle it
<moneromooo> A reason to use UNIX timestamps is to not depend on block time changes.
<endogenic> (unreclaimable) vesting period; force-hodl
<sarang> that's a fair point
<Isthmus> If the unlock time is plaintext, then how can the hodl be forced?
<Isthmus> Erm
<Isthmus> *if is encrypted, how enforced
<sarang> There's a range proof included, showing that the current block height exceeds the committed lock period
<moneromooo> Can't you easily brute force it ?
<sarang> The goal is to reduce heuristics around expected spends
<suraeNoether> endogenic: auditability in this case would be the same security/threat model as our confidential transactions, so that wouldn't reduce our auditability... not to mention, for the folks in the audience, monero balances are guaranteed by the unforgeability property of our signatures; if anyone is capable of cheating the monero system with our confidential transactions, they can also forge signatures with
<suraeNoether> elliptic curves, which breaks a lot more than just monero.
<Isthmus> I second mooo's question
<sarang> moneromooo: the lock time is in a Pedersen commitment
<endogenic> suraeNoether: was joke :)
<sarang> which is perfectly hiding
<suraeNoether> isthmus: early cross-chain swap models require unlock times to elapse to use SPV
<endogenic> but how does recipient easily verify time til unlock isnt ridiculous through only range proof?
<suraeNoether> endogenic: it's a joke, but like a making a math joke in a math class, it's always followed up by a serious discussion of why it's funny. #mathteacherlife
<sarang> That needs to be communicated to the recipient endogenic
<endogenic> suraeNoether: one-up'd
<sarang> The range proof is included at spend time
<sarang> not at output generation time
<Isthmus> Ohhhh
<moneromooo> So a verifier gets a yes/no, and at some point a no becomes a yes.
<suraeNoether> moneromooo: can't brute force due to sarang's observation about perfect hiding
<moneromooo> Right ?
<sarang> not quite
<endogenic> sarang: out of band?
<sarang> When you generate the output, you specify an unlock time commitment, and transfer the plaintext version to the recipient either encrypted or out of band
<moneromooo> I mean, from a verifier's perpective, they will need to either reject a spend, or ok it.
<Isthmus> -_-
<sarang> When the output is spent, a range proof is generated using a particular time offset against the commitment, to show the lock time has been exceeded relative to the current block height
<moneromooo> When they stop getting a verification failure, there's no other reason (currently) other than that, no ?
<sarang> The method is a bit unintuitive until you write it out, TBH
<moneromooo> Oh. I see. Thanks.
<sarang> but it's included in the DLSAG preprint
<moneromooo> er.
<suraeNoether> moneromooo: you wouldn't be able to construct a range proof on [0, ..., N] with time offset -3
<suraeNoether> it wouldn't be a valid proof
<suraeNoether> the trickiness is in realizing how the DLSAG construction actually captures the offset
<moneromooo> So you include the block hash at currnet block then ?
<suraeNoether> let me pull it up
<sarang> But moneromooo, it's important to note that you can't simply brute-force the verification at each successive block until it succeeds
<suraeNoether> for the audience members: https://eprint.iacr.org/2019/595
<sarang> The signer generates the proof once, at spend time
<moneromooo> OK, that's good enough for me. Thanks.
<sarang> There's some subtlety in choosing the offsets and such, to reduce heuristics, but the method makes sense
<suraeNoether> bottom of page 10, left hand column
<sarang> Cost would be replacing plaintext lock times with commitments, and extending bulletproofs to include the lock proof
<suraeNoether> this would be the first step toward "private" smart contracts that depend on dev-selected unlock times
<suraeNoether> in a sense it's more basic than DLSAG, almost an independent component used in DLSAG. it should have occurred to me before that it was basically it's own construction...
<sarang> It is an independent component... you can do DLSAG with plaintext trigger heights
<suraeNoether> *nod*
<sarang> but it's probably a bad idea to do so
<endogenic> i have to step out y'all
<suraeNoether> which means it has its own stand-alone security definitions. in this case, the definitions rely on some adversarially generated blockchain, yadda yadda
<Isthmus> I think that would be worthwhile to switch to unlock time commitments... Right now an adversary can partition (/fingerprint) the blockchain into ~20 different anonymity puddles based on unlock time alone.
<Isthmus> When I first plotted it I was expecting a few Easter eggs, not heuristic info bleeding everywhere.
<endogenic> keep killin it Isthmus
<suraeNoether> okay, anyone else want to present any research or thoughts at our roundtable?
<moneromooo> If you guys are looking at making unlock time a commitment, maybe this is a good time to look at a possible semantics change for unlock time to ease future things like atomic swaps etc.
<Isthmus> ^ ooooh
<sarang> How so?
<suraeNoether> yeah, please go on
<Isthmus> Ok, my head is figuratively literally splitting in half, so I'mma peace out. Thanks y'all.
<Isthmus> gg
<moneromooo> By... er... thinking of the requirements you know of for atomic swaps etc, and what semantics would best match those.
<sarang> See ya Isthmus; feel better
<sarang> also see ya endogenic
<moneromooo> I'm thinking in particular of the fact monero's unlock_time semantics do not match bitcoin's, and bitcoin's used for more fancy things like atomic swaps.
<sarang> Ah ok
<Isthmus> Oh but before I go, huge shoutout to @n3ptune who curated the data set
<Isthmus> Ok ciao!
<suraeNoether> moneromooo: yeah, we need to nail down specific examples of usual atomic swaps with bitcoin and how the masked unlock times in monero will play with the unmasked lock times in bitcoin...
<suraeNoether> for sure
<suraeNoether> isthm and i are having a video call about it after he feels better. i'll take notes and we'll draft an issue.
<suraeNoether> allrighty, we are coming up on an hour
<sarang> Action items, I suppose?
<suraeNoether> indeed
<suraeNoether> Mine: sending comments to sarang re: triptych and clsag, consulting with isthm about masking unlock times... which maybe we should do over IRC instead of a video call... to make a donation to sarang's funding request...
<sarang> I'll be continuing that Omniring issue, editing CLSAG/Triptych based on suraeNoether's reviews, and a few odds and ends relating to code libraries and MPC
< does anyone have any last questions?
<sarang> Nay
<sarang> I suppose we can adjourn then
<gingeropolous> when ringsize a bajillion
<sarang> Soon (tm)
<gingeropolous> :)
<sarang> Or the Futurama answer: "Soon enough." "That's not soon enough!"

Logs for the MRL Meeting Held on 2019-12-23

Mon, 23 Dec 2019 00:00:00 GMT

Logs

<suraeNoether> we'll start with GREETINGS. hiya!
<suraeNoether> mele kalikimaka, etc
<suraeNoether> let's move along to the ROUNTABLE
<suraeNoether> i know isthmus has been up to some interesting stuff with block sizes and fees, but he doesn't appear to be here. sarang, as usual, has been busy. you want to start, sarang?
<sarang> Sure
<sarang> I redid the CLSAG linkability and non-frameability definitions, theorems, and proofs
<sarang> and then did a major reorganization of the preprint for clarity and style/format
<sarang> It's ready for suraeNoether's review, and then posting
<sarang> Additionally, the Triptych preprint draft is ready for suraeNoether to review as well
<sarang> and then it can be posted
<sarang> good times
<suraeNoether> word, word
<suraeNoether> does anyone have any questions for sarang?
<sarang> Apparently not!
<mikerah[m]> I have a question for the MRL team regarding L2 scaling for Monero: Are there any scalability solutions currently deployed on Monero? If not, why not?
<sarang> I assume you mean off-chain?
<mikerah[m]> I do mean off-chain
<suraeNoether> not currently deployed. DLSAG and thring signatures are two fundamental pieces of off-chain scaling
<suraeNoether> DLSAG is currently... uhm... accepted for publication? did iirc?
<sarang> Accepted to FC2020
<suraeNoether> that's a spicy meatball, yes
<sarang> Awaiting some likely rewrites for definitions
<sarang> Downside is that indistinguishable refund-compatible transactions don't play nicely with key image requirements
<suraeNoether> mikerah[m]: requires some more research into how to ensure consistency in key image use
<suraeNoether> ^
<mikerah[m]> So, the current state of the art for monero is DLSAG, thring signatures and the Tari sidechain?
<suraeNoether> tari sidechain is independent
<sarang> Tari is a separate project
<suraeNoether> but built on top of monero, from my understanding
<sarang> No
<suraeNoether> er... sidechain
<suraeNoether> not *on top of*
<sarang> IIRC they're doing a MW-based implementation
<suraeNoether> oh
<suraeNoether> news to me *shrug*
<sarang> Hoping to do merge mining
<sarang> But I have not been following their recent work
<suraeNoether> ah
<suraeNoether "news to me *shrug*"> Me too. I guess the association to fluffypony made me assume that it was Monero related
<suraeNoether> well, for my part of the roundtable, my work this week was to start copy-editing triptych and clsag, and to work on my matching simulations. I just made a push this morning... https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
<suraeNoether> anyone can run tracing.py and it will create a data folder, stash human-readable simulated monero transcripts inside...
<sarang> mikerah[m]: to be clear, DLSAG is not deployed anywhere
<sarang "mikerah: to be clear, DLSAG is n"> Thanks for the clarification.
<suraeNoether> these transcripts say things like "Alice sends key NODE_ID with ring members RING_MEMBERS, authorizing the creation of outputs NEW_NODE_ID owned by Bob." It's a "ground truth" ledger.
<suraeNoether> these transcripts also contain the accusations that Eve makes. "Eve thinks ring signature NODE_ID belongs to Bob. In actuality, it belongs to Alice." sort of thing
<suraeNoether> in theory, anyone can fire up tracing.py, tweak the parameters inside, and see the simulated ledger
<suraeNoether> the ledger is working just fine
<sarang> nice
<suraeNoether> unfortunately, but also fortunately, once i put these transcripts into human readable format it became immediately obvious there was a problem with my Eve
<suraeNoether> she is allegedly granted knowledge of her part of the graph, but she doesn't incorporate that knowledge into her matching solution appropriately.
<suraeNoether> so the previous numbers i shared in here, which i took care to explain where provisional, are lower than what we can expect from a realistic eve.
<suraeNoether> these problems were not being caught by my unit tests
<sarang> What needs to be done to properly account for that?
<suraeNoether> the run_experiment function in tracing.py builds a dictionary called eve_ownership, which is not utilized correctly, and allegedly deletes spurious ring members, but i have some evidence that this isn't being done correctly either
<suraeNoether> what really needs to happen is that eve builds a sub-ledger by deleting all her known information, so that it's purely "uknown" data to Eve, before playing the matching game
<suraeNoether> that, together with reporting her known information, would fix the problem
<suraeNoether> since i have CLSAG and triptych to take care of, and since so much of this code is human readable at this point, i'm putting this project down until the new year
<suraeNoether> especially since "the problem" is easily explainable and I can point to where it's occuring
<suraeNoether> but, for example, if anyone wants to just simulate a ledger using different stochastic matrices or spendtime distributions, they can tweak the parameters inside of tracing.py and generate as many ledgers as they like
<suraeNoether> and now you can read them like a story. the world's least interesting procedurally generated story.
<suraeNoether> i'll be unavailable for the next 72 hours or so (family is coming into town) but i have CLSAG and triptych printed; i'm about 1/3 of the way marking up my copy of triptych
<suraeNoether> that's all i have today. does anyone have any questions for me about that, or other questions on anything research-y?
<sarang> When you're done with Triptych, will suggestions be added as Overleaf review comments?
<suraeNoether> i was going to add some as comments and send the rest as an email to you
<sarang> Great, thanks
<sarang> You have the line-numbered version?
<suraeNoether> yep
<suraeNoether> okay, let's move onto ACTION ITEMS
<suraeNoether> sarang?
<sarang> I'll be addressing some multisig-related MPC stuff for RCT3 and Omniring
<sarang> Then working on any necessary updates for CLSAG and/or Triptych based on review
<sarang> and then getting both papers posted to IACR
<suraeNoether> Helping sarang finish triptych and clsag; if i finish this before end-of-year, i'll go back to matching
<sarang> Oh, a longer-term action item is to backport the CLSAG security model changes to DLSAG, but that's likely not this week
<sarang> I don't recall the DLSAG reviewers mentioning it, but it should be done anyway
<suraeNoether> allrighty
<suraeNoether> unless anyone has any final quesitons
<suraeNoether> i think we can adjourn
<sarang> Happy Festivus!

Logs for the Community Meeting Held on 2019-12-21

Sat, 21 Dec 2019 00:00:00 GMT

Logs

<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/421
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<parasew[m]> hello!
<almutasim> Hi.
<Snipa> Hallo all.
<msvb-fab> Helo.
<rehrar> hi
<learninandlurkin> hello there
<txmr[m]> Hi
<ErCiccione> Hi
<sgp_> glad to see many people here and the mattermost relay working
<sgp_> thanks for being here
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> Most notably, a large portion of the community is focused on making the 36c3 a success
<sgp_> There was also "An update from the Core Team on some technical responsibilities" https://web.getmonero.org/2019/12/16/technical-responsibilities-update.html
<kinghat> o/
<sgp_> say hello to Monero's new lead maintainer Snipa!
* sgp_ waits for at least 1 person to say hello
<parasew[m]> hello!
<nevvton[m]> hi..
<sgp_> lol there it is
<Snipa> Morning, glad to be here and looking forwards to driving the project forwards.
<almutasim> Hello. Great! Congratulations to Snipa.
<rehrar> Snipa!
<sgp_> Does anyone have community (non-workgroup) updates to share?
<rehrar> I have written you a ballad.
<kinghat> you get a CEO! and you get a CEO!
<kinghat> new reocuo is out
<sgp_> 3. CCS updates
<kinghat> reouvu*
<sgp_> Funding required:
<sgp_> Sarang: research funding for 2020 Q1 (340.24 / 695 XMR) https://ccs.getmonero.org/proposals/sarang-2020-q1.html
<sgp_> Ideas (to be discussed): None
<sgp_> As discussed during the last meeting, there was a desire to have a standalone page on the CCS for donations to workgroups and contributors. I opened an issue for this: https://repo.getmonero.org/monero-project/ccs-front/issues/1
<sgp_> Is there any material you believe is missing or could be better? Unless someone else can take up this project, it will probably land on rehrar’s plate and will not be touched for a while.
<learninandlurkin> that sounds like a great idea
<ErCiccione> i just PRd my new CCSfor jan-march: https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/111
<ErCiccione> i'm also writing a comment about the past one in this very moment
<sgp_> ErCiccione: cool, we can discuss that too
* needmonero90 arrives
<ErCiccione> sgp_ i'm not completely sure that giving funds to workgroups is a good idea. I mean, how would they be managed? by whom? for what would the funds be used for?
<rehrar> agreed
<ErCiccione> i see a lot of possible controversies
<rehrar> with erciccione
<rehrar> I think that any workgroup that would want to receive money this way must have a statement with who will be in charge of it and how it will be handled.
<rehrar> And that info would have to be posted alongside the address so people know the terms
<rehrar> and if that's the case, it seems to a bit excessive for the CCS website.
<rehrar> Perhaps another (not core team) hosted alternative site for such a thing would be best.
<rehrar> The CCS is, at its heart, a core team arbited crowdfunding thing. I think it's slightly out of scope for the site to also have other fundraising methods not overseen by them
<learninandlurkin> I guess workgroups are meant to be their own independent entities where they can
<sgp_> ErCiccione: I was personally thinking of outreach in particular, who raised funds historically and checks in relatively often with updates
<rehrar> they never claim their paychecks :P
<sgp_> I think it's pretty clear to the donor that if they send funds to a "Monero Outreach" address, that the workgroup manages the funds as they see fit
<ErCiccione> and they are not really transparent with the rewards AFAIK. i mean, there is no public list of transactions that i know of
<sgp_> jtgrassie raised the issue that it was difficult for people to otherwise find groups to donate to outside the ccs
<ErCiccione> sgp_: but what is "the workgroup"?
<sgp_> ErCiccione: I think it's clear in this case transparency is not expected
<ErCiccione> mmh, don't know. I think if we want to have an "open fund" for workgroups, the terms should be more strict
<sgp_> it's not really an open fund
<sgp_> we're not allocating any money
<sgp_> it's a list of addresses that people can donate to if they want
<selsta> Couldn’t you also post your address on the old forum software?
<sgp_> selsta: yes
<selsta> It would be similar to that, just for workgroups.
<rehrar> technically it's against the rules
<sgp_> you could include an address in your profile
<rehrar> I'd be more comfortable with it on a separate site tbh.
<sgp_> rehrar: it's against the rules to include in the CCS ideas/in progress/etc workflow
<selsta> Who would visit that site?
<sgp_> like it or not, to most outside people, the CCS is THE way for people to find projects to contribute to
<ErCiccione> got it, but i'm still not convinced. Maybe rehrar is right and something external might be better
<rehrar> no. It's against the rules to put your address in a proposal.
<sgp_> we can try to push something else, but I'm worried that would be even more complicated
<xmrhaelan> On CCS would be the most effective way to increase support for community projects and I think it would actually help take pressure off the core team in terms of accountability
<sgp_> rehrar: in the proposal is what I meant. I don't see this as a proposal at all
<rehrar> I don't like that this centralizes the workgroups onto core team infrastructure even further.
<sgp_> rehrar: it's an optional thing
<sgp_> monero community workgroup won't be on there
<xmrhaelan> I see that concern.
<selsta> How is posting an address centralization? :P
<rehrar> the workgroups are supposed to be decentralized and separate/non-answerable to the core team. This gives core team power to deny some workgroups over others, effectively creating a "what we deem necessary" approach
<sgp_> rehrar: how is having a list of workgroups centralization?
<xmrhaelan> It’s also the best option. As has been mentioned already it would be difficult to promote yet another site
<sgp_> we already kinda have/had one
<rehrar> I just answered that. Read above.
<Snipa> The only way I could see it causing centralization would be if there wasn't a process for "How does a workgroup get included" and/or that process provided rather direct ways for a workgroup to be excluded that are obviously targets.
<xmrhaelan> Exactly
<sgp_> rehrar: in my opinion this concern is entirely outweighed by the benefits of having a clear page and clear discussions about what groups get added
<rehrar> then iron that out, and I'm willing to reconsider
<rehrar> but it's not currently present
<selsta> right, the alternative would be close to no donations to workgroups
<sgp_> I think we can have a page without being required to list Church of Monero, and for that to be okay
<Snipa> If a workgroup meets the process requirements, then doesn't get included, that's a different problem, but process helps to deal with that in the first place.
<xmrhaelan> So let’s plan to have a temp committee to put together a proposal for what that would look like
<rehrar> *reconsider my position
<ErCiccione> I suggest to create a mock up to show how this proposal would look integrated to the present CCS system, right now it's not entirely clear to me how all this would look
<selsta> sounds complicated :D
<sgp_> I mean, we already have a list for merchants and a basic list of requirements for them to be added
<rehrar> as written, my statement sounds like I'm the decider of this matter and I'm not
<rehrar> sgp_ yes but this is for the getmonero.org website
<sgp_> rehrar: https://web.getmonero.org/community/merchants/
<rehrar> oof I hate this page
<sgp_> lol
<ErCiccione> tell me about it rehrar :P
<ErCiccione> updating it is no fun
<xmrhaelan> +1
<rehrar> another thing that should be moved to a third party
<rehrar> xmrchants.com
<parasew[m]> +1
<rehrar> although it looks like xmr chants.
<rehrar> where we can also list some gregorian chant style Monero songs
<ErCiccione> should be completely reorganized at least, but that requires a good amount of time
<xmrhaelan> MO has discussed plans to build a directory where merchants can add themselves, but that’s a long ways out.
<parasew[m]> but i am also not sure why "libraries and helpers" are merchants
<rehrar> I think
<sgp_> didn't mean to open up another discussion here, just wanted to point out that we have something similar. I don't expect the proposed CCS page to be as chaotic
<rehrar> a workgroup page with donation addresses can be added to the main getmonero.org website if it must be on core infrastructure
<ErCiccione> xmrhaelan: no way for now, they already managed to make my life harder even with the issue template
<ErCiccione> *hard
<rehrar> the Team page was already going to be reorganized into a workgroup page
<rehrar> you know, when I'm not drowning in other work
<parasew[m]> +1 ErCiccione - reorganisation of the merchants part is a very good thing. maybe we could do this in a git repo, where the info is collected
<rehrar> but I can make that a priority after C3
<xmrhaelan> @erciccione It would be on MoneroOutreach.org
<rehrar> anyone care to discuss the merits of having the donation adddresses on this new Workgroups page on the website rather than the CCS site?
<ErCiccione> parasew: there are multiple ways to do that, better open an issue and discuss about it
<xmrhaelan> That seems like a reasonable approach
<sgp_> rehrar: what about the centralization of the workgroups page!
<xmrhaelan> ^responding to Rehrar
<rehrar> If we are really gung ho about the CCS site then I will discuss with core. But the CCS site isn't quite as hands-off about content as they are with getmonero
<sgp_> kidding, I'm open to ideas that include donation links
<rehrar> sgp_ I'm making concessions here for you
<rehrar> ideally, it wouldn't be on getmonero infra at all
<rehrar> but if you guys are adamant about it, I would be much happier with it on getmonero.org rather than the ccs
<sgp_> I'm worried it will conflict with the user mindset of "I want to make a donation, so I'm going to check out CCS"
<rehrar> If anything, a link can be added to the CCS that takes to this page on the website
<sgp_> workgroup page is more "I want to see what's out there and help out"
<rehrar> so they will still go to the CCS with "donation mode" activated, and find where to donate
<sgp_> rehrar: that could work
<sgp_> In any case, it seems like the CCS page is lower priority than the workgroups page
<rehrar> just my thoughts on the matter
<almutasim> It would be good to look at it in terms of what maximizes donations to the workgroups.
<sgp_> but that the workgroups page revamp is well overdue
<rehrar> in other CCS news, Zcoin adopted Monero's CCS.
<sgp_> rehrar, ooh, link?
<rehrar> zcs.zcoin.io
<learninandlurkin> workgroup page as a central place to donate/help/contribute/contact different groups sounds better
<sgp_> rehrar: very cool, thanks for sharing
<ErCiccione> agree with prioritizing the new workgroups page
<learninandlurkin> then keep the ccs as a crowdfunder for specific work over specifc time windows
<rehrar> See? Monero puts out stuff that people want. Yay!
<rehrar> They asked us to help implement, and Xiphon and I used the opportunity to give the CCS some upgrades. Those should be rolling out to Monero in the new year.
<xmrhaelan> Perhaps we go that route, but also add a link on CCS main page pointing back to Workgroups page?
<rehrar> One of the upgrades you can see now: https://zcs.zcoin.io/proposals/test.html
<learninandlurkin> that's actually awesome. Did they get a lot of help setting up or did they just quietly take the code and launch it?
<rehrar> Clicking contribute button doesn't take to a new page.
<learninandlurkin> oh I see
<rehrar> as sometimes those pages were slow to generate or there were a few bugs in the past. And now it feels like a tighter experience.
<sgp_> rehrar: off-topic but after clicking on "milstones" I can't get back to the proposal. just keeps opening/closing the contribute
<rehrar> lolol
<xmrhaelan> I’ve gotta run, looks like we have some more Monero Outreach representation here now. Thanks all. Happy holidays!
<rehrar> aight, I'll see what's up with this
<sgp_> anyway it seems like we're getting sidetracked here, so we can move on
<sgp_> my fault
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> vtnerd contributed some more networking improvements for enhanced privacy.
<ErCiccione> (remember to check out and comment my proposal pls ^_^)
<sgp_> There were many other updates to make the code more robust
<sgp_> ErCiccione: thanks for the reminder. I look forward to your writeup
<sgp_> b. Localization workgroup
<sgp_> ErCiccione: updates?
<ErCiccione> if yo uare referring to the old CSS, it will be just a short comemnt, no write up
<ErCiccione> about localizations,
<ErCiccione> not much really, but soon there will be need for translators. A lot of strings are being changed, especially in the GUI
<ErCiccione> also, in the next months i will work to put getmonero on weblate
<ErCiccione> because translating the website was fine when there weren't many updates
<ErCiccione> but with more stuff coming or changing, we really need a localization platform
<ErCiccione> the problem is that monero-site need some heay tweaks before being fully translatable on weblate
<ErCiccione> That's it, nothing else coming in my mind
<ErCiccione> oh one thing
<ErCiccione> if somebody speak brazilian portuguese, please come chat on #monero-translations. We got many commits changing/updating a lot of stuff, but there is an unprecedent luck of reviewers, and we weren't having too many before...
<ErCiccione> that's everything i can recall now
<almutasim> Weblate sounds great.
<sgp_> thanks
<ErCiccione> weblate -> translate.getmonero.org
<almutasim> Nice.
<sgp_> c. GUI workgroup
<sgp_> A million small UX improvements for consistency have been raised and patched. There is a lot of ongoing discussion lately thanks to a few contributors who are raising many issues, so please participate!
<sgp_> d. Outreach workgroup
<sgp_> They have a draft ready on “RPC-Pay” tentatively scheduled for the week between Christmas and New Year’s.
<sgp_> anything else xmrhaelan almutasim?
<almutasim> We have a couple of other articles in the queue.
<almutasim> And Thunderosa is setting up an Outreach server.
<almutasim> He may have more to add on that. The plan is to have it host a Pay-for-RPC (or RPC-Pay) node.
<thunderosa> We'll be setting up Primo and trying that out as a way to help fund ourselves.
<thunderosa> I think we have a neat way to deploy their software with content and authors. We'll know more clearly in the next week or so on how that might work.
<thunderosa> Otherwise, I'm in catchup mode on the Calendar and merchant projects but expect them to move along much quicker.
<thunderosa> That's about it for me.
<sgp_> thanks!
<sgp_> e. 36c3 workgroup
<sgp_> The organizers are going crazy in #monero-ccc and in real life preparing. The talks will be livestreamed on the Monero Community Workgroup channel https://youtube.com/c/monerocommunityworkgroup
<monerobux> [ Monero Community Workgroup - YouTube ] - youtube.com
<sgp_> Monero Talk will also conduct several interviews. Expect a lot of Monero and privacy content this holiday season. The 36c3 takes place December 27-30 in Leipzig, Germany.
<sgp_> parasew[m]: anything else?
<parasew[m]> C3 workgroup is preparing the last steps for the show which will be from 27th-30th dec in germany!
<parasew[m]> yes, i prepared some updates!
<parasew[m]> the taiga on getmonero holds some information, in case you don’t know what this is about: https://taiga.getmonero.org/project/parasew-36c3/wiki/home
<parasew[m]> There is a large gathering of privacy-related ‘assemblies’ and there will be a live stage, workshops and other programs.
<parasew[m]> Here are pics how this looked last year: https://taiga.getmonero.org/project/parasew-36c3/wiki/35c3-in-pictures
<parasew[m]> Txmr and nevvton are already in leipzig and the setup is working great!
<parasew[m]> Here are some images on the stage setup:
<parasew[m]> http://parasew.com/dl/36c3/1photo\_2019-12-21_16-47-48.jpg
<parasew[m]> http://parasew.com/dl/36c3/1photo\_2019-12-21_16-45-32.jpg
<parasew[m]> And this is how it will look in the end (pics of last year)
<parasew[m]> http://parasew.com/dl/36c3/photo\_2019-12-21_17-16-33.jpg
<parasew[m]> http://parasew.com/dl/36c3/photo\_2019-12-21_17-16-36.jpg
<parasew[m]> the whole cluster can hold about 200 people.
<parasew[m]> This year will be live streamed! Livestreaming will be happening from 2019-12-27 17:00 CET onwards (other days from 13:00 CET) and will be on the monero community channel:
<parasew[m]> https://youtube.com/c/monerocommunityworkgroup
<monerobux> [ Monero Community Workgroup - YouTube ] - youtube.com
<parasew[m]> This year the streaming and recording is coordinated by @getzi (a professional who also worked with the apertus open source cinema camera and with riat before) and @ajs!
<sgp_> (13 UTC is 7am CT)
<parasew[m]> We will have a very amazing show; here is a demo of our stream overlays http://parasew.com/dl/36c3/cdc\_streamtest.mp4
<parasew[m]> There will be a monerotalk (remote) interviews with the speakers as well (just like on the last konferenco), so expect a lot of content!
<nevvton[m]> woop woop !! love it!!
<selsta> looks awesome :D
<thunderosa> nice!
<parasew[m]> :D
<almutasim> Looks and sounds great!
<parasew[m]> Program and website will be online after this weekend, and will be on the usual place at https://decentral.community
<rehrar> goodness there's so much to done and so much to do
<parasew[m]> @rehrar, do you want to give a short sneak peek of the site?
<rehrar> sure. But I don't have the URL on hand. Sec.
<parasew[m]> Here is a sneak peek of the site so far: http://107.191.41.147/ (content still missing, me and rehrar are on it)
<nevvton[m]> http://107.191.41.147/
<rehrar> Ay, you go it.
<parasew[m]> current state of the content is here (but is missing the program still)
<parasew[m]> http://parasew.com/dl/36c3/cdc\_text_v1.md
<rehrar> Yeah, I'm working on that over the next couple of days. Adding assemblies, adding About section. Adding the livestream.
<almutasim> Nice!
<parasew[m]> From tomorrow onwards, there will be further announcements regarding speakers, workshops and bonus program! (hidden gems!)
<msvb-fab> The website is quite nice so far.
* ErCiccione afk for like 15 minutes
<parasew[m]> nevvton: can you give some spoilers?
<nevvton[m]> sure..
<nevvton[m]> its all about the hidden gems, right
<nevvton[m]> So we arrived safely in leipzig and started
<nevvton[m]> setting up our cluster:
<nevvton[m]> everything is running great so far..
<nevvton[m]> stage arrived.. and yes its already being rigged and
<nevvton[m]> mounted,LED light equipment, sound equipment..
<nevvton[m]> so we're actually ahead of time this year.. thats a good thing.
<nevvton[m]> currently txmr, na_tt_i and polto from switzerland
<nevvton[m]> are around helping + plus netg [not to forget overall].
<nevvton[m]> so we have a couple of early hands here in leipzig making this easier...
<nevvton[m]> -- txmr is actuallyx right next to me .. so i'd also dedicate him some time .-...
<nevvton[m]> @txmr
<txmr[m]> yeah..
<txmr[m]> we're looking forward having a great time
<txmr[m]> regarding some 42+ speakers
<txmr[m]> that signed up in total
<txmr[m]> throughout the last days of 2019.
<txmr[m]> streaming links will follow, in case you cannot make it to
<txmr[m]> leipzig.
<txmr[m]> regarding our daily activites at CDC-Cluster @36c3, Leipzig ->

<txmr[m]> i will post all the necessary information,
<nevvton[m]> or i could do, :)
<txmr[m]> timetables and live streaming links
<txmr[m]> daily the follwing days on respective social media channels.
<nevvton[m]> but generally we're in good company here.. ( besides: fun fact
<nevvton[m]> there was a WW2 bomb being found --:) in leipzig.. yes this happens sometimes
<nevvton[m]> so .. yeah .. part of the city (tiny 1km radius) was evacuated.. we were not within the zone :)
<nevvton[m]> but people are friendly.
<txmr[m]> very friendly
<almutasim> All kinds of excitement.
<nevvton[m]> we get big props for lasts years work ..
<almutasim> 42+ speakers is fantastic.
<parasew[m]> almutasim: it could be more, there are still some submissions missing that i know of.
<parasew[m]> If you are attending C3, please enter your workshops and presentations ASAP here: https://frab.riat.at
<nevvton[m]> people are looking forward to this years speakers, all things privacy, hardware related things.. -- everything that defines the core values of our community
<nevvton[m]> we have an e-scooter (for those that are not familiar with the size of this exhibition ground - its huge!! ) saving us energy
<nevvton[m]> and its covered with monero stickers.. so people are already psyched to meet everyone at our cluster ..
<nevvton[m]> :)
<sgp_> thanks for the updates, looks like it will be a good time
<sgp_> anything else before I proceed?
<parasew[m]> This all was made possible through the CCS and a lot of voluntary work. Thanks to everyone who supported this!
<txmr[m]> i further want to emphasise on the CCS contributors
<txmr[m]> Thank you all!
<nevvton[m]> yes also from my side:
* nevvton[m] sent a long message: < https://matrix.org/\_matrix/media/r0/download/matrix.org/oinctLynLkmCdxaLgbFYHhhu >
<almutasim> Lucky attendees! And lucky the rest of us with streaming.
<sgp_> nice, good luck! look forward to watching the streams
<sgp_> f. Hardware workgroup
<nevvton[m]> <sgp_ "nice, good luck! look forward to"> ty
<msvb-fab> Sorry, no report from the hardware team. I'm in the lab right now printing enclosures.
<sgp_> msvb wanted to give an update. are you here and can make it fast? Otherwise there will most likely be an update during the conference
<sgp_> ok, keep working msvb-fab :)
<msvb-fab> Otherwise, unless anyone has a specific question please move on to the next topic.
<sgp_> g. Konferenco workgroup
<sgp_> pebx continues to search for a Berlin location. He has focused only on locations that allow our own AV and catering.
<msvb-fab> Almost the same thing, my files are not with me so I can't give details of last week's Berlin venue scouting.
<nevvton[m]> i casn totally help as being a berliner..
<sgp_> nothing else to add here at the moment, other than to contact him on Reddit u/pebx if interested
<nevvton[m]> i will contaxct pebx
<sgp_> h. Monero Research Lab
<msvb-fab> Does anybody have a specific question about Konferenco 2020 venue choice?
<parasew[m]> yes, what is the venue choice
<sgp_> msvb-fab: after speaking with pebx, it seems like the venue isn't chosen yet and that a few options are still being contacted
<msvb-fab> The choice follows a report which is not stable yet. The chioce has not been made.
<parasew[m]> why not university? the venues looked expensive.
<msvb-fab> Both universities have denied.
<parasew[m]> lol
<msvb-fab> And BBC denied, so those three are not part of the report.
<nevvton[m]> so.--.
<msvb-fab> Not BBC, rather BCC. Berlin Congress Center.
<nevvton[m]> i certainly can help..
<nevvton[m]> i have a couple of good options in mind..
<msvb-fab> Thanks nevvton, unless there are more detailed questions we can move on sgp.
<sgp_> next steps are to contact pebx and to get a more direct line of communication, potentially on Wire
<nevvton[m]> :)
<sgp_> h. Monero Research Lab
<sgp_> Surae made significant progress on his matching code, with preliminary results now available for validation. Sarang did some moon math. Their meeting logs are on Github under meta.
<sgp_> oh, and a nerew version of clsag is almost out
<sgp_> *new
<sgp_> attend their Monday meetings if you're interested in following their progress
<rehrar> good stuff coming?
<sgp_> I'm going to skip 5. open ideas time since we're already over
<sgp_> rehrar: yeah, more work on triptytch (or however it's spelled) too
<sgp_> A few final things:
<sgp_> I need help updating this roadmap for Monero 2019 and 2020. Please contribute any major items I missed (especially website changes) https://cryptpad.fr/code/#/2/code/edit/AvAp1k1pPjW4lZ2lO3A4rr9e/
<sgp_> I worked on 36c3 and GUI tasks this week instead of writing up a draft of the emergency response process. I will focus on this more the next two weeks (lower productivity this week). Hopefully we can discuss it during the next meeting :)
<sgp_> Anything final before we conclude?
<thunderosa> Merry Christmas Monero!
<rehrar> merry christmas, happy holidays
<sgp_> indeed
<Jae> Let's make 2020 the year of Monero :D
<sgp_> Monero Coffee Chat: Christmas Day edition?
<sgp_> (kidding)
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 4 January at 17:00 UTC.
<sgp_> There will be NO COFFEE CHAT NEXT WEEK since we will already have livestreamed content for 36c3. The next Coffee Chat is on Saturday January 11 at 17:00 UTC.
<Jae> Where will be the meeting?
<sgp_> Jae: community meeting is here (#monero-community)
<Jae> Oh, ok
<sgp_> Coffee Chat is on YouTube/Jitsi
<Jae> I thought there was in a physical place x)
<Jae> this*
<sgp_> haha not quite
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

An update from the Core Team on some technical responsibilities

Mon, 16 Dec 2019 00:00:00 GMT

The Core Team would like to share with the community some changes of responsibility that are expected to better streamline developments and collaborations going forwards.

Lead Maintainer Transfer

fluffypony is stepping down as the lead maintainer of Monero. Snipa will be taking his place. fluffypony will continue as a backup maintainer to relieve Snipa during times when he is busy or on vacation.

fluffypony has served the Monero project well over its five years of existence, and he will continue to remain active in the community as a maintainer.

Snipa is a longtime contributor to Monero. He is best known for developing a popular piece of Monero pool software and supporting the network with well-connected nodes. He has substantial coding and auditing experience, and a desire to better Monero's processes.

luigi1111 will continue as a backup maintainer of the CLI repository.

Release Engineering and Signed Hashes

selsta is taking over most release engineering responsibilities for the CLI. Snipa and fluffypony will be available as backup CLI release engineers.

xiphon is taking over most release engineering responsibilities for the GUI. luigi1111 and fluffypony will be available as backup GUI release engineers.

binaryFate will take over signing the hashes of the release binaries and uploading them.

Website and Download Server Access

binaryFate will become the backup for control of the various core Monero domains, in addition to fluffypony. Domain changes are rare, and mostly consists of renewing the domains when necessary.

binaryFate and luigi1111 will take over the primary administrative responsibilities for the DNS records and the CDN, with pigeons and fluffypony as backup. These changes are typically triggered when a new release happens.

binaryFate is getting access to the downloads server, in addition to pigeons and fluffypony who currently have access.

General Fund and Community Crowdfunding System

binaryFate will administer the General Fund wallet.

rehrar and Justin Ehrenhofer are getting access to the CCS repository. luigi1111 is getting access to the CCS Monero wallet and will administer payouts. These changes will allow the CCS to operate more smoothly.

The private view key of the CCS wallet will be added to the CCS website to increase accountability.

Monero-Announce mailing list

luigi1111 and binaryFate are gaining the ability to approve emails sent to the Monero-Announce mailing list, in addition to pigeons and fluffypony who are the current approvers.

The Monero-Announce mailing list is an important notification tool for network alerts, new releases, and important discussions. Please subscribe to it to stay updated!

Logs for the MRL Meeting Held on 2019-12-16

Mon, 16 Dec 2019 00:00:00 GMT

Logs

<sarang> GREETINGS
<suraeNoether> howdy!
<suraeNoether> suppose we should move onto the roundtable?
<sarang> Might as well
<sarang> Who shall begin?
<suraeNoether> I'm going to ping isthmus
<suraeNoether> in the hopes that he can describe a bit of the data science work he's currently doing
<Isthmus> n3ptune and I have been looking at block rewards
<Isthmus> Lots of funky stuff going on
<sarang> How so?
<Isthmus> Isthmus is digging up figures
<Isthmus> Here's a bad figure, and I'll try to have a nicer one by the end of the meeting
<Isthmus> https://usercontent.irccloud-cdn.com/file/f9F4XDd3/image.png
<Isthmus> x-axis is block height
<Isthmus> y-axis is the total reward claimed by the miner
<Isthmus> (fresh + fees)
<Isthmus> The trend is basically our emission curve (the bottom of the traces)
<Isthmus> The data points above the trend are miners who made good blocks with fees on top of reward
<suraeNoether> exponential decay shape of the graph comes from our emission curve (fees are related to block reward). is the piecewise break from bulletproofs?
<Isthmus> The anomalies below the line are what's interesting
<Isthmus> There's a few distinct events that happened
<Isthmus> For each, we can tell a few things:
<Isthmus> Exactly which blocks were mined by that miner/pool/software
<Isthmus> (linkability)
<Isthmus> And exactly how long it took them to notice that they were making suboptimal blocks, and fix the software
<Isthmus> You can tell a bit more by adding size as the color
<Isthmus> https://usercontent.irccloud-cdn.com/file/HUoctx7I/image.png
<Isthmus> Scale is blue to yellow
<Isthmus> So there I've zoomed into a small section
<Isthmus> Looking at the band from 1225000 to 1275000ish
<Isthmus> It looks like the blocks claiming *less* reward than empty blocks are about the same size as those produced by others
<suraeNoether> that graph is gorgeous bro
<Isthmus> thx :- )
<sarang> Odd behavior
<sarang> The definition of suboptimal, you might say...
<Isthmus> Yeah, because their sizes are about the same as the surrounding blocks, here are two guesses for what might be happening
<Isthmus> Maybe other miners are making high-fee big blocks, and the ones below the trend are the suckers that make big blocks after the mempool has been tapped out for high-fee txns
<Isthmus> But based on how bounded the second (anomalous) trend is, I think it might just be a software bug?
<Isthmus> I just discovered this like 20 hours ago, so I haven't done full exploration
<Isthmus> I'll be able to drill down into the blocks and actually figure out what was going on
<Isthmus> (that's about where it's at right now)
<sarang> It's really interesting to see it mapped out so clearly
<suraeNoether> thanks so much, isthmus; it seems to me like i've read at least one paper about purposely claiming smaller rewards for a variety of game-theoretic reasons...
<suraeNoether> i'm going to try to dig up at least one of htem
<suraeNoether> i have so many questions about this
<sarang> It would be good to know which particular software (if it's specific) leads to this, due to how common it appears to be
<sarang> suraeNoether: your roundtable?
<suraeNoether> yeah, sure: Matching. I *think* i'm *one* bug away from getting all the data i want. and I'm talking to Insight Data Science to throw a fellow at the simulation results to help me come up with best-practices recommendation
<suraeNoether> my current bug is silly and strange, in that i'm not adding the number of nodes and edges my software is expecting. initially i thought this was a problem with computing the number of available ring members or something like that, but i'm still trying to figure it out
<sarang> Do you have code ready that can reproduce it?
<suraeNoether> it occurs in a random test in testSimulator.py, not any of my deterministic tests
<suraeNoether> so i'm still hunting down exactly the conditions that lead to the bug, and attempting to isolate it as a new unit test
<suraeNoether> the graph theoretic component is working perfectly, the analysis component exploring parameter space is working perfectly, but the simulator keeps hitting this snag and then we're off to the races
<endogenic> oops, here
<suraeNoether> welcome
<endogenic> suraeNoether: you dont think V could make all those masks by himself even in 20 years though?
<sarang> suraeNoether: is the currently-pushed code the version you're working with?
<suraeNoether> yes, the commit i pushed this morning
<suraeNoether> to matching-buttercup branch
<suraeNoether> so, someone brought up by sidechannel the question about whether i should re-implement the sims in rust in the hopes that the improved explicit references of rust would help find the errors
<sarang> Do you suspect that could be the origin of the errors?
<suraeNoether> i think refactoring the whole codebase is a last-ditch effort for finding the bugs, though
<sarang> If they're simply algorithmic mistakes, switching to Rust might not do anything
<suraeNoether> no; i literally think i'm merely predicting the number of nodes and edges incorrectly based on the total nodeset as opposed to only the nodes that can be spent.
<endogenic> have you tried log statements?
<endogenic> secret weapon
<suraeNoether> and i'm in the midst of tracking that down
<Isthmus> Could you tweak the simulation to be 3 blocks long, 2 transactions per block, with spend pattern & ring member selection algorithm = pull from previous block
<Isthmus> Would the issue persist and be easy to spot by eye?
<sarang> endogenic: your suggestion reminded me of https://xkcd.com/451/ =p
<endogenic> except that i am
<endogenic> :P
<sarang> Nono, the statement about logs!
<sarang> Sorry, digression
<suraeNoether> isthmus unfortunately i believe the problem may be in the ring selection algorithm i have written (which is only uniform at this point), so that would reduce the problem away
<suraeNoether> but i'm attempting something similar next
<suraeNoether> right now, debugger is my friend
<suraeNoether> sarang, how about you?
<endogenic> log statements are nice because you can let the whole thing run
<sarang> Several things to mention
<endogenic> debugger is also nice.
<sarang> I modified the linkability and non-frameability definitions in Triptych, and would like to see if they can be directly used in CLSAG as well
<sarang> I've come around on Backes' definition of linkability
<sarang> I updated the CLSAG linkable anonymity definition, as well as its proof
<sarang> Reviewed a paper by the Zcoin folks on hierarchical Groth commitment proofs
<sarang> Looked over some changes that Zcoin made to fix a problem they had relating to Groth proofs (doesn't apply to Triptych)
<sarang> Worked out some example code for doing inversion via an MPC for use in computing certain linking tag constructions
<sarang> and wrote out some simple draft MPC ideas for RCT3 and Triptych, which for now assume honest-but-curious players
<suraeNoether> nice!
<sarang> The good news on MPC is that it's certainly possible to collaboratively compute the inverse-based key images used in those proving systems
<sarang> The bad news is it requires something akin to Paillier encryption, which leads to some computational overhead
<suraeNoether> hmmm are you looking into the MPC stuff for linking tag constructions due to the constructions and usage of linking tags in Triptych?
<sarang> (note that my example code should _not_ be taken to be a secure Paillier implementation)
<sarang> Yep, the MPC is to handle linking tags in Triptych, RCT3, and Omniring
<sarang> Even though Omniring can use traditional linking tags, even that construction still requires an underlying inversion
<sarang> There are also affine quantities to compute, but those are understood
<suraeNoether> refresh my memory: which, if any, of those 3 require self-sends?
<sarang> None of them
<sarang> DLSAG and Lelantus would require this
<endogenic> LELANTUS
<suraeNoether> okay, so what, in your heart of hearts, are you hoping for from linking tags?
<sarang> The problem, previously, was that it was not clear how to enable multisig support when the linking tags require a secret key inversion
<suraeNoether> aaaaah
<sarang> Now that there's an understood MPC to compute this, it means multisig support is feasible
<suraeNoether> gotcha gotcha
<suraeNoether> you had questions about multisig for me
<sarang> The downside to the MPC is that Paillier can't take advantage of the efficient curve libraries we all know and love
<suraeNoether> we can address them now or after the meeting if you like
<silur> hoi sorry for being late
<Isthmus> holla
<suraeNoether> long time no see silur
<endogenic> whatup silur
<sarang> Paillier requires RSA modulus stuff (but there aren't issues with trusted setup etc.)
<sarang> Encryption and decryption require exponentiation with variable modulus
<sarang> So computationally-constrained devices would need to able to support this
<sarang> s/to able/to be able
<suraeNoether> so are we hoping for an MPC to compute inversion-based key images... such that the MPC is more consistent with the development history of monero/cryptonote? ie based on the DL setting in Ed25519 instead of RSA?
<suraeNoether> or at least, one of the items on our "wish we had" list?
<sarang> Such a thing would be great, but as you pointed out, getting the required homomorphicity would imply a DL break, or some such thing
<silur> can you elaborate on "inversion based key images"?
<silur> or shall I just review it from the log?
<sarang> Key images / linking tags in newer proving systems use the form (1/x)\*U
<suraeNoether> rather than x*H(X)
<suraeNoether> U is fixed, yes?
<sarang> Here the division is an inverse, x is the secret key, and U is either globally fixed or depends on the proof statement
<sarang> but it's public
<suraeNoether> uhmmmm wait a moment:
<sarang> It's globally fixed in the more efficient versions of the proving systems
<suraeNoether> my comment had to do with an efficient group-to-scalar map that had any sort of homomorphicity built in
<suraeNoether> oh oh oh
<suraeNoether> i get what you are saying
<sarang> For context: https://github.com/SarangNoether/skunkworks/tree/inverse-mpc
<sarang> The inverse.py script shows how the process works, and the markdown documents describe one possible use for RCT3/Triptych (again, with many assumptions on the players)
<sarang> The encryption homomorphicity is important for the MPC method that Gennaro and Goldfeder introduce
<suraeNoether> so most generally, each person has a secret x_i and there is a function f such that you want to compute f(x_1, ..., x_n)*U with some friends. you were using f(x_1, ..., x_n) = 1/sum(x_i) ?
<suraeNoether> you know what: let's talk about this after the meeting
<sarang> Yeah, better for after meeting
<suraeNoether> so, isthmus, myself, and sarang have all brought the room up to speed. does anyone else want to talk about any monero-related research they are doing?
<silur> can't we somehow exploit the bootle inner-product encryption with a killian randomization here somehow? the killian randomization preserves linear combinations so everything before multiplying with U is the same
<silur> but individual inputs are useless
<silur> and at the last step the same inner-product for the last vector reduces into a Z_p element?
<sarang> I don't see how to directly apply that to the share derivation in Gennaro
<sarang> The multiplicative-share to additive-share method, I mean
<sarang> (which is the point of their Paillier-based protocol)
<silur> Oh the Genaroo-Goldfeder method IS a hard requirement
<silur> then we can't inded :)
<silur> I wasn't aware it's a must-have
<sarang> Well, we don't _need_ to use Gennaro-Goldfeder
<sarang> but it seems reasonably efficient and useful if you can accept the homomorphicity requirement
<sarang> In the interest of time, let's move to ACTION ITEMS
<sarang> Mine are to continue work on the MPC stuff, get CLSAG definitions ported as necessary (would like to discuss with suraeNoether as well), and get final review on the Triptych draft to get posted to IACR
<silur> triptych? O.o
<sarang> ?
<suraeNoether> mine is to hunt down and kill my final bug, work on the churn report, review the triptych draft (finally) and continue chatting with isthmus about getting a data science fellow working with me on matching/churn
<silur> I was not familiar with that, will look into
<suraeNoether> it's a paper sarang is presently writing
<silur> too much meetings missed :D
<sarang> silur: Triptych is a linkable ring signature construction based on Groth 1-of-many commitment proofs
<3
<sarang> Preprint draft forthcoming
<sarang> There's a super-efficient version for which I can't reduce soundness to a known hardness assumption
<sarang> If you want to take a look silur, most welcome
<sarang> The less-efficient version does reduce nicely
<silur> yea I'd be more than happy to look into
<sarang> neat
<sarang> OK, I suppose we can formally adjourn and continue discussions as desired

Release 0.15.0.2 of Monero GUI

Sun, 15 Dec 2019 00:00:00 GMT

Overview

This is the v0.15.0.2 release of the Monero GUI software. This release mostly introduces bug fixes and improvements to the user experience.

Changelog

The major changes introduced with this release are:

Fix Trezor support on Linux
Fix blank screen on Tails startup
Translation improvements
Fix update notification hash
Persistent subaddress account selection
Various UI/UX improvments
Minor bug fixes and performance improvements

Note that you can find a full changelog on GitHub.

Download Links

You can also compile it from source by yourself. See the instructions on GitHub

Verify Hashes

monero-gui-win-x64-v0.15.0.2.zip, 8684d9ba3cdad8f9b73bbcae85a69f7eb3cfd27db030163485e066131b68e7b7
monero-gui-install-win-x64-v0.15.0.2.exe, e09edd01afa7f2224b3498825e5ba5dcf3fe887efb0b3ff07bbc30c5bce847f1
monero-gui-mac-x64-v0.15.0.2.tar.bz2, a652484a2a74f0d2697a4f0c000221d2a90927b8b8d536f1429756596d048f90
monero-gui-linux-x64-v0.15.0.2.tar.bz2, e21d688b5e26c3dea7c774e97fdd44f169abd218d212378eaacab5c64ea80f7d

Logs for the MRL Meeting Held on 2019-12-09

Mon, 09 Dec 2019 00:00:00 GMT

Logs

<sarang> Let's go ahead and get started with GREETINGS
<kinghat> o/
<sgp_> hello
<sarang> That's long enough!
<sarang> Let's move to ROUNDTABLE
<sarang> suraeNoether: what up with you
<suraeNoether> i'm terribly ill this morning, so my update will be very brief. my work in this past week has involved three incomplete tasks:
<suraeNoether> 1) CLSAG linkable anonymity proof required some thought. sarang and i have thought about it and we have a strategy to finish writing the proof. sarang: do you want to make the changes to our LA definition or do you want i should?
<sarang> suraeNoether: I have a writeup for LA in my notebook that I'm transcribing to TeX
<suraeNoether> and proof* not just the definition
<sarang> it works just fine
<sarang> On that note
<sarang> Do you have any thoughts on linkability (not LA)
<sarang> I don't particularly like the Backes definition
<suraeNoether> uh one sec
<sarang> Triptych has a version of linkability+non-frameability that I like better
<suraeNoether> is there soemthing wrong with the definition we proposed initially?
<suraeNoether> iirc that one's from bender
<sarang> It's not formalized quite enough, in the apparent opinion of the reviewer
<sarang> I think it needs just minor work
<sarang> Triptych formalizes it a tad more IMO
<sarang> I can add that to the writeup if you like
<suraeNoether> well
<suraeNoether> for the sake of the audience, can you describe the 3 different definitions you want to consider? or 2, assuming you want to bail on backes'
<sarang> Backes requires the following for an LRS: completeness, linkable anonymity, linkability, non-frameability
<sarang> Right now we combine linkability and non-frameability with non-standard terminology
<sarang> Backes uses a particular linkability definition: can the adversary use q keys to generate q+1 non-linking signatures?
<sarang> Where q is scaled via the security parameter
<sarang> I don't particularly like this definition over the "usual" one about producing two linking signatures, but I think it's important to frame the definition as a challenger-player interaction
<sarang> Our current method does this very informally
<sarang> I propose a combined linkability definition in my Triptych writeup that's a slight formalization of what CLSAG has now
<sarang> (it could easily be split into linkability and non-frameability)
<suraeNoether> hmmmm q scaling with the security parameter is the weird part to me: if the security parameter goes up, so does q... and so this means, for example, the adversary can't produce 3 signatures using 2 keys without some linking occurring. this feels *weaker* than the statement "can't produce two signatures using the same key without them being linked"
<sarang> Yeah, which is why I don't really like it
<sarang> didn't sit well with me
<suraeNoether> and we want the property with q=1 anyway to prevent double-spending
<sarang> So I am proposing not using the Backes definition, but simply formalizing what we have now, a la Triptych
<sarang> then it's more clear what the linkability player has access to in terms of keys etc.
<suraeNoether> okay, i'm going to read more deeply into that this afternoon
<sarang> IMO it's a pretty straightforward formalization
<sarang> doesn't affect much in practice
<suraeNoether> backes' definition with q=1 seems to me to imply backes' definition with greater q, but it's possible that it doesn't technically reduce the way it seems. i'll think more about it
<sarang> That definition doesn't make assumptions about linking tags being equal AFAICT
<sarang> Whereas ours does
<sarang> I think that's part of it
<sarang> Anyway, you were talking about work you'd been doing, before I barged in =p
<suraeNoether> moving along, my next incomplete task is reviewing triptych's security proofs more deeply, which dovetails with this :P
<sarang> Yeah, a nice tie-in
<suraeNoether> finally, i'm working on matching simulations today. i'm experiencing a data management and presentation issue, but i hope for the end of the day a nice graph displaying performance of Eve as a function of ring size and churn length
<sarang> Nice!
<suraeNoether> this will come along with a push to my repo with all the code used to generate that, and explanations so people can replicate it
<sarang> word
<suraeNoether> that's it, if i had presented in the other order then your "barging" would have been a great segue into *your* work for the week :P
<sarang> We can pretend otherwise
<sarang> I have completed a draft of the Triptych preprint, which is now in suraeNoether's hands
<sgp_> suraeNoether: I'm really looking forward to that chart
<sarang> it includes my proposed linkability+non-frameability definition
<sarang> Figured out the CLSAG linkable anonymity definition, which is not as strong as Backes, but does the job IMO
<sarang> I've also been working with Aram from Zcoin on some related Groth proving system stuff
<sgp_> what's the shortfall on the linkable anonymity definition, even if there's no practical difference?
<sarang> There will be a neat paper coming out from them on that shortly, which they graciously provided to me in advance
<sarang> sgp_: Backes permits key corruption, which doesn't work with our DDH hardness assumption
<sarang> Instead, we assume the adversary can obtain key images
<sarang> And that the adversary can pack rings with their own malicious keys
<sgp_> sarang: thanks
<sarang> (which you can assume are trivially corrupted)
<sarang> This is already stronger than the existing definition that was used
<sarang> Otherwise, I also wish to update the DLSAG paper (which will appear next year in conference proceedings) with the CLSAG security model, since they are structurally extremely similar
<sarang> So overall, a lot of tedious (but still interesting) stuff involving formal definitions and proofs
<sarang> When suraeNoether finishes his review of the Triptych preprint, it'll go to the IACR archive
<sarang> and presumably any CLSAG/DLSAG updates as well
<suraeNoether> hmm Backes' linkability definition is a puzzle i have very little intuition about: should it be harder or easier to present 2 signatures from the same key without linking the signatures than it should be to present 201 signatures from 200 different keys without any of them linking? *taps chin*
<sarang> The adversary picks which keys IIRC, right?
<suraeNoether> yeah, adversary can use KeyGen or any other way of selecting the verification keys
<suraeNoether> may not even know the secret key, so it's genuinely adversarial
<sarang> ya
<sarang> The adversarial generation isn't really a big deal, since soundness implies the adversary's choice of keys satisfy the verification equations
<sarang> and then you rely on the one-way mapping
<suraeNoether> actually, it's not clear; each verification key needs to be in \mathcal{VK}, and it's not specified where that comes from, i'm assuming from the challenger
<suraeNoether> in which case the adversary has to pick challenge keys to break linkability, it's not enough for the adversary to pack all rings with fake pubkeys
<sarang> Backes even notes that generating q such signatures is trivial, since you simply use separate keys
<sarang> Fake pubkeys should be acceptable
<sarang> since the adversary does all this offline, or otherwise generates the pubkeys in its own (seemingly) valid transactions
<sarang> The q=1 case feels like some kind of targeted linking attack, where the general q case seems like a broader "hope for a collision somewhere" attack
<sarang> suraeNoether: thoughts?
<suraeNoether> nothing concrete. the way this definition is written feels very very counter-intuitive to the way you and i have discussed linkability in the past.
<sarang> Yeah, and I haven't seen it anywhere else
<sarang> Again, I don't feel any particular need to use it
<sarang> But getting the existing definition more formalized in a challenger-player sense seems wise
<suraeNoether> agreed
<sarang> roger
<sarang> OK, that's my update
<sarang> Does anyone else have interesting (or uninteresting) research to share?
<suraeNoether> ok, dude, i think i know the problem here
<suraeNoether> with that definition
<suraeNoether> or at least my problem with it
<sarang> Ooh, go on
<suraeNoether> linkability is a property that has a "correctness" component and a "soundness" component. to correctly link two things means to link them when they should be linked. to soundly link two things is to *only* link them when they should be linked
<suraeNoether> you called this positive and negative linkability at some point
<suraeNoether> i feel like this definition is mashing the two together
<suraeNoether> or attempting to
<suraeNoether> anyway, my thoughts don't go deeper than that yet
<sarang> Backes uses non-frameability to show that you can't make signatures that _appear_ to link without knowing/using the same key
<sarang> and linkability to mean that you can't make sigs with the same key(s) but different tag(s)
<sarang> The reviewer didn't like the CLSAG paper's use of positive/negative/soundness in linkability
<suraeNoether> hmm
<suraeNoether> okay, that's going to require more thought
<suraeNoether> anywya, now i'm done. :P
<sarang> A lot of this is simply getting the right terminology for the definition(s) of choice
<sarang> I happen to like using linkability to refer to both
<sarang> since that's typically what you want
<sarang> but it's two different concepts
<sarang> OK, we can move on to any other research
<sarang> or to the next topic, QUESTIONS
<suraeNoether> i have a pretty general observation
<suraeNoether> which may be relevant in terms of independent interest
<suraeNoether> a property like linkability applies to all ZK proofs. for example, our ring signatures are ZK proofs of knowledge of a secret key. but they are *linkable* proofs of knowledge, so that if the same witness data (keys) are used for two different proofs (signatures), then an observer can link them.
<suraeNoether> so just like ZK proofs have a property of correctness (if you know a witness, the proof is valid) and a property of soundness (if you don't know a witness, your proof is invalid), a linkable ZK proof is going to have a dual pair of notions for linkability
<suraeNoether> i bring this up so that the next version of snarks has an L floating around
<sarang> There's a related-ish property in sigma protocols, quasi-unique responses
<sarang> But that relates to responses to the verifier challenge
<suraeNoether> more reading to do :\
<sarang> There's probably a subtle relationship to (SHV)ZK
<sarang> and therefore witness indistinguishability
<sarang> (which follows from SHVZK)
<suraeNoether> anyway
<sarang> Normally, providing two proofs should not reveal distinguishing information about the witnesses
<suraeNoether> right
<sarang> Hopefully you will enjoy the Triptych paper, which builds a linkable construction on top of a sigma protocol :)
<suraeNoether> i enjoyed it the last time i read it, and the tiem before that. it takes awhile to digest :P
<suraeNoether> ok, i gotta bounce, i'm not feeling well; my list of 3 unfinished tasks is also my list of action items today
<sarang> roger
<sarang> My ACTION ITEMS are getting these new definitions and proofs typeset and finalized, determining their DLSAG applicability, a few other organizational issues on the CLSAG paper to prepare it for resubmission, and getting Triptych submitted on review
<sarang> Any other final thoughts, comments, or questions before this meeting ends?
<moneromooo> I have an unrelated question.
<sarang> ?
<moneromooo> I was wondering whether atomic swaps between two cryptonotes with hte same curve etc (ie, not the general case) is possible now.
<moneromooo> Well, assuming the tooling was there of course, which it isn't.
<moneromooo> In theory I mean.
<sarang> I don't know of a good way that retains indistinguishability as well as DLSAG does, and that still has the tracing issue
<sarang> If you were willing to accept and mitigate the tracing issue, then its method could do it
<sarang> its = DLSAG's
<moneromooo> What is the tracing issue already ?
<sarang> The fixed basepoint used for dual-address key images allows determination of unwanted signature linking
<sarang> It isn't clear how to do a DLSAG-type construction with the variable-basepoint key images used currently
<sarang> I should more precisely say, the use of a fixed basepoint and having output private keys used as the corresponding key image discrete log (this doesn't exist in more recent constructions that use a fixed basepoint but in a different way)
<sarang> Oh, suraeNoether: do you think it's useful in the LA definition to include the linking tag oracle separately from the signature oracle?
<sarang> The player can get the linking tag oracle result simply by querying the signature oracle on a public key by using a random ring and message (and ignoring everything but the returned linking tag)
<sarang> Having a separate oracle only really serves to make it clear that the player doesn't necessarily need to convince a user to sign messages, but can obtain linking tags otherwise
<sarang> (although in this security model, it can do both)

Logs for the Community Meeting Held on 2019-12-07

Sat, 07 Dec 2019 00:00:00 GMT

Logs

<sgp_> Meeting time!
<rottensox> :-D
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/418
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<rottensox> o/
<rottensox> wuddup bra.
<sgp_> ping rehrar needmonero90 ArticMine ErCiccione[m]
<rottensox> ping all.
<needmonero90> Oh right
<needmonero90> This is today
<hyc> I thought yesterday was today
<rottensox> wat.
<ajs[m]> hi
<sgp_> welcome everyone! thanks for coming
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> The special upgrade edition Coffee Chat was the most-viewed to date, with 248 hours of watch time and 1,300 views. This is more watch time than the previous record held by the November 2017 Coffee Chat.
<sgp_> (thanks of course to everyone who helped make it possible)
<sgp_> Note that the Monero website was compromised for a short period of time. Please see this: https://getmonero.org/2019/11/19/warning-compromised-binaries.html
<sgp_> You can see the meeting logs here: https://github.com/monero-project/meta/issues/413
<sgp_> The Core Team made a blog post about the administration of the general fund: https://getmonero.org/2019/12/03/core-team-general-fund.html
<sgp_> And of course, the Monero network upgraded successfully!
<sgp_> Does anyone have community (non-workgroup) updates to share?
<rottensox> launch your native tongue monero-focused podcast.
<rottensox> :-)
<sgp_> indeed, please make more content everyone! in all the languages
<needmonero90> The subreddit will be codifying the informal 'two week between advertisements' and 'no reflinks' rules that have been enforced without being listed for ages
<sgp_> thank goodness reflinks are officially banned
<monerobby> I launched xmrnotify.com :)
<sgp_> welcome monerobby!
<rottensox> reflinks officially banned? hmm?
<needmonero90> They have been unofficially
<monerobby> hello
<needmonero90> Hi
<sgp_> 3. CCS updates
<sgp_> Funding required:
<sgp_> 36c3 supplies (503.88/560 XMR) https://ccs.getmonero.org/proposals/36c3.html
<sgp_> Multiple features and fixes for getmonero.org: https://ccs.getmonero.org/proposals/ErCiccione-website.html
<sgp_> wait, never mind that second one! already in progress whoops
<sgp_> Surae: research funding for Nov 2019 – Jan 2020 (339.07 / 499 XMR): https://ccs.getmonero.org/proposals/surae-q4-funding-2019.html
<sgp_> Ideas (to be discussed):
<sgp_> RandomX thanks: https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/107
<sgp_> This received mixed feedback
<sgp_> Some people recommended immediately adding this to "completed tasks" with a donation link instead of funding required
<sgp_> Others prefer for it not to be added to the CCS, saying another donation platform is more appropriate
<sgp_> And of course some people feel it should be added as-is
<sgp_> jtgrassie needmonero90 want to give some comments?
<rottensox> i liked needmonies90 comment.
<needmonero90> luigi1111w ping
<sgp_> fwiw, I merely want to note that I spoke with a few other people who wanted to donate to RandomX, and they found the process of donating to the provided Github link to be unclear
<needmonero90> My thoughts are already basically all expressed
<sgp_> the user I spoke with wanted a clear way to contribute to all RandomX contributors. They felt confused on how the GitHub donations would be dispersed and it took them a little while to find
<sgp_> of course, that doesn't necessarily suggest that the CCS is warranted for these reasons
<hyc> I'm not sure I see how this is a *misuse* of the CCS though.
<needmonero90> In short, paying for work retroactively cheapens the work done for years by other people without pay
<sgp_> but I wanted to forward the feedback
<needmonero90> It's not a misuse. I am concerned about precedrbt
<needmonero90> Precedent
<sgp_> needmonero90: I don't quite agree with your perspective since people can donate for any reason on any platform to anyone, but I don't think the CCS is ideal for this
<hyc> So it's a bad precedent to thank people for work done, after the fact?
<rottensox> 'While I really like the sentiment, I'm a bit worried about the precedent that this would set for the project as a whole. I think using the CCS for this particular initiative is a misstep, personally.
<rottensox> I would have zero problems with self directed donations directly to the contributors, or even a separate non-CCS custodian, but if we're getting into 'retroactive paychecks for prior work done without expectation of pay', we have tons of people who fit the bill, and singling any of them out over the CCS cheapens the work done by the others.'
<sgp_> I would probably personally feel more comfortable with moving this to completed tasks or something directly
<rottensox> individual, direct donations. not ccs. done.
<hyc> It's up to those people to write CCS proposals
<rottensox> and it's up to the community to let them in or not. :-)
<sgp_> maybe a solution, independent of whatever is done with the CCS, is a clearer description of how the GitHub donations are dispersed
<hyc> I don't see any precedent being set that changes the mission of the CCS
<rottensox> ok.
<hyc> Fwiw I don't believe this could have worked the "traditional" way, as a CCS done in advance.
<hyc> Mainly because nobody knew in advane whether the work would ever result in anything successful.
<needmonero90> We also dont know if it will work
<hyc> We took on the development risk instead of asking the community to bear it
<hyc> Sure, it's still an open question that can only be answered after the passage of time
<needmonero90> Maybe it does get asic'd six months down the line
<needmonero90> A payment for this and not other tweaks would be a bit premature, no?
<hyc> at any rate, if anyone in the community feels like saying thanks, why prevent using the CCS for that purpose?
<hyc> This isn't asking for payment. You couldn't afford to pay the horus spent.
<needmonero90> Because it opens the door to every two bit coder or ecosystem contributor to ask for a slot
<sgp_> I wonder if another part/page of the CCS for donations to various contributors, workgroups, etc would help meet the goals here while keeping the CCS proposals for work that follows a more typical process
<hyc> hours
<rottensox> I do not think using CCS is correct.
<needmonero90> Where is the line for retroactive work
<needmonero90> Using the CCS to ask for payment for future work or future expenses just feels..well scoped
<hyc> The line is where the community decides whether to fund any proposal or not.
<hyc> The same line it has always been.
<sgp_> needmonero90: respectfully I think the more important point is that the CCS process isn't really meant for retroactive work at all, whether than the concern of setting a precedent
<sgp_> *rather than
<needmonero90> Sure
<needmonero90> I'm using the phrase precedent
<rottensox> if it isn't meant for that, why are we still discussing it then?
<rottensox> no ccs. that's it.
<needmonero90> Nah that's the open question
<hyc> There's nowhere in the CCS that precludes it
<sgp_> is there anyone that would be opposed to a clear CCS page with donation links to workgroups, initiatives, and contributors? Would that meet everyone's concerns?
<sgp_> that's what I personally feel would be most appropriate
<sgp_> with the Monero project donation address at the top of course
<hyc> It seems pretty stupid to me. Folks in the community want a single place they can go to to contribute to the project. You're telling them no. Makes no sense.
<rottensox> if we do that, it has to include clause stating any donation to workgroups, initiatives or contributors is entirely voluntary and is not part of the ccs themselves. do i get it right? sgp_.
<sgp_> hyc: what do you think of adding a fifth button on ccs.getmonero.org for misc donations?
<rottensox> it'd be confusing if we add all those links, along with the classic ccs funding proposals...
<hyc> That might work
<hyc> rottensox: the entire CCS is voluntary so I don't see your point
<sgp_> rottensox: they would be on a separate page, not under any of the 4 existing components
<rottensox> ok.
<rottensox> sgp_: thanks.
<needmonero90> An index of donation addresses is fine
<sgp_> I can speak with rehrar to see what this could look like, since I think adding clearer donation options is good, and so is preserving a clear "work-in-progress" process. Hopefully this is a good compromise that does both
<needmonero90> No objections
<sgp_> and then it gives exposure in the same way the other CCS projects get exposure. all on 1 platform for more legitimacy
<rottensox> might be a good idea. hope you get to talk him more on this soon.
<sgp_> ok cool, let's start there and see what we can do
<hyc> +1
<sgp_> ok, on to the second one
<sgp_> us-west-cost-monero-drop-storage: https://repo.getmonero.org/monero-project/ccs-proposals/merge_requests/108
<sgp_> This includes a discussion about reimbursements. How do we feel about this proposal and using the CCS for reimbursements?
<sgp_> I personally am ok with the reimbursements. Note however that I was reimbursed for many Monero meetup travel costs in 2017
<sgp_> rehrar indicated however that this CCS may not be necessary if other funds that were already raised can cover the shortfall
<sgp_> so it's on hold anyway until we figure that out since it may not be needed
<sgp_> needmonero90: do you have any comments here? you asked to bring up this topic of reimbursements
<needmonero90> I feel like the bad guy of the CCS right now, heh
<needmonero90> I kind of take issue with reimbursements for overages on CCS stuff, because it encourages lowballing (to a degree) if you can expect people to pay for the excess
<sgp_> I also want to note that ErCiccione expressed disapproval of this proposal and the purchasing and storing of equipment for Defcon in general
<needmonero90> idk, people make CCS requests, and should hopefully build in potential overages
<needmonero90> this case is special of course, because it was unknown that the storage site would cover it
<needmonero90> would increase costs*
<sgp_> I think that's a valid point, but we need to be careful about the flip side where the community always overpays for everything in the worst case. It's a bit of a balance
<ajs[m]> not all the funds raised in the original proposal was used by the way
<sgp_> rehrar is custodying them, right?
<needmonero90> hm?
<sgp_> needmonero90: there is Defcon 2019 money leftover
<ajs[m]> most of it was allocated to the dev fund because we couldn't record video
<sgp_> I think for this proposal we are waiting on rehrar's description of funds leftover
<sgp_> but your point about discouraging lowballing is noted needmonero90
<sgp_> Any other CCS comments before we move on?
<ajs[m]> I'll make sure to high-ball next time
<rottensox> lol.
<sgp_> haha
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> No major changes have been made since the 0.15.0.1 release as far as I can tell, but there are many small back-end changes and test improvements for reliability.
<sgp_> b. Localization workgroup
<sgp_> ErCiccione isn't here today to give an update, but he recently gave one on Reddit
<sgp_> c. GUI workgroup
<sgp_> A contributor reported many small quirks, and these were quickly patched by xiphon and others
<selsta> GUI tagged v0.15.0.2 and will be out in ~24 hours
<msvb-fab> I have a one liner Monero hardware team workgroup report.
<sgp_> Thanks selsta :)
<selsta> depending on how fast fluffy is uploading the bins
<sgp_> selsta: do you know if anyone is working on the i2p integration? I haven't seen updates to the PR in a few weeks
<selsta> AFAIK no one is working on it currently.
<sgp_> ok, thanks
<rottensox> news about Kastelo? :DDDD
<sgp_> d. Monero Research Lab
<sarang> Hi
<sgp_> sarang is here to give an update :)
<sarang> Primarily have been working on transaction protocols and proving systems: CLSAG is getting a security model overhaul, and Triptych is getting finalized
<sarang> I've been working recently with Aram, a Zcoin cryptographer, since his Lelantus work has some structural similarities to Triptych
<sarang> Note that no CLSAG algorithm changes are yet proposed... only a stronger security model
<sarang> Plenty of tedious math and proofs :)
<sarang> (thanks to the anonymous FC conference reviewers for their insights)
<sgp_> thanks sarang
<sarang> no prob
<sgp_> e. Hardware workgroup
<msvb-fab> Thanks, Monero hardware team status update follows.
<msvb-fab> We may have Kastelo developer kits available for distribution or at least demonstration for 37C3.
<msvb-fab> However, I failed to get a ticket for the event so I won't be on site.
<msvb-fab> If anybody wants to help, please notify me.
<msvb-fab> Help means:
<msvb-fab> Deliver the hardware team speech that is in the RIAT frab system.
<msvb-fab> And demonstrate the devices.
<msvb-fab> That's all, thank you sgp_. Next topic.
<sgp_> That was indeed quick, thanks msvb-fab
<rottensox> you meant 36C3, no?
<sgp_> hopefully someone can get you a ticket
<msvb-fab> Ups, is it year 36? Yes.
<rottensox> i'm afraid so, yes.
<msvb-fab> I guess Defcon 27 and 36C3. That's it.
<rottensox> wonderful to know there'll be development kits available. thanks for the update.
<rottensox> indeed.
<sgp_> 5. Konferenco 2020
<msvb-fab> Me and pebx are the location scouts for Berlin, which won the Konferenco location survey.
<sgp_> msvb-fab: you have the floor again for Berlin planning progress
<rottensox> :DDD
<msvb-fab> There are midterm scouting results to see, but please note that these values are semi private (not public at all.=
<msvb-fab> https://taiga.getmonero.org/project/michael-konferenco/task/40/
<msvb-fab> It seems pebx is not here, he or she has not published their results (to me) but has said they are scouting thirty (?) locations.
<nioc> there was another survey?
<rottensox> there was a network split between sgp_ and msvb-fab running surveys for konferenco 2020.
<sgp_> nioc: no I never made another one. I need to follow up with the others to see if anything else was found
<msvb-fab> I don't know how many survey there were, but the one I did covered six cities and two questions, about six hundred hits and two hundred fifty votes.
<sgp_> msvb-fab: can you clearly specify for each venue if we can handle our own catering and A/V?
<nioc> sgp_: ok, don't think another survey would change things, just wondering if I missed something
<msvb-fab> Yes, but it has been very time consuming and a couple venues have not yet reported prices.
<msvb-fab> Don't worry as I've informed all venues that we're sensitive to freedoms and restrictions, naming specificatlly A/V technik and catering.
<sgp_> ok, keep us updated please
<rottensox> we're set for berlin is what i'm understanding?
<sgp_> rottensox: most likely unless the venues all suck
<rottensox> lol.
<rottensox> okiedokie.
<msvb-fab> rottensox In the end only Berlin will host Konferenco if the conference boss (who nobody has volunteered to be) decides it. Kind of a dictatorship like last year.
<rottensox> heh.
<sgp_> yeah, Berlin so far is the only place where work has gone into it yet, so it's kinda the default choice at this point
<msvb-fab> Any other location venue questions about Konferenco?
<rottensox> everyone was rooting for eu months ago, now they don't even participate in the meetings.
<rottensox> happens all the time.
<rottensox> msvb-fab: what approximate date do we have? just to have an idea?
<rottensox> mid 2020?
<sgp_> I'll follow up with pebx
<rehrar> test
<monerobux> test failed
<rottensox> lol.
<rottensox> sgp_: kk, let's move on.
<rottensox> we're running out of time for meeting.
<msvb-fab> Folks, it's quite time consuming to scout venues, so if anybody knows of a reason that I should stop doing this please say so and I'll put scouting on hold. There are already a lot of megabytes of information regarding seating, services, options, darkening windows, floorplans and a bunch of stuff.
<rehrar> argh. Sorry for missing the meeting. Mattermost was disconnected.
<msvb-fab> rottensox I've told all venue managers that we want a weekend in May or June.
<sgp_> cool, thanks msvb-fab. We should work with pebx to help organize this all in a comprehensive format
<rottensox> msvb-fab: thanks a lot.
<sgp_> But we shall proceed for now for time's sake
<sgp_> 6. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<sgp_> How did we market this release? What could we have done better? What else in the community can be improved?
<sarang> I would like to know ways to better engage the ecosystem when it comes to network upgrades
<sarang> e.g. Zcash is having an upcoming upgrade, and it's interesting to watch their list of supported services
<sarang> https://z.cash/upgrade/blossom/
<sarang> https://mobile.twitter.com/zooko/status/1203050788257333248
<sarang> Hopefully lessons to learn, or information to share
<hyc> In particular, how do we get exchanges to upgrade as soon as new code is available, as opposed to waiting until the new fork actually occurs?
<sgp_> hyc: that's a huge annoying problem :/
<sarang> ^
<hyc> all of those exchanges waiting till last minute looked pretty stupid
<sgp_> OsrsNeedF2P put in a ton of work compiling a list in r/xmrtrader
<sgp_> but most exchanges were lazy
<rottensox> not our fault.
<sarang> If it affects users, it's a big deal
<sgp_> we need to somehow get these services to subscribe to the announce mailing list at the minimum
<msvb-fab> If you are here ajs, please join #monero-konferenco
<hyc> or we need users to make more noise too, badger their exchanges
<hyc> not sure that's effective though, badgering tech support seldom has much positive effect
<rottensox> mailing list sounds like a good idea, but then all the exchanges are ultimately divided and god knows if the right person will get the e-mail notification at the end. sgp_
<sgp_> I can ask Sonya from Zcash to see if she is familiar with the process of contacting exchanges
<sarang> Good idea sgp_
<sarang> Hopefully it doesn't come down to "hope that the right exchanges follow you on twitter"...
<sgp_> lol
<Snipa> Exchanges tend to listen to high value holders more than anything else, unsurprisingly. Having gone through some of the processes before, it's surprisingly hard to get them to listen, even if you're running a medium-ish sized fund
<Snipa> Medium ish being several million dollars in held crypto at any point.
<sarang> I'm surprised there isn't a more formalized "established contact" system between exchanges and the projects whose code they run
<rottensox> nioc is the official network upgrading certified individual then.
<rottensox> that's the biggest whale.
<sgp_> most of the time they probably talk to companies or don't care enough about the low-caps
<Snipa> This was specifically a registered crypto fund that I was advising on their Monero handling processes and how they managed them IRT exchanges.
<sgp_> Snipa: thanks for this perspective
<sgp_> in my experience, most funds don't know much about the crypto they are trading, so their feedback is not often taken to heart
<Snipa> Smaller exchanges tend to be using whitelabel products in my experience, so they don't always have the technical expertise to handle a network upgrade safely, which are the ones that would be easiest to grab with a specified upgrade procedure and such. Larger exchanges that have done extense integration work with the client API's care more about changelogs and such from my contact perspective.
<nioc> rottensox: I'm big in your eyes :)
<nioc> also don't forget I'm in NY :(
<rottensox> so?
<rottensox> i can be in Venezuela. i still have an internet connection to pester exchanges.
<rottensox> nioc: you misspelled cute.
<rottensox> in any case, shouldn't the meeting have ended by now?
<Snipa> I ran into that as well sgp_, as I was sub-advising for some startup funds as well. The main fund I was working with was specifically investing in privacy/security chains, so they had an outsized position in XMR. I'd suspect chasing down fund managers would not be the /worst/ idea in the world, to provide leverage against the exchanges.
<sgp_> yes probably, but we should keep the conversation about how to talk with exchanges and other services in our minds
<sgp_> Snipa: thanks, let me know if we can arm them with any resources they might need to chat with the exchanges
<sgp_> but I'm going to wrap this up for now, since I need to enjoy my weekend :)
<sgp_> not that this meeting isn't enjoyable ofc :p
<sgp_> 7. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 21 December at 17:00 UTC
<sgp_> 8. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

The Funds Travel Rule and Monero

Thu, 05 Dec 2019 00:00:00 GMT

Note: This text is for informational purposes only. It does not have any legal basis and is not to be considered factual or authoritative. It is important to read and understand all relevant laws (including those not referenced here), as well as the linked documents and documents that are referenced herein because there are many concepts that this post does not touch on. It is the responsibility of each person individually to understand the rules and regulations that impact them, including their status as a regulated or non-regulated entity. The information in this post is not intended to be relied upon or used for making any decision, including financial and/or investment decisions. Do not use it as such.

Summary

FinCEN issued guidance in May 2019 to remind those subject to the Bank Secrecy Act (BSA) how FinCEN regulations apply to money services businesses (MSBs). This guidance is therefore likely applicable to certain cryptocurrency exchanges, among other parties, who are considered financial institutions. This guidance reminds regulated entities that among other things, certain activities they perform may be subject to the Funds Travel Rule. Non-regulated entities are not subject to these requirements.

FinCEN's May 9, 2019 Guidance

The guidance issued by FinCEN available here did not establish new regulatory expectations or requirements. Rather, existing guidance and regulations are consolidated and applied to MSBs dealing with convertible virtual currencies (CVC).

One of the points noted in the guidance is that to the extent that a money transmitter’s transactions constitute a transmittal of funds according to the FinCEN regulations, the money transmitter must also comply with (among other things) the Funds Travel Rule.

What is the Funds Travel Rule?

The Funds Travel Rule requires financial institutions who are sending and / or receiving funds to or from other financial institutions to capture, transmit, and store certain information associated with each transfer of funds above a certain threshold.

Referencing these documents by the SEC and FinCEN:

Only transmittals of funds equal to or greater than $3,000 (or its foreign equivalent) are subject to the rule.
A transmittor's financial institution must include and send the following in the transmittal order:
- The name of the transmittor
- The account number of the transmittor, if used
- The address of the transmittor
- The identity of the transmittor's financial institution
- The amount of the transmittal order
- The execution date of the transmittal order, and
- The identity of the recipient's financial institution
A receiving financial institution must receive and retain:
- The name of the recipient
- The address of the recipient
- The account number of the recipient, and
- Any other specific identifier of the recipient

Regulated exchanges that are currently AML / KYC compliant should have most of the information required to transmit when appropriate since they retain certain customer identification documentation as part of their AML / KYC processes. Additionally, details of specific transactions are presently displayed on most major exchanges in the relevant "user account," "transaction history," "ledger," or other appropriate heading, meaning that most of the required data is probably already being captured. Transaction IDs are searchable in the public blockchain.

How Might Regulated Entities Comply with Travel Rule Obligations?

It is up to each regulated entity to decide how to comply with the Travel Rule requirements. Some organizations may simply only permit non-regulated, non-financial institutions to interact with their products. For others, using a third-party tool to transmit information off-chain is the most efficient and reliable method that will allow entities to comply with the Travel Rule.

Relating to the transmission of the required data, FinCEN states in their May 9, 2019 guidance that "...if a given transmission protocol is unable to accommodate such information, the obligated person may provide such information in a message different from the transmittal order itself." The FATF recommendations (updated June 2019) also state similarly that "the information can be submitted either directly or indirectly. It is not necessary for this information to be attached directly to the virtual asset transfers." Therefore, on-chain sharing of information is not needed. This allows the Travel Rule information-sharing process to remain separate from any transacted asset.

There may be additional work required by regulated entities to compile their data into a transmittable form and / or to use a third-party transmission protocol to send the required information to the recipient regulated institution. These challenges are not unique to transacting in Monero and apply to the regulated institution itself, rather than any individual cryptocurrency.

One example of a company providing this third-party information transmission service is CipherTrace with its TRISA product. However, almost any direct method of communication, such as email or file transfer, could suffice.

Similarly to Zcash's memo field, the Monero tx_extra field could be used to include arbitrary encrypted data; this might include Travel Rule information specified by regulated entities. However, the use of such a field contributes to chain bloat, could affect transaction distinguishability, and is unnecessary due to the benefits of off-chain solutions. Building infrastructure surrounding this field is strongly ill-advised due to the changing nature of the Monero protocol. Services should invest in standardizing entity-to-entity secure solutions for off-chain information exchange rather than building small silos for individual assets. Furthermore, the consequences of encryption error are lower for direct lines of communication than for information stored on a public ledger.

However information is shared, services should remain aware of other relevant privacy regulations, including GDPR. Encryption alone may not be sufficient to comply with certain privacy and data protection regulations. Running afoul of these could expose services to legal liability.

Does the Funds Travel Rule impact Monero?

The Funds Travel Rule doesn’t appear to impact Monero itself. FinCEN’s May 9, 2019 guidance reminds regulated entities (likely including cryptocurrency exchanges) of their obligations to comply with BSA regulations. The Funds Travel Rule is a BSA regulation.

It would appear to be inappropriate to state that any cryptocurrency is compliant or not compliant with the Funds Travel Rule, since the Funds Travel Rule appears to apply to regulated entities, rather than the underlying assets in which the entities trade.

FinCEN’s May 9, 2019 guidance states that "A money transmitter that operates in anonymity-enhanced CVCs for its own account or for the accounts of others (regardless of the frequency) is subject to the same regulatory obligations as when operating in currency, funds, or non-anonymized CVCs." Therefore, it doesn’t appear that regulated entities would need to treat Monero differently from a regulatory compliance perspective than more traditional surveillance capable coins, like Bitcoin.

The guidance then goes on to state "In other words, a money transmitter cannot avoid its regulatory obligations because it chooses to provide money transmission services using anonymity-enhanced CVC". This appears to further reiterate that regulated entities aren't prohibited from transmitting or receiving anonymity-enhanced CVCs. A logical conclusion would be that from the regulatory compliance perspective, transmitting funds denominated in Monero would be equivalent to transmitting funds denominated in a surveillance capable coin like Bitcoin.

Conclusion

The Travel Rule is a burden to share information placed on regulated entities, not on the Monero protocol itself or non-regulated entities who use the Monero protocol. You must determine for yourself if you are a regulated entity or not. The Monero community generally recommends that regulated entities share information off-chain using a direct line of communication or a third-party tool. We do not recommend using Monero’s encrypted message field tx_extra over simpler solutions such as using a third party data transmission tool.

Monero is an asset that can be used by regulated entities without prohibiting them from meeting their regulatory requirements. In the context of this post, there are no rules imposed on regulated entities dealing in Monero that are not also imposed when dealing in traditional surveillance capable coins like Bitcoin. Additionally, leading data sharing infrastructure solutions are cryptocurrency-agnostic. Thus, it can be said that Monero as a platform does not interfere with the required Funds Travel Rule regulatory requirements.

A message from the Core Team about the General Fund

Tue, 03 Dec 2019 00:00:00 GMT

Administration of the General Fund

The Core Team as a group has existed from the very early days of Monero, and its responsibilities have evolved over the years. For a write up of the responsibilities that the team considers itself responsible for nowadays (that is, trusted by the community to take care of), see /2018/03/01/core-team-announcement.html. These responsibilities tend to diminish as the project moves forward and some structures are changing; for instance, reproducible builds are a big step forward to provide binaries to the community without having to blindly trust any of us.

A responsibility that remains fully in our hands is to administer and/or escrow financial donations to the project. In practice it means:

escrowing and arbitrating the Community Crowdfunding System (CCS), and
stewarding the General Fund (GF), spending funds as the team sees fit for the advancement of Monero.

It is important to note that none of this is a forced monopoly. Anyone who does not trust the team’s arbitration can easily raise funds the way they want, the CCS software being even open source this is technically trivial. Similarly, anyone could set up their own general donation fund and administer it as they see fit, including hosting it on a different website than getmonero.org.

The CCS has clear rules (https://ccs.getmonero.org/what-is-ccs), so the arbitration we offer is as predictable as possible and donations can be sent to various proposals with confidence that the mechanisms are clear both for donors and recipients.

The General Fund on the other hand is more loose, the principle being simply that the funds are spent for the advancement of Monero, at the discretion of the Core Team. In the early days, the GF was used liberally, with payments supporting early work of the Noether's (Sarang, Shen, and Surae) as full-time members of the Monero Research Lab. Later on, Sarang and Surae began to use the CCS directly to raise quarterly, which moved their accountability to their CCS donors.

The GF has also always been used to pay infrastructure and server costs, even if nowadays these have lowered thanks to Globee and Tari maintaining and paying for the getmonero.org infrastructure, as well as some sponsors donating assorted VPS’ for our use (sponsors can be seen on the sponsor page).

Current usage of the General Fund

For the past couple of years, the Core Team has seen beneficial to the project to pay Diego “rehrar” Salazar for assorted work. Rehrar originally started part time, then moved to working full time last year. Today this constitutes the largest recurring expenditure of the General Fund.

Obviously, we believe that the added value from rehrar is worthwhile, otherwise we would not have continued this arrangement. If you ever contributed to Monero one way or another, it is likely you have been supported in your contributions by his work, from running meetings, researching and deploying community resources, doing high-quality UI/UX work, etc.

Additionally, we believe there is specific value in employing someone for this role directly (as opposed to a typical CCS with the community). There are multiple reasons for this. First it allows to employ this person for a broad set of tasks, whether these tasks are actually known in advance or might suddenly fall in a domain a priori unknown (in which case it is hard to receive donations via the CCS beforehand). Second, the accountability to the Core Team allows for a highly efficient, quick decision making process, in a way that would not be possible by having accountability to dozens or even hundreds of CCS donators. This efficiency also translates in practice to a degree of availability in reporting, discussing and executing, that would not be possible with only volunteers or individuals paid via the CCS (who generally promise to work a certain number of hours but are free to organize their time and do not answer to anyone besides fulfilling the proposed CCS description of work). Hence, to allow for these efficiencies, it is a deliberate choice that he is not answerable to the community directly, but indirectly via the Core Team.

Increased transparency going forward

We would like to institute more transparency going forward for the General Fund. We will publish regular reports, probably quarterly. We will include donations that have been received, how much and how the funds have been allocated, and what is the state of the “reserves”. You can expect the first such report soon.

As of December 2019, the amounts (including XMR and BTC) in the General Fund account to roughly $180,000.

We hope this information will shed some light for everyone contributing to Monero on how funds are allocated, and motivate more donations to the GF. Thanks to everyone who is part of this incredible, world-changing community!

Release 0.15.0.1 of Monero GUI and CLI

Sun, 24 Nov 2019 00:00:00 GMT

Overview

This is the v0.15.0.1 release of the Monero GUI and CLI software. The GUI introduces many changes since last release, the CLI contains mostly bug fixes noticed in the 0.15 release. It's suggested to use this point release in preparation for the network upgrade of November 30.

GUI

The major changes introduced with this release are:

Better Tails support
Transaction history page improvements
Show address on Trezor device
Titlebar: wallet name and new icons
SimpleMode: automatic public nodes discovering and switching
Left panel: new design
Basic right click context menu
Various UI/UX improvments
Bug fixes and performance improvements

Note that you can find a full changelog on GitHub.

More info on this Reddit thread

Download Links

You can also compile it from source by yourself. See the instructions on GitHub

CLI

This point release introduces mainly bug fixes. You can find a full change log on GitHub.

More info on this Reddit thread

Download Links

You can also compile it from source by yourself. See the instructions on GitHub

Verify Hashes

GUI:

monero-gui-win-x64-v0.15.0.1.zip, a09cc7bf06834e49ec267e89daf1dc6ecc3b2c34ac50e8f0548f8997aef37b06
monero-gui-install-win-x64-v0.15.0.1.exe, 55b4ac0b5131337ea7a7a66a7c6d4a277354a150c303bf70148ac284f6da5b9c
monero-gui-mac-x64-v0.15.0.1.tar.bz2, c8994781510e234985e24f465761355e4ae7bd58ef686bd8b0ce4401c2314d51
monero-gui-linux-x64-v0.15.0.1.tar.bz2, 85a6885849d578691a09834c66ed55af4783ea8347b7784de9ea46e90995a57c

CLI:

monero-win-x64-v0.15.0.1.zip, a1d2a4a0a9f2cdb17808c0b7a2a872a70c9f3e6487494b29cc1627b5490f25e9
monero-win-x86-v0.15.0.1.zip, a3dc6d57c52383fcb83337799909c2c85cc8fe88b127d9408e3ea92880beb38d
monero-mac-x64-v0.15.0.1.tar.bz2, f3648a94fc9252a2e5b6e56978e756ff272403ec385f8be42338cae3f4f4e8a5
monero-linux-x64-v0.15.0.1.tar.bz2, 8d61f992a7e2dbc3d753470b4928b5bb9134ea14cf6f2973ba11d1600c0ce9ad
monero-linux-x86-v0.15.0.1.tar.bz2, f157d8130978772bfe3ec4ebaca21f561dc0deffe49904af49f4a11d96c0cda6
monero-linux-armv8-v0.15.0.1.tar.bz2, 67b890a10332cd91c69472e345b9ab624532540601a1d99f6fabb9c5c1b62455
monero-linux-armv7-v0.15.0.1.tar.bz2, 19c34bf8d79b6ae809efe30a4c02695cd2d8212709a5bff43a5aec49517c41ee
monero-android-armv8-v0.15.0.1.tar.bz2, f9cbf531049068f9c07b92a89371ff8aab6b69062077c3dfe4fa27a9956f8759
monero-android-armv7-v0.15.0.1.tar.bz2, ea5eac2eed4d10cb35af50182ad11edeeffc4200d2b2b8e47f0283ae06fc4185
monero-freebsd-x64-v0.15.0.1.tar.bz2, 810dbac09546a14fe6e2c276f41eebc5489bc43f91c0a85a080528ccd9ce12a8

Logs for the Community Meeting Held on 2019-11-23

Sat, 23 Nov 2019 00:00:00 GMT

Logs

<sgp_> Meeting time
<sgp_> 0. Introduction
<needmonero90> Hi diego
<sgp_> Welcome to the Emergency Response Process and Compromised Binaries Post-Mortem Meeting. Today, we shall discuss the information we know so far about the compromised binaries and introduce ideas to better respond to emergencies in the future.
<sgp_> It’s later than most of our meetings, so thank you for coming at this unusual time.
<sgp_> 1. Greetings
<needmonero90> Hello!
<M5M400> Servus!
<rehrar> h'lo
<binaryFate> hi
<pizzaburger> Good day!
<anhdres2> hola!
<mrpublic> top o the mornin'
<intj440> Hello
<needmonero90> Is the fluffiest pony here this evening?
<sgp_> Welcome everyone! There is a lot to cover, so let's move methodically so that we can respect those staying up late
<sgp_> https://github.com/monero-project/meta/issues/413
<sgp_> 2. Website compromised facts and review
<el00ruobuob_[m]> Hi
<ArticMine> hi
<sgp_> long set of text incoming describing the situation, including new information
<almutasim> Hello.
<sgp_> Here is a short timeline of the events that unfolded earlier this week:
<sgp_> Relevant blog post: https://getmonero.org/2019/11/19/warning-compromised-binaries.html
<sgp_> The CLI binaries were compromised for approximately 35 minutes on Monday
<sgp_> The attackers did not modify the hashes on the website
<needmonero90> Is that time frame known for certain?
<sgp_> Core team member binaryFate created a Reddit post and messaged me about it on IRC. He shared it on his personal Twitter account
<needmonero90> Did the logs get pulled?
<sgp_> needmonero90: I will cover the exact time frame near the end of this wall :)
<needmonero90> Mmk
<sgp_> Reddit link: https://www.reddit.com/r/Monero/comments/dyfozs/security\_warning\_cli\_binaries\_available\_on/
— needmonero90 waits patiently
<sgp_> I found it likely that this was true given binaryFate’s position and that it was shared on three different mediums. Thus, I immediately sent Blockfolio, CoinGecko, and Delta notifications. I created a tweet from the Monero Twitter account
<sgp_> Note that although I have partial access to the Monero Twitter account, I am not the primary owner or maintainer of it, and the tweet I created was an exception for the circumstances
<sgp_> I also contacted the other moderators of r/CryptoCurrency, who agreed to allow an announcement about the situation in r/CryptoCurrency
<sgp_> ErCiccione authored an announcement on the website about 14 hours after the incident was initially reported. An email to the Monero-announce mailing list went out around the same time.
<sgp_> Approximately 12 hours after the sending the Blockfolio notification, it had 14,673 impressions and 259 clicks. Today, it has 25,308 impressions and 326 clicks. I don't have numbers for the other portfolio platforms.
<sgp_> The Reddit thread has nearly 300 upvotes and nearly 300 comments.
<sgp_> Twitter reports that the initial tweet has 100,918 impressions and 1,455 engagements.
<sgp_> Major and minor news sites picked up on the story, including Naked Security, Crypto Briefing, The Next Web, Ars Technica, ZDNet, CoinGeek, Fossbytes, CoinTelegraph, Bleeping Computer, AMBCrypto, Bitcoinist, Coingape, Finder, and Decrypt.
<sgp_> There are a few writeups on the content of the malware:
<sgp_> Bartblaze: https://bartblaze.blogspot.com/2019/11/monero-project-compromised.html
<sgp_> serhack: https://serhack.me/articles/cli-binaries-compromised-monero-analysis/
<sgp_> They both determined that the malware was a simple coin stealer. KnifeOfPi also came to the same determination.
<sgp_> Now, on to the website information.
<sgp_> I can answer a few more questions than I could before, but I can’t answer everything yet, including how the website was compromised. I have no insider info there
<sgp_> Security professionals have been working to learn more information. The security team has promised their post-mortem when they have more details.
<sgp_> The downloads are served by two sources: the CDN and the source. The CDN binaries were not affected, which are the preferred sources. The source is fallback.
<sgp_> After the hack, the security admins temporarily turned logging on with the DR download box (which was switched to) in case someone was trying to hack it. A benefit of this is that we learned there are typically fewer than 10 wallet downloads per hour from the direct source.
<sgp_> I can also confirm that 35 minutes is the *maximum* time that the malicious binaries were served. The file integrity monitor (FIM) was killed 35 minutes before fluffypony initiated the failover to the backup DR box. If the attackers replaced the files immediately after, then the website was compromised for 35 minutes.
<sgp_> Full timeline:
<sgp_> The FIM’s last log entry was at 16:04 UTC (10:04 CST) - malicious binaries were not served before this point
<sgp_> A Github issue was created at 16:21 UTC
<sgp_> A community member privately informed site admins at 16:30 UTC
<sgp_> fluffypony switched to the failover at 16:40 UTC
<sgp_> The maximum compromised time was between 16:04 UTC and 16:40 UTC Monday November 18
<sgp_> Since they were served for only 35 minutes, it’s highly likely that fewer than 10 malicious downloads were served. Among these, some were presumably updating their nodes, not running wallets.
<sgp_> and that brings us to the end of the wall of text
<sgp_> Does anyone have questions or comments on what happened? I won’t be able to answer some of them unfortunately but I’ll do my best.
<M5M400> one question comes to mind: HOW?
<needmonero90> The security researchers are dealing with the box atm
<needmonero90> We'll probably only know after their analysis
<sgp_> M5M400: that's an important question that I don't really have the answer to
<sgp_> But I am certain that a dedicated team is digging through the boxes
<DarkDotFail> Hi Justin - What does "DR" stand for?
<M5M400> disaster recovery
<needmonero90> Disaster Recovery
<DarkDotFail> "it’s highly likely that fewer than 10 malicious downloads were served" - I assume this is based on logs? How confident are you in this count?
<sgp_> I find it remarkable that two independent community members reported on the issue within 30 minutes
<M5M400> when did fluffy upload the original files? ie, how long did it take them from upload to replacment?
<Supportoi> Sio
<sgp_> DarkDotFail: unless there was a significant anomaly (3+ sd downloads over that period), then I am very confident. So I'd say >95% confident
<Supportoi> Any news?
<HungryForAvo420> Are there any plans to periodically check sha256 hashes?
<sgp_> There are almost never more than 10 downloads/hr. And it was compromised for 35 minutes
<DarkDotFail> Who has server access, and what is the process for giving someone server access?
<Supportoi> I read about hacking this is Russian hackers
<sgp_> Supportoi: there is no evidence I know of that suggests this
<anhdres> is it my non-techie impression or we got very lucky here? I mean we only realized it because someone that downloaded the CLI checked the hashes AND they didn't change the hashes accordingly
<Supportoi> I downloaded this fkng cli
<needmonero90> Changing the hashes would have required compromising a second box
<Supportoi> I'm not infected?
<Supportoi> My money not stolen
<sgp_> Supportoi: when did you download the cli exactly?
<Supportoi> But I worry about my PC
<anhdres> needmonero90, ok
<Supportoi> 18th
<sgp_> DarkDotFail: I do not have a full list
<sgp_> Supportoi: what time and what time zone?
<DarkDotFail> and regarding the process of granting access, how is it determined who should have access?
<needmonero90> As few people as is realistically possible
<Supportoi> SHA is eq to SHA of infected files
<almutasim> It's really good that changing the hashes requires hacking a second box.
<rehrar> DarkDotFail Tari or Globee hosts the getmonero infrastructure
<xmrscott[m]> Supportoi: Verify your hashes, that will conclusively tell you if it's the nalicious binary
<rehrar> the details would have to be asked of them
<anhdres> is there a way to have a bot somewhere else doing just what the human user did by chance? I mean downlaoding the files regularly and checking the hashes to see they match, and if they don't issue an alarm?
<DarkDotFail> anhdres: I am working on precisely that :)
<sgp_> anhdres: while technically possible, this service would probably be blocked as a DoS attack
<needmonero90> That would be a tiny DOS on the server, and if done with a consistent IP, it's possible to serve uninfected binaries to the pollers
<Supportoi> Fkng Russian hackers
<anhdres> mmmm...
<sgp_> there are a stupid number of people who constantly are trying to download the 55GB blockchain.raw
<M5M400> when did fluffy upload the original files? ie, how long did it take them from original upload to replacment with compromised bins?
<needmonero90> Supportoi: please keep on topic, speculation on who did this is unwarranted at the moment.
<needmonero90> We will know more after the post mortem
<Supportoi> I reading news and founded article about some hacking russian forum
<DarkDotFail> sgp_: Is there any indication yet that the server was compromised, and how?
<sgp_> M5M400: are you referring to the time between the 0.15 safe binary uploads and them being compromised?
<M5M400> sgp_: yes
<Supportoi> Where they have article about monero hacking
<binaryFate> M5M400 the malicious binaires were compiled from sources, they are not obtained based on the original ones. So it's indepedendant from original upload time.
<Supportoi> Russian hackerssssssss omg
<sgp_> DarkDotFail: yes, I can state that the website WAS compromised, though I do not yet have details on how
<anhdres> good thing it wasn't the GUI, because those would have been less technical users and therefore less probable they checked the hashes. We need a fool-proof official tutorial to teach how to check them.
<needmonero90> Supportoi: last warning.
<DarkDotFail> sgp_: Has law enforcement been notified about this breach?
<pizzaburger> Is there a possibility that the attackers were after something else and we just haven't noticed their ulterior motives?
<PewPewPewPew> ^^
<M5M400> binaryFate: trying to gauge how premeditated this attack was... ie if they had everything ready and possibly already access to the box for a while, just waiting for new bins to be uploaded and then quickly replacing them...
<sgp_> DarkDotFail: no, and we have not yet found a strong reason to. I will make a recommendation that the security researchers do (in addition to their own assessments) if there's a clear reason to. I do not have knowledge on the state of the investigation to make a recommendation
<HungryForAvo420> What is the decommission schedule for source box? CDN was not impacted, but am wondering what the maintanance is like for Source.
<needmonero90> I would like to point out that the attack felt rushed/incomplete, from reports I'm hearing. There were many things that could have been done that weren't (infecting the GUI dls for example)
<sgp_> pizzaburger: while we can never know for sure what their motivations were, we know the security researchers only found a relatively primitive coin stealer included in the wallet software
<Supportoi> I'm worry about my privacy. I'm not programmer but I know some in programming and security. My antivirus not detected danger, I runned this file.
<DarkDotFail> How long has FIM been installed, and has it ever detected other anomalies?
<Supportoi> And I readed about this forum. This forum contains information about CLI replace
<sgp_> DarkDotFail: I do not know for how long, but FIM was disabled by the attacker
<Supportoi> Somebody know some about this?
<DarkDotFail> Has FIM ever detected other anomalies?
<needmonero90> Supportoi: this has nothing to do with the issue at hand. Please stay in topic for the meeting.
<PlasmaPower> I know you don't know how it was compromised yet, but what were the potential avenues of attack for the box other than an insider threat? The web server, maybe SSH, maybe a cloud provider?
<M5M400> needmonero90: that's my gut feeling aswell. that's why I was asking how long it took them to replace the bins after initial upload... but I don't seem to get an answer :)
<sgp_> DarkDotFail: I do not know about the test environment in which it was tested, but I know there were no other anomalies on the live version of the site
<DarkDotFail> Thank you. that's very good.
<Supportoi> I payed 50$ in xmr to body from comments and they gived me screenshot
* Supportoi was kicked by needmonero90 (Supportoi)
<sgp_> M5M400: I don't know when the original 0.15 binaries were uploaded, but that's something we can check on I suppose
<sgp_> Any other questions? Sorry to not have juicy details yet on how this happened
<binaryFate> this reddit post suggest the 9th: https://www.reddit.com/r/Monero/comments/dtt2j3/cli\_v01500\_carbon\_chamaeleon\_released/
<DarkDotFail> I want to quickly commend Justin and team for the quick response. My complaint is that the public website took over 14 hours to update after the breach, and I suggest we get a quicker "post an alert to the website" process in place. Going AFK for now, but be safe everyone.
<M5M400> binaryFate: that would speak for the less premeditated "uh, new release. let's try to hack that box and replace with our coinstealer" theory
<rehrar> honestly, the timing of this seems too good for it to not be premeditated
<xmrscott[m]> binaryFate: Also semi-verified going off of WebArchive for getmonero
<needmonero90> Processes are being put in place to expedite updates of the public site in the event of a security event. 14 hours was excessive, but we can do better.
<ZaiRoX> Strange of them not waiting for the GUI release though
<M5M400> rehrar: why wait 5 days then?
<rehrar> honestly, who updates CLI early? Exchanges. Services.
<rehrar> I think they were hoping for big fish.
<binaryFate> Agree website update has the largest room for improvement.
<M5M400> rehrar: agreed.
<anhdres> would a stupid but useful security measure to suggest to newbie users for them to wait a few hours before running a downloaded binary and see if there's any warning on an official channel?
<needmonero90> Hash checking should be sufficient
<needmonero90> And signature ofc
<sarang> With signature verification you know the file is what it is expected to be
<rehrar> M5M400 you asked why wait 5 days after the new CLI was released?
<needmonero90> I think prioritizing teaching people how to verify signatures is infinitely better than having them wait for a few hours and hope someone notices
<rehrar> because if you release ASAP, everyone is downloading and testing. They will catch it right away.
<needmonero90> That's just me tho
<sgp_> they also compromised the website at a relatively convenient time
<M5M400> rehrar: makes sense
<sgp_> time of day
<PlasmaPower> frankly, even Monero's "beginner" guide to signature verification on Windows is way too long
<anhdres> ok, and based on that "hacking" the hash to match the compromised binary would be too difficult to pull of, right?
<M5M400> rehrar: good thing the "big fish" are usually the laziest in updating, I guess...
<rehrar> PlasmaPower I just spoke about this with another individual that does website stuff.
<sgp_> anhdres: it's more realistic to check the hashes haven't changed
<rehrar> We need to separate verification user guides into three. Linux, Mac, and Windows.
<rehrar> They won't be so long or scary then.
<sgp_> rehrar: good, that's a specific action item
<rehrar> I was literally helping a person on Telegram and told him to verify hashes and he got scared by how big the page was and how much CLI commands there were
<anhdres> sgp_, needmonero90 : got it thanks
<pizzaburger> Thank you for the information and hard work. Best of luck to the Monero team, bye!
<PlasmaPower> rehrar: the Windows specific guide is still long, though not scary except the small part that requires command prompt
<xmrscott[m]> FWIW with respect to timing, domain was bought 11/14. Arguments could be made that a purchase so close to delivering the attack means it wasn't pre-meditated, but best to wait for the official report
<M5M400> xmrscott[m]: ah, I forgot about that domain info. makes perfectly sense
<justalurk3r> sgp_: I, too, have downloaded the compromised binaries. If my browser history is right, then it must have happened at 12:24 CET
<anhdres> would it be too cumbersome to develop a little monero-branded, hash-checking program for windows that required no installation so a very noob could use it practically guide-less?
<M5M400> sgp_: any info which hosting company the infected box belongs to?
<sgp_> M5M400: I don't know that
<PlasmaPower> anhdres: I thought about that too, but then what if that binary gets compromised :P
<needmonero90> Andrhes: and if they compromise that?
<needmonero90> Jinx
<anhdres> well, it needs to be in a third box
<sgp_> the malicious software would just say "I'm totally safe"
<needmonero90> 🤔
<cbster> Yeah, were it too simple I think they'd just change that program too
<anhdres> if screwing with the hash is "safe" we could do the same with the app
<sarang> The only guarantee is a full hash and signature check
<needmonero90> ^
<sarang> Only doing hash checks is potentially vulnerable
<cbster> Agreed, a lot of people leave off the signature check
<sarang> It's annoying but important
<tevador> one positive aspect of this incident is that people are more likely to verify the hashes from now on
<M5M400> sgp_: is there any intersection in the groups of people who research the breach and the group who had access to the box?
<rehrar> honestly, the entire cryptography space is long overdue for a good UX GUI for hash checking and verification
<rehrar> one that could be used for all of the programs ever
<needmonero90> Pgp is pretty good
<anhdres> rehrar: yes, please
<needmonero90> ...not
<sarang> However if you're confident that externally hosted trusted hash lists have not been modified, then a hash check is ok
<PlasmaPower> Are GitHub release assets generally deemed safer than the website downloads? I don't think they're GPG signed (though the tags themselves can be).
<sgp_> PlasmaPower: it's simpler to hack a Github account probably
<HungryForAvo420> Any consideration in using GitLab? have seen MS owned github drop some repos in some countries
<pca> Just arrived. How was the box compromised, or does anybody know that information yet?
<tevador> are we signing git tags?
<sgp_> HungryForAvo420: Monero already partially uses Gitlab, but this is mostly irrelevant for the conversation at hand
<M5M400> pca: not yet
<sgp_> For the sake of time, I'm going to warp up this section soon. Most of these questions have been answered in Reddit
<rehrar> kthanksbai
<PlasmaPower> tevador: I just checked, yes at least the latest tag was signed and most commits seem to be signed too.
<needmonero90> Thanks for hosting sgp_
<sgp_> just this section lol
<sgp_> still have a few more
<needmonero90> Oh rip
<sgp_> that was just the update and clarification portion
<xmrscott[m]> I was going to, still plenty left to discuss nm90 ;)
<sgp_> now time to do actual work
— needmonero90 nods sheepishly
<sgp_> 3. Introduction of emergency procedure
<M5M400> ah, the big red button
<sgp_> I would like to introduce a project to draft more formalized emergency procedures. This procedure will help the community understand what to do if another emergency occurs.
<anhdres2> haha everybody was "ok good one see ya" and Justin still had the cake untouched
<sgp_> https://github.com/monero-project/meta/issues/412
<sgp_> We can pull from existing resources, including the Monero Vulnerability Response Process and the Monero Malware Response Workgroup.
<sgp_> I know that the Monero community has significant concerns about centralization, and these are justified and should be considered carefully. Nevertheless, there are many was that this process can help organize a proper response without having many centralization advantages. And to be clear, it’s not like we can force people to follow a set procedure anyway. All participants’ involvement is entirely voluntary
<sgp_> and subject to their own best judgments.
<sgp_> I'm currently breaking the procedure into main topic areas: a) safe verification of the emergency, b) classification of the severity, c) communication, d) incident response, e) regular tests/audits, and f) responsible roles, including alternates in case of inactivity.
<sgp_> Let’s open discussion on the 6 points that I have above, one at a time. We can talk about what processes (even if informal) we already have, and what you think is a good idea to help with these. If you feel there are any missed topics (likely), please reserve them for later.
<sgp_> a. safe verification of the emergency
<sgp_> in this case, we didn't have signed messages saying "this was compromised." We simply relied on several trusted accounts. What are our thoughts on this?
<sgp_> also related: if people want to contact someone about an emergency, is there a clear disclosure process?
<needmonero90> The people who would verify signatures of warnings would verify signatures of their binaries
<PlasmaPower> you mean from the perspective of the user verifying the emergency, not the Monero team verifying the emergency?
<needmonero90> Trust-y auth is fine here.
<M5M400> I'm less worried about "fake news" as about response time, so I guess reputable community members breaking the news is fine
<anhdres2> agree
<cbster> I agree, even were there a false alarm I can't foresee harm from it
<sgp_> needmonero90: is there a certain threshold where you would personally say "hold on a minute, I need some extra verification"?
<sgp_> false alerts are unprofessional and also harm the project potentially
<ArticMine> Provided one relies on decentralization for alarm security
<needmonero90> If the person was in my web of trust, no. If they were not, I would manually verify sigs
<xmrscott[m]> Wouldn't hurt to have public keys of core members on getmonero
<needmonero90> Personal webs of trust are fine here, theyre probably just as effective (and faster) than signatures
<sgp_> they're definitely faster
<needmonero90> And that's what should be prioritized imo
<cff97476> hello to everyone
<needmonero90> If there's questions, the warning can say it's a question mark
<sgp_> I received binaryFate's RC PM and was sending out notifications 2 minutes later
<cff97476> any news?
<needmonero90> I had a post stickied on the sub a minute after I got your ping
<sgp_> cff97476: scroll up and find section 2
<sgp_> ok, so we are all ok with relatively basic identity checks here
<M5M400> +1
<sgp_> no need to require something that would delay the process
<cbster> +
<sgp_> ok, so the second question
<needmonero90> False positives are better than delayed warnings
<ArticMine> yes there is enough redundancy
<sgp_> do we have a clear disclosure process? who should people contact?
<sgp_> how does the discoverer know how to initiate the process of raising the alarm?
<binaryFate> I don't think we can assume much from people finding out something is wrong. It's not like programmers finding bugs who are technical and educated about response.
<sgp_> surely long-time Monero members would probably contact people by DM and have personal relationships
<cbster> My first thought would be to turn to Reddit, but not everyone knows the site
<sgp_> but the first person to raise the alarm in this case did so through a Github issue
<anhdres2> I would have used Reddit but I'm not technical
<needmonero90> I suspect regardless of where it was posted (irc, github, gitlab, reddit), it would have percolate quickly
<needmonero90> We have lots of lurkers
<needmonero90> Percolated*
<cbster> There could be a section added to the site clarifying what to do in an emergency
<binaryFate> I think everyone's first thought will be different, and they are not going to dig for information to know how to disclose. Most people would think they are doing something wrong rather than recognize there is an actual issue
<cbster> Perhaps detailing the subreddit, the GitHub and a few handles of core members
<sgp_> something in the github readme may be appropriate imo
<cbster> Although that could also lead to false alarms, not everyone understands emergencies
<sgp_> I'm sure many users will report false alarms
<PlasmaPower> I think that might send too much "spam" (users who think they have an emergency but don't) their way
<PlasmaPower> yeah
<ArticMine> across multiple platforms for redundancy
<almutasim> False alarms have a price, too.
<M5M400> binaryFate: agreed.
<binaryFate> I find it more important to have an "internal" response process so that however this is disclosed, it then quickly gets put on the right rails by community members
<M5M400> +1
<ArticMine> +1
<OWLHACKATHON> hello world
<PewPewPewPew> is it safe to assume if someone found a problem like this again they would be technical enough to know about git and irc
<sgp_> should we just point people who are new to #monero or something?
<M5M400> PewPewPewPew: no
<needmonero90> Don't we already?
<cbster> I think it's wise to assume
<cbster> Unwise*
<needmonero90> Getting people to use IRC is like pulling teeth
<sgp_> needmonero90: just something that clearly says to go to #monero in the case of an emergency
<needmonero90> Ah I see
<needmonero90> That could work
<sgp_> eg: what if it's an exchange or mining pool who never talks to anyone
* ChanServ set +o needmonero90
<needmonero90> Oops
<OWLHACKATHON> go to #churchofmonero ;)
* needmonero90 set -v OWLHACKATHON
<binaryFate> Harmless but still a lot of people never used IRC whatsoever
<cbster> It's always an option, we could offer multiple channels of reporting
<cbster> I think IRC is a good start
<needmonero90> binaryFate: linking to kiwiirc would work
<sgp_> agreed, this is just something I think people should think about since not all the people who will notice major anomalies are always active
<needmonero90> Webirc portal
<needmonero90> No downloads, no logins
<_XeN_> love IRC =)
<binaryFate> It's fine to give them suggestions, but we should not assume they will follow nicely
<sgp_> binaryFate: of course not, we just want to make it easier for people to know what they're supposed to do
<sgp_> Anything else on a)?
<PlasmaPower> There's a good amount of posts on r/Monero about people who lost funds because of something that was their fault like a fake web wallet, so I don't think telling people to DM the Monero team for emergencies is a good idea. A public location like IRC is probably the best idea.
<cbster> Good point
<sgp_> b. classification of the severity
<sgp_> should we use low - medium - high, and how? who determines?
<fluffyunicorn> ALL YOUR BASE ARE BELONG TO OWL
<fluffyunicorn> >)>
<fluffyunicorn> WEEEEEEE
<needmonero90> Er
<needmonero90> Can you not? This is a meeting
<fluffyunicorn> IM HERE TO HACK STUFF
<xmrscott[m]> (Sorry didn't look up in advance, re: A it may be good to look at Tails/Qubes escaltion process)
* needmonero90 set channel modes +b fluffyunicorn!*@*
* fluffyunicorn was kicked by needmonero90 (fluffyunicorn)
<needmonero90> I'll remove after the meeting.
<sgp_> xmrscott[m]: yes, it's important to look at what other people are doing too
<sgp_> these classifications are common in projects and in the industry
<cbster> I think low, high and critical give more emphasis
<sgp_> we use it for HackerOne
<sgp_> is there anyone who thinks this classification is unnecessary?
<binaryFate> what is the purpose? Public disclosure later? Internal while we work on issue?
<sgp_> binaryFate: depends on how it's used. could be either or both
<sgp_> how do you envision it being used?
<anhdres2> do the classifications change how / which channels are used ? or are they only informative?
<cbster> I think they'd stay standard across platforms
<binaryFate> I don't find it very useful for either, simply because these incidents are so rare
* needmonero90 set channel modes +b *!18cdb83a@gateway/web/cgi-irc/kiwiirc.com/ip.24.205.184.58
<sgp_> anhdres2: they could
<anhdres2> for example only critical are pushed to all channels and low ones only stick in reddit
<cbster> Mind you, as Monero grows, they may not stay so rare
* satoshijnakamoto was kicked by needmonero90 (satoshijnakamoto)
<sgp_> indeed, these should happen rarely / never
<xmrscott[m]> If they are used for escalation though the user may not know what the proper flag is, etc
<PlasmaPower> Does anyone have an example of a low severity emergency? I'm thinking that things that send out a notification, like delta direct, shouldn't be used for those.
<anhdres2> exactly
<PlasmaPower> but I'm not quite sure what a low severity emergency would be, assuming that we aren't including 3rd party services
<anhdres2> yellow warnings are usability or network related
<anhdres2> red warnings are those when funds might be in danger and therefore are not reversible
<anhdres2> for example
<sgp_> maybe something low would be like after RingCT was first added, where blocks were super full
<sgp_> no attack necessarily, but degraded network experience
<anhdres2> something like that yes
<binaryFate> wasn't really about an emergency response
<sgp_> unless there are other topics on this, we can move on from b)
<ArticMine> It was a good cover for an emergency response
<sgp_> c. communication (internal and public)
<sgp_> this is communication standards and processes
<sgp_> eg: do we all need to be available on a specific platform (mattermost users can't DM IRC users)
<sgp_> also, using services like Twitter, Reddit, Blockfolio
<needmonero90> I'm generally available. My ringer is generally on even when I'm asleep, so I can resoond when stuff happens
— needmonero90 should consider getting paid for this availability
<sgp_> we took too long this time to get the website notification up and the monero-announce mailing list email out
<M5M400> yes, the website should be a priority
<asymptotically> !tip needmonero90 0.001
<tippero> asymptotically has tipped needmonero90 1 millinero (0.001 Monero)
<binaryFate> internal communication between community members to deal with issue was very efficient I found
<sgp_> are there other platforms we forgot about this time? ones we felt were mostly a hassle and not very beneficial?
<xmrscott[m]> Where was the roadblock though in getting the site annoucement up
<M5M400> it's traditionally generally slacking, but in this case updates need to be of high priority
<needmonero90> Your generosity will not be forgotten
<xmrscott[m]> Was it in getting approval after erc drafted it?
<xmrscott[m]> etc
<binaryFate> we'd need a website specific timeline of events
<xmrscott[m]> Exactly
<sgp_> can we build in notification systems with Cake Wallet, Monerujo, etc?
<xmrscott[m]> (Which may be best done after the meeting)
<needmonero90> I think we just blanked on updating the site
<needmonero90> It was an oversight
<needmonero90> Once we were clued in it was updated fairly quickly
<sgp_> indeed, which is why the process is important. it gives us a checklist to help us remember
<asymptotically> sgp_: bitcoin-qt used to have a built in notification system, but it kind of sucked and got removed
<M5M400> sgp_: like a emergency broadcast system that pushes out to multiple outlets with minimal effort?
<anhdres2> sgp_ I don't see how unless it adds a centralized element.
<cbster> I think built-in notification systems would be smart, but their use would be limited as those affected are probably not using them (they downloaded the core wallet)
<xmrscott[m]> Built in notifications introduce a point of attack
<M5M400> yeah. super amplified FUD
<cbster> If the binaries are comprised for that, I'd be unsure of its reliability to relay notifications
<PlasmaPower> Bitcoin's now retired system: https://en.bitcoin.it/wiki/Alert\_system
<sgp_> PlasmaPower: thanks for the reference
<xmrscott[m]> Hey, wallet is compromised, download at this new (malicious) website
<PlasmaPower> cbster: yeah, though for e.g. an active linking attack it could be helpful
<cbster> I think you're right, could prove more troublesome than what it solves
<sgp_> ok, no additional platforms coming up. keep thinking about better ways to reach people
<sgp_> *coming to mind
<sgp_> d. incident response
<M5M400> I'd like to throw the mailinglist in the ring. who's got access to post there besides the big fluff?
<sgp_> M5M400: good q> I don't know
<binaryFate> everyone can post, but emails are approved on a case basis (pigeon and maybe fluffy too)
<M5M400> maybe take a note for later. I think it is a good medium, but worthless when notifications get sent out a day or two late
<binaryFate> in this case there was a misunderstanding between fluffy and myself. He thought I would send email, I thought he would
<binaryFate> (I did not have access to my PGP key in time)
<M5M400> fair enough
<sgp_> an example of the communication process helping in that case could be specifically assigning tasks to people
<PlasmaPower> is there any generally applicable "incident response" besides communication?
<sgp_> PlasmaPower: nice segway, thanks
<sgp_> an example of an incident response process, though extreme, could be something like getting the opinion and help of an independent firm
<M5M400> sgp_: that's not extreme. it's common practice to have security incidents assessed by independent parties to minimize the risk of compromized entities being part of the investigation
<sgp_> right, so how do we do that without writing a $10m check to Deloitte?
<M5M400> hence my question earlier if the people disecting the box also had access at the time of breach
<asymptotically> write me a $9m check instead
<needmonero90> I'll do it for $8m
<M5M400> sgp_: that's the $8m question
<PlasmaPower> I definitely agree that's a good step when a server is compromised. Would it also be applicable to e.g. an RCE in the protocol? I'm not sure how useful an investigation would be there, besides a git blame.
<needmonero90> And by do it I mean delegate
<binaryFate> I don't see that as possible or useful in an emergency situation. Maybe for investigations later. No firm will be hired (with what funds?), get to the case and help us in a couple hours
<PlasmaPower> true
<sgp_> binaryFate: right, which is why I'm looking for realistic procedures
<binaryFate> Since we are not a company and we do not have people around the clock 24/7, I think we should realistically focus on procedures indeed. Not even assigned them strictly so we do not have bottleneck if someone is afk
<M5M400> sgp_: community internal segregation of duties would be a start
<sgp_> M5M400: can you elaborate a bit more?
<M5M400> seperate publishing teams and forensic teams
<binaryFate> Maping the current capabilities (mostly website update) would be good too. What processes are required for each steps and who has the permissions currently to do them?
<sgp_> binaryFate: good one
<sgp_> basic access control stuff
<PlasmaPower> though probably keep that documentation internal
<M5M400> not sure how it's organized right now, so can't elaborate in detail. but from previous conversations it seems that it's not even totally clear who even had access to the comped box. (probably multiple people)
<PlasmaPower> you don't want to provide attackers with a guide of who to attack
<M5M400> PlasmaPower: internal is a pretty fuzzy thing... where do you draw the line in the circle of trust an opensource project?
<M5M400> anyone in here could be a potential attacker
<sgp_> M5M400: I agree in this case it's pretty industry-standard to have some discussions like this kept in the dl
<PlasmaPower> M5M400: it's going to be somewhat arbitrary of course, and IDK how the Monero team is currently organized, but whoever has access to the GitHub is a good place to start.
<sgp_> any other incident response comments? we will need to revisit this much more later
<sgp_> e. regular tests/audits
<sgp_> ideally, we will assess the existing processes and suggest improvements. then we can test them to see how effective these processes are
<sgp_> that's why schools have fire drills
<binaryFate> I want to highlight that people that trust each other getting on an IRC channel to discuss the situation at hand remains by far the most efficient decision process. I find it more important to remove potential bottlenecks in terms of who can do what, than to try to guide too much said decision process.
<binaryFate> Have to go now, thanks everyone, thanks sgp_ for meeting
<sgp_> binaryFate: thanks for coming
<M5M400> +1 on the removing bottlenecks thing
<M5M400> cu
<sgp_> ideally this would be its own workgroup, but I also don't know how realistic this is
<sgp_> ok, people are pretty quiet on this one. we can keep going
<sgp_> f. responsible roles, including alternates
<sgp_> it's an open-source project without people getting paid for things, so people will be asleep, on vacation, etc
<M5M400> regarding fire drills... we could regularly publish emergency broadcast test posts on the outlets and have people go to a website, click on a button or something to assess message reception depth
<sgp_> it's important imo to have a list of primary and secondary contacts
<M5M400> sorry, I'm slow. it's late.
<needmonero90> One solution is to create a hired role for this.
— needmonero90 puts his name into the hat
<sgp_> needmonero90: I'll give you $1
<needmonero90> 🤔
<needmonero90> I can do a writeup of role requirements later
<sgp_> that would be very beneficial
<sgp_> eg: Justin is the primary for Blockfolio, secondary for Twitter, etc
<sgp_> any other ideas? we're getting close to finishing this long meeting
<M5M400> would those roles be published somewhere?
<sgp_> M5M400: I recommend they're only given to trusted people
<sgp_> give people only what they need to see
<sgp_> g. missed topics and frameworks
<sgp_> If you have any topics you feel were not covered or some other better framework to consider going forward, please mention these now for discussion.
<M5M400> <void>
<ArticMine> I would raise the question of post incident hardening
<M5M400> good one
<asymptotically> is there a post mortem of how the bad wallet binary actually ended up on the site? or is that not known yet
<M5M400> but probably needs the forensics to complete first
<asymptotically> ok nvm that answered my question :p
<M5M400> though it begs the question what makes the DR host more secure than the comped box at this point in time
<needmonero90> Nothing left on my end
<ArticMine> Yes that is the case, but for example hardening the the binary verification process
<ArticMine> Such as rehrar suggested but going further
<ArticMine> binary verification for android
<ArticMine> Free BSD etc
<M5M400> still awake - but I can't contribute to this
<sgp_> ArticMine: I don't have anything to add here, but I'll note the process
<sgp_> Any final thoughts?
<sgp_> 4. Action items
<sgp_> I will compile the recommendations in 3 into a document and share the initial draft version
<sgp_> Once shared, please comment on the draft
<sgp_> Please think about specific roles you would feel comfortable filling, even in a backup role
<sgp_> rehrar named an action item 1000 years ago when the meeting started but I forget what it was
<sgp_> then there's the action item of identifying who has access to what parts of the server (or making sure the core team has that info already)
<sgp_> Anything else?
<ArticMine> It was about improving the guides for binary verification
<ArticMine> Making them easier to understand for users
<rehrar> Goodness! This is still going?
<sgp_> ok, add that :)
<sgp_> very nearly done rehrar, we were very productive
<xmrscott[m]> Write up website notification timeline to figure out what the major contributors were ro thevdelay
<asymptotically> maybe openbsd signify would be easier than a pgp signed shasums file?
<sgp_> xmrscott[m]: good, have a timeline so we can see what took the longest
<sgp_> last chance to say something
<sgp_> 5. Conclusion
<sgp_> Thank you for participating in this extremely important discussion for Monero
<almutasim> Thank you.
<M5M400> thx
<sgp_> I was extremely pleased at the dedication for this emergency response, and with some organization, I think we can set a gold standard for other projects to follow
<sgp_> See you all later :)
<needmonero90> Great :)
* needmonero90 set channel modes -b *!18cdb83a@gateway/web/cgi-irc/kiwiirc.com/ip.24.205.184.58
* needmonero90 set channel modes -b *!18cdb83a@gateway/web/cgi-irc/kiwiirc.com/ip.24.205.184.58
* needmonero90 set channel modes -b fluffyunicorn!*@*

Warning: The binaries of the CLI wallet were compromised for a short time

Tue, 19 Nov 2019 00:00:00 GMT

Yesterday a GitHub issue about mismatching hashes coming from this website was opened. A quick investigation found that the binaries of the CLI wallet had been compromised and a malicious version was being served. The problem was immediately fixed, which means the compromised files were online for a very short amount of time. The binaries are now served from another, safe, source. See the reddit post by core team member binaryfate.

It's strongly recommended to anyone who downloaded the CLI wallet from this website between Monday 18th 2:30 AM UTC and 4:30 PM UTC, to check the hashes of their binaries. If they don't match the official ones, delete the files and download them again. Do not run the compromised binaries for any reason.

We have two guides available to help users check the authenticity of their binaries: Verify binaries on Windows (beginner) and Verify binaries on Linux, Mac, or Windows command line (advanced). Signed hashes can be found here: https://getmonero.org/downloads/hashes.txt.

The situation is being investigated and updates will be provided soon.

The Monero community

Logs for the MRL Meeting Held on 2019-11-18

Mon, 18 Nov 2019 00:00:00 GMT

Logs

<sarang> First, GREETINGS
<sarang> Hello
<hyc> heylo
<mikerah> hello
<sarang> For today's ROUNDTABLE, I have a few things of interest to share
<sarang> Updates to the RingCT 3.0 analysis and code reflect its two provably-sound versions: https://github.com/SarangNoether/skunkworks/blob/sublinear/rct3.md
<sarang> One version is the authors' padded-input version that implies some restrictions on the signer count
<sarang> The other version is a backport I did of the exploit fix from their newer version to the original one, with corresponding changes to security proofs
<sarang> Triptych analysis now reflects an optimized multi-signer version: https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
<sarang> as does its code and the draft writeup
<sarang> I have shared the writeup with a few additional researchers as well, in the hope of getting extra eyes on the soundness proof
<sarang> The CLSAG paper was unfortunately rejected for the Financial Cryptography 2020 conference (which only had a 22% acceptance rate, according to the committee)
<sarang> Here are the reviewer comments: https://gist.github.com/SarangNoether/e39db743c3260448c1d67c3622b43f4b
<sarang> Reviewer A, who recommended rejection, made some detailed points about the security model: particularly how ambiguity and linkability are treated relative to some other papers
<sarang> Once suraeNoether returns, I want to discuss the particulars of this
<sarang> I'm not convinced that the more complete linkability treatment (which ties in ambiguity as well) is needed, given the use case
<sarang> However, the recommendation for a more robust treatment of signer ambiguity is fair
<sarang> The notes about the k-OMDL assumption being less common are also fair, but that's the best hardness assumption that was found for the proofs in question
<sarang> Related to CLSAG: Derek at OSTIF tells me that JP Aumasson, who quoted $7200 to review the paper, is available presently to do so, and it's not clear at the moment when he would be unavailable again
<sarang> I didn't sense a lot of broad support for this earlier
<sarang> Given that the FC2020 review comments just came back, the paper should be updated to reflect the notes before being sent off to anyone for additional review
<sarang> So the timeline on this seems unclear right now
<sarang> Does anyone else wish to share interesting news or research?
<sarang> Righto
<sarang> My ACTION items are to address CLSAG reviewer comments to update the preprint, finalize single-signer Triptych analysis and the associated preprint, continue working with others on whether multi-signer soundness is provable using known assumptions, and examine the current state of suraeNoether's graph-matching work
<sarang> What a quiet meeting =p
<MalMen> normaly this meetings are you talking with suraeNoether :P (at least the lasts I watch)
<MalMen> I am reading the links you posted, thank you for the heads up
<sarang> selsta also posted this link elsewhere, which I found very interesting: https://medium.com/dragonfly-research/breaking-mimblewimble-privacy-model-84bcd67bfe52
<sarang> Looking at a practical attack on Grin using network observation
<MalMen> I did start to understud better how MW work with that research
<MalMen> there is not much they can do about this kinda of attack unless users kinda of "coinjoin" the transactions with know peers before releasing them to the all network
<MalMen> for what I did understund about it
<sarang> It definitely highlights the importance of the network and propagation layer in transactions
<kico> seems like using 8 peers only by default is kinda dangerous
<sarang> vtnerd has been looking into the tricky interactions involved with integrating Dandelion++, I2P, Tor, and the like
<kico> I mean for dandelion to work "properly"
<MalMen> It should be possible to get some farly good level of privacy with MW, but the way the transactions are propagated would need to became more complex in order to ofuscate the way they are made
<sarang> How so? Dandelion++ provides restrictions on stem neighbor selection for a given time epoch
<MalMen> kinda of what Bitcoin think they can do on layer2 to obuscate the linkability on layer1
<kico> I guess if one connects to more peers it increases the chance that it aggregates transactions before they're peered to the network for what I understood from that paper
<sarang> A good lesson on how it's tricky to assume things about transactions before they reach the chain, I suppose
<sarang> Well, anything else of interest to discuss before closing the meeting?
<sarang> If anyone has thoughts or comments relating to the CLSAG reviewer notes, I'd be glad to hear them
<MalMen> just one quick question from someone that dont know much abouth CLSAG
<sarang> sure
<MalMen> CLSAG will not make possible second layer networkds (missing the word here) ?
<sarang> No, it doesn't introduce any new functionality toward that
<sarang> Its only purpose is to make signatures smaller and a bit faster
<sarang> Off-chain solutions are limited by a lack of scripting and ambiguity around useful things like non-interactive refunds, etc.
<MalMen> there is something that can possibility second layer in the future for monero yet or we still far from it ?
<sarang> Introducing such things is tricky (DLSAG is one attempt, but suffers from a linking problem)
<MalMen> ok, thank you for the heads up
<sarang> If you are willing to work through the technical language and definitions, the DLSAG paper has some very clever constructions: https://eprint.iacr.org/2019/595
<sarang> (disclaimer: I am a co-author on the paper, but did not come up with the original idea)
<MalMen> Ok, I will take a look
<sarang> It highlights how tricky it can be to enable swaps, payment channels, and the like, given the protocol and indistinguishability restrictions
<sarang> Oh, I should also add that the DLSAG paper _was_ accepted to the FC2020 conferences
<MalMen> oh, that is good
<MalMen> I believe that it will be almost impossible to make any "Non-Interactive Refund Transactions" (just took it from the paper) seemless as the other transactions
<sarang> DLSAG comes very close, but the linking problem is troublesome
<MalMen> peraphs we would come to a place where we need to choose if we want to acept anything like DLSAG knowing its less private but allow us to have hotswaps and some kind of lightning network working
<MalMen> or just keep with onechain transactions
<sarang> I would not expect broad support for such a tradeoff, but who knows
<sarang> And perhaps a new idea that _does_ solve the problem will arise at some point
<MalMen> we hope so
<sarang> Anyway, are there other topics of interest to bring up before closing the meeting?
<MalMen> well, thats all from me, thanks for your time sarang *
<sarang> no problem
<sarang> OK, the meeting is over! Thanks to everyone for attending

Logs for the MRL Meeting Held on 2019-11-12

Tue, 12 Nov 2019 00:00:00 GMT

Logs

<sarang> Hello all
<sarang> Meeting begins presently
<sgp_> hello
<sarang> First, GREETINGS
<sgp_> darn, beat you to it :)
<sarang> Next up, ROUNDTABLE
<suraeNoether> howdy :D
<suraeNoether> sarang how about you go first
<sarang> I backported the RCT3 exploit fix from the multi-input aggregated proving system to the single-input prover, updated code to reflect this, and checked the relevant security proofs for this construction
<sarang> Also went through some math on ways to support multisignatures securely on the sublinear protocols under consideration, with no good answers
<sarang> As of now, the constructions for RCT3, Omniring, and Triptych all require an output secret key inversion, which is incompatible with the linear-combination method used for doing multisignatures
<sarang> This only comes up for RCT3 and Triptych in the key image generation step, but it's still unfortunate
<suraeNoether> i was reading about some signature schemes that don't use hash functions and do use key inversion the other day... when i review your stuff on triptych soundness later today, i'll see if there is anythingt obvious that jumps out at me
<sarang> Thanks
<suraeNoether> i would assume it's not obvious because you and randomrun are both v diligent
<sarang> A few things are still in progress too
<sarang> Regardless of multisignature support, I'm working up a preprint on Triptych for IACR eprint
<sarang> It'll either be the provably-secure single-signer version, or the multi-signer version if the soundness argument works out
<sarang> It'll include the same PRF-based key image construction as found in RCT3 and Omniring, since that's much more efficient than one based on hashing public keys
<sarang> Now passing the baton to suraeNoether
<suraeNoether> cool, so for our traceability analysis, i'm collecting data now. i presented some preliminary results from a *single* simulation yesterday that were rather promising, but can't be generalized yet
<sarang> Is the code for those results currently pushed to your repo?
<suraeNoether> indeed, all you do is run playerchallenger.py with python3 and simulation results will be spit out
<sarang> Can you provide the branch and commit for that version, to be sure we're running the same code?
<suraeNoether> of course, the results will vary from simulation to simulation so the precise numbers i provided yesterday will change from simulation to simulation
<sarang> right
<suraeNoether> https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching is the present up to date everything
<sarang> Got it, thanks
<suraeNoether> the code isn't complete in a lot of ways (there are always ways to make the weighting scheme selected by Eve to be better and to take into account more data), but it's complete enough to start doing some data analysis to get some hard numbers on churn
<sgp_> How can I configure it to test with different churn parameters?
<suraeNoether> i am currently modifying the code to specifically investigate churn, which requires some changes to the very front end of my simulations; i don't expect it to be done today
<suraeNoether> ^ heh
<sgp_> ok, so stay tuned
<sarang> I'm seeing commit d5076 as most recent
<suraeNoether> indeedindeed, d5076 is most common
<sarang> roger, thanks
<suraeNoether> i think MRL-churn-numbers will have some more satisfying answers later this week
<suraeNoether> other than that: catching up on the RCT, omni, and triptych work that sarang has been doing
<suraeNoether> that's all i have. OH my work report and stuff like that :P
<scoobybejesus> fingers crossed my question makes sense
< could the logistics be made to work such that signing a tx still happens via linear-combination but key image is derivable independently by multisig members?
<sarang> We'd need a secure MPC for the function J(x) = (1/x)*U
<sarang> If there is such a thing, it's all ok
<sarang> (here U is a globally fixed curve group generator)
<sarang> I'm trying to find the paper where that particular PRF was first introduced
<sarang> Cited from Omniring (reference 20): https://www.iacr.org/cryptodb/archive/2005/PKC/3320/3320.pdf
<sarang> Anything else to share or discuss from anybody?
<sarang> Besides me both liking and disliking that particular pseudorandom function =p
<suraeNoether> Just compute the logarithm then add ;)
<sarang> But for real, an MPC for that function based on linear combinations would solve the multisig problem AFAICT
<sarang> It may not be possible while retaining its nice PRF properties
<sarang> (perhaps there's a formal argument that such an MPC couldn't exist)
<suraeNoether> Slightly more seriously: why not compute the inverse of the product of the private keys and instead of a partial sum on the basepoint being passed around, a partial product on the basepoint is passed around...
<suraeNoether> If I have x and you have y, let the combined key be 1/(xy) U
<sarang> If you take away the affine nature of the composite key, I don't see a way to make that work cleanly with the rest of the proof
<sarang> nor do I immediately see what partial key image data would be passed around to construct the full image
<suraeNoether> I send you (1/x)U. You multiply by 1/y...
<suraeNoether> So it's not just an mpc you need but specifically a linear function of the input keys...
<sarang> Perhaps. I was thinking in the context of linear key combinations initially (since the rest of the proofs play nicely with that)
<sarang> The current multisig works nicely because everything plays nicely with linear combinations
<sarang> But point taken that if it were possible to relax that restriction, it could be quite compelling
<sarang> The only point in Triptych and RCT3 that requires the use of a full private key (outside of key image construction) is at the end of the proofs, to construct a particular masked scalar
<suraeNoether> Hmm
<suraeNoether> Ok well I am going to continue reading on triptych and I will try to make a push later today to mess with churn number in my simulations for sgp_
<sarang> Righto
<sarang> Let me know if you have any additional thoughts on multisig/MPC constructions too
<sarang> Oh, and here's a neat paper that came out recently for doing composable zk proofs in a Python library: https://arxiv.org/abs/1911.02459
<sgp_> thanks suraeNoether. I'm interested in testing your model out
<sarang> So perhaps on to ACTION ITEMS now?
<sarang> Mine are to wrap up the Triptych formalization to a preprint as much as possible, while considering options for secure MPC
<sarang> and then I want to do a deeper review of suraeNoether's recent work on his simulation code
<sarang> (and clear a backlog of lit review)
<suraeNoether> My big backlog for matching at this point is commenting it and documenting how it works for anyone who wants to pick it up
<suraeNoether> But other than that, I am reading today and doing my work reoorts

Monero 0.15.0.0 "Carbon Chamaeleon" released

Tue, 12 Nov 2019 00:00:00 GMT

Overview

This is the v0.15.0 release of the Monero software. This major release, announced in an earlier post, is due to the November 30th network upgrade. Users, merchants and exchanges should update to the latest Monero software before that date. The binaries for the GUI wallet are forthcoming, we will make another announcement as soon as they are released.

Some of the major changes introduced with this release are:

New PoW (RandomX) based on random instructions, adapted to CPUs
Android builds
Automatic public nodes discovery and bootstrap daemon switching
Improved network protections for connections between wallets and nodes
Pay for service system (either for nodes to offer paid RPC, or third parties to offer services paid for via monero mining)
Optional Tor/I2P transaction relay for privacy (block relay being done on clearnet)
New gen_ssl_cert tool to generate SSL certificates suitable for Monero usage
IPv6 support
Removed Long Payment IDs (see the deprecation announcement)

The complete list of features and changes is on GitHub: github.com/monero-project/monero/releases/tag/v0.15.0.0.

Download Links (CLI only)

You can also compile it from source by yourself. See the instructions on GitHub

Important note: This release contains a bug which makes problematic (very slow) to sync the blockchain from scratch. A fix was already introduced and will be available with a subsequent point release, which will be out very soon.

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.15.0.0.zip, 6b72b3836d179eb517154bbcb8e2119b168ae9d1054866a438aaeab9521f795f
monero-win-x86-v0.15.0.0.zip, b4856d0d3389497bf103d5a4dc4e73c6a39e5be20736b3e0286e76f100c508b6
monero-mac-x64-v0.15.0.0.tar.bz2, bca6b776e7e906fcda4c829aa8666eb9d92014450b87a6723a7c6eda6d6e7de1
monero-linux-x64-v0.15.0.0.tar.bz2, 53d9da55137f83b1e7571aef090b0784d9f04a980115b5c391455374729393f3
monero-linux-x86-v0.15.0.0.tar.bz2, 2197d04f4ffad4e1344b2648273f0be152de637bafc5d940cdf215cbc50e1f79
monero-linux-armv7-v0.15.0.0.tar.bz2, 326f783ffde78694b2820c95aa310ead00bb5876937ed4edf9c1abd6b6aadc02
monero-linux-armv8-v0.15.0.0.tar.bz2, f92f0acbc49076ad57337b5928981cd72c01aabe6a8eb69a1782f7fa1388fb77
monero-android-armv7-v0.15.0.0.tar.bz2, 90f7717c47031f27512e95c111e74313544049c44c765b59420ac1c13721cd09
monero-android-armv8-v0.15.0.0.tar.bz2, 01c18528f93f1c347188a0645ab4150016c6471aa391b2499b618f9e3d2fad2d

Carbon Chamaeleon logo made by Monero Outreach

Logs for the MRL Meeting Held on 2019-11-04

Mon, 04 Nov 2019 00:00:00 GMT

Logs

<suraeNoether> GREETINGS!
<suraeNoether> I'm surae, I'm a taurus maybe, and i like long walks on the beach with high probability
<sarang> Hi
<suraeNoether> anyone else here?
<suraeNoether> well, public logs will be posted of this meeting either way, so anyone who missed it can find the logs online
<suraeNoether> okay, well, sarang, would you like to start?
<sarang> Sure
<sarang> I've been working on a few things...
<sarang> More Triptych work, on math/proof for single inputs, which are fine
<sarang> This includes some CLSAG-style key aggregation and more efficient key images
<sarang> (more on multi-input in a sec)
<sarang> Also gave a talk on transaction protocols
<sarang> And looked at using the existing transaction proofs to mitigate the Janus subaddress attack
<sarang> As to multi-input Triptych, this link is to the Overleaf paper: https://www.overleaf.com/read/ncqsdsydxvjv
<sarang> (multi.tex)
<sarang> The problem with witness extraction is the last equation on page 7
<suraeNoether> you and arthur are planning on submitting for peer review, yes?
<sarang> We could, once/if the proofs work out for multi-input
<sarang> We want to show that for every spent input M, H(M) = r*J
<sarang> where J is the key image
<sarang> and M = rG
<sarang> What we instead show is that a sum of the form \sum_u (\mu_u * H(M_u)) = \sum_u (witness_u J_u)
<suraeNoether> do you have your talk powerpoint up on your github?
<suraeNoether> by chance
<sarang> yes
<sarang> It's also the case that the sum of all witness_u is equal to the witness found for the signing key check
<sarang> Two equations above that one
<suraeNoether> found it: https://github.com/SarangNoether/talks :P
<sarang> I don't see a good line of reasoning to show why such a witness extraction would be equivalent to the honest generation of those key image
<suraeNoether> i'm taking a look now.
<suraeNoether> that shouldn't discourage anyone else from looking tho
<sarang> (you have to swap the two sums in the last equation to get something of the form that's two equations above, but that's fine)
<suraeNoether> janus mitigation right now is extra schnorr signatures, right?
<sarang> Yes, but you can use the existing transaction proof method, provided you check against a complete subaddress
<sarang> It's still off-chain, but functionality that exists now
<suraeNoether> very nice. iirc sgp_ wrote something on the janus vulnerability and made a blog post about it, or has a draft prepared. is that out or does it need updating or anything like that?
<sarang> Probably, but I'd like someone else to confirm that tx proof verification does in fact require external input of the suspected subaddress
<sarang> and that it's not pulled from the proof string in any way, or otherwise influenced directly by the prover
<sarang> (since the prover could simply use the Janus-modified subaddress)
<sarang> For this witness extraction, I suspect that it may possible to show that each u-summand in the X-check is in fact equal to a particular r_u term
<sarang> If that's the case, then we could easily show that the u-summand scalars in the Y-check are those _same_ r terms
<suraeNoether> great, does anyone else have any other questions for sarang about his work on triptych, or his work on janus, or questions about his talk?
<suraeNoether> well, my work this week has been on the matching code ( https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching ) which has some peculiar failings right now
<suraeNoether> my basic unit tests for graphtheory.py, which handles all the graph theoretic stuff, are passing. nodes and edges are added and deleted correctly, weighted correctly, matches are found, etc.
<suraeNoether> but when i simulate a ledger with my simulator.py tool, the result misses some nodes and/or edges
<suraeNoether> these aren't being caught lower down, but are being caught higher up
<sarang> hmm
<suraeNoether> so anyone with interest in python, graph theory, traceability, etc, can contribute by trying to figure out why my code isn't adding edges/nodes appropriately all the time. it's very bizarre behavior, and i'm sure it comes down to something ridiculous like my previous buffer problem
<suraeNoether> but, i want to put it down for a few days since other folks in theory could help, and i have other things to do like help review triptych's proofs
<sarang> That seems reasonable
<sarang> Is it clear in the code (or errors) where the specific problems are?
<sarang> i.e. if someone wishes to play around with it
<suraeNoether> running sh tests.sh from the tools folder will auto detect all the tests and execute them; i've skipped all the tests i know are currently passing, so it'll go right into the brick wall immediately
<sarang> got it
<sarang> suraeNoether: if you're going to be on IRC this afternoon, we could dive into that witness extraction and see if we can't solve it
<sarang> I have some ideas
<suraeNoether> beyond that, i have a few papers i have begun reading, such as this one https://eprint.iacr.org/2019/1177.pdf on aggregation approaches, and a few others on interactive versions of concensus mechanisms like this one https://eprint.iacr.org/2019/1172.pdf
<suraeNoether> sarang: i'm catching up on the triptych paper now and whiteboarding it
<suraeNoether> if i go all pepe sylvia on the thing i may take a crazed picture for posterity
<sarang> excellent reference
<sarang> I'll add a few more lines to page 7 to show how the X and Y witnesses are related
<sarang> since that should come into play in the Y-soundness
<suraeNoether> https://www.youtube.com/watch?v=InbaU387Wl8
<suraeNoether> so my action items today are: triptych whiteboarding, janus tx proof validation check (the external input issue you just mentioned)
<sarang> great
<suraeNoether> my action items immediately are to post my work report for last month and request funding for my next quarter, but i hate that and i much prefer coding and math so i'm finding myself v avoidant
<sarang> For this week, I'd (ideally) like to figure out this soundness issue... if it's possible to do so, it provides a very interesting extension to this Groth proof scheme
<suraeNoether> does anyone have any other research to advertise, or other questions for sarang or i?
<sarang> and would make Triptych a competitive option for tx protocol
<suraeNoether> it's such a great name
<sarang> suraeNoether: here are some general notes on the witness structure for ya
<suraeNoether> afk for about 10 minutes
<suraeNoether> sarang ^ yes pls!
<sarang> The prover wants to show that it knows the discrete logs (r-terms, in notation) for each of the signing pubkeys (M terms)
<sarang> so it knows a set of r (indexed by u different spends, no index here for clarity) such that M = rG for each one
<sarang> it also wants to show that H(M) = rJ for each one, where each J is a key image provided by the prover
<sarang> When done honestly, each J is defined such that J = (r^-1)*H(M)
<sarang> In the soundness proof, the "X check" is for signing keys, and the "Y check" is for linking tags
<sarang> X-soundness allows us to extract a witness (which involves certain Vandermonde-related coefficients) r1 such that r1*G = mu_1*M_1 + mu_2*M_2 + ...
<sarang> and we claim (MuSig/CLSAG-style) that knowing this witness r1 implies knowledge of each of the r terms going into the right-hand sum
<sarang> Ideally, for the Y-soundness, we want to extract a related witness that implies knowledge of the same r-terms that go into the linking tag identities
<sarang> If you stare at the rightmost terms of the bottom equation and third-from-bottom equations on page 7, you can see the u-summands match up
<sarang> If we can show (using the form of the Vandermonde coefficients, etc.) that each u-summand in the X-soundness corresponds properly to an r-value, we may be able to make a solid argument about using those same u-summands in the Y-soundness equation (since we need the _same_ r-values there)
<sarang> The construction of the Vandermonde-related coefficients \theta_e is also discussed on page 7 (and can be found in the original Bootle paper's proof)
<suraeNoether> back
<sarang> This might get complicated, since rows of the Vandermonde matrix correspond to different F-S challenges :/
<sarang> sarang is done talking now
<sgp_> suraeNoether: yes, the blog post should be updated to include the mitigation
<suraeNoether> hmmmm
<suraeNoether> sgp_: can you link the post for the meeting logs pls?
<sarang> sgp_: once it's been confirmed that the verifier externally provides the expected subaddress
<suraeNoether> showing the correspondence like that has always been a sticking point :\
<sgp_> https://getmonero.org/2019/10/18/subaddress-janus.html
<sarang> suraeNoether: unless you can think of a good argument that having the same summand terms in both the X- and Y-witnesses is sufficient already
<suraeNoether> well, i'll catch up and then i'll see what you mean by that. :P
<sarang> e.g. we already claim that knowledge of that sum-witness in the X-portion is equivalent to knowledge of each discrete log
<sarang> sure
<suraeNoether> *nod*
<sarang> Just remember that the key to the linking is that we show that the _same_ r-terms are used to construct the signing keys _and_ the corresponding linking keys
<sarang> so having the same witnesses should come into play
<sarang> It gets tricky because we don't directly show knowledge of each r-term, just the mu-weighted CLSAG-style combination
<sarang> So I wonder if we in fact already have all the information we need to show this
<sarang> and perhaps don't need to mess with those Vandermonde coefficients (which would be a huge pain to do)
<suraeNoether> okay, does anyone else have any research to talk about, or questions for MRL, or requests/points to bring up/etc?
<suraeNoether> otherwise we can adjourn the meeting and continue chatting about triptych outside of that context
<sarang> roger

Logs for the MRL Meeting Held on 2019-10-28

Mon, 28 Oct 2019 00:00:00 GMT

Logs

<sarang> GREETINGS
<sgp_> hello!
<sarang> I'll give a few moments for others who wish to join
<sarang> OK then
<sarang> Since suraeNoether is unavailable for this meeting due to an appointment, I'll share my recent work
<sarang> I've been working on algorithms and proofs for Triptych, a new transaction protocol
<sarang> The goal is to use a single proof to represent multiple inputs at the same time, including balance proving and linking tags
<sarang> Everything works great with completeness, zero knowledge, and soundness except for one proof component (the linking tags)
<sarang> There's a less efficient version that operates on single inputs, but can be combined for general transactions
<sarang> For this single-input version, modified proofs of security seem to work just fine
<sarang> For this reason, I'll finalize work on the single-input proving system while considering alternate approaches to finalizing the soundness proof for the multi-input version
<sarang> Separately from this, I have a small pull request (PR 6049) for a minor speedup and simplification to the Bulletproofs prover
<sarang> Also separately from this, Derek at OSTIF informs me that an audit group is willing to complete the CLSAG review
<sarang> JP Aumasson has offered to complete a review of the math and proofs for $7200 (USD), and his new company Teserakt has offered to then complete a code review for as little as $4800
<sarang> He says that including dependencies would increase the time (and therefore the cost), possibly significantly
<sarang> But the timeline could be before the end of this year, if there are no changes required to the algorithms after the math review
<moneromooo> Dependencies, like the src/crypto code ?
<sarang> Presumably. I do not have specific details on what his scope is (but will get this information)
<sarang> One approach might be to review all the changes _from MLSAG_, to show that CLSAG is no less secure as a whole than MLSAG
<sarang> These changes are fairly minor in the grand scope of the codebase
<sarang> I see there being efficiency advantages to having JP (and colleagues) doing both types of review, but this also reduces the total number of eyes on the combined math+code
<sarang> That being said, JP knows his stuff
<sarang> (he was formerly with Kudelski)
<moneromooo> Adding eyes by having Alice do the math and Bob do the code does not provide anything of value over Alice doing both IMHO.
<moneromooo> Assuming Alice and Bob have similar eyes and brains and proficiency in the relevant fields etc etc etc.
<sarang> So that's my report
<moneromooo> Is any of the new protocols being considered still compatible with multisig ?
<sarang> Aside from CLSAG, you mean?
<sarang> None of them specifically consider it in either algorithms or security model
<sarang> but it's on my list for analysis on RCT3 and (eventually) Triptych, since there are some modifications to RCT3 that I wish to consider (more on this later)
<moneromooo> I mean tryptich, rct3 and... and.......... the other the name of which escapes me.
<moneromooo> lelantus
<sarang> Omniring?
<moneromooo> Also :)
<sarang> Omniring and Lelantus both suffer from some drawbacks at present... Omniring does not support batching, and Lelantus still has a tracing issue unless you remove stealth addressing
<sarang> Looking into batch-compatible Omniring-style constructions with other proving systems is a topic for more investigation down the road that is nontrivial
<sarang> Is there other research that anyone wishes to present, or other questions?
<moneromooo> Also, rather selfishly, would any of them avoid the public-a issue we had for multi user txes ?
<moneromooo> (if known offhand)
<sarang> public-a?
<moneromooo> The problem where users would have to make their a values known to other signers.
<sarang> Ah, that's very unclear to me
<sarang> FWIW: RCT3, Omniring, and Triptych are agnostic to how output keys are generated (though their security models address particular constructions)
<sarang> So my ACTION ITEMS for this week are a bit in flux, mainly because I'll be at World Crypto Conference giving a talk on transaction protocols
<sarang> But aside from that, I want to finish the proof modifications (completeness, SHVZK, special soundness) for the single-input version of Triptych (which can be used in a larger protocol to support multi-input transactions), as well as a more efficient linking tag construction that matches what RCT3 and Omniring propose
<sarang> I also want to backport some of the ideas from the latest RCT3 update to their older version to compare efficiency
<sarang> It's unclear if this could easily be proven secure, or what the efficiency gains would be
<sarang> Their update did essentially two things: fix an exploitable flaw due to a particular discrete log relation, and allow for aggregated proofs of multiple inputs
<sarang> Unfortunately, the latter means potentially large padding requirements that would also incur computational cost to the verifier
<sarang> I want to see how easily the exploit fix could be included in the non-aggregated version... which would avoid this potential verification bloat at the cost of proof size
<sarang> I probably won't have time to do so this week, but it's on my list
<sarang> Anything else of note to cover before we formally adjourn?
<sarang> All right! Thanks to everyone for attending
<sarang> Logs will be posted shortly to the GitHub agenda issue

Logs for the Community Meeting Held on 2019-10-26

Sat, 26 Oct 2019 00:00:00 GMT

Logs

<sgp_> Meeting time
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/405
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support. Fun fact: you are awesome :)
<sgp_> 1. Greetings
<el00ruobuob_[m]> Hello!
<sgp_> ping dEBRUYNE rehrar ErCiccione[m] xmrscott[m]
<ErCiccione[m]> Hi all. Thanks for the ping sgp_
<sgp_> needmonero90 dsc_ gingeropolous sarang
<gingeropolous> yo
<sgp_> hopefully more people pour in later
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com
<sgp_> Reminder that 0.15 is expected on October 31, with the scheduled protocol upgrade on November 30: https://getmonero.org/2019/10/01/announcement-release-0-15.html
<needmonero90> Oh, right, meetings are a thing on Saturdays
<sgp_> The code is frozen! Get testing!
<sgp_> We tried out a gaming session two weeks ago, and we had our coffee chat last week which was excellent despite technical challenges.
<sgp_> Are there any outstanding questions regarding the upcoming update, or does anyone have community (non-workgroup) updates to share?
<needmonero90> Last coffee chat was packed
<needmonero90> We need that more
<sgp_> super stacked lineup indeed :)
<msvb-mob> Hello.
<needmonero90> I expect you're going to link your poll soon enough, so I'll hold off
<sgp_> yup :)
<sgp_> needmonero90: can you create that update thread for exchanges in r/xmrtrader?
<needmonero90> Will do during this meeting.
<sgp_> excellent
<thunderosa> I guess it's a community update. The new Monero Pool UI is coming out in the next few days. Half the size, twice the speed, new features etc.
<sgp_> did someone else volunteer for the mining pool list for r/moneromining? I don't recall if I signed up for that
<xmrmatterbridge> <rehrar> Hey. I'm in Mexico right now.
<xmrmatterbridge> <rehrar> Won't be back home for a few hours.
<needmonero90> Okay amigo
<sgp_> thunderosa: very cool
<rottensox> what i miss.
<xmrmatterbridge> <rehrar> Left a comment on the meta issue of the meeting.
<sgp_> rehrar: yes, I added a section to discuss :)
<sgp_> let's proceed
<sgp_> 3. CCS updates
<sgp_> Funding required:'
<sgp_> Rehrar to 36C3 (4.42 / 58.65) https://ccs.getmonero.org/proposals/rehrar-36c3-expenses.html
<sgp_> Multiple features and fixes for getmonero.org: https://ccs.getmonero.org/proposals/ErCiccione-website.html
<sgp_> Ziphon’s request was overfunded! https://ccs.getmonero.org/proposals/xiphon-part-time-2.html
<sgp_> *xiphon
<sgp_> Ideas (to be discussed):
<sgp_> WIP: Norwegian translation (3 XMR): https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/102, and
<sgp_> moneromooo, from November 2019 (395 XMR): https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/103
<needmonero90> Xiphon*
<needmonero90> Oh you corrected my nad
<needmonero90> Bad
<sgp_> any comments? or shall I take the silence as approval?
<needmonero90> My silence is approval on everything other than the rehrar funding proposal, which has its own issues that have been discussed
<needmonero90> Not sure if it's resolved, but I'll take it to back channels first
<needmonero90> (issues meaning the speed at which it was merged, potential for alternatives with lower travel fees, etc)
<sgp_> sure, it's already been moved, so that complicates things a bit
<el00ruobuob_[m]> i silently approve moneromooo, looking into the Norwegian.
<sgp_> did you hope that it would be discussed during a meeting first needmonero90?
<needmonero90> I can't recall where the conversation is at, so I don't want to cover old ground
<ErCiccione> I suggested the guy for Norwegian to open the CCS and make the post on reddit, but i also asked to write references for his work. So, i'm waiting for those before i express my vote on that
<needmonero90> Just wanted to express in meeting that that particular proposal is a thorny issue
<sgp_> all right. it was officially open for 4 days
<needmonero90> Not long enough or with enough discussion imo
<sgp_> thanks ErCiccione. fwiw I find the asking amount for that proposal pretty reasonable
<ErCiccione> sgp_: I agree on that.
<sgp_> Any other CCS comments before we move on?
<needmonero90> none here
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> Code freeze. All the things happened.
<needmonero90> I was confused when I saw a reddit thread about getting translations done *before* the freeze (maybe I misread)
<sgp_> most notably the pay-by-hash for remote node use PR
<needmonero90> which didnt make sense, I thought translations and stuff were ideal after the freeze
<sgp_> needmonero90: my understanding is that there are essentially two freezes, so it depends on which one you call the "freeze." ErCiccione would be able to explain more though
<needmonero90> https://www.reddit.com/r/Monero/comments/dlxyiu/monero\_translators\_we\_need\_you\_to\_make\_one\_final/
<monerobux> [REDDIT] Monero translators, we need you to make one final sprint! The code freeze is imminent. (self.Monero) | 112 points (99.0%) | 15 comments | Posted by ErCiccione | Created at 2019-10-23 - 11:33:44
<needmonero90> ah, okay
<ErCiccione> needmonero90: translations and stuff were ideal after the freeze <- They are, but for this release the GUI has been ready for some time, with no strings added
<needmonero90> I thought code freeze meant the codebase was in a state where bugfixes and text data would be updated
<needmonero90> or, thats the ideal place
<ErCiccione> if there are no new strings we can start a bit earlier
<needmonero90> im curious when the deadlines are for translation work
<ErCiccione> the deadline was yesterday for CLI and today for GUI
<xmrscott[m]> They've both come to pass
<needmonero90> ah, so no translations in this release
<needmonero90> no more*
<sgp_> there were two weblate PRs I think
<sgp_> This brings up to b. Localization workgroup anyway
<sgp_> *us
<ErCiccione> needmonero90: weblate is open, if people keep translating (and approving strings), we can open another PR. But that never happens
<ErCiccione> well, it's open for the CLI. GUI is locked because i pushed the translations today and they have to be merged before i unlock it
<sgp_> code freeze* *except for optimistic translations
<ErCiccione> yeah
<hyc> code freeze: no more code changes besides bugfixes
<hyc> text changes, doc changes - probably still fair game
<needmonero90> thats what I thought from past projects I've interacted with
<sgp_> Can we take a step back and let us know how how the localization process happened this time ErCiccione? Or any other contributor
<ErCiccione> the thing is.We never had a proper code freeze, so i was usually waiting until all the features were in and then ask translators to translate,
<ErCiccione> now with an actual code freeze and release week after, we had to do things a bit earlier
<ErCiccione> sgp_: sure
<ErCiccione> Weblate was open since i announced it. There was few activity until my last calls for translators on reddit and twitter. I gave as a deadline the day of the beginning of the code freeze. merged those, translators can keep translate,
<ErCiccione> and if there are enough strings translated i PR them to the repo (GUI or CLI) when it's possible to do so
<sgp_> Do people like using weblate?
<ErCiccione> As far as i can see, they seem to love it
<ErCiccione> and i agree
<ErCiccione> after the release we will use it for the website as well, i don't know if i already said that
<xmrscott[m]> Very much so
<sgp_> thanks
<xmrscott[m]> Grammatical checks and similar strings os incredibly powerful, and you don't need to find your own locally run client for those features, all browser based
<sgp_> I'm glad people like the system. It will help make translations more approachable to people who want to help
<xmrscott[m]> We should add MyMonero app at some point too
<ErCiccione> xmrscott: today i added some more QT specific checks, should be even more accurate now
<xmrscott[m]> And as an aside to highlight how amazing it is, when I got the OpenWrt to start using it they described it as very addictive :)
<ErCiccione> about the workflow: i'm roughly using the "continuous translations" system weblate suggests https://docs.weblate.org/en/weblate-2.8/admin/continuous.html
<xmrscott[m]> My person favorite feature is the ability to get new emails when new strings are added
<ErCiccione> yeah the notification system can be personalized a lot
<sgp_> Any other localization comments?
<el00ruobuob_[m]> i just saw that, that's great!
<sgp_> c. GUI workgroup
<sgp_> GUI code freeze is today. i2p support will come in a later point release unfortunately
<sgp_> the complexity of the code took a toll on some contributors who need more time to make it happen
<sgp_> related note: dsc has been teasing a new non-core GUI that he made on the side
<sgp_> Any questions? I'll do my best to answer
<rottensox> na. move on.
<needmonero90> I believe there was some discussion on renaming the GUI?
<needmonero90> idk where that went
<needmonero90> some people thought "Monero GUI" was too clinical/technical, and wanted something "warmer" for new users (my words)
<sgp_> needmonero90: I'm going to table that discussion for this meeting, but here is the relevant naming discussion that xmrscott[m] is championing: https://github.com/monero-project/meta/issues/384
<thunderosa> I'll just chime in with wanting to banish anything "graphical interface" because the public has never seen a non-graphical interface.
<needmonero90> wasn't trying to discuss it, just find the discussion point :)
<thunderosa> It's inside reality vs outside reality.
<sgp_> no problem, thanks for mentioning
<sgp_> is sarang free to do a quick MRL update?
<sgp_> d. Monero Research Lab
<sgp_> Surae made significant progress on his matching code, with preliminary results now available for validation. Sarang did some hard moon math. Their meeting logs are on Github under meta.
<sgp_> We also discussed subaddress association (and the related Janus attack). See this article and the accompanying Breaking Monero episode: https://getmonero.org/2019/10/18/subaddress-janus.html
<sgp_> if there are no other comments or questions, we can move on to 5
<sgp_> 5. Monero 0.15 release name
<sgp_> We need to pick a release name. To assist this, I’ve solicited feedback informally in this ranked-choice poll: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E\_e228920d8a4d1cec&akey=ebaf2172a4c2dcc9
<sgp_> Results:
<sgp_> 1. Carbon Callisto
<sgp_> 2. Carbon Comet
<sgp_> 3. Carbon Crab
<sgp_> 4. Carbon Chamaeleon (or Chameleon)
<sgp_> 5. Carbon Cosmos
<sgp_> at this point we really need to pick a name, fast
<needmonero90> I'll do a quick Telegram poll
<thunderosa> Callisto is already the name of a crypto-project. Comet or Cosmos are both strong
<needmonero90> speaking of projects with the same name, cosmos?
<needmonero90> lol
<sgp_> I shared this on Telegram too needmonero90, but other feedback is welcome. You can point them to the same link if you like. I can keep it up for the rest of the day
<thunderosa> well, it's a little more universal I guess
<darkaleph> callisto is a little on the nose as well
<rottensox> Carbon Comet is a winner.
<needmonero90> crab too :(
<sgp_> I'm fine with all 5 of those choices honestly
<needmonero90> though lots of elements have a C, so
<sgp_> crab is probably my least favorite though
<hyc> I dislike COmmet / Consetllation /whatever as too generic
<thunderosa> yeah, crab = bad
<needmonero90> D:<
<needmonero90> how dare you
<needmonero90> I'll fork off
<hyc> the name should be a specific celestial body, not a general type of object
<sgp_> lol sorry :p
<needmonero90> crab nebula*
<needmonero90> btw
<sgp_> "MASSIVE Monero naming dispute"
<hyc> So Callisto, Crab, Chamaeleon are the only proper nouns in this selection
<thunderosa> Cassiopeia
<el00ruobuob_[m]> Luna wasn't a specific celestial body hyc
<hyc> yes it is Luna is a proper name for the earth's moon
<sgp_> hyc: I interpret the naming convention a little more loosely, so I'm ok with any of these if they make sense
<sgp_> in some ways, the simplicity is a strength
<rottensox> luna is moon in Spanish
<rottensox> yeah, i'll see myself out.
<rottensox> Carbon Comet dammit.
<sarang> Sorry I stepped away for a moment
<needmonero90> \o/
<needmonero90> welcome back
<sgp_> Carbon Callisto is both simple and unique enough that it's a reasonable compromise imo
<sarang> Hit a bump in a soundness proof
<sarang> I'm working on alternate approaches
<needmonero90> sgp_: https://coinmarketcap.com/currencies/callisto-network/
<thunderosa> Yeah, and it's a bullshit coin too.
<needmonero90> at rank 694 we'd trounce their SEO, so its nbd
<sgp_> yeah I'm not too concerned about that :p
<needmonero90> after looking at it, I think using Callisto isn't a problem, even though its another crypto project
<needmonero90> my concerns are gone now
<needmonero90> https://coinmarketcap.com/currencies/cosmos/
<needmonero90> that tho
<needmonero90> cosmos is out
<sgp_> yeah, probably not the best idea
<el00ruobuob_[m]> Carbon Crommelin Comet, abreviated in Carbon Comet ?
<el00ruobuob_[m]> https://en.wikipedia.org/wiki/27P/Crommelin
<monerobux> [WIKIPEDIA] 27P/Crommelin | "Comet Crommelin, also known as Comet Pons-Coggia-Winnecke-Forbes, is a periodic comet with an orbital period of almost 28 years. It fits the classical definition of a Halley-type comet with (20 years < period < 200 years). It is named after the British astronomer Andrew C. D. Crommelin who calculated..."
<sgp_> Does anyone hate Carbon Callisto?
<needmonero90> the name doesnt conjure up strong feelings of space in my mind
<hyc> I'm ok with Callisto
<needmonero90> but I'm indifferent
<sgp_> two voters who actually ranked everything in the poll rated it pretty low
<thunderosa> I've got a bad association, but it's probably personal...I'm ok.
<sgp_> but for most people, it was the top 1-4 choices
<hyc> well, I recognize it as a moon of Jupiter so that works for me. but not much in love with it
<needmonero90> if we go with Comet, I can see some retro cleaning product advertisement pushes by outreach
<hyc> Chamaeleon is still my #1. multiple people pointed out its self-changing nature
<needmonero90> https://i.pinimg.com/originals/3c/34/2b/3c342b122549bade835eaa0fcdc906f2.jpg
<needmonero90> "with ring signatures"
<thunderosa> yeah, chamaleon is a decent choice,...it has some personality
<ErCiccione> i like Callisto
<sgp_> The Chamaeleon / Chameleon similarities is a small weakness imo. Would be better if they were spelled the same way
<needmonero90> I have a solution
<sgp_> lol @ comet ad needmonero90
<needmonero90> lets call it Carbon Chamæleon
<sgp_> lol
<needmonero90> fixes all the issues :D
<hyc> ok with me. alternate spellings, easier spelling, whatever
<thunderosa> +1 Carbon Chamaleon (or however it's spelled)
<sgp_> well, hopefully this helps Core in some way make a decision :)
<needmonero90> lets table the bikeshedding, debruyne and I will figure out a reddit thread and stuff
<darkaleph> chameleon is better then callisto but if you want heavenly bodies with a nod to rings then Cassini is cool
<sgp_> we should move on to the final main topic
<needmonero90> nah, move back sgp
<needmonero90> sarang is here now
<sgp_> sure, sarang do you have a quick summary?
<needmonero90> maybe he's afk again :(
<sgp_> lol
<sgp_> he can take the stage if he comes back
<sgp_> 6. Extracurricular activities
<sgp_> Rehrar asked to reserve some time for extracurricular activities. Fun things that we can do to help foster the community.
<sgp_> We tried a gaming session that was a good start, but it wasn't too fun for viewers
<sgp_> We still have some room to test things out there I think
<sgp_> I recently paid for a premium Kahoot subscription for r/cryptocurrency, so we can use that for fun quizzes if we want
<sgp_> but ultimately, what activites would be useful to help bond the community together? what would you like to see the Monero community do?
<rottensox> videogames, sports, even board games tournaments. put together by the community for the community and its users...
<sgp_> board games are cool, but they're a little difficult to play online
<rottensox> livestreaming community members playing a videogame won't do much.
<hyc> this community isn't collected together because of gaming
<sgp_> we probably need an announcer for the games
<sgp_> hyc: of course not, but we're looking for other excuses to do things
<rottensox> well, I precisely said board games to do them face to face...
<rottensox> gaming can help others understand a truckload of things. through gaming you can achieve many things...
<thunderosa> I don't really like it, but gambling type stuff has been popular. Maybe that could be made to be more interactive or team-based or something.
<rottensox> there's a lot of room for us to grow. ruling out games be it videogames, board games, sports or anything you can think of is very short-sighted.
<hyc> sure. maybe you can try putting together an educational game about monero, money, finance...
<sgp_> cooperative minko lol
<rottensox> a little guy created moneropoly...
<sgp_> I wonder if that could somehow be done as a giveaway instead of gambling like it was done at Defcon
<rottensox> a tournament of moneropoly? :-)
<sgp_> but I wonder how much appeal that has
<el00ruobuob_[m]> i'm in for a moneropolly tournament
<rottensox> a set of cards whose arts are xmr-related?
<thunderosa> monopoly actually kinda words online,..more than most other games at least
<rottensox> see? there we go. interest spiking.
<needmonero90> hyc: corporations aren't collected together because of golf, but its still a fantastic excuse to do something outside of a business context in a more casual situation
<rottensox> thunderosa: you have not played moneropoly, have you?
<needmonero90> for example.
<thunderosa> no, I saw the post and thought it was a cool. I'm a Monopoly hound from way back.
<sgp_> A Monero-themed cards against humanity could maybe work, but I think the websites that support custom cards are really dated
<hyc> you could do moneropoly with live wallets
<hyc> on testnet coins
<needmonero90> finally my testnet hoard will be useful
<sarang> Gah, i am back!
<thunderosa> well, just a $1 buy-in to play,....the pot gets split somehow with the winner and the house
<sarang> Multitasking is failing me
<thunderosa> goes to the fund or something
<sgp_> Can we somehow make "Game of Whales" work? Somehow related to Game of Thrones
<needmonero90> more like unitasking
<needmonero90> sarang whats the summary?
<rottensox> outreach and rehrar can help these idea pan out?
<needmonero90> sgp_: Lets discuss game stuff unlogged after-meeting :)
<sarang> I have been hard at work on a new transaction protocol
<rottensox> s/idea/ideas
<monerobux> rottensox meant to say: outreach and rehrar can help these ideas pan out?
<sgp_> sure needmonero90. good to get some ideas rolling while people are paying attention
<sarang> A really cool multi input version works but the soundness proof does not
<sarang> A single input version does have proofs that are working
<sarang> But I would love to get the former proven properly
<sarang> It's so close
<sarang> I have a full writeup to share at Mondays meeting
<needmonero90> anything happening on the other protocol fronts?
<needmonero90> Halo, RCT3, lelantus?
<needmonero90> or are those same as before
<sarang> I want to backport some RCT3 stuff for efficiency comparisons
<sarang> Nothing new on Omniring given its batch limitations
<sarang> The RCT3 stuff was on hold due to this new protocol
<sarang> So much math to do!
<rottensox> sounds right up your alley though.
<sgp_> Thanks sarang!
<sgp_> Any final comments before we wrap up the meeting?
<sgp_> Thanks for joining everyone
<sgp_> (skipping 7. open ideas time)
<el00ruobuob_[m]> thank you!
<msvb-mob> Thanks sgp_, good meeting.
<sgp_> 8. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 9 November at 17:00 UTC. Note a possible regional time change! The next Coffee Chat will be on 16 November at 16:00 UTC, but we may change the format. Stay tuned for more details.
<sgp_> 9. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the Monero Research Lab Meeting Held on 2019-10-21

Mon, 21 Oct 2019 00:00:00 GMT

Logs

<suraeNoether> Greetings everyone!
<suraeNoether> My work this past week has been fruitful. Right now I'm running simulations. These are not data collection simulations yet, but if they pass testing, then I'm making a final push my repo and then data collection will begin and I'll be getting *literal answers* later this afternoon.
<suraeNoether> this is the matching/churn project
<sarang> Nice
<suraeNoether> in addition to that, sarang asked yesterday: do we care more about space or time when it comes to replacing signature schemes. luckily, we can literally quantify when it is worth switching to a new scheme
<suraeNoether> Just to remind the audience, here is how that derivation goes
<suraeNoether> Let's say we have two possible ways of encoding a database and verifying its contents.. Case I: Size of file is O(n) and time to verify file is O(n). Case II: Size of file is O(log(n)) and time to verify file is O(n).
<suraeNoether> When is it worth it to switch from Case I to Case II? In Case I, total download and verification time is a*n/c + b*n/v where a and b are constants, c is average download speed, and v is average verification speed (per bit)
<suraeNoether> In Case II, total download and verification time is A*log(n)/C + B*n/V where A, B, C, and V are other constants, usually different than in Case I (although we can assume c = C for simplicity although often V != v)
<suraeNoether> The total cost in time to download and verify implies that Case II is better than Case I if and only if (a/c) + (b/v) > B/V + (A/c)*(log(n)/n). To give you guys a rough idea, when n > 10^2, log(n)/n is smaller than 0.025, so this term drops pretty quickly
<suraeNoether> Since log(n)/n tends toward zero, if n is remotely large (for a blockchain we are talking about large powers of 10... and n increases as time goes on), we require a/c + b/v > B/V for this ever to be at least asymptotically a good idea to switch, and we realize that asymptotic bound pretty quickly
<suraeNoether> we can run timing tests on some schemes for to estimate ballpark values of a, b, c, v, B, and V (I suspect b = B but a != A...)
<suraeNoether> (these derivations are why we haven't *yet* switched to a sublinear scheme, by the way!)
<sarang> Well, that and not having a clear winner in terms of overall efficiency+soundness
<sarang> Different constructions don't necessarily scale the same way with transaction input/output structure
<sarang> The logarithmic size scaling is for the size of the specified anonymity set, overall
<sarang> How they handle multiple inputs/outputs makes a difference
<suraeNoether> indeed, all the above is very generalized and specific formulations for specific schemes are required... besides, *none* of the above assumes batching
<suraeNoether> although batching can be approximated by tweaking the parameters b, v, B, and V, it's still just a ballpark back of napkin thing
<sarang> This past week I've worked on a few things
<sarang> First, the IACR/2019/944 optimized IPA verifier was added to kenshamir[m]'s Rust implementation and benchmarked, showing no improvement over the Bulletproofs IPA
<sarang> We sent a note to the authors to share our results and get some clarification on the results from their paper
<sarang> But it definitively answers the question of how useful it would be in practice to use the updated verifier (answer: it wouldn't be)
<mikerah> Do you have a link to @kenshamir's rust crate?
<sarang> https://github.com/kenshamir/qesa
<sarang> I also have Triptych balance proving working
<sarang> and have completed a writeup of the algorithms
<sarang> Now I'm putting correctness proofs in, which is tedious due to the algebra
<sarang> There were some other modifications for efficiency too, which will need to be examined for soundness
<sarang> Also of note is that last week, a side-channel issue with subaddresses was reported and examined
<sarang> We discussed a fix that would essentially add a Schnorr representation proof to outputs
<sarang> I'm told there is a blog post and corresponding Breaking Monero episode ready to go that describe this
<sarang> This week, I plan to continue work on Triptych proofs: correctness, soundness, zero knowledge
<sarang> Back to you suraeNoether
<suraeNoether> This week, my action items include posting my funding request for the next quarter, assisting sarang with the soundness proof of triptych, and to actually answer some questions about churn with some rigor
<sarang> Anyone have questions, or other interesting research to share?
<suraeNoether> the work i've put into the infrastructure of this project has paid off, because the actual script running the tests is around 30 lines. the rest of the code is writing output to file etc
<suraeNoether> (the library i wrote is 700 lines with 1200 lines of tests iirc but who counts lines anyway)
<sarang> I'll be interested to see what level of support there is (or is not) for the Schnorr proof modification to avoid the subaddress side-channel attack
<mikerah> I want to pass some ideas by you all around minimal smart contracts on monero.
<sarang> ok
<mikerah> The idea is to use FHE with a DSL to then store in the extra tx_data field of monero transactions
<sarang> DSL?
<mikerah> The main problem with this is that there isn't any actual enforcement of the smart contract logic
<mikerah> DSL = Domain Specific Language
<sarang> It's tricky because ring signatures are, by definition, signer-ambiguous
<sarang> Meaning more complex spend conditions typically don't play nicely with that
<mikerah> yeah, agreed. Has anyone looked into bringing the DLSAG construct into production?
<suraeNoether> DLSAG currently has some key image formatting problems :\
<sarang> Not that I know of... its scaling is still linear with the ring size, and it has a tracing problem that hasn't been solved
<suraeNoether> also ^
<sarang> Right, any other questions or comments before we adjourn?
<mikerah> https://eprint.iacr.org/2019/1229.pdf
<mikerah> Has anyone had time to skim that?
<mikerah> It's the new supersonic scheme by BBS
<sarang> Ah yes, I gave it the most cursory of glances
<suraeNoether> it uses groups of unknown order, which is a fun but weird concept that is also used in VDFs
<sarang> Even so, with certain instantiations, they estimated 7 kB or so for a 1 million-gate circuit (of some structure that I don't recall)
<mikerah> My issue with constructs using groups of unknown order is what happens if a smart kid finds the order of the group?
<sarang> The hardness assumption has to do with element order IIRC
<sarang> among other hardness assumptions they require
<sarang> Anyway, it's interesting and applicable to different proving systems
<sarang> OK, I'm gonna get back to work typesetting some correctness proofs
<sarang> Thanks to everyone for attending

Overview and Logs for the Dev Meeting Held on 2019-10-20

Sun, 20 Oct 2019 00:00:00 GMT

Logs

<rehrar> Alright everyone. 17 UTC.
<rehrar> Meeting time.
<rehrar> 1. Greetings
<hyc> hey
<rbrunner> Hi
<kinghat> \o/
<rehrar> small crowd today?
<sech1> hi
<rehrar> well, perhaps people will trickle in.
<rehrar> Two weeks ago I was at HCPP, so I wasn't able to be here for a meeting. Was there one?
<dEBRUYNE> I am here
<rbrunner> No, neither 1 week ago
<dEBRUYNE> I think we decided to postpone it
<rehrar> ok, so
<rehrar> 2. What's been completed since the previous meeting (a month ago)
<hyc> a lot of PRs got merged
<hyc> has the v12 forkheight been merged?
<moneromooo> You can now sync off pruned nodes.
<moneromooo> Not yet.
<dEBRUYNE> I think that will probably be on the last merge list before we branch
<dEBRUYNE> ^ rehrar
<moneromooo> vtnerd__: do you intend your latest network changes to go in for the fork ?
<vtnerd__> the one that is up for review, yes that would be the hope (provided its determined to be ready)
<vtnerd__> its not needed for the hardfork, so if you feel it should wait, then my recommendation would be to wait for a point release
<vtnerd__> the problem is that re-testing some of your recommendations are likely to take up time before the upcoming branch, but I will try
<moneromooo> I think that and pay-for-service are the only large ones left.
<moneromooo> Oh, and the defer tx verification one. Not huge either but a bit substantial.
<rehrar> are either of those expected to be in?
<moneromooo> Hopefully all of them.
<moneromooo> pay-for-service goes next, I've kept it waiting for long enough.
<hyc> sounds good
<rbrunner> Did I get that right that a PR is waiting in that batch that will cause testnet to reorg back to some much earlier blockheight?
<hyc> not that I've seen
<hyc> ?
<rbrunner> Maybe I misunderstood then, while reading something up here
<moneromooo> I said so, but I was wrong. The rules are different, but actually coincide in practice.
<rbrunner> Surprising
<rbrunner> All the better
<moneromooo> They'll stop conciding whe nthe block size shoots up.
<rbrunner> So we only need some seed nodes working for testnet ... caugh ... caugh
<moneromooo> gingeropolous added one, that'll be merged soon.
<rbrunner> Nice
<hyc> dEBRUYNE: didn't you get hold of fluffypony regarding seed nodes?
<dEBRUYNE> He posted an update here 1-2 days ago
<dEBRUYNE> <fluffypony> re: testnet nodes, I've been having some issues with the boxes I run, but there are other people running testnet nodes besides me
<hyc> ah, I missed that. ok
<rbrunner> Especially nice that stagenet gets a third seed node, with the only two so far probably just sitting side-by-side and offering zero redundancy
<rbrunner> well, not zero, but you get what I mean ...
<rehrar> Anything else of note to discuss on what's been done this past month?
<hyc> sounds like not
<rehrar> Alrighty.
<rehrar> 3. Fork related things
<rehrar> is there anything that is needed, desired, wanted, or otherwise needs to be discussed regarding the upcoming fork.
<tevador> FYI, there will be probably RandomX 1.1.5 with some OpenBSD-related fixes
<tevador> but best if 1.1.4 is merged first (1.1.5 doesn't need any changes in monero code)
<hyc> that's PR#5980 for v1.1.4
<tevador> yes
<rehrar> ok, no other fork related topics? If not we can move on.
<rehrar> Zipping through this meeting.
<rehrar> is anyone from GUI here? dsc_ selsta
<selsta> yes we only had bug fixes recently
<selsta> GUI is ready for v0.15
<rehrar> ok
<rehrar> 4. Any Ticket/PR related questions?
<rbrunner> By the way, is there already a final name for the release? I could use it for adjusting the Windows installer. Is it now crab something?
<hyc> carbon crab?
<hyc> I don't recall a final name decision
<rbrunner> Yeah, that one
<rehrar> Where was the discussion?
<rbrunner> Me neither, that's why I ask for sure
<rehrar> We can make a decision here.
<rbrunner> I think there was some chatter in a Reddit thread once
<hyc> I think some names got tossed around in this channel a few weeks ago. but nothing decided.
<moneromooo> camelopardalis is satifyingly complicated.
<rehrar> you guys want to decide now? Or not urgent?
<hyc> oh yeah, that was my suggestion
<moneromooo> I think pony likes to leave it for a reddit vote where people can't break things
<hyc> we can do it now, there seems to be enough people present
<hyc> ah
<dEBRUYNE> Pony usually makes a Github thread and links that to reddit iirc
<rbrunner> I would also prefer a Reddit thread, more fun for the fans, so to say
<dEBRUYNE> (re: name)
<rbrunner> But why not soon, e.g. tomorrow
<tevador> does the 24th Oct code freeze still apply?
<tevador> (it should)
<hyc> there was a mention of name on reddit https://www.reddit.com/r/Monero/comments/d884zt/preliminary\_information\_thread\_regarding\_the/f2zfmr1/
<hyc> but pretty sure that was just relaying a suggestion from here on IRC
<rehrar> I can make a meta issue and link to it on the Reddit
<hyc> cool
<rbrunner> Yeah that was me, but I forgot where I got that Carbon Crab
<rbrunner> Yes, do go ahead
<dEBRUYNE> rehrar: should I ask pony first if he wants to uphold the tradition?
<hyc> (I have the previous discussion in chat logs, was in this channel a couple weeks ago)
<moneromooo> Callisto alliterates nicely too fwiw.
<rehrar> sure
<rbrunner> Hmm, yes indeed
<rbrunner> "Crab" is very short
<rehrar> Is there anything else to discuss besides the naming?
<rehrar> Kind of a free for all time.
<hyc> that's always the hardest problem in computing...
<rbrunner> So it looks surprisingly good for this code-freeze
<rehrar> it's because we extended it out an extra month?
<rehrar> Alright, well if there's nothing else to discuss, then we can go ahead and break. Doughnuts are on the table on your way out.

Advisory note for users making use of subaddresses

Fri, 18 Oct 2019 00:00:00 GMT

Dear participants of the Monero ecosystem,

After some new limitations of subaddresses were found, this post should help clarify the use-cases of subaddresses and the privacy protections that they provide. Monero added subaddresses to its software to allow simpler OpSec management. For many users, subaddresses are a more elegant way to receive transactions than integrated addresses or main addresses. However, subaddresses are not as robust as using entirely different seeds for each desired disparate identity.

In summary, the below chart should help explain the relative privacy protections of different address behaviors. From a user experience perspective, subaddresses are far more user-friendly than using addresses from completely different seeds, while still providing a level of privacy protection that is sufficient for most use-cases.

Reusing the main 4... addresses or integrated addresses will most likely allow counterparties and many passive observers to connect related addresses together to a single entity. This can occur if the addresses are posted publicly.

Subaddresses provide a much stronger degree of protection than integrated addresses. However, they provide weaker protection against malicious counterparties under some circumstances. We will describe one specific limitation as the "Janus attack."

Users who want the highest level of privacy and control should use independent seeds for each identity that they want entirely isolated from other activities.

Janus attack information

Plain English explanation:

You have two subaddresses in your wallet, A and B. You ask the attacker to send funds to you at address B, but the attacker suspects that you also own address A and wants to prove that you do. To prove this, instead of sending funds to you at address B, the attacker can send funds to you at address A and make it look to your wallet like the funds were actually received at address B. If you tell the attacker that you successfully received the funds, the attacker then knows you own address A. This attack is undetectable.

To give another example, suppose an attacker is given a subaddress deposit address at a popular exchange. They suspect that your subaddress is an exchange address. They may confirm this by sending themself a transaction that is only credited to their account if your account is also derived from the same seed held by the exchange. If the attacker's suspicions are incorrect, then they will not receive a deposit, and the funds are forever inaccessible by both them and you.

Technical explanation:

You ask me to send funds to you at the subaddress (C_j, D_j). I suspect you have two identities, and that you also own subaddress (C_i, D_i). Instead of publishing the tx public key sD_j and output public key Hs(sC_j)G+D_j, I instead publish the tx public key sD_i and the output public key Hs(sC_i)G+D_j. You can't tell that I've done this, and it looks to you like I sent funds to you at your (C_j, D_j) subaddress. If you tell me you received the funds, I have now established that the (C_i, D_i) subaddress is in the same wallet and that you own both subaddresses within the same wallet (i.e. that they share the same private view key).

Attack requirements:

All three of the following must be true for the attack to successfully link subaddresses to a shared seed:

The victim is using subaddresses connected to a single seed. Accounts are irrelevant. Separate accounts under a single seed are still susceptible.
The attacker is knowledgeable of a subaddresses to test and crafts a special transaction that is received by the victim if the subaddresses are derived from a single seed.
The entity confirms (manually or automatically) off-chain that the payment is received. The attacker can confirm their own receipt instead if they also have a subaddress derived from the same seed as the victim, such as in the exchange example.

Mitigation:

Use separate wallets instead of separate subaddresses if you need to keep two different addresses completely unlinkable. Alternatively, do not notify any sender of the receipt of funds to your wallet. An attacker cannot know if the poisoned transaction was received to your wallet unless you confirm this to them. Do not share your exchange deposit subaddress with others; it's for your eyes only.

Notes:

There are at least two known mitigations. Either we could encrypt the tx private key and send it as part of the transaction, or we could publish a Schnorr signature proving knowledge of the tx private key corresponding to the published tx public key, on the base point D_j. Doing either of these things would allow the recipient to verify that the incoming transaction is constructed properly. This mitigation would result in a slight increase in transaction size. Research on other possible mitigations is ongoing.

This vulnerability requires an active attack involving sending funds to a wallet by the attacker. Passive non-colluding observers with knowledge of this vulnerability do not gain any advantage when attempting blockchain analysis to trace the movements of funds.

This attack cannot be used to steal funds or inflate the supply of Monero. It can only be used to determine if two subaddresses belong to the same wallet.

If you are using subaddresses to distinguish between incoming funds to your wallet, rather than to maintain separate identities, then this attack does not affect you. Therefore, most merchants and exchanges will not be affected by this attack.

If the attacker's attempt is unsuccessful and the targeted subaddress is not derived from the same seed, then the funds are permanently inaccessible by the sender and receiver.

Breaking Monero explanation

Justin Ehrenhofer explains the limitations of subaddresses, including the Janus attack, in a Breaking Monero video.

Conclusion

Subaddresses are an excellent, simple OpSec tool for the vast majority of people, but they are not perfect. Users who prioritize their privacy over convenience should use addresses derived from separate seeds as needed. However, most users should rest assured that this edge case will not impact most users in practice. The best, simple way to achieve reasonable unlinkability remains through the use of subaddresses.

Overview and Logs for the tini2p Dev Meeting Held on 2019-10-17

Thu, 17 Oct 2019 00:00:00 GMT

Logs

<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> h
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> last week was the alpha release of tini2p
<tini2p_gitlab> the router is still in its earliest stages, and things will still be changing fairly drastically as refactors and bug fixes are made
<tini2p_gitlab> tini2p routers are capable of building ECIES tunnels, and communicating end-to-end via ECIES-X25519
<tini2p_gitlab> NTCP2 (a tcp-like transport) is fully implemented
<tini2p_gitlab> cross-implementation testing is still needed to discover and remedy any bugs (if they exist)
<tini2p_gitlab> the router is also currently compiled with a testnet netID to mitigate any communication with mainnet routers
<tini2p_gitlab> using a testnet netID means custom compilation is required to communicate with mainnet I2P routers over NTCP2
<tini2p_gitlab> I haven't added the necessary build for mainnet because tini2p isn't ready yet, and I don't want to encourage usage which may be disruptive/harmful to the network
<tini2p_gitlab> I also began work on ElGamal tunnel building (basic encryption/decryption of BuildRequestRecords is more-or-less done)
<tini2p_gitlab> 2: What's next
<tini2p_gitlab> will continue work on ElGamal tunnel building
<tini2p_gitlab> the next steps are:
<tini2p_gitlab> - serializing/deserializing ElGamal BuildRequestRecords (slightly different from ECIES records)
<tini2p_gitlab> - deriving keys for ChaCha tunnels using the ElGamal shared secret
<tini2p_gitlab> - refactoring the router context to handle ElGamal tunnel building
<tini2p_gitlab> maybe it will go quickly, but it could take a couple weeks
<tini2p_gitlab> will also work on creating test vectors for i2pd and Java I2P for cross-impl ElGamal testing
<tini2p_gitlab> will bring up KDF discussion about deriving record keys using the ElGamal shared secret
<tini2p_gitlab> for AES tunnels, deriving record keys is likely unnecessary, since any saved space would be consumed with random padding
<tini2p_gitlab> for ChaCha tunnels, the saved space is necessary for transmitting the AEAD receive key to each hop
<tini2p_gitlab> the additional 32 bytes for the AEAD key will not fit in the current space allocated for "options/random padding"
<tini2p_gitlab> + the bytes for the options header + flags
<tini2p_gitlab> will also be adding fuzz test drivers for data structures with deserialize methods as I work on other features
<tini2p_gitlab> if the KDF changes for ElGamal records are unwanted/unworkable, ElGamal tunnels will only be able to use AES for layer encryption
<tini2p_gitlab> which would effectively mean any tunnel with one ElGamal hop must use AES layer encryption for the entire tunnel
<tini2p_gitlab> if the KDF changes are accepted, ElGamal tunnels will be able to use AES and/or ChaCha layer encryption
<tini2p_gitlab> for a review of AES layer encryption: https://geti2p.net/en/docs/tunnels/implementation
<tini2p_gitlab> and ChaCha layer encryption proposal: https://geti2p.net/spec/proposals/153-chacha20-layer-encryption
<tini2p_gitlab> 3: Questions / comments
<tini2p_gitlab> much love for the lurkers
<tini2p_gitlab> 4: Next meeting time
<tini2p_gitlab> 2019-10-31 18:00 UTC
<tini2p_gitlab> @tini2p_gitlab gavels the gavels like it's never been gavelled before

Logs for the Monero Research Lab Meeting Held on 2019-10-14

Mon, 14 Oct 2019 00:00:00 GMT

Logs

<sarang> GREETINGS
<suraeNoether> howdy!
<sgp_> Hello
<sarang> Small crowd today, apparently
<sarang> Even so, we carry on
<sarang> Let's move to ROUNDTABLE
<sarang> I've been working on a few things this past week
<sarang> First is getting caught up with the usual literature review
<sarang> Second was finalizing things for World Crypto Conference and some background research associated to that
<sarang> Third was getting balance proofs working in Triptych, which is now successful
<xmrmatterbridge> <serhack> hello
<sarang> This means that Triptych now supports a single proof showing all spends, correct key image construction, and balance
<suraeNoether> nice!
<sarang> How about you, suraeNoether?
<suraeNoether> i've been furiously debugging my matching code as my primary task. there are some persistent problems. i wanted to finish this weekend but it didn't happen
<sarang> Earlier you had indicated some known bugs... are these the same?
<suraeNoether> no... every problem i solve reveals like... a small handful of new bugs, but the newer and newer bugs are becoming less frequent and less severe
<suraeNoether> it *feels* like there's a single problem lurking that will cause the house of cards to stop falling down
<suraeNoether> i'm very close.
<suraeNoether> i really wanted it to be today
<suraeNoether> i'm taking a break later today to read sarang's WCC talk (sorry for the delay on that) and I am taking a break later today to work on *literally anything else*
<suraeNoether> i'm very frustrated with this project
<sarang> Are the known bugs documented anywhere, so others might assist you?
<suraeNoether> i'm sure a lot of community members are also frustrated, but i this is nearing completion
<suraeNoether> no
<suraeNoether> "test X not working for unknown reason" is not a helpful document to write
<sarang> Hmm ok
<sarang> Well, I selfishly hope you will take time off that project today and review my talk :D
<sarang> Perhaps it will also help you clear your head
<sarang> Does anyone else have interesting research to share as well?
<sarang> In that case, let's go ahead and discuss ACTION ITEMS first, and then any lingering questions
<sarang> First, I have an efficient verifier for the inner-product argument in IACR/944 that I've been meaning to implement in kenshamir[m]'s Rust code, which will be useful for benchmarking... that's in progress but with some algebra problems that I'm working out
<sarang> Second, Triptych needs plenty more work: key aggregation, better Fiat-Shamir challenges, and some questions on proof elements and efficiency
<sarang> Third, I want to see if it's possible to backport some of the new RCT3 changes to the older version without using spend aggregation, to check the resulting efficiency
<sarang> and that's about it for now
<sarang> suraeNoether: ?
<suraeNoether> pushing this commit once my code is flowing. reading your WCC talk. catching up on tryptychychch
<sarang> It definitely remains to be seen how efficient we can make Triptych... but as I mentioned last week, the underlying changes to the Groth proving system are very interesting regardless
<sarang> and, as before, there is no security model for it yet
<sarang> All righty, are there other questions on research?
<sarang> This meeting has gone quite quickly
<sarang> Oh, one note about what Isthmus brought up last week regarding transaction keys and subaddresses
<sarang> It is apparently still the case that transactions to only standard addresses retain a single transaction key
<sarang> Mandating separate transaction keys for all outputs would add 32 bytes to each additional output
<sgp_> Standard = 4?
<sarang> but we're already saving > 32 bytes per output after the last change to the Pedersen mask format anyway
<moneromooo> Could there be a way to deterministically generate keypairs in such a way that the sender generates the secret keys from a seed, the recipients generate the pubkeys ? I think Bitcoin has such a scheme for generating addresses.
<moneromooo> And hopefully the seed is <= 32 bytes :)
<sarang> Well, a big selling point of subaddresses is the efficient scanning across all addresses at once
<sarang> Isthmus: only need to read up a few lines
<moneromooo> Would such a scheme invalidate the efficient scanning ? It seems doubtful since the tx keys are currently arbitrary.
<sgp_> How much effort is it to scan and see what proportion of transactions are only to standard addresses?
<sarang> sgp_: to get a distribution of how common subaddresses are?
<Isthmus> @sgp_ I think that @n3ptune accidentally did that recently
<Isthmus> Lemme see if the plots are on GitHub anywhere
<sgp_> sarang: essentially yes
<sarang> Presumably this would be affected by which large players (like exchanges) support them
<sgp_> Thanks Isthmus
<Isthmus> https://github.com/noncesense-research-lab/tx\_extra\_analysis/blob/master/tx\_extra\_viz.ipynb
<sarang> 404
<Isthmus> Oh, private repo. Lemme grab the juicy parts
<Isthmus> This might be the relevant one
<Isthmus> https://usercontent.irccloud-cdn.com/file/LgrrzOIS/image.png
<Isthmus> I suspect the diagonal is transactions that include a subaddress, while the horizontal bands are primary-only
<Isthmus> Though I'm open to alternate interpretations
<moneromooo> Oh I get it. The fast lookup would still exist, but verifiers would have to generate pubkeys, and *that* might be slow.
<sgp_> Thanks
<Isthmus> If that is the case, then I can slide a window over time and calculate fraction of transactions that appear to include no subaddresses
<sgp_> I'm not the one who can say yes or no to that :/
<sarang> Probably worth bringing up at the next dev meeting to see what others think of it
<moneromooo> It is trivial to know whether >= 1 subaddress was used as an output in a tx.
<moneromooo> If that was the question...
<moneromooo> Oh wait. Maybe not, there's some funky going on with change being treated differently...
<sgp_> A more meta question: how did this happen? What could have been done differently to help prevent this from happening?
<sarang> That's probably a question for someone like stoffu who was more directly involved in the code
<sarang> I suspect space saving was one consideration
<sgp_> knaccc too?
<sarang> but it's quite minor for the most part
<Isthmus> @sgp_ meta answer: we rolled out a new feature that:
<Isthmus> 1) you could tell use from blockchain as external observer
<Isthmus> 2) was optional
<Isthmus> Either one of those alone is ok, but together we end up in this situation.
<sgp_> I always assumed 1 wasnt the case. I was very misinformed and thus misinformed others
<Isthmus> Yeah, I think we're all just putting 2+2 together on that now
<sarang> OK, something to discuss at next dev meeting, then
<sarang> Are there any other topics to discuss for this meeting?
<Isthmus> Oh yea, lemme grab a link
<Isthmus> The CryptoEconSec paper by hasu and all is very interesting, and parts are relevant to both Monero and our lock time conversation
<Isthmus> *et al
<Isthmus> I definitely recommend reading it. Very approachable.
<Isthmus> Here's the writeup: https://uncommoncore.co/research-paper-a-model-for-bitcoins-security-and-the-declining-block-subsidy/
<Isthmus> And here is my analysis: https://twitter.com/Mitchellpkt0/status/1183581226357014528
<Isthmus> I won't rehash it all here. Just take a pass through on your next commute. :- )
<sarang> Thanks Isthmus
<sarang> Any last questions before we adjourn and continue discussions?
<sarang> Righto, thanks to everyone for attending!

Logs for the Community Meeting Held on 2019-10-12

Sat, 12 Oct 2019 00:00:00 GMT

Logs

<sgp_> yes indeed
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/400
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support. Fun fact: we’ve been doing these since issue #79.
<sgp_> 1. Greetings
<OsrsNeedsF2P> I like fun facts
<el00ruobuob> Hi!
<rottensox> o/ the rottenest sox present.
<rehrar> here'
<needmonero90> Hey all
<sgp_> welcome everyone
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com/
<sgp_> Reminder that 0.15 is expected on October 31, with the scheduled protocol upgrade on November 30: https://web.getmonero.org/2019/10/01/announcement-release-0-15.html
<sgp_> There's a help thread in https://reddit.com/r/monero if you need assistance or have specific questions
<sgp_> Monero Talk interviewed Brad Mines, Daniel Krawisz, and spesmonerujo in the past two weeks: https://youtube.com/c/monerotalk
<monerobux> [ Monero Talk - YouTube ] - youtube.com
<sgp_> Are there any outstanding questions regarding the upcoming update, or does anyone have community (non-workgroup) updates to share?
<OsrsNeedsF2P> I'm planning on releasing a 1.0 version of MoneroTipsBot soon
<needmonero90> I'm curious which exchanges are still in limbo wrt subaddresses
<OsrsNeedsF2P> Oh u first ^
<needmonero90> as usual, I would like an updated listing of who needs contacting, so we can rally people to shoot off pings
<needmonero90> As the network upgrade approaches, this becomes more and more important :)
<sgp_> indeed. needmonero90, want to take the initiative? :)
<needmonero90> I already am with binance actually
<needmonero90> I've been keeping in contact with them regarding the deadline
<sgp_> Polo is good I know. What about Kraken? Shapeshift? MorphToken?
<needmonero90> debruyne any idea who is left?
<rottensox> TradeOgre. :-)
<mooman12> tradeogre don't use unencrypted payment id do they?
<rottensox> .shrug
<monerobux> ¯\_(ツ)_/¯
<ErCiccione[m]> Hi
<needmonero90> hi
<sgp_> not sure about Bitfinex either
<sgp_> maybe a thread on r/xmrtrader is best for this honestly
<needmonero90> I heard the mods there are really strict
<needmonero90> (I'll make a post)
<sgp_> like we others do a thread for mining pools on r/moneromining
<OsrsNeedsF2P> ^_^
<needmonero90> Ok, on to osrs's question. I'll make an exchange post on xmrtrader today.
<sgp_> yeah I think that's best
<mooman12> Snipa: does supportxmr still have anyone mining to an address with payment id?
<sgp_> oh that's a good question
<sgp_> could email them and tell them to stop if they are registered
<rottensox> sgp_: https://imgur.com/cLtds0r.png
<rottensox> Bitfinex still does have payment ID. Took it from my account right now.
<sgp_> yuck. add one to the list to pester
<sgp_> thanks rottensox
<mooman12> are they even solvent? :v
<rottensox> Anytime.
<Snipa> Probally, I can pull the logs and check. We need to make a deprecation message, but the mining clients don't usually allow for it.
<sgp_> Snipa: let us know if there's some way to help out there. It's a clever way to reach people in a way that we typically don't
<Snipa> Traditionally, M5M and I will update the main pool page with notices/announcements of this nature.
<rottensox> sgp_: Morph has it too - https://imgur.com/HzaBl7I.png
<sgp_> anything else on this topic?
<el00ruobuob> Kraken seems to use integrated addresses
<sgp_> rottensox: that's optional for refund, so I think it's not quite as important. It's more important when depositing Monero
<rottensox> okie.
<sgp_> el00ruobuob: yeah, I believe they do
<sgp_> I can send a quick message to Morph to make sure they know
<sgp_> endogenic: is MyMonero pulling payment ID support in the wallet? (he can answer later if not here)
<sgp_> Anything else on this topic?
<sgp_> summary: check r/xmrtrader for a list soon^TM
<Snipa> If there's anything else we can do on the pool side, let me know.
<sgp_> thanks Snipa, great to see you around here :)
<Snipa> RandomX is throwing some bigger wrenches into the original pool designs, so everyone's sort of working things out still, but notifications are something we can sort-of do.
<sgp_> 3. CCS updates
<sgp_> There are no new proposals in ideas or funding required. Any CCS comments before we move on?
<sgp_> I'll take the silence as a no
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> luigi1111w merged a considerable number of changes the past few weeks to substantially improve Monero’s stability. vtnerd submitted new mempool code that handles i2p transaction broadcasts.
<sgp_> b. Localization workgroup
<sgp_> ErCiccione[m]: you have the floor
<ErCiccione[m]> yep
<ErCiccione[m]> Not much to report, Weblate is finally online and translators already started to work. Everything seem to work without issues and contributors seem to appreciate the new platform.
<ErCiccione[m]> see: translate.getmonero.org
<ErCiccione[m]> i encourage everybody who can to help translate release 0.15 of GUI and CLI
<ErCiccione[m]> Also,
<ErCiccione[m]> while preparing weblate for GUI and CLI i tested it for the website. We can use it. Not for the complete website but at least for the main part (the LANG.yml files)
<ErCiccione[m]> i will make some more testing on my private instance and see how it works out, but i'm optimist. It will make much more easier to maintain the existen translations, but won't have much inpact about adding a new one. Still a big improvement.
<ErCiccione[m]> i think that's it
<el00ruobuob> Great!
<sgp_> thanks ErCiccione[m]
<ErCiccione[m]> for more info about how weblate works and the feature it has. there's the guide: https://github.com/monero-ecosystem/monero-translations/blob/master/weblate.md
<sgp_> very helpful
<ErCiccione[m]> i would like to say a couple of things about the website, even if it's not technically a workgroup, if it's ok, sgp_
<sgp_> sure
<sgp_> thanks for taking on that initiative btw, it's hugely important
<ErCiccione[m]> my pleasure! :P
<ErCiccione[m]> btw
<ErCiccione[m]> moneromooo proposed to change the header of the website adding "A Reasonably" before "Private Digital Currency
<ErCiccione[m]> "
<ErCiccione[m]> see: https://repo.getmonero.org/monero-project/monero-site/merge\_requests/1136
<rehrar> down
<ErCiccione[m]> the thing is that that particular header was discussed quite a lot before it was chosen, so i thought was best to discuss that here
<sgp_> I'm also ok with "a reasonably private digital currency for all"
<ErCiccione[m]> i like it too
<el00ruobuob> i like it too
<rehrar> i like it too
<ErCiccione[m]> ooow <3
<OsrsNeedsF2P> In the privacy world, phrases like that are super popular, for instance I2P really drills in a similar idea
<OsrsNeedsF2P> But it looks absolutely terrible to the uneducated user, and IMO, drives them to a less safe alternative
<sarang> Terms like "private" and "untraceable" claim a lot
<rottensox> ^
<needmonero90> Private^[1] Digital Currency
<sarang> and depend highly on risk and threat models
<sgp_> "xyc coin says it's more private," but they will say that anyway
<OsrsNeedsF2P> But what about terms like "The most private [cryptocurrency]", @sarang
<rehrar> we really need to remove untraceable
<rottensox> no?
<rottensox> lol.
<needmonero90> thats arguable even, osrs
<needmonero90> "but muh piratechain has mandatory zksnarks"
<sgp_> that's why I like the focus on "for all" for marketing's sake
<Mochi101> Did you two make up and become lovers now?
<sgp_> it's the only privacy-focused option someone can reasonably use right now
<sgp_> from a UX perspective
<rehrar> and even that is questionable :D
<sgp_> so overall, changing this phrasing is more accurate, and shills are going to shill other stuff regardless of what it says
<Mochi101> obfuscated ?
<rehrar> yeah, but how does the word "reasonably" look on the website?
<rehrar> I'll give it a look
<rehrar> in terms of spacing and stuff
<Mochi101> private and obfuscated transactions
<rottensox> https://twitter.com/xmranon/status/1179771671303065600
<monerobux> [ xmranon on Twitter: ""Bitcoin is so much easier to use than #Monero" is such a bullshit argument. ios.cake android.monerujo web.mymonero" ] - twitter.com
<sgp_> imo, obfuscated means nothing to non-cryptrocurrency-focused people
<rehrar> in other news, I am almost done with a Monero pumpkin picture that sarang requested
<sarang> That's fantastic rehrar !
<el00ruobuob> rehrar, it looks bad with the video that large.
<sgp_> what about the Monero pumpkin carving?
<rehrar> it will be available for purchase for recurring payment of 0.1 XMR for monthly licensing
<sgp_> for the sake of time, we should move on from this specific topic. Thanks for mentioning it ErCiccione[m]
<sgp_> Do you have anything else to talk about related to the website?
<rehrar> el00ruobuob: opinions need to be justified
<sgp_> el00ruobuob: screenshot + comment on Gitlab please :)
<rehrar> oh wait
<rehrar> you mean the changed version, not the version as is
<rehrar> got it, I'll check
<ErCiccione[m]> sgp_: yes, user guides and dev guides need to be updated. I would totally support a CCS with that goal
<sgp_> oh for sure
<ErCiccione[m]> or anybody who wish to pick up some of the issues labelled help needed: https://repo.getmonero.org/monero-project/monero-site/issues?label\_name%5B%5D=%E2%9B%91%EF%B8%8F++help+needed
<el00ruobuob> done sgp_
<ErCiccione[m]> that's basically it. Please comment on mooo's issue about that header, because if we want to change it completely, that should be an entire different discussion
<sgp_> Thanks ErCiccione[m]
<sgp_> I'll pay more attention to GitLab
<sgp_> c. GUI workgroup
<sgp_> xiphon made improvements to remove long payment IDs and to better handle nodes in simple mode.
<sgp_> d. Monero Research Lab
<sarang> Hi
<sgp_> hello sarang, take it away!
<sarang> There's been a lot of work on transaction protocols from me, and on graph analysis frameworks from suraeNoether
<sarang> I'll be joining rehrar and Daniel Kim at a developer conference later this month, where I'll talk about transaction protocols and how fungibility and privacy come into play
<rottensox> :-D
<sarang> I'm happy to answer particular questions, but don't want to bore with details on protocol design here
<rehrar> oof. More Vegas.
<sarang> Looking forward to speaking to a develop audience
<sarang> *developer
<sarang> Of note is that RCT3 was updated fairly recently, as was Lelantus
<sarang> and rockstart contributor RandomRun had an idea on extending a particular Groth proof that I've been working on
<sarang> we're calling that protocol-in-progress Triptych
<sarang> (no security model for it yet, though)
<sgp_> thanks sarang, anything else?
<sarang> Those are the broad topics of research interest lately
<nioc> catching up, I thought bittex was also using unencrypted PIDs
<nioc> bittrex
<sarang> shapeshift still uses them too, afaik
<rottensox> We moved on, but I can quickly log in and check.
<sgp_> any final updates? we will skip over open ideas for time
<sgp_> last comments
<rehrar> ne
<sgp_> was a good meeting everyone :)
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 26 October at 17:00 UTC. The next Coffee Chat will be on 19 October at 16:00 UTC.
<sgp_> Stick around after the meeting for a new initiative! We’re playing 0 A.D., an open-source, real-time strategy game. This event helps promote the community by focusing on something other than Monero. We hope you join us and have fun watching us mess around! https://www.youtube.com/watch?v=DqIJmY3cOO4
<monerobux> [ 0 A.D. Territory Rush with the Monero Community - YouTube ] - www.youtube.com
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Overview and Logs for the tini2p Dev Meeting Held on 2019-10-10

Thu, 10 Oct 2019 00:00:00 GMT

Logs

<tini2p_gitlab> greetings
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> alpha release is live!
<tini2p_gitlab> master branch is tagged for alpha release 0.0.1
<tini2p_gitlab> there are likely still bugs, and refactors that need to be done
<tini2p_gitlab> but all the pieces are in place for the core router
<tini2p_gitlab> tini2p is capable of end-to-end sessions over I2P tunnels
<tini2p_gitlab> tini2p is NOT currently capable of communication with Java I2P, i2pd, or ire routers
<tini2p_gitlab> in the coming weeks, I will be working on ElGamal tunnel building to enable communication with Java I2P, i2pd, and ire
<tini2p_gitlab> point-to-point communication over NTCP2 is likely possible with Java I2P/i2pd/ire, but I haven't tested it at this point
<tini2p_gitlab> anyone interested is welcome to pull the latest master, and test stuff out
<tini2p_gitlab> any testing is very much appreciated
<tini2p_gitlab> release is three months past the initial planned alpha, and I am grateful for the support and patience
<tini2p_gitlab> my goal is to add client functionality, a fuzzing test suite, and core refactors by December
<tini2p_gitlab> will have a longer meeting next week
<tini2p_gitlab> 2: Next meeting time
<tini2p_gitlab> 2019-10-17 18:00 UTC

Logs for the Monero Research Lab Meeting Held on 2019-10-07

Mon, 07 Oct 2019 00:00:00 GMT

Logs

<sarang> GREETINGS
<suraeNoether> howdy!
<ArticMine> hi
<sarang> I suppose we can jump into ROUNDTABLE discussion
<sarang> suraeNoether: ?
<suraeNoether> sure; I've been working on my matching code. I fixed a few bad unit tests, i fixed a problem that was making the code take O(n^2) time and now it takes O(n) time... the challenger code and the parameter space explorer code are nearing completion, and my simulations are still misbehaving
<sarang> Any ideas what exactly is misbehaving?
<suraeNoether> i'm also beginning to read about an idea by randomrun and thinkinga bout security proofs for it
<suraeNoether> well, no, that's what's strange. i have unit tests that check things like "check that the correct number of nodes are added to the graph", and they all pass those things... but then the integrated simulation as a whole produces a bad output file
<suraeNoether> which is why i posted the stupid gif the other day of "two unit tests, no integration test"
<sarang> I see
<suraeNoether> but i'm working on it, and i have a few clues... and six more unit tests i'm coding up this afternoon
<sarang> excellent
<suraeNoether> i also want to bring up the topics that isthmus posted on github
<sarang> Let's save those until he returns
<suraeNoether> but we should hold off till the end of the meeting to chat about those
<suraeNoether> *nod* he may not return, though, and we should chat about it in public today eventually either way
<sarang> I've worked on a few things this past week
<sarang> I collaborated with Aram on a Lelantus update: https://lelantus.io/enabling-untraceable-anonymous-payments.pdf
<sarang> It seems to solve the sender tracing issue, but at the cost of proper one-time addressing
<suraeNoether> hmm *taps chin*
<sarang> Trying to fix both at the same time keeps running into a wall involving Pedersen generators
<suraeNoether> i'm very interested to spend some time catching up on that trade-off
<sarang> So we're looking at possible ways to use Schnorr representation proof tricks here... nothing so far though
<sarang> Aside from that, I updated the RCT3 proof-of-concept code and spacetime analysis to reflect the new version of the preprint that was released
<sarang> They compress the spend proof across inputs, but this incurs some major cost in padding inputs
<sarang> Unfortunately, undoing that compression doesn't play nicely with their integrated balance proof
<sarang> As in, (number of spends)*(size of anonymity set) must be a power of 2, or padded to one
<suraeNoether> iirc lelantus originally used a tree structure, yeah? is that why?
<sarang> Is what why?
<suraeNoether> is that why they require padding inputs to powers of two?
<sarang> RCT3, not Lelantus
<sarang> It has to do with the inner-product argument that it uses for compression
<suraeNoether> gack, got them confused~ nevermind, i retract my question
<suraeNoether> ah, that makes sense too
<sarang> It would be nice to get separate spend proofs if only to avoid this padding issue
<sarang> but that would require redoing security proofs etc.
<sarang> Finally, I've been working more on some ideas RandomRun had for Triptych involving balance proofs and multiple spends
<sarang> I have a simple version of the Groth proving system that supports proving knowledge of multiple commitment openings to zero, along with linking
<sarang> but haven't done any security proofs (in particular, I have some questions about the uniqueness requirements on certain proof elements)
<sarang> Getting balance integrated is tricky, and that's what I'm working on now
<suraeNoether> is there any write-up anywhere you and/or RR are willing to share with the public, or is this still too much "in prep"?
<sarang> His ideas are listed in the GitHub issue here: https://github.com/monero-project/research-lab/issues/56
<sarang> and the work-in-progress code is here, but very unfinished: https://github.com/SarangNoether/skunkworks/tree/lrs/lrs
<suraeNoether> gotcha
<sarang> and very probably insecure as written
<sarang> Right now it's just at the playing-around-with-the-algebra stage, to see what's useful/possible
<suraeNoether> it's good to clarify that before some other coin goes and implements it :P
<sarang> Anyway, kudos to RandomRun on some really clever ideas to extend that Groth proving system
<sarang> TBH it's probably worth a short paper on its own
<sarang> Right now (if proven secure, mind you) it turns Groth's idea for a ring signature into a linkable ring signature
<sarang> If the balance proof extension works, then we're really cooking
<sarang> Efficiency TBD
<sarang> While we wait for Isthmus to return, I can wrap up by saying my ACTION ITEMS for the week are trying to get balances working in Triptych, finishing a presentation on transaction protocols, and getting caught up on some lit review
<suraeNoether> good timing bruh
<sarang> Isthmus: we didn't talk about your items at all
<sarang> Care to go over them now?
<Isthmus> Sure
<Isthmus> One of the things I've been pondering about is how to assess the appropriate (safe) lock time
<Isthmus> Here is one possible framework for the conversation: https://github.com/noncesense-research-lab/lock\_time\_framework/blob/master/writeup/lock\_time\_framework.pdf
<Isthmus> Since the lock time only needs to be longer than reorg events, we can approach the question systematically by enumerating the list of things that cause alternative blocks, assessing the maximum plausible length of alternative chains that they could produce, and buffer that with a safety term
<sarang> Enumerating the expected sources of reorganizations is a good idea, now that you have some empirical data on latency-based reorgs
<Isthmus> My goal is to take the conversation out of the realm of intuition, towards addressing specific things that we can model/discuss/etc. :- )
<sarang> I seem to recall some talk a long while ago about individual nodes that had observed much longer reorgs, but I assume these were not global?
<sarang> (for some definition of global)
<Isthmus> Well, that was back when there were ASICs on the network
<suraeNoether> i'm inclined toward T2 or T3. the selection of an enforced lock time to ban inarguably-too-short txn times is easy and has an immediate benefit to the system. analysis paralysis while selecting an "optimal" lock time isn't desirable, and having the enforced lock time in place - even if we don't change the current lock time - is critically important
<Isthmus> Yeah, (should we enforce lock time?) and (how long should lock time be?) are two distinct questions
<suraeNoether> so, here's the deal
<sarang> There seemed to be good support for consensus enforcement of whatever value is chosen
<sgp_> Is it worth exploring privacy implications as well? It could be that the longer the lock time, the better it is for network privacy to some extent
<suraeNoether> sgp_: this is especially true if the lock time is longer than the median spend-time
<suraeNoether> but that's not a desirable lock time
<suraeNoether> for obvious reasons
<suraeNoether> so, the deal i'm thinking is that it's easy to discern what is *unacceptably long* or short in lock times
<suraeNoether> a lock time of two blocks is too short, a lock time of 90 days is too long, for sure
<sgp_> I don't think it needs to be the main topic (chain re-orgs are more important imo), but it's worth considering
<sgp_> I think we will have a tough time reducing it from 10 honestly for UX reasons
<suraeNoether> i guess my question is
<suraeNoether> does anyone have an argument in favor of using a value *other than 10*
<sgp_> *tough time increasing it
<sgp_> suraeNoether: I would like to justify a smaller number for UX reasons if possible
<suraeNoether> i wouldn't dare lower it further than 10
<sgp_> Isthmus's document outlines a basic framework for coming up with a number
<sgp_> suraeNoether: based on what though?
<suraeNoether> or let me rephrase that, because "i wouldn't dare" is a bit dramatic
<suraeNoether> sgp_: well, we've witnessed many re-orgs length longer than 10. they are downright *common*
<suraeNoether> moreover, spend-times that are lower than 20 minutes are *extremely* noticable in a txn graph
<suraeNoether> if a sequence of very fast chained txns occur in a row, you can almost bet your ass that they're the same person churning.
<ArticMine> The question in my mind is what is an acceptable risk probability for T2, and T3
<suraeNoether> ArticMine: that was the question that popped into my mind
<sgp_> that's what I was referring to from the privacy angle
<suraeNoether> *nod*
<sarang> Do you happen to know the corresponding threshold for Bitcoin's choice of typical lock time?
<sarang> I don't, off the top of my head
<suraeNoether> ^ sgp_ or ArticMine or isthmus?
<sgp_> nope
<suraeNoether> hm
<Isthmus> I'm avoiding commenting on any particular numbers until we decide on a framework for discussing
<suraeNoether> personally i would find it helpful to have those numbers in deciding the framework
<sarang> Here's a writeup that I'd seen before: https://bitcoil.co.il/Doublespend.pdf
<dEBRUYNE> sarang: Bitcoin has no lock time for normal transactions
<dEBRUYNE> You can essentially chain unconfirmed transactions
<suraeNoether> dEBRUYNE: thanks that's important to know, too. :P
<sarang> Page 8 shows some example data based on hashrate and confirmations using Bitcoin as an example
<Isthmus> Chicken/egg, don't need numbers for the framework
<sgp_> I see your point Isthmus
<Isthmus> Does buffering the lock time to be greater than the worst case plausible scenario make sense as a framework?
<sarang> dEBRUYNE: but most clients use the 6-confirmation rule for "confirmed" transactions
<suraeNoether> Isthmus: if we did this, our lock time would have to be >> 23
<sarang> I was curious about that particular choice's assumptions
<suraeNoether> iirc we saw a 23-block reorg recently
<dEBRUYNE> It is a soft rule essentially
<dEBRUYNE> You can easily overrule it
<sgp_> Let's consider a 3 standard deviation scenario
<sarang> dEBRUYNE: right, but I'm simply curious to make a comparison
<Isthmus> Lock_time = Safety*(max(len_latency, len_51%, len_selfish...))
<Isthmus> So if you're saying that would be 23
<Isthmus> You're saying lock
<Isthmus> lock_time = 23
<Isthmus> What are you using as your value for the Safety term?
<Isthmus> And which term in the max are you looking at?
<suraeNoether> ah, good questions
<Isthmus> I never suggested any value for the safety term, so I'm trying to figure out how we got to 23 :- P
<suraeNoether> no no
<suraeNoether> that's not the 23
<suraeNoether> i'm saying max(...) > 23, because we've seen 23 within the last year
<Isthmus> Woah, I totally missed that
<Isthmus> When?
<suraeNoether> so whatever number we select needs to be > safety*23
<Isthmus> We can fish it out of the NRL logs
<sarang> That was from a single node report, no?
<suraeNoether> sarang: *shrug* even if it was 15, or 12, safety*12 for any safety > 1 is going to be bigger than 20, generally
<sgp_> That's why I think looking at all reogs and using 3sd longer than normal or something like that is a more practical number
<suraeNoether> my point is: if we look at how common re-orgs are, and if we want to protect against those, we need unreasonably long lock times that risk slowing down the monero economy
<sarang> sgp_: all observed reorgs, regardless of assumed origin (latency, high-hashpower entity, etc.)?
<sgp_> sarang: I would need to go deeper into the numbers, but I just want to see what the numbers are without some of the outliers
<Isthmus> I've been out of the loop, so I'm not disagreeing. But wowza, I hadn't seen anything *global* greater than length 2 since we switched to CryptoNoteR
<suraeNoether> sgp_: *nod* we should look at the distribution of re-org times, though, and decide on a rigorous statistic instead of picking 3*stdev, but your point is 100% correct
<sgp_> that's the overall point I want to convey
<ArticMine> I suggest a risk based approach. Starting with who bears the risk?
<sgp_> eg: if there was 1 reog at 20 and every other one is <3, that's important to know
<sarang> I think using data and methods from the Bitcoin community for risk estimates of high-hashpower entities would be useful as one data point
<sgp_> Isthmus: in terms of the framework however, I think we need to add some privacy implications
<Isthmus> True, though the Gini coefficient for BTC hashrate is probably much more lopsided that Monero's distribution
<sgp_> shrinking the lock time likely has adverse privacy implications
<sgp_> and it also have positive UX implications
<ArticMine> There are some significant differences in Bitcoin: 1) Great Firewall of China 2) 10 min blocks
<Inge-> Better UX at the cost of privacy sounds like ... not-Monero.
<Isthmus> I suspect (and I may totally backtrack this later...) that the fact we flip coins every 2 minutes rather than every 10 minutes may mean we reach stable equilibrium faster
<sgp_> Inge-: it's about the tradeoff. No one would use a coin with a lock time of 100 days
<Isthmus> SLOWNERO
<Isthmus> YESSSS
<suraeNoether> ^ nah, it's like using a smooth/exponential curve for a mortgage versus discretized timesteps using monthly annualization formulas: one approximates the other, but you converge at the same rate
<suraeNoether> wrt 2 minus vs 10
<suraeNoether> okay, let's operate briefly assuming that the longest reasonable "natural" re-org is 6 blocks. it's smaller than our current lock time, longer htan isthmus' global data, and matches satoshi's arbitrary selection.
<suraeNoether> if we pick safety = 2 or 3, we are still looking at 12 or 18 lock time, not shorter than 10.
<suraeNoether> now, if we recall, block re-orgs don't always happen naturally and can take place due to adversarial behavior, using the longest one in history is incomplete
<suraeNoether> why? the attacker may hold off, biding their time on a real attack, until their attack power is most likely to lead to success. Seeing only a few re-orgs of length 2-6 in the entire history of monero doesn't mean that an adversary can't force a 30-length re-org, as an example, so while the monero archival stuff that isthmus has been running is helpful
<suraeNoether> i dunno, i feel like this is an unnecessary rabbit hole
<sgp_> "past performance does not indicate future results." But I still like seeing how the network performs under normal scenarios
<suraeNoether> or at least: why try to select a number other than 10 before the next hard fork?
<suraeNoether> sgp_: well... *historical* scenarios anyway
<ArticMine> So do we just stay with 10?
<sgp_> let's agree on the framework first :)
<sgp_> if we don't agree on anything, the status quo will remain (10)
<Isthmus> Oh totally NOT trying to adjust this by the next fork
<Isthmus> This is going to take us like 3 months to discuss
<suraeNoether> oh, then if that's the case
<Isthmus> I was just responding to the ping from last meeting
<Isthmus> I think enforce at 10 for this upcoming upgrade
<Isthmus> Ahhahaha
<Isthmus> Re @suraeNoether "this is an unnecessary rabbit hole", As MRL, if we are going to inform lock time, we HAVE to go down three rabbit holes. 1) What's the longest plausible natural reorg, 2) What's the longest plausible attack, 3) what margin of error do we want?
<Isthmus> I literally don't think there's a way to address the question if we're not willing to consider these
<Isthmus> (I think... there may be some clever way to circumvent this...)
<suraeNoether> i'm saying there is not a way to address this problem
<Isthmus> What do you think about additive safety term versus multiplicative?
<sgp_> suraeNoether: I agree on a theory level, but not on a practical level
<suraeNoether> sgp_: yeah, i'm saying theoretically, there is no optimal solution. in practice, there will be a whole host of solutions that are "good enough" that have different tradeoffs between them depending on threat models
<sgp_> ....have you worked on Monero before? lol
<suraeNoether> this is why isthmus is using the word plausible here
<suraeNoether> ...
<sgp_> yeah it's a tradeoff, but we need to pick one, and there's potential reason to believe (with evidence) that a number other than 10 is best
<suraeNoether> *cough* there is no best solution
<sgp_> I'm open to changing the number with the right evidence
<Isthmus> Maybe we can circle back to this next week with more recent numbers from the archival network regarding global events
<ArticMine> Is it not possible to take a risk based approach for a framework?
<Isthmus> @ArticMine yes, please share ideas :- )
<ArticMine> 1) % hashrate of attacker
<ArticMine> 2) Who bears the impact
<ArticMine> 3) Type of impact ie double spend, privacy
<ArticMine> One should be able to derive risk provabilities
<Isthmus> Some of #1 may be captured in Eq 3. Or at least I tried.
<Isthmus> https://usercontent.irccloud-cdn.com/file/iRNSWEPW/image.png
<sarang> Again, that Bitcoin-related paper does this type of hashrate-threshold analysis
<ArticMine> Yes this is the type of analysis I mean
<suraeNoether> 1) lock times > 50 or < 10 are extremely bad ideas for opposing reasons.
<suraeNoether> 2) This leaves a narrow band of a half of a single order of magnitude. not a lot of wiggle room.
<suraeNoether> 3) going from 10 to 15 is extremely unlikely to have a dramatic or concrete impact on privacy; this is a 10 minute difference when we are speaking of distributions with medians around a day and a half
<suraeNoether> 4) Going from 10 to 40 is going to have huge impacts on our economy, and would have to be justified by a veritable mountain of evidence
<suraeNoether> i look at this as willfully entering into analysis paralysis just because we have the data to answer questions about some very specific hypotheses
<sarang> In the interest of time, may we table this and return when folks have had a chance to review the relevant analysis?
<sgp_> yes please
<sarang> Isthmus had one other item to discuss
<Isthmus> So, I might not have 100% of the technical details right, so feel free to jump in with corrections:
<sarang> It was the question of tx pubkey representation, since its use is different between primary and subaddresses
<Isthmus> Yes, that.
<Isthmus> The ability for an external observer to ascertain whether there were any subaddresses included in the construction of a transaction
<Isthmus> Leaks information about the recipient
<moneromooo> Or sender.
<sarang> For some reason I thought that unique pubkeys were always used now, regardless of address type, to reduce distinguishability... but I need to check this
<Isthmus> Yes, and/or sender
<dEBRUYNE> sarang: Sure, that is fair, but in that instance I would set it to zero
<sgp_> This is the first I am hearing of this
<moneromooo> Actually... I'm not sure. The logic is a bit different for change IIRC...
<suraeNoether> i'm a bit confused...
<moneromooo> I hit that when I tried to add custom change addresses.
<suraeNoether> isthmus do you have a small toy example you could show us?
<Isthmus> Nope, I have no clue how the constructions differ
<sarang> suraeNoether: for subaddress destinations, you use a unique tx pubkey
<Isthmus> Well wait
<Isthmus> Maybe I can fish up an example
<Isthmus> Does tx_extra = (empty) imply no subaddresses were involved?
<Isthmus> In that case I can just hit a block explorer
<sarang> tx_extra stores tx pubkey, which is always included
<suraeNoether> sarang: do you mean the tx pubkey is encoded differently?
<suraeNoether> oh oh
<suraeNoether> yeah
<sarang> yes
<suraeNoether> aha
<Isthmus> Mmmmm
<sarang> It's derived differently for primary and subaddresses
<sarang> It's possible to use only one pubkey for multiple non-subaddress destinations
<sarang> but this implies distinguishability
<Isthmus> ^^^^
<suraeNoether> hmm
<sarang> I thought this had been changed to be unique per destination all the time, for this reason
<suraeNoether> sarang i am beginning to recall this conversation and using a unique key per destination, and we didn't like that it revaled the number of dest addresses, or something...
<sarang> Unique per output, is what I should have said
<sgp_> why would the # of dest addresses be different than the number f outputs, unless someone is doing terrible churn?
<suraeNoether> *shrug* users do dumb stuff all the time for dumb reasons
<sarang> I will confer with moneromooo and examine code to see what the current default behavior is
<Isthmus> +1
<moneromooo> I purposefully shut up after what I said above since stoffu will know for sure, and I don't.
<Isthmus> Cool, I think we can probably stick a pin in this, research over the week, and circle back with more concrete details about distinguishability under the current design.
<ArticMine> +1
<sarang> OK, any other action items before we adjourn?
<sarang> Righto, thanks to everyone for participating

Overview and Logs for the tini2p Dev Meeting Held on 2019-10-03

Thu, 03 Oct 2019 00:00:00 GMT

Logs

<tini2p_gitlab> meet time
<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> hi all
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> an incredible amount of refactoring, and router context impl
<tini2p_gitlab> a lot of the early code that I wrote in the first months of the project has returned to bite me
<tini2p_gitlab> I've spent a good amount of time correcting early design and implementation mistakes
<tini2p_gitlab> work remains on the refactoring front, but it works
<tini2p_gitlab> the real test will come with cross-implementation integration tests (post-alpha)
<tini2p_gitlab> you can see my progress in the context branch: https://gitlab.com/tini2p/tini2p/tree/context
<tini2p_gitlab> I have a bit more work to do cleaning things up, and making the context work without so much manual interaction
<tini2p_gitlab> but tunnel messages, and end-to-end ECIES messaging works over localhost!
<tini2p_gitlab> you can see for yourself here: https://gitlab.com/tini2p/tini2p/blob/context/tests/net\_tests/router/context.cc
<tini2p_gitlab> notably, this test shows an end-to-end ECIES session over inbound and outbound tunnels: https://gitlab.com/tini2p/tini2p/blob/context/tests/net\_tests/router/context.cc#L402
<tini2p_gitlab> you can also see that I'm manually adding tunnels, selecting which router infos are used for tunnel hops, and manually creating the LeaseSet
<tini2p_gitlab> so all that needs to be automated, and wrapped in functions inside the router context itself
<tini2p_gitlab> I'll be working on that for the remainder of today, and pushing an alpha release candidate today or tomorrow
<tini2p_gitlab> I'll leave the alpha candidate open for review for one week before merging into master
<tini2p_gitlab> I've also updated my ECIES impl to *mostly* match what is in the current revision of 144
<tini2p_gitlab> where there are TODOs and otherwise murky content, I've filled in the gaps
<tini2p_gitlab> the proposal is still highly in flux, and I will continue to update my impl until we reach a stable spec
<tini2p_gitlab> over the last few meetings, zzz, orignal, the rest of the I2P devs, and I have been making a lot of progress
<tini2p_gitlab> zzz is dedicating time to the next I2P release, and will return focus to 144 afterward
<tini2p_gitlab> they have stated an estimate for end-of-year for a stable spec/rollout in Java I2P impl code
<tini2p_gitlab> I'm hoping to also be ready with some client code (I2CP, SAMv3, Reseed) around that time to do full integration tests with Java I2P and i2pd
<tini2p_gitlab> (ire too if str4d is ready :)
<tini2p_gitlab> after alpha, I'll also be implementing ElGamal tunnel building, so that tini2p users will be able to build tunnels through existing Java I2P and i2pd routers
<tini2p_gitlab> after that, Reseed
<tini2p_gitlab> between now and next week, I'll be working on more bug fixes, the automation of router context stuffs, and trying to put together instructions for running tini2p routers over a docker testnet
<tini2p_gitlab> docker testnet may wait until after alpha release, since I have net-tests that show full end-to-end communication (even if it is only over localhost)
<tini2p_gitlab> that was 2: What's next
<tini2p_gitlab> :0
<tini2p_gitlab> 3: Comments / questions
<tini2p_gitlab> then that leaves
<tini2p_gitlab> 4: Next meeting
<tini2p_gitlab> will be a short update next week for alpha release: 2019-10-10 18:00 UTC
<tini2p_gitlab> thanks for reading
<tini2p_gitlab> @tini2p_gitlab kick juggles the gaffer like a hacky-sack

Network upgrade and release 0.15

Tue, 01 Oct 2019 00:00:00 GMT

Dear participants of the Monero ecosystem,

A tentative schedule for the upcoming scheduled network upgrade has been set. The schedule is as follows:

October 24 - Code freeze
October 31 - Targeted v0.15 release date
November 30 - Network upgrade

Thus, approximately the 30th of November there will be a scheduled network upgrade on the Monero network. To be sufficiently prepared, a user, service, merchant, pool operator, or exchange should run CLI v0.15 or GUI v0.15. The scheduled network upgrade introduces a few major changes. First and foremost, a new long-term Proof-of-Work algorithm, namely RandomX, will be introduced. Miners therefore ought to upgrade their mining software as well. Second, long payment IDs will be phased out in order to improve privacy and user experience as well as reduce support work for services and exchanges. Third, transactions will now require at least two outputs. Fourth, the ten block (approximately twenty minutes) lock time for incoming transactions will be enforced on the protocol level. Both these changes will improve privacy for the user as well as for the whole network.

To reiterate, following our earlier announcement, long payment IDs will be phased out in this scheduled network upgrade.

Services still utilizing long payment IDs are thus reminded to upgrade to either integrated addresses or subaddresses as soon as possible. If any assistance is required, feel free to contact the Monero dev community at #monero-dev (freenode - IRC, Riot/Matrix, MatterMost).

Note that a preliminary information thread regarding the scheduled network upgrade has been posted on Reddit that contains more elaborate information for users and miners.

Kind regards,

The Monero dev community

Logs for the Monero Research Lab Meeting Held on 2019-09-30

Mon, 30 Sep 2019 00:00:00 GMT

Logs

<sarang> Let's start! Agenda here: https://github.com/monero-project/meta/issues/395 (logs posted there after the meeting)
<sarang> GREETINGS
<mikerah> Hello
<silur> hi
<gingeropolous> hewro
<sarang> Is suraeNoether here?
<suraeNoether> howdy
<suraeNoether> hi, sorry, i'm going to be in and out this morning
<kinghat> o/
<sarang> ok
<suraeNoether> i can do a real quick rundown, but i have to go :(
<charuto> o/
<sarang> In that case, let's jump into the ROUNDTABLE with suraeNoether
<suraeNoether> okay, so
<suraeNoether> matching
<suraeNoether> i've been working on the code, and there were some structural problems, and then a failure-to-push-my-damn-commits failure of my local harddrive
<suraeNoether> it's proceeding... slowly
<suraeNoether> i've been sick a lot :(
<suraeNoether> other than that, i don't have anything to chat about right now
<sarang> What would you say the current state of matching simulations is?
<suraeNoether> i'm hoping to push some code later today on my simulations
<suraeNoether> non-functional
<sarang> And is there any part of it that could/should be worked on by others as well?
<sarang> Or of the corresponding theory?
<suraeNoether> the paper has been available and the codebase is available. the matching code itself is working, but my method of comparing it to some simulated ledger is what is taking awhile.
<sgp_> I'm here from where Sarang should be :)
<sarang> >_>
<suraeNoether> anyone can choose to simulate a ledger *some other way* and run my code
<sarang> Ah ok, got it
<suraeNoether> we even have speed numbers for our matching code from you
<suraeNoether> literally, it's a sanity check and comparing against known churn behaviors
<sarang> Righto, any questions for suraeNoether before he must go?
<suraeNoether> okay guys i have to go. expect a push later today. i'm also going back on solid food later today so who knows, maybe i'll have some burst of inspiration
<sarang> Feel better plz
<sarang> I've been working on several things this past week
<charuto> may good health and good fortune go your way mr surae
<sarang> First, the CLSAG paper is now submitted to Financial Cryptography 2020
<sarang> The preprints on the MRL archive and on IACR are updated
<sarang> Or rather, IACR has been updated and an MR exists for the MRL archive
<sarang> The DLSAG paper was also updated and submitted to the same conference
<xmrmatterbridge> <sgp_> https://eprint.iacr.org/2019/654
<sarang> Second, I'm still working with the author of Lelantus on some modifications to avoid its linking problem
<sarang> We'll have a short writeup soon about one possible way, but it doesn't work cleanly with one-time addresses in the way you might want it to
<sarang> There are some techniques involving Schnorr proofs that we still want to investigate
<sarang> Third, I am finalizing proof-of-concept code and spacetime analysis for the updated RCT3 preprint, which has interesting tradeoffs from the earlier version
<xmrmatterbridge> <rehrar> exciting!
<silur> is the PoC code available somewhere?
<sarang> Besides fixing a big flaw, it aggregates proofs together... this means very small proofs at the expense of some verification
<sarang> Code (danger: not for production) is here: https://github.com/SarangNoether/skunkworks/tree/rct3/rct3
<silur> thanks
<sarang> I'll also run numbers on doing non-aggregated proofs, since that would effectively reverse the spacetime tradeoff
<hyc> ^ bets on which xmr fork deploys it first ...
<sgp_> What is "some verification"?
<sarang> My initial estimates suggest a drop in size from 3.1 kB to perhaps 2.3 kB (2-in-2-out)
<sarang> Verification numbers TBD, but not too bad... considering the original 2-2 single verification estimate was 39 ms on a test machine, batched down to 13 ms
<sarang> Back-of-the-envelope is that batched 2-2 txns will see maybe 5% increase from the old version's time
<sarang> but again, you save 25% on space from the old version
<sarang> Pulling apart the aggregation will improve batching time by reusing generators
<sarang> but then space is back up again
<sarang> There are also some structural differences to the proofs that will mean somewhat higher times regardless
<sarang> More details once I have the actual numbers finished
<sarang> Fourth, my monthly report is posted here: https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/77#note\_7393
<sarang> Fifth, I'll be joining rehrar and Daniel Kim to speak at World Crypto Conference later this month
<sarang> My talk is about the history of cryptographic constructions toward privacy-preserving transactions, and future research directions
<sarang> I'm starting it early to meet their particular deadlines
<xmrmatterbridge> <rehrar> woot!
<xmrmatterbridge> <rehrar> WCC represent
<sarang> I'm trying to think of some good analogies for why terms like "privacy coin" set the wrong baseline
<sarang> For example, you wouldn't visit someone's house and say "oh, you have one of those bathrooms with a door"
<mikerah> Try to frame it in terms of cash
<sarang> It should be the default!
<xmrmatterbridge> <sgp_> "This is a safe car"?
<mikerah> Cash is anonymous, debit/credit cards are tracked by your bank
<xmrmatterbridge> <rehrar> the bathroom door is spot on
<sarang> Anyway, the talk is mainly about cryptography, but I like setting the stage briefly to give motivation for the cryptography
<sarang> And I'm a terrible designer, so I always take longer than expected to make presentations look not-too-horrible :/
<xmrmatterbridge> <rehrar> sarang, bro just send to me?
<sarang> in all its TeX goodness :)
<xmrmatterbridge> <sgp_> your plain presentations are ok imo
<xmrmatterbridge> <rehrar> test, is MM working in this room?
<sarang> hi rehrar
<xmrmatterbridge> <rehrar> bloof
<sarang> So yeah, that's what I've been working on
<sarang> Any particular questions on those items?
<xmrmatterbridge> <serhack> In my opinion, this should depend on audience sarang
<xmrmatterbridge> <rehrar> nah
<sarang> serhack: how so?
<sarang> It's an audience of developers
<xmrmatterbridge> <rehrar> though I have a Research Request (tm) for MRL as a whole
<silur> I'm so missing an audience of developers :D
<sarang> rehrar: go on
<xmrmatterbridge> <sgp_> I have a point to mention after
<sarang> ok
<xmrmatterbridge> <rehrar> It's be asked before with varying degrees of intensity, but I'd like some research done on the 10 confirmation unlock time.
<xmrmatterbridge> <rehrar> 10 confs was kinda chosen arbitrarily? Or did it have reasoning? Research on if this is the ideal number.
<dEBRUYNE> sarang: Have there been any noteworthy developments regarding the CLSAG audits?
<sarang> I see that as really being a question of network topology and propagation, as it relates to reorgs
<xmrmatterbridge> <rehrar> Obviously the hope is to get the conf time down for spendable funds, but if research shows 10 is good (or even increase), well at least we have numbers to back it up
<sarang> I don't have particular data on this... best candidates for that are the noncesense folks
<sarang> dEBRUYNE: OSTIF is working to get the first code audit number (24750 USD) down
<sarang> the math audit number is currently 7200 USD
<dEBRUYNE> OK
<dEBRUYNE> Do we have only one offer for a code audit btw?
<xmrmatterbridge> <serhack> sarang: probably you know this suggestion but I will never tire of repeating it. You have to capture attention of people, in any possible way. So, if you think the presentation graphic could be changed to improve the readability, go for it. If you think you have to remove text and to add more images, go for it.
<nioc> rehrar if you reduce the time to 5 minutes won't you just get questions like, why I need to wait 5 minutes?
<sarang> AFAIK there is only the single code audit offer right now, but OSTIF is working on this
<sarang> Both to allow the possibility of multiple reviews (if desired) and to promote competition that could reduce the cost of each review
<xmrmatterbridge> <sgp_> This isn't high priority, but I'd like to see an analysis of the number of coinbase outputs in rings on average over time
<sarang> Ah, over the different selection algorithms?
<sarang> I agree that it would be interesting. I ran some numbers on super small datasets and it was a spread that maxed at 1-in-11 IIRC
<sarang> There is always the question of whether a consensus rule of "any ring w/ coinbase must be all coinbase" would be a net benefit
<sarang> I still hold that it shifts the resulting heuristic down the transaction graph one hop, but overall it's probably not a bad idea
<xmrmatterbridge> <sgp_> You know my view is that it's a net positive, but most people don't agree yet
<silur> I don't get the assumptions itself, aren't coinbases in rings can be used as inputs to any other tx?
<silur> won't making "any ring with coinbase must be all coinbase" that property nonexistent?
<sarang> One claim is that coinbase can be excluded as the true spend for "average transactiosn"
<sarang> as well as questions of pool behavior
<sarang> Prior to the last selection change, coinbase were being overselected as part of a broader weighting issue
<sarang> Now they're selected according to their on-chain frequency, but are otherwise not selected differently
<sarang> Of course, making all-coinbase rings means that you could now identify the outputs of those transactions as heuristically not true spenders where they are used
<silur> on firsth thought that doesn't seem too much of a practical privacy leak
<sarang> It was not good when they were being overselected, but in fact the over/underselection was technically occurring for all selection regions where block density was varied
<sarang> It was just that coinbase were far more visible as an effect of this
<silur> I see
<sarang> So right now you'll usually see 0-1 coinbase or so per ring, but there are certainly outliers with more
<sarang> Anyway, certainly something to keep thinking about. As with most things, it's probably a bit more subtle than it seems at first glance
<sarang> Back to the agenda... did anyone else have research to share?
<sarang> Or other questions?
<sarang> Right, then on to ACTION ITEMS
<mikerah> I have some questions related to what was discussed last week
<sarang> sure mikerah
<sarang> go ahead
<mikerah> Have you considered using Polynomial commitments
<sarang> For what?
<mikerah> In order to get a SNARK without trusted setup for ring signatures
<sarang> How so?
<mikerah> Current schemes that are coming out are using polynomial commitments in such a way that you can eliminate the need for a trusted setup
<mikerah> Halo and DARKs come to mine.
<silur> afaik those are more generic schemes than what's needed in practice here
<sarang> Well, Halo's big goal is recursive evaluation
<mikerah> These schemes aren't quantum secure and you get larger proof verification sizes as usual
<sarang> and it's not even close in terms of desired efficiency yet; early stages
<kenshamir[m]> <mikerah "Halo and DARKs come to mine."> DARKs can be used, but the polynomial commitment scheme in Halo cannot from what I’ve read and tried
<mikerah> isn't halo's big goal recursive composition + no trusted setup
<sarang> yes
<silur> mikerah: quantum secure schemes have even larger proofs
<silur> usually 2kb+
<silur> at best
<mikerah> kenshamir: If I understand correctly, the polynomial commitment scheme in Halo is derived from Sonic.
<mikerah> silur: There's a lot of research going into quantum secure zk-SNARKs. Although proofs are prohibitely expensive, even more so than current schemes, I expected it to get better in the next 5-10 years
<kenshamir[m]> The paper on the commitment scheme for DARKs is not out yet, it uses class groups, so group sizes will be roughly the same as RSA, but verifier asymptotics will be sublinear
<silur> mikerah: I'm mainly into quantum-safe crypto so I also follow these researches. I'm more optimistic on the matter and expect that breaktrough much sooner :P
<sarang> In the interest of time, let's go ahead and wrap up this meeting; discussions can of course continue after
<kenshamir[m]> <mikerah "kenshamir: If I understand corre"> I read it as a modification of inner product argument that is similar to bulletproofs, I’d need to read sonic though haha, only have ever skimmed it
<kenshamir[m]> The polynomial commitment scheme used in sonic is KZG10 IIRC
<mikerah> kenshamir: I also read it as that but if you skim through Halo, they present Sonic and then give the modifications to the sonic scheme in order to achieve amortized succintness
<sarang> I'll be working on WCC prep, RCT3 proof review and analysis numbers, and an idea RandomRun had for modifying the Triptych proof to support multiple inputs natively
<sarang> For log posting purposes, let's adjourn here and let conversations continue :D

Logs for the Community Meeting Held on 2019-09-28

Sat, 28 Sep 2019 00:00:00 GMT

Logs

<sgp_> Meeting time
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/391
<sgp_> wait jk
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/396
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<xmrmatterbridge> <el00ruobuob> o/
<intj440> hello
<xmrmatterbridge> <rehrar> hiya
<xmrscott[m]> Sup
<xmrmatterbridge> <rehrar> will be on IRC soon.
<darkaleph> hey everyone
<sgp_> welcome everyone. thanks for being here!
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com/
<sgp_> There was an initial "policy & regulation" meeting here earlier this week: https://github.com/monero-project/meta/issues/392
<sgp_> Head to #monero-compliance to join that initiative
<sgp_> Of course, the most important news is that 0.15 is expected on October 31, with the scheduled protocol upgrade on November 30. Here are some of the major changes: https://www.reddit.com/r/Monero/comments/d9lbji/what\_are\_some\_of\_the\_major\_notable\_changes\_coming/
<monerobux> [REDDIT] What are some of the major notable changes coming to Monero this Oct 2019 for v0.15? (self.Monero) | 31 points (80.0%) | 16 comments | Posted by patoshii | Created at 2019-09-26 - 15:38:56
<sgp_> Release schedule: https://twitter.com/JEhrenhofer/status/1175830009254166534
<monerobux> [ Justin Ehrenhofer on Twitter: "Tentative Monero 0.15 release schedule: Oct 24: code freeze Oct 31: release Nov 30: network upgrade… " ] - twitter.com
<sgp_> Are there any outstanding questions regarding the upcoming update?
<sgp_> None? Wow, you people are quite informed
<sgp_> Please help us contact exchanges. I'll make a Blockfolio notification today, and we should make a Monero-announce mailing list announcement: https://www.reddit.com/r/Monero/comments/daacw0/reaching\_out\_to\_the\_exchanges\_network\_upgrade\_v015/
<monerobux> [REDDIT] Reaching out to the exchanges / Network Upgrade / v0.15 (self.Monero) | 26 points (90.0%) | 4 comments | Posted by mishka1984 | Created at 2019-09-28 - 02:37:16
<sgp_> Does anyone have community (non-workgroup) updates to share?
<sgp_> 3. CCS updates
<sgp_> Monero Wiki October 2019 (5.2 XMR): https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/98
<sgp_> All ideas in funding required have been fully funded.
<sgp_> Any comments on this new proposal in ideas?
<xmrmatterbridge> <rehrar> hmmm
<xmrmatterbridge> <rehrar> Thoughts on the wiki thing sgp?
<sgp_> It's a really small amount. I'd like to see a better idea how the funds are rewarded though
<xmrmatterbridge> <rehrar> I'm a little bit skeptical
<sgp_> Asking for sensible server hosting costs is totally reasonable to me
<xmrmatterbridge> <rehrar> I know asymptomatically is as good as they get
<xmrmatterbridge> <rehrar> but I'm just afraid of the burnout that comes with having to maintain something as..."intensive" as a wiki
<xmrmatterbridge> <rehrar> but hey, he's asking for server costs, so I guess it doesn't matter
<sgp_> Possibly, but the ability to edit the wiki is much simpler than editing the getmonero website
<sgp_> especially from a newcomer perspective
<xmrmatterbridge> <rehrar> meh, what the heck? it's not much XMR, and we'll see how it goes
<xmrmatterbridge> <rehrar> I'm for
<sgp_> Any other comments? I prefer the format and approachability of a wiki compared to the main website
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> RandomX was merged, and all hands are on preparing for release at this point.
<sgp_> There were a few instabilities on testnet that are being ironed out, hence the slightly later than expected network upgrade (hardfork) date
<sgp_> b. Localization workgroup
<sgp_> ErCiccione has a new translation platform at translate.getmonero.org.
<sgp_> Join #monero-translations to help out
<sgp_> c. GUI workgroup
<sgp_> i2p support is finally anticipated in the GUI for 0.15! It may also include the ability to send funds to multiple addresses in one transaction (feature available in the CLI), but this is lower priority.
<xmrmatterbridge> <rehrar> I2P is for this update? woof
<xmrmatterbridge> <rehrar> when did vtnerd say this?
<sgp_> As of a few minutes ago, pigeons set up an i2p Monero node for testing that "seeds" peers to other monero clients. So that's coming along nicely :)
<sgp_> That was the main holdup afaict
<dEBRUYNE> and we should make a Monero-announce mailing list announcement <= I will have that ready tomorrow
<dEBRUYNE> ErCiccione[m] will put it on the site as announcement too
<sgp_> Tor support probably won't make it
<sgp_> But most users will see larger practical benefits from i2p anyway
<sgp_> d. Monero Research Lab
<sgp_> Sarang and Surae have focused their attention on CLSAG, Omniring, Lelantus, RingCT 3.0, and matching. A new RingCT 3.0 preprint is out with large changes.
<xmrmatterbridge> <rehrar> sad on the Tor, but it's good for I2P{
<sgp_> You can always view their logs in the meta repo
<sarang> Yes, I've been focusing on sublinear protocols mostly
<sgp_> Any questions on Monero workgroups? We are speeding through this meeting
<sgp_> 5. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<xmrscott[m]> Just a comment that I don't think technically translate.getmonero.org has been released to the masses, so keep it on the downlow
<xmrmatterbridge> <rehrar> I have something to discuss.
<kinghat> *hands torch to rehrar*
<xmrmatterbridge> <rehrar> This is a semi-serious idea. Similar to the testing of the minecraft server for people to play on
<xmrmatterbridge> <rehrar> what are some things the community might be interested in doing, that's online?
<xmrmatterbridge> <rehrar> together, I mean
<xmrmatterbridge> <rehrar> online board game, book club, debates, discussions?
<xmrmatterbridge> <rehrar> maybe the answer is nothing
<xmrmatterbridge> <rehrar> but it'd be cool to have a few different things going, and having a vibrant "community space"
<xmrmatterbridge> <rehrar> that's not just Monero-centric
<xmrmatterbridge> <rehrar> different people want different levels of engagement. I'm sure there's some people that don't care to be involved in a "Monero community" in anything past Monero related matters
<xmrmatterbridge> <rehrar> but others might feel differently. Just wanted to ask in this meeting what people might think
<sgp_> I'm not going to directly answer your question, but I can speak to the importance of something like this
<sgp_> For university student groups, they strongly encouraged us to have someone who role was to focus on promoting group "culture." Bonding, doing fun things, etc
<sgp_> Maybe it would be worth making a long list of ideas people would be interested in doing and seeing who wants to do these?
<xmrmatterbridge> <rehrar> if engagement in this meeting is anything to go by..... :P
<xmrscott[m]> Yeah, probably best done offline
<xmrscott[m]> Make a reddit post etc, a select few can only be so representive of a community
<xmrscott[m]> *select few in a meeting
<sgp_> It seems like people are busy doing other stuff today. Make a reddit post and hopefully it will help encourage engagement
<sgp_> Unless there are other comments, I can end the meeting early
<sgp_> 6. Confirm next meeting date/time
<xmrmatterbridge> <rehrar> kthanksbai
<sgp_> The next community meeting will be in 2 weeks on 12 October at 17:00 UTC. The next Coffee Chat will be on 19 October at 16:00 UTC.
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the Monero Research Lab Meeting Held on 2019-09-23

Mon, 23 Sep 2019 00:00:00 GMT

Logs

<sarang> First up, GREETINGS
<suraeNoether> howdy!
<sarang> And, I suppose, ROUNDTABLE as well
<sarang> suraeNoether: care to go first?
<suraeNoether> sure, I spent all weekend working on the CLSAG paper for submission
<suraeNoether> the deadline is 5am (my time) tomorrow morning
<sarang> Some really good changes to definitions
<suraeNoether> i've been up past 2am for the past few nights trying to get it all done
<sarang> Better capturing forgeries, and cleaning up linking :D
<suraeNoether> yeah, the paper is actually v gorgeous now, and i'm excited to update the preprint after submission
<suraeNoether> also, reviewing the DLSAG paper today for submission to the same proceedings
<suraeNoether> i missed the deadline for getting thring signatures out there, but 2/3 ain't bad
<suraeNoether> once that deadline passes, i'm shifting gears back to code for a few days
<sarang> Oh well, there are other good destinations too
<suraeNoether> aaaand that's it
<suraeNoether> yes for sure
<sarang> Some with rolling deadlines, which may be much more convenient
<sarang> I've been working on a hodgepodge of items
<sarang> FC 2020 submission review
<sarang> Ongoing work with the Lelantus author on ideas and constructions for removing its sender tracing issue
<sarang> It's proving surprisingly tricky to get a Lelantus construction that admits both one-time addresses and prevents sender linking
<sarang> It has to do with how range proofs are constructed using the one-time address, since this is used directly in a commitment
<sarang> In the case without one-time addresses, the recipient generates a representation proof that assures verifiers the range proof is with respect to generators with unknown discrete log relationships
<sarang> In the case with one-time addresses, I don't know a way to achieve this
<sarang> So, work continues on it
<sarang> Finally, the RCT3 authors released an update to their preprint
<sarang> This is quite exciting... it modifies how public keys are used within spend proofs to fix a problem with a particular proof (which would otherwise lead to an exploit)
<sarang> but it also permits the use of a single log-sized proof across all spends
<sarang> So there are substantial changes to review and test
<suraeNoether> i'm eager to get further into the details of them. i'm still skirting the edges of lelantus, ringct3, etc. HALO was a surprisingly short paper, and so many recent results are showing us all how important it is to formalize our transaction protocol as a circuit...
<sarang> Halo is quite interesting, but seems to be widely misreported as something that is practically usable now for chain verification, which it is not
<sarang> There is also not a soundness proof, but there are for some of the underlying constructions (which bodes well)
<sarang> Sean (the author) thought there might be an interesting application to how Bulletproofs' inner-product arguments are batched
<sarang> so it's neat stuff
<suraeNoether> i liked the response "big if sound"
<sarang> Heh, me too
<suraeNoether> i don't know who tweeted that, but it's working it's way into my daily vocabulary.
<suraeNoether> at the grocery store, looking at humongous squashes. Knock on the squash. "Big if sound."
<sarang> -___-
<sarang> Does anyone else have interesting work to share, or questions on anything?
<mikerah> Can you go into more details about specifying the monero transaction protocol into a circuit
<suraeNoether> its*
<defterade_> What are the chances of CSLAG making it in the April hardfork?
<suraeNoether> mikerah: long story short: a lot of the ZK proof systems out there rely on showing "Given an arithmetic circuit that describes a function f(-), here is y and a proof p that I know a secret x such that y = f(x)."
<sarang> Specifying transaction requirements as a language suitable for various proving systems is useful for broader application
<suraeNoether> the function f formalizes the language sarang just mentioned
<sarang> defterade_: depends entirely on audits, which I'd like to address momentarily
<suraeNoether> it can be complicated to take a statement like "I know one of these ring members, and the associated commitment opening" and turn it into an arithmetic circuit
<suraeNoether> or, the resulting circuit could be really slow
<suraeNoether> or too large or what have you
<suraeNoether> so there's a challenge in formalizing our ring confidential transaction "statements" into an arithmetic circuit
<sarang> Well, systems like Omniring take such statements, formalize them into a language, and then construct a proving system for that language
<sarang> (albeit less generally)
<mikerah> Have there been other attempts at specifying ring signatures in arithmetic circuits
<kenshamir[m]> eprint 1076 also uses recursive proofs. The benchmarks are asymptotically equal to Marlon though.
<suraeNoether> we can exploit a lot of available proving systems out there, possibly yielding more efficient ring confidential transactions, given a description of such a circuit
<sarang> Not without trust requirements at this point
<kenshamir[m]> There was no comparison to Halo because Halo was too informalq
<sarang> Proving systems specific to particular language constructions (Bulletproofs range proofs, Omniring, RCT3, etc.) tend to be reasonably efficient for having no private setup
<suraeNoether> mikerah: not that i know of, yet... certainly not in the DDH + ROM setting without trusted setup
<sarang> As far as CLSAG goes, OSTIF informs me that one code reviewer quoted $24750 (code only, not the paper)
<mikerah> Ooh. Another research project idea!
<kenshamir[m]> <mikerah "Have there been other attempts a"> I think you can do it, but it would not be efficient; a statement like Pubkey 1 OR pubkey2 OR ... PubkeyN
<sarang> And one math reviewer quoted $7200 (paper only, not the code)
<sarang> They are looking into it more
<suraeNoether> i have to go for a doctor's appointment; please accept my apologies for bailing early. sarang, care to take it from here?
<sarang> The math review could be completed by the end of November in this case
<sarang> sure suraeNoether, see ya
<suraeNoether> that's a decent deal for the math review tbh. who is it?
<sarang> It isn't clear if I can share that publicly before they've made a formal commitment
<sarang> but it's someone quite respected
<mikerah> If I'm going to take a guess, I think it's Dmitry Khovatovich
<mikerah> Not sure if I spelt his name correctly
<sarang> Unclear about the timeline for the code review
<sarang> OSTIF is inquiring with other groups
<sarang> Any other questions or items to share before moving on?
<sarang> All right then; on to ACTION ITEMS
<sarang> This week, I'll be completing the edits and submission for FC 2020 (and updating on IACR and MRL archive)
<sarang> and continuing review of the updated RCT3 proofs and proving system
<sarang> there's a lot of stuff to unpack with that
<sarang> Anything else before we adjourn?
<defterade_> Do the changes made in CLSAG warrant a level of audits to the extent of RandomX? (i.e. >= 3 code reviews)
<sarang> The code changes for the basic signature scheme (and some underlying plumbing) aren't terribly complex... there are plenty of other code changes that plug it in to the rest of the codebase
<sarang> The math isn't very different from MLSAG, but is different enough to warrant a formal review... additionally, the proofs in the original MLSAG paper weren't very formal either, and we've worked to make the CLSAG definitions and proofs more extensive
<sarang> That being said, I would be surprised if 3 separate code audits would be of value in this case, depending on the scope
<sarang> Getting review of the math, whether by the usual peer-review process or a paid review, is certainly a good idea
<ArticMine> So are looking instead at one maybe two audits?
<sarang> It's not up to me
<defterade_> But it would be fair to say the financial burden for the community is expected to be lower than RandomX?
<sarang> Given the numbers presented so far, it seems so
<sarang> The sum of the two current quotes (code and math) is $31950
<sarang> Hopefully the code quote will be reduced once the scope is more clearly (and perhaps narrowly) defined
<sarang> There's the code that produces and checks signatures, and then there's the code that integrates these into transactions etc.
<defterade_> Has there been any discussion on changing the ring size when CLSAG goes live?
<sarang> There has been
<sarang> IIRC increasing from 11 to 13 would retain the same verification time as we have now
<sarang> Whether or not this marginal increase is "worth it" is an open question
<defterade_> Doesn't break the prime sequence, nice
<defterade_> Okay
<sarang> Righto, thanks to everyone for attending; logs will be posted to the GitHub issue shortly

Overview and Logs for the Dev Meeting Held on 2019-09-22

Sun, 22 Sep 2019 00:00:00 GMT

Logs

<rehrar> ok
<rehrar> it's time
<rehrar> 1. Greetings
<rehrar> who all is here?
<sgp_> hello :)
<needmonero90> Hi
<xmrscott[m]> Hey hey hey
<rbrunner> Hi
<tevador> hey
<sech1> \o/
<ErCiccione[m]> Hi
<ferretinjapan> so everyone except the people rehrar pinged are here, nice.
<rehrar> it would seem so
<rehrar> moneromooo: do we have you at least? :P
<moneromooo> Yes.
<rehrar> one last round for fluffypony luigi1111 ArticMine binaryFate
<rehrar> please join us ASAP
<rehrar> in the meantime, we can move on to 2. What's been completed since last meeting?
<vtnerd__> here
<sech1> I've finished RandomX JIT compiler for ARM CPUs. Verification time is even better than CN/R on ARM.
<moneromooo> Pretty good stuff here.
<rbrunner> Nice
<ArticMine> Hi
<dEBRUYNE> I am here
<meksi> Hi
<tevador> so I guess we are including the ARM JIT in the release?
<tevador> probably no reason not to
<moneromooo> It can be disabled with an env var AFAIK so sure.
<tevador> just it hasn't been heavily tested as the x86 JIT
<SoiMatter> Sirs! ferretinjapan asked moi to join.
<hyc> since it's easily toggled off, I'd say we run with it
<jtgrassie> hi
<SoiMatter> o7 I will keep still :)
<moneromooo> monerod can now synced from pruned blocks (optional). I'd like this to go in before release if reviewed.
<rehrar> Honest question to everyone, now that CLI has reproducible builds, can we as a community decide on a date without input from Core?
<selsta> GUI?
<rehrar> that's next selsta :P
<selsta> yes but it would be nice to release both the CLI and GUI at the same time and that depends on core
<moneromooo> Pony still controls the website (for binaries to be uploaded), and the DNS records (for the hashes of the binaries).
<rehrar> ok so there's distribution and GUI to consider
<dEBRUYNE> Pony said he'd be around for the CLI & GUI release
<rehrar> I mean, ultimately we want to go along this road at some point to reduce centralization anyways, no?
<moneromooo> Also needs people to build for random OSes. Does Windows have repro builds too ?
<ArticMine> Do we have a release date in mind?
<dEBRUYNE> moneromooo: Yes
<dEBRUYNE> At least for the CLI
<ErCiccione[m]> ArticMine: i think the idea was to set a date today
<rehrar> so let's set one
<rehrar> ArticMine can represent the core team here
<sgp_> October 26?
<rehrar> Are we thinking mid-October? End of October?
<dEBRUYNE> I would personally prefer a bit more towards the end of October, as that gives us a bit more leeway
<ArticMine> I do not ave an issue with setting a release date at this meeting
<ErCiccione[m]> i agree
<hyc> Let's go with October 31, Halloween
<tevador> is this the release date of the fork date?
<tevador> or*
<hyc> it'll be scary
<moneromooo> I have some reservations about the stability of randomx-in-monerod. Bugs are still coming in fast.
<needmonero90> Monero's spoopy fork
<rehrar> tevador: fork date
<dEBRUYNE> tevador: fork date
<sech1> October 31 is a bit too late
<moneromooo> So pushing back would be good in my view :)
<ArticMine> and code freeze?
<rehrar> if mooo has reservations then maybe 31 is a decent date?
<rehrar> sech1: what's your reasoning?
<tevador> so better to not do it in the middle of the week
<luigi1111> I'm sorta here
<sech1> October 31 is kind of an edge of publicly promised "fork in October"
<sech1> October 26 sounds better
<moneromooo> I don't anyone (who counts) ever promised.
<hyc> assuming it's actually ready by then
<needmonero90> Welcome to decentralization sech1.
<rehrar> I am fine with 26th
<tevador> yeah, 26 October would be better if it's doable
<needmonero90> Community won't be too mad if we don't hit deadlines
<SoiMatter> Go with the date of the next UK election
<hyc> testnet has been disturbingly unstable the past few weeks.
<hyc> but most of the problems were unrelated to randomX
<Inge-> Better a safe launch than an october launch.
<ArticMine> One key point is the time between release and fork date
<rbrunner> Normal testnet or the RandomX testnet?
<hyc> randomX testnet
<hyc> but the issues with peers being disconnected and banned would have happened on public testnet too if anyone bothered to exercise that
<hyc> basically current git master is unstable, recent changes to the networking code broke a lot.
<sech1> if fork is October 26 (4 weeks), would 2 weeks be enough to fix all that?
<sech1> and would additional 5 days help?
<ErCiccione[m]> i'm starting to think would be better to posticipate to after october
<tevador> so it looks more like November
<ArticMine> Release and fork date ware very different
<dEBRUYNE> hyc: Those recent changes will be reverted by 5905 right?
<moneromooo> Yes.
<ArticMine> We need to give people time to update
<ErCiccione[m]> if there are so many doubts i would just wait. No reason to rush it, this is a big fork
<hyc> agreed, safer to wait
<rehrar> so really all of this should have been discussed two weeks to a month ago
<sgp_> I don't think the optics of a "late" Oct 31 date will be terrible. We can get ahead of it with the Halloween marketing. If people prefer November, then I think we should still pick a date
<M5M400> will this release discontinue legacy payment IDs?
<rehrar> so for next time we really need to start seriously discussing the fork two months prior to "planned" date
<moneromooo> Yes.
<moneromooo> Though currently not banned, just code removed.
<dEBRUYNE> rehrar: I don't think we could have foreseen the issues arosen on testnet
<moneromooo> Are any large exchanges still using them ?
<ArticMine> I suggest an October 31 release date with a fork date 4 weeks later
<luigi1111> late is far better than broken
<sgp_> I can try to compile a list
<sech1> We still need to decide fork date and release schedule today
<rehrar> dEBRUYNE: literally every single fork there is a "I don't think we could have foreseen" situation?
<needmonero90> What happened to move fast and break things? This is tech!
<dEBRUYNE> Yes because there will simply be things that cannot be foreseen
<dEBRUYNE> You cannot perfectly plan such a thing
<luigi1111> I too enjoy breaking money when possible
<rehrar> ok, ArticMine has made a concrete suggestion
<rehrar> 31st release date, one month later fork date
<sgp_> one month? why one month?
<needmonero90> I think its reasonable.
<needmonero90> No objection here.
<ferretinjapan> luigi1111, I agree, late and working is far better than on time and buggy...
<hyc> is that the same offset we used in previous releases?
<M5M400> moneromooo: i have about 330 miners still mining to payment_id addresses. that's 5 %
<sgp_> no, closer to two weeks I think
<ArticMine> To give people proper notice to upgrade
<luigi1111> that's what it ended up being
<needmonero90> We were pushing to the wire last time
<needmonero90> To be fair
<luigi1111> we never targeted two weeks that's simply not ideal
<needmonero90> Two weeks was cutting it close
<ArticMine> This has been an issue many times before
<ErCiccione[m]> yeah, one month seems fair
<sech1> October 31st release and November 30th fork then?
<luigi1111> yes we've always pushed releases to late but doesn't mean we shouldn't try to do better
<ArticMine> sounds fine to me
<sgp_> So what specific fork date?
<tevador> 30th Nov
<rbrunner> November 30 is again Saturday, which is nice
<sech1> let's hope CN/R holds without ASICs until then :)
<ArticMine> So when is code freeze?
<moneromooo> Whenever we don't have anything left we want to merge :)
<ErCiccione[m]> now with reproducible build releases should be much faster, at least for CLI. We rarely managed to release at the time we decided
<needmonero90> October 31st makes sense imo
<sgp_> I think having a release in October will help with optics. And a 31st update is easy to brand
<rehrar> alright, it looks like we have a loose consensus, unless anyone would like to speak now
<ArticMine> Sure but how much time is needed between code freeze and release?
<rehrar> in opposition
<luigi1111> like a week
<luigi1111> but fluffy fluffy fluffy
<selsta> +1
<selsta> long code freezes never work
<rehrar> luigi1111: did not show
<dEBRUYNE> We only need fluffy to upload the bins though for the CLI release
<dEBRUYNE> (and do the website)
<luigi1111> I know but if he's building he has to be able to commit to a schedule
<sgp_> so Thanksgiving weekend hardfork (Nov 30)
<sech1> yes, better safe than sorry
<hyc> since we have reproducible builds we don't need him to build
<dEBRUYNE> rehrar: He said he'd be available for the release (he'd prefer to have a timeline a bit in advance though)
<rehrar> luigi1111: if he's unable to commit to a schedule, then we can do the deterministic builds thing, and just make sure they get uploaded
<luigi1111> ok cool
<luigi1111> then just gooey
<rehrar> which is you
<ArticMine> The time between code freeze and release need to be set buy those closest to the code
<rehrar> can you commit to this schedule?
<dEBRUYNE> GUI gets build by pony
<rehrar> oof
<needmonero90> Speaking of build privs, I would like to formally propose that some of the GUI repo privileges be transferred to dsc (the non deterministic build part at the very least)
<M5M400> how can fluffy still be the only person able to do some vital things?
<luigi1111> I'm the one going to be doing all the merges in both projects so heh
<dEBRUYNE> rehrar: Third time and last time I will say -> He said he'd be available for the release
<rehrar> M5M400: that's why deterministic builds is top priority
<rehrar> dEBRUYNE: ok
<ferretinjapan> M5M400, mainly because reproducible builds were never a thing before now.
<needmonero90> luigi1111: we really should move some of those responsibilities to dsc.
<dEBRUYNE> needmonero90: I disagree, then we would have coders merging their own stuff
<needmonero90> He would be the new maintainer/lead of gui
<needmonero90> Or something
<rehrar> ok, any other questions in regards to the set dates? October 31st release, November 30th fork.
<moneromooo> So what do we need for the release ? readline fixes for repro builds, randomx. The pay-for-service stuff. Payment ID changes. Hopefully the sync-pruned-blocks. Anything else that's large or really needed ?
<ferretinjapan> freeze date?
<rehrar> needmonero90: that would be the first time a non-core team member will have done this. Not impossible, but certainly unprecedented and worthy of a bigger discussion which we don't have time for here in this meeting
<dEBRUYNE> Once we branch the code is basically frozen right? Because then only fixes go in
<ErCiccione[m]> one week code freeze would be appreciated. Let's remember that there are the translation to deal with (and i beg for a code freeze since ever :D)
<needmonero90> Okay, tabled for now rehrar
<moneromooo> vtnerd__: are you planning to have some more network stuff ready for the release ?
<ferretinjapan> I guess the #monero-pow guys would have a better idea when to freeze...
<ArticMine> Oct 24th as per luigi1111 selsta?
<luigi1111> he's not the only one with access to a couple things but the only one that actively used his access
<dEBRUYNE> moneromooo: The readline fix is 5892 right?
<selsta> ArticMine: yes
<luigi1111> until recently where him and pigeons have both not been to active
<moneromooo> Could be. Depends on what people who have the problem say after testing it :)
<dEBRUYNE> ArticMine: I think we can branch earlier, but moneromooo probably has a better view on that
<ArticMine> moneromooo does Oct 24 work for code freeze?
<ErCiccione[m]> pigeons is active. I asked him to update the server of getmonero last time
<moneromooo> That sounds plausible to me.
<M5M400> moneromooo: it appears bittrex and binance still use payment_id's
<ErCiccione[m]> and he also gave me a hand with weblate
<moneromooo> Thanks.
<vtnerd__> moneromooo : yes, the split mempool is jst about done (finishing core tests nows)
<rehrar> wow
<dEBRUYNE> M5M400: Binance is working on upgrading their system, needmonero90 is in touch with them
<rehrar> vtnerd__: so your stuff will make it in this one?
<vtnerd__> and the dandelion++ remnants _shouldn't_ be too painful - although I always say that :/
<M5M400> dEBRUYNE: saifu. great.
<needmonero90> Binance indicated they should be ready by fork in October. Pushing the date back shouldnt hurt the timeline.
<M5M400> anyone in touch with bittrex?
<dEBRUYNE> They are aware as far as I know
<vtnerd__> I can't say whether it will "make it in", because theres always a chance something comes up during review, etc
<vtnerd__> but the split mempool for the i2p/tor is close to ready. my concern is that its kind of tough the way it got shoved in
<rbrunner> You mean in a technical sense?
<vtnerd__> I took hyc's approach of adding a tag to the metadata, but I had to inspect a bunch of code paths to make sure stuff didn't leak
<binaryFate> hi all, sorry got late to the party
<vtnerd__> ultimately a true "physical" or "logical" split would be ideal, but it seemed kind of tough at the momnent when I tried to think about hwo to do it
<moneromooo> Oh so it's a single txpool, just txes have a flag ?
<vtnerd__> yeah, unfortunately
<M5M400> are we aware of any GPU miner in the works for randX that will be ready in time for spork?
<moneromooo> That's what I did for the sync-from-pruned :)
<hyc> M5M400: xmrig is ready
<luigi1111> 24th and 31st targets are good with me for 30th fork
<sech1> M5M400 xmrig 4.0 is combined CPU + OpenCL miner
<vtnerd__> if thats worth a reject, then I can go back and try again, but its a little dicey otherwise (it requires a slightly larger refactor and possibly a second lmdb database)
<luigi1111> mostly afk now
<rehrar> vtnerd__: if this does make it in this time, it can be iterated on in the future no?
<M5M400> hyc: sech1: nice
<moneromooo> It's not IMHO. I'd have done that too.
<moneromooo> But then I tend to shove things in :)
<vtnerd__> yes, I don't think the patch makes it harder to refactor, its probably neutral from that perspective
<hyc> I don't really see other approaches to that as being a good idea
<tevador> btw, fork height could be 1978433, which is exactly the start of a RandomX epoch and should be in the afternoon CET on Nov 30th
<vtnerd__> as an example of what I mean - one of the weird cases is that fluffy blocks request can leak the anonymity channel, etc, so yeah
<dEBRUYNE> tevador: Afternoon CET would allow most people to be online, because it would basically be late evening for Asia and morning for US
<moneromooo> And let's reset testnet to fork on an epoch boundary too ?
<tevador> dEBRUYNE: yeah, nice coincidence
<ErCiccione[m]> i guess we have a fork height. Nice
<rbrunner> With a testnet fork around release, end of October?
<hyc> sounds good
<dEBRUYNE> To summarize the timeline, this is approximately correct right? Branch within 2-3 weeks, freeze October 24, release October 31, fork November 30
<moneromooo> I think we have everything we need for v12 now, apart from randomx, so we can fork the real testnet as soon as it gets merged.
<rbrunner> Even better then
<tevador> that looks like a sensible schedule
<sech1> yes, plenty of time to iron out all issues
<rbrunner> Famous last words :)
<dEBRUYNE> It at least feels we are better prepared now than last time :-P
<tevador> someone should strictly enforce code freeze this time
<rehrar> penalty of death
<ErCiccione[m]> tevador: i strongly agree
<dEBRUYNE> moneromooo: Do we need pony around to fork the real testnet?
<PauleBert> can we reset stagenet too? it is getting quite huge
<moneromooo> Yes, the miner's one of his nodes, and seed nodes need updating too.
<moneromooo> The former's not a big problem, but the latter kinda is.
<needmonero90> Don't reset stagenet :(
<dEBRUYNE> Ok, I will send him a message then
<needmonero90> Telegram tipbot uses it
<rbrunner> "Reset" means here dropping a few hundreds of blocks probably, no new genesis block
<needmonero90> It'll wipe all our balances ;_;
<rbrunner> Back to the latest epoc date, that is
<needmonero90> (yes, I know, it's stagenet)
<rbrunner> Or a few thousands ...
<M5M400> are we in any way concerned about the probably 10x hashrate post fork and the amount of blocks being spit out quickly? might it be a good idea to set a ballpark initial diff?
<hyc> I'm guessing that will be offset by the typical hashrate drop due to not everyone updating
<moneromooo> I am not.
<sech1> I don't think so. It'll rather grow slowly.
<rbrunner> I think to remember from earlier forks that "doctoring" the diff is not trivial
<sech1> Even with higher hashrate from CPUs, hard fork drop in hashrate will make initial diff roughly the same as now
<ferretinjapan> I wouldn't be worried un less ASICs were currently saturating the network, but by the sounds of it, theres been no indication of that being the case...
<M5M400> I've seen a few big miners on the pool that are most likely CPU based. one instance of 17MH cn/r. these operations don't miss forks, as opposed to casual miners
<sech1> No signs of ASICs
<ferretinjapan> thats good.
<rehrar> alright, is there anything else of note to discuss?
<ErCiccione[m]> minor: is it fine for everybody if we take down the current warning on getmonero, it's there since last fork
<needmonero90> We need to talk about extending the Monero Foundation's Dev tax, and the Monero name trademark issue
<ErCiccione[m]> i want to avoid people not reading it because they are used to it when we put up the new one
<needmonero90> Oh wait wrong coin
<needmonero90> We good
<hyc> ErCiccione[m]: good idea
<rbrunner> Yeah, take it down before it gets a running gag or something
<rbrunner> "Monero mixes up its hardforks"
<rehrar> alright
<ErCiccione[m]> alright, will open a PR tomorrow
<rehrar> alright friends, it would seem we're all good
<needmonero90> Is Gui considered core?
<needmonero90> Or is it it's own thing
<hyc> dEBRUYNE: now that randomx has quieted down I'll get to rebasing that gitian PR of mine
<ErCiccione[m]> needmonero90: that's actually a good question. See https://github.com/monero-project/meta/issues/384
<selsta> Please no renaming discussion.
<selsta> The github issue is a better place for that.
<rehrar> alright everyone, we'll officially break for today
<rehrar> thanks for coming. Good discussion, and got a lot done.
<hyc> who's posting meeting logs?
<rehrar> We can continue on a two weeks schedule for now? Or want to go to one week mini-check in on off weeks?
<ErCiccione[m]> hyc: el00ruobuob, usually
<hyc> ok.
<hyc> I think next mtg in 2 weeks is fine. after that, we can decide again
<rehrar> ok
<ErCiccione[m]> unles you didn't mean on getmonero
<rehrar> sounds good
<dEBRUYNE> hyc: Thanks
<dEBRUYNE> ErCiccione[m]: I'd prefer to update it with a general information thread regarding the upcoming fork
<dEBRUYNE> I can have that ready next week
<ErCiccione[m]> dEBRUYNE: sure! will you PR it on repo.getmonero?
<IRC-Source_89> guys sorry for the question , but i missed the begining of the discussion... Have you already choosen a block height for the fork?
<scoobybejesus> tevador> btw, fork height could be 1978433, which is exactly the start of a RandomX epoch and should be in the afternoon CET on Nov 30th
<dEBRUYNE> ErCiccione[m]: Sure
<scoobybejesus> there seemed to be rough consensus on that
<IRC-Source_89> thank you
<ErCiccione[m]> dEBRUYNE: great, thank you. Ping el00ruobuob_ so he remembers to not PR it
<dEBRUYNE> I don't mind if he PRs it
<ErCiccione[m]> he usally PR them after more than one week, should be fine
<dEBRUYNE> Are we talking about the same thing? :P
<dEBRUYNE> I was referring to the new information thread regarding the fork
<ErCiccione[m]> I was talking about the logs :P i understood you wanted to include them in the thread.
<ErCiccione[m]> but anyway, we should really make a blog post about it.
<sech1> So will the schedule be officially announced soon?
<rbrunner> sgp_ was fast: https://old.reddit.com/r/Monero/comments/d7twle/tentative\_monero\_015\_release\_schedule/
<hyc> sgp already announced it
<dEBRUYNE> sgp_: Perhaps worthwhile to mention in the comments why there is a bit of a delay
<sgp_> I don't know what happened with testnet
<ErCiccione[m]> el00ruobuob_ ignore what i said earlier, we need the logs :P

Overview and Logs for the tini2p Dev Meeting Held on 2019-09-19

Thu, 19 Sep 2019 00:00:00 GMT

Logs

<tini2p_gitlab> time of the meet
<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> h
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> A lot
<tini2p_gitlab> Finished tunnels impl, and merged into master
<tini2p_gitlab> (with helpful review from @DavidBurkett)
<tini2p_gitlab> I'm still used to being the only person working on the project, so have to habituate myself to a workflow that includes other people
<tini2p_gitlab> started work on the router context (what ties all the pieces together)
<DavidBurkett> Don't change anything because of me. I'm slow and unreliable
<DavidBurkett> I'll catch up eventually, just keep doing what you're doing :)
<tini2p_gitlab> in the process, came across some impl bugs in NTCP2 (fixed), updated NTCP2 to include a testnet v. mainnet netID, and started working on ECIES updates
<tini2p_gitlab> no worries, I just meant that you're the first other than me to review my code :)
<DavidBurkett> Haha, got it
<tini2p_gitlab> for the ECIES updates: there has been a lot of them
<tini2p_gitlab> zzz pushed updates to move us to something much closer to standard Noise, and I love the changes
<tini2p_gitlab> it's a bit of work to change my impl, but all the changes are for the better
<tini2p_gitlab> the code is looking much cleaner now
<tini2p_gitlab> the cryptographic guarantees are stronger and more clear as well, which is the bigger win imo
<DavidBurkett> :rocket: Do you have a link to zzz's updates?
<tini2p_gitlab> you can follow my work in my context branch: https://gitlab.com/tini2p/tini2p/tree/context
<DavidBurkett> Ah perfect
<tini2p_gitlab> yeah, zzz's updates are pushed to the main 144 proposal: https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet
<tini2p_gitlab> we're still working out some kinks in the handshake, and will need to update the ratchet KDFs afterwards
<tini2p_gitlab> we are getting **much** closer to finalizing the spec though, which is awesome
<tini2p_gitlab> so, my impl may deviate from the spec a bit until we get everything figured out
<tini2p_gitlab> we're trying to get as close to standard Noise as possible, while maintaining the necessary properties for ECIES-X25519 stated goals
<DavidBurkett> That's great news
<tini2p_gitlab> definitely
<tini2p_gitlab> :smile_cat:
<tini2p_gitlab> the downside to all that is I've spent a good amount of time refactoring, so don't have code that is ready for a release candidate
<tini2p_gitlab> long-term it's for the best, in the short-term it's a slog to get to alpha release
<tini2p_gitlab> which leads to the next item
<tini2p_gitlab> 2: What's next
<tini2p_gitlab> continue the refactors for ECIES-X25519
<tini2p_gitlab> get something working for end-to-end crypto sessions, and work with zzz on fixing spec bugs (if/when they come up)
<tini2p_gitlab> finish the context impl
<tini2p_gitlab> create the docker testnet for local integration testing
<tini2p_gitlab> idk how long the docker testnet will take, but I'm hoping something minimal will be fairly easy to setup
<tini2p_gitlab> if it takes more than a day or two, I'll push an alpha release candidate without the testnet
<tini2p_gitlab> the biggest hurdle I see for the testnet is populating the NetDB of the routers with the RouterInfos of the other routers in the testnet
<tini2p_gitlab> I don't have reseed impled, so I'll have to do something manual
<zlatinb> you may find this useful: http://zzz.i2p/topics/2756-testnet-with-lxc-instructions
<tini2p_gitlab> really hoping this is the last time I'll have to say this: pushing the alpha release date back another two weeks
<tini2p_gitlab> awesome! thank you @zlatinb :)
<zlatinb> also talk to "obscuratus" on Irc2P, he has a mixed i2pd/java i2p testnet, also with lxc
<tini2p_gitlab> right on, I'm hoping to do it with docker for eventual windows support
<tini2p_gitlab> right now, tini2p only builds on linux. will be working on cross-platform builds post-alpha
<tini2p_gitlab> there's probably a lot of crossover in approach to lxc, so I appreciate the resources. will definitely be reaching out to obscuratus
<DavidBurkett> Builds on mac also
<DavidBurkett> But of course, that's based on linux
<DavidBurkett> I nearly had it building on windows, but I got frustrated and quit :)
<tini2p_gitlab> haha wow, thanks for build testing
<tini2p_gitlab> yeah, I imagine the windows experience is pretty hellish atm
<DavidBurkett> np, wasn't intentional. I'm the 0.1% of devs who prefers windows
<DavidBurkett> So I tried there first
<DavidBurkett> It wasn't quite as bad as you might think, but 1 of the dependencies was pissing me off lol
<tini2p_gitlab> noise-c?
<DavidBurkett> Yes, that's the one
<tini2p_gitlab> yup
<tini2p_gitlab> that's a bear
<tini2p_gitlab> I'll be moving all the noise stuff into the project proper, and remove the noise-c lib
<tini2p_gitlab> it's a great reference, but making it cross-platform is such a pain
<DavidBurkett> Excellent. Let me know when you want me to try building again
<tini2p_gitlab> will do, I appreciate the offer
<DavidBurkett> :thumbsup:
<tini2p_gitlab> long-term I hope to contribute a CMake build system to noise-c
<tini2p_gitlab> atm that's low priority though
<tini2p_gitlab> that will be extremely time-consuming, but I want to give something back to the project
<tini2p_gitlab> rweather did a lot to help me understand Noise :)
<tini2p_gitlab> so, that's more-or-less what I'll be working on: router context, ECIES updates, some NetDB stuff, docker testnet
<tini2p_gitlab> 3: Questions/comments
<tini2p_gitlab> alright, so that's the meeting
<tini2p_gitlab> will do my best to get a release candidate out by next Thursday, and alpha release the following week
<DavidBurkett> Looking forward to it
<tini2p_gitlab> :+1:
<tini2p_gitlab> 4: Next meeting
<tini2p_gitlab> 2019-10-03 18:00 UTC
<tini2p_gitlab> holy shit, we're already almost in October
<tini2p_gitlab> thanks all for attending
<tini2p_gitlab> @tini2p_gitlab twirls the gavel

Logs for the Monero Research Lab Meeting Held on 2019-09-16

Mon, 16 Sep 2019 00:00:00 GMT

Logs

<sarang> OK, it's time for the meeting!
<sarang> Agenda: https://github.com/monero-project/meta/issues/390
<sarang> Logs posted there afterward
<sarang> GREETINGS
<mikerah> Hello
<sarang> I'll wait a couple of minutes in case anyone else shows up
<kinghat> o/
<kinghat> *the regular crowd shuffles in*
<el00ruobuob> Hi
<sarang> Our pal suraeNoether said he may not be available for today's meeting
<sarang> But I can share some of the things I've been working on for our ROUNDTABLE
<sarang> The ever-clever RandomRun posted an idea for a signature scheme earlier: https://github.com/monero-project/research-lab/issues/56
<sarang> Some updates have been made for efficiency, and I worked up proof-of-concept code: https://github.com/SarangNoether/skunkworks/tree/lrs/lrs
<sarang> And a timing/space analysis: https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
<sarang> (I gave it the name Triptych as a placeholder, so we have a name to use for clarity)
<sarang> It actually beats Lelantus in terms of 2-2 transaction size
<sarang> But verification is less efficient
<sarang> Also note that security hasn't been proven yet, but it uses a modification by Bootle et al. to a 1-of-N proof by Groth
<sarang> and that 1-of-N has good proofs
<sarang> Aside from that, I've been working with the Lelantus authors on some ideas to fix its self-spend tracing problem
<sarang> And that's coming together nicely
<sarang> The CLSAG paper will be submitted to Financial Cryptography this week
<sarang> And my CCS funding request for next quarter has been opened: https://ccs.getmonero.org/proposals/sarang-2019-q4.html
<sarang> On a more whimsical note, a preprint was just posted that does some analysis on a card-based cipher originally designed by Bruce Schneier for a book: https://arxiv.org/abs/1909.06300
<sarang> It's a neat example of a cipher that appears to resist a good deal of modern cryptanalysis, but can be done using paper, pen, and a deck of playing cards!
<mikerah> ElsieFour also has such properties except without the playing cards.
<sarang> Ah, and I'd be remiss if I didn't mention the trustless recursive SNARK paper, Halo, that was recently posted by the Zcash folks
<sarang> mikerah: I wasn't familiar with that!
<sarang> Has it undergone much analysis?
<mikerah> Here's the preprint: https://eprint.iacr.org/2017/339.pdf
<sarang> neat
<mikerah> I'm not sure if it has gone through much analysis as it's a relatively new construction.
<mikerah> But you can use paper and pen!
<sarang> Halo has some clever ideas in it, but it's worth noting (as usual) that preprints don't undergo peer review, and that Halo currently lacks a soundness proof
<sarang> It will be fun to see the new research that comes from its ideas
<sarang> Any particular questions on the items that I mentioned?
<mikerah> How would the ideas from lelantus get implemented in monero?
<sarang> Its transaction model could, hypothetically, be implemented directly
<sarang> Using a particular kind of migration transaction to transition older outputs
<sarang> It would result initially in a smaller anonymity set
<sarang> Currently Lelantus has a tracing issue that's a deal-breaker IMO
<sarang> but very recent ideas mean that may not be a problem
<mikerah> Would there be traceability problems from the current monero blockchain to this hypothetical lelantus+monero blockchain?
<sarang> How so?
<mikerah> As in, would it be possible to trace transactions between hard forked blockchains
<sarang> In such an implementation, old-style transactions would not be allowed
<sarang> Old outputs would undergo a signer-ambiguous transaction to generate a new output commitment that is Lelantus-compatible
<doxxy> sarang: greets
<sarang> So a migration is trivially distinguishable, but retains the same kind of signer ambiguity that exists now
<sarang> hi
<sarang> To be clear, there are no plans to implement this AFAIK
<mikerah> I see. I guess more work would need to be done on this front.
<sarang> It's all just research
<sarang> Anyway, that's what I've been working on
<sarang> Does anyone else wish to share interesting research?
<sarang> OK!
<sarang> Well, in that case my ACTION ITEMS are administrative stuff for FC submission, ongoing analysis of Lelantus modifications and proofs, and returning to some existing recent proving systems
<sarang> Before we adjourn, is there anything else to discuss?
<gingeropolous> i don't have any research im working on, but im enjoying banging my head regarding the randomx branch prediction problem
<sarang> Go on!
<gingeropolous> so, big chunk of CPU silicon dedicated to branch prediction. Turns out a lot of the methods use neural networks kinda thing (called perceptron at one point).
<gingeropolous> however, problem is that randomx is random - its random whether a branch will be taken
<gingeropolous> and when somethings random, hard for machine-learning / pattern recognition to get any gains
<sarang> Makes sense
<gingeropolous> however, if you try and seed random into the program (such that a branch predictor could find some emergent pattern), this information could be harvested by an ASIC or some other mitigation
<gingeropolous> so, my head sorta got stuck at that point... and if it'd be possible to somehow hide the emergent pattern... and then all the thought threads frayed
<sarang> So, using information from existing CPU architectures in order to develop better specialized hardware?
<sarang> Or information from any kind of well-designed predictor, I suppose
<gingeropolous> well the general randomx problem is to make a PoW that leverages stuff in CPUs.
<gingeropolous> and branch prediction is underleveraged due to the problem i just described
<sarang> Ah, ok
<sarang> I don't know enough about CPU branch prediction to fully appreciate this, but it sounds interesting nonetheless
<sarang> Anything else of interest to share before the meeting ends?
<sarang> All righty then
<sarang> Thanks to everyone for being here; we are now adjourned!
<sarang> Logs will be posted shortly

Logs for the Community Meeting Held on 2019-09-14

Sat, 14 Sep 2019 00:00:00 GMT

Logs

Logs for the Monero Research Lab Meeting Held on 2019-09-09

Mon, 09 Sep 2019 00:00:00 GMT

Logs

<sarang> GREETINGS
<suraeNoether> howdy!
<ArticMine> Hi
<xmrmatterbridge> <worriedrise> Hello
<sarang> For our ROUNDTABLE, I can go first
<sarang> A meta-note is that my next funding request needs feedback to determine if/when it should be opened: https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/96
<sarang> Aside from that, I've been working on inner-product proofs from IACR 944, which I know kenshamir[m] has also been working on
<sarang> Some neat efficiency things going on with those: https://github.com/SarangNoether/skunkworks/tree/944-ipa-nozk/ipa-nozk
<sarang> I've received plenty of edits/feedback to get the CLSAG paper submitted by its deadline
<suraeNoether> *thumbs up for clsag*
<sarang> And our friend RandomRun had a neat idea for applying a Groth proving system to transactions, detailed in a GitHub issue: https://github.com/monero-project/research-lab/issues/56
<suraeNoether> that proving system is also the basis for bootle's sublinear ring signatures, which was the basis for RTRS once upon a time
<sarang> The sizes are pretty big, but it may be possible to use some tricks from another paper to shrink them down
<suraeNoether> it's a strong foundational paper
<sarang> Yeah, it's used in Lelantus too
<sarang> That's my two cents so far
<sarang> suraeNoether: ?
<mikerah> Hello
<suraeNoether> my updates involve 1) matching, 2) proof of knowledge of signatures, and 3) looking at omniring as a general proving system for various uses
<suraeNoether> re: 1) i've made a bunch of local commits that i'll be squashing and pushing in a day or so
<suraeNoether> re: 2) i've identified a few of the foundational papers i'll be using to make my argument
<suraeNoether> re: 3) is a lot of reading and asking sarang questions
<sarang> neat
<sarang> Before we do questions and discussion, any other interesting work to share?
<suraeNoether> that's pretty much it so far; i have a stack of papers i've annihilated in the past few weeks, ranging from BOLT to bilinear pairings papers, but a lot of it has been background reading
<sarang> All right, we can also do QUESTIONS now
<sarang> suraeNoether: sounded from earlier like the PoKoS would likely require pairing operations?
<mikerah> I have a question. A few weeks back, I came on here asking about minimal smart contracts. I'm still doing some thinking about this. It doesn't seem like monero has any form of storage. Is this correct?
<sarang> What do you mean by storage?
<suraeNoether> yeah, all the foundational stuff i've found ranges from "easy" to "moderate" in the pairings setting, but has zero solutions at all for the DL setting. so i'm looking sort of into how to solve some of these problems in the DL setting. If i make progress on that front, it'd be of independent interest to the larger research community *AND* it would allow for some weeeeird stuff in Monero
<kenshamir[m]> suraeNoether: I was reading the bulletin and saw this issue: "Tech note/MRL bulletin on placing STARKs inside bulletproofs"
<kenshamir[m]> Is there anymore information regarding this?
<kenshamir[m]> Issue: 43
<mikerah> @kenshamir: How would fitting a STARK inside a bulletproof work? I can see the opposite working, though.
<suraeNoether> kenshamir[m]: I wanted to write a technical note re: that topic, or i want someone else to write it. i'm interested in the details behind placing a Sapling-style statement inside of a bulletproof. this is work that the zcash folks have done already, apparently, but i want a formal write-up. it's a common idea a lot of folks have, so it'd be nice to have a document to point to re: efficiency etc
<sarang> AFAIK the zcash-related work was simply estimating sizes/times based on circuit complexity
<suraeNoether> mikerah: a bulletproof can prove statements about inner products about vectors. so you can take a Sapling-style statement and formalize it in a bulletproof
<suraeNoether> sarang: indeedily do, neighborino, that's my recollection as well
<sarang> Well, bulletproofs can prove things about circuits natively :)
<sarang> The range proofs that are commonly used are a less general application
<suraeNoether> *nod*
<sarang> (but are more efficient)
<mikerah> @sarang: storage as in extra space in a transaction that one can take advantage of for random stuff. Bitcoin blocks have extra space that people have used in the past to store messages. In Ethereum, there's calldata.
<mikerah> *extra space in a block
<sarang> There's an arbitrary data field that's also used to store certain transaction information and payment IDs
<sarang> tx_extra
<suraeNoether> we have tx_extra, but storing anything but uniform random data in it can lead to de-anonymization
<sarang> aye
<sarang> (or if not uniform random, "typical" data)
<suraeNoether> yeah
<suraeNoether> i should caveat that
<sarang> There have been ideas in the past for things like return addresses etc
<suraeNoether> if any data is stored in tx_extra, it should be encrypted
<mikerah> I see. I will continue thinking about this see if I can come up with something, eventually
<ArticMine> This begs the question how does one enforce encryption for tx_extra?
<sarang> should != must
<Inge-> What is the length limitation of tx_extra?
<xmrmatterbridge> <worriedrise> Have you looked into dual outputs for Lelantus? Maybe if instead using the hash of the signing key, it took the hash of two signing keys S = Hs(P||Q), then also perhaps the commitments for the timelock could be stored in triple commitment? I haven't thought much about it though.
<sarang> Inge-: AFAIK there is no hard cap (aside from any block-specific limits etc.)
<sarang> worriedrise: interesting, but why a triple commitment?
<sarang> That commitment could be stored as a standard Pedersen commitment along with the new outputs, could it not?
<xmrmatterbridge> <worriedrise> It could indeed. It would be one more point to store is all
<suraeNoether> "This begs the question how does one enforce encryption for tx_extra?" <-- add a tx_extra_valid field, change tx_extra to a pair of group elements, use switch commitments in tx_extra and in tx_extra_valid store a proof of knowledge of the opener of the commitment. if you stash plaintext in tx_extra, you won't be able to open it as a commitment... that'd be one way. but i don't think enforcing it is
<suraeNoether> necessarily a good idea...
<suraeNoether> ArticMine: ^
<ArticMine> There is a possible attack vector if unencrypted data in tx_extra is enforced or an incentive is provided. This came up in the payment id discussion
<suraeNoether> *nod* but enforcing that stuff in tx_extra "looks uniform" can only go so far before head-meets-brick-wall
<kenshamir[m]> Reading a bit slow; sarang For rangeproofs, are you looking to switch out the inner product argument being used currently in bulletproofs for the one being used in 944?
<sarang> Oh, I was just tooling around with it
<kenshamir[m]> For the record, I think previously I mentioned 944 modifying bulletproofs inner product proof�, but bulletproofs is an inner product argument� also
<kenshamir[m]> Oh right
<sarang> ?
<kenshamir[m]> <sarang "?"> In case I said it in a previous monero meeting, not sure
<sarang> Yeah, I was playing around with the algebra needed to get the 944 IPA playing nicely with the optimized verification in BP
<sarang> righto
<sarang> It sounds like the 944 authors did implementations of the BP range proofs with both inner product arguments, and claimed a fairly substantial speedup, if I'm reading correctly
<sarang> A much bigger speedup than I'd expect
<ArticMine> suraeNoether Right one can enforce encryption but one cannot prevent out of bounds publication of the decryption key
<kenshamir[m]> <sarang "It sounds like the 944 authors d"> Yep, I am trying to verify this against Dalek's implementation, but I have paused as something in the paper does not make sense to me at the moment
<sarang> kenshamir[m]: what's that?
<kenshamir[m]> Hopefully, I can get an asnwer on it and benchmark against Dalek's optimised implementation
<kenshamir[m]> <sarang "kenshamir: what's that?"> The \Gamma_{i} that is mentioned multiple times
<kenshamir[m]> Which is of size n-2 x n-2
<sarang> I assume, for example, that the 944 authors didn't unroll the IPA recursion in verification
<kenshamir[m]> Only holds on quadratic equation
<kenshamir[m]> I originally thought that it would hold n-2 quadratic equations
<sarang> Why would this be important for the underlying non-zk IPA?
<kenshamir[m]> <sarang "I assume, for example, that the "> Yep, I will need to implement your code in order to make the benchmarks fair because Dalek's code does this
<sarang> My suspicion is that the unrolled recursion wipes out almost all of the speedup
<sarang> Since most of the optimizations appear to be in scalar operations only
<kenshamir[m]> <sarang "Why would this be important for "> It does not make sense to me that a matrice only holds one equation, unless there is something I have misunderstand
<sarang> But this doesn't affect any uses of _only_ the underlying non-zk IPA, correct?
<sarang> So you don't mean that misunderstanding is a holdup for testing of the IPA for rangeproofs alone?
<kenshamir[m]> <sarang "My suspicion is that the unrolle"> Plus Dalek use a batch_invert function for Scalars, so this may absolutely be the case
<sarang> Yeah, we also batch the inversions
<sarang> so it's really just a single inversion and some scalar-scalar multiplications (which are essentially free)
<kenshamir[m]> <sarang "So you don't mean that misunders"> I implemented the code using dense matrices, which is really in-efficient. I think there will be a big difference if we can store n-2 equations in one matrice, versus storing n-2 matrices of size n-2 x n-2
<sarang> Right, but if you're only testing a swap of the inner product argument in the bulletproofs rangeproof, you don't need any of the "higher-level" protocols
<sarang> the non-zk IPA stands on its own
<kenshamir[m]> <sarang "Right, but if you're only testin"> Oh right, I get what you mean
<sarang> This is what I assume that table at the end of 944 was doing
<sarang> For the general applications, totally
<sarang> I think we're on the same page :D
<kenshamir[m]> I was thinking of benchmarking 944 rangeproof vs bulletproofs. But you are correct, in that we also need to benchmark 944s IPA_Nozk vs bulletproofs IPA
<sarang> The paper seems to have both
<sarang> Perhaps the latter benchmarks were only in the extended 944 paper (I'd have to check)
<sarang> but no matter reallly
<sarang> AFAICT the last timing table is just swapping the non-zk IPA
<kenshamir[m]> Yeah it had both, the benchmarks show that they are basically the same once bulletproofs uses IPA_NoZK
<kenshamir[m]> Yeah
<sarang> Although the speedup was still impressive from just IPA_NoZK (hence wanting to know if unrolling makes it irrelevant)
<sarang> something like ~30% IIRC?
<sarang> which seems absurd
<kenshamir[m]> Yeah, it was in that ballpark
<sarang> Still, worth a shot anyway to confirm :)
<sarang> Probably will be worth writing to the authors to note this
<kenshamir[m]> I will also test the normal IPA_NOZK without multi-exp versus bulletproofs with multiexp
<sarang> I'll send them my unrolling algorithm too, to provide better benchmarks
<sarang> Multiexp will be huge, of course, in any of the applications
<sarang> when the size gets large
<kenshamir[m]> They used a generic library too, so this could play a role in the benchmarks
<kenshamir[m]> Not sure how/if though
<kenshamir[m]> <sarang "when the size gets large"> Yep
<sarang> Yeah, but that shouldn't matter, ideally, if they did parallel implementations
<sarang> But hey, that's part of the point of a preprint, I suppose
<sarang> Get feedback and additional info!
<sarang> Perhaps we can collaborate on feedback to the authors, kenshamir[m]
<sarang> once we have numbers on this stuff
<sarang> I think it would be useful in their paper to note these things
<kenshamir[m]> <sarang "Perhaps we can collaborate on fe"> Yep that would be great
<sarang> awesome
<kenshamir[m]> Yeah, because this was one of the more important contributions of the paper
<sarang> for sure
<kenshamir[m]> The proof system was also great
<sarang> 10/10 would verify?
<sarang> =p
<kenshamir[m]> :D
<sarang> In the interest of time, are there other questions?
<sarang> OK!
<sarang> On to ACTION ITEMS before we close
<sarang> I'll be continuing several things: proving systems, benchmarks, paper submission
<sarang> Feel free to comment on the proposed funding request, to determine if it should be opened
<sarang> suraeNoether: your action items?
<suraeNoether> ah, yes, sorry about that: squashing a bunch of commits for matching, to whip thring signatures into shape for the FC conference, and to start putting my ideas on POKOS down
<suraeNoether> but mainly matching, because that is so close to giving good results
<sarang> Awesome! Any other action items to share before we close?
<suraeNoether> just that i love all of you
<suraeNoether> be sure to comment on sarang's proposal request/comment period
<kenshamir[m]> 😳
<sarang> Aw shucks
<sarang> Thanks to everyone for participating! Logs will be posted to GitHub shortly

Overview and Logs for the Dev Meeting Held on 2019-09-08

Sun, 08 Sep 2019 00:00:00 GMT

Logs

<rbrunner> Looks like meeting will start in a few minutes. Stay tuned.
<hyc> time?
<hyc> who's already here?
<moneromooo> Well, it can start now. Who wants to say anything ?
<vtnerd__> present
<jtgrassie> hola
<rbrunner> Hi
<moneromooo> I've been working on a "sync pruned blocks" patch, it's proving annoying to test but it's almost ready.
<rbrunner> Asking around until get the full block?
<hyc> I'm reworking the randomx integration patch, it has gotten ugly with the added tweaks over the past few months
<moneromooo> I do not understand that question.
<hyc> and currently the daemon mining support is broken
<rbrunner> I mean what means "sync pruned blocks"
<moneromooo> You asked for pruned blocks when you can, rather than full blocks that you'd then prune.
<dEBRUYNE> hyc: Could you define ugly?
<rbrunner> Ah, ok. Thans
<rbrunner> Thanks
<hyc> dEBRUYNE: two different code paths for main blocks vs altchain blocks
<rehrar> hello, apologies for tardiness
<hyc> ought to be able to consolidate it back into 1
<hyc> but need to step back and rethink the overall structure
<moneromooo> (it's to save network bandwidth btw, it doesn't save more db size)
<rbrunner> How does reworking of RandomX PR look in regard to the calendar?
<hyc> well, it always takes 2-3 days to test and verify that the network is behaving
<jtgrassie> fwiw hyc, current state of pr seems to be working now
<rehrar> It's September, do we have a hard fork date?
<hyc> jtgrassie: we haven't crossed a nother epoch boundary yet, I don't think
<jtgrassie> ^ good point
<moneromooo> No fork date yet.
<rehrar> We were thinking Octoberish though, no?
<moneromooo> We were.
<hyc> I would assume mid-October
<hyc> we ought to be nailing that date down
<rehrar> so in theory there is a hypothetical freeze coming mid September? :D
<moneromooo> Though the randomx code being still changed makes me nervous about mid october.
<tevador> hyc: for testing, you could shorten the epoch to 128 blocks, then you can test it in 2 hours
<rehrar> fluffypony luigi1111 ArticMine smooth binaryFate ?
<hyc> tevador: we did that when the PR was originally written. for some reason the current problems never showed up then.
<dEBRUYNE> hyc, tevador: The recent change were made after audit recommendations or?
<hyc> successfully mined millions of blocks with epoch=128
<dEBRUYNE> Recent changes to RandomX
<tevador> that was with a private testnet perhaps?
<hyc> dEBRUYNE: changes to RandomX itself are independent of the randomx integration patch
<hyc> tevador: true
<tevador> dEBRUYNE: most changes were made based on audit recommendations
<dEBRUYNE> I see. I guess if we need more time we can always push it back to end of October, but most people and services are expecting a fork in October
<rehrar> dEBRUYNE: are they though?
<moneromooo> Nobody expects a monero fork.
<hyc> we could always release with daemon mining disabled, and fix it up in a point release if we need to
<hyc> since xmrig is already available
<rehrar> I realize we don't have to go Verge vaporware extreme where we push back indefinitely, but I think people are used to some "delays" if it means code that works from the get go (hopefully)
<rehrar> especially if it's just a couple of weeks
<hyc> but I'm pretty sure I can get a new patch ready in the next couple days
<tevador> hyc: I think you could change the testnet epoch to 128 blocks even for public testing
<rbrunner> No mining in daemon would make me nervous, I have to admit
<hyc> tevador: yeah I guess we can try that.
<endogenic> hello all
<rehrar> dsc_ or selsta here also?
<hyc> speeding up test verification to 2 hours would certainly help
<endogenic> i may be in and out
<selsta> yes
<rbrunner> Would also be a minor PR defeat, so to say, after telling everyboding about restoring everybody's capacity to mine
<hyc> my cat just died
<endogenic> :(
<hyc> ^ joke
<endogenic> o
<rehrar> I think launching with daemon mining is pretty crucial. Shows we are prepared and not reliant on just one software for it, no?
<dEBRUYNE> hyc: Oh, then we should still have plenty of time
<dEBRUYNE> There's like 6 weeks left until mid october
<hyc> ok then should be no problem
<dEBRUYNE> rbrunner: Yes I tend to agree. I'd prefer to release v0.15.0.0 with full functionality
<rehrar> selsta: what's the state of the GUI as we march toward this fork?
<tevador> yeah, we should make sure daemon mining is working, especially since there is not much difference in hashrate between xmrig and monerod
<dEBRUYNE> With respect to branching, I guess we just keep merging stuff into master until the RandomX pull request is ready?
<moneromooo> There's certainly more stuff to be merged atm.
<rbrunner> Pragmatic approach :)
<selsta> xiphon added simple mode public node discovery without a centralized service, I did some redesigned the balance card, dsc is working on i2p
<hyc> makes sense
<jtgrassie> we shouldn't release a pow change and it being reliant on some third party miner
<selsta> also small things
<endogenic> moneromooo: hyc i just got it
<hyc> lol
<rehrar> it seems like this is shaping up to be a standard Moenro fork :P
<rehrar> we'll have our standard debriefing afterward with our similar standard complaints
<rehrar> anything else currently being worked on?
<tevador> how long was the code freeze last time?
<hyc> oh well. the integration PR was pushed in May. if more people had been testing it since then we could've found this earlier
<rbrunner> Last time was quite rushed because of the "ASIC emergency"
<hyc> as it is, we found the problems on testnet, so that at least served its purpose
<rbrunner> Are the Wownero people running smoothly then? If yes, why?
<hyc> they aren't using daemon mining
<rbrunner> Oh
<jtgrassie> amuses me how the problem exists in loki and wow
<rehrar> does anyone take Wownero seriously as a testing bed? Serious question.
<hoochu> This problem is likely will not be detected unless someone mined 3 long altchains with epoch boundary in the middle privately and exposed them to hyc`s testnet
<hoochu> *would not be
<sech1> yes, mining issue only happens when there are long altchains across epoch boundary
<hoochu> I had another initial attempt when did that
<moneromooo> "long" means that one block on each side would not be enough to trigger ?
<sech1> not necessarily long, I guess they need to have different seed hashes
<nioc> RandomX was released for wow will only daemon mining, tthere were no 3rd party miners at first
<tevador> must be at least 64 blocks I think
<sech1> so 64 blocks is enough if split block is chosen carefully
<hoochu> I suppose enough but noone tried to expose them before daemon miner even started to mine epoch boundary block
<moneromooo> OK. I'll see if I can add tests for this.
<hoochu> There was a race
<rbrunner> That sounds like an awfully special situation
<sech1> yes
<hyc> yes, but one which any attacker can construct
<hoochu> And noone claims that he tested all possible special situations
<sech1> other than that, it works
<hoochu> But it's better test all of them
<rbrunner> Mining ahead 64 mainnet blocks? Good luck for that attacker :)
<rbrunner> But I understand of course.
<hoochu> rbrunner, you're wrong
<sech1> technically, you don't need 64 valid blocks to do it
<hoochu> mine 2 blocks before mainnet and expose them immediately
<sech1> just 64 blocks to trigged node to verify them
<sech1> and boom
<sech1> it's broken
<hyc> anyway we don't need to occupy the rest of the meeting with this
<hyc> discussion in -pow
<rehrar> kinda fascinating though
<rehrar> are there any questions about specific issues or PRs?
<rbrunner> Remember when PoW algorithms were easy and simple ...
<rehrar> no core team seems to be here though :/
<hyc> rbrunner: I suppose we'd have similar problems with any PoW scheme that references previous blocks
<hoochu> this problem exist due to complex dependencies in monerod and lack of people to know all of them to write correct code but not local small changes
<hoochu> *that know all of them
<moneromooo> tewinget: if you're still working on loki: ^
<rehrar> is vtnerd here?
<rehrar> I think he said in one of the previous meetings that his networking stuff will probably not be ready in time, correct?
<dEBRUYNE> <rehrar> so in theory there is a hypothetical freeze coming mid September? :D <= I guess branching is technically a freeze right? Because typically only fixes go into the branch
<rehrar> though it doesn't need a hard fork for his stuff so it doesn't matter
<dEBRUYNE> rehrar: Yeah I think he said the dandellion++ stuff would not be ready in time
<iDunk> vtnerd__: can you take a look please https://paste.debian.net/hidden/bccdc3a2/
<dEBRUYNE> His white noise PR has been merged though
<iDunk> That's a MacOS depends build with Clang 3.7.1
<rehrar> was there anything else that needed discussing?
<rehrar> alright, so it looks like we can call it here for the meeting
<rehrar> discussion can obviously continue afterwards on various topics
<rehrar> I'll try to ping core team peeps to be present for next meeting since we're drawing very close to a fork

Overview and Logs for the tini2p Dev Meeting Held on 2019-09-05

Thu, 05 Sep 2019 00:00:00 GMT

Logs

<tini2p_gitlab> meeting time!
<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> l
<DavidBurkett> :wave:
<tini2p_gitlab> :)
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> opened merge request for tunnels implementation: https://gitlab.com/tini2p/tini2p/merge\_requests/15
<tini2p_gitlab> it's a large amount of work (around a month's worth), so I'm going to leave it up for a bit (few days)
<tini2p_gitlab> going to take a day away from that code, and come back to it for manual review
<DavidBurkett> Awesome! Is there anyone from i2p actively reviewing it? If not, I'll review with what little knowledge I have
<tini2p_gitlab> remember how I said "hopefully, no more major refactors", well so much for that. I overlooked some parts of OutboundEndpoint and InboundGateway processing, and had to refactor how I extract I2NP fragments from tunnel messages
<tini2p_gitlab> @DavidBurkett many thanks! I'm the only active reviewer, so any input from you is very welcome
<tini2p_gitlab> fresh eyes are always helpful
<DavidBurkett> :thumbsup: I'll take a look
<tini2p_gitlab> there are still some aspects of peer selection that remain, mostly around restrictions of peers from the same /16 IPv4, and any given peer only participating in ~33% of active tunnels
<tini2p_gitlab> not sure what layer of abstraction I should enforce those restrictions. right now, those restrictions make sense at the RouterContext layer for my impl, but TBD
<tini2p_gitlab> the RouterContext will ultimately be pulling peers from NetDB, and feeding them into the PoolManager
<tini2p_gitlab> so the work in that PR represents what I've been working since last meeting
<tini2p_gitlab> a lot of time was spent on peer profiling and tunnel testing
<tini2p_gitlab> and the refactors for the OutboundEndpoint sending a TunnelGateway message when the delivery is to another tunnel
<tini2p_gitlab> from the existing I2P docs, it's not very clear when the different tunnel delivery types are used (Local, Router, Tunnel)
<tini2p_gitlab> it took me implementing the things, and thinking about how the pieces fit together to really make sense of it
<tini2p_gitlab> basically, afaiu, Local is used by the InboundGateway to tell the InboundEndpoint, "this message is for you"
<tini2p_gitlab> Router is used by the OutboundGateway to tell the OutboundEndpoint (and maybe IBGW to IBEP) that the I2NP message should be directly delivered to a router
<tini2p_gitlab> e.g. for DatabaseStore and DatabaseLookup messages
<tini2p_gitlab> Tunnel delivery is used by the OutboundGateway to tell the OutboundEndpoint (and maybe IBGW to IBEP) that the I2NP message should be delivered to the InboundGateway of another tunnel
<tini2p_gitlab> Router and Tunnel don't make sense to me for inbound tunnels, unless some form of chaining is used. not clear that it ever is from the specs
<tini2p_gitlab> for example, if Alice sends an I2NP message through an outbound tunnel to the IBGW of another tunnel (with some indicator for chaining), and that IBGW uses Router or Tunnel delivery to tell the IBEP to deliver the I2NP message to the IBGW of yet another tunnel
<tini2p_gitlab> maybe that exists, but I've implemented IBGW only using Local delivery to send I2NP messages to the IBEP
<tini2p_gitlab> Local delivery is never used for outbound tunnels
<tini2p_gitlab> anyway, figuring all that out took a bit of time, and I may send spec diffs upstream to clarify the use of the different delivery types
<tini2p_gitlab> 2: What's next
<tini2p_gitlab> RouterContext
<tini2p_gitlab> and associated classes
<tini2p_gitlab> this set of classes will be the main brains tying everything together
<tini2p_gitlab> RouterContext will use the transport (NTCP2) to talk directly to other routers
<tini2p_gitlab> it will use an I2NP handler to either pass messages to the NetDB or Tunnel PoolManager for further processing
<tini2p_gitlab> similarly, resulting messages from NetDB and Tunnel processing will be returned to the RouterContext, and sent back out over NTCP2 to the appropriate router
<tini2p_gitlab> the RouterContext will also be the main owner of the router's RouterInfo
<tini2p_gitlab> LeaseSets for local InboundTunnels will also be compiled by the RouterContext, and stored in the NetDB
<tini2p_gitlab> setting a goal for myself to have the RouterContext finished (in a minimally working sense) by next Thursday (2019-09-12)
<tini2p_gitlab> with RouterContext finished/merged, I will tag a release candidate
<tini2p_gitlab> I will be implementing a Docker/container test network for integration/end-to-end testing, to ensure all the pieces work together
<tini2p_gitlab> I will also make changes to match the latest updates to ECIES-X25519, posted by zzz this past weekend
<tini2p_gitlab> ECIES-X25519 changes will also go into the alpha release candidate
<tini2p_gitlab> with RouterContext and ECIES-X25519 changes in place, tini2p will have an internally consistent implementation of I2P
<tini2p_gitlab> and I will tag the alpha release a week after the release candidate
<tini2p_gitlab> after alpha release, I will focus on ElGamal tunnel building, and integration tests with Java I2P and i2pd
<tini2p_gitlab> end-to-end sessions will still be tini2p-to-tini2p, but tunnel building should be possible through Java I2P and i2pd
<tini2p_gitlab> the Docker/container setup should be a nice testbed for inter-implementation testing, so hopefully it will be useful for other implementations as well
<tini2p_gitlab> TBD
<tini2p_gitlab> post-alpha release will also get some (a huge amount) of fuzz tests
<tini2p_gitlab> basically every class with a deserializemethod or buffer input interface, will be getting a fuzz driver attached to it
<tini2p_gitlab> I may also be taking a small break from tini2p post-alpha release to preemptively prevent burnout
<tini2p_gitlab> these past nine months have been basically coding tini2p everyday, often 10-12+ hours a day
<tini2p_gitlab> 3: Questions/comments
<DavidBurkett> This project structure is really clean, and code easy to follow. Working on building now. You're doing great work
<tini2p_gitlab> aww :3 thanks @DavidBurkett that means a lot, very kind
<tini2p_gitlab> still needs a lot of work to be production-ready, but I'm doing my best to code well
<tini2p_gitlab> some of the structure is heavily influenced by portions of Java I2P, i2pd and ire. there are some really good bits in those codebases
<DavidBurkett> Well I'm just talking your cmake files, your handling of dependencies, etc. Very clean
<DavidBurkett> And I've seen i2pd. This is night and day better (although i2pd is pretty easy to work with)
<DavidBurkett> [edit] And I've seen i2pd. This is night and day better (although i2pd is also pretty easy to work with)
<tini2p_gitlab> i2pd has very different project goals and design. i2pd aims to be a one-stop-shop router, tini2p aims for use as an I2P library by other projects
<DavidBurkett> Ah, that makes sense
<DavidBurkett> I assumed i2pd was also meant to be used as a library
<tini2p_gitlab> the CMake and dependencies took influence from Kovri (and by extension i2pd)
<tini2p_gitlab> i2pd can also be used as a library
<tini2p_gitlab> what I mean is that i2pd contains an HTTP server, router console, bundled client, all-in-one. somewhat similar to Java I2P, though with less apps bundled in
<DavidBurkett> :thumbsup: Understood
<tini2p_gitlab> tini2p moves away from that singleton design, into something highly modular
<tini2p_gitlab> a future goal is to split tini2p up further, having common structures be its own repo, with separate core and client libs
<DavidBurkett> Makes sense. Yea, I pulled i2pd into Grin++ at one point, but I had to decouple a bunch of things to be able to just pull in what I want. It wasn't a straightforward task
<tini2p_gitlab> that's somewhat far down the line though, but it would support stuff like pluggable end-to-end and signing crypto
<DavidBurkett> That's awesome, you'll get there for sure.
<tini2p_gitlab> :) thank you
<tini2p_gitlab> alright, think that's about all for this meeting. unless you have something else @DavidBurkett?
<DavidBurkett> Nothing from me
<tini2p_gitlab> for sure
<tini2p_gitlab> 4: Next meeting
<tini2p_gitlab> 2019-09-19 18:00 UTC
<tini2p_gitlab> thanks all for attending (that means you @DavidBurkett ;)
<DavidBurkett> :smile:
<tini2p_gitlab> @tini2p_gitlab stares intently at the gaffer, wondering if it feels

Logs for the Monero Research Lab Meeting Held on 2019-09-02

Mon, 02 Sep 2019 00:00:00 GMT

Logs

<sarang> Agenda: https://github.com/monero-project/meta/issues/388
<sarang> (logs posted there afterward)
<suraeNoether> good morning everyone
<sarang> GREETINGS
<rottensox> Hola.
<sarang> Happy Labor Day to those celebrating it
<sarang> Happy Monday to all others
<sarang> Let's do our ROUNDTABLE
<sarang> suraeNoether: care to go first?
<suraeNoether> sure. This past week i've been coding my economarkov chain simulating a fake Monero economy to apply matching to. this is slow-going, but steady progress. in addition to that, I started reading 3 separate papers for a new-ish idea...
<suraeNoether> https://eprint.iacr.org/2016/583.pdf , https://www.microsoft.com/en-us/research/wp-content/uploads/2008/02/tcc2008.pdf , and https://link.springer.com/chapter/10.1007/3-540-36413-7\_20
<suraeNoether> the idea is new-ish to me but not the e-cash community, which is to demonstrate not a valid signature on a public message m, but *knowledge of* a valid signature on a public message m, without revealing the signature information like signer
<suraeNoether> that 583 paper presents a trustless way of doing so with hash functions that can be described with a boolean circuit, and presents zk proofs of knowledge of RSA, DSA, and ECDSA signatures
<suraeNoether> the idea is to replace ring signatures with something that is trustless and signer ambiguous
<sarang> Interesting
<suraeNoether> that way, instead of saying "Either A, B, or C signed this m with key image J," the statement being proven is "I have seen a valid signature on m with key image J"
<sarang> Requires efficient trustless accumulator?
<suraeNoether> coupling this together with a zk proof of membership in a strong dynamic accumulator allows for a "signature" scheme that does away with the explicit anonymity sets of ring signatures
<suraeNoether> i think i'm onto a method for doing this with key images that are compatible with our current approaches
<sarang> Nice!
<suraeNoether> but I need, probably, 2-3 additional pairs of eyes helping me out, so I'll be writing some stuff up and possibly starting a github issue for discussion on the matter
<sarang> roger
<suraeNoether> other than that, i've been offline with family for a reunion + a 100-years-olds birthday party :D
<sarang> My monthly report details my recent activities, and is available now: https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/77#note\_7105
<sarang> Matching simulation review, updating papers, etc.
<sarang> Nothing earth-shattering over the past few days
<sarang> Very neat to hear about kenshamir[m]'s work on IACR/944
<suraeNoether> yes, i would like to hear more about that
<sarang> Is kenshamir[m] still here?
<kenshamir[m]> Hi
<kenshamir[m]> I’m here
<sarang> Anything specific you'd be interested to share about your recent work on proving systems?
<sarang> (no obligation to do so)
<kenshamir[m]> I think the most notable contribution from 944 that can be applied to bulletproofs straight away is the improved inner product argument
<kenshamir[m]> There are benchmarks which show that it gives significant improvements in verifier and prover efficiency
<mikerah> Is there no meeting today?
<sarang> In the general circuit case, correct?
<sarang> (the meeting is happening now)
<sarang> Not the optimized range proof application AFAICT
<kenshamir[m]> Yeah for 944s proving system it was the general case
<kenshamir[m]> I think if that if we tailored the proof to be specific for 944s proving system, we may be able to get a more efficient rangeproof. This is only a conjecture though and I’m unsure of how to do it at the moment
<sarang> The general case remains extremely interesting
<sarang> since the range proofs are quite efficient
<kenshamir[m]> For the general case asymptotically it is the same as the tailored bulletproofs rangeproofs from what I’ve seen
<kenshamir[m]> Yeah I agree. It will be really interesting to see what optimisations can be made with this language
<kenshamir[m]> *Quadratic Equation Sat
<kenshamir[m]> That’s all I’ve discovered so far from 944
<sarang> Thanks kenshamir[m]
<sarang> Does anyone else have interesting work to share?
<sarang> Or, for that matter, general questions
<sarang> Righto!
<sarang> We can also move to ACTION ITEMS, if there's nothing else urgent to discuss
<suraeNoether> my action items are short and simple. economarkov chain work, reading more on proofs of knowledge of valid signatures (which i'm considering calling redacted signatures), and my end of month work report.
<sarang> I will be doing some code review, continued work on proving systems, and ongoing work with suraeNoether on his recent updates to graph matching as needed
<sarang> Well, a short meeting today, but that's ok
<sarang> Anything final before we formally adjourn?
<sarang> Adjourned! Thanks to everyone for participating

Logs for the Community Meeting Held on 2019-08-31

Sat, 31 Aug 2019 00:00:00 GMT

Logs

Logs for the Monero Research Lab Meeting Held on 2019-08-26

Mon, 26 Aug 2019 00:00:00 GMT

Logs

<sarang> All righty!
<sarang> Let's begin our meeting
<sarang> Agenda: https://github.com/monero-project/meta/issues/385
<sarang> Logs will be posted there after the meeting
<sarang> GREETINGS
<rehrar> hi
<parasew[m]> hello
<suraeNoether> good morning
<sarang> Let's move to ROUNDTABLE
<sarang> suraeNoether: care to go first?
<suraeNoether> sure, last week I made a commit to my buttercup branch with some matching algorithm fixes, which is now operating as far as i can tell 100% smoothly
<sarang> Nice! Looking forward to reviewing it
<suraeNoether> i also have the framework for a markov chain simulator of a basic ledger almost ready to push later today, which we will be using to identify best practices while churning, etc
<suraeNoether> in addition to that, I discovered a discrete distribution over the weekend that could be very helpful in working with output selection
<suraeNoether> that's pretty much it. not tremendously eventful, except the matching algo unit tests
<sarang> Will be neat to see if we can adjust output selection to such a distribution efficiently and robustly
<sarang> Low priority in the grand scheme of things, but intriguing nonetheless
<sarang> I am finishing preparation of the CLSAG paper for submission to Financial Cryptography 2020
<hyc> definitely, will be nice to have some exploration of churning that we can document
<sarang> PR 5707 has been updated to simplify the hashing code
<suraeNoether> oh, sarang and i decided we should also submit the thring signature paper to FinCrypt2020 also, sort of doubling our chances (but not really, it's nonlinear :P)
<sarang> Note that this removes hashToPointSimple and moves its functionality directly into the relevant unit test
<sarang> hashToPointSimple is only used to produce a Pedersen generator, but it's brittle on arbitrary input and not useful elsewhere
<sarang> (unless we updated how we do hash-to-points to use an iterated index, but this is not backwards-compatible)
<sarang> Additional eyes on PR 5707 would be welcome
<sarang> And: Stanford announced the dates and CFP of their next blockchain conference
<sarang> TBH it's probably not worth our time to submit a paper/presentation, given their acceptance rate
<sarang> Unless anyone has an idea for something something zero knowledge ethereum =p
<sarang> I kid, I kid
<suraeNoether> *cough*
<suraeNoether> but not
<hyc> lol
<sarang> Finally, I continue analysis work on proving systems
<suraeNoether> 5707 is for how the second basepoint in our pedersen commitments are selected. if i recall from my conversation with sarang earlier, this PR will make the monero codebase slightly more robust, less brittle, more consistent with the way it works, and more importantly *more easily verified to be correct* by new users, even though it's a relatively small change
<sarang> RingCT3.0 is exploitable in its current form, but I'm told a forthcoming fix likely solves the problem (unclear if provably at this point) with little impact on efficiency
<sarang> suraeNoether: the change only makes it harder to use the wrong hashing method :)
<sarang> and enables slightly more efficient hash-to-point operations under some constructions
<sarang> Anyway, a new preprint (IACR/944) discusses a new proving system for more general constraint systems
<sarang> And there will be a forthcoming preprint with a proving system on pairing groups, which simplifies cleanly to non-pairing groups too
<sarang> I've been looking over that one, since the authors graciously provided an advance copy
<sarang> What will be interesting is whether the Omniring prover relations can be efficiently moved into a more general proving system
<sarang> Making it easier (in theory) to do future changes
<kenshamir[m]> Could you comment on the computational complexity when you simplify the proving system to a non-pairing group?
<sarang> Eventually =p
<sarang> I've only just begun working through that paper
<sarang> FWIW I'm told the preprint is quite imminent
<kenshamir[m]> Ahh alright, any idea when it will be released?
<sarang> ^^
<sarang> Oh and suraeNoether: the primary purpose of 5707 is to speed up MLSAG by removing redundant operations... this led to simplifications of the available hashing operations as a side effect
<suraeNoether> thanks for correcting that! i didn't realize the larger scope (just started going through it)
<sarang> and at that point it seemed like a good idea to remove the brittle hashToPointSimple and put it directly into the unit test that enables verification of how H was derived
<sarang> There are two commits: the second commit moves the hash stuff around
<sarang> the first commit alters the MLSAG code
<suraeNoether> gotcha
<sarang> All righty
<sarang> Does anyone else wish to share interesting research work?
<rehrar> :/ if I were that smart, sure
<sarang> Don't underestimate yourself!
<sarang> While we're at it, we can also do GENERAL QUESTIONS for anyone
<rehrar> well, I did read a recent paper on hormesis as it relates to beetles.
<sarang> lol
<rehrar> my skills are not going to be helpful here :P
<hyc> oh, you just reminded me of that stream of tweets from Sarah Jamie Lewis yesterday, about ants and alarm pheromones
<sarang> Regarding CLSAG, the plan is to submit to several relevant conferences/journals (in sequence) and hope for acceptance
<hyc> the relevance was to illustrating how localized decision making can be gamed / subverted
<sarang> It falls into an awkward spot: it's a neat improvement on earlier work with good security model/proofs, but isn't profoundly new
<sarang> And unfortunately you can't do simultaneous submissions :/
<hyc> (and thus an argument why you need global consensus)
<sarang> The FC deadline is in September, with notification by November 15
<hyc> lots of stuff isn't profoundly new, but the imporvement still is worth talking about
<sarang> Yeah, but that's tough for publication
<hyc> maybe different forums then. heck, chip manufacturers give big presentations on ~5-10% gains
<sarang> Hence doing a fair bit of rewriting for better context
<hyc> cool. yes, expanding the scope of applicability is also a good angle
<sarang> and page limits (grumble grumble stupid wide margins)
<sarang> Aaaaanyway
<sarang> Perhaps on to ACTION ITEMS
<sarang> I have several, and I don't expect to complete them all this week
<sarang> CLSAG revisions, in preparation for submission
<sarang> My doctoral adviser always recommended putting down a paper for a week after your revisions, so you can revisit it with fresh eyes before submission
<sarang> Second is a better understanding of the reduction of this forthcoming proving system to non-pairing groups
<sarang> Third is going over suraeNoether's completed matching code
<sarang> Since suraeNoether had to step away for a few minutes, I assume his action items are applications of his test-passing matching code, and preparation of the thring signature paper for its submission (he can correct me later)
<sarang> Any last comments or questions or information from anyone?
<sarang> OK, we can adjourn! Thanks to everyone for joining in
<sarang> Logs will be posted shortly to the agenda issue

Overview and Logs for the Dev Meeting Held on 2019-08-25

Sun, 25 Aug 2019 00:00:00 GMT

Logs

<rbrunner> Meeting time, but it seems Rehrar has problems getting through to here from Mattermost ...
<dEBRUYNE> rehrar can't join IRC directly?
<rehrar-mob> ok, let's do this then
<rbrunner> So you all don't see him either, right?
<rehrar-mob> I'm on the move atm, unfortunately.
<dEBRUYNE> Nope
<rbrunner> Technology, pfft
<rehrar-mob> In fact, I may be called away in about twenty minute's time.
<rehrar-mob> I can lead until then, but maybe dEBRUYNE or moneromooo can afterwards?
<rehrar-mob> normal stuff today.
<dEBRUYNE> Sure
<rehrar-mob> 1. Greetings, 2. What's done since last meeting? 3. Code/ticket discussion 4. Other meeting items 5. next meeting time
<dEBRUYNE> pings luigi1111 sarang fluffypony moneromooo vtnerd suraeNoether___ hyc jtgrassie selsta xiphon
<rehrar-mob> 1. Greetings
<rehrar-mob> say hi
<vtnerd__> hi
<rbrunner> Hi
<rehrar-mob> dsc_ medusa_ also
<xiphon> hi
<TurtleCoin> <VISSER THREE> hi
<rehrar-mob> 2. What's been completed since last meeting?
<sarang> Hi
<rehrar-mob> Did you guys have a meeting a couple weeks ago? I was at defcon, so didn't attend.
<hyc> hi
<dEBRUYNE> Yes, there was a meeting two weeks ago
<hyc> there was a meeting 2 weeks ago, not much happened
<rehrar-mob> cool, so completed since then then
<rehrar-mob> been a slow past couple of weeks?
<dEBRUYNE> I've worked with luigi and mooo to get some stuff merged
<dEBRUYNE> We're at about 60 open PRs now (quite a few of those are relatively new)
<rehrar-mob> on CLI? or between both CLI and GUI?
<dEBRUYNE> CLI yes, but luigi also merged some stuff for the GUI
<rehrar-mob> any idea on what those things are? summary.
<rehrar-mob> vtnerd how's your stuff coming along? Everyone awaits with bated breath.
<dEBRUYNE> You mean what kind of PRs were merged?
<rehrar-mob> dEBRUYNE yes. What'd they do.
<rehrar-mob> Just for anyone reading the logs.
<dEBRUYNE> As far as I can see, mostly optmizations, bug fixes, readme additions
<dEBRUYNE> IPv6 support got merged
<rehrar-mob> Cool deal.
<dEBRUYNE> Also a few improvements to the deterministic build process
<sarang> I'd like additional review on a slightly older MLSAG PR: https://github.com/monero-project/monero/pull/5707
<dEBRUYNE> Bunch of new tests got added too
<sarang> (recently updated)
<dEBRUYNE> ^ Perhaps luigi1111 can have another look at that?
<vtnerd__> Im working on handling the mempool separation, which is a bit tough to separate the components cleanly
<rbrunner> You mean code separation?
<vtnerd__> the first PR for white noise appears to not be hated at least - I rebased and tested against the ipv6 merge
<xiphon> regarding the broken Travis builds - they were broken due to ncurses configuration, sent a PR that fixes the issue.
<xiphon> Though now some builds are halt on libunwind build error. Did we change anythign related to libunwind recently?
<vtnerd__> ideally dandelion++ and this covert sending technique have different mempools
<vtnerd__> but its determining how to handle it thats the tricky part - whether the txes are stored in the lmdb file like normally, kept only in memory, or separately altogether
<vtnerd__> its a very subtle leak of information if your tx is in the mempool stored on disk before appearing anywhere else, but this is monero so ...
<vtnerd__> dandelion++ flat out suggests separate mempools because the information can be leaked externally through p2p or rpc calls
<vtnerd__> so for both dandelion++ and my CCS I proposed a separate mempool that didn't return the tx until it was "spread"
<rehrar-mob> you don't foresee any of this being live in October, yeah?
<rehrar-mob> Or perhaps none of this necessitates a hard fork?
<vtnerd__> none of these needs a fork
<vtnerd__> *this
<rehrar-mob> aight, so it can go live whenever. Would any of this need to be audited, you think?
<rehrar-mob> or is it not that simple?
<rehrar-mob> I'm guessing that's the answer.
<vtnerd__> uh, its not the typical thing that gets audited, theres no cryptography involved really, but its wrong of me to push against it probably
<hyc> vtnerd: explanation makes sense, thanks
<rehrar-mob> dEBRUYNE now I have to step away. I should be back in a while, but I don't expect the meeting to last that long. Can you take over?
<dEBRUYNE> Sure
<rehrar-mob> thanks
<hyc> vtnerd but it sounds like this could just be a flag on records in the single txpool
<vtnerd__> yes, that is something that I thought about
<hyc> and you only need to control disclosure when a remote client is asking
<hyc> not e.g. the local CLI
<xiphon> ^ you still need to do this even with separate mempools
<vtnerd__> the only negative is that its recorded on disk to what is generally believed (or at least by me, perhaps not all) to not contain "sensitive" information. that flag would be recording that the tx origin was that machine
<vtnerd__> and its mixed with what is otherwise public information
<hyc> ... no, that flag's meaning is not necessarily that.
<vtnerd__> it might be something I end up doing - since its less work - and document that it can be updated as needed
<hyc> the flag is "broadcasted yet" - it would be false on intermediate nodes in the dandelion stem too
<vtnerd__> yes
<vtnerd__> my only concern about mixing was the small data leak to disk and making sure it wasn't easy to accidentally undo.
<vtnerd__> I think its just going to use an existing flag or a new one, because its the easiest to get the bulk of the concern - the externally visible network traffic - up and running
<hyc> using a separate memory-only pool has the same dangers as why we switched to LMDB in the first place
<hyc> it can grow to ubnounded size
<hyc> and unless you use locked memory, it could just get swapped to disk anyway
<vtnerd__> yeah I had been considering a separate lmdb file for this. No code was written for that, but I was going through it in my head to track how much work it was
<hyc> and if you use locked memory, you'll just run out
<vtnerd__> its not terrible, but cleaning up the tx inspection process should probably be done first
<vtnerd__> I was thinking of storing it to disk using lmdb, but letting the user specify a separate entry point for an encrypted volume, but its going to be too much work (as you are likely hinting at)
<rbrunner> This all is only relevant if you have a local attacker, right?
<hyc> I would think so, yes
<vtnerd__> for the most part. I primarily wanted to do it because I still think its easier conceptually to have two separate pieces in code handling this, but its not trivial
<hyc> and a local attacker that can examine the disk can probably also examine monerod's memory
<rbrunner> Yes, and if your starting point is "no dandelion++ whatsoever", maybe implement that quick and worry about local attackers afterwards
<vtnerd__> if the person is storing the blockchain to an unencrypted portion thinking its all public information
<vtnerd__> arguably everyone is running monerod on a machine using disk encryption, but perhaps not always
<xiphon> also storing txes in lmdb will help in case of casedandelion++ stem phase fail
<xiphon> one could safely restart the daemon and don't bother that any outgoing tx will be lost
<vtnerd__> theres also a small concern about getting information remotely via timing, but thats another advanced attack that I was merely going to document rather than code around (it aint easy)
<rbrunner> Good argument
<vtnerd__> and Im not even sure how realistic that timing attack is, its going to vary from machine to machine a lot
<vtnerd__> xiphon: thats probably pointless
<hyc> fwiw, a patch for page-level encryption in LMDB is available, works fine. I haven't released it yet because I wanted to add authenticated encryption
<vtnerd__> because the embargo is almost certainly going to fire, and everyone in the chain is broadcasting at that point
<hyc> which requires eating up extra space for the encryption signature
<hyc> but we could go with the current patch immediatelym if it helps
<xiphon> dvtnerd__: oens't seem so to me
<xiphon> if you restart the daemon right after sending a tx and choosen stem node fails, you tx will be lost
<vtnerd__> its no worse than the current code, so I don't see a reason to rush
<xiphon> and that won't happen with lmdb-stored txes
<vtnerd__> and likely the timer from the origin node goes off by then anyway, its probably close
<vtnerd__> although we could have it retry on connection loss to a backup node before doing the embargo timer thing
<vtnerd__> with dandelion++ theres always the possibility of an intentional blackhole, so storing the stem txes to disk is not an obvious benefit
<vtnerd__> the origin needs counter-measures either way
<xiphon> something is wrong then, this sounds like we don't guarantee that tx will be broadcasted to the network
<vtnerd__> you can't with dandelion++, thats how the protoocl works
<vtnerd__> and to be fair, you cannot really guarantee it with the gossip protocol either
<vtnerd__> theres no acking on this, its a fire and forget in monero
<sarang> D++ is intended to fail to the existing broadcast scheme, essentially
<vtnerd__> yes, its one of the consequences of having a single outbound path
<hyc> ... we really should be using IP multicast
<hyc> btw, for those who aren't following this -dev channel all the time, I have a randomx testnet node on 206.127.12.163:28080
<hyc> seems there are only 5 peers active at the moment
<rbrunner> Yeah, that was one of my questions, how that's going
<rbrunner> There were plans anyway to switch testnet soon, right?
<hyc> running uneventfully so far. mining, sending coins around
<hyc> official switch is waiting on fluffypony's availability
<rbrunner>
<rbrunner> But your well-running private testnet is a pro argument, then
<rbrunner> For such a switch
<dEBRUYNE> With respect to binaries, what would the devs prefer?
<dEBRUYNE> Would a first 0.15 release within a few weeks be a proper timeline?
<rbrunner> Nobody seems to push a release, funny
<xiphon> there will be anissue with Ledger
<xiphon> They hardcoded accepted Monero version in the ledger monero app - the firmware the is installed on ledger device
<xiphon> it only accepts "0.14.1.0" string right now
<rbrunner> So they must plan to follow-up any Monero release quite closely, otherwise that does not make sense
<xiphon> and (if i'm correct) it usually takes some time for them to push an app update
<hyc> all the better to get a 0.15RC out sooner then
<hyc> and get them to use a saner version check. like >= 0.14.1
<rbrunner> Exactly
<selsta> They added the strict version check because of the change bug.
<xiphon> as a fallback plan, i thoguh about doing a workaround on the monero side
<xiphon> disabling this check by always supplying "0.14.1.0" version to the device
<hyc> yeesh...
<rbrunner> Oh, that's a straight road to hell
<rbrunner> See all the lying Windows does about the version numbers ... yikes
<selsta> They added the version check on purpose so we shouldn’t disable it like this.
<xiphon> right, i'm not saying it is good
<xiphon> but, we will loose ledger support with the new version if they won't manage to patch their code
<selsta> They managed to do it in time with the v0.14.1.2 release.
<rbrunner> That's why hyc's argument of early 15.x release is good
<hyc> yes, give them more advance warning, more time to respond
<rbrunner> The earlier before the hardfork itself that is out, the better
<moneromooo> The white noise stuff will most likely be in the october release.
<moneromooo> Before a 0.15 release, the v12 changes should be reviewed and merged.
<dEBRUYNE> xiphon: I presume they will release a new version in conjunction with our v0.15 release
<moneromooo> That's 5823.
<dEBRUYNE> So 5823 and the RandomX PR are the consensus changes that need to go in before we do an RC right?
<hyc> sounds right
<hyc> randomx is 5549
<ErCiccione[m]> so we are doing an RC release this time?
<ErCiccione[m]> because i remember many were against last hard fork
<xiphon> dEBRUYNE: hopefully they will implement version >= check, so the user won't need to update the ledger app with every monero release
<selsta> Plan was to add >= for minor point releases.
<dEBRUYNE> ErCiccione[m]: I guess we could also do a straight 0.15 and then work out any bugs via point releases
<dEBRUYNE> moneromooo, hyc, vtnerd__: thoughts?
<dEBRUYNE> also xiphon
<vtnerd__> well thats how its been done the last few releases
<ErCiccione[m]> i mean, i would totally go for an RC release
<rbrunner> Isn't that mostly only an issue with labels?
<moneromooo> If you're asking about version numbers, my preference is to have increasing version numbers. It mkaes things so much easier. IIRC pony prefers to have "rc" labels instead.
<moneromooo> I'm not gonna fight that, just moan from time to time and say "told you so" if it bites us later.
<dEBRUYNE> vtnerd__: Right
<rbrunner> Yeah, but also, how would an RC be effectively different from a release?
<rbrunner> And not just called any other way
<dEBRUYNE> I guess we can release earlier now though because randomx and the other consensus changes are already ready
<moneromooo> As long as it contains all the needed consensus changes.
<rbrunner> You are not moaning, you are moooing
<moneromooo> That's randomx and 5823 AFAIK. If there's something else, say so.
<moneromooo> rbrunner: indeed!
<xiphon> rbrunner: "but also, how would an RC be effectively different from a release?" - i think the difference is in the official press release statement
<xiphon> we won't do one for -RC
<xiphon> so it will be for testing purposes
<sech1> randomx has 1 PR pending: https://github.com/tevador/RandomX/pull/118
<rbrunner> Hmmm, ok, but with the risk that less people test then
<xiphon> rbrunner: if that's is not how it is supposed to be, i'm lost
<rbrunner> I see what you mean, yes, it's a trade-off of course
<rbrunner> sech1: An audit result, then, this RandomX PR
<hyc> that PR appears (so far) to have no downside
<ErCiccione[m]> about the RC thing. Since there are many contrasting opinions, maybe better keep the old system.
<moneromooo> "Everybody builds their own" ?
<rbrunner> The old system does not really look broken, either, so why fix
<ErCiccione[m]> well, would be nice to have more testing before a proper release, but at this point i think it doesn't worth it.
<hyc> I suppose, if we don't do that last-minute advance-by-1-month release, it should work out fine
<selsta> Readline is still broken with reproducible builds.
<selsta> that has to get fixed with v0.15
<hyc> isn't there already a PR for that?
<selsta> I haven’t seen one.
<dEBRUYNE> We could reverse the commit that broke it I guess?
<selsta> Reversing it would mean no readline at all But that’s better than broken readline I guess.
<hyc> hm, can't find one, must be misremembering
<hyc> I think the original problem is linking readline without its curses dependencies. the next problem is that curses has different dependencies on different OSs
<dEBRUYNE> So I guess that is added to the list of things that need to go in before we tag
<dEBRUYNE> Would a target of tagging in 2 weeks be reasonable?
<hyc> terminfo vs termcap vs ... something else
<moneromooo> Any vote against the pay-for-rpc going in ?
<moneromooo> (I have a wip patch to make it use randomx, not pushed yet)
<hyc> I have nothing oposing
<rbrunner> It's reviewed well, after all
<xiphon> would be nice to have it in the 0.15
<dEBRUYNE> I guess we can conclude the meeting then

Overview and Logs for the tini2p Dev Meeting Held on 2019-08-22

Thu, 22 Aug 2019 00:00:00 GMT

Logs

<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> hi
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> A lot
<tini2p_gitlab> I've more-or-less finished the tunnel message processing classes (Hop, InboundEndpoint, InboundGateway, OutboundEndpoint, OutboundGateway)
<tini2p_gitlab> still making changes as I impl tunnel management classes (InboundTunnel, OutboundTunnel, TransitTunnel, Pool, PoolManager), but the changes are fairly minor
<tini2p_gitlab> had a few big, time-consuming refactors for the processing classes, but most of those are finished now (hopefully)
<tini2p_gitlab> I am almost done with the TransitTunnel class (used for participating in Tunnels created by remote routers)
<DavidBurkett> :wave:
<tini2p_gitlab> hi @DavidBurkett, how are you?
<DavidBurkett> Great! And yourself?
<tini2p_gitlab> doing well, thanks :)
<tini2p_gitlab> welcome
<tini2p_gitlab> to the meeting
<DavidBurkett> Happy to be here. Will observe and try not to interrupt :)
<tini2p_gitlab> right on, feel free to ask or comment at will
<tini2p_gitlab> happy to have you, as always
<tini2p_gitlab> so Tunnels are almost done, and have been what I've spent all of my time on over the last two weeks
<tini2p_gitlab> 2: What's next
<tini2p_gitlab> so, the last few I2P LS2 meetings have been a bit hairy
<tini2p_gitlab> we've been discussing, mainly, changes to 144 (ECIES-X25519 end-to-end sessions)
<tini2p_gitlab> admittedly, I could have handled things much better than I did
<tini2p_gitlab> thankfully, things seem to be moving forward again, and we've concluded that reuse of ephemeral keys is a bad idea
<tini2p_gitlab> it will require some changes to my ECIES-X25519 impl, which I will do after finishing tunnels
<tini2p_gitlab> whether to follow the drop-until-secure or send-NewSession-until-secure is still to be determined
<tini2p_gitlab> drop-until-secure is what I prefer, and means routers with drop end-to-end messages, until a secure channel to the Destination is established
<tini2p_gitlab> only requires one round-trip, and support sending one 0-RTT payload in the initial NewSession and NewSessionReply messages
<tini2p_gitlab> zzz is of the opinion that drop-until-secure will not work for performance and client-related reasons
<tini2p_gitlab> I haven't begun to implement client stuff, so maybe zzz is right
<tini2p_gitlab> NewSession-until-secure basically sends NewSession messages to the Destination until the first NewSessionReply is received
<DavidBurkett> Is that discussion in the PR for 144 or something?
<DavidBurkett> Or was that in IRC?
<tini2p_gitlab> was on Irc2P, the meeting logs are here: tini2p/meta#29
<DavidBurkett> Thanks :)
<tini2p_gitlab> and here: tini2p/meta#28
<tini2p_gitlab> guess it might be a bit much to rehash the discussion here, just trying to summarize
<DavidBurkett> I'll read through and understand
<DavidBurkett> YOu have good TL;DR's
<tini2p_gitlab> NewSession-until-secure also has its problems, but should be workable
<tini2p_gitlab> thanks :)
<tini2p_gitlab> anyway, I'll be implementing the drop-until-secure until we come to consensus on what actually becomes spec
<tini2p_gitlab> it's simpler, more secure, and more efficient
<tini2p_gitlab> though latency/performance may be a killer for it
<tini2p_gitlab> after the changes for ECIES-X25519, I'll be gluing everything together with a RouterContext class
<tini2p_gitlab> with RouterContext, I'll be able to have the NTCP2 transport talk to the Tunnels and NetDB classes
<tini2p_gitlab> I'll create some basic unit tests, if they make sense. the majority of the tests for RouterContext will be net-tests (integration/functional tests)
<tini2p_gitlab> with RouterContext finished, tini2p library users will be able to build their own router
<tini2p_gitlab> that will likely be alpha-release time
<tini2p_gitlab> I'm shooting for a one-week impl time on RouterContext, but may run into bugs/refactor work that pushes that timescale back a week or two
<tini2p_gitlab> it's really just gluing stuff together though, so I'm hoping it goes quickly
<tini2p_gitlab> I also need to make a small update to NTCP2 for the testnet-separation update to specs from 147
<tini2p_gitlab> basically it's a netID check that ensures no cross-talk between mainnet and testnet routers
<tini2p_gitlab> it's important for I2P network health, so I am happy to impl
<DavidBurkett> That's awesome! I'll watch for updates on that RouterContext. I'll try setting one up once you're finished
<tini2p_gitlab> for sure :)
<tini2p_gitlab> will likely be adding a docker setup, so you can run a full testnet entirely locally
<DavidBurkett> Nice!
<tini2p_gitlab> definitely! also allows spinning up 10+ routers on different /16 pretty easily, so it may be a good way to do integration tests with I2P Java and i2pd once I add ElGamal tunnel building
<tini2p_gitlab> ElGamal tunnel building is post-alpha though
<DavidBurkett> :)
<tini2p_gitlab> so that's about it for stuff until alpha release
<tini2p_gitlab> 3: Questions/Comments
<DavidBurkett> Nothing from me. :thumbsup:
<tini2p_gitlab> for sure
<tini2p_gitlab> 4: Next meeting
<tini2p_gitlab> staying on normal schedule, two weeks from today: 2019-09-05 18:00 UTC
<tini2p_gitlab> that's all, thanks all for the meeting
<@tini2p_gitlab> gaffer banger

Logs for the Monero Research Lab Meeting Held on 2019-08-20

Tue, 20 Aug 2019 00:00:00 GMT

Logs

<sarang> OK, let's get started with our meeting
<sarang> Agenda here: https://github.com/monero-project/meta/issues/383
<sarang> Logs posted there afterward
<sarang> GREETINGS
<sarang> hello
<suraeNoether> howdy
<gingeropolous> heya
<sarang> It's been two weeks since the last meeting... plenty to discuss!
<sarang> In the spirit of fairness and teamwork, I'll go first :D
<sarang> The DEF CON village, despite having a poor location, was well attended
<sarang> I did a talk, a workshop, a CTF, and a panel discussion
<suraeNoether> how did the attendance compare to last year?
<sarang> I would estimate higher
<suraeNoether> nice!
<sarang> I've written up a brief spacetime analysis of Omniring in its current form: https://github.com/SarangNoether/skunkworks/blob/sublinear/omniring.md
<sarang> It does not presently support batching, but the authors have a couple of ideas on how to do so safely that are forthcoming
<sarang> I'll be discussing with them this week
<sarang> On a related note, the RCT3 construction has a flaw that would be exploitable in practice
<sarang> The authors of that paper, I'm told, also have a fix forthcoming that may relate to the Omniring batching enhancement
<sarang> Made a quick PR to fix a bias in Schnorr signatures: https://github.com/monero-project/monero/pull/5807
<endogenic> o/
<sarang> Cleaned up an MLSAG improvement PR: https://github.com/monero-project/monero/pull/5707
<sarang> Made some updates to Zero to Monero (see topic branches): https://github.com/SarangNoether/zero-to-monero/
<sarang> And I'm working on getting CLSAG and thring sigs submitted to conference proceedings (a tiresome and lengthy process)
<sarang> That's my two cents
<endogenic> damn, son
<suraeNoether> yeah, that was a damn mic drop brother
<sarang> Anything to share with the class, suraeNoether ?
<suraeNoether> as for me, I've been on vacation and just got back. I'm still going to be only half-on today because I have some personal business I have to attend. it was an eventful vacation. for one thing, I was able to prove a few theorems for my graph matching paper that are necessary for publication. based on a conversation I had with sgp_ right before I left, I spent a lot of time thinking about experimental
<suraeNoether> design, and I'm starting to discuss this with sarang.
<suraeNoether> in addition to that, I was contacted by Astral, the team working on bullet-proof monero-mining drones, re: an unfortunately urgent funding matter.
<luigi1111w> sarang what happened to reusing existing functions or adding it as a function instead of inline?
<luigi1111w> not that it matters that much I guess
<sarang> There were some silly issues with includes and having access to the right underlying functions
<sarang> It seemed simpler to do it as is
<suraeNoether> i would urge folks in the audience to watch OhGodAGirl__'s talk from teh Konferenco here (https://www.youtube.com/watch?v=jDSKIr5EPiU ) or Leah's interview wiht monerotalk https://www.youtube.com/watch?v=jl1w6VDEWq4 to refresh themselves on the project
<endogenic> meaning they need funding?
<suraeNoether> if anyone is interested in assisting Astral in composing a CCS, I've been pinging some ideas back and forth with Leah
<suraeNoether> yes, and some of the funding needs are rather urgent; I spoke with OhGodAGirl__ and OpenSourceress about this in person at the Konferenco and we have been kicking some ideas around
<suraeNoether> i anticipate a vigorous discussion on the matter, because the community funding sources, in my mind, should be a source of funding of last resort
<suraeNoether> the folks who contribute to the monero community are people who care about privacy and they want to see the project advance in a healthy direction, and without them, all of this falls apart
<sarang> Probably a good discussion for -community?
<sarang> Unless there's a technical/research component to it?
<suraeNoether> well, it's a nascent funding request for a hardware project with a timeliness component that recently presented at our conference, but going into further detail during the meeting is certainly unnecessary
<sarang> got it
<suraeNoether> and full disclosure: i am not yet in any way financially linked with Astral, although that may eventually change
<suraeNoether> i.e. this isn't for me
<sarang> Anyone else wish to share research work of interest?
<sarang> I'm excited to take a look at the current state of the matching simulations suraeNoether
<suraeNoether> that's all I have for the round table this week, but I'll also be playing catch-up on the lelantus vs. omni vs. rct3 cage match that's been going on these past few weeks
<gingeropolous> may eventually change? hamster.gif
<sarang> OK, so after the brief ROUNDTABLE is GENERAL QUESTIONS... anyone?
<sarang> I have a general question
<suraeNoether> i have one, too
<sarang> The proceedings/journals under consideration for CLSAG (thanks also to some outside advice) are Financial Cryptography, PETS, ACM TOPS, and ANCS
<sarang> Any other suggestions that I may have missed, that could be in scope?
<sarang> It's tough in the CLSAG case since it's an improvement over earlier work, but not earth-shattering
<sarang> and that always seems to be a tricky place to be in the publishing world
<sarang> I plan to highlight the improvements and generalize it a bit for submission
<suraeNoether> are you strictly considering conference proceedings or are you open to journal-only suggestions?
<sarang> Journals are fine too (ACM TOPS, e.g.)
<sarang> But since submissions are typically one-at-a-time, there's no real rush to add to the list
<sarang> But obviously prioritizing is useful to avoid submitting for delayed rejections
<suraeNoether> fair enough. I thought ACM TOPS was a conference, silly me. :P
<sarang> Anyway, that's my question
<sarang> suraeNoether: yours?
<suraeNoether> some of the biggest improvements that have come out of MRL this year have involved efficiency improvements, ranging from bulletproofs optimizations to compressed signature schemes. Only some of these improvements will carry on to the "next version" of monero, especially if we end up having to migrate our transaction model to something like one of the Big Three...
<dEBRUYNE> suraeNoether: Don't they have other options than to tend to the CSS?
<dEBRUYNE> I genuinely think this is not appropriate for it
<suraeNoether> so my question is: what sort of improvements would you like to see from the Monero Research Lab in the next year, keeping in mind that we will want to migrate to a different scheme sooner or later?
<suraeNoether> dEBRUYNE: i'll start a conversation about this over in -community
<rehrar> I would definitely like some research into ring sig alternatives.
<sarang> That's very much in progress rehrar
<suraeNoether> do you mean ring confidential transactions?
<rehrar> from the ground plebs, we're never quite sure how much progress and when and why and stuff
<suraeNoether> because lelantus, omni, and rct3 are each replacements for ring sigs
<suraeNoether> in a certain sense
<suraeNoether> but they are still ring confidential transaction schemes
<sarang> Yeah, my analyses try to give a reasonable spacetime estimate for those protocols
<rehrar> I wonder if a bimonthly MRL bulletin would be helpful to the masses
<rehrar> or a monthly one
<rehrar> I can assist in getting it out
<dEBRUYNE> suraeNoether: OK
<sarang> Any other general questions?
<suraeNoether> sarang, do you have an answer to my question?
<suraeNoether> rehrar answered and this was something i was happy to see
<suraeNoether> usually it's the noethers talking at everyone else during these meetings :D
<suraeNoether> but i am curious
<sarang> I think determining the real viability of newer transaction protocols is a priority for my research
<suraeNoether> okay. my personal white whale has always been to replace linearly-sized RCT with something sublinear but sufficiently fast to not drag down the network, so i'm happy to have such an embarassment of schemes to work through
<suraeNoether> anywya, no other questions from me
<sarang> Yeah, once the RCT3 fix and Omniring batch issues are solved, there will be a much clearer view of what's reasonable IMO
<sarang> Anyway, on to ACTION ITEMS
<sarang> I'll be discussing protocol details with some other researchers this week, to gain some better information on these changes
<sarang> Getting the preprints sorted out for edits and submission
<dEBRUYNE> If any of you feels like leaving a brief comment here btw -> https://www.reddit.com/r/Monero/comments/ct29nx/spectre\_protocol\_update/
<sarang> and catching up on a backlog of other preprints that have come out
<sarang> suraeNoether: ?
<suraeNoether> working with you on matching code and experimental design, and backlog reading on the work Sarang has done over the past 2 months comparing these three sublinear protocols
<sarang> neat
<sarang> OK, any final questions or comments before adjourning?
<sarang> going once
<sarang> going twice
<sarang> Adjourned! Logs will be posted shortly

Logs for the Community Meeting Held on 2019-08-17

Sat, 17 Aug 2019 00:00:00 GMT

Logs

<sgp_> Hello everyone, welcome back to the typical meeting schedule
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/382
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<JOhNKmus> Hello
<rehrar> hi
<serhack> hi
<sgp_> hello everyone, welcome
<lh1008[m]> Hello
<sgp_> 2. Community highlights
<sgp_> Monero just concluded its Defcon village. More details on that later.
<sgp_> I need a Blockfolio banner. What should it be? I need an announcement and a link.
<sgp_> At the moment, it points to monerovillage.org. not great
<xmrmatterbridge> <el00ruobuob> Hi
<JOhNKmus> Point to getmonero.org?
<sgp_> Sure, but with what text?
<JOhNKmus> Maybe something about the upgrade to let people know too?
<sgp_> Check out the official website?
<JOhNKmus> Yeah that would work
<sgp_> Did you upgrade to 0.14.1 yet?
<sgp_> we're supposed to be their test bunny for conversions, so think of some announcements we can make over the next few weeks
<sgp_> PM me if you think of any
<sgp_> I can use it for the coffee chat to see if it gets more traction than normal I suppose
<midipoet> waves as he shuffles in late
<sgp_> Does anyone else have community (non-workgroup) updates to share?
<sgp_> welcome midipoet
<midipoet> thanks for the heads up...
<lh1008[m]> Monero News telegram channel was born this week
<sgp_> very nice lh1008[m]
<rehrar> which one is that?
<lh1008[m]> Oh, and Monero Telegram channel too.
<lh1008[m]> <rehrar "which one is that?"> @MoneroNews247
<sgp_> any other questions/updates?
<sgp_> 3. CCS updates
<sgp_> There have been no updates on the CCS proposals in ideas since last meeting. Are there any other comments?
<_hahsun_> hi guys
<JOhNKmus> hello
<sgp_> I'll take that as none
<sgp_> please comment on gitlab and reopen the discussions if you are interested in making these proposals come to fruition
<sgp_> Ideas in funding required:
<sgp_> v1docq47: video creation / translations into russian (august - january) (1.33/37.8 XMR) https://ccs.getmonero.org/proposals/v1docq47-video-creation-translations-into-russian-(august-january).html
<sgp_> Continued funding for Surae for another quarter, Aug Sep Nov 2019 (252.42/357 XMR) https://ccs.getmonero.org/proposals/surae-mrl-research-q3-2019.html
<sgp_> World Crypto Con for rehrar and Sarang (28.73/30 XMR) https://ccs.getmonero.org/proposals/rehrar-sarang-2019-wcc.html
<sgp_> Does anyone else have a CCS update, or comments about any of these CCS proposals?
<rehrar> there is one that is not showing on the website
<rehrar> due to being incorrectly formatted
<rehrar> the one about Monero GIGS
<rehrar> *GIFS
<sgp_> link?
<rehrar> grabbing, sec
<rehrar> https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/88
<sgp_> any comments on this one? looks a little expensive to me, but they have a history of making them and interest
<sgp_> deadline is 2019-09-01
<rehrar> I don't really think it's necessary, but that's just me
<dEBRUYNE> $800 for 25 gifs seems a bit steep
<sgp_> rehrar: are you in touch with Jack? Maybe have him solicit opinions in r/moonero
<rehrar> ok, I'll have him do that.
<sgp_> if people from r/moonero are happy with the rates, then I don't want to be the reason it's not moved
<sgp_> maybe it's something that sub-community is interested in funding
<sgp_> any final CCS comments?
<_hahsun_> yes a question.
<sgp_> sure hahsun
<_hahsun_> what happens when I did work on a proposal? but it is still open?
<dsc_> Don't really like the CCS for .gif meme creation.
<_hahsun_> I have reached some milestones that is
<sgp_> hahsun: that happens sometimes, and usually they are retroactive if approved and funded
<_hahsun_> ok. and do I have to update it on the open proposal?
<sgp_> I would probably comment or something, yes
<_hahsun_> alright will do
<xmrmatterbridge> <el00ruobuob> Btw, didn't we approve the telegram tipbot already?
<sgp_> el00ruobuob: I think custody was/is still an open question
<xmrmatterbridge> <el00ruobuob> Ah ok.
<_hahsun_> yes. I am awaiting a response from fluffy. will update as soon as I get it
<xmrmatterbridge> <el00ruobuob> Great.
<xmrmatterbridge> <el00ruobuob> I still approve it, as a few weeks ago.
<_hahsun_> I got a great response from the communit,.thats why I made a plan B if custody is not taken care by the monero team
<_hahsun_> I see an increase of users by average of 25 users per day. amazing feedback from people with feature requests. I am happy.
<sgp_> I'm glad this is proceeding even as you wait for a response
<sgp_> 4. Workgroup report
<sgp_> moneromooo is still on vacation, but development continues
<lh1008[m]> <_hahsun_ "I got a great response from the "> Decentralize the responsibility. Just saying.
<sgp_> vtnerd make some i2p and lightweight server upgrades
<lh1008[m]> <_hahsun_ "I see an increase of users by av"> Awesome
<sgp_> there are some other node updates
<sgp_> 2 output minimum will now be enforced on consensus layer (hooray, thanks Isthmus)
<_hahsun_> I will lh1008. I try. thanks
<sgp_> those are the main things that stuck out to me looking at the github commits. Am I missing something?
<kinghat> looks like there is still activity with the tini2p according to the gitter dev channel
<sgp_> interesting. we will have to see how that comes about
<sgp_> we met some i2p folks at defcon
<kinghat> they also posted a defcon report on their forum
<sgp_> https://i2pforum.net/viewtopic.php?f=18&t=875&sid=088751cca1b2e6560a01a2e960671eb7
<lh1008[m]> <sgp_ "https://i2pforum.net/viewtopic.p"> Nice!
<sgp_> any localization updates? chime in or I'll proceed to the gui updates
<xmrscott[m]> I think we're largely still waiting for WebLate to be enabled
<dsc_> no GUI updates from me
<sgp_> GUI has a few other design updates. It's nice to have a group of people consistently participating and politely discussing different options
<sgp_> dsc_ has been slacking indeed
<sgp_> totally not focused on the ctf or anything
<dsc_> hehe
<sgp_> which transitions us nicely to....
<sgp_> d. Defcon workgroup
<dsc_> also i2p-zero and I traveled to meet certain GUI contributors
<dsc_> there is more happening that you dont see ;p
<sgp_> Monero^TM
<sgp_> Defcon is over! What an event! Livestreams had some issues but are up:
<sgp_> Friday: https://www.youtube.com/watch?v=wNnjO1XSEdg
<monerobux> [ Monero Defcon27 Village - Friday Livestream - YouTube ] - www.youtube.com
<sgp_> Saturday: https://www.youtube.com/watch?v=J\_9ssXDErqY
<monerobux> [ Monero Defcon27 Village - Saturday Livestream - YouTube ] - www.youtube.com
<sgp_> Sunday: https://www.youtube.com/watch?v=un7-pwkZRDc
<monerobux> [ Monero Defcon27 Village - Sunday Livestream - YouTube ] - www.youtube.com
<sgp_> The hotel AV staff recorded all the talks, but they will probably take months to be uploaded. I’ll keep trying to grab copies in the meantime.
<sgp_> Read rehrar’s report: https://www.reddit.com/r/Monero/comments/cqegma/monero\_village\_defcon\_2019\_report/
<monerobux> [REDDIT] Monero Village - Defcon 2019 report (self.Monero) | 78 points (96.0%) | 19 comments | Posted by Rehrar | Created at 2019-08-14 - 19:20:38
<sgp_> I will be sending photos that I took to the relevant people so that they can share as they choose. Here are what I’m calling “atmosphere photos” of the room and non-people. PM me for original versions of the ones you like: https://imgur.com/a/fu9vmDQ
<sgp_> Monero Talk uploaded 10 videos from the event: https://www.youtube.com/channel/UC3Hx81QYLoEQkm3vyl4N4eQ/videos
<monerobux> [ Monero Talk - YouTube ] - www.youtube.com
<sgp_> There are many areas for improvement, but I think it was overall an improvement compared to last year. We still need more people to sit at the front tables and answer the "what is Monero" question 10,000 times
<landude> rehrar's report was great!
<xmrmatterbridge> <el00ruobuob> Where could we find the moneropoly? I need one.
<sgp_> el00ruobuob: these were limited first-edition releases. None left. However, CypherMarket will have the second version at some point
<xmrmatterbridge> <el00ruobuob> \o/
<xmrscott[m]> Which will be arguably better as they will have custom house/hotel pieces
<sgp_> btw rehrar alleges the typical Moneropoly game takes 30 minutes..... more like 3+ hours
<rehrar> 30-40 if played quickly and by correct rules
<sgp_> no way
<sgp_> anyway
<sgp_> that's all from me for Defcon. we can finally talk about other stuff happening in the community
<sgp_> 5. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<dsc_> I'd like to discuss the possibility of marketing through an (video) advert - how that could look like
<sgp_> sure, what do you have in mind
<dsc_> I had nothing particular in mind, but something in the spirit of Apples "privacy" commercial
<sgp_> I love the way that ad gets the point across
<dsc_> It's a very good ad indeed.
<sgp_> https://www.youtube.com/watch?v=A\_6uV9A12ok
<monerobux> [ Privacy on iPhone — Private Side - YouTube ] - www.youtube.com
<lh1008[m]> <landude "rehrar's report was great!"> Yes
<dsc_> Monero has barely no marketing - I don't mind that much usually.. but I'm the position to use proffesional equipment to create something.
<dsc_> <== also filmmaker
<sgp_> person of many talents
<dsc_> Adverts are tricky though. Just wondering what the community thinks.
<xmrscott[m]> Nice! I'd be down to throw in some money to the CCS or whatever
<lh1008[m]> <dsc_ "I'd like to discuss the possibil"> Nice idea
<sgp_> I haven't thought of a video series, but I will tell of one ad campaign we are slowly working on for Mastering Monero
<sgp_> We are going to be advertising "Using Bitcoin isn't safe", "using x isn't safe" with links to pages outlining why the privacy protections are terrible, then recommending Monero
<dsc_> If anyone has an idea for a 1 minute commercial feel free to send it my way. I shoot on super 16mm (Aaton XTR).
<sgp_> dsc_: do you have anything in mind at the moment?
<dsc_> sgp_: absolutely no idea
<sgp_> who is the target audience?
<dsc_> It could be something that represents our community and values
<dsc_> Which then could be used on the website or .. I don't know.
<sgp_> "open source is better"
<sgp_> "Monero: we've got your back"
<sgp_> "Monero: no surprises"
<dsc_> Yeah. Ill make sure it doesn't get cheesy I can provide some stills from a thing I shot recently.
<dsc_> Anyway, just wanted to present the idea.
<xmrscott[m]> Out of curiosity on the note of advertising, are there any billboard designs people have already?
<xmrscott[m]> A ~$2K billboard in PHX (roughly 5 mil people) nets roughly 3mil impressions over a month, allegedly
<dsc_> Regardless of this video idea I think Monero could currently use some proffesional marketing. Our software is currently stable enough for the masses, good ecosystem all-around (better than during 2017 bubble).
<sgp_> Mastering Monero info from Amazon: https://usercontent.irccloud-cdn.com/file/tq2doUtJ/amazon%20advertising
<dsc_> But I can also understand if we don't do any marketing since we're a grassroots community. So it's fine eitherway
<JOhNKmus> If we do marketing maybe it would be a good idea to target areas with privacy conscious people/culture. Not sure how to determine that though...
<sgp_> dsc_: if you advertise Mastering Monero, we may be able to pay for a budget
<dsc_> Interesting.
<xmrscott[m]> I think the video would be worthwhile. While organic word of mouth growth is great, if we want to accelerate adoption the word needs to get out to more people
<sgp_> Yes, I think marketing is fine
<sgp_> as long as it isn't predatory
<sgp_> any final comments before we wrap up? thanks dsc_ for introducing the topic and offering your skills
<sarang> Any MRL questions?
<sgp_> when auto churn?
<xmrscott[m]> We should probably have a semi-formal postmortem for DEFCON in the next month or so after folk have had a chance to rest, but before people forget too much
<sgp_> kidding
<sarang> I'm on mobile but can type slowly
<sgp_> xmrscott[m]: indeed, would be good
<xmrscott[m]> I'll post the info here after polling folk for a good time in -defcon
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 7 September at 17:00 UTC. The next Coffee Chat will be on 24 August at 16 UTC.
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Overview and Logs for the Dev Meeting Held on 2019-08-11

Sun, 11 Aug 2019 00:00:00 GMT

Logs

<dEBRUYNE> so dev meeting? :P
<jtgrassie> hi!
<dEBRUYNE> Who's here? hyc, vtnerd, sarang, suraeNoether, moneromooo, jtgrassie, luigi1111, fluffypony
<rbrunner> Certainly!
<dEBRUYNE> Probably forgetting a lot of people
<dEBRUYNE> Guess it's vacation time for a lot of people :-P
<Guest16177> here more or less
<dEBRUYNE> So what should we discuss?
<kinghat> o/
<jtgrassie> testnet->rx ?
<jtgrassie> as in when can we fork testnet to RandomX
<rbrunner> Maybe that would be good with moneromooo back from "frolocking amoung cows" or so
<sarang> Here, live from def con
<rbrunner> Def con party then? :)
<sarang> Very good attendance at the def con village this weekend, for sure
<kinghat> even being off the beaten path?
<rbrunner> Anyway, concerning RandomX: The reviews are all through, right?
<sarang> Yes, for sure
<sarang> Having free badges was a huge help
<vtnerd__> ... present (too busy too lock at clock) ...
<sarang> https://ostif.org/four-audits-of-randomx-for-monero-and-arweave-have-been-completed-results/
<dEBRUYNE> I think what is left is to merge the RandomX PR from hyc and set a testnet fork date
<hyc> hey sorry, was afk. but yes
<rbrunner> Yes, nice to see all those "fixed" and "solved"
<dEBRUYNE> As a side note, thoughts on releasing 0.15 binaries in early september already?
<dEBRUYNE> Or would that be too short
<hyc> would probably need mooo's opinion there
<hyc> what's our outstanding PR count look like anyway?
<dEBRUYNE> I am thinking that we have freedom to release early as we do not have any last minute consensus changes
<dEBRUYNE> Quite a lot, but I am working with luigi to get the queue down :P
<dEBRUYNE> luigi & mooo*
<hyc> cool
<hyc> a mid-Sept release date sounds plausible. basically 1 month from now?
<dEBRUYNE> Sounds like a decent target
<dEBRUYNE> It also gives services, users etc. a larger time frame to prepare
<dEBRUYNE> The forks with binaries 1 week in advance were admittedly quite hectic :-P
<hyc> so we would expect testnet to switch to randomx on that mid-Sept date
<hyc> on or around...
<jtgrassie> it would be nice to have testnet fork a little earlier to randomx imo
<sarang> There was some issue with another project's switch to RandomX, right?
<sarang> Was that an issue with a miner implementation?
<hyc> Loki. xmrig bug
<hyc> there are no issues with the monerod integration
<dEBRUYNE> What was the effect of the bug?
<dEBRUYNE> (in the miner that is)
<hyc> jtgrassie: so, switch over testnet earlier, but on self-compiled binaries maybe?
<hyc> dEBRUYNE: the miner didn't reinitialize the dataset when seed epoch changed
<jtgrassie> yes
<hyc> all blocks mined after that point were invalid, rejected by daemons
<hyc> restarting the miner would get it working until the next epoch
<hyc> but it was patched pretty quickly
<dEBRUYNE> Ah I see, so part of the network hashrate basically disappeared because they were mining invalid blocks
<hyc> yes
<rbrunner> So will those mid-September binaries now be the ones that do not support *long* payment id's anymore? I lost a little the overview
<hyc> no idea, haven't followed payment ID discussion
<dEBRUYNE> needmonero90: did Binance provide you with a timeline?
<needmonero90> https://usercontent.irccloud-cdn.com/file/IA4ai9LF/Screenshot\_20190811-102559\_Telegram.jpg
<needmonero90> https://usercontent.irccloud-cdn.com/file/eo22z2BE/Screenshot\_20190811-102608\_Telegram.jpg
<needmonero90> https://usercontent.irccloud-cdn.com/file/YcXsymNo/Screenshot\_20190811-102612\_Telegram.jpg
<needmonero90> There was the latest.
<needmonero90> I can upload the full convo to pastebin if you want it
<sarang> neat
<rbrunner> Yeah, sounds good
<tat> moneromooo: are there any infos on which exchanges would be able to receive/send to subaddresses after the mid September fork?
<tat> sorry i meant needmonero90
<dEBRUYNE> Anyone got contacts at bittrex or bitfinex? I tried reaching out to them on reddit, but did not get a response
<needmonero90> Bittrex can be contacted over their slack iirc
<needmonero90> At least a year and a half ago that was the case.
<rbrunner> Well, they also could contact *us*, at least in theory :)
<tat> would be good to create a list, i guess some exchanges will be concerned if removing the ability to use payment ids cribles them to get transactions from other exchanges
<needmonero90> Tat: I just took up the discussion with binance because someone had to do it, I don't have the list of other exchanges.
<tat> needmonero90: thx
<needmonero90> I will happily talk to whoever if we get a contact
<needmonero90> Just ping me their details
<bibble> Kraken important
<needmonero90> Kraken will be fine
<bibble> oh, great :)
<needmonero90> Least of our concerns on the exchange front
<tat> i think if at least 3-5 big exchanges would move to subaddresses, that would put some pressure on the rest and they probably follow within a reasonable timeframe
<rbrunner> Well, "reasonable timeframe" is almost over, with hardfork in mid-October, wouldn't you say?
<rbrunner> Maybe they are pretty quiet because they don't want let people look into their cards ...
<tat> rbrunner: we are talking of not using long payment id's anymore, integrated addresses would still work i guess, so most of the exchanges will still be able to work with that as is
<rbrunner> Ah, ok, right, misunderstood you
<dEBRUYNE> The most important thing is to get them off long payment IDs imo
<rbrunner> Certainly, if we don't support them anymore in 2 months
<hyc> so these exchanges aren't supporting integrated addrs yet?
<tat> hyc: it depends, i think poloniex uses integrated addresses, bitfinex uses 64 char payent id's
<hyc> yes, polo uses integrated
<tat> dEBRUYNE: do you think receiving of transactions with long payment id's will be still supported by the wallet
<rbrunner> Who would send those, and how?
<tat> i mean in theory you need to be able to resync, so to prevent that, the wallet would have to ignore all long payment id's from block height X
<rbrunner> Yes, the code is full of such switches "Starting from height x stop to do X and start do to Y"
<rbrunner> Daily business, so to say
<tat> rbrunner: is there really only one source for code of the monero wallet, is there any wallet implementation that isn't using monero c++ wallet core?
<rbrunner> I would guess that starting with the fork height the long payment just does not get decoded / delivered to the wallet anymore
<rbrunner> tat: Not sure about MyMonero's code
<moneromooo> I'm happy with testnet switching to randomx as soon as a patch is made fwiw.
<rbrunner> Otherwise I think it's pretty much a monoculture
<moneromooo> Pony's the one to get on board since seed nodes and his mining node will need to be updated then.
<tat> i mean if there is any wallet that will still send with long payment id's, it wont be too bad, since funds will still arrive but if you rely on that id to track incoming setlements you are screwed
<moneromooo> The wallet will ignore the payment id IIRC. It'll still get the money of course.
<dEBRUYNE> hyc: The big ones are binance, bittrex, bitfinex
<dEBRUYNE> needmonero90 is currently working with binance, I will try to get ahold of the other two somehow
<hyc> moneromooo: all that's needed before merging the existing randomX integration patch, then, is setting the block height for the testnet fork
<moneromooo> IIRC I put a command line switch somehwere to enable something there.
<moneromooo> (about payment id decoding)
<tat> i would say if an exchange is still using long payment id's and he switches within one month, and he is not able to process long payment id's anymore he will have two years of still receiving to those long payment'id since not all users get that change immediately
<hyc> they should've switched to integrated addrs 2 years ago ...
<tat> i think a command line switch would be pretty fair, with the emphasis on this feature will be deprecated, that would send the right signal
<rbrunner> What do you mean with "not all users get that change immediately"? Your software will stop to work after the hardfork, no?
<hyc> and it's their own obligation to notify their users if deposit addresses change
<rbrunner> Maybe I misunderstand, but this is not Bitcoin where the move to SegWit takes 5 years or so ...
<moneromooo> The wallet has been warning it's deprecated for a while.
<tat> hyc: so you are full positive that sending out with long payment ids will be impossible after the next hard fork
<moneromooo> It will likely be still possible.
<jtgrassie> fwiw, we have been stating long payment ids are deprcated for ages now. they are a problem for privacy and IMO removed asap.
<moneromooo> But if several large exchanges still use long payment ids close to the fork, I might be convinced to consensus ban them.
<rbrunner> "Close to the fork" ... being ... about today :)
<moneromooo> Oh.
<needmonero90> To elaborate, using them has required going to advanced settings and toggling a box saying "don't do this" before you could send for ages.
<moneromooo> Is there fork soon ? I missed the talk.
<hyc> mid-OCtober presumably
<moneromooo> We're liky july, no ?
<rbrunner> No, I mean, as far as big projects are concerned, 2 months pass in a blink of an eye
<moneromooo> August. Close enough.
<moneromooo> OK, true.
<needmonero90> I did give binance until October, so it would be nice not to go faster than that
<moneromooo> So "binance, bittrex, bitfinex" sounds like a lot indeed.
<needmonero90> Or I'll have to backpedal and apologize and politick
<tat> i totally support that point, but for the poor souls that use still long payment ids and continue to receive payments, after the fork with long payment ids, since some users/exchanges will still do so it will be case for customer suport every single time
<rbrunner> "Possible" does not mean "easy to do". Maybe would need your own doctored self-compiled software
<jtgrassie> exchanges and users won't ever stop using payment ids while they are still possible.
<rbrunner> Which would work because *consensus* would still allow the long id's
<vtnerd__> to the above: mymonero is indeed not using the monero core wallet - it simply cannot actually
<vtnerd__> the light wallet server and openmonero implementations are using parts but not the whole as well for the same reason
<vtnerd__> but the payment id stuff is client side which has already moved away from long ids
<tat> i think making it impossible to send long payment ids, but have a switch that still allows to decode them would be a good move, possible fading that switch out over time
<endogenic> yeah our pure fns for long payment ids were actually deleted in mymonero core iirc
<endogenic> fwiw monero core can adopt that code
<rbrunner> I think long payment id's still floating around after the work is much less probable than some poor exchange not being able to receive payments at all
<rbrunner> s/work/fork
<tat> rbrunner: could be true, there is only a few wallets, if they all disallow that, and there is no hand woven code that push transactions to the network
<hyc> we have certainly seen oddball txns on the network before, which probably came from custom wallet code
<hyc> but I don't see that as our problem to manage
<jtgrassie> except it potentially weakens other users privacy
<jtgrassie> (e.g. if those odd tx outputs get used as decoys)
<jtgrassie> which is why i favor banning long payent ids at protocol level
<hyc> I'm a bit reluctant to do that since we still are keeping extradata itself
<dEBRUYNE> Banning in october seems a bit optimistic imo
<hyc> but if the official wallets have already disabled generating them by default, seems OK to me
<rbrunner> You do mean the long payment id's? Well, backing down now could set a bad precedent
<moneromooo> FWIW, to see what I've done: https://github.com/moneromooo-monero/bitmonero/commits/crash
<hyc> yes
<moneromooo> I don't remember exactly so can't give a tl;dr :)
<moneromooo> (grep for "payment" in the commit title)
<hyc> this? https://github.com/moneromooo-monero/bitmonero/commit/0951c3a9ad0c8376b8abd8908603166d7ffc174d
<jtgrassie> that one looks good to me
<moneromooo> Yes. There's at least another one a few commits earlier.
<hyc> I also see ignoring receivedo nes https://github.com/moneromooo-monero/bitmonero/commit/6aad370708c0c06c1091912fcc97dceaa09d5b75
<rbrunner> So standalone *short* id's are gone also, at least over RPC, if I read that code correctly.
<rbrunner> Only integrated over RPC
<hyc> yeah that all looks good to me
<moneromooo> Yes. They were never supposed to be supported. I added them because I'm an idiot. luigi was right.
<rbrunner> Now we just wait what bittrex, bitfinex say :)
<rbrunner> I still count on them not being stupid, just not noisy - working on it for quite some time already
<hyc> back to randomx - any suggestions for testnet fork date? 1 week from today? sooner? later?
<moneromooo> Whenever pony can be certain to have his nodes updated.
<moneromooo> So... mid november ?
<hyc> sigh...
<rbrunner> 2 weeks, for the next meeting?
<moneromooo> Oh. I did have some minor stuff I wanted to add for v12.

Overview and Logs for the tini2p Dev Meeting Held on 2019-08-08

Thu, 08 Aug 2019 00:00:00 GMT

Logs

<tini2p_gitlab> 0: Greetings
<tini2p_gitlab> hi
<tini2p_gitlab> 1: What's been done
<tini2p_gitlab> Reworked a BuildRequestRecord, BuildReplyRecord, and TunnelBuildMessage to be templated based on symmetric crypto used (AES/ChaCha20)
<tini2p_gitlab> reorged the commits, because the changes were verbose, and most (if not all) were for code added in the tunnels branch
<tini2p_gitlab> Added Hopand OutboundGateway classes for tunnel message processing
<tini2p_gitlab> OutboundGateway is still WIP, and will hopefully be finishing up today
<tini2p_gitlab> didn't get nearly as much done as I had hoped, so scaling back my expectations a bit
<tini2p_gitlab> going to push back alpha release two weeks
<tini2p_gitlab> 2: What's next
<tini2p_gitlab> will be finishing OutboundGateway, and implementing OutboundEndpoint, InboundGateway, and InboundEndpoint
<tini2p_gitlab> those are the last of the message processing classes
<tini2p_gitlab> dev is somewhat slow because I'm implementing AES + ChaCha tunnels simultaneously (which adds some headache), but it should be worth it in the long-term
<tini2p_gitlab> ultimately, I think it is faster to do both simultaneously
<tini2p_gitlab> after the processing classes, I'll start implementing tunnel pools and management classes
<tini2p_gitlab> given the experience of the past couple weeks, pools + management could take a week each, so alpha may actually be a month away
<tini2p_gitlab> hopefully not, and I'll do my best to complete them correctly as fast as possible. correctness takes priority over speed, though
<tini2p_gitlab> 3: ECIES Status
<tini2p_gitlab> development and discussion on 144 continues
<tini2p_gitlab> there has been progress over the last couple meetings, and hopefully we're getting closer to consensus on what 144 goals + spec should be
<tini2p_gitlab> zzz is insistent on unlimited 0-RTT messages, and reusing ephemeral key data for cached DH results
<tini2p_gitlab> I think both are bad ideas
<tini2p_gitlab> unlimited 0-RTT messages opens an attack vector for never completing the handshake, where a mitm on the reply tunnel drops Bob's New Session Reply messages
<tini2p_gitlab> or allows the reply messages through, but blocks Alice's Existing Session messages
<tini2p_gitlab> reusing ephemeral key data could lead to the same symmetric key being used to encrypt the New Session and New Session Reply payload sections
<tini2p_gitlab> in a version of the spec that sends multiple New Session (Reply) messages, encrypting different payload sections with the same key material breaks ChaCha20-Poly1305
<tini2p_gitlab> it's a fragile scheme, that requires a lot of analysis and care to get right
<tini2p_gitlab> I'm proposing that instead of sending unlimited New Session and New Session Reply messages, we send one each, including up to the maximum data for one payload section (~60KB)
<tini2p_gitlab> until the New Session Reply is received by Alice, she will drop any other messages from the client destined for Bob
<tini2p_gitlab> somewhat outside the protocol, I'm suggesting Alice's router send a "please resend in X seconds/minutes" as a reply to the client until the session is established
<tini2p_gitlab> similarly, if Bob's initial reply is too large to fit in one Payload section, Bob will send a "please resend after session established" message to Alice
<tini2p_gitlab> Alice can then send a "reply was too large for initial message, please retry the request"
<tini2p_gitlab> ^ can send that to the client
<tini2p_gitlab> alternatively, Alice and Bob could queue messages until session establishment, but that could lead to resource exhaustion. less desirable and less secure
<tini2p_gitlab> latest I2P LS2 meeting log: https://gitlab.com/tini2p/meta/issues/26
<tini2p_gitlab> I'll likely be implementing the drop-until-secure, single New Session (Reply) scheme until we come to consensus on what to do
<tini2p_gitlab> 4: Next meeting
<tini2p_gitlab> 2019-08-22 18:00 UTC
<tini2p_gitlab> @tini2p_gitlab juggles baffer like a hacky sack
<tini2p_gitlab> thinking further about the "resend request" message Bob sends when the reply is too large for a single payload section, Bob could include the original request in the message
<tini2p_gitlab> Alice could then extract the request, and resend in the first Existing Session message

Logs for the Monero Research Lab Meeting Held on 2019-08-05

Mon, 05 Aug 2019 00:00:00 GMT

Logs

<sarang> Let's go ahead and get started
<sarang> suraeNoether says he is unavailable at this time due to an appointment
<sarang> Agenda is here, where logs will be posted: https://github.com/monero-project/meta/issues/381
<sarang> GREETINGS
<needmonero90> hello
<sarang> Seeing as it's a quiet day, I'll move right along to ROUNDTABLE
<sarang> I finished work on an efficient RCT3 verifier that takes advantage of Bulletproof-style inner product scaling
<sarang> and also added fee support, which the original paper didn't natively support
<sarang> As well as many other assorted code library updates that I'd been meaning to get to over time
<sarang> Finally, I've been preparing for my DEF CON talk and workshop, and also made a simple CTF puzzle
<sarang> What have other folks been working on?
<needmonero90> nothing of particular note here, though I'm curious what the latest on the different ring signature schemes is
<sarang> Aha, that'll be the topic of my talk!
<needmonero90> its been on my mind :D
<sarang> Why's that?
<needmonero90> transaction efficiency (both time and space) is one of the obstacles we need to overcome
<sarang> Agreed
<needmonero90> randomX seems fairly solid now
<sarang> Of course, these proposals aren't really long-term scaling solutions
<sarang> but they would provide welcome improvements
<needmonero90> Is this meeting slow because of defcon? I assume so
<sarang> There are still some questions on an RCT3 proof that are being investigated
<sarang> and on the possibility of Omniring efficiency improvements
<sarang> so the status of different tx protocols may change over time
<sarang> On that note, an ACTION ITEM for me is to return to Omniring analysis
<sarang> it's a more complex approach (computationally) than RCT3
<sarang> and one of those things where the usual efficiency analysis sweeps some types of simple operations under the rug
<sarang> but those operations can add up fast!
<sarang> This weekend's village is of course another big action item :)
<sarang> Slow day today :/
<sarang> Well, in the interest of respecting everyone's time, are there any questions or other research of interest to share?
<sarang> (crickets)
<JOhNKmus> hey I happen to be here
<sarang> hello
<JOhNKmus> I was going to ask if there has been any helpful stuff from Lelantus?
<sarang> The authors have been working on a modified prover that offloads some of the proving complexity to the verifier (and pays a bit in size)
<sarang> and the goal is still to remove the tracing that's present (and necessitates self-spend operations)
<sarang> But AFAIK there have been no solutions as of yet
<JOhNKmus> Ah okay, cool.
<sarang> I suspect that removing that problem would require big architectural changes to the whole construction :/
<sarang> but I hope that I am proven wrong :)
<sarang> Well, since it's a quiet day I suppose we can adjourn the meeting quite early
<sarang> Hopefully livestreaming will be happening at the DEF CON village so everyone can see the talks
<sarang> I'll post my slides to github after my talk, since they have (IMO) some nice and simple information comparing tx protocols
<sarang> Thanks to everyone for attending today!

Logs for the Community Meeting Held on 2019-08-03

Sat, 03 Aug 2019 00:00:00 GMT

Logs

<sgp_> meeting time
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<serhack> Hi!
<needmonero90> Hello people
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/380
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<OsrsNeedsF2P> Hello
<serhack> Hi :)
<JOhNKmus> Hello everyone
<lh1008[m]> Hey everyone
<sgp_> welcome everyone
<jwinterm> ahoy
<needmonero90> Ahoy hoy
<kinghat> |o/
<sgp_> I'm reporting live from a world-famous beach in Wisconsin. Just kidding, it's not world-famous. But I am at a beach
<lh1008[m]> Thanks
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com/
<kinghat> o_0
<sgp_> There was a Coffee Chat led by rehrar last week: https://www.youtube.com/watch?v=1S5UotVgku8
<monerobux> [ Monero Coffee Chat - 2019.07.27 - YouTube ] - www.youtube.com
<sgp_> Ecosystem related: I’m hosting a Zcash community conversation on the future of the block reward Sunday (tomorrow): https://forum.zcashcommunity.com/t/livestream-discussion-future-of-zcash-block-reward/34247
<sgp_> Does anyone else have community (non-workgroup) updates to share?
<OsrsNeedsF2P> I was impressed by XMR.RU's report
<needmonero90> Kinda, what are the sections again?
<sgp_> yes, they do a lot of great work
<needmonero90> I want to talk in the right place
<sgp_> needmonero90: https://github.com/monero-project/meta/issues/380
<sgp_> if you're unsure, we should have plenty of time in open ideas
<needmonero90> Ah this works actually.
<needmonero90> We have a problem.
<needmonero90> Konferenco funding.
<needmonero90> There was a shortfall, and one of our beloved PhD researchers (sarang) is now footing the $30-40k bill.
<needmonero90> Taking it extremely well, might I add
<needmonero90> I don't think that this is an appropriate state for things to be in, and I would like to propose a second CCS be created for the community to cover the shortfall
<needmonero90> I will of course be putting my money where my mouth is and contributing a chunk, it sets a really bad standard if the organizer is on the hook for overages in costs at the event.
<OsrsNeedsF2P> What caused this?
<needmonero90> I imagine that would be a massive sticking point to attracting talent to the position in the future, it's a huge risk
<needmonero90> Price fluctuations and unforseen konferenco costs (which admittedly sarang was not entirely unresponsible for)
<nioc> OsrsNeedsF2P: the market tanked after the funds were raised
<nioc> and before they were converted to $
<needmonero90> I told sarang that I was appalled that he expected to be on the hook for the costs, and that I would bring it up at the next community meeting
<needmonero90> So here I am
<jwinterm> that's a chunk of change
<needmonero90> Yes.
<nioc> needmonero90: sarang or surae?
<needmonero90> One of them
<needmonero90> Whoever organized
<needmonero90> May have been surae
<nioc> I believe it is surae
<needmonero90> Lemme check
<sgp_> needmonero90: did you read the full funding report? Probably good to talk to scooby about the accounting specifics too
<needmonero90> My bad it was suraeNoether
<needmonero90> I didn't yet, I just thought it would be appropriate to broach the subject here
<needmonero90> Because $40k is significant
<xmrmatterbridge> <rehrar> It should be noted that he would only be like 4k on the hole if the market had shifted so drastically.
<sgp_> needmonero90: if you want to champion this, I recommend talking to scooby so you have a full picture of the finances
<xmrmatterbridge> <rehrar> Market shift accounts for literally like 85% of his loss. So not "bad planning" or anything.
<needmonero90> I can do that, sure.
<thunderosa> Thanks for bringing it up, I wasn't quite sure the best way to mention it. I've been thinking of some possible fundraising ideas though. I'm willing to volunteer for the effort.
<dsc_> apart from trying to recover the funds, is this something that can be avoided in the future? 1) Allow for dynamic/moving CSS targets 2) release funds ASAP
<sgp_> we can also consider other options, including some allocation for the next Konferenco CCS that will inevitably happen. There are a few possible reimbursement options
<ferretinjapan> You can't force a conference to be funded if people aren't interested in it.
<sgp_> dsc_: yes, immediate release needs to happen for trusted entities in the future
<maxfp> Ayeoo
<ferretinjapan> The conference should appeal to the needs of the fundees after all.
<sgp_> needmonero90: is there anything you specially wanted to have answered, or are you feeling for support?
<needmonero90> I just wanted to make this a topic of discussion and explain where I think things stand
<needmonero90> I'm minorly advocating a new CCS for the shortfall, but I'm not too particular about where we go with it
<needmonero90> Just wanted the subject up for discussion
<xmrmatterbridge> <rehrar> If we're being real, that conference will be the highlight of Monero's year, just in quality. Talks freely available on YouTube as a resource for years to come.
<sgp_> All right, please keep going with the initiative and let us know how it goes. Might be best to open a Reddit discussion too
<sgp_> yes, the recordings are very valuable
<sgp_> I will keep going with the meeting, but we can cover this topic again during open ideas if people have other comments
<sgp_> thanks for introducing the idea needmonero90
<sgp_> Any other non-workgroup updates to share?
<ferretinjapan> Maybe a focus on those types of deliverables should be emphasised?
<sgp_> 3. CCS updates
<sgp_> CCS proposals in ideas to be discussed:
<lh1008[m]> I suggest to ciber this shortfall with a CCS for it, but start on planning and funding earlier for future events (konferenco, defcon, etc.) Be better prepared for this type of things. Have a bigger budget.
<sgp_> “Telegram bot for Monero-Jobs group” (3 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/91
<lh1008[m]> Ciber *cover
<sgp_> Does anyone have comments on this proposal?
<dsc_> looks good to me
<OsrsNeedsF2P> Generally speaking I'm strict with proposals I support, but this definitely has mine
<sgp_> 3 XMR looks reasonable
<dsc_> 3 XMR is too reasonable
<sgp_> lol
<needmonero90> Yeah
<dsc_>
<serhack> me too
<needmonero90> It's like, ramen budget living at your parent's house low
<lh1008[m]> ENDOGEN was not able to make it. I'm part of the Monero jobs chat room. Alteady gave my comments, would like to hear from the community.
<OsrsNeedsF2P> I wish more proposals were like this. He's really outlined the benefits of this
<needmonero90> It's a very good deal, if the code works as advertised.
<sgp_> Any final comments on this proposal? People seem comfortable with it
<OsrsNeedsF2P> >Something like "What would you like to do?" and then there would be three buttons that the user could press: "Request Work", "Offer Work" and "Create Proposal"
<OsrsNeedsF2P> We need this for IRC and Reddit too. I know the outreach team wanted to do something like this
<OsrsNeedsF2P> This is super useful
<sgp_> “A Monero Tip Bot for Telegram” (13 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/86
<lh1008[m]> The 3XMR was what he estimated for his work. He's actually really enthusiastic about it. We will have to see how he delivers of course.
<sgp_> We discussed this similar proposal last week, but I wanted a last call for comments
<sgp_> *last meeting
<dsc_> I honestly feel kind of bad for that 3XMR maybe we should advise him to double it
<lh1008[m]> OsrsNeedsF2P the bot will be open source so I guess we all would benefit :).
<dsc_> I'd be happy to fund that extra 3..
<OsrsNeedsF2P> I provided my insights on that thread, but I still think the Telegram tip bot is asking for too much
<OsrsNeedsF2P> It's definitely a good initiative though.
<sgp_> OsrsNeedsF2P: what # or range would you feel comfortable with?
<OsrsNeedsF2P> Well here's the thing; it's a custodial service that really will just be running one wallet and a very simple file tracking everyone's balance.
<needmonero90> That feels like something that should be done open source and maintained by core
<needmonero90> Like, the servers
<OsrsNeedsF2P> That's the intention ^
<sgp_> luigi specified in the thread that he would feel comfortable moving it with an agreed-upon host
<OsrsNeedsF2P> Luigi said he's willing to move it forward if a suitable host is found
<OsrsNeedsF2P> Let's review his funding points
<needmonero90> Like idk, I'm not sure we need to pay for this one? I think repurposing osrs's bot would work fine
<needmonero90> We could maybe talk to endogen
<OsrsNeedsF2P> My bot is non-custodial, finding a host is much more difficult
<lh1008[m]> I like the tip bot. That sure will also help.
<OsrsNeedsF2P> Keeping wallet synced is a b**
<OsrsNeedsF2P> I like the tip bot as well. I think getting it out no Telegram is worth it. But his funding points directly:
<OsrsNeedsF2P> >>Collect Feature Requests and Prototype the Telegram bot: 1 XMR
<OsrsNeedsF2P> Thoughts?
<sgp_> tbf it's <$100
<needmonero90> Prototyping is an essential part of any project
<xmrmatterbridge> <rehrar> I think the hope was the core team would indeed host it.
<xmrmatterbridge> <rehrar> I can ask them what their thoughts are for doing that.
<lh1008[m]> Endogen suggested once he worked the monerojobs.bot and be.working he wil add a multisig wallet for it.
<OsrsNeedsF2P> If there's an integratable telegram tip bot though, that would be much easier
<lh1008[m]> Yep
<OsrsNeedsF2P> >Implement Features: 5 XMR
<needmonero90> OsrsNeedsF2P: you reminded me
<needmonero90> There is
<needmonero90> Briar patch has a SPICE token tipbot
<needmonero90> For spicy comments
<needmonero90> I can see if it's open source or whether they can share the code
<needmonero90> If we get the code, it cuts the work significantly.
<OsrsNeedsF2P> Honestly, you guys overestimate how hard it is to make a tip bot
<OsrsNeedsF2P> All the APIs already exist
<OsrsNeedsF2P> The only reason the Reddit Tip Bot took so long to perfect the UX was soley because I was keeping everyone's wallets separate. Knowing as little as I did (no RPC, hardly Python), that would have still been a 1 day job
<xmrmatterbridge> <rehrar> #makeitthenlol
<lh1008[m]> What would be a reasonable price OsrsNeedsF2P? Just give your thoughts.
<OsrsNeedsF2P> I think 5 XMR to implement it is reasonable. I don't think any of his other requests are;
<OsrsNeedsF2P> >>Intensive Testing of Bot on Stagenet Within one or more Monero Telegram groups / Bug Fixing: 4 XMR
<OsrsNeedsF2P> >>Maintenance and Support: 3 XMR (one time fee)
<OsrsNeedsF2P> The prototype is certainly worth 1 XMR if there is really a solid prototype goal he's following, but unlike Endogen's request for instance, it's not nearly as clear or laid out
<lh1008[m]> What does everyone else think? I'm no coder so for me is quite hard to know more.
<lh1008[m]> But if OsrsNeedsF2P says it is because he knows. Those are my thoughts.
<OsrsNeedsF2P> The only thing I can't really comment on is the bot would likely be written in Javascript, and I'm very poor at estimating the difficulties in that
<OsrsNeedsF2P> But that is within the Implement Features category
<dsc_> I think OsrsNeedsF2P should be head of Python Monero robots
<dsc_> as such I trust his authority on the matter
<lh1008[m]> I've heard javascript is terrible so I wouldn't like something written in javascript. But again, I'm no coder so is like...mmm
<sgp_> To summarize, OsrsNeedsF2P feels the cost is about twice as much as it should be, and hosting still needs to be resolved. Overall, the benefits are generally understood as valuable
<OsrsNeedsF2P> Very valuable I might add; also, the condition Luigi set was already on the hosting.
<lh1008[m]> We could tell him that the community supports a 5XMR proposal and wait and see his response.
<sgp_> Perhaps the course of action should be first to figure out hosting, and then try to negotiate slightly better rates. But in the absence of others willing to code, we may not have other rate options
<OsrsNeedsF2P> I would even donate if it was only 5 XMR. 5/6/7, depending on what he offers.
<sgp_> OsrsNeedsF2P: please add your comments again after this meeting in the thread, along with anyone else who has an opinion
<OsrsNeedsF2P> Will do.
<sgp_> Any final comments on this matter?
<sgp_> Another reminder to Luigi/rehrar: please move the v1docq47 proposal, which was discussed in detail and received favorable feedback last meeting
<sgp_> Final chance for CCS comments
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> moneromooo is taking a much-needed vacation
<sgp_> progress is continuing with various networking features and tests
<sgp_> rehrar: want to summarize the dev meeting from last week?
<dsc_> I have to get off my train. Cannot provide GUI update other than: pony is building bins, I'm working on I2P-Zero still.
<sgp_> thanks dsc
<maxfp> I know I’m coming into this late. Talking bout hosting. What about using Tari .org
<maxfp> Are we talking container deployments?
<xmrmatterbridge> <rehrar> Sorry. Got busy for a bit.
<sgp_> now is a good time to ask if there are localization workgroup updates too, or else we can skip that section
<needmonero90> Do we have a pirate localization workgroup yet
<xmrmatterbridge> <rehrar> We talked about Gitlab/GitHub stuff and people have opinions.
<lh1008[m]> I will give a small summary from outreach
<sgp_> needmonero90: there was for one old version at least iirc
<xmrmatterbridge> <rehrar> Did anything else of interest pop up?
<sgp_> sure lh1008[m], we can do that for e)
<xmrmatterbridge> <rehrar> Not to my mind. But I may just be forgetting something
<sgp_> rehrar thanks
<sgp_> I can give an update for d) Defcon workgroup
<sgp_> Please check https://monerovillage.org for the livestream links (will be posted soon) and schedule (posted now). We will unfortunately only learn around 9:30am MT on Friday whether the events will be livestreamed. It's dependent on Defcon staff, but we'll keep you updated
<sgp_> e) Outreach workgroup
<lh1008[m]> sent a long message: < https://matrix.org/\_matrix/media/v1/download/matrix.org/RRYzFHFhqHanRLjmjzmyNPQV >
<sgp_> Copy of link contents:
<sgp_> About transcriptions:
<sgp_> - All Breaking Monero transcriptions done.
<sgp_> - MoneroKon from 26/12 already finished. 7 merged and 5 in review process.
<sgp_> https://github.com/monero-ecosystem/outreach-docs/tree/master/monero-outreach-docs/en/transcriptions
<sgp_> https://taiga.getmonero.org/project/xmrhaelan-monero-public-relations/epic/198
<sgp_> thanks lh1008[m], anything else? we look forward to your help for Defcon
<lh1008[m]> Thank you sgp_
<sgp_> 5. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<sgp_> We have a good 8 minutes, don't be shy!
<lh1008[m]> That would be all. The rest of MoneroKon are in production. Every talk has a volunteer.
<lh1008[m]> Yes of course count with us
<needmonero90> So, I want to talk about skepticism Sunday. Specifically, people posting the same stuff repeatedly with no intention of following up or responding to replies
<sgp_> ah, the "uncensored version of this thread" person
<needmonero90> To be more direct, yes
<needmonero90> That's not skepticism
<lh1008[m]> I have one. We should be better prepared for events and shortfalls.
<sgp_> imo remove, easy decision for me
<needmonero90> Any objections? I can just blacklist the link from that thread specifically.
<needmonero90> Scalpel
<lh1008[m]> Have never been on sundays skepticism. I guess I will also participate on them.
<sgp_> lh1008[m]: indeed, that has been an ongoing effort. MRL takes payment before working the three months to reduce volatility
<lh1008[m]> Yep I've seen those efforts too.
<lh1008[m]> Something else. We should support more those artisitc initiatives. Just take this into your pillow discussion >:).
<sgp_> we also need official Monero Village and Monero Party hashtags
<sgp_> #MoneroVillage #defcon27? #Monero #Defcon27?
<lh1008[m]> Thank you everyone. Have to finish reviews. Love you all.
<lh1008[m]> #MoneroVillage
<sgp_> We're running out of time, but think about hashtags and comment here if you have good ideas. Of course this channel is always open for discussions after the meeting
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 17 August at 17:00 UTC. The next Coffee Chat will be on 24 August at 16 UTC. Thanks rehrar for handling the last one.
<xmrmatterbridge> <rehrar> Ye
<sgp_> 7. Conclusion
<xmrmatterbridge> <rehrar> Question on those.
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

Logs for the Monero Research Lab Meeting Held on 2019-07-29

Mon, 29 Jul 2019 00:00:00 GMT

Logs

<sarang> OK, let's begin
<sarang> Hello all
<sarang> Logs of this meeting will be posted to the GitHub agenda issue afterward
<sarang> GREETINGS
<suraeNoether> greetings!
<kenshamir[m]> hey
<sarang> Whoops, here is the current agenda: https://github.com/monero-project/meta/issues/377
<sarang> Let's go ahead with ROUNDTABLE
<sarang> I've been working hard on an RCT3 implementation, integrating some nice optimizations and seeing if it's possible to get key images working as expected
<sarang> This also led to a bunch of other library updates that the code relies on
<sarang> So generally just a lot of coding
<sarang> I also gave a fun lecture on the Enigma cipher machine and the math behind it, which is always fun ;)
<suraeNoether> nice, what was that for? a meetup or something?
<sarang> A friend teaches at a university and thought it would be good for an undergrad crypto class
<sarang> Since the Enigma break is all about permutation groups
<suraeNoether> nice
<sarang> I should be able to finish up an integration of the BP inner product verifier optimization into RCT3 shortly
<sarang> Then, of course, DEF CON approaches!
<suraeNoether> neat
<suraeNoether> i have a very dirty branch on my computer with my matching simulations and experiments being worked upon
<sarang> How are those going?
<hyc> defcon - anyone got grasshopper repellent?
<sarang> -____-
<suraeNoether> i've proven all the theorems necessary to prove that the algorithm in graphtheory.py does what i claim it does, and i'm currently testing that my simulated ledgers are doing what i expect.
<sarang> noice
<sarang> Will be very neat to see the results, and to see if/how they can work with the analysis that Isthmus et al. are doing on Monero and Zcash
<suraeNoether> in addition to that, i have a bunch of MAGIC stuff I need to get done, and my discussions with isthmus' digital forensics work are leaning in that direction
<suraeNoether> i'm thinking the content of this project may take up more than two papers :\
<sarang> Cool!
<sarang> Also worth noting that the CLSAG paper has been updated on IACR, thanks mainly to kenshamir[m]'s comments and questions
<sarang> kenshamir[m] has also been working on a Rust implementation of CLSAG/MLSAG using the dalek library
<suraeNoether> hyc: i hear grasshoppers are delicious, i wonder if any of those fancy vegas michelin star restaurants are capitalizing on the swarm
<sarang> Anything you'd like to share on that, kenshamir[m] ?
<kenshamir[m]> Hi, the library is finished, not interopable with monero because it uses a different curve though. The numbers are quite impressive and I believe it is due to the way cLSAG was created
<sarang> aw shucks
<sarang> Will be great to see your MLSAG vs CLSAG numbers at different ring sizes
<suraeNoether> i believe there was a question re: ristretto and multi-exp like pippenger right before the meeting that would be relevant here?
<sarang> I brought it up a while back because we handle different linear combination sizes _very_ differently in the codebase
<scoobybejesus> is that rust code in a public repo?
<sarang> We use no fewer than 4 methods
<kenshamir[m]> The numbers above were for different ring sizes, I may have mis-typed key sizes by accident
<kenshamir[m]> 256 and 512 were for the decoy sizes; if I was not clear
<sarang> A big part of the reason CLSAG verification is faster than MLSAG is because of the introduction of a new linear combination evaluation algorithm
<sarang> kenshamir[m]: can you link them again for the logs?
<sarang> (if comfortable having them public)
<kenshamir[m]> <scoobybejesus "is that rust code in a public re"> Not the cLSAG code, once I add documentation and sanitise it I can post it in here
<sarang> ty
<kenshamir[m]> <sarang "kenshamir: can you link them aga"> Yep sure
<scoobybejesus> :)
<sarang> What does "without Pippenger/Straus" mean? Simple iterative evaluation of linear combinations?
<kenshamir[m]> Yep exactly
<sarang> Impressive numbers
<sarang> Of course, it's a different hash function
<kenshamir[m]> I just did scalarbase mult in a for loop
<kenshamir[m]> haha yeah that too
<suraeNoether> hmmmmm
<sarang> But if the hash function is the same across both of your CLSAG/MLSAG, then the relative numbers are good
<suraeNoether> something that is both faster and smaller and with equivalent security is a no-brainer for implementation (pending audits)
<sarang> Speaking of this, still in contact with potential auditors, who are moving very slowly
<sarang> Nothing to report on that front :/
<suraeNoether> the improved space allows for a logarithmic increase in verification time without actually slowing down the network (at least when it comes to new nodes downloading the network). judging by these numbers, a ring size of 16 or 32 is no longer like pouring molasses or concrete onto the network
<sarang> OK, any other interesting research to report?
<gingeropolous> re: audits, or roll-out in general. Is this the kind of thing that could be rolled-out in parallel with existing? i.e., have an overlap, where the network uses the existing as the primary / default, but can optionally use the new thing, and then once new thuing is vetted, just prune the old?
<hyc> ^ slow auditors - a lot of people are on summer holiday now
<gingeropolous> or, switch to the new and no longer have to relay / verify the old style during the overlap?
<suraeNoether> sarang: am i wrong in saying that gingeropolous is correct that clsag could be implemented in parallel before mlsag is deprecated?
<hyc> we had a 24hr overlap in the last hardfork for this sort of thing
<gingeropolous> this would be kinda different.
<sarang> I suppose it could be overlapping, provided the fee model supports it properly
<sarang> I don't really see why this would be useful
<gingeropolous> i dunno. i'm just opening the conversation regarding the model that all new things need to be audited
<gingeropolous> i mean, obvi auditing is great
<sarang> yes
<gingeropolous> but its not perfect
<dEBRUYNE> hyc: Yeah in general, summer constitutes low activity
<sarang> It's good for inspiring confidence, as well as the obvious benefits of catching any errors
<kenshamir[m]> Can Monero benefit from using bulletproofs for arithmetic circuits?
<dEBRUYNE> gingeropolous: Didn't we discuss that kind of model for Bulletproofs or RingCT too?
<sarang> Likely not, with our current tx model
<gingeropolous> yeah dEBRUYNE
<sarang> The scaling isn't great
<dEBRUYNE> I think it was shot down for good reasons, but I cannot remember them exactly :-P
<gingeropolous> i think that was post audit though
<sarang> and we have hash functions, which screw things up
<sarang> Zooko had a slide in some presentation where his team estimated the verification time for a circuit with the complexity of Sapling (Sprout? don't recall)
<sarang> and BP verification was O(1 s)
<sarang> Compared to our current verification time which is probably 1/50th of that
<sarang> maybe 1/100th
<kenshamir[m]> yikes
<suraeNoether> kenshamir: if we designed an arithmetic circuit to describe a ring confidential transaction language, then yes, but that's sort of what RCT3 and omniring and lelantus try to do... sarang, i think zooko was showing "what it would look like for a Sapling transaction language to be proven in the bulletproof setting" not ring confidential transactions, so it's not clear to me whether it'd be slower.
<suraeNoether> in our setting
<suraeNoether> with the exception of our non-AC-compatible hash function
<dEBRUYNE> sarang: That's verification time for fully shielded transactions?
<suraeNoether> dEBRUYNE yeah, iirc
<dEBRUYNE> Yikes
<sarang> Yeah, that timing was just to give an example of what a production-size tx circuit might look like
<dEBRUYNE> Especially given that, as far as I know, you have to run a full node in order to properly perform fully shielded transactions
<dEBRUYNE> Anyway, I digress :-P
<sarang> Anyway, suraeNoether is right in that RCT3 and Omniring try to bring the BP benefits to specific languages used to prove RingCT-type statements
<sarang> which is why we're interested in them
<suraeNoether> yeah, bulletproofs for use in SNARK-style languages is like... uhm... putting a large-diameter turbofan engine into a Mini Cooper. It's not going to do what you think it's going to do.
<sarang> BPs can be much more efficient for languages built for it
<sarang> which is why range proofs are so efficient
<kenshamir[m]> haha
<suraeNoether> indeed
<suraeNoether> moving along
<sarang> heh
<sarang> ok, other research?
<sarang> Or QUESTIONS, from the agenda?
<sarang> OK then! To ACTION ITEMS
<sarang> I'll be finalizing some things for my DEF CON talk, workshop, and panel; and finalizing some RCT3 integration optimizations
<sarang> suraeNoether: ?
<suraeNoether> oh gosh sorry
<suraeNoether> i was computing a number sorry about that. :P
<sarang> it's 7
<suraeNoether> my action items are: work on sims and the experimenter, and work with isthmus to formalize statistical hypotheses for testing all this
<sarang> Having data from Isthmus's group will be extremely valuable for this kind of analysis
<suraeNoether> actually the number is O(153.58*N), which is the number of bits used to describe the number of possible spend histories at ring size 32 with N outputs.
<suraeNoether> which is nutters
<sarang> This is all assuming no external information?
<sarang> Or other graph-based information on chain reactions and provably-spent outputs?
<suraeNoether> merely the total number of self-consistent spend histories
<sarang> Ah ok, so for a hypothetical graph
<suraeNoether> yeah
<sarang> got it
<gingeropolous> O(153.58*N) ... great. now your math is talking in math
<suraeNoether> well it means that for, say, 1000 transactions at ring size 32, there are 2^(153,580) possible spend histories.
<suraeNoether> anyway
<suraeNoether> (N has to be a lot bigger than the ring size for the above formula to hold btw)
<sarang> which is... quite reasonable
<sarang> Any other final thoughts or questions before we adjourn?
<sarang> OK then! Thanks to everyone for participating. We are adjourned

Overview and Logs for the Dev Meeting Held on 2019-07-28

Sun, 28 Jul 2019 00:00:00 GMT

Logs

<rehrar> Alright, it's time to start ladies and gentlemen.
<rehrar> 1. Greetings
<rehrar> Anybody out there?
<rbrunner> Nope. All people on holiday.
<rbrunner>
<vtnerd__> yes
<rehrar> well, the three of us can have a grant ol time then
<rehrar> just pinging hyc moneromooo dsc_ selsta and dEBRUYNE also
<rehrar> maybe a luigi1111 and fluffypony in the mix too, who knows
<rehrar> either way
<rehrar> 2. What's been completed since last meeting?
<dsc_> dont ping me broooo
<rehrar> _csd
<rehrar> there, I took it back
<dEBRUYNE> CLI v0.14.1.2 has been released
<dEBRUYNE> Which is mostly bug fixes I guess
<dEBRUYNE> mooo is holding a vacation, but he provided me a list of stuff that is ready to be merged
<dEBRUYNE> So I am working with luigi to get the merge queue relatively empty
<kinghat> 🙏
<rehrar> ah, did not know mooo was on vacation
<rehrar> I hope he ignores my ping then. Sorry!
<dEBRUYNE> For the GUI, we tagged 0.14.1.2 and we're waiting on pony to finish the builds
<dsc_> I'm more than half way into integrating i2p-zero and tor into GUI
<dEBRUYNE> Main new feature is optimized Tails support
<dEBRUYNE> Perhaps dsc_ can share a bit more detail
<dsc_> Sure thing.
<rehrar> dsc_: that's actually super exciting
<dsc_> So Tails integration is a collection of improvements that improve user experience for our Tails users
<dsc_> You would be suprised how big the audience is there
<dsc_> So, starting from 0.14.1.2 it will be very easy to use GUI on Tails
<dsc_> As for i2p-zero, I need a couple of days then that's done too
<dsc_> I suggest to package i2p-zero with the GUI release
<dsc_> Which can pose problems for our reproducible build efforts
<dEBRUYNE> I don't see much harm in packaging it with the GUI, especially if the user first has to check a checkbox to turn it on
<dsc_> but that's a problem for later
<dsc_> That also
<rbrunner> Shouldn't the CLI pack it also then?
<dEBRUYNE> I think most CLI users are able to download the package themselves
<dEBRUYNE> And get it running (especially given the instructions present on Github)
<dEBRUYNE> By contrast, GUI users need a checkbox and not tons of steps
<rbrunner> Ok, makes sense, more or less ...
<dsc_> The fact we package i2p-zero is a convienence feature. I'm also 'integrating' support for Tor but we wont be packaging that. That's basically running Tor and using socks proxy at :9050
<rehrar> we GUI people are scrubs
<xmrmatterbridge> <xmr-romine> is there already some doc about running monerod over tor ?
<dsc_> https://github.com/monero-project/monero/blob/master/ANONYMITY\_NETWORKS.md
<dEBRUYNE> https://github.com/monero-project/monero/blob/master/ANONYMITY\_NETWORKS.md & https://github.com/monero-project/monero#using-tor
<xmrmatterbridge> <xmr-romine> thanks guys
<rehrar> hyc any update on randomx audit?
<rehrar> The last one?
<dsc_> One more thing regarding i2p-zero.. It can take up to 1-2 minute(s) for the local socks proxy to become 'active' which means, if the user has i2p-zero enabled and starts up the GUI to create a quick tx ... might have to wait a minute or two
<dsc_> This is related to how i2p-zero works
<dsc_> so beware of that limitation
<rbrunner> So it's i2p-two, from "two minutes"?
<kinghat> can it check if i2p is currently running?
<dsc_> rbrunner: haha
<rehrar> it's how i2p works in general, no? Getting bootstrapped into the network, I mean.
<dsc_> rehrar: most likely
<dsc_> kinghat: it can
<rehrar> under bad circumstances it can take even longer
<rehrar> I wonder if there can be some kind of notification to let users know this
<vtnerd__> tor should have similar issue iirc, building circuits isn't immediate
<kinghat> also, are we still going to do the beta builds for the gui?
<dsc_> vtnerd__: Sure, but not 1-2 minutes?
<dsc_> kinghat: yes
<kinghat> 👌
<vtnerd__> I think it might be longer than that, at least it seemed like forever yesterday when I was testing
<vtnerd__> actually no, I've run tails once before, it takes some amount of minutes, just don't remember the exact time frame
<dsc_> vtnerd__:
<dsc_> $ time (sudo service tor restart && sleep 2 && torify curl icanhazip.com)
<dsc_> 171.25.193.77
<dsc_> real0m2.759s
<vtnerd__> if your not using outbound connections tor destroys the circuits and goes into an idle mode too, which isn't a problem if "noise" is enabled (because its always sending)
<rehrar> there goes dsc_ bragging about his internet again
<dsc_> yes, my internet.
<vtnerd__> it keeps state in a file that it might re-use, so you'd have to a cold restart
<dsc_> vtnerd__: fair enough
<rehrar> alright, anything else?
<dEBRUYNE> vtnerd__: I was wondering if you intend to pick this up somewhere in the future? https://github.com/monero-project/monero/pull/2317
<vtnerd__> see https://github.com/monero-project/supercop/pull/2
<vtnerd__> this one and the next one after that PR is a bit rough because its x86 ASM
<rehrar> that was a hilarious conversation to witness
<rehrar> person 1: i was wondering if git link
<rehrar> person 2: Well you see it's like git link
<dEBRUYNE> Thanks
<vtnerd__> Im also not certain that having a separate repo for this is beneficial, but I guess some other project could make use of the custom hooks
<vtnerd__> my original code should need some re-working since the device/ledger stuff got slammed in, but I look at recently and I think its possible to rebase/update that without crying
<vtnerd__> Im also not certain whether that supercop repo should be an external git thing, or something that you manually have to do
<vtnerd__> I'm thinking the latter, since people are blasted without another submodule
<vtnerd__> *are not
<dEBRUYNE> I see, seems like a thing that warrants more in depth discussion in a future dev meeting
<rehrar> With more attendees?
<rehrar> serious question
<rbrunner> And maybe some more background info to prepare
<rehrar> who should be present for such a discussion?
<rehrar> we can add it to next meeting as an item and try to ping the people to be there
<vtnerd__> the background is either the supercop code goes as a submodule and it must be synced by every person
<vtnerd__> or only those that which to accelerate wallet scanning drop the repo into a folder and toggle a cmake bit
<rbrunner> So that's not something for the normal, general release then?
<vtnerd__> its not needed for testing, unless you need to test the feature specifically
<vtnerd__> no, likely it would be in the normal general release, but I suppose it doesn't have to be
<vtnerd__> this came up because ryo recently added support for basically the same thing, and it should cut wallet-scanning time in half
<vtnerd__> although its probably dependent on your HD speeds too
<rehrar> alright, any more discussion on this?
<hyc> re: randomx audit, Quarkslab are finalizing their report, said we may get it by middle of next week
<rehrar> nice!
<rehrar> does anyone have anything else that they want to discuss?
<hyc> since they've been opening github issues as they arose, there's not likely to be anything in the report we haven't already seen
<ErCiccione> yep! https://github.com/monero-project/meta/issues/236#issuecomment-515669422
<ErCiccione> GitHub is starting to censor people coming from countries under US sanctions, we should definitely migrate away
<ErCiccione> i don't know how the core team feel about it
<rehrar> do people here have any thoughts about the Github/Gitlab thing, especially in light of the recent Github things?
<vtnerd__> those countries listed probably require some vpn/tor/i2p opsec to contribute anyway ... ? I'm certainly not attempting to stop a switch to a self-hosted gitlab, but meh
<rbrunner> If such a switch was so easy it would probably have happened already, I think, after the Microsoft acquisition ...
<vtnerd__> or maybe not, but they would have to after that hammer that was thrown
<rbrunner> With all submodules still on GitHub, for example
<vtnerd__> the support team for the gitlab instance are probably the most relevant for this
<ErCiccione> rbrunner: the point was to test monero-site on the self-hosted gitlab first, and then see what to do with the other repos. But has been almost an year now
<hyc> I've always favored moving to self-hosted gitlab and away from github
<rbrunner> Yeah, I remember. But I think the site is a particularly simple case
<vtnerd__> I mean most devs should have a copy of the code and history luckily, but its the discussions that can get purged if not backed up properly
<hyc> but this particular issue only affected private, paid github accts
<hyc> (i.e., github closing off accts from sanctioned countries)
<ErCiccione> hyc: i guess that depends by how they are forced to enforce the sanctions
<hyc> https://twitter.com/natfriedman/status/1155533738278699008
<hyc> https://twitter.com/natfriedman/status/1155311121038864384
<hyc> they're splitting some hairs I guess. trade sanctions only affect commerce. if you paid for a private acct, you're affected.
<rbrunner> Has any other notable cryptocurrency team already made such a switch?
<hyc> if you're on a public/free acct, you're not affected
<rehrar> rbrunner: define notable?
<rbrunner> I mean, some "interesting" team. Top 100 coin, maybe? Sizeable community, I mean
<ErCiccione> thanks for the links. it's still a very precarious situation.
<ErCiccione> rbrunner: sia
<rbrunner> And complexity of the code
<hyc> ErCiccione: agreed. as I already said, I'm in favor of moving off.
<kinghat> i think ppl are worried about contributions after moving off github. i dont think it would make a difference.
<hyc> again, just my perspective: the OpenLDAP Project maintains our own repo. we only mirror to github, because it seems you're not a real project these days if you're not on github
<hyc> out github mirror is read-only
<hyc> our*
<ErCiccione> kinghat: i agree.
<dsc_> I keep repeating myself but I question people whose first thought is 'gitlab' when thinking of a git alternative
<dsc_> There is more! Noooo.. Yes!!
<dsc_> Consider it...
<hyc> gitea?
<dsc_> for example, yep
<hyc> I don't really care which alternative is used. all I care is self-hosted.
<ErCiccione> iirc gitea was considered
<hyc> you could make an argument that being off github adds a barrier to entry - people don't like having to create accounts just to interact with another project
<rehrar> In favor of gitea
<dsc_> Even more so when considered gitlab is a company, enterprise, they have funding, maybe they have shareholders - and capitalism is evil. Therefor, gitea
<rehrar> hyc which is why I am arguing for a federated git ecosystem
<rehrar> open issues on another git based project management site from yours, etc
<ErCiccione> let's not forget that we already have half repos on github and half on gitlab. That's not ideal
<hyc> rehrar: agree, federated identity would be preferable
<rehrar> let's build it
<rehrar> we can have it out by Wednesday at the latest
<hyc> +1
<dsc_> ok sounds good
<ErCiccione> i want 2
<rehrar> that'll take an extra day
<hyc> this could be a long conversation, but totally - we need to rethink the notion of accounts and identities
<rehrar> But for reals though this is an ongoing discussion and...
<rehrar> ^ hyc
<rehrar> we have the issue open about this that ErCiccione
<rehrar> although that one is about moving to gitlab, I think
<rehrar> so maybe another one can be opened for discussion on which platform?
<dsc_> +1 for centralized authentication service
<dsc_> (hosted by monero)
<rbrunner> Oh the added complexity
<dsc_> rbrunner: for whom?
<rbrunner> The system in general, I mean.
<dsc_> It could simplify things
<hyc> not quite centralized authent. just public key based.
<rbrunner> Something more that can go wrong
<ErCiccione> rehrar it is yes, as hyc says for me the important is to move away from a centralized place. I think gitlab is the best choice because we have been testing it for an year, but sure let's discuss alternatives
<hyc> we could use monero wallet addresses as our identities
<rehrar> hyc I've been thinking of using Monero signatures as password alternatives
<dsc_> thats a cool idea
<rehrar> public key as ID
<rehrar> signature from private key as password
<kinghat> does that work with subaddys or am i missing something?
<rehrar> but then losing your seed is even a bigger deal
<rehrar> or getting it stolen
<hyc> good point
<rehrar> as long as there are standard ways of resetting or something
<rehrar> it's no more annoying than losing or getting your regular password stolen
<hyc> having a reset facility implies a centralized admin authority
<dsc_> Call the Monero helpdesk and provide them your miaden name, your first car brand and your date of birth
<hyc> ^
<rehrar> enforced 2/3 MFA then
<hyc> should we wrap up the mtg before continiung this conv?
<rehrar> but yeah, we'll call it here
<rehrar> unless anyone has any last minute things?
<vtnerd__> I hope to finally issuing some PRs related to the i2p/tor white noise stuff, took some time to architect this bt hopefully. nothing else needs to be reported by that really other than look for more stuff to review
<rehrar> cool deal!
<rehrar> well everyone, thanks for making the time today.
<rehrar> You're all free to disperse. Coffee on the little table outside the meeting room.

Overview and Logs for the tini2p Dev Meeting Held on 2019-07-25

Thu, 25 Jul 2019 00:00:00 GMT

Logs

tini2p 0: Greetings
hello all
1: What's been done
merged ECIES updates for 144 updates + my spec suggestions: tini2p/tini2p!12
had a long discussion about 144 at this week's LS2 meeting: tini2p/meta#23
getting closer to a solid spec there, though there is still quite a bit to get done / come to consensus on
more updates to 152, and got rid of Blowfish: https://gitlab.com/snippets/1878282

tini2p basically, instead of using Blowfish for nonce encryption, tunnel gateways will keep a nonce counter
they advance the counter for every set of tunnel messages, concatenate the counter to the random tunnelNonce, and participants use the counter to ChaCha20 encrypt the tunnelNonce
participants don't change the counter value, but do need to verify it against an independent Bloom filter
there may be a fancy way to validate uniqueness of the counter without a separate Bloom filter, or save space by having a sliding Bloom filter with fewer elements that advances as it becomes full, TBD
the naive way is just to have two Bloom filters though: one for the tunnelNonces, one for the counters

tini2p unfortunately had to spend more time than I wanted working on specs this last week, so didn't make as much progress on code as I wanted
began work on ECIES tunnels, and have the BuildRequestRecord and BuildReplyRecord basically done: https://gitlab.com/tini2p/tini2p/tree/tunnels
2: What's next
I'll be spending the remainder of today working on tunnels, trying to get them "finished" (aka functional)
if I can't get them done today, I'll push back alpha release one more week. will do all I can to complete the work on end-to-end communication through tunnels
I could just "ship it" today, but tunnels aren't complete. I would really like to have an end-to-end functional setup in alpha release, even without interop with existing I2P network

tini2p even with interop, I will be setting a testnet netid, so communication with the main I2P network would require custom compilation
so, my focus will be on getting ECIES tunnels working with ECIES-only tunnels, and using the new layer encryption proposed in 152
hopefully, that will be finished by next week
after that, I will implement mixed tunnels with ElGamal participants, and the existing tunnel layer encryption
3: Questions / comments

tini2p 4: Next meeting time
2019-08-08 18:00 UTC
if I'm able to make alpha release by next Thurday, I'll make an announcement in here as well.
no meeting next week otherwise

David Burkett :thumbsup: Keep up the good work @tini2p_gitlab

tini2p thanks @DavidBurkett :smile:

David Burkett If you ever need me to help test anything, I'll gladly do so. Just let me know.

tini2p will do, thanks for the offer!!
thanks to all for attending / reading
meeting over

Logs for the Monero Research Lab Meeting Held on 2019-07-22

Mon, 22 Jul 2019 00:00:00 GMT

Logs

<sarang> OK, let's get started
<sarang> GREETINGS
<suraeNoether> hello fellow not-robots
<sarang> Let's move on to ROUNDTABLE
<sarang> suraeNoether: care to begin?
<suraeNoether> sure
<suraeNoether> so this weekend i finally posted the konferenco post mortem report, the budget, and markdown'd all the things: https://www.reddit.com/r/Monero/comments/cfsc2m/suraes\_content\_dump\_konferenco\_post\_morto\_budget/
<suraeNoether> this includes my research report for the last quarter and my request for funding for Aug, Sep, Oct.
<suraeNoether> And isthmus pointed out a property of zcash's shielded pool that i am capable of modeling with my matching simulations, so i've spent a few hours this past weekend trying to get those working (still a wip)
<suraeNoether> that's all
<suraeNoether> sarang?
<sarang> Nice!
<sarang> I've posted the handout and some sample code for my upcoming DEF CON workshop
<suraeNoether> nice! thatsafineoutreach.gif
<sarang> (note that you should not use the handout or sample code in production environments, of course... only for playing around)
<sarang> And I have incomplete work on an RCT3 proof of concept implementation
<sarang> with some efficiency improvements
<sarang> the batching opportunities for RCT3 are quite nice
<sarang> as is the fact that the prover and verifier are relatively straightforward
<sarang> also also it can take advantage of any existing rangeproof implementation
<sarang> Any questions on these?
<kenshamir[m]> Hi Sarang, yes
<kenshamir[m]> Do you believe that all of the alternatives; omniring, ringct and lelantus would be a better alternative to the current ringCT even with cLSAG?
<kenshamir[m]> Are you waiting for a feature or an event before choosing a specific alternative?
<kenshamir[m]> better in terms of performance, space savings and anonymity set
<sarang> In terms of practical anonymity set, the sublinear schemes are an improvement at first glance
<sarang> but
<sarang> Lelantus requires a separate output pool and self-spends to avoid tracing
<sarang> Omniring does not support efficient batching
<sarang> RCT3 requires a separate output pool
<sarang> and in all cases, larger anonymity sets require a careful look at handling ring representation, which can become substantial
<kenshamir[m]> Hmm, so is it fair to say that in their infancy, they are not ready to take over the current ringCT?
<sarang> IMO not without a lot of careful thought on implementation details
<sarang> That being said, I'm looking at two particular things regarding that:
<kenshamir[m]> Do you think it would be better to move away from hiding users in a set of users, to hiding coins in a set of coins?
<sarang> One is determining if/how to efficiently split the rangeproof from Omniring for better verification
<kenshamir[m]> Similar to zcash
<sarang> Two is figuring out if it's possible to use the same key image format with RCT3
<sarang> Full anonymity would be great if we could do it efficiently
<dEBRUYNE> And without a trusted setup :P
<kenshamir[m]> > Two is figuring out if it's possible to use the same key image format with RCT3
<kenshamir[m]> This is very interesting
<suraeNoether> "Do you think it would be better to move away from hiding users in a set of users, to hiding coins in a set of coins?" <-- what's the difference?
<suraeNoether> at a KYC exchange, the exchange knows your personal details and which coins are yours. same same as far as the most common threat model is concerned... unless i'm missing something
<sarang> Oh I totally missed that distinction in what kenshamir[m] said
<sarang> In all cases, users are used to derive coin data
<sarang> Anon sets are considered by coins, not by users
<sarang> Does that answer your question kenshamir[m] ?
<kenshamir[m]> Yep, I was re-reading it to make sure I understood
<kenshamir[m]> <dEBRUYNE "And without a trusted setup :P"> yes this too :)
<sarang> This actually leads neatly into my ACTION ITEMS
<sarang> I'm working on including proper batch verification in the proof of concept code, and integrating into the test transaction flows
<sarang> Then I want to dive more deeply into the two things I mentioned to kenshamir[m]
<sarang> 1. splitting Omniring proofs for better batching
<sarang> 2. determining the feasibility/security of retaining key image structure in RCT3 to avoid an output pool split
<sarang> And finalizing DEF CON material, of course
<sarang> I'll be giving a talk and leading a workshop in the Monero village, as well as staffing an information table
<sarang> and also doing a panel discussion in the blockchain village
<sarang> suraeNoether: your action items?
<suraeNoether> uhm just working on sims
<suraeNoether> i want to finish the matching stuff soonish to start answering questions rigorously
<suraeNoether> and i want to catch up on your work on the Big Three Trustless Protocols, which is what i'm calling them in my head
<sarang> Yes, IMO the matching stuff is a priority in terms of getting results
<sarang> Moving back in the agenda slightly, does anyone else have either research to present or general questions to ask?
<kenshamir[m]> What was the matching stuff, you guys are referring to?
<sarang> Treating possible spend histories in the tx graph as a graph matching problem
<sarang> and analyzing the structure and complexity
<sarang> In an ideal tx graph, the number of valid matchings (under any data you might already have) should be very high, to provide useful anonymity
<kenshamir[m]> <sarang "Treating possible spend historie"> ohh right, this is very cool research
<sarang> It's one possible metric to examine anonymity
<sarang> (but certainly not a complete one)
<kenshamir[m]> right, it would be interesting to see how much certainty you can produce from such a graph in terms of monero
<sarang> Initial estimates show that it's extremely low
<sarang> but that assumes no external knowledge
<suraeNoether> depends on the size, really.
<kenshamir[m]> I don't know much about it, however I am assuming that it can be used to show how certain one can be that two outputs are linked
<suraeNoether> i mean, a graph where everyone churns 100 times before spending... huge graph... obviously going to have a ton of false results
<sarang> Right, but if done poorly, you can develop heuristics on partial matchings
<kenshamir[m]> I wonder how external data influences the graph, and what type of external data
<sarang> That's the big question on this research
<sarang> Without that, it's purely academic
<kenshamir[m]> As in a real-world scenario, an adversary will have access to external data. I believe the strongest adversary would be an exchange
<kenshamir[m]> oh right
<sarang> Exchanges, governments, entities with broad access to network data
<sarang> It's a big part of why these sublinear schemes are so critical in research
<sarang> At some point, any useful graph data gets lost in the noise of large anon sets
<sarang> (this does not eliminate all types of analysis, of course)
<kenshamir[m]> So the strongest type of external data, would be to know who owns some percentage of outputs and who they are?
<suraeNoether> kenshamir[m]: that's part of it
<kenshamir[m]> <sarang "At some point, any useful graph "> Yep right
<suraeNoether> kenshamir[m]: periodicity can be used to great effect, too
<sarang> True, timing can play a large role
<sarang> both in anon set selection and tx operations
<kenshamir[m]> <suraeNoether "kenshamir: periodicity can be us"> Could you explain?
<suraeNoether> IP data from the network when you ctrl-v your txnid into a block explorer without tor immediately after the transaction is relayed
<kenshamir[m]> Is that "I see a payment being sent every monday at 7pm"
<kenshamir[m]> * Is that "I see a payment being sent every monday at 7pm"?
<suraeNoether> kenshamir[m]: okay well, imagine you are a churner with a superstitious streak and you like to churn every 88 minutes
<suraeNoether> that chain of churns will stick out like a sore thumb
<sgp_> Joining now and caught up, hello everyone. I agree this matching paper is top priority right now
<suraeNoether> a smart churner selects the age they wait between churns from the wallet distribution. then all the outputs in the ring are drawn from the wallet distribution and no timing data is leaked at all
<kenshamir[m]> Right, that makes sense
<suraeNoether> but any sort of additional data like IP address or timing can be merged together into a big bayesian updating machine and you can develop pretty good (if probabilistic) behavior profiles of users. and this applies to zcash and monero
<kenshamir[m]> suraeNoether: do you mind going into some detail on how you are simulating?
<sarang> So right now it's a balance between determining how many times to churn (to diffuse the graph) and how not to do it badly
<sarang> To do this, we need better data (e.g. matching)
<suraeNoether> kenshamir[m]: sure, let's do it after the meeting though because it's a little involved
<sarang> OK, any other questions or work to present for this meeting?
<sarang> going once
<sarang> twice
<sarang> OK, we are adjourned! Thanks to everyone for joining us. Logs will be posted to GitHub shortly

Logs for the Community Meeting Held on 2019-07-20

Sat, 20 Jul 2019 00:00:00 GMT

Logs

<sgp_> community meeting starting now
<sgp_> 0. Introduction
<sgp_> We would like to welcome everyone to this Monero Community Workgroup Meeting!
<sgp_> Link to agenda on GitHub: https://github.com/monero-project/meta/issues/374
<sgp_> Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
<sgp_> 1. Greetings
<rottensox> o/
<ArticMine> hi
<el00ruobuob_[m]> Hi
<sarang> Hi
<rehrar> oyo boyo
<xmrscott[m]> Yo yo yk
<kinghat> hey
<rehrar> Yo yo yk
<parasew[m]> hello!
<sgp_> 2. Community highlights
<sgp_> See Monero weekly highlights at https://revuo-monero.com/
<sgp_> rehrar put me out of a job :)
<sgp_> Does anyone else have community (non-workgroup) updates to share?
<sgp_> 3. CCS updates
<sgp_> CCS proposals in ideas to be discussed (one by one):
<sgp_> “v1docq47: video creation / translations into russian (august – january)” (37.8 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/84
<rehrar> sure
<sgp_> lh1008 indicated support on Gitlab, I also support
<el00ruobuob_[m]> v1docq47 seems to have done a huge amount of work on his previous FFS, i vote for.
<msvb-mob> Hello.
<sgp_> any other comments?
<rehrar> ne
<pwrcycle> I just read the FSS, but seems good to me. I vote yes.
<sgp_> great
<sgp_> second one: “A Monero Tip Bot for Telegram” (13 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/86
<rehrar> he updated prices
<rehrar> seems more reasonable now
<rehrar> I say sure
<jwinterm> aren't there already a bunch of telegram tipping bots available?
<jwinterm> $1k for forking a repo and running bot seem kinda pricey to me
<jwinterm> but my dumbass does it for free
<parasew[m]> is this the tipping bot which is at use in the monero-germany tg group?
<el00ruobuob_[m]> i didn't see he updated price. For 13XMR, sounds good to me
<pwrcycle> I don't see the use in a app specifit, channel specific bot. And I think there are other bots that can do this already.
<pwrcycle> FFS says: "This bot is the first of its kind..." I do not agree with that.
<el00ruobuob_[m]> wait, there is a tg tipping bot on monero-germany parasew[m]?
<rehrar> I seem to remmber there was one one day
<rehrar> but if there is one that exists, please comment with that one there
<pwrcycle> If the Tip bot is so good, why not just build it and have people tip you for it? Why a FSS?
<parasew[m]> el00ruobuob_[m]: yes there is one, but testnet only
<pwrcycle> I vote no on the tip bot.
<el00ruobuob_[m]> it should be easy to just update the existing one then...
<parasew[m]> this is the tipbot on monero germany: https://imgur.com/a/S7k3oa2
<rehrar> parasew[m]: where is the repo?
<parasew[m]> not sure where repo is, i just remembered the bot there; let me search for more info
<rehrar> thx
<el00ruobuob_[m]> not reinventing the wheel could be great here. If there is a bot already, i don't see the benefit of a new one.
<rehrar> yep
<xmrscott[m]> Agreed, work smarter, not harder as they say
<rehrar> so the prereq of my support is no good bot existing
<rehrar> next?
<sgp_> any final comments? seems like this is a reasonable question to address first
<parasew[m]> bot might be the same that is the one of the CCS in question. i asked in monero germany tg
<sgp_> please comment on gitlab when you get more info
<sgp_> third idea: “rehrar-sarang WCC” (30 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/87
<parasew[m]> yes sure
<rehrar> I vote yes
<rehrar> er
<rehrar> I mean
<rehrar> I recuse myself
<sarang> I abstain from a "vote" on this, obviously
<el00ruobuob_[m]> are you confident with a 10% buffer at the moment?
<msvb-mob> I like the IRC tippero a lot, this is a nice idea.
<el00ruobuob_[m]> i see price raise and fall like of 20% those days...
<rehrar> dude the market is def much more valite than normal
<rehrar> we can maybe do 15%?
<rehrar> but that's a bit much
<sarang> Excess to general fund?
<sarang> (if there is any)
<el00ruobuob_[m]> it's your call, i just found market so volatile...
<rehrar> we can do that
<sarang> Then perhaps a higher margin would be acceptable
<pwrcycle> sarang's talks are really good. rehrar is really personalable at big events and really knowledgable. I vote yes on WCC.
<sarang> (provided this is all specified on the CCS)
<sarang> thanks pwrcycle
<parasew[m]> i second
<el00ruobuob_[m]> btw, i am sure for it. You two are great speakers
<sarang> rehrar: I assume you would not be the one to merge this particular CCS?
<sarang> Should be done by someone else for better transparency
<rehrar> sure
<rehrar> I never merge
<rehrar> luigi does
<sarang> oh nvm
<sarang> thought you also did
<sgp_> any final comments on this one?
<Inge-> +1 on WCC
<sgp_> 4. Workgroup report
<sgp_> a. Daemon/CLI workgroup
<sgp_> 0.14.1.2 is tagged now I believe
<sgp_> I'm out of the loop on the difference between 0.14.1.1 and 0.14.1.2
<selsta> v0.14.1.1 had problems with checkpoints
<selsta> We forgot to change a file.
<sgp_> selsta: thanks
<sgp_> any other recent developments you think are worth mentioning?
<selsta> difference between v0.14.1.0 and v0.14.1.2 is mostly bug fixes
<sgp_> thanks
<sgp_> b. Localization workgroup
<sgp_> Is ErCiccione[m] here to give an update?
<sgp_> or anyone else with a comment
<sgp_> all right, nothing to report
<sgp_> c. GUI workgroup
<sgp_> dsc_: want to discuss some of the recent work you have done?
<sgp_> there was recent work on better TAILS support, and up next is i2p-zero integration
<sgp_> there have been quite a few other UI changes
<sgp_> better account support, better balance card, etc
<sgp_> any GUI questions? I may be able to answer them
<selsta> better balance card is work in progress
<sgp_> https://github.com/monero-project/monero-gui/issues/2298
<selsta> v0.14.1.2 GUI will also come out soon after CLI.
<ArticMine> One question is ow fees are displayed
<sgp_> selsta: will there be any UX changes, or just bundled with the latest daemon?
<ArticMine> how
<ArticMine> The fee levels do not correspond to the actual fees
<selsta> sgp_: Bug fixes and minor UX changes.
<hahsun> hi everyone
<sgp_> ArticMine: I do not know the answer to this, probably best to ask in #monero-gui
<sgp_> hello hahsun
<hahsun> did I miss the meeting?
<sgp_> no, still ongoing
<hahsun> cool :)
<sgp_> any GUI questions or updates?
<sgp_> d. Defcon workgroup
<sgp_> We just had the meeting before this, so I won’t say much more here other than to say all the final preparations are being made now. Please go to #monero-defcon if you want to help out.
<sgp_> Direct all questions there please :)
<sgp_> Well, we powered through the agenda and are left with 5. Open ideas time
<sgp_> It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
<sgp_> I know many people are busy with Defcon planning right now, but what can the community workgroup do better?
<hahsun> if I missed the questions on the proposal 86 please feel free to ask. I am here now.
<sgp_> hahsun: yes, there were a few questions
<hahsun> unfortunately I have no logs. just joined.
<sgp_> someone mentioned the @MoneroTipBot existing Telegram bot and wanted to confirm that it wouldn't be redundant
<sarang> (it's not on the agenda but I'm also happy to answer any relevant MRL questions during workgroup Q&A)
<hahsun> sgp_: no it is not redundant. I can confirm.
<sgp_> parasew[m] rehrar pwrcycle jwinterm el00ruobuob_[m] xmrscott[m] had comments before, any questions?
<pwrcycle> hahsun: FFS says: "This bot is the first of its kind..." but there seem to be many other tip bots and Telegram bots.
<el00ruobuob_[m]> How is it not redundant with the one mentioned by parasew[m] https://imgur.com/a/S7k3oa2 ?
<msvb-mob> No questions from me, thanks.
<hahsun> pwrcycle: no there is only one.
<hahsun> el00ruobuob_[m]: that bot you see on the picture is the bot we are testing in the monero telegram groups
<dEBRUYNE> el00ruobuob_[m]: Do you intend to work on the meeting logs btw? I think the last one on the website is from mid june
<hahsun> I can confirm that the bot is not redundant. because the very mentioned @MoneroTipBot IS the bot of the proposal.
<el00ruobuob_[m]> ok, so this is the bot you're going to implement on mainnet?
<hahsun> exactly
<el00ruobuob_[m]> dEBRUYNE, yes, i've been busy on other things, and have to catch back. Will do it soon, i swear
<dEBRUYNE> All right, thanks
<pwrcycle> How would funds tipped from one user to another be handled? Is the bot wallet in custody of XMR during tipping?
<hahsun> we are currently testing the bot in various groups with the help of many people to be able to deliver the bot on time. it is very alpha stage right now and bug fixing is ongoing.
<el00ruobuob_[m]> thanks hahsun, so i'm back on my "ok for me" opinion then
<hahsun> pwrcycle: the bot wallet is a monero-wallet-rpc daemon running with the wallet file open on a VPS.
<hahsun> the goal is to get a trusted member of the core team to host this wallet file.
<hahsun> I asked mooo and he denied. and am now in contact with fluffy to see if it can be run side by side with the IRC tip bot.
<pwrcycle> I don't like that part. Having someone in the middle seems risky.
<hahsun> pwrcycle: it was the best compromise I could think of in this case. this is a custodial bot.
<hahsun> and to seek trust, we came up with the idea to let it run by a trusted member.
<pwrcycle> did the IRC tip bot get a FSS? I don't see how funding something on a private app, for users already, basically into Monero because they are in the channel. So I don't see how the tip bot expands the community.
<hahsun> pwrcycle: I cant comment on the IRC tipbot but I estimate to reach approx. 10k users in telegram in the effort to bring monero closer to the people.
<pwrcycle> I mean, the bot would be cool. And bots in channels are useful. but for the project to fund a bot for one app, why not fund bots for them all, and do bots really bring more people in and connected to the privacy aspect of the project.
<pwrcycle> IRC is where the main project is held and many other FOSS projects, so a bot there would make sense.
<hahsun> pwrcycle: as far as I can tell by now, the bot is a funny way to get together with other people. discussions on various other monero related topics rise through the interaction with the bot.
<pwrcycle> But still, I don't think it was funded, it was just doned.
<pwrcycle> *donated.
<hahsun> pwrcycle: afaik the irc tipbot was a fluffy/mooo project. but I dont know much about it other than that.
<sgp_> fwiw, many other crypto communities are on Telegram and Discord
<pwrcycle> Let those communities fund the bot. If the Tip bot entertains the Telegram channel, let the Telegram channel Tip for it's creation.
<hahsun> also, on telegram, is the church of monero. where people hold masses to exchange small amounts of monero. this teaches people to learn the GUI wallet for example.
<sgp_> pwrcycle: the CCS isn't necessarily "IRC community only"
<sgp_> we are over time, and I'm glad we were able to ask some questions and have some answered. Discussions on this CCS can continue here and on Gitlab
<sgp_> I'm going to conclude the meeting
<sgp_> 6. Confirm next meeting date/time
<sgp_> The next community meeting will be in 2 weeks on 3 August at 17:00 UTC. The next Coffee Chat will be on 27 July at 16 UTC. I will not be present at this event.
<sgp_> 7. Conclusion
<sgp_> That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.
<hahsun> thank you all for your questions.
<pwrcycle> o7
<el00ruobuob_[m]> Bye§
<jwinterm> pwrcycle, afaik moneromooo wasn't ffs for tippero
<selsta> There’s a Monero Austria meetup on August 1st at Riat, https://www.meetup.com/Monero-Austria/events/263317607/
<sgp_> ty selsta
<selsta> topics include deep dive into DLSAG

Overview and Logs for the tini2p Dev Meeting Held on 2019-07-18

Thu, 18 Jul 2019 00:00:00 GMT

Logs

tini2p 0: Greetings
hi
1: What's been done
Not a lot code-wise, spent quite a bit of time working on spec proposals
zzz made some updates to 144 examples, and my suggestions for a NewSessionReply are being reviewed
as of today, here is a diff with my suggestions: https://gitlab.com/snippets/1876476

David Burkett

tini2p hi

David Burkett Don't mind me. Just listening in and hoping to learn something :)

tini2p :) right on, glad to have you here
feel free to ask questions or make comments on anything

David Burkett

tini2p here are my latest updates to the ECIES Tunnels draft proposal: https://geti2p.net/spec/proposals/152-ecies-tunnels
got some feedback from zzz today, so will make a couple more additions
will more or less be moving forward with the changes in the 144 diffs, and the 152 draft
will hopefully have something working by next Thursday
then alpha release
the release will be a bit ugly (code-wise), and will likely change quite a bit between alpha and beta release
but the core functionality will be in place, and at the least building end-to-end sessions will be possible through tini2p routers

David Burkett That's excellent!

tini2p it is NOT recommended to build connections on live networks, or contexts that require strong privacy
given that tini2p is in the earliest stages, there are likely bugs, and there will be very few routers running tini2p

David Burkett Will close my PR to bitcoin core and await further maturation :)

tini2p :)
what do you mean? use it for all the things :P in all seriousness it still needs a lot of work before recommending use to other projects

David Burkett just trolling lol

tini2p if I get interop working with ElGamal tunnels working, technically it would be possible to build tunnels through existing I2P routers
I will add a test network netid to prevent interaction with the live network by default

David Burkett That's what I'm looking forward to...I think. So many protocols, it's a lot to wrap my head around

tini2p so, it means you could build outbound and inbound tunnels using existing I2P routers as intermediary hops
the ends of the end-to-end session would still need to be tini2p routers, until we get 144 fully fleshed out
i.e. you won't be able to connect to existing I2P destinations

David Burkett Still fine with me. So the "tunnels" would be the same protocol as existing destinations, but the "sessions" would be a different protocol?
Or am I wildly incorrect

tini2p even the interop with existing I2P routers as tunnel hops is a maybe, and remains to be tested
so lets take the situation where router A wants to talk to router B
router A builds and outbound tunnel with outbound endpoint of OA
router b builds an inbound tunnel with inbound gateway IB
A and B will need to be tini2p routers

David Burkett G
got it

tini2p the routers between A and OA, and B and IB can be tini2p or existing I2P/i2pd routers
OA and IB can be tini2p/I2P/i2pd as well
that's the goal anyway, integration and end-to-end tests on a test network still need to be done
that's why I'll be adding a test network netid to prevent interacting with the live I2P mainnet by default

David Burkett So if a p2p project decided to use tini2p, it could only communicate with other peers running i2p, but theoretically, it would get the anonymity set of the i2p network as a whole, correct?

tini2p it will require the user to change the code and recompile
if I can get tunnel interop working it would be able to use the existing anonymity set for tunnel building

David Burkett :thumbsup: Understood

tini2p however, it may still be possible to detect tini2p destinations, so may still have a limited anonymity set in that way
for full tini2p stealth mode, it would require using blinded leaseset2 published to netdb
I haven't implemented blinded leaseset2, and they aren't live for I2P or i2pd yet either

David Burkett I don't necessarily need to hide participation, so that would be fine. But it would be difficult to detect which participants are communicating with each other, correct?

tini2p though I think i2pd has made a ton of progress there
tini2p hop participants in tunnels should look like any other I2P hop to existing non-tini2p routers

David Burkett excellent

tini2p they will be distinguishable to tini2p tunnel creators
that should change if 152 is adopted network wide, but that is still a long way off
we're still in the earliest stages of discussing 152
long way from seeing implementation and adoption by other implementations
if it is at all

David Burkett Ah, using the context I just gained from this discussion, I now at least understand what's being proposed in 144 & 152. So thanks!

tini2p awesome, happy to help!
144 is closer to adoption, and when the spec is finalized, tini2p will be able to connect to any destination implementing the spec
zzz has longer estimates than I do for finalization though, so TBD
152 might get split into two proposals, one for tunnel building changes, one for tunnel layer encryption
there appear to be less concerns with tunnel building, and the changes for tunnel layer encryption introduce Blowfish as a new crypto primitive for nonce encryption

tini2p tini2p and ECIES routers need the tunnel building changes to build through existing I2P ElGamal routers, but can use existing tunnel layer encryption for passing/encrypting messages to existing tunnel participants
e.g. there is no way for an ECIES identity to encrypt to an ElGamal identity (no X25519-ElGamal key exchange algo exists)

David Burkett Why Blowfish?

tini2p how 152 proposes solving this is using an ElGamal identity to encrypt build records to existing ElGamal hops, and an ECIES identity for ECIES hops
Blowfish is a 64-bit block symmetric cipher, which is normally a bad idea with new protocols

David Burkett So 152 == Prefer ECIES, but support both for interoperability?

tini2p however, it is only used to encrypt nonces used for ChaCha20 tunnel layer encryption
re: interop, mostly yes. though at first, ElGamal will be preferred in practicality, given they are the entirety of the available hops atm

David Burkett And if a single nonce is compromised, ChaCha20 still remains relatively secure compared to other stream ciphers. So that makes sense

tini2p the only existing practical attack against Blowfish is the Sweet32 birthday attack, which gets block collision in ~2^32 blocks
yeah if the nonce gets compromised, it doesn't affect the ChaCha20 encryption

David Burkett O, then why does Schneier discourage it? Just because it's only 64 bytes?
*bits :)

tini2p nonce compromise does allow two non-consecutive tunnel hops to know they are in the same tunnel, which has some consequences for I2P
64-bit block ciphers are not as good as 128-bit+ block ciphers when using it for full confidentiality, yeah

David Burkett Gotcha, I think I've seen him recommend threefish over blowfish before, even though both are 64-bit. O well, I digress. Carry on

tini2p in this case though, we need Blowfish for it's 64-bit block size because ChaCha20 only has a max of 96-bit nonces
(in the ietf version)
threefish is 64-bit?
if so, I'll change it to threefish

David Burkett I believe, let me check

tini2p the 64-bit block is what's important, so if there is a stronger algo supporting 64-bit block size, I'll use that

David Burkett https://en.wikipedia.org/wiki/Threefish
Looks like it

tini2p :rocket: so nice, thank you!!!
honestly preferred something stronger than Blowfish, so will look into threefish, and it's support in crypto libs

David Burkett Please confirm though. When it comes to crypto, all 'facts' come straight from my backside.

tini2p sure, I will investigate

David Burkett

tini2p While nonce compromise doesn't destroy the crypto system, it does leak info to attackers that could enable strong attacks between non-consecutive tunnel hops

David Burkett Makes sense

tini2p i.e. if E -> H -> G are tunnel hops, and E + G are colluding attackers, compromising H's nonce would allow E + G to know they are in the same tunnel
it doesn't fully destroy the anonymity of using tunnel proxies, but severely compromises it
so want to protect against it as much as possible
why I set the limit of tunnel messages to 2^31, so that Sweet32 attacks against Blowfish aren't possible
though even 2^30 messages will never be practically reached in 10 minute tunnels
it's on the order of millions of messages per second
existing tunnel layer encryption uses double encryption with AES256/ECB for tunnel IVs to defeat the described confirmation attack
duplicate IVs are also rejected, further protecting against the attack
going to run some tests on that, but makes sense atm

tini2p i.e. see if observable patterns can be detected in IVs that only change a bit or two
if they can, then the changes for tunnel layer encryption become much more important

David Burkett There shouldn't be any observable patterns. If changing 1 bit is in any way detectable, the cipher failed

tini2p my hypothesis going into it though is that they can't
right
ECB has its problems, but hopefully it isn't that broken
2: What's next
we basically just covered what I'll be working on over the next week
goal is to get an ECIES impl in place following the 144 diffs, work on solidifying the 152 proposal, and getting a tunnel impl in place

tini2p it may only be possible to do ECIES-to-ECIES tunnels by next Thursday, but sometimes miraculous things happen :)

David Burkett Indeed. Good luck!

tini2p thanks
3: Comments / Questions
4: Next Meeting
2019-07-25 18:00 UTC
will be discussing alpha release, and then resuming 2-week meeting schedule
meeting over!

David Burkett Thanks @tini2p_gitlab!
@tini2p_gitlab bangs a squeaky toy gavel

tini2p thanks for attending!