00:07:20 thanks, I don't really understand what I'm meant to put in the "block_ids" field of the /get_blocks.bin RPC method? 00:10:20 You might not want to use that function, but... last block hash you have, the block hash you have that's 2 from the toip, the pone 4 from the top, the one 8 from hte top, etc. Last is the genesis block if you've not included it already. 00:10:57 This is so the daemon can know where to send from without the client sending everything it has. 00:12:53 Yeah the non-json rpc end points aren't as dev friendly as the json rpc ones, but none of them really provide offset information right? 00:13:48 I just cheked, get_transactions does. 00:15:08 I sorry I meant like get which transactions are referenced by the offsets 00:15:46 there's the /get_outs method but the txid it returns is unfortunately empty... 00:29:31 Did you set get_txid to true ? 00:34:19 no I did not, thanks so much for the tip! That works, that should really be in the documentation 11:20:28 Does Monero have such things as Monero improvement proposals? 11:23:46 We don't have a structured proposal system like the BIP, but anybody is welcome to make proposals and suggest improvements 11:23:54 If it's cryptography, you can file a bug in the monero-research-lab repo and talk about it in #monero-=research-lab. Otherwise, in the monero repo and here. 11:24:26 Alright 14:54:08 I drafted up a small whitepaper about how Monero could extend transactions to not only allow atomic swaps but also more versatile transactions likely without significantly impacting privacy, I have it as a pdf what would be the best way to share it and does anyone want to read it? 14:57:33 Put it on github and link it here ? 15:06:21 I'd love to read it, philogy 15:10:00 https://github.com/philogy/revokable-branched-outputs Tell me what you think! The idea is relatively simple so I wouldn't be surprised if somebody has already had it 15:41:15 If you'd like to give your feedback I'd recommend the reddit thread as your comments will be more permanent there: https://www.reddit.com/r/Monero/comments/gye8cq/revokable_branched_outputs_atomic_swaps_complex/ 15:44:24 philogy: Can you perhaps also open a new issue on the Monero Research Lab Github repository? 15:44:38 Reddit is kind of bad for looking up historical threads 15:44:44 And threads quickly disappear from the front page 15:44:50 here: https://github.com/monero-project/research-lab/issues 15:45:08 Ok 15:51:09 not sure I understand section 3.2, are you implying `s` would be published before one of the outputs is spent? in that case, some malicious party could steal `s`, make their own revokable outputs, then spend one of them - thereby producing `KI_s` and locking the original outputs forever; to get around that you'd need to mandate unique `k^s*G` keys (e.g. can only appear in a given transaction) 15:53:17 Yes I'm implying it would be published before being spent. That's why I added in the Mechanisms section (1.6) that no transaction may reuse an sG insuring that nobody is able to maliciously lock that transaction. 15:53:34 ah missed that 15:56:42 there don't seem to by any serious problems, although you probably should add a Schnorr signature on the commitment to zero between the revokable output pair; the range proof would only use one of the revokables 15:58:49 what do you mean? 15:59:07 so the total cost for [normal output] -> [revokable pair] would be: 1 more output (+ scan time), 1 EC point for the revokable key (can just point it at a given output, which needs at most 1 byte), 1 Schnorr proof 15:59:42 "the sum of outputs may be greater than inputs" only makes sense with an additional proof 16:00:32 the output commitments for the revokable pair can't be the same since the blinding factor is deterministic from the sender-receiver shared secret 16:02:07 couldn't you reuse the commitment for outputs that use the same revocation key? 16:05:15 yes you could, although you'd have to encode the blinding factor for both recipients (the method from pre-RCTTypeBulletproof2) 16:08:05 so the cost difference would be: [2x encoded blinding factors = 64 bytes + extra implementation effort and complexity] vs [1 extra commitment + 48-byte Schnorr signature = 80 bytes] 16:09:10 Ah wait: you could leave the same blinding factor derivation as it is currently you just count outputs that have the same revocation key as having the same index t. 16:09:54 the recipient view keys are likely to be different, so even with the same index the shared secret changes 16:10:33 plus the tx pub keys may be different 16:10:38 Oh yeah I forgot about that... 16:15:04 interesting idea thanks philogy 16:17:06 thanks to you too, I mean there's some still kinks to work out but it could be pretty useful right? 16:19:17 quite possibly; there has been a general struggle to find a good use for timelocks, which this could address 16:21:18 On a totally separate note would it be possible to hide timelocks? Like you commit to the timelock somehow and when you want to spend the transaction you somehow do a zero knowledge proof that the current time is equal to or greater than the commited lock time? 16:24:23 Yes 16:24:35 You can embed this inside signatures 16:24:47 But it has a nontrivial computational cost 16:26:00 Interesting. 16:26:52 philogy: https://github.com/monero-project/research-lab/issues/65 16:30:01 There's example code as well for the underlying signature modifications 16:40:45 There's a thing I don't understand about MLSAG ring signatures why is the [rG + cK] term necessary? isn't [rH(K) + cK~] enough? Where can I see the code? 16:42:19 UkoeHB_: I think I have a solution for the commitment mask problem instead of yt = Hn(“commitment mask”, Hn(rKv B, t)) simply do yt = Hn(“commitment mask”, Hn(sKv B, t)). For normal transactions that don't require revocation simply do r = s 16:58:57 the `[rG + cK]` component means you know the private key `k` in `K`, while `[rH(K) + cK~]`means you know the private key `k` in key image `KI`; placing them next to each other proves that `k` is the same in both cases (recall Section 3.1 from ZtM2, on proving knowledge of a discrete log across multiple bases) 17:02:02 philogy: if `s` is made public then someone could brute force the amount, since it's only 8 bytes (e.g. figure out `a*H = C - Hn(sKv, t)*G` then brute force `a` by guess-and-check) 17:11:09 You're right, I'll keep thinking 18:49:53 UkoeHB_: instead of publishing publicly the actual private revocation key s, revealing the amount in an atomic swap a type of diffiehellman exchange is done: 18:49:53 Bob (has btc wants xmr); Mary (has xmr wants btc) 18:49:53 Bob: generates random db (sends it securely to Mary) 18:49:53 Mary: generates random dm (keeps it to herself) 18:49:53 Mary: s = dm * db 18:49:54 Mary: creates a transaction with revocation public key sG; with the timelocked output to herself and the normal output to Bob 18:49:54 Mary: Qm = dm * G 18:49:55 Mary: sends Qm to Bob 18:49:55 Bob: verifies that db * Qm = sG 18:49:56 Bob: creates a locking script as specified based on Qm where dm unlocks it 18:49:56 Mary: unlocks the script and redeems her bitcoin using dm 18:49:57 Bob: can unlock his monero using s because (s = dm * db) 19:24:25 philogy: it makes sense to me 20:22:26 Is it possible that malicious remote nodes feed empty blocks to the wallet? 20:35:29 wouldn't the hash be invalid if they took the transactions out of it?