where are the debug logs usually stored

~/.bitmonero/bitmonero.log

Obviously if you set a different data directory, it'll be there.

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 reddit.com/r/Monero/comments/ev8be7…eep_all_to_return_0_xmr_back_to_the

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?

You mean the two-key Schnorr proof?

It's done on a single shared-secret/tx-pubkey combination at a time

Hi, I'm updating pages on monero outreach and I'm looking for info on planned work in 2020. Can anyone help?

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?

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)

not much*

nvm lucky find in transfer_selected_rct()

There has been good support for getting CLSAG deployed

It's already coded

Thanks for your reply koe

Suppose we had 64 bytes of free space available in each transaction... what would be useful to include?

I mention this because bulletproofs can be used to store 2 proof elements arbitrarily, given a PRNG seed

what would you even want to include?

That's why I'm asking :)

can someone help me understand what destination_split_strategy() is? Im very concerned that destinations are being sorted in a predictable manner

which has serious implications for heuristics around which output is the change output for most transactions

It's obsolete (pre rct).

May still be used when sending unmixable outs though.

It's not consensus, so feel free to change the sorting.

sarang: whatever makes second layer easier :)

problem is I cant track down how the original list of output addresses is created

or if it gets rearranged between then and when the output index is assigned

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)

ok transfer_selected_rct() apparently puts change address (or dummy address for 0-amount) on the end of the list ;(

You could check some of your own txes for easy falsification :)

moneromooo: anything not second-layer related?

hehe

It's 64 bytes per bulletproof, not per output, FWIW

er, actually 32 bytes, sorry

could make it a hash of something, then add the fee to it

Can't do 64 bytes without knowledge of mask

couple bytes saved!

What next ? 32 bits ?

lol

Does DLSAG have something that could use it ?

well even if it is random I want some reference to the code, so have to track it down either way

construct_tx_something shuffles, if it's told to. You'd have to check the relevant calls do.

The non shuffling case is for multiisg IIRC, where followup signers have to use the same order.

yay found it in construct_tx_with_tx_key()!

thanks mooo :)

very good news lol i was a bit worried '=D

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')

just wondering if the wallet data structures are set up to easily accomodate that

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

It would suck to waste a perfectly good hidden 32 byte value for those things.

knaccc: annoying.

moneromooo cool thanks

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

sarang those bulletproofs are prunable, right?

so it'd have to be data you wouldn't mind being pruned

could use it for the return address scheme

i.e. this monero-project/research-lab #53

Why can you give it just that info ?

moneromooo you talking to me? not sure i understand the question

Yes. I'm asking for the reason(s) why you could give it only output private key and per-output shared secret.

it being the wallet here.

moneromooo oh right, i'm imagining the following scenario:

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

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

it means simple web apps that can privately accept incoming payments without giving away the full view key and without running wallet infrastructure locally

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

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)

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

And what is the reason you can't get other info ?

moneromooo oh the txid or output global index etc would be easily told to it as well, if that's what you mean

Could you give it anything the wallet would normally get (like, the whole tx, say) ?

sure

Then it becomes much less annoying.

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?

It is calculated during scanning, if it's not view only.

If view only, when it imports the data from the other wallet.

If multisig... hairily.

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

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

koe yeah you're right, that is a flaw. these are very early random thoughts, thanks for spotting that

there are other ways to do it, other than literally creating a subaddress the usual way

it could literally be via multiple seeds instead

and that would solve the problem

so you'd just do Hs(b||i) to get multiple seeds for one-time receiving addresses

and Hs(Hs(b||i)) for the one-time private view key

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

For your own ? I don't think so.

Ceteris paribus anyway.

I say that and immediately find "// sort ins by their key image"

IIRC the pick is equiprobable within a correlation class.

Correlation class being "same block", "within 10 blocks" and "other", I believe.

That comment is about sorting rings, IIRC.

Oh I had misread, I thouht you meant larger heights, not amounts.

ah that's relevant too, sounds good!

devil is in the details, and it's devilishly complex!

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.