I think if the host is contacted over i2P or Tor then input/output groupings can be hidden to some extend. There is still risk of MitM

although MitM would be really hard to pull off

basically without IP logs then the protocol as it currently stands can be hosted just fine, assuming MitM is difficult and unlikely

such a service could participate as an output in each hosted join, basically requiring the other participants to pay the service some tiny amount

that way no need to set up accounts or anything

was there discussion about knaccc 's refund address scheme?

koe i think the main hurdle was deciding whether any kind of refund address scheme is a good idea. now that it might be almost-free, the question still remains over whether it's useful or a good idea or not

almost free?

well 32 bytes for free from the bulletproof storage, but it needs a few bits extra on top of that to

too*

i can quite easily see that there may be a much stronger case for using that free storage for a general-purpose encrypted memo field

it's 32 bytes for a 2-out tx, so that'll all be free storage in the bulletproof, but if there are >=3 outputs you need to also store in txextra ceil(num_outputs*ceil(log2(num_outputs))/8) bytes

ah ok

I wonder about pruning.. seems a pernicious roadblock to using that free scalar

you could argue that the refund address is only really useful for a short period after the tx is received, so only useful anyway when within the pruning window

but then, there is a good chance i've not thought through all the return address use cases

and by "good", i mean 100% :)

how wide is the pruning window?

are refund addresses needed for payment channels etc?

i'm not sure

to either of your questions

in any case it's an interesting scheme, well designed

heh thanks, yeah it went through more than 10 iterations to get there, with the help of people in mrl to keep bouncing ideas off

I really like the blog post about supply auditability. this term comes up so often and it's not clear at all what this even means

Thanks real_or_random

knaccc: can't safely store it in the bulletproof if the recipient is to be able to access it

the recipient could use that information to brute-force the amount of the output it doesn't control

gingeropolous: some method of effective refund (ideally non-interactive)

anyone knows whether @atoc will be around today? wanted to talk xmr-btc atomic swaps to her//him

Backlog shows atoc is around every few days, so I expect it to continue.

zkao[m]: anything of interest to the channel about the swap protocol?

sarang: we put a video up of petrinet exectutions of the protocol. it can be found here: open.tube/videos/watch/515a1dc7-978c-44e3-b9fd-42a380a949ca

and i wanted to clear out that there's already some initial code for implementing it: github.com/h4sh3d/monero-swap-lib

What's used for the preimage proof?

sarang: nothing, its not done. thats is what @atoc should work on

Got it, thanks

I'm very much in favor of return addresses, with a few considerations to prevent privacy concessions:

(most or all of which have been discussed previously)

1) Encrypt them, to prevent dusting.

2) Required in every transaction by consensus, to prevent fingerprinting and not create a new anonymity partition for transaction linking.

3) Sender can put dummy return address to avoid mandated bidirectionality.

#3 is a freebie, could encrypt 0s, stick in a random number, or encrypt the *recipient's* address for the "return" address

This is a builbing block for second layer stuff, right ?

Interactive refunds require user action

What I mean is, is this just for the case where Alice might want to send money back, or is there something actually useful behind it :)

Or is the sending money back actually common without second layer, because I can't imagine it is.

I kinda remember this being mentioned about second layer, but I thought I'd make sure.

And wasting space just for a corner case seems unwanted.

I'd much rather spend the space on something of general interest.

(and a building block for some second layer would definitely be)

as a general rule, btc doesn't really have return addresses either

so any use case would have to be either a building block that is specific to xmr, or outside of how people generally use btc today

Brief writeup describing Janus mitigation (with simple code example): github.com/SarangNoether/skunkworks/tree/janus

The mitigation requires a single fixed-base tx public key per tx private key used in the transaction

So this plays into the "how many pubkeys do we have?" game

