All you are fighting for is e-penis of a guy you never met, that doesn't even have common decency to pay you for your time.

Do you think they care about Monero, or privacy or anything other than money?

UkoeHB__ wrote a report on the mechanics of MobileCoin if anyone wants to read up on it

^ seems like it's still missing any mobilecoin specific sections.

TheCharlatan: looks like I jumped the gun, it's just the first 2 chapters that are ready

releasing approx 1ch a week

the protocol isn't a secret though; in summary: crypto is Ristretto on Ed25519, tx protocol is modeled after RctTypeBulletproof2, transactions are validated inside SGX secure enclaves where inputs (ring signatures and input references) are discarded post-validation, validating enclaves ensure ring members exist in the blockchain with merkle proofs, and the network is a Byzantine federated agreement

protocol based on Stellar consensus protocol

sgp_[m]: looks complete to me. It can generate and verify bulletproofplusses.

1930 bytes for a test 2->2.

Wait, that one was not a BP plus.

Why does MobileCoin use MLSAG?

Artifact of development cycles

Ring sig scheme is somewhat less important in MC because sigs are discarded post-validation

is this like grin (at least on a high level) where surveillance nodes can retain this info?

If enclaves are not breached, no one can know the contents of transactions

So in the ideal state the complete transaction graph is unknown

The main weaknesses are A) barrier to entry for running a node since you must own SGX-enabled device, B) in a severe situation where most or all of the network is shut down it MIGHT be possible to inject outputs into the databases of compromised nodes and get them accepted as legitimate when the network recovers

Also, Intel could really mess things up if they wanted

Basically tx authors encrypt tx, the tx are sent into secure enclaves and decrypted, the tx are validated, and the enclaves output the tx outputs. How exactly that works, is part of Mechanics of MobileCoin

<UkoeHB__ "Also, Intel could really mess th"> This has never seemed like a good trade-off for me

Instead of targeting the blockchain, I could target Intel

* Instead of targeting the blockchain, I could target Intel or their employees

Afaik the MC team wants to rely less on intel in the future. The development work for even the initial implementation is non-trivial

Maybe the biggest improvement would be not depending on Intel for remote attestation, making it harder to censor nodes trying to run the MC software

<UkoeHB__ "Afaik the MC team wants to rely "> Oh I see, if trust is not that big a issue, I’d probably swap it out for a Snark which uses a trusted setup like vanilla PLONK

It’d be interesting to see how it develops

sgp_: github.com/moneromooo-monero/bitmonero/tree/bp%2Bc (plugs sarang's code in, looks like it works just fine)

I'll have a small efficiency update later today relating to transcript initialization

nothing major

:(

We *want* major efficiency updates :(

heh

I already included those!

The initial work I did was much less efficient...

^_^

I don't think the optimizations were super clever, but I think they were a _little_ clever :D

sarang: Were you going to PR a blog to the site btw?

About Bulletproofs+

Wasn't sure if it was appropriate before an audit

I have that draft post that could be used

I think it is, arguably

Would also help potential donors understand what they are funding

I think it's useful

are the original people that had a BP+ CCS still available to audit?

I think we need to contact