15:12:41 <maybefbi> UkoeHB_: there is no 0 on an elliptic curve. so how do we show difference in sums of commitments is 0?
15:15:27 <maybefbi> im thinking of showing the two different sums are the same.
15:37:39 <UkoeHB_> there is identity I which is analogous to 0, you could show the sums subtract up to I; or, as we do, sign a commitment to zero which demonstrates when the sums subtract that the result is only 'composed' of one generator
15:39:33 <UkoeHB_> https://elementsproject.org/features/confidential-transactions/investigation
15:41:10 <UkoeHB_> maxwell's original paper is no longer hosted...
15:42:06 <UkoeHB_> but looks like that link has the same content
16:15:21 <maybefbi> UkoeHB_: by signing the way of Z2M2 Section 6.2.2, we prove to everyone we know the difference between pseudo_blinding_factor of an input of the current transaction and the blinding_factor used in the previous transaction's outputs, such that no new money is created in the inputs of the current transaction. pseudo_blinding_factors are all random except for one which is set to be the difference between the sum of blinding facto
16:15:21 <maybefbi> rs of the previous transaction, and the sum of random pseudo_blinding_factors in this transaction. but if we subtract sum of blinding factors of this transaction's outputs from pseudo_blinding_factors of THIS transaction's inputs we will never get field element 0. because the blinding factor used in this transactions outputs are generated using this transaction's transaction-public-key, view-key etc. if blinding factors of out
16:15:21 <maybefbi> puts - inputs of the same transaction dont cancel each other out, i dont know how the commitments can cancel each other out.
16:28:11 <UkoeHB_> "pseudo_blinding_factors are all random except for one which is set to be the difference between the sum of blinding factors of the previous transaction, and the sum of random pseudo_blinding_factors in this transaction" <- not so, (section 5.4) the last pseudo blinding factor is equal to [sum output blinding factors - sum other pseudo blinding factors]; this way sum of pseudo outs equals sum of new outs
16:28:44 <UkoeHB_> while [sum inputs - sum pseudo outs = zG]
16:29:18 <UkoeHB_> sorry: each individual [input - pseudo out = z_t G]
16:36:33 <maybefbi> UkoeHB_: "the last pseudo blinding factor is equal to [sum output blinding factors - sum other pseudo blinding factors]; this way sum of pseudo outs equals sum of new outs" <- if this is the case we haven't proved if new money hasn't been created between previous transaction's outputs, and this transaction's inputs. somebody would be able to create a transaction which spends more money than available in the previous transactio
16:36:33 <maybefbi> n's outputs
16:42:34 <UkoeHB_> the connection is the commitment to zero [input - pseudo out = z_t G], signing z_t G shows there is no H component so the amount in a given pseudo out equals the amount in its corresponding input
16:43:08 * Isthmus pokes head up
16:43:12 <Isthmus> did somebody say quantum?
16:43:40 <Isthmus> Lemme catch up
16:44:19 <moneromooo> I thought you might be interested in this problem of identifying asshole peers based on machine learning techniques.
16:44:40 <moneromooo> We want to get rid of them in a way that doesn't break once they start hiding.
16:44:53 <Isthmus> Oooh that's an interesting problem
16:45:41 <moneromooo> They point to each other, so I thought k-means might be a good way to find those clusters of high internal connectivity.
16:46:00 <moneromooo> However, peers don't send their whole peer list, they only send bits, over time.
16:46:22 <Isthmus> Let's see, so if we want objective measures that I can apply to any node...
16:46:22 <Isthmus> 1) does or does not relay transactions
16:46:22 <Isthmus> 2) does or does not relay blocks
16:46:22 <Isthmus> 3) does or does not mirror your height regardless of block height
16:46:43 <Isthmus> And then yea, the additional features/distances that can be analyzed from the graph
16:47:09 <maybefbi> UkoeHB_: by signing we proved this_transaction.input - previous_transaction.output == 0. i.e. no new money has been created. is this the case?
16:47:41 <Isthmus> Do we know what kind of coverage they have (are the potential AHPs connected to 30% of known/organic nodes or 90%)
16:47:52 <UkoeHB_> uh I guess you could think of it like that
16:48:38 <maybefbi> UkoeHB_: we haven't proved this_transaction.output - this_transaction.input == 0
16:48:44 <UkoeHB_> technically the input is literally the previous transaction's output; the pseudo output is just that, a pseudo representation of the output being spent; a 'rebranding' of that output if you will, which signing the commitment to zero demonstrates
16:50:35 <maybefbi> agreed. but we havent proved this_transaction.output - this_transaction.input == 0
16:51:01 <maybefbi> we have proved this_transaction.input - previous_transaction.output == 0
16:51:05 <UkoeHB_> it's like this: [old output - pseudo out = zG], [sign zG], [sum pseudo outs == sum new outs]
16:51:59 <UkoeHB_> the pseudo out blinding factors are based on new out blinding factors
16:53:27 <maybefbi> i was doing it wrong then. i made pseudo out blinding factors are based on old out blinding factors
16:53:51 <maybefbi> and i was able to [old output - pseudo out = zG], [sign zG], but not do [sum pseudo outs == sum new outs]
16:54:57 <maybefbi> UkoeHB_: thanks i think i get it now. sorry for acting like a skeptic.
16:55:38 <UkoeHB_> no problem :) sometimes it is hard to believe RingCT really works; I find myself over and over getting skeptical and digging deeper
16:56:20 <maybefbi> yeah i cant shake the paranoia that somebody might be secretly minting money without being a miner
16:59:09 <Isthmus> Have we tried reporting to AHPs a higher height than known to see if they mirror it back or ask for it?
16:59:09 <Isthmus> If the purpose is surveillance, reporting height 9999999999 would stick out on their logs and reveal suspicion. But reporting +1 or +2 blocks ahead shouldn't trigger any attention.
16:59:09 <Isthmus> (Of course anybody spying on Monero ought to be in this room, so probably just tipped my hand anyways)
16:59:21 <Isthmus> I could see a R-X-R probe situation
16:59:46 <Isthmus> Because this allows us to very subtly check something with no false positives:
16:59:54 <Isthmus> Let R1 and R2 be research nodes connected to the test subject X
17:00:42 <Isthmus> Suppose R1 says, "hey, I'm at height H+1" and X replies "same here"
17:00:42 <Isthmus> And then R2 says "hey I'm at height H" and X replies "same here"
17:00:45 <TheCharlatan> Isthmus did you see the script that gingeropolous posted in -dev? It pops a couple of blocks, checks who is still mirroring and bans them.
17:01:04 <Isthmus> Ooh I didn't see that
17:01:12 <TheCharlatan> Seems like we have some more people here for today's meeting :)
17:01:22 <TheCharlatan> Hi all
17:01:33 <UkoeHB_> hi
17:02:13 <Isthmus> heyo
17:02:19 <moneromooo> Oh. Forgot again -_- Hi.
17:04:38 <TheCharlatan> We don't have any items posted, right?
17:05:09 <UkoeHB_> has anyone been working on any research-like projects they would like to mention
17:05:12 <UkoeHB_> ?
17:06:27 <TheCharlatan> I'll go first then. With the last fork we also changed the way Unix time based unlock_times are treated.
17:06:34 <Isthmus> :- )
17:06:46 <TheCharlatan> The formula for that was created by UkoeHB_
17:07:08 <UkoeHB_> yep
17:07:24 <TheCharlatan> I published a full writeup on why it was changed on my blog: https://thecharlatan.ch/Monero-Unlock-Time-Vulns/
17:07:39 <UkoeHB_> oh nice
17:08:09 <TheCharlatan> There should be a disclosure on hackerone as well, but someone from the core team has to hit a button for it to be visible or something.
17:08:11 <ArticMine> Hi
17:08:46 <TheCharlatan> Anyway, that article treated a specific weakness in the protcol that is now patched.
17:08:56 <moneromooo> I can do that. I think we just do it for actual exploits, not all the stuff we get.
17:09:28 <TheCharlatan> I also wrote another article on timelocks that gives a summary of why I think the field is problematic.
17:10:03 <TheCharlatan> It builds on work that Isthmus has discussed here in January and that we discussed here in May with sarang https://thecharlatan.ch/Monero-Unlock-Time-Privacy/
17:10:57 <TheCharlatan> To re-iterate: about 98% of current unlock_time usage does not really make semantic sense.
17:12:49 <TheCharlatan> These are unlock_time values that are far below a current block height.
17:13:52 <TheCharlatan> The 2% of legitiamte values seem reasonably distributed, safe for some small weird clusters.
17:14:15 * Isthmus gets an idea for a plot
17:14:18 <Isthmus> (brb)
17:14:39 <TheCharlatan> However, current ring selection does not take the unlock_time into account.
17:15:04 <ArticMine> One question that I have with time locks is allowing for basic payment channels in Monero
17:15:26 <moneromooo> Hmm. We could consensus forbid unlock time below currnet height. It'd double as "this tx is only valid for N blocks". That sounds like it could be useful.
17:15:37 <TheCharlatan> So two transactions mined in the same block, but with different values and mature since different times are treated the same.
17:16:00 <TheCharlatan> Yes, so in the article I argue that we should get rid of it altogether.
17:16:11 <TheCharlatan> But I think that might be a hard selll.
17:17:19 <TheCharlatan> So instead, I propose to 1) limit the field to a more compact size, 2) only use block-based unlock_time, 3) move it to per-output and 4) take the maturity of a transaction, not its mined height into account.
17:17:42 <TheCharlatan> And then 5) what you said moneromooo
17:17:56 <Isthmus> `(unlock time) - (height of youngest ring member) >= 10`
17:18:03 <moneromooo> 3 sounds you could usually deduce which is the change (the one without an unlock time).
17:18:11 <moneromooo> What is 4 ?
17:18:54 <TheCharlatan> moneromooo Copied from the post:
17:19:24 <Isthmus> Hmm yea, per-output is good for functionality, will make info leaks leakier if kept plaintext. However, per-output encrypted lock time would give best of both worlds (full functionality & information-theoretic privacy)
17:19:35 <TheCharlatan> Assume the current block height is 400'000. By the current rules, an output with unlock_time 350'000 mined at block height 200'000 is treated the same as an output at 200'000, even though the unlock_time encumbered output has only been available for spending for 50'000 blocks, while the other output has been for 200'000.
17:20:46 <moneromooo> You mean the code selects ring members which are still locked ? Are you sure about this ? IIRC it at least tries not to, but it might be buggy if that's what you saw...
17:21:03 <TheCharlatan> No
17:21:08 <TheCharlatan> That's not what I mean :)
17:21:27 <TheCharlatan> That code works correctly in that respect.
17:21:58 <moneromooo> Define "treated the same" then please.
17:23:47 <TheCharlatan> The ring member selection should not select by current_height - tx_mined_height, but rather by current_height - unlock_time (if the timelock is not 0)
17:24:51 <Isthmus> BTW here's the visual representation of comment by TheCharlatan "To re-iterate: about 98% of current unlock_time usage does not really make semantic sense."
17:24:53 <Isthmus> https://usercontent.irccloud-cdn.com/file/h4V6caVQ/image.png
17:25:01 <Isthmus> The data set started at height 10^6 (red line)
17:25:30 <Isthmus> So every single unlock time below that value is meaningless (would never be locked)
17:26:00 <moneromooo> I see.
17:26:04 <moneromooo> That makes sense.
17:26:57 <moneromooo> So you're saying an output with a very lock time would never the a period of high likelihood of selection as fake out, so will likely onle be used  as the real spend. Right ?
17:27:05 <moneromooo> very *long* lock time
17:27:26 <TheCharlatan> To repair this unlock_time ring member selection, we should collect some data from bitcoin's use of CHECKLOCKIMEVERIFY and CHECKSEQUENCEVERIFY first though. Just to make sure we mimic actual unlock_time usage.
17:27:36 <TheCharlatan> yes moneromooo
17:28:17 <UkoeHB_> I think that treating a locked tx age as 'time spendable' instead of 'time on-chain' for purposes of ring-member selection is a good idea
17:28:58 <Isthmus> Haha wait it's even better as a PDF than CDF... The few txns in the blue circle are the only ones that used block unlock times in a meaningful way
17:29:00 <Isthmus> https://usercontent.irccloud-cdn.com/file/qa6YyXhu/image.png
17:29:09 <TheCharlatan> But, as stated in the article, it's not really a problem right now, because it amounts to about 200 such transactions. Of course usage may change in the future though.
17:30:22 <TheCharlatan> On the topic of transparent per-output timelocks, I might be weighing the risks wrong here. After all, we could not find a single transaction that locked XMR for a fatal amount of time.
17:30:52 <Isthmus> besides mine :- P
17:31:00 <UkoeHB_> ArticMine: I wondered that too, but have a hard time imaging who would use them or for what purpose
17:31:01 <TheCharlatan> Besides yours :P
17:31:31 <ArticMine> Multiple tx to one vendor
17:31:51 <ArticMine> For example a coffer shop or transit authority
17:32:40 <ArticMine> One opens a payment channel with the vendor. Then spends n the channel for each cup of coffee or bus / tram ride etc
17:33:19 <ArticMine> There are very significant privacy advantages for this
17:34:03 <TheCharlatan> Anyway, next step for me will be to probe bitcoin's usage of timelocks.
17:34:37 <TheCharlatan> Then I think I should open a MRL issue with points 1), 2), 3) and 5). The discussion can be continued after that with something more fleshed out.
17:35:35 <moneromooo> With encrypted lock times, does the lock time prevent verification if any input in the ring is locked, or if only the real input is locked ?
17:36:45 <Isthmus> Has to be real input, because we wouldn't be able to know/decrypt lock time of decoys
17:37:02 <moneromooo> Then this would fix the problem TheCharlatan pointed out.
17:37:09 <TheCharlatan> yes, it's just the real input. It's analogous to the amounts.
17:37:49 <Isthmus> BTW b10c has written some really great articles about bitcoin lock time.
17:37:49 <Isthmus> https://b10c.me/mempool-observations/1-locktime-stairs/
17:37:49 <Isthmus> https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/
17:37:52 <moneromooo> (since locked outs would be selected in rings without failing verification, and yes, thinking some more I could have worked it out)
17:38:09 <TheCharlatan> ^ I might have inspired some of those articles :P
17:38:37 <TheCharlatan> So I guess I'll still ask, how the room feels about removing them entirely?
17:39:21 <UkoeHB_> I don't have strong feelings either way
17:39:23 <Isthmus> I think the only viable options are removing or encrypting
17:39:28 <moneromooo> I would not be against it, unless they're needed for payment channel style stuff.
17:39:40 <moneromooo> (replacement would still be OK if so)
17:39:44 <UkoeHB_> the lack of current use implies it wouldn't be missed
17:41:21 <ArticMine> I am not in favor of removing
17:41:44 <ArticMine> because of the future payment channel application
17:42:40 <ArticMine> LN is a horrible mess, but vendor payment channels is that baby that should not be thrown out with the bathwater
17:42:59 <ArticMine> So I would go for encrypting
17:43:18 <UkoeHB_> would you mind sketching out how such a payment channel would be constructed?
17:43:35 <UkoeHB_> or could be*
17:43:35 <moneromooo> The lock time scheme we end up needing for that future payment channel system might not be the one we have now, so that doesn't prevent removing.
17:43:55 <TheCharlatan> ^ I agree with moneromooo
17:44:00 <moneromooo> And either reading later, or, more likely, adding a differentl one later better adapted to payment channels.
17:44:48 <moneromooo> Umless you think we won't be able to change anything at some point I guess.
17:44:52 <ArticMine> Then we can remove the current one
17:45:58 <ArticMine> Unless there is another clear use case
17:47:14 <Isthmus> I think that the IRC crowd does not know of other known current uses. (based on this and recent conversations)
17:47:17 <Isthmus> If we open a github issue about removal and crosspost to Reddit, that should give ample opportunity for anybody in the community with a compelling use case time to speak up
17:47:43 <ArticMine> That sounds like a good idea
17:48:24 <TheCharlatan> Isthmus I'm all for that :)
17:48:48 <moneromooo> Uses I heard about are: "prevent my future self from selling in fear", "gift some money to my kids for when they're 18" and "prevent stealing", though that last one's miguided.
17:49:06 * Isthmus clarifies: payment channels are a very compelling use case, and I'm fine with discussing re-implementation if/when payment channels are on the table
17:49:25 * Isthmus ponders cases mentioned by mooo
17:49:35 <moneromooo> I could also imagine keeping money as security (ie, a flat deposit).
17:49:46 <moneromooo> Though that's probably better done with multisig.
17:50:26 <ArticMine> US DOJ "burn Monero" application with lock time >> age of the universe
17:51:17 <Isthmus> Ah yea
17:51:22 <Isthmus> That's not the only way to provably burn, right?
17:51:23 <Isthmus> e.g. send to generator, send to pubkey 00000000000000000, etc
17:51:34 <moneromooo> No :)
17:52:08 <moneromooo> I mean, maybe not :)
17:52:13 * Isthmus wants to compile a list of all the ways to provably destroy monero, but doesn't want to derail unlock time convo
17:52:35 <moneromooo> Just setting the pubkey in extra to 0000 doesn't mena it's burnt.
17:52:45 <Isthmus> Oh true, there *could* exist a private key...
17:53:11 <sech1> boating accidents have always been the only way to burn monero
17:53:14 * sech1 runs
17:53:55 <TheCharlatan> Meeting is nearly over, does someone else have something to discuss?
17:55:45 <Isthmus> Oh btw all data credit for unlock time stuff goes to @n3ptune and their magical DB
17:56:23 <TheCharlatan> yupyup, thanks n3ptune!
17:56:29 <n3ptune> thanks!
17:56:49 <n3ptune> #noncesense-research-lab is always open for your data needs
17:58:31 <Isthmus> :- D
17:59:14 <Isthmus> I got a giant (many GB) data set from n3ptune this weekend to do the per-field stats tests for info leaks, but I'm still working on data ingestion, no results yet https://github.com/Mitchellpkt/crypto_field_stats_tests
18:00:06 <TheCharlatan> nice :)
18:02:30 <TheCharlatan> see y'all next week then
18:02:32 <UkoeHB_> Thanks for the meeting
18:03:18 <Isthmus> gg
18:09:52 <ArticMine> <Isthmus> That's not the only way to provably burn, right? <---- by provably meaning not involving a ZCash style ceremony to destroy private keys at an "obscure" location such as Kersley BC
18:10:30 <ArticMine> https://tourismquesnel.com/stay/alamo-motel-rv-park/
21:53:32 <dEBRUYNE> If anybody is able to comment here, would be appreciated.
21:53:36 <dEBRUYNE> https://www.reddit.com/r/Monero/comments/jcsm23/rmonero_weekly_discussion_october_17_2020_use/g9kd3ee/
21:53:37 <monerobux> [REDDIT] /r/Monero Weekly Discussion – October 17, 2020 - Use this thread for general chatter, basic questions, and if you're new to Monero (self.Monero) | 19 points (100.0%) | 63 comments | Posted by AutoModerator | Created at 2020-10-17 - 10:09:35
22:00:02 <hyc> he should write about teh trivialization of recent bugs ...
22:01:24 <dEBRUYNE> lol
22:01:53 <dEBRUYNE> I guess you can classify my statement as trivializing if you assume the base is substantial exaggeration
22:08:15 <hyc> this guy was right https://old.reddit.com/r/Monero/comments/jfcsoh/regarding_antifragility_and_the_recent_bugs/g9jf15t/
22:08:22 <hyc> the post was ridiculously patronizing
22:09:31 <hyc> that bug clearly fell into the category of unknown unknowns. You can't design a test for it if you don't know to look for it.
22:29:10 <Isthmus> @dEBRUYNE I added a few ideas, but welcome more
22:31:06 <Isthmus> Hmm, depending on their background... @ArticMine your fee stuff & modeling falls under EconSec threat models, which could be pretty interesting. Anything you would want to carve off for them to analyze?
22:31:30 <Isthmus> (in response to the reddit link posted by dEB)
22:31:46 <Isthmus> s/dEB/dEBRUYNE
22:31:46 <monerobux> Isthmus meant to say: (in response to the reddit link posted by dEBRUYNE)