00:00:12 cc [@woodser:monero.social](https://matrix.to/#/@woodser:monero.social) 00:02:27 it's not time based, but it can become stale with reorgs 00:03:07 at least to my knowledge 00:03:21 are you sure? the docs say it's time based https://docs.getmonero.org/multisignature/#spending, and additionally, i tested on a local chain with no new blocks being produced, and it still gave this error after a few minutes of sitting there. 00:03:22 ``` 00:03:24 Note: Once you synchronize the partial key images, there is a certain time window by which you can create and send your transaction. I'm unsure exactly how long the time window is. If you leave it too long you will see the output: 00:03:26 Error: Multisig error: This signature was made with stale data 00:03:28 ``` 00:04:33 ah ok, don't know how much time before it becomes stale 00:05:19 we build into our protocol exporting and importing again if it becomes stale for any reason 00:08:13 the docs arent always gospel 00:08:37 yeah, but i did test locally and it expired despite nothing happening 00:08:38 Stale data sounds to be like old data, not expired data 00:08:52 To me* 00:15:59 it'll also become stale if you create a new tx 00:18:17 the only thing that changed when it expired locally was the time, i never created any new tx, never exported or ran any other command, never made new blocks 00:18:25 i'm pretty sure the docs are correct based on that 02:22:57 it looks like only the sender of a multisig tx can know the destination? one of the wallets that wasn't the last signer just shows this 02:22:58 213 out - 2026-01-24 01:55:55Z 0.017000000000 96fcfd36cb6bd1e10e9d6eae89b38547e2a45bdb86f0a1da27c59dd340201bf8 0000000000000000 0.002599200000 - 0 - 02:23:00 the one that is shows this 02:23:02 213 out - 2026-01-24 01:55:55Z 0.017000000000 96fcfd36cb6bd1e10e9d6eae89b38547e2a45bdb86f0a1da27c59dd340201bf8 0000000000000000 0.002599200000 49(restofaddresshere):0.017000000000 0 - 02:23:04 is there a way to get it to know? i did use export_multisig_info but the other wallets still didn't show the address 02:23:09 is this the problem the new upgrade's view keys will solve? 02:23:11 🤔 02:27:30 No 02:27:46 Recipient address isnt saved on chain 02:29:41 Lets say you have a non-multisig wallet running on 2 different devices. Only the device that sent the tx knows the address that it was sent to 02:57:22 and it's impossible to prove it to the other instance? 02:57:29 so that won't change with the new upgrade? 02:58:26 wait, you could just send a spend proof to prove it to the other instances, no? 02:59:28 Right 10:31:11 kiersten: you can use 'describe_transfer' for other wallets to verify unsigned tx's address and amounts. for example: https://github.com/haveno-dex/haveno/blob/f9ea863162ba7cc6827d3fc85449b5cb1dd7ccc4/core/src/main/java/haveno/core/trade/Trade.java#L1596 10:40:37 does kiersten have to read this reg proofs? https://github.com/monero-project/monero/issues/8819#issue-1656289739 15:51:14 but how do you relate the unsigned version to the version that you receive? if i sign a tx, send it to the next guy, and he is the one who signs + broadcasts, then how do i know the tx in my mempool that is outbound from me is the one i checked when it was unsigned? 15:54:10 in the code you sent, that's the one that broadcasts it 15:58:06 is this for multisig or regular tx 15:58:46 multisig 15:59:28 if the guy changes it 15:59:33 doesn't it invalidate the signature you signed on it? 16:03:21 kiersten: when the tx is signed, the tx id becomes available, so you have a handle to the specific signed tx 16:04:23 only the last signer knows this though, describe_transfer on an intermediate one doesn't show it 16:04:40 yeah, couldn't say on intermediate signers 16:13:55 oh, multsig uses a secret sharing 21:41:43 Apologies if this is a dumb question. I was wondering if anything else would be needed to fix #10274 besides this: 21:41:51 https://paste.debian.net/plainh/65b9e09f 21:42:01 Just wanted to check before making a PR or something 21:44:06 diff is for /src/rpc/zmq_server.cpp 21:54:52 That should be it, but have you tested it? 21:58:59 Yes, and it seemed to be working fine. 22:03:21 The daemon started up without any errors, and P2Pool also recognized it. I'll try again with the chain synced before submitting.