sarang can you add a note that subaddress recipients may share a transaction private key, so there should never need to be more than one extra `base' key per transaction

Sure

What cases, if any, exist where multiple tx privkeys are present?

otherwise looks really good, can you make a repo issue recommending the change?

any time at least one subaddress exists (excluding cases: 2-output with non-change to subaddress, 1-subaddress and it's the change output)

currently when there is at least one subaddress, every single recipient gets their own tx pub key

Right, but I mean for private keys (`r` in the notation of the writeup)

Ignoring all the cases of identifying which keys to use, the mitigation is technically per-privkey

"every single recipient gets their own tx pub key" -> "every single recipient gets their own tx private key"

OK, so when you say "may share a transaction private key", this is not done by default

construct_tx_and_get_tx_key() creates all the private keys; that's right

noted

Would this not reveal whether a single subaddress was used in multiple outputs of the same transaction?

It would yield identical tx pubkeys

ah indeed

If size were not an issue, it'd be great to have all separate pubkeys and "mitigation points"

I am concerned the cost of mitigation will be too high if we need an additional pub key for every output

Right, size is an issue

Of course, there could be a wallet/consensus check for repeated pubkeys that indicate a repeated address

I think there needs to be better agreement on how to handle these cases before making concrete suggestions about Janus mitigation implementation

there may be a way lemmee see

Even having a designated single "mitigation point" with individual pubkeys derived from a single privkey is problematic, since the mitigation point would be identical to any pubkeys for standard addresses

and this would leak the number of subaddresses again!

"Of course, there could be a wallet/consensus check for repeated pubkeys that indicate a repeated address"

Wait, nevermind

That wouldn't apply if there was a single privkey

Since all standard-address outputs would share identical pubkeys

Using separate independent privkeys for all outputs removes the problem, but then introduces the new problem of size bloat

there will this work?

since you need separate tx pubkeys _and_ separate mitigation points

plz explain

(I get the notation from ZtM, just want to confirm what the resulting values correspond to!)

basically make the tx private key a sum of base private key and hash of base pub key with output index; will be different for each index, but can be reconstructed for janus mitigation

using just the one base key

even if repeat of same subaddress recipient

gotta afk lmk if it works

Popping in just to say that all non-subaddress tx pub keys would be random. Only shared secret (with subaddy spend key) would use the constructed private key

Distribution of output count since 1978433 (last update, banning 1OTXs)

What's up with the 11-spike?

Uh I stopped paying for irccloud but apparently my account still works ??

There's a free version that only keeps you logged in for something like 2 days

Oh

Maybe it reverted to that

It shows you just joined the channel before writing

Guess I'll suck it up for the 5$ 😭

what an odd spike

The distribution between 3 and 10 was a bit unexpected to me

Pools I'd suspect.

Probably

I'd bet that most of the >2 is pool activity

supportxmr.com has a list of all our payout counts, it's +1 output of course due to the pool being it's own payee

We send bunches of 16 output txns every hour, then it's weird straggler counts for whoever we can't jam into the main groupings.

10 outputs I think is the old pool with it's hard-limit to the number of outputs for when they were larger, and you couldn't jam as many outputs into a single txn.

That makes sense

Though straggler transaction would have count (# of users mod 16), which would be evenly distributed across the range. So it doesn't totally explain the 'decay'-ish trend

No reason for even distribution.

Assuming that it's fully random, sure, but pools have a sort of interesting thing, where there's a small number of users that get paid out highly reuglarly, then it's one-two offs from there.

Aw geez at some point I need to take 2 months off and deep dive into pool mechanics

Just ping me and ask.

It's probally way faster. :P

Always appreciate your input and insights :- )

I'd also suggest raiding SXMR's API

Oooh I'll check that out

There /used/ to be network docs, but the provider I was using went away. However, there's 144k payments in our DB, with payee counts you can use to mine data about "How do pools pay out" :)

Ok shouldn't lose pms now

Snipa what do you think about using a coinjoin-like service (name now TxTangle) to collaborate with other pool(s) for purpose of hiding which pool your miners belong to?

Also is there anyone who understands networks and privacy networks that can give advice about TxTangle? I don't know the design limitations around anonymous communication

vtnerd has done a lot of research in this area

UkoeHB_ - I don't know why we'd bother honestly. Functionally, you'd have to know an address to confirm if a miner's mining at a pool or not in the first place.

UkoeHB_: is this what you intended with your idea? gist.github.com/SarangNoether/e41a760f5558cb05357d1fd6134cca07

(ignore all the revision history; it was me trying to remember how to do nested lists in Markdown)

The way I wrote it, the output and key generation is essentially identical between subaddresses and standard addresses

uses a single Janus key

etc.

Also: "The Janus Key" sounds like the title of a mystery novel

Snipa heuristics can be used to track down which pool a miner gets payed from. I expect it's fairly trivial. Say a miner deposits his earnings into an exchange without any rigorous churning. Bam, easily traced to his pool

So with this method, the Janus key is specifically identified as such in the tx data, and each output pubkey can be safely linked to its indexed public key

The cost is an indexed pubkey for all outputs, and one additional Janus key

(should be mandatory IMO to avoid obvious heuristics!)

UkoeHB_ - I suppose that's true enough, frankly, if you're going right to a exchange, I don't think you worry too much about privacy. :)

sarang using enforced sorted TLV it might be easy to start requiring things on the protocol level, like a certain size of the extra_pub_keys field

Does the gist make sense and capture the idea of what you were also thinking?

actually non-subaddress can't use the indexed version, it has to be random, since observers can trivially test it

otherwise yup!

Isthmus: besides the 11 spike, that's what I was expecting

Ah good point UkoeHB_

I had used the index method mainly for the simplicity of consistency

and the equality check would be slightly cheaper without subtracting, check if equal not subtract to zero

but the proportion of 11 and 16-out transactions, mostly related to pools, makes me think that the impact of public pool data can be quite significant....

UkoeHB_: we can do both operations cheaply, and they only apply to outputs controlled by the wallet anyway

the difference would be trivial

ok

But you are technically correct (the best kind of correct)

im thinking of the case when someone owns a bunch of outputs

If there are enough of them, you could do a delayed batched check using multiscalar multiplication

there's a factor of `lg(N)` savings for large `N`

and in that case you use the zero-sum equalities

if tx pub keys are sorted like I want, it will require testing every other pub key in the extra field

randomly sorted*

and will be even more tests if viewspent idea is implemented, or return addresses, or or or

updated gist

What's the advantage to randomizing?

versus including them directly with the associated output pubkey

with txTangle the only way to janus mitigate is using the change tx pub key as janus base key

or any other non-subaddress output from your subset of outputs

but if the base key isn't at index 0 in tx pub key list, then recipient knows its a TxTangle transaction

It would be nice to avoid testing against them all

In fact, it would be interesting to know how much scanning time is spent doing all these tests

yeah, I just don't see any way around it for TT; plus you can't enforce 1:1 correlation with outputs, so parser has to scan everything anyway in case someone implemented it weird

so better to randomize as the standard

Why can't you enforce 1:1?

If you require a separate indexed pubkey for every output

(plus separate Janus key)

well it's not verifiable

unless removed from extra field

It's not verifiable now that the tx pubkey actually corresponds to anything in the output either

it's only on a per-owned output basis, so if you own 1000 outputs it will only correspond with a few thousand blocks or less of normal scanning time, probably

It can be random, if your client is wonky or you feel like watching the world burn a little =p

I don't really like the idea of forcing extra scan time just to accommodate clients doing silly things

it's a mild form of DoS

it's 1% or less scanning time, and usually alot less unless you own TONS of outputs

1% or less of whole chain anyway

So you prefer lexicographic ordering for output pubkeys and indexed pubkeys?

(using the naming I had in the gist)

and then a separately-flagged Janus key

or just randomized, shuffled; currently they are implemented 1:1 with output index

for implementers it's easier to scan all pub keys instead of keep track of the rules around which pub key is what

marginally easier

Can't verify a shuffle

Can verify lexicographic

Less room for a bad implementation getting propagated

good point

no need to flag the janus key, just mix it in with the other pub keys

I'd rather have lexicographic for one of the sets (e.g. output pubkeys) and then a matched indexed key, but the next best thing would be lexicographic on both sets, IMO

that's the original point

no need to care about sorting if janus key is identifiable, since the point of sorting is to aid TxTangle janus mitigation

For that use case, sure, I guess

Is your idea for that TT use case limited to pool operations?

(haven't read all the scrollback)

no just one application

FYI will be away tomorrow (Friday)

sarang are you planning to make a repo issue describing Janus?

It's well known

I don't want to formally recommend a particular fix until we have a better grasp on what to do more generally about the handling of tx pubkeys

ok I can make a post about enforced sorted TLV, which is the first step in that direction; waiting on decisions about TxTangle for janus might be overkill, since TT is such a huge project (if even doable in the final analysis)

Even so, including a Janus key would require a decision about how to store it, handle it, etc.

But I agree that moving discussion forward on tx_extra handling is a good idea

hopefully once I work out TT's networking kinks and nail down other minor iterations, it can move forward as a more formal proposal that can be taken into account for other decisions like tx pub keys; it may require a very focused meeting exactly on that topic, since there is also viewspent and return address proposals that involve tx pub keys

Yep, a lot of different protocol decisions...

😈

And then there are ring signatures to consider for future protocol upgrades too...

Or rather, ring signatures / spend proofs

ok I will put some energy into organizing a focused meeting, in 1-3 weeks, since development on any of these things should start within next couple months to be on the same track with CLSAG

Wait, what do you hope to have deployed concurrently with CLSAG?

would be nice (from my pov) to have at least one other thing out of: janus mitigation, enforce sorted TLV, viewspent

IMO having mandatory Janus mitigation without a more robust handling of subaddress keys seems like a bit of a waste

robust handling?

e.g. mitigating the heuristic with tx pubkey counts etc

(which could be part of Janus mitigation, I know)

Whereas CLSAG is neatly modular

and basically done :)

pubkey counts? aside from the bug with extra key, it's two clear categories

if there are at least two non-change outputs, and at least one of them is a subaddress recipient, then #outputs == #keys (+1 due to bug); in all other cases 1 tx pub key

Or, as Isthmus would say, "anonymity pools"

do you mean deciding if all tx should have #outputs == #keys?

aye

Ill put it on the list for discussion

A takeover of the research lab!

=p

😇

-____-

"Transaction keys and you" lol what is this cheesy title :p

UkoeHB_: in a world where Triptych is used for ring signatures, a view-spent key could be included directly within the proof at no additional space cost

that's great news

Provided the sender uses a PRNG seed they (and only they) can recover, this would recover the key (or other arbitrary data) and would also leak the signing index via a brute-force recovery

(which makes it unsuitable for hiding data intended for other parties to recover)

is it a prunable part of the proof?

The recovery is done during the signature verification process

It's included as an offset to one of two proof elements that are necessary for signature verification

And because there are two such proof elements, there's still 32 bytes open

I'll note this on the github issue for ya

Seems like a perfect use for this functionality

and it's not possible for an observer to determine if such a key was included at all, since the proof elements are still uniformly distributed and verification is not affected

sweet!

Therefore, it's no additional space cost, minimal computational overhead (a couple of hash-to-fields), and no heuristics

RCT3 likely could function in this way too, FWIW

Here's the recovery process: github.com/SarangNoether/skunkworks…ch/triptych-single/triptych.py#L265

Those lines are ignored for any signature where the verifier does not suspect auxiliary data is present

The seed would be a hashed combination of wallet key, transaction information, etc. such that it's unique to the signature and known only to the signer

(but it can be anything that you can throw into a hash function)

well just hash the view key, since a viewer will know the signing index anyway (or am I speaking out my ass, cause idk anything about those protocols!)