-
gingeropolous
is the problem solved with a ringsize 1024
-
gingeropolous
cause sometimes i convince myself it is, but then i think of the iterative thing
-
gingeropolous
<knaccc> we kept coming back to the fundamental problem that your outputs just aren't ever used as decoys much, if at all. <<< i mean if this is the case, i dunno whats gonna augment this besides order of magnitude changes in ringsize
-
gingeropolous
in 2018 there was no triptych or arcturius.... lets do it
-
Isthmus
What fraction of outputs never showed up in a ring?
-
Isthmus
(within some arbitrary window)
-
knaccc
gingeropolous the problem is, even at ring size 1024, you have tens of millions of outputs to choose from, so getting outputs owned by the same set of users appearing in all 3 branches (in my diagram) is just not going to happen
-
knaccc
Isthmus actually i misremembered, most outputs are used
-
knaccc
-
» Isthmus is pleasantly surprised
-
knaccc
so yeah actually 100% coverage is so good there that i wonder if that can be right...
-
knaccc
hmm
-
knaccc
looks too good to be true
-
knaccc
all but 8 out of 27120 were used at least once
-
knaccc
it's as if someone pumping monero was running a script to artificially inflate the tx count, knowing that spamming 100k txs only costs $140
-
gingeropolous
now who would do that
-
sarang
Hello all
-
sarang
Looks like a lot of discussion about churn this past weekend
-
sarang
I'll catch up today (but will be away for a few hours for an appointment)
-
sgp_
needmoney90: I haven't looked at the numbers, but shouldn't churn behavior be relatively well hidden for a few churns given the relatively hasty selection algo? Maybe not for dozens of churns, and probably not for even >2,3 if done every 10 blocks exactly or something
-
sgp_
knaccc: paste expired; can you reshare please?
-
sgp_
disregard my earlier comment
-
sgp_
what is the difference between the count and chain length numbers?
-
knaccc
sgp_ 90-day expiry on this one
paste.debian.net/plain/1156229
-
knaccc
count means nubmer of times an output is referenced by another (in a ring)
-
knaccc
chain length means for each output, what is the maximum length of any chain that follows that output (due to other outputs referencing it in a ring, and other outputs referencing the results of those rings, and so on)
-
sgp_
knaccc: that's really clear, thanks
-
knaccc
sgp_ oops sorry, it may have been clear ,but also wrong :)
-
sgp_
it would be sweet if there was a way to extrapolate these with diferent ringsizes using the selection algo
-
knaccc
it's the preceeding chain
-
sgp_
haha
-
knaccc
so you take each output, and you go backwards as far as you can in the chain
-
knaccc
so did it reference any outputs, and did those outputs reference outputs, etc
-
sgp_
ah, I read it that way anyway haha
-
knaccc
one aspect of this proposal, the instant-on, hasn't been commented on: which is whether there is acceptance that monero will hit a wall if it gets 10x the daily tx volume or beyond, because people simply are not going to want to wait 12 hours to sync their wallet each time they start it, and it'll be too much of a hassle to use
-
knaccc
instant-on would be transformative for monero
-
real_or_random
sarang: is that relevant to monero (e.g. for checking incoming txs)?
twitter.com/hashbreaker/status/1282300847607578625
-
sgp_
knaccc: instant-on?
-
real_or_random
ah no, probably not
-
real_or_random
hm
-
real_or_random
not sure, I don't know remember how this this works in monero :D
-
knaccc
sgp_ yeah that's one of the biggest upsides - you don't have to expensively scan the blockchain with your wallet if your incoming outputs are tagged with subaddress hashes. so monero wallets can be instant-on, like electrum
-
knaccc
if you didn't know about the instant-on thing, maybe you didn't see the github mrl issue?
-
hyc
which issue?
-
hyc
if you can tag outputs, can you tag them with amount encrypted by viewkey, so that view-only wallets can see outgoing txn amounts?
-
knaccc
hyc this one, with the diagram explaining iterated-eabe
monero-project/research-lab #75
-
sgp_
knaccc: I've just had a super busy weekend buying a car and moving haha
-
knaccc
oh nice, porsche?
-
sgp_
Lmao nah, Kia Forte
-
hyc
lambo or get out
-
knaccc
actually that forte looks pretty nice
-
knaccc
hyc the purpose of tagging is so that other people can correlate outputs as being owned by the same subaddress
-
knaccc
but sure, you could tag with other stuff too
-
knaccc
the main thing is you can't rely on a thief tagging it, in order to notice the theft
-
knaccc
which is why i think people have not considered something like what you propose
-
hyc
it can be forced by consensus
-
hyc
if the tag is missing or incorrect, reject the tx
-
sarang
The network can't enforce encryption with a key it doesn't know
-
sarang
It can certainly require a tag be present
-
gingeropolous
well, instant on if there's a server doin the work for yah
-
hyc
still not instant-on, you still need to scan all the blocks that are newer than the last time you were online
-
hyc
you're just making the output detection operation faster
-
sgp_
yeah afaict "instant-on" is a little bold (maybe it's fine for marketing), but faster is better :)
-
hyc
hard to say that it will be a noticeable improvement for majority of users
-
hyc
everyone with compute access has cheap access to relatively fast CPUs
-
hyc
they don't all necessarily have access to fast internet
-
hyc
the block scan may not be improved at all, if the network was the bottleneck
-
hyc
and frankly, making outputs readily identifiable to 3rd parties seems insane
-
sgp_
I agree on the limitations part, but in my experience CPU has always been the bottleneck for syncing
-
sgp_
maybe that isn't the case on some high-end desktop CPUs
-
hyc
syncing daemon or wallet?
-
sgp_
you're right I was thinking daemon, but I also think this applies for wallet sync? I'm only 75% sure about that one
-
moneromooo
knaccc wanted to have the wallet tell the daemon "gimme outputs with a tag in the following list".
-
moneromooo
So the daemon would do the work. And be able to tell even more about the wallet.
-
moneromooo
And you know people would also trust a stranger's daemon for this.
-
hyc
ohh, didn't realize he moved the entire scan to daemon side
-
hyc
that's also nuts
-
moneromooo
Not the scan, just a preliminary filter. Also asking for tags that are not yours.
-
hyc
sorry I can't believe anyone is giving serious consideration to any of this
-
sgp_
hyc: I think the tradeoffs are too significant personally
-
sarang
OK, back from my appointment
-
sarang
Hooray for healthy eyes
-
sarang
Boo for those eye drops
-
hyc
even the notion of using a 32bit hash as the tag. so you collapse the 128bit key space down to 32 bits. that helps attackers as much as it helps legit wallet owners
-
knaccc
hyc i don't think there is an attack on 32-bit hashes that wouldn't also apply to 512-bit hashes. re: scanning, the daemon would provide a bloom filter to the client. the client then knows which blocks it needs to request, and will over-sample blocks to avoid giving too much away
-
knaccc
but you could, of course, also request all blocks. and you'd have no CPU problem
-
knaccc
i don't see how monero can survive if tx volume goes up my more than 10x
-
knaccc
syncing a wallet takes forever if you don't leave it running all the time
-
selsta
do you mean with a remote node?
-
knaccc
yes, nodes will provide bloom filters to anyone that asks
-
selsta
because it doesn’t take too long when using a local node IMO
-
moneromooo
Did you not have an idea about the sender brute forcing keys so the prefix/suffix could be used to discard 1/256 of incoming outputs ?
-
moneromooo
255/256
-
knaccc
mooo i had an unworkable variant of that years ago, UkoeHB_ had a working one recently
-
knaccc
but that discards 255/256 of scalarmultbases
-
knaccc
you still always have to do the first variable-base scalarmult
-
moneromooo
It seems plausible that one could skip outputs outright.
-
knaccc
moneromooo i'm not sure i understand that sentence
-
moneromooo
Why do you need to do a scalarmult in the first place ?
-
knaccc
so that only the recipient knows the tx is for them
-
moneromooo
Why does "so that only the recipient knows the tx is for them" imply "have to do the first variable-base scalarmult" ?
-
knaccc
they could be advised of the location of the received funds out-of-band
-
knaccc
but if it has to be done within the blockchain, there have been no alternative ways found, so far
-
moneromooo
If the key prefix is set to, say, the first byte of some data in the tx prefix encrypted with the destination subaddress' pubkey. Nobody knows that except sender and recipient.
-
luigi1111w
anyone with that address would be able to decrypt
-
moneromooo
Ah, but the recipient still has to encrypt tht.
-
moneromooo
Yes, and that's only sender and recipient ideally :)
-
luigi1111w
sure but that's knaccc's idea I think
-
luigi1111w
using the public address
-
luigi1111w
(this is not like rsa public key encryption at all)
-
moneromooo
Hmm. Alright.
-
knaccc
moneromooo so yes, the subaddress-hash proposal effectively means that only the holder of the destination address can know if an output was destined for that address
-
knaccc
and if it's one subaddress given out to each sender, that does preserve privacy
-
luigi1111w
if you have end to end encryption on the out of band communication, etc etc
-
knaccc
right
-
knaccc
hyc don't get me wrong, i'd be horrified if everyone just said it was a great idea and started coding it. it will take a lot of thinking about. i'm just trying to spark some ideas, and at least get consensus over the severity of intersection attacks that make a mockery of untraceability, and of the wall we'll hit one day with tx volume
-
moneromooo
Hmm. What would you say if I'd started coding it...
-
hyc
you'll get my attention when it's deployed on the mooonero testnet
-
sarang
Updated version of FROST, the threshold signature construction from Zcash Foundation research:
eprint.iacr.org/2020/852
-
knaccc
haha genuis reverse psychology my mooo. i retract everything!
-
moneromooo
I didn't.
-
knaccc
by* mooo
-
knaccc
i really do think i'm at least onto something though, about the correct unit of anonymity perhaps needing to be wallet-level rather than transaction-level, due to the intersection attack
-
sarang
It's certainly an interesting way to look at the "level" of anonyimity
-
hyc
I suppose it was wallet-level before the intrduction of subaddresses
-
tevador
wallet sync is not that slow, I did a rescan of 3 years of transactions in about 20 minutes yesterday
-
knaccc
hyc what i mean is that even prior to subaddresses, the anonymity set of each transaction was considered separately from the anonymity set of any other transaction made. so the change in thinking would be to start choosing decoys patterns across all transactions, rather than per-transaction.
-
UkoeHB_
not sure if this has been mentioned, but it seems like a malicious actor could inject outputs with fake subaddress tags to pollute specific individuals' rings