jules | reality bender

This is happening. A special edition of Zcash Office Hours where we try to prove the null hypothesis by looking through the Zcash Orchard codebase for the supposed backdoor. @shieldedmark @colludingnode There is No Orchard Backdoor May 26, 3pm UTC Zcash Global Discord RSVP: luma.com/71d8jo7c

x.com/i/article/2058…

Discussion continued on post-quantum encryption for Jamtis addressing. tevador confirmed he is continuing with AC1024 as discussed in the previous meeting. rucknium shared thoughts on optional interactive address protocols to address merchant UX/DX concerns with non-interactive "push" cryptocurrency transactions versus the traditional "pull" model of digital fiat payments, while stressing that non-interactive transfers and passive donation addresses (e.g. kuno, CCS, xmrchat) must remain supported. This led to extended discussion of spirobel’s scan-reduction proposal using ECDH-derived secrets (replacing dummy payment IDs) and comparisons to current subaddress and Jamtis approaches. rucknium: 3. Post-quantum encryption (#issuecomment-4412416686" target="_blank" rel="nofollow noopener">github.com/monero-project…). tevador: I have no updates, I'm still going with AC1024 as discussed in the last meeting. I can answer questions if needed. rucknium: I thought more about having an interactive address option. I think some merchants have problems with non-interactive txs. Or you could say that they are accustomed to the "pull" procedure of digital fiat payments, but cryptocurrency txs are "push". In previous research, I found this set of complaints about accepting cryptocurrency. It says that small underpayments were a problem: blog.shodan.io/accepting-cryp… rucknium: Just some thoughts on UX. Or DX (developer experience) maybe. rucknium: ^ AFAIK, that site blocks Tor. And I cannot get archive.org to work right now :( tevador: I think that interactive transactions could be an option, but not the only option. There are use cases for non-interactive transfers. rucknium: That reminds me that the Tor Project is running a cryptocurrency donation campaign for some internet privacy tools, including ones that are useful for research. I used OnionShare to collect user-submitted monerod logs, for example. The donation link appears in the blank page of the newest version of Tor Browser: internetfreedom.torproject.org rucknium: They accept XMR. Donations are being matched by Cake Wallet and Zcash Community Grants, plus some smaller donors. rucknium: tevador: I agree. Not the only option. I just wanted to say that an optional interactive protocol could have some UX/DX advantages. tevador: Yes, I'm still planning to include an interactive protocol in the appendix of Jamtis. tevador: In response to spirobel, for point 2, you cannot just pretend that passively posted donation addresses don't exist. They do and we are not going to discontinue that use case. tevador: This is a response to: #c677589" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc… rucknium: Here was point 2: > 2.the one-to-many "donation address" use case: > for this case the status quo is that we have systems like kuno, ccs, xmrchat. > there is a need for the group to see a donation counter go up. > people don't donate to passively posted donation addresses where nothing happens after the transaction was sent. > so in any case where donations are successfully collected, > the information how many donations happened to this address is public in any case. > this still doesn't mean the receiver needs to be online at the same time. > strictly speaking the service to record the received transactions just needs to be able to receive messages, > with similar ergonomics to smtp relays. > in practice as we see, there is a hosted service with a donation progress bar in any case, > so this service might just act like a checkout and in practice this falls back to the one-to-one case, > as the donation checkout page generates a unique address for each donation attempt. sgp_: I agree passive donation addresses are important rucknium: More discussion about PQ addressing? spirobel: tevador: just to clarify: i am not for discontinuing the use case. its just that if someone wants this functionality, they have to continue to scan the whole chain. also again: my suggestion is non interactive. spirobel: regarding the PQ addressing small addition: it would be good to have it as a separate document from jamtis and it shouldnt take up most of the space regarding addressing design choices. the discussion should be more focused on ux problems in the real world and how we can reduce scan time. > rucknium: More discussion about PQ addressing? jpk68: spirobel: Why shift the focus even further away from the non-interactive side of the protocol? This seems like a needlessly large UX change with no apparent benefit spirobel: jpk68: i clarified earlier my approach is non interactive. further context: #m" target="_blank" rel="nofollow noopener">xcancel.com/spirobel/statu… and two more MRL messages ... spirobel: jpk68: mrelay.p2pool.observer/e/gIrIw4QLRzMz… maybe i should turn this whole thing into a gist ... just to be clear i dont like interactive protocols ... where both parties have to be online at the same time. spirobel: jpk68: the apparent benefit is that you dont have to sync wallets anymore. tevador: spirobel: Your twitter post is too vague to properly judge the proposal. You should post a more detailed write-up, with all the keys and derivations, what constitutes an address, what is included on-chain and what must be shared off-chain. tevador: I'm suspecting that in the process of writing it down, you will identify several issues. spirobel: tevador it is good enough to judge the core idea. no i don't think there is an issue with this. its a fairly clear idea spirobel: i will turn it into gist when i have more time tevador: It's not clear to me. One paragraph says the sender includes an index verbatim, one paragraph says the sender increments an index and one paragraph says the sender fills part of the index with random data. spirobel: or write a prototype ... do a kdf on the wallet seed and put it into the address ... put the secret into the place where the dummy payment id is now spirobel: then only scan transactions that contain this secret in the dummy id tevador: But that's a serious privacy regression. Any external observer can see the same pid repeating and can conclude that those two outputs are owned by the same party. spirobel: tevador ... yes because this works for only one tx, so after that this secret index needs to be incremented tevador: That doesn't solve anything, the external observer can identify (pid, pid+1) just as easily as (pid, pid) spirobel: no it cant. because after the initial transaction the channel is open and we can obviously "increment" it in away the channel observer wont know tevador: Ah, so your proposal requires a secret channel between the sender and receiver. OK, in that case we don't actually need addresses, the receiver can just construct their own outputs every time. spirobel: and the point is: you find the channel opening ... and then you can find all others ... that where sent with this participant spirobel: no wallet syncing anymore spirobel: and just to be clear: by channel i mean this in the simplest way, just some ecdh with the viewkey in the address and just say: this is the next secret for the next transaction. then you can find it as easily as the first but the observer wont know. thats what i mean by increment spirobel: used the word channel because i had hedy lamarrs frequency hoping technique in mind, but its not some interactive off chain connection spirobel: so you can reconstruct the first secret from seed and you get all the others afterwards as the next "index" is always embedded in encrypted form in the transaction tevador: Does it allow for stateless address generation? Probably not. You'd have to keep track of issued 'view keys' and never reuse the same key for two recipients (even if they don't send you anything). And you still have to scan, at least for the first transaction in every channel. spirobel: do subaddresses allow for stateless address generation? no we increment the subaddress index. " never reuse the same key for two recipients " exactly what we recommend now for subaddresses ... tevador: Jamtis does allow for stateless address generation. spirobel: and scanning for open channels: no. the expensive part is the cpu work ... and even if we were to still to do all the network fetching (which is not necessary, as this secret is similar to a txhash an "index" in the sense of a database index, so we can retrieve just what we want. its just a matter of in the case of remote nodes to obscure it... but that is a minor detail that can be worked out ... tevador: It could probably work if the channel opening transaction included the original index. But at least the sender is always stateful. If they ever forget how many transactions they have sent, repeated 'view tags' will appear in the blockchain. tevador: spirobel: you can't have stateless address generation that supports "index lookup" because you don't know which addresses exist. spirobel: yes i dont see statefulness as a big issue. wallets have to do this in practice. statefulness is cheap compared to having to scan every single transaction everyone is sending all the time spirobel: and also for logical reasons: if you want to compartmentalize your identity you have to make different identifiers for the people you interact with in any case tevador: Stateful addresses get you issues like this: github.com/monero-project… spirobel: but that is an engineering issue. because wallet2.cpp sometimes left gaps ... in my wallet library i increment the index for every address generated tevador: And how do you know the value of the index when restoring from a seed? spirobel: this whole lookahead thing is clunky ... also statelessness is not worth the price ... we can literally do away with scanning entirely ... which is a much practical step towards scaling than something like tachyon (which needs to update a proof constantly to be able to spend, different topic, but shows the different directions here ...) spirobel: "And how do you know the value of the index when restoring from a seed?" you would know how many addresses you generated ... you can easily just make 100000. just call the kdf make the secret ask the node if there where txs for these ... just a database lookup spirobel: and the incremented indeces per participant only come into play if a tx was found ... if that is the case its easy ... because the info is in the tx #c677826" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

@gainzy222 Rail not zec