15:53:20 <knaccc> UkoeHB whoa, your Mechanics-of-MobileCoin paper is incredible. how did you find time for that?!
15:56:00 <moneromooo> If you've looked at it in detail, then you probably can answer that question: what, if anything, can intel do if there were malicious and/or compromised ?
15:56:56 <knaccc> i only just found a link to the paper a couple of hours ago, and scan read some of it. I am by no means endorsing MobileCoin :)
15:57:08 <knaccc> it is a very interesting approach though
15:57:22 <knaccc> and exactly as you say, relies on Intel not being malcious/incompetent
15:57:47 <moneromooo> It looks like you thought I was asking you. I was asking UkoeHB.
15:57:57 <knaccc> ah ok
16:00:41 <knaccc> there is an interesting philosophical question that I think their approach raises. Which is: even if SGX presents a serious risk, does that mean it should not be used as part of a defense-in-depth strategy?
16:01:59 <knaccc> the idea of asking a remote node to scan for outputs with a private view key that only their private enclave can have visiblity of is fascinating
16:06:39 <knaccc> selsta interesting, yes i'd imagine they'd allow for a higher-security option for people that wanted to store more than just toy-money
16:12:41 <knaccc> selsta based on my extremely limited understanding of how SGX works, I think it is possible to get an intel-authenticated attestation from a remote cpu that a certain public key can be used to encrypt code and data that only that secure enclave can see/process, and then for a wallet to then send the private view key in a secure way to that remote secure enclave for some compute-intensive EC
16:12:42 <knaccc> scanning work to be done
16:14:23 <knaccc> but of course, there could be implementation flaws, intentional backdoors, or a man-in-the-middle attack where intel's leaked keys are used to attest that an insecure enclave is really a secure enclave
16:15:23 <knaccc> i'm not entirely clear about how the intel authentication part works
17:01:49 <UkoeHB> they contracted me since september, hired me a couple weeks ago
17:05:35 <luigi1111w> <selsta> Or does this have to be done on a protocol level? <= if protocol level = blockchain level, then almost certainly not.
17:06:30 <luigi1111w> yes
17:12:05 <moneromooo> Am I missing several lines from selsta here... two replies but nohting from selsta...
17:12:47 <UkoeHB> re: Intel malicious/compromised
17:12:47 <UkoeHB> 1. they can read MobileCoin's transaction graph (i.e. see all ring members)
17:12:47 <UkoeHB> 2. they can censor new enclaves issued by MobileCoin Foundation/related to MobileCoin (would compromise the integrity of their SGX product line - ruin their reputation)
17:12:47 <UkoeHB> 3. in an extreme case, they could build a 0-day into the SGX software to replace enclave contents with their own code (very hard in many ways, but possible)
17:12:47 <UkoeHB> 4. Fog lets users find their owned outputs (like MyMonero, except instead of private-view-key-custody they read encrypted tags containing users' public view keys, then sort and store). Enclaves are used so the Fog operator can't see the view public keys. If enclaves broken, then output:user groupings would be known.
17:12:56 <UkoeHB> yeah I don't see selsta commenting either
17:13:08 <luigi1111w> grr
17:13:48 <moneromooo> Fog ?
17:14:13 <UkoeHB> it's this service thing that lets mobile be more efficient
17:14:40 <moneromooo> So, intel can pierce ring signatures, and syncers can't verify those rings signatures. Is that correct ?
17:14:54 <selsta> Basically MyMonero with view keys stored in a secure enclave
17:15:04 <UkoeHB> ring signatures are still real - you just can see them if enclaves broken
17:15:23 <UkoeHB> it's a step above MyMonero because operator doesn't see amounts
17:15:39 <selsta> why?
17:15:46 <moneromooo> Real, but they're dumped after going through SGX, no ? So syncers don't see them ?
17:15:58 <UkoeHB> syncers don't see them correct
17:16:38 <UkoeHB> selsta: outputs have enc(pub view key) attached, Fog then groups outputs:pub_view_key, and user collects them
17:16:40 <moneromooo> So it doesn't look like an improvement.
17:16:54 <sethsimmons> Fog on top of Monero would be nice
17:16:58 <moneromooo> Except in "lightweightness".
17:17:00 <sethsimmons> For a more trustless LWS
17:17:31 <UkoeHB> it's a probabilistic improvement: what's the probability that an enclave is breached 'right now' and contents being read
17:18:37 <moneromooo> It cannot be improvement since if that probbility is 0%, you get "intel cannot spy", which is what monero has. And that does not remove "syncers cannot check".
17:19:27 <luigi1111w> the spy thing isn't right
17:19:37 <luigi1111w> intel can't see more than every monero node can now
17:19:47 <UkoeHB> yeah ^
17:19:54 <luigi1111w> syncers cannot check is potentially valid though
17:20:15 <moneromooo> So reading the tx graph (point 1) is wrong ? Or did I misinterpret it ?
17:20:17 <luigi1111w> I think basically point 3 above
17:20:18 <UkoeHB> yeah I have a whole section on the 'validation framework, and beyond' in my last chapter - not release...
17:20:34 <luigi1111w> moneromooo tx graph = what is public in monero right now
17:20:41 <UkoeHB> in my view the tx graph includes all decoys
17:20:44 <moneromooo> OK
17:22:17 <moneromooo> So it boils down to preventing syncers from verifying, and instead having a proof it was checked by intel.
17:22:40 <moneromooo> I guess it does become more and more interesting for large ring sizes.
17:22:52 <moneromooo> Assumign this proof doesn't also grow superlinearly.
17:23:35 <moneromooo> Why don't they keep the signatures, and let syncers choose whether they want to download/verify or not ?
17:23:44 <UkoeHB> the proof is on a pub key owned by the enclave - the enclave signs validated block contents with that key
17:23:47 <moneromooo> (which is what we do)
17:24:53 <moneromooo> OK, if it's whole blocks, then it seems it must scale well.
17:24:59 <UkoeHB> I don't think signature contents can be preserved without losing forward secrecy
17:25:14 <UkoeHB> block contents*
17:36:12 <gingeropolous> so who can run a validator node?
17:44:13 <sethsimmons> Anyone with an SGX-capable CPU, in theory
17:44:36 <sethsimmons> Not sure how you actually join consensus, though, and there is no monetary reward for validation.
17:45:05 <sethsimmons> There are no docs for doing so ATM
17:45:31 <sethsimmons> Just a support email to reach out to if you want to become a validator.
17:48:19 <gingeropolous> oh gawd
17:49:03 <sethsimmons> Only altruistic validators will join as their is no game-theoretic incentive to draw decentralization of validators.
17:49:23 <knaccc> UkoeHB the SGX has an asymmetric keypair that is supposed to be unique to that particular CPU, right? so does Intel just provide an Intel-signed signature once as part of the chip manufacturing process, which then later you can use to check that the per-CPU secure enclave public key you're looking at is really from a "secure" intel chip? So there is a well-known intel public key published
17:49:25 <knaccc> somewhere that we need to rely on not being compromized?
17:49:28 <sethsimmons> Unless the foundation chooses to subsidize them directly or they collect fees (that isn't clear how fees are collected/used)
17:50:31 <sethsimmons> Fees are currently quite high ($0.65 flat fee per TX, 0.01MOB), so fees could be substantial if they are split between validators somehow and not just burned.
17:51:44 <gingeropolous> so you can sybil the validator network and print money?
17:52:03 <sethsimmons> Idk, it isn't clear.
17:52:20 <sethsimmons> I would doubt it, there is no mention of fees being collected by validators that I could find.
17:52:29 <gingeropolous> heh, how's that sgx thing work with VMs?
17:53:16 <gingeropolous> well no, if no one else except validators actually check the integrity of transactions .. i guess i just really don't understand the stellar consensus protocol
17:53:27 <luigi1111w> it works, but attestation can be wonky
17:55:13 <knaccc> if the per-CPU keypair is created using the same manufacturing technique that yubikeys use, then the pain threat is intel misusing/having a compromised signing key
17:55:22 <knaccc> main* threat
17:55:53 <knaccc> or maybe they just have a back-door that allows them to exfiltrate it
17:56:40 <selsta> My largest obvious issue with mobilecoin are insta mined supply and the distribution. That has been quite intransparent (almost shady), but that is off topic for this channel.
17:57:37 <luigi1111w> agreed
17:59:33 <sethsimmons> <selsta "My largest obvious issue with mo"> Yeah, technically it makes some tradeoffs that could be OK for the specific use-case (even if I dislike the trust model).
18:00:16 <sethsimmons> That's not the biggest issue at this point, but am definitely curious if any of their work could be helpful to Monero now or in the future, especially as a base/starting point for a Rust implementation.
18:22:53 <UkoeHB> knaccc: there is a bit more to it than that
18:23:35 <UkoeHB> because they want to blacklist compromised devices
18:24:12 <knaccc> UkoeHB oh so you're supposed to connect to an intel site somewhere to find revocations? and how have devices become compromised?!
18:26:21 <UkoeHB> idk if there exist compromised devices, but they want to blacklist them if they are discovered
18:27:00 <UkoeHB> basically Intel will stop attesting to data provided by enclaves on compromised devices
18:27:14 <UkoeHB> each new piece of data must get its own Intel signature
18:27:35 <moneromooo> Is there a difference between "miner" and "validator" ?
18:27:46 <UkoeHB> there are no miners - it was a premine
18:27:54 <moneromooo> *all* premined ?
18:28:10 <sethsimmons> 100% baby
18:28:11 <moneromooo> That can't be right...
18:28:16 <sethsimmons> It is
18:28:19 <UkoeHB> yes, stellar consensus protocol + mining = no one has done it afaik
18:28:20 <moneromooo> Even bytecoin was 80%...
18:28:31 <knaccc> UkoeHB whoaaaa, so you need to constantly talk to an intel server somewhere to get attestations every time you want to execute a different kind of code in the secure enclave of a particular cpu?!
18:28:36 <sethsimmons> 15% has been sold at least so far, but 100% was mined in the genesis block.
18:29:13 <moneromooo> jesus... so it's an outright scam basically. I assumed the premine was a few percent or so.
18:29:38 <sethsimmons> https://raw.githubusercontent.com/UkoeHB/Mechanics-of-MobileCoin/master/Mechanics-of-MobileCoin-v0-0-39-preview-10-11.pdf
18:29:41 <sethsimmons> Page 133
18:30:25 <moneromooo> Stellar is also 100% premined ?
18:30:36 <sethsimmons> Not sure
18:30:59 <sethsimmons> I don't think so but its been years since I dug into them.
18:31:07 <sethsimmons> Forgot they existed TBH
18:32:02 <UkoeHB> knaccc: not quite, you just attest to a public key, then anyone can open a communication channel with the enclave
18:33:01 <knaccc> UkoeHB oh ok, that's more reasonable, thanks for explaining. Btw am in awe of your paper-writing talents, as always :)
18:33:22 <UkoeHB> hah thanks :) I think they are slowly getting better over the years
18:33:50 <rupee[m]> <moneromooo "Stellar is also 100% premined ?"> stellar started with 100 billion lumens and there is 1% inflation
18:34:07 <hyc> still can't beliee anyone would look at anybody's proprietary security mechanisms as acceptable. for anything.
18:34:19 <UkoeHB> rupee[m]: how do they mint new coins?
18:35:28 <rupee[m]> i'm not that familiar with it actually, but from searching the web I found:
18:35:28 <rupee[m]> "The Stellar distributed network has a built-in, fixed, nominal inflation mechanism. New lumens are added to the network at the rate of 1% each year. Each week, the protocol distributes these lumens to any account that gets over .05% of the “votes” from other accounts in the network."
18:35:40 <rupee[m]> from here: https://medium.com/blockchain-manchester/how-to-stellar-inflationary-rewards-3c7df9090c24
18:36:07 <rupee[m]> "Basically every week, once you are setup to receive inflationary rewards, you account will be debited with XLM. Distribution of inflation and any fees used on the network is based on the voting power you possess, the number of votes is based on the number of Lumens, XLM, you own. The minimum amount of you need to vote is 0.05% of all Lumens in existence which for most XLM owners will mean joining a pool which
18:36:07 <rupee[m]> many will also charge you for the privilege e.g. 10% of any rewards earned."
18:36:47 <UkoeHB> some kind of staking?
18:37:26 <gingeropolous> yes, all non-mining protocols require premine because mining is also a way to distribute coins afaict
18:38:13 <gingeropolous> sry, scrollback.
18:38:38 <hyc> self-perpetuating wealth. if you bought into the ICO, you keep earning coins in perpetuity
18:39:00 <hyc> doesn't sound like it'd yield very broad distribution
18:39:01 <gingeropolous> its just central banking 2.0
18:39:39 <gingeropolous> if you control the money, you control the votes, and if you control the votes, you control the money. wcgw?
18:40:44 <hyc> yeah
18:43:28 <gingeropolous> what do they call it? byzantine agreement?
18:44:11 <UkoeHB> scp uses the 'federated byzantine agreement model'
18:45:01 <gingeropolous> aka the Central Banking Model. i wonder if the central banking model could actually be called that
18:45:23 <UkoeHB> ?
18:46:05 <gingeropolous> i just wonder if you actually compared the two approaches, how similar they'd be
18:46:22 <UkoeHB> quite different I imagine
18:47:17 <gingeropolous> I dunno. The central banks decide  and reach a consensus on what the money supply should be.
18:51:45 <gingeropolous> but i guess mobilecoin doesn't think of itself as a money, just a payment platform ... ?
18:54:13 <UkoeHB> mobilecoin has thoughts? has ai come that far? alternate universe?
18:58:04 <hyc> mobilecoin was created to fund signal, didn't whtshisface already state that explicitly? moxie or whoever?
18:59:04 <rupee[m]> "I started MobileCoin to fund Signal. That’s it."
18:59:08 <rupee[m]> https://news.ycombinator.com/item?id=26726246
18:59:50 <rupee[m]> and "once the dust settles" MobileCoin intends to not own many coins
19:01:23 <rupee[m]> that almost implies to me that the intention is for the transaction fees to go to either MobileCoin or Signal (in addition to the money they raise from selling the coins)
19:02:02 <rupee[m]> wouldn't be a very sustained funding model if they stop bringing in revenue once all the coins are sold
19:02:38 <rupee[m]> Who decides the transaction fee rate? I read it's 0.01 MOB right now but they are planning to reduce it
19:03:01 <sethsimmons> Foundation I guess
19:03:21 <sethsimmons> I would assume they either forgot to change it or didn't expect the pump to go so well
19:04:22 <UkoeHB> someone opened a 200mill USD short position when the price was like 4$ - didn't end well for them
19:04:42 <selsta> UkoeHB: do you know why the circulating supply is not known? and mobilecoin also said they might will not share that info?
19:04:49 <selsta> might not*
19:05:22 <UkoeHB> can't say - contract
19:05:27 <rupee[m]> I wonder if that "short position" was one of the founders just tryiing to lock in their gains in case the price crashed on announcement
19:05:52 <rupee[m]> or to lock in profits despite having some sort of restrictions on their ability to sell their pre-sale coins
19:05:57 <UkoeHB> well they lost all their collateral (probably 400-600mill +)
19:07:08 <rupee[m]> why would someone bet so massively against it. seems more likely to me they were trying to lock in profit and then got caught without enough collateral to finance the hedge
19:07:46 <UkoeHB> actually probably not that much - I think they just had to pay back interest, which was maybe 40-100mill usd max
19:08:47 <midipoet> Why is Mobilecoin discussed in here?
19:08:57 <midipoet> It's an ICO is it not?
19:09:04 <midipoet> Does that discussion belong here?
19:11:10 <rupee[m]> it's a new implementation of RingCT and other technology that monero uses (developed). Perhaps there are concepts we can learn from their code
19:11:11 <sethsimmons> Started out discussing the technical approaches
19:11:15 <sethsimmons> But devolved a bit
19:12:01 <rupee[m]> Personally, I would like to see monero have view keys that reveal both incoming and outgoing transactions if it can be done in a way that doesn't damage the privacy of users in a meaningful way
19:12:30 <rupee[m]> I suspect that will give MOB an advantage when trying to get listed on exchanges
19:13:31 <UkoeHB> we tried to figure it out here: https://github.com/monero-project/research-lab/issues/58
19:14:12 <midipoet> It's devolved quite a bit indeed, but I am not a moderator, so perhaps it's legit convo for MRL channel.
19:15:55 <rupee[m]> no, thanks for getting the conversation back on track.
19:17:27 <sarang> Outgoing view keys are tricky to do in a way that can't be gamed
19:17:51 <sarang> It's straightforward as a convenience feature, but implies a certain level of trust in keyholders
19:19:11 <moneromooo> I believe someone proposed a way. Named... Kingsomething. It was on github.
19:20:05 <moneromooo> Aha: https://github.com/monero-project/monero/issues/1070
19:25:27 <luigi1111w> ye
19:25:29 <luigi1111w> but heavy