UkoeHB_: there is no 0 on an elliptic curve. so how do we show difference in sums of commitments is 0?

im thinking of showing the two different sums are the same.

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

maxwell's original paper is no longer hosted...

but looks like that link has the same content

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

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

puts - inputs of the same transaction dont cancel each other out, i dont know how the commitments can cancel each other out.

"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

while [sum inputs - sum pseudo outs = zG]

sorry: each individual [input - pseudo out = z_t G]

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

n's outputs

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

did somebody say quantum?

Lemme catch up

I thought you might be interested in this problem of identifying asshole peers based on machine learning techniques.

We want to get rid of them in a way that doesn't break once they start hiding.

Oooh that's an interesting problem

They point to each other, so I thought k-means might be a good way to find those clusters of high internal connectivity.

However, peers don't send their whole peer list, they only send bits, over time.

Let's see, so if we want objective measures that I can apply to any node...

1) does or does not relay transactions

2) does or does not relay blocks

3) does or does not mirror your height regardless of block height

And then yea, the additional features/distances that can be analyzed from the graph

UkoeHB_: by signing we proved this_transaction.input - previous_transaction.output == 0. i.e. no new money has been created. is this the case?

Do we know what kind of coverage they have (are the potential AHPs connected to 30% of known/organic nodes or 90%)

uh I guess you could think of it like that

UkoeHB_: we haven't proved this_transaction.output - this_transaction.input == 0

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

agreed. but we havent proved this_transaction.output - this_transaction.input == 0

we have proved this_transaction.input - previous_transaction.output == 0

it's like this: [old output - pseudo out = zG], [sign zG], [sum pseudo outs == sum new outs]

the pseudo out blinding factors are based on new out blinding factors

i was doing it wrong then. i made pseudo out blinding factors are based on old out blinding factors

and i was able to [old output - pseudo out = zG], [sign zG], but not do [sum pseudo outs == sum new outs]

UkoeHB_: thanks i think i get it now. sorry for acting like a skeptic.

no problem :) sometimes it is hard to believe RingCT really works; I find myself over and over getting skeptical and digging deeper

yeah i cant shake the paranoia that somebody might be secretly minting money without being a miner

Have we tried reporting to AHPs a higher height than known to see if they mirror it back or ask for it?

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.

(Of course anybody spying on Monero ought to be in this room, so probably just tipped my hand anyways)

I could see a R-X-R probe situation

Because this allows us to very subtly check something with no false positives:

Let R1 and R2 be research nodes connected to the test subject X

Suppose R1 says, "hey, I'm at height H+1" and X replies "same here"

And then R2 says "hey I'm at height H" and X replies "same here"

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.

Ooh I didn't see that

Seems like we have some more people here for today's meeting :)

Hi all

hi

heyo

Oh. Forgot again -_- Hi.

We don't have any items posted, right?

has anyone been working on any research-like projects they would like to mention

?

I'll go first then. With the last fork we also changed the way Unix time based unlock_times are treated.

:- )

The formula for that was created by UkoeHB_

yep

I published a full writeup on why it was changed on my blog: thecharlatan.ch/Monero-Unlock-Time-Vulns

oh nice

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.

Hi

Anyway, that article treated a specific weakness in the protcol that is now patched.

I can do that. I think we just do it for actual exploits, not all the stuff we get.

I also wrote another article on timelocks that gives a summary of why I think the field is problematic.

It builds on work that Isthmus has discussed here in January and that we discussed here in May with sarang thecharlatan.ch/Monero-Unlock-Time-Privacy

To re-iterate: about 98% of current unlock_time usage does not really make semantic sense.

These are unlock_time values that are far below a current block height.

The 2% of legitiamte values seem reasonably distributed, safe for some small weird clusters.

(brb)

However, current ring selection does not take the unlock_time into account.

One question that I have with time locks is allowing for basic payment channels in Monero

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.

So two transactions mined in the same block, but with different values and mature since different times are treated the same.

Yes, so in the article I argue that we should get rid of it altogether.

But I think that might be a hard selll.

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.

And then 5) what you said moneromooo

`(unlock time) - (height of youngest ring member) >= 10`

3 sounds you could usually deduce which is the change (the one without an unlock time).

What is 4 ?

moneromooo Copied from the post:

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)

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.

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...

No

That's not what I mean :)

That code works correctly in that respect.

Define "treated the same" then please.

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)

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."

The data set started at height 10^6 (red line)

So every single unlock time below that value is meaningless (would never be locked)

I see.

That makes sense.

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 ?

very *long* lock time

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.

yes moneromooo

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

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

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.

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.

besides mine :- P

ArticMine: I wondered that too, but have a hard time imaging who would use them or for what purpose

Besides yours :P

Multiple tx to one vendor

For example a coffer shop or transit authority

One opens a payment channel with the vendor. Then spends n the channel for each cup of coffee or bus / tram ride etc

There are very significant privacy advantages for this

Anyway, next step for me will be to probe bitcoin's usage of timelocks.

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.

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 ?

Has to be real input, because we wouldn't be able to know/decrypt lock time of decoys

Then this would fix the problem TheCharlatan pointed out.

yes, it's just the real input. It's analogous to the amounts.

BTW b10c has written some really great articles about bitcoin lock time.

(since locked outs would be selected in rings without failing verification, and yes, thinking some more I could have worked it out)

^ I might have inspired some of those articles :P

So I guess I'll still ask, how the room feels about removing them entirely?

I don't have strong feelings either way

I think the only viable options are removing or encrypting

I would not be against it, unless they're needed for payment channel style stuff.

(replacement would still be OK if so)

the lack of current use implies it wouldn't be missed

I am not in favor of removing

because of the future payment channel application

LN is a horrible mess, but vendor payment channels is that baby that should not be thrown out with the bathwater

So I would go for encrypting

would you mind sketching out how such a payment channel would be constructed?

or could be*

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.

^ I agree with moneromooo

And either reading later, or, more likely, adding a differentl one later better adapted to payment channels.

Umless you think we won't be able to change anything at some point I guess.

Then we can remove the current one

Unless there is another clear use case

I think that the IRC crowd does not know of other known current uses. (based on this and recent conversations)

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

That sounds like a good idea

Isthmus I'm all for that :)

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.

I could also imagine keeping money as security (ie, a flat deposit).

Though that's probably better done with multisig.

US DOJ "burn Monero" application with lock time >> age of the universe

Ah yea

That's not the only way to provably burn, right?

e.g. send to generator, send to pubkey 00000000000000000, etc

No :)

I mean, maybe not :)

Just setting the pubkey in extra to 0000 doesn't mena it's burnt.

Oh true, there *could* exist a private key...

boating accidents have always been the only way to burn monero

Meeting is nearly over, does someone else have something to discuss?

Oh btw all data credit for unlock time stuff goes to @n3ptune and their magical DB

yupyup, thanks n3ptune!

thanks!

#noncesense-research-lab is always open for your data needs

:- D

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 github.com/Mitchellpkt/crypto_field_stats_tests

nice :)

see y'all next week then

Thanks for the meeting

gg

<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

If anybody is able to comment here, would be appreciated.

he should write about teh trivialization of recent bugs ...

lol

I guess you can classify my statement as trivializing if you assume the base is substantial exaggeration

this guy was right old.reddit.com/r/Monero/comments/jf…agility_and_the_recent_bugs/g9jf15t

the post was ridiculously patronizing

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.

@dEBRUYNE I added a few ideas, but welcome more

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?

(in response to the reddit link posted by dEB)

s/dEB/dEBRUYNE