06:49:08 <kayabaNerve> RFC, for anyone who hates the burning bug and doesn't care to wait years for Seraphis. Implications for higher level protocols incoporating Monero, parties that publish their view keys, and view-only processes (such as non-custodial payment handlers): https://gist.github.com/kayabaNerve/8066c13f1fe1573286ba7a2fd79f6100
06:51:26 <kayabaNerve> I implemented this (or something extremely similar, probably not *exactly* as proposed) into my own work because I needed it, yet another party does as well, and then at MoneroKon integrated addresses were advocated for. While I hate the things, they are susceptible to the EBB if the organization receiving publishes their view key, hence the wider reasons for something like this to be done. While writing it up, I also realized the 
06:51:26 <kayabaNerve> non-custodial payment handler angle and... yeah. Lot of reasons for me to move it from "something I do in my code" to "proper spec with a proper address format that could be displayed in a QR code/copied + pasted"
06:52:15 <kayabaNerve> I also feel it has a reasonable enough implementation discussion to cut through red tape, but obviously, RFC for a reason ;) Would love to get thoughts :D
07:07:23 <rbrunner> I can only watch from the sidelines, as a non-cryptographer, but I am really curious whether you find will enough "haters of the burning bug" to get this off the ground
07:07:33 <rbrunner> I am quite sceptic right now, to be honest
07:08:19 <kayabaNerve> So the cryptography isn't the notable part. It's a mild change to the hash definition :p
07:10:16 <kayabaNerve> It's about 1) The burning bug existing. 2) The burning bug having a user-on-user grief if you publish your view keys, which affects 2+ protocols (neither live). 3) The burning bug preventing secure payment processing by a party with your view keys yet without your key images. Under the standard policy, they'll acknowledge payments which you can never spend, depending on timing.
07:10:26 <kayabaNerve> So this... hasn't been exploited in the real world? Ever AFAIK?
07:10:55 <kayabaNerve> ... I'd have to double check one write up I remember reading but seems people generally didn't care to troll exchanges, not to mention it was patched within Monero quite quickly?
07:11:38 <kayabaNerve> Yet now that we have hit a use case where there actually would've been a 0-cost user-on-user grief, I feel much more strongly about this. I also don't believe the payment processing aspect has been discussed.
07:12:28 <kayabaNerve> So regardless of if the address itself is a good idea, the internals are mandatory for at least a subsection of the Monero userbase. The address is an open offer for more parties to join in, notably in the payment processing field (who would require exposed addresses), which I will say I don't plan to take off.
07:13:13 <kayabaNerve> But a patch to wallet2 is free for wallets to implement and would enable payment processors to consider a higher security option, while also consolidating behind a format for decentralized protocols to adopt. We had 0 last year, and will have 2 this year. Who knows what next will bring? :p
07:15:54 <kayabaNerve> *tbf, I think one of those 2 was supposed to be last year, and should ack they may not be valid for consideration. I'm fine quoting them as a statistic for my benefit here, and it is correct, but it's hard for me to say I support them nor they should be worth considering. Without them, it's just my work, which arguably may make this proposal moot.
07:17:28 <kayabaNerve>  Why it was written in a way we can try it, yet drop it as soon as it proves itself either way ;) I don't have the highest expectations it'll work it, yet between needing the internals and not knowing unless it's tried, combined with the fact this already will be fixed *just one-to-two years from now*... Seemed worth it.
08:09:21 <rbrunner> "while also consolidating behind a format for decentralized protocols to adopt. We had 0 last year, and will have 2 this year" Sounds mysterious 
08:16:48 <kayabanerve[m]> <rbrunner> ""while also consolidating behind..." <- I'm looking at announcing my work properly tomorrow, and I tweeted about the incompetence of Haven's Thorchain integration yesterday :p Regardless, I'll be sending this document to them as it is the only way to handle this properly given their situation.
08:18:30 <rbrunner> A fork with some incompetence? Something like that does exist? I am shocked, I tell you. /s
08:19:05 <rbrunner> But well, they at least try something new and innovative over at Haven, have to give them that.
08:21:34 <kayabanerve[m]> I was mainly frustrated people don't get review for their stuff
08:21:42 <rbrunner> The second one being Secret Network?
08:22:14 <kayabanerve[m]> Ffs if I ever work with secret network, I've been compromised
08:22:40 <rbrunner> :)
08:27:41 <kayabanerve[m]> So XHV didn't handle the burning bug with their code, which is a mistake I've made, yet it highlights why you need review. People experienced with the Monero wallet would quickly catch that and...
08:28:44 <kayabanerve[m]> The next comment is that they didn't realize exposing the view key when they were crediting deposits enabled user on user griefs which is... A really complex set of interactions. I can see why there
08:30:24 <kayabanerve[m]> So those are my complaints with them :p Review by someone competent should've caught at least the first one. I only stepped in because of all the people who are saying Monero being added to a project with a 50% premine and multiple exploits and examples of bad behavior is a good idea, and that's the code it'd be done with :/
13:44:12 <jeffro256[m]> Can you expand on what the uniqueness aspect is exactly for non-miner transactions? Is it some sort of deterministic hash or sum of essential transaction data (you mentioned key images which would make sense because you already need unique key images)
13:44:39 <jeffro256[m]> I really like this idea btw 
14:54:44 <ooo123ooo1234567> <kayabanerve[m]> "I was mainly frustrated people..." <- any reference example of the best review process anywhere on the internet ?
15:04:41 <ooo123ooo1234567> <kayabaNerve> "It's about 1) The burning bug..." <- "The burning bug preventing secure payment processing by a party with your view keys" an incentive against light wallets ?
16:19:27 <hanshan[m]> Q about dev identity verification.
16:19:27 <hanshan[m]> is there a list of PGP keys associated with devs or verification of commits coming from them?
16:19:27 <hanshan[m]> seems like a possible attack vector
16:20:24 <sech1> https://github.com/monero-project/gitian.sigs/tree/master/gitian-pubkeys
16:21:00 <moneromooo> Some people have theur pubkeys in utils/gpg_keys. Commits adding them are signed by the maintainer at the time, whose key is also there.
16:21:24 <moneromooo> I ask on IRC for people to confirm their key fingerprint when a PR to add one shows up.
16:21:38 <moneromooo> I think the maintainer also does. Pony did at least.
16:21:54 <ooo123ooo1234567> PGP key doesn't test quality of code signed with it
16:21:56 <moneromooo> Pony's fingerprint (the root of all this) is published on the talks he made.
16:22:11 <moneromooo> Coders with a key usually sign their commits with that key.
16:22:17 <ooo123ooo1234567> there are more severe attack vectors
16:28:06 <rbrunner> "PGP key doesn't test quality of code signed with it" Yes, but that wasn't the question :)
16:29:11 <hanshan[m]> Thank you. That seems like a good way.
16:29:11 <hanshan[m]> What can be done anyway.
16:29:19 <rbrunner> Signing also does not diminish the quality.
16:29:53 <ooo123ooo1234567> "seems like a possible attack vector" no, it's about relying on code signed with some keys