01:52:47 <UkoeHB> 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 
01:52:47 <UkoeHB> 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.
03:11:12 <br-m> <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 https://mrelay.p2pool.observer/e/yMTspJMLQ0hhN2da ]
03:11:50 <br-m> <spirobel:kernal.eu> i think 3-5 is a good choice so that the merchant can keep one key offline 
03:16:35 <br-m> <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 (https://x.com/ace_malad/status/2040121716991811739). They need no arbitrator.
03:16:35 <br-m> <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 https://mrelay.p2pool.observer/e/hZmApZMLaVhwLVZP ]
03:16:35 <br-m> <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 https://matrix.to/#/!PAAeACCTzofUENRcqJ:monero.social/$wiZBhnDzQAspeMqH0N19gy0VlbjucO2-46qb3a19F8Q?via=monero.social&via=matrix.org&via=unredacted.org. Not surprisingly, it never gained mu [... too long, see https://mrelay.p2pool.observer/e/hZmApZMLaVhwLVZP ]
03:27:42 <br-m> <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. :)
03:32:14 <UkoeHB> @aillia I made a presentation about improved multisig UX, but was burnt out at this point and never implemented my poc https://www.youtube.com/watch?v=S478LukKlEs
03:32:53 <br-m> <spirobel:kernal.eu> UkoeHB: i also watched this one 
03:34:01 <UkoeHB> 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.
03:35:15 <br-m> <spirobel:kernal.eu> UkoeHB: serais work is audited and the implementation is finished and works
03:35:59 <br-m> <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 
03:38:16 <UkoeHB> 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.
03:38:54 <br-m> <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 :)
03:38:59 <br-m> <spirobel:kernal.eu> https://monerochan.news/article/19 there is an escrow flow here based on the serai stuff 
03:38:59 <UkoeHB> Anyway it's interesting to hear aillia's perspective, thanks for sharing
03:39:36 <br-m> <spirobel:kernal.eu> UkoeHB: have you seen the latest work by bünz? what do you think about flock? 
03:40:16 <UkoeHB> I have not been keeping up to date on multisig developments
03:41:06 <br-m> <spirobel:kernal.eu> i mean they did some work on frost i think and mainly the golden dkg  but flock is something different
03:41:12 <br-m> <spirobel:kernal.eu> it is related to the pq stuff
03:41:59 <br-m> <spirobel:kernal.eu> the trend is towards making all the proofs work with hash based signature schemes ... not just the addressing scheme 
03:42:18 <UkoeHB> Oh SNARKs. I never got into the more advanced cryptography, I'm more protocol-layer-focused.
03:42:36 <br-m> <spirobel:kernal.eu> but i mean this is where the trend is going
03:43:34 <br-m> <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
03:45:10 <UkoeHB> You are suggesting a ground-up redesign based on 'hash-based signature schemes'?
03:45:46 <br-m> <spirobel:kernal.eu> yes they already got this working ... recommend giving the latest zknowledge podcast a listen 
03:46:11 <UkoeHB> If that is possible I'd be interested in an outline how it could be translated to Monero's design constraints
03:46:30 <br-m> <spirobel:kernal.eu> i would also look into protostar and now bpstar
03:46:48 <br-m> <spirobel:kernal.eu> it is a big deal proably the more practical thing 
03:48:20 <br-m> <spirobel:kernal.eu> these folding / accumulation schemes are great. somebody should do set membership proof with it
03:49:04 <br-m> <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 
03:50:21 <br-m> <spirobel:kernal.eu> ethereum is doing this too https://ethresear.ch/t/block-update-digests-membership-proofs-without-a-global-state-tree/24509
03:51:28 <br-m> <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 ... 
04:11:23 <UkoeHB> 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.
04:11:25 <UkoeHB> of
04:14:01 <br-m> <spirobel:kernal.eu> key images get published with each tx in any case though 
04:14:28 <br-m> <spirobel:kernal.eu> so why not provide a set membership exlusion proof with it
04:15:05 <br-m> <spirobel:kernal.eu> look into these folding / accumulator schemes like bpstar (based on protostar)
04:15:27 <br-m> <spirobel:kernal.eu> maybe there is not even a need for a merkle tree ... maybe the set can be folded up ....
04:16:50 <br-m> <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)  
04:23:24 <UkoeHB> Link to paper for bpstar?
04:24:10 <br-m> <spirobel:kernal.eu> UkoeHB: https://eprint.iacr.org/2026/586
04:25:13 <br-m> <spirobel:kernal.eu> the other topic is using this to fold up the old proofs, so that nodes can quickly trustlessly catch up