I agree multisig arbitrators are non-custodial, and it may in the long run acquire judicial precedent to give businesses confidence. But in the mean time businesses *don't* have confidence and hence *don't* have demand. I was and am bullish on 2-of-3 as a pretty good solution to a hard problem, but ultimately the work to implement/support multisig is meaningless to me if there is no adoption. Evangelizing it is worthwhile and I

wish you luck, just be precise about what is or isn't true/possible/likely. In this case, businesses *might* develop demand if they have legal confidence, which would require trailblazers to meet and overcome lawfare challenges.

<spirobel:kernal.eu> i read this paragraph a few times and i am still unsure what you are trying to say. you wouldnt have started working on multisig if you didnt believe in it. just dont overthink it. code is law. who cares what boomers think. most of the world has never heard of this and does not care about pedantic interpretations of laws that [... too long, see mrelay.p2pool.observer/e/yMTspJMLQ0hhN2da ]

<spirobel:kernal.eu> i think 3-5 is a good choice so that the merchant can keep one key offline

<aillia:matrix.org> Established businesses probably don't need multisig at all: for example, wardsace.com was able to start accepting Monero simply by setting up BTCPay Server (x.com/ace_malad/status/2040121716991811739). They need no arbitrator.

<aillia:matrix.org> imo multisig's main use case is P2P deals between individuals, and I'm convinced there's demand for it. A lot more people would have used bazaar's multisig if it didn't require everyone to log in and sync 5+ times, often with delays and across different time zones. Some users can do the multiple syncs, but most just want a o [... too long, see mrelay.p2pool.observer/e/hZmApZMLaVhwLVZP ]

<aillia:matrix.org> ...therefore, as someone who's probably one of the more active multisig users, it's surprising I never heard about that Monero Multisig GUI matrix.to/#/!PAAeACCTzofUENRcqJ:mon…l&via=matrix.org&via=unredacted.org. Not surprisingly, it never gained mu [... too long, see mrelay.p2pool.observer/e/hZmApZMLaVhwLVZP ]

<spirobel:kernal.eu> we need more aillias in the monero matrix channels. constructive comments grounded on real world experience. think that was the first time in weeks i read one here. :)

@aillia I made a presentation about improved multisig UX, but was burnt out at this point and never implemented my poc youtube.com/watch?v=S478LukKlEs

<spirobel:kernal.eu> UkoeHB: i also watched this one

Overall, doing multisig right is a lot of work and very hard and maintaining it is a non-trivial burden on core (especially if it is reworked/expanded). It should be implemented and maintained third-party IMO.

<spirobel:kernal.eu> UkoeHB: serais work is audited and the implementation is finished and works

<spirobel:kernal.eu> mayber you can just build your poc with it / do another review of it or something instead of building your poc on the old code

I don't have any plans to work more on multisig beyond core maintenance. Jamtis-PQ will have broader utility and will be higher priority for the next couple years I expect.

<aillia:matrix.org> UkoeHB: Oh, nice clickable title :)) Thank you koe! I was going to say how tf I missed this, but then saw the date: it was before my time in the community. Appreciate the link :)

<spirobel:kernal.eu> monerochan.news/article/19 there is an escrow flow here based on the serai stuff

Anyway it's interesting to hear aillia's perspective, thanks for sharing

<spirobel:kernal.eu> UkoeHB: have you seen the latest work by bünz? what do you think about flock?

I have not been keeping up to date on multisig developments

<spirobel:kernal.eu> i mean they did some work on frost i think and mainly the golden dkg but flock is something different

<spirobel:kernal.eu> it is related to the pq stuff

<spirobel:kernal.eu> the trend is towards making all the proofs work with hash based signature schemes ... not just the addressing scheme

Oh SNARKs. I never got into the more advanced cryptography, I'm more protocol-layer-focused.

<spirobel:kernal.eu> but i mean this is where the trend is going

<spirobel:kernal.eu> that will be the competition. or the whole topic will get less attention, the can will be kicked down the road and nothing will get deployed in the end

You are suggesting a ground-up redesign based on 'hash-based signature schemes'?

<spirobel:kernal.eu> yes they already got this working ... recommend giving the latest zknowledge podcast a listen

If that is possible I'd be interested in an outline how it could be translated to Monero's design constraints

<spirobel:kernal.eu> i would also look into protostar and now bpstar

<spirobel:kernal.eu> it is a big deal proably the more practical thing

<spirobel:kernal.eu> these folding / accumulation schemes are great. somebody should do set membership proof with it

<spirobel:kernal.eu> also the other way round. do an exclusion proof so the nodes dont need to keep the key images all in memory / on disk to verify transactions

<spirobel:kernal.eu> ethereum is doing this too ethresear.ch/t/block-update-digests…s-without-a-global-state-tree/24509

<spirobel:kernal.eu> which directly contradicts the claim of zcashers that state growth is such an issue .... if there is the possibility to verify transactions without having to have the key images / nullifiers ...

BUDs appears to be building smaller Merkle trees that only encompass the last-modification block of an account up to present. Not exactly usable in a privacy setting where you don't want last-modification exposed and where there are no account-based solutions that I know if.

of

<spirobel:kernal.eu> key images get published with each tx in any case though

<spirobel:kernal.eu> so why not provide a set membership exlusion proof with it

<spirobel:kernal.eu> look into these folding / accumulator schemes like bpstar (based on protostar)

<spirobel:kernal.eu> maybe there is not even a need for a merkle tree ... maybe the set can be folded up ....

<spirobel:kernal.eu> in any case this shouldnt be privacy sensitive ... the key image is public ... its just about relieving the node of the responsibility of having to have all the state to verify transaction validity (no double spend, double key images)

Link to paper for bpstar?

<spirobel:kernal.eu> UkoeHB: eprint.iacr.org/2026/586

<spirobel:kernal.eu> the other topic is using this to fold up the old proofs, so that nodes can quickly trustlessly catch up