<jpk68:matrix.org> rbrunner7: After looking at issue #8762 (in the core repo), it seems LXMF (based on the Reticulum network) might be decent fit

<jpk68:matrix.org> It can also run over LoRa and packet radio, which is pretty cool

<jpk68:matrix.org> cc tobtoht

<jpk68:matrix.org> It does seem that you can't really set it up over RPC like you can with Bitmessage, which is very annoying. The only good implementation code is in Python, which would be a huge pain to embed

<jpk68:matrix.org> Maybe Nostr over Tor could be used instead? Just throwing out some ideas ;)

<rbrunner7> @jpk68:matrix.org: With "you can't really set it up over RPC like you can with Bitmessage" and "The only good implementation code is in Python" you mean that there is no proper API to drive it, right? If yes, I don't think that this would fly.

<jpk68:matrix.org> Yes, there is not an API, besides using the Python code directly somehow. Too bad, since it seems pretty nice in every other aspect

<jpk68:matrix.org> Nostr is based on WebSockets and could likely work at first glance, but its privacy is far worse than that of Bitmessage

<rbrunner7> There is a very nice app to do Monero multisig interactively. It works well, which I know because I tested it extensively. People have to be online at the same time, but well, can't have all, right? Thing is it gets next to zero attention, and made almost no "splash" when it was released, which IMHO probably means one thing: Interest in doing Monero multisig interactively is very, very small.

<rbrunner7> Here it is: freigeist-m.github.io/monero-multisig-gui

<jpk68:matrix.org> Ah, yes, I saw that when it came out. Too bad it didn't really get the attention it deserved :|

<spirobel:kernal.eu> there is tons of interest: nitter.net/spirobel/status/2056020125145600366#m the old multsig is just outdated.

<spirobel:kernal.eu> everyone will build on the work that serai, frost, evrf dkg did. there is also golden dkg by bünz et al

<spirobel:kernal.eu> if i remember correctly the limitation was that all n participants have to be present with golden. (they mentioned during some talks that this is not the case, but i couldnt verify this with the paper)

<spirobel:kernal.eu> in any case i doubt anyone cares as the serai dkg exists

<spirobel:kernal.eu> (threshold) multisig is definitely something that people want. rbrunner7 i also read your posts on this and how you deemed the whole project too complex and gave up. maybe take a look at the new work that was done. things have changed

<spirobel:kernal.eu> also looked at frostsnap code recently. they generate a device specific seedphrase as a result of the dkg setup. it is very clunky. it shows how much potential there still is. much better to be able to derive the dkg keypair from seed + passphrase.

<dangerousfreedom:matrix.org> Hello everyone,

<dangerousfreedom:matrix.org> I'm almost done with the coding related to this project:

<dangerousfreedom:matrix.org> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/645

<dangerousfreedom:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/1pL3l5MLdVJ3a3Ew ]

spribol: That link is just evidence of your personal demand, not general demand from vendors (who would demand it if there was a competitive advantage/it improved their product). Afaik the main problem is arbitrators can be deemed money transmitters, which makes it doa for many (didn't localmonero encounter this?).

I don't have a source for that money transmitter bit, so correct me if there's a solid conclusion.

<kayabanerve:matrix.org> If Claude was used to translate the functions, isn't this effectively more of a code review by Claude than an independent implementation as to assert the integrity of Monero?

<kayabanerve:matrix.org> Especially as this is a sufficient 'transliteration' I may have basis to DMCA your entire repository for illegally reproducing the FCMP tree :/

<kayabanerve:matrix.org> *I'm not saying I would. I'm saying reading that Python, the first file I opened did seem to be extremely analogous of the Rust as written.

<kayabanerve:matrix.org> I also will ask you include the proper licenses and attribution statements from the monero-oxide repository FCMP++ branch though, so this isn't a possible question moving forward (I am not the sole copyright holder and accordingly cannot unilaterally say this is okay, if this was to be considered derivative).

<kayabanerve:matrix.org> Oh, I'm a dumbass, you did

<kayabanerve:matrix.org> It was in the README, not a LICENSE, nvm, ty for respecting that :D

<kayabanerve:matrix.org> I'd recommend clarifying that some parts were translated from monero-oxide, with the license you've already redistributed, and the project as a whole is GPL 3 with your full license text though (not just the declaration it is, which is ambiguous) in a `LICENSE` file @dangerousfreedom:matrix.org:

<kayabanerve:matrix.org> But I still have my original question about the value of an alternate verifier which is comparable to a line-by-line translation and may have the same systemic faults, and the use of LLMs

<kayabanerve:matrix.org> The original CCS seemingly did not discuss the use of any LLMs and I'm unconvinced this claim has been met yet:

<kayabanerve:matrix.org> > Provide my own implementation for each functional block (GBP, arithmetic circuits, merkle tree proof generation/verification) in Python.

<kayabanerve:matrix.org> Not just because of the LLM use, because what makes "my own implementation"?

<kayabanerve:matrix.org> There presumably should be an independence there which I'm unsure is met by anything which can be considered a translation...

<dangerousfreedom:matrix.org> Yes, I have to clarify with you regarding the licensing. I think I did it right by trying to mention it in every file but it is possible that I made a mistake somewhere.

<dangerousfreedom:matrix.org> Well, it is not finished yet. I hope I can finish it by the end of the month. I got a lot of help of Claude indeed so I get the first version working. I'm still doing my audit and writing what I understand from the proof so I can convince myself and possibly others regarding how that work.

<dangerousfreedom:matrix.org> And even if it was a pure translation, some bugs could be found in your code (or my code) anyway. For example, if I get it verifying correctly for 100 txs and at some point a tx fails (what happened some times for the legacy), then it means that there is a problem somewhere. Spotting them would be useful as well I think.

<plowsof:matrix.org> you have until july 7th to use Fable 5

<spirobel:kernal.eu> UkoeHB ailia wrote an article on this subject: x.com/themerit0crat/status/2056090684734804162 it is mainly a naming issue. Multisig does not make anyone participating in it a money transmitting business as it is non custodial

<spirobel:kernal.eu> There are also products like stripe that enable (clumsily and centralized) the building of p2p "escrowesque" products. stripe.com/connect

<spirobel:kernal.eu> it is obvious that massive businesses like ebay, amazon, alibaba, paypal are built around this

<spirobel:kernal.eu> in the greymarket area, exit scams are the biggest problems

<spirobel:kernal.eu> you also worked on this. dont understand why you wouldnt be bullish on this use case.

<spirobel:kernal.eu> its just a building block. if you market it directly in this half finished state to the end consumer of course there wont be a "splash"

<spirobel:kernal.eu> because the building block by itself doesnt address a need

<spirobel:kernal.eu> its an important part in building two sided marketplaces that require for some trust between parties to work

<spirobel:kernal.eu> next to slow finality and throughput this is the main thing that is holding back adoption. these fundamental three things need to be addressed

<spirobel:kernal.eu> overcome low trust environments, make it fast and make it possible to be used by many people at the same time

<spirobel:kernal.eu> get rid of the need for wallets to sync, so users can effortlessly participate in many escrow sessions.

<spirobel:kernal.eu> (thats why i care about the monero pre shared key addressing scheme concept. it can also solve the harvest now, decrypt later pq topic )

<jpk68:matrix.org> It would be nice if design constraints didn't exist, wouldn't it

<spirobel:kernal.eu> some constraints are real, others are just imagined. that privacy preserving wallet sync has to exist is one of the imagined ones