03:01:30 <gingeropolous> wait wut? https://twitter.com/HerdAlert/status/1394482638094807040
10:02:03 <hyc> what wut? someone put an invalid unlock time in atxn?
10:08:28 <moneromooo> Are there invalid unlock times ?
10:09:06 <hyc> if it's smaller than a unix timestamp it's treated as a block height. so a new txn with a block height in the past seems kinda pointless
10:09:32 <hyc> and likewise if it is a timestamp, a timestamp in the past is still pointless
10:09:48 <hyc> ?
10:10:20 <moneromooo> Pointless, sure.
10:11:09 <hyc> but is it always an absolute block height? or relative? if unlock_time=5 what is it interpreted as?
10:11:13 <Inge-> 98% of all specified unlock_time transactions set a low-integer value? "These low-integer unlock_time values do not make semantic sense, so the developer’s intent is unclear. Perhaps they thought block times were relative rather than absolute, or the field is used for something else unrelated to unlock_time." https://thecharlatan.ch/Monero-Unlock-Time-Privacy/
10:11:55 <moneromooo> AFAIK that means block 5.
10:12:08 <hyc> so it is always an absolute block height
10:12:28 <moneromooo> No, it can be a UNIX time too as you said above.
10:12:43 <hyc> ok. *when* it is a block height, it is absolute
10:12:50 <moneromooo> Yes.
10:13:38 <moneromooo> Preventing mining txes with unlock time in the past could give txes a validity range. But that might make scamming easier.
10:13:53 <moneromooo> ie, give your tx 10 blocks to go but use a tiny fee...
11:42:45 <masken8> I have a question. Suppose I withdraw my Monero from exchange A and I send it to someone, eventually it ends up on exchange B. Assuming the Feds have access to both exchanges wallets what stops them from traversing the ring members transactions until they find the real path by finding a common transaction?
11:43:12 <binaryFate> That's called the EABE attack https://github.com/monero-project/monero/issues/1673#issuecomment-312968452
11:45:36 <binaryFate> If either A or B is concerned about that risk they should churn
11:45:42 <masken8> I see
11:47:19 <Inge-> and by churn, you probably mean sweep_single n times at some random intervals?
11:48:29 <binaryFate> yes
11:49:30 <binaryFate> more on churning https://monero.stackexchange.com/search?q=churn
11:51:43 <masken8> I'll check it out
11:57:01 <masken8> Is there a reason a high privacy transaction option has not been added to the GUI wallet?
12:00:43 <binaryFate> asga32ag: not that I know
12:01:07 <binaryFate> masken8: what do you mean by "high privacy transaction"?
12:01:18 <gingeropolous> prolly churning
12:01:41 <masken8> "The ability of Alice to increase her anonymity set when sending funds to Bob can be implemented as a "high privacy" transaction option that automatically takes care of queuing up the intermediate churn transactions prior to funds ultimately being sent to Bob."
12:02:57 <binaryFate> no reason besides that nobody implemented it I guess
12:06:24 <masken8> I would implement it but I'm not very good at C++. I'll make a feature request.
15:00:31 <NickvanSaberhagn> It’s an interesting idea, really. A SEND button in the GUI that churns and then sends newly churned funds in a way that places the tx right in the middle
15:00:39 <NickvanSaberhagn> Of the ring selection
15:01:41 <moneromooo> lol
15:03:06 <hyc> not very useful unless it inserts random delays between steps
15:03:18 <hyc> usually when someone hits SEND they want it to happen NOW
15:04:02 <moneromooo> I have a super old patch that sends txes on a timer, using poisson delays.
15:04:20 <moneromooo> That was for transfer, back when txes were often split, but the principle's the same.
15:05:28 <hyc> and you really can't just randomize the transmit time. you need to randomize across multiple blocks
15:06:29 <moneromooo> What do you mean by across multiple blocks ?
15:07:18 <hyc> eh I guess that was implicit. you can't churn the output until it has been mined into a new block anyway
15:07:40 <hyc> never mind
15:07:44 <moneromooo> Oh OK.
15:08:00 <hyc> so you can't just set a timer for "resend this after N minutes"
15:08:04 <hyc> you have to count blocks
15:08:41 <hyc> "resend this after (10 block minimum + random#)
15:08:43 <hyc> "
15:25:15 <binaryFate> I think ideally it should draw the number of blocks using the same sampling as the ring sampling distribution. Since in both cases you want the same thing: stick to what is supposedly the true spend distribution and make your random drawings indinstuishable from it
15:26:30 <binaryFate> Except you don't want to wait weeks to churn so you need to upper bound it somehow
15:27:01 <hyc> prob something on the order of 12-24 hours
15:28:08 <binaryFate> A simple thing like draw with gamma distribution + resample if outcome >24h, should be pretty solid already
16:01:40 <asga32ag> is there anything visible on the blockchain/network monitors that could explain the problems multiple exchanges have? transaction numbers don't look like anything out of the ordinary
16:02:16 <asga32ag> also kraken now has pretty much the same message for nano.....it's weird
16:07:52 <selsta> asga32ag: there is no network issue
16:07:59 <selsta> also kraken resolved their issue https://status.kraken.com/
16:09:15 <asga32ag> in the long list of walllets monero is still marked with "degraded performance" just like nano though
16:10:20 <selsta> whatever their issue is is probably not on network side, also no one reached out
16:10:47 <selsta> fwiw multiple people reported successful withdrawals on kraken even with the message displayed
22:18:10 <john_r365> names
22:18:34 <john_r365> */ names -> sorry, ignore me