06:46:55 Is there any kind of relay mechanism for blackball outputs? I think it could be a good idea if nodes could share blackball outputs as long as a transaction proof is provided 06:47:37 This could allow miners and exchanges to help curate the list of possible decoys 06:48:07 No. 06:58:20 Do you think that it could be beneficial to privacy? Also, blackball outputs was a real smart idea btw 06:59:17 Probably. At first approximation, yes. At second, I'm less sure, but still probably. 06:59:58 It probably has very little effect for ringct outputs, but high effect for pre-ringct outputs. 07:02:09 If by "relay mechanism" you mean automated p2p updates, it opens the door to potential fingerprinting. But then I don't think monerod is very resilient to this in the first place anyway. 07:03:07 I have no idea how "a transaction proof" would go and be verified. I suspect you'd need to redo a lot of the original work (though you can possibly prune a fair bit of dead ends maybe). 07:04:19 Easy for some cases at least, by supplying a set of outputs. But for known spent outs derived from chain reactions, it might be a bit more complicated. 07:04:47 Having a partial set is still better than no set though, modulo the fp. 07:05:14 Whether it is worth the work though, dunno. 07:06:03 I expect the majoity of people have never owned a pre-rct output, they'd have no use for this in practice. 07:06:16 s/people/monero users/ 07:08:41 Yeah that's what I meant by relay mechanism; like some new p2p notification command which automatically adds the output to the database. I was thinking that it could really improve privacy if implemented by those who conduct a lot of transactions + those who have to report transactions to IRS, etc. It would level the playing field and let people not use outputs who are known to be spent by some gov agency or chainanaysis company. 07:08:41 Could you explain the fingerprinting comment? It shouldn't really affect the distribution of output selection as long as every node follows the same relay rules. Also when I said "transaction proof", I meant a spend proof. Other nodes can verify spend proofs without private keys right? 07:09:43 Fair point about forced privacy self violation. 07:10:33 By fp I mean that if a daemon has a particular set of blackballed outs, and is squawking on clearnet and tor, you can tell they're (probably) the same. That kind of thing. 07:11:10 It'll be less of an issue if those are largely static. Which they'd be if it's just pre-rct outs I guess, but not otherwise. 07:11:43 Also, if you want to include outputs for "those who have to report transactions to IRS, etc", you then cannot have a proof. 07:11:54 It would allow exchanges (e.g.) to still be compliant but help everyone else out with their choice of decoys 07:12:08 So this opens the door to liars. Of whom we have at least one around. 07:13:50 Is there not a way to voluntarily expose the true spender of a ring w/o revealing private keys? 07:14:38 There is. Not sure we want to encourage doing this in public though :D 07:18:22 That's fair, it may be a cat that should stay in the bag 11:48:53 "also make sure you actually..." <- How does one do this, guys? Does anyone know? Is it some kind-of library? 15:01:20 What's the result when you execute the command `pkg_info -c readline`? 15:16:07 oh 15:16:23 Comment: 15:16:23 library to edit command lines as they are typed in 15:17:14 Is that the full message? 15:17:51 There's also the link for the package, but yes 15:17:59 pub/OpenBSD//7.0/packages/amd64/readline-7.0p0.tgz 17:52:32 .merges 17:52:32 -xmr-pr- 8207 8211 8232 8239 8240 8241 17:57:24 moneromooo: now that BP+ is merged, could you rebase 7819? 18:13:49 ok 21:04:25 selsta: done 22:22:41 in functional tests, where is it deciding what fork to use? 22:27:35 Latest defined IIRC. 22:28:10 (in the mainnet table)