-
maybefbi
UkoeHB_: there is no 0 on an elliptic curve. so how do we show difference in sums of commitments is 0?
-
maybefbi
im thinking of showing the two different sums are the same.
-
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
-
UkoeHB_
-
UkoeHB_
maxwell's original paper is no longer hosted...
-
UkoeHB_
but looks like that link has the same content
-
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
-
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
-
maybefbi
puts - inputs of the same transaction dont cancel each other out, i dont know how the commitments can cancel each other out.
-
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
-
UkoeHB_
while [sum inputs - sum pseudo outs = zG]
-
UkoeHB_
sorry: each individual [input - pseudo out = z_t G]
-
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
-
maybefbi
n's outputs
-
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
-
» Isthmus pokes head up
-
Isthmus
did somebody say quantum?
-
Isthmus
Lemme catch up
-
moneromooo
I thought you might be interested in this problem of identifying asshole peers based on machine learning techniques.
-
moneromooo
We want to get rid of them in a way that doesn't break once they start hiding.
-
Isthmus
Oooh that's an interesting problem
-
moneromooo
They point to each other, so I thought k-means might be a good way to find those clusters of high internal connectivity.
-
moneromooo
However, peers don't send their whole peer list, they only send bits, over time.
-
Isthmus
Let's see, so if we want objective measures that I can apply to any node...
-
Isthmus
1) does or does not relay transactions
-
Isthmus
2) does or does not relay blocks
-
Isthmus
3) does or does not mirror your height regardless of block height
-
Isthmus
And then yea, the additional features/distances that can be analyzed from the graph
-
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?
-
Isthmus
Do we know what kind of coverage they have (are the potential AHPs connected to 30% of known/organic nodes or 90%)
-
UkoeHB_
uh I guess you could think of it like that
-
maybefbi
UkoeHB_: we haven't proved this_transaction.output - this_transaction.input == 0
-
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
-
maybefbi
agreed. but we havent proved this_transaction.output - this_transaction.input == 0
-
maybefbi
we have proved this_transaction.input - previous_transaction.output == 0
-
UkoeHB_
it's like this: [old output - pseudo out = zG], [sign zG], [sum pseudo outs == sum new outs]
-
UkoeHB_
the pseudo out blinding factors are based on new out blinding factors
-
maybefbi
i was doing it wrong then. i made pseudo out blinding factors are based on old out blinding factors
-
maybefbi
and i was able to [old output - pseudo out = zG], [sign zG], but not do [sum pseudo outs == sum new outs]
-
maybefbi
UkoeHB_: thanks i think i get it now. sorry for acting like a skeptic.
-
UkoeHB_
no problem :) sometimes it is hard to believe RingCT really works; I find myself over and over getting skeptical and digging deeper
-
maybefbi
yeah i cant shake the paranoia that somebody might be secretly minting money without being a miner
-
Isthmus
Have we tried reporting to AHPs a higher height than known to see if they mirror it back or ask for it?
-
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.
-
Isthmus
(Of course anybody spying on Monero ought to be in this room, so probably just tipped my hand anyways)
-
Isthmus
I could see a R-X-R probe situation
-
Isthmus
Because this allows us to very subtly check something with no false positives:
-
Isthmus
Let R1 and R2 be research nodes connected to the test subject X
-
Isthmus
Suppose R1 says, "hey, I'm at height H+1" and X replies "same here"
-
Isthmus
And then R2 says "hey I'm at height H" and X replies "same here"
-
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.
-
Isthmus
Ooh I didn't see that
-
TheCharlatan
Seems like we have some more people here for today's meeting :)
-
TheCharlatan
Hi all
-
UkoeHB_
hi
-
Isthmus
heyo
-
moneromooo
Oh. Forgot again -_- Hi.
-
TheCharlatan
We don't have any items posted, right?
-
UkoeHB_
has anyone been working on any research-like projects they would like to mention
-
UkoeHB_
?
-
TheCharlatan
I'll go first then. With the last fork we also changed the way Unix time based unlock_times are treated.
-
Isthmus
:- )
-
TheCharlatan
The formula for that was created by UkoeHB_
-
UkoeHB_
yep
-
TheCharlatan
I published a full writeup on why it was changed on my blog:
thecharlatan.ch/Monero-Unlock-Time-Vulns
-
UkoeHB_
oh nice
-
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.
-
ArticMine
Hi
-
TheCharlatan
Anyway, that article treated a specific weakness in the protcol that is now patched.
-
moneromooo
I can do that. I think we just do it for actual exploits, not all the stuff we get.
-
TheCharlatan
I also wrote another article on timelocks that gives a summary of why I think the field is problematic.
-
TheCharlatan
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
-
TheCharlatan
To re-iterate: about 98% of current unlock_time usage does not really make semantic sense.
-
TheCharlatan
These are unlock_time values that are far below a current block height.
-
TheCharlatan
The 2% of legitiamte values seem reasonably distributed, safe for some small weird clusters.
-
» Isthmus gets an idea for a plot
-
Isthmus
(brb)
-
TheCharlatan
However, current ring selection does not take the unlock_time into account.
-
ArticMine
One question that I have with time locks is allowing for basic payment channels in Monero
-
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.
-
TheCharlatan
So two transactions mined in the same block, but with different values and mature since different times are treated the same.
-
TheCharlatan
Yes, so in the article I argue that we should get rid of it altogether.
-
TheCharlatan
But I think that might be a hard selll.
-
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.
-
TheCharlatan
And then 5) what you said moneromooo
-
Isthmus
`(unlock time) - (height of youngest ring member) >= 10`
-
moneromooo
3 sounds you could usually deduce which is the change (the one without an unlock time).
-
moneromooo
What is 4 ?
-
TheCharlatan
moneromooo Copied from the post:
-
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)
-
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.
-
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...
-
TheCharlatan
No
-
TheCharlatan
That's not what I mean :)
-
TheCharlatan
That code works correctly in that respect.
-
moneromooo
Define "treated the same" then please.
-
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)
-
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."
-
Isthmus
-
Isthmus
The data set started at height 10^6 (red line)
-
Isthmus
So every single unlock time below that value is meaningless (would never be locked)
-
moneromooo
I see.
-
moneromooo
That makes sense.
-
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 ?
-
moneromooo
very *long* lock time
-
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.
-
TheCharlatan
yes moneromooo
-
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
-
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
-
Isthmus
-
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.
-
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.
-
Isthmus
besides mine :- P
-
UkoeHB_
ArticMine: I wondered that too, but have a hard time imaging who would use them or for what purpose
-
TheCharlatan
Besides yours :P
-
ArticMine
Multiple tx to one vendor
-
ArticMine
For example a coffer shop or transit authority
-
ArticMine
One opens a payment channel with the vendor. Then spends n the channel for each cup of coffee or bus / tram ride etc
-
ArticMine
There are very significant privacy advantages for this
-
TheCharlatan
Anyway, next step for me will be to probe bitcoin's usage of timelocks.
-
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.
-
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 ?
-
Isthmus
Has to be real input, because we wouldn't be able to know/decrypt lock time of decoys
-
moneromooo
Then this would fix the problem TheCharlatan pointed out.
-
TheCharlatan
yes, it's just the real input. It's analogous to the amounts.
-
Isthmus
BTW b10c has written some really great articles about bitcoin lock time.
-
Isthmus
-
Isthmus
-
moneromooo
(since locked outs would be selected in rings without failing verification, and yes, thinking some more I could have worked it out)
-
TheCharlatan
^ I might have inspired some of those articles :P
-
TheCharlatan
So I guess I'll still ask, how the room feels about removing them entirely?
-
UkoeHB_
I don't have strong feelings either way
-
Isthmus
I think the only viable options are removing or encrypting
-
moneromooo
I would not be against it, unless they're needed for payment channel style stuff.
-
moneromooo
(replacement would still be OK if so)
-
UkoeHB_
the lack of current use implies it wouldn't be missed
-
ArticMine
I am not in favor of removing
-
ArticMine
because of the future payment channel application
-
ArticMine
LN is a horrible mess, but vendor payment channels is that baby that should not be thrown out with the bathwater
-
ArticMine
So I would go for encrypting
-
UkoeHB_
would you mind sketching out how such a payment channel would be constructed?
-
UkoeHB_
or could be*
-
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.
-
TheCharlatan
^ I agree with moneromooo
-
moneromooo
And either reading later, or, more likely, adding a differentl one later better adapted to payment channels.
-
moneromooo
Umless you think we won't be able to change anything at some point I guess.
-
ArticMine
Then we can remove the current one
-
ArticMine
Unless there is another clear use case
-
Isthmus
I think that the IRC crowd does not know of other known current uses. (based on this and recent conversations)
-
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
-
ArticMine
That sounds like a good idea
-
TheCharlatan
Isthmus I'm all for that :)
-
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.
-
» 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
-
» Isthmus ponders cases mentioned by mooo
-
moneromooo
I could also imagine keeping money as security (ie, a flat deposit).
-
moneromooo
Though that's probably better done with multisig.
-
ArticMine
US DOJ "burn Monero" application with lock time >> age of the universe
-
Isthmus
Ah yea
-
Isthmus
That's not the only way to provably burn, right?
-
Isthmus
e.g. send to generator, send to pubkey 00000000000000000, etc
-
moneromooo
No :)
-
moneromooo
I mean, maybe not :)
-
» Isthmus wants to compile a list of all the ways to provably destroy monero, but doesn't want to derail unlock time convo
-
moneromooo
Just setting the pubkey in extra to 0000 doesn't mena it's burnt.
-
Isthmus
Oh true, there *could* exist a private key...
-
sech1
boating accidents have always been the only way to burn monero
-
» sech1 runs
-
TheCharlatan
Meeting is nearly over, does someone else have something to discuss?
-
Isthmus
Oh btw all data credit for unlock time stuff goes to @n3ptune and their magical DB
-
TheCharlatan
yupyup, thanks n3ptune!
-
n3ptune
thanks!
-
n3ptune
#noncesense-research-lab is always open for your data needs
-
Isthmus
:- D
-
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
github.com/Mitchellpkt/crypto_field_stats_tests
-
TheCharlatan
nice :)
-
TheCharlatan
see y'all next week then
-
UkoeHB_
Thanks for the meeting
-
Isthmus
gg
-
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
-
ArticMine
-
dEBRUYNE
If anybody is able to comment here, would be appreciated.
-
dEBRUYNE
-
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
-
hyc
he should write about teh trivialization of recent bugs ...
-
dEBRUYNE
lol
-
dEBRUYNE
I guess you can classify my statement as trivializing if you assume the base is substantial exaggeration
-
hyc
-
hyc
the post was ridiculously patronizing
-
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.
-
Isthmus
@dEBRUYNE I added a few ideas, but welcome more
-
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?
-
Isthmus
(in response to the reddit link posted by dEB)
-
Isthmus
s/dEB/dEBRUYNE
-
monerobux
Isthmus meant to say: (in response to the reddit link posted by dEBRUYNE)