Be excellent to each other.

i say we need weekly cryptography memes in the topic as well

hi, protocol question: is the 'dummy encrypted payment id' that appeared in v10 a protocol change, or just part of the core wallet software?

koe: AFAIK just core wallet

The original pull request #5001 doesn't imply a protocol change, but later pull requests may have. Anyone know?

thanks selsta

enforcing it would mean parsing tx_extra on consensus level which we want to avoid

#5008 sry

true

you back again? :)

just chipping away at 2nd edition, need to update list of changes at minimum

this mentions need to decide a long-term solution reddit.com/r/Monero/comments/aj21yt/big_bang_attack_on_xmr

is that the 'change to the block median used to calculate penalty' implemented in recent v12?

I'm wondering about this 'forbid old RingCT transaction format' at protocol v10/11. It doesn't look like there were new RCTTypes added (other than for bulletproofs), and the CURRENT_TRANSACTION_VERSION is still 2.

how was it enforced?

koe: RCTTypeBulletproof2

oh ok,did RCTTypeBulletproof consolidate RCTTypeFull and RCTTypeSimple? or was one eliminated?

not sure if I understand

previous to bulletproofs there were two kinds of transactions, RCTTypeFull and RCTTypeSimple. Full was for transactions with a single input, and Simple for multiple inputs.

ok, after bp hardfork only RCTTypeBulletproof exists

and now RCTTypeBulletproof2

but someone else has to explain the details I guess :P don’t know if all inputs are now treated as multiple inputs

ah looking back it seems the difference was down to amount hiding, which bulletproofs took over

or maybe TypeFull was just abandoned, since it wasn't really used much from the beginning

Is ban on unencrypted PIDs at consensus level or also honor system?

no ban

wallet ignores them

'unsupported by core wallet software' accurate?

Full is now unused. I had kept it originally because it saved like 32 bytes or so (not sure). But it also added a fair amount of extra code.

Bulletproof txes only use the "simple" scheme.

Nearly finished with CLSAG preprint revisions and major reorganization

It's tricky to build a straightforward narrative leading from the unforgeability definition and forking lemma to the final proof

suraeNoether: I'm going to work the unforgeability master algorithm description into the proof... I think this is more consistent with the structure of the other proofs, and hopefully more clear

I kept the forgery and forking algorithm descriptions separate, as you had before

suraeNoether: my reorganization is complete; please review (reorg.tex is the file)

Note any edits as review comments, if you please, to avoid any confusion or conflicting edits

I will do the same

Then we can release to IACR