November 27, 2017

**<suraeNoether>** anyway, agenda for the day: 1) Greetings, 2) Sarang's work 3) my work 4) open discussion. The new zksnark paper will presumably take up some of 4. :P

**<suraeNoether>** 1) is done i guess. :\

**<suraeNoether>** 2) Sarang want to bring us up to speed?

**<sarang>** roger

**<sarang>** I have working code for both linear and logarithmic bulletproofs that tests correctly

**<sarang>** I'm finishing up a few small optimizations to reduce the curve op count

**<suraeNoether>** nice

**<sarang>** and then it'll be ready for C++

**<sarang>** moneromooo already has the linear version up and running

**<suraeNoether>** fantastic!

**<sarang>** That's been my big project

**<suraeNoether>** page 8 of the new zksnark paper talks about dot product proof protocols

**<sarang>** orly

**<sarang>** That's the big shiny toy of bulletproofs

**<suraeNoether>** literally caught my eye

**<suraeNoether>** or rather

**<suraeNoether>** metaphorically? well

**<suraeNoether>** anyway, my point is i have done nothing but skim the paper (in the past 10 minutes) and that popped out at me

**<suraeNoether>** you have also been helping me on multisig, as well, don't discount that

**<sarang>** I shan't

**<suraeNoether>** anything else?

**<suraeNoether>** gratz on getting it working

**<sarang>** Thanks to everyone who offered support in the most recent fund drive

**<sarang>** I remain humbled

**<suraeNoether>** thank you, sarang! thanks again

*** sarang** takes a small bow

**<suraeNoether>** As for my work, I've been working on the multisig paper, which is intended to 1) present a formal model of our threshold ringct, and 2) show how our current implementation compares to that formal model. there are differences that i'm hunting down one by one

**<suraeNoether>** JollyMort[m] has found several already, and we've been having discussions about it the past few days

**<suraeNoether>** That has represented the vast majority of my time

**<suraeNoether>** In addition to that, I believe I may have a problematic example case of SPECTRE. the original authors sweep my concern aside, but i wanted to bring it up and see if anyone had any thoughts

**<sarang>** I'm intrigued

**<suraeNoether>** if two transactions using the same input are relayed nearly simultaneously, they will find their way into two separate blocks. they will appear as conflicting transactions until the spectre algorithm arranges one block to precede the other

**<suraeNoether>** or stay conflicting forever if spectre can never linearly order them

**<suraeNoether>** this can happen with a simple example of a "mostly linear" blockchain, except with a single block in the chain replaced with a pair of blocks like a diamond shape:

**<suraeNoether>** ___\/\___

**<suraeNoether>** \/

**<suraeNoether>** something that looks like that

**<suraeNoether>** then any transactions that conflict in the pair of non-linearly-ordered blocks will appear to conflict forever

**<suraeNoether>** this allows a clumsy user who re-sends a transaction twice becuase he's foolish to lose his funds.

**<sarang>** Can we back this up with a simulation?

**<suraeNoether>** i mean, we could, but there's a solid chain of lemmas that lead to a theorem i can write up later if you like

**<suraeNoether>** using the theorems about how rapidly sets in spectre get finalized

**<sarang>** Even better

**<sarang>** *lemmata

**<suraeNoether>** now, the spectre authors said "the only reason someone would relay two transactions like this is to attempt a double spend, so it's okay that the funds are lost."

**<sarang>** lolwut

**<suraeNoether>** well

**<suraeNoether>** the idea is that htey are *two* transactions with valid signatures using the same input

**<suraeNoether>** or rather, using at least one of the same inputs

**<suraeNoether>** so by definition, it's a double spend

**<suraeNoether>** and i can't really think of a scenario where someone would compute two signatures separately like that, then relay them nearly simultaneously like that… on accident

**<suraeNoether>** BUT

**<suraeNoether>** it's enough of a leap for me to be concerned

**<suraeNoether>** moreover

**<suraeNoether>** i'm not sure if that sort of "double spend implies money lost forever instead of "eventually one of the two spends is accepted."

**<suraeNoether>** and what's really crazy

**<suraeNoether>** is that if block arrival times are very fast, like 10/s as in the original spectre paper… this problem is solved *with high probability*

**<suraeNoether>** so, that's where SPECTRE is sitting.

**<suraeNoether>** and lastly, my viewkey proposal

**<suraeNoether>** s/lost forever/lost forever" philosophy instead of…

**<scoobybejesus>** I own address A, B, and C. I simultaneously send the same output as an input in txns A ->** B and A ->** C. Free coins? Or B and C each now have unspendable outputs?

**<suraeNoether>** a miner would see two conflicting transactions, so neither would be considered valid

**<suraeNoether>** and constructing another transaction later A->**D will also be considered invalid
**<scoobybejesus>** Ah. Thanks.

Post tags : Dev Diaries, Community, Cryptography, Monero Research Lab