<k​iersten5821:matrix.org> so i will need a new seed phrase in the cli wallet?

<j​effro256:monero.social> This is a better topic for Monero

<r​brunner7:monero.social> Monerujo Polyseed support was done a year ago already, according to bounty info here: bounties.monero.social/posts/116/2-…polyseed-support-for-monerujo-0-25m

<r​brunner7:monero.social> But the latest version that I installed today does not seem to offer Polyseed?

<o​frnxmr:xmr.mx> correct

<r​brunner7:monero.social> :(

<o​frnxmr:xmr.mx> This was before the new rule

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> 2025/03/30 - Bounties for established projects

<o​frnxmr:xmr.mx> Require pre-approval.

<o​frnxmr:xmr.mx> The author/bounty hunter MUST reach out to the project before starting work on it so they have a chance to concept ACK.

<o​frnxmr:xmr.mx> Evidence of such MUST be provided (public ACK of the bounty from the project)

<o​frnxmr:xmr.mx> Example: FeatherWallet bounties would require pre-approval from tobtoht

<o​frnxmr:xmr.mx> ```

<r​brunner7:monero.social> Not sure what you mean. It does not work?

<o​frnxmr:xmr.mx> I mean that, previously you could make bounties for projects that dont feel like merging your work

<o​frnxmr:xmr.mx> New rules is that you have to confirm uptream that they are onboard with your idea

<r​brunner7:monero.social> Ah, and that may be the case now with Monerujo you mean? The latest version is from Summer 2025 and could therefore include this - if it wanted ...

<o​frnxmr:xmr.mx> yea

<r​brunner7:monero.social> Ok, anyway, if support is not yet "official" in Monerujo we have 1 wallet less that could do something differently because of different interpretations of the spec, so maybe that's net positive :)

<o​frnxmr:xmr.mx> j0j0 did it so its probably similar/same as anonero

<o​frnxmr:xmr.mx> anonero, feather, monfluo, cake, stack support polyseed

<r​brunner7:monero.social> By the way, I just confirmed that also Polyseeds with offsets (or however you want to call that) are interoperable between Cake and Feather. At least as of today. Which is very good.

<o​frnxmr:xmr.mx> did you create in cake and then restore in feather?

<o​frnxmr:xmr.mx> iirc there was a report from user that it wouldnt work. Will have to see if i can search it up

<r​brunner7:monero.social> So far only the other way round. To be complete, I can try to create in Cake and then restore in Feather. However, that would be very surprising if only one way round worked, no?

<o​frnxmr:xmr.mx> Agreed lol

<r​brunner7:monero.social> Will later look at the source to see first hand what the apps really do.

<r​brunner7:monero.social> At least in theory, you could treat Polyseeds differently according to the encoded restore height, and Cake may have improved something, starting at some height

<r​brunner7:monero.social> So it's possible it once wasn't interoperable

<r​brunner7:monero.social> Hmm, that's surprising. Feather refuses the Cake seed with a message that "encrypted seeds are not supported".

probably their catch-all message for seeds they can't parse

<r​brunner7:monero.social> Don't think so, but a look into the source later will certainly tell me what's up.

<o​frnxmr:xmr.mx> So i wasnt crazy

<r​brunner7:monero.social> Not this particular way, no :)

<o​frnxmr:monero.social> I looked for the initial report but couldnt find it, and started to think i dreamed it up

<k​iersten5821:matrix.org> under what circumstances does this occur? `Failed to sign withdrawal tx: sign_multisig failed: Failed to sign multisig tx: This signature was made with stale data: export fresh multisig data, which other participants must then use (code: -35)` i thought it was just time, but i noticed my code which is rapidly exporting to each other got this error when trying to do a signature, do<clipped message>

<k​iersten5821:matrix.org> es each import of the multisig data invalidate the previous data and sig/tx somehow?

<k​iersten5821:matrix.org> github.com/monero-project/monero/bl…rc/wallet/wallet2.cpp#L14551-L14552

<k​iersten5821:matrix.org> ```

<k​iersten5821:matrix.org> // - Calling this function will reset any nonces recorded by the previous call to this function. Doing so will

<k​iersten5821:matrix.org> // invalidate any in-progress signing attempts that rely on the previous output of this function.

<k​iersten5821:matrix.org> ```

<k​iersten5821:matrix.org> i guess that answers it

<k​iersten5821:matrix.org> hmm still can't figure out how much time it takes to expire

<k​iersten5821:matrix.org> hmm still can't figure out how much time it takes to expire (didn't look too closely though)

<o​frnxmr:xmr.mx> I dont think its time based