At the meeting, kayabaNerve (Luke Parker) suggested:

What'd likely be easiest, in a pure-C++ way, is to explicitly intended Monero's DKG to match MRL-0009 (if not already) and have it audited to line up. Then, a Musig2-esque CLSAG should be formalized (likely a modification of MRL-0009's Musig-DN-esque CLSAG?) and Monero should explicitly intended to match it. The fact it lines up should be audited.

My conclusion:

If anyone really wants to work on multisig, especially in the direction of kayabanerve's proposal, please speak up. IMHO, this was a productive conversation, but I don't expect any action to be taken unless more labor [is] put toward the problem.

Meeting log

It is interesting that it took nine transactions to empty the CCS wallet. Is that indicative of somebody new to monero?

No.

A donation wallet has lots of individual transaction outputs that need to be consolidated if you move the entire balance. A transaction that has a lot of inputs that consolidates these transactions will be large in kilobytes. Unless network transaction volume is high enough to push up the dynamic block size rules, the maximum block size is about 300 kilobytes. Transactions must fit inside a single block, so there is a limit to the number of inputs in a single transaction. Plus, you don't want to create a transaction the full 300 kilobytes in size since miners' block creation rules might not mine a transaction that large. The first theft transaction in the list was about 22 kilobytes with 33 inputs:

https://xmrchain.net/search?value=ffc82e64dde43d3939354ca1445d41278aef0b80a7d16d7ca12ab9a88f5bc56a

The next was 99 kilobytes with 146 inputs:

https://xmrchain.net/search?value=08487d5dbf53dfb60008f6783d2784bc4c3b33e1a7db43356a0f61fb27ab90cc

Etc.

The full list: ffc82e64dde43d3939354ca1445d41278aef0b80a7d16d7ca12ab9a88f5bc56a 08487d5dbf53dfb60008f6783d2784bc4c3b33e1a7db43356a0f61fb27ab90cc 4b73bd9731f6e188c6fcebed91cc1eb25d2a96d183037c3e4b46e83dbf1868a9 8a5ed5483b5746bd0fa0bc4b7c4605dda1a3643e8bb9144c3f37eb13d46c1441 56dd063f42775600adf03ae1e7d7376813d9640c65f08916e3802dbfee489e2c e2ab762927637fe0255246f8795a02bd7bb99f905ae7afc21284e6ff9e7f73db 9bf312ed09da1e7dfce281a76ae2fc5b7b9edc35d31c9eb46b21d38500716b6b 837de977651136c18b0018269626be7155d477cc731c5ca907608a2db57ff6a8 9c278d1496788aee6c7f26556a3f6f2cbb7e109cd20400e0b2381f6c2d4e29f4

If you have a Matrix account you should go to https://matrix.to/#/#monero-community-dev:monero.social to get help there and describe your app design. If you are just accepting payments to a website, then you can use BTCPay Server or BitCart.

The Monero blockchain does not hold data in plaintext like other blockchains. You cannot just query the blockchain data through an API. You have to decrypt transactions with private view keys.

Thanks. AGPL vs. MIT, if you mean the cuprate Rust implementation of a Monero node, I was just the messenger for that CCS fundraiser. I am not involved in the project. But there is a little intersection with the fungibility defects issue. If Monero's main wallet code wallet2 would be AGPL (which it isn't. It is BSD, which is similar to MIT) then the closed source multi-coin wallets that implement Monero wouldn't be able to use it. That would increase the number of wallets producing fungibility defects because they wouldn't use the wallet2 procedure.

Thank you! I tried to be clear. Looks like I succeeded :) Let me know if you have any questions or comments.

XMR donations to the MAGIC Monero Fund, which funds Monero research and development, are tax deductible for the donor if you file taxes in the USA: https://monerofund.org/ . Or donations can be made anonymously in XMR if donors do not care about making tax deductions.

Recipients of funds, i.e. devs and researchers, must KYC to MAGIC. It's a system that works for some devs. Others can use Monero's Community Crowdsoucing System (CCS).

(I'm on the MAGIC Monero Fund committee.)