03:15:52 where are the debug logs usually stored 03:17:46 ~/.bitmonero/bitmonero.log 03:18:11 Obviously if you set a different data directory, it'll be there. 18:19:33 do 0-amount outputs have dummy one-time addresses, or are they considered `change' outputs directed to your address? This guy on reddit has an interesting idea https://www.reddit.com/r/Monero/comments/ev8be7/can_we_get_sweep_all_to_return_0_xmr_back_to_the/ 18:22:18 also wondering, when proving you authored a transaction and the transaction has more than one transaction public key, is the message you sign using ALL the pub keys, or just one of them? or am I misunderstanding how that proof is done? 18:24:04 You mean the two-key Schnorr proof? 18:24:25 It's done on a single shared-secret/tx-pubkey combination at a time 20:46:44 Hi, I'm updating pages on monero outreach and I'm looking for info on planned work in 2020. Can anyone help? 20:47:12 dEBRUYNE mentioned that a random address is used when sending 0-amount dummy outputs (e.g. since there is a 2-output minimum). Where might I find this in the code base? 20:50:48 hwgttm as far as the protocol goes afaik now much is nailed down, although there are many items that need discussion on my list. Only thing for sure is enforcing exact block rewards (miners are currently allowed to accept less than maximum amount, although not one block has done so in years) 20:50:56 not much* 20:57:02 nvm lucky find in transfer_selected_rct() 20:58:21 There has been good support for getting CLSAG deployed 20:58:33 It's already coded 21:15:57 Thanks for your reply koe 21:24:27 Suppose we had 64 bytes of free space available in each transaction... what would be useful to include? 21:26:25 I mention this because bulletproofs can be used to store 2 proof elements arbitrarily, given a PRNG seed 21:29:58 what would you even want to include? 21:34:43 That's why I'm asking :) 21:44:23 can someone help me understand what destination_split_strategy() is? Im very concerned that destinations are being sorted in a predictable manner 21:46:21 which has serious implications for heuristics around which output is the change output for most transactions 21:46:41 It's obsolete (pre rct). 21:47:06 May still be used when sending unmixable outs though. 21:47:28 It's not consensus, so feel free to change the sorting. 21:47:53 sarang: whatever makes second layer easier :) 21:48:15 problem is I cant track down how the original list of output addresses is created 21:48:30 or if it gets rearranged between then and when the output index is assigned 21:51:29 sd.splitted_dsts seems to be the list that gets passed into the index assignment (it just uses the order of sd.splitted_dsts directly) 21:53:48 ok transfer_selected_rct() apparently puts change address (or dummy address for 0-amount) on the end of the list ;( 21:57:39 You could check some of your own txes for easy falsification :) 22:04:24 moneromooo: anything not second-layer related? 22:04:25 hehe 22:04:38 It's 64 bytes per bulletproof, not per output, FWIW 22:06:22 er, actually 32 bytes, sorry 22:06:28 could make it a hash of something, then add the fee to it 22:06:33 Can't do 64 bytes without knowledge of mask 22:06:33 couple bytes saved! 22:06:40 What next ? 32 bits ? 22:06:47 lol 22:07:05 Does DLSAG have something that could use it ? 22:11:04 well even if it is random I want some reference to the code, so have to track it down either way 22:11:43 construct_tx_something shuffles, if it's told to. You'd have to check the relevant calls do. 22:12:36 The non shuffling case is for multiisg IIRC, where followup signers have to use the same order. 22:15:35 yay found it in construct_tx_with_tx_key()! 22:15:40 thanks mooo :) 22:16:53 very good news lol i was a bit worried '=D 22:21:34 quick random question: how hard would it be, from a coding perspective, to implement a method that could be called on the wallet to tell it to recognize ownership of a particular output (you'd either supply the output private key for full ownership, or supply the per-output shared secret for view-only 'ownership') 22:22:08 just wondering if the wallet data structures are set up to easily accomodate that 22:22:12 sarang fee is usually 4-5 bytes from what I can tell, and the transaction type is 1 byte, could put both in your extra scalar 22:23:25 It would suck to waste a perfectly good hidden 32 byte value for those things. 22:24:08 knaccc: annoying. 22:24:17 moneromooo cool thanks 22:25:20 could make it the janus mitigation base public key, although I'm hoping when janus is added that it's randomly indexed in the pub key list, which would be helpful for a join protocol 22:25:33 sarang those bulletproofs are prunable, right? 22:25:41 so it'd have to be data you wouldn't mind being pruned 22:28:15 could use it for the return address scheme 22:30:18 i.e. this https://github.com/monero-project/research-lab/issues/53 22:30:36 Why can you give it just that info ? 22:31:02 moneromooo you talking to me? not sure i understand the question 22:31:29 Yes. I'm asking for the reason(s) why you could give it only output private key and per-output shared secret. 22:31:52 it being the wallet here. 22:31:58 moneromooo oh right, i'm imagining the following scenario: 22:34:45 you create a subaddress, but issue it as a regular address instead of as a subaddress. that means you have a one-time view key c which you can give out to a scanning service, in order to scan for only an incoming payment to that address for a limited period of time (e.g. 5-30 mins). that service then does a callback to the web app to let it know if a payment was successfully recevied. only a one-time view 22:34:47 key is shared, so no privacy loss. but this would require the merchant wallet to be notified of an output it now owns, which it needs to be told where to look for. i guess the wallet could simply be told an alternate view key to be used for scanning just a single particular transaction with, to achieve the same result 22:35:33 it means simple web apps that can privately accept incoming payments without giving away the full view key and without running wallet infrastructure locally 22:37:22 Note that the BP data thing was introduced in the context of rewinding for witness extraction (Mimblewimble etc.), so I need to make sure it's safe to include this 22:37:46 But it would be nice to get 32 bytes in this way (you'd have to run the BP verification to get this data, though) 22:38:25 it's very elegant how in MW the bulletproof is used to allow wallet restoration, and it works perfectly because you don't need to know how to recover an output if it has been spent and the bulletproof thus pruned 22:40:33 And what is the reason you can't get other info ? 22:41:18 moneromooo oh the txid or output global index etc would be easily told to it as well, if that's what you mean 22:42:25 Could you give it anything the wallet would normally get (like, the whole tx, say) ? 22:43:13 sure 22:44:12 Then it becomes much less annoying. 22:45:15 how does the wallet know the private key for an output when it's time to spend it? does it calculate it just-in-time? or is the output private key calculated once during scanning, and then stored in wallet data files? 22:47:40 It is calculated during scanning, if it's not view only. 22:47:52 If view only, when it imports the data from the other wallet. 22:48:05 If multisig... hairily. 22:50:09 moneromooo oh nice, so if the wallet is storing global output index + output private key + output shared secret for later reference when spending, then that sounds like it would be easy to inject other outputs into that list that the wallet didn't scan for itself 23:06:59 knacc wouldn't that one time view key compromise your spend key if they got a hold of your normal address view key somehow? would work if the subaddress index was a random huge number 23:43:28 koe yeah you're right, that is a flaw. these are very early random thoughts, thanks for spotting that 23:43:59 there are other ways to do it, other than literally creating a subaddress the usual way 23:44:08 it could literally be via multiple seeds instead 23:44:14 and that would solve the problem 23:45:45 so you'd just do Hs(b||i) to get multiple seeds for one-time receiving addresses 23:46:12 and Hs(Hs(b||i)) for the one-time private view key 23:46:33 looking at how owned outputs are selected to be spent, and it seems highly random although the selection process is quite intricate; is there any risk of assigning heuristics to the order of inputs? e.g. lower indexed inputs are more likely to be larger amounts? moneromooo 23:47:59 For your own ? I don't think so. 23:48:10 Ceteris paribus anyway. 23:48:18 I say that and immediately find "// sort ins by their key image" 23:48:25 IIRC the pick is equiprobable within a correlation class. 23:48:59 Correlation class being "same block", "within 10 blocks" and "other", I believe. 23:49:25 That comment is about sorting rings, IIRC. 23:50:35 Oh I had misread, I thouht you meant larger heights, not amounts. 23:51:11 ah that's relevant too, sounds good! 23:51:31 devil is in the details, and it's devilishly complex! 23:53:30 Theree is a first pass on selection where it'll try to get any two inputs that are enough to cover fee+outputs. That one is deterministic.