Seems fair

A new site for sharing research papers, from JHU: acrab.isi.jhu.edu

sarang or suraeNoether what do you think about, for multisig, removing commit and reveal for marketplace escrow, where every transaction is directed to a different vendor subaddress, with change pointed at buyer subaddresses. One problem rbrunner encountered with OpenBazaar integration is requirements for offline purchases, while with

commit-and-reveal it seems impossible to do create tx without vendor sending a message to the buyer

a direct message*

ah crap nvm, the buyer has to hide the signature opener from observers anyway, so commit and reveal is unavoidable

I would need a detailed explanation of what you mean before I could possibly judge. C-and-r adds a round of interaction, no matter what there will have to be interactivity. Maybe I'm not following what you were going for

Ok while writing out an explanation I may have solved it

cliff notes

vendors publish, for each product, a list of shared secret pub keys with trusted escrow agents, along with the original pre-secret keys, in addition to a commitment to signature opening EC point

buyer declares intent to purchase by sending tx details and signature opener commitment to vendor, along with correct address for vendor to complete the 2-of-3 wallet with whatever escrow agent the buyer selected; vendor accepts the terms and sends out the product, along with his reveal of the commitment data; buyer receives product, completes his

part of signature, and sends to vendor his signature-response scalar along with this reveal of his commitment data; vendor completes signature and publishes tx to the blockchain in order to receive funds

workflow does not interrupt the common workflow of a digital marketplace

what are the pros and cons of increasing max number of tx outputs?

pros: more outputs, less txs needed if doing large batches

cons: everything else

everything else?

Pros also include smaller overall size, and better batching speedups.

Quite a corner case currently though. Might not be if we get some kind of coinjoin.

is batching better for small batches rather than larger?

Better for large.

ah right, pro implies better duh

con is probably, easier to fingerprint individual tx since breaking large batches into smaller chunks increases indistinguishability

I think the original worry was someone making a tx with 100k outputs, DoSing verifiers.

The one I remember anyway.

is it really better for batching?

AFAIK it is, though it gets into diminishing returns.

smaller over size depends on distribution of of output sizes I would guess

overall*

output amounts*

numbers of outputs*

whatever

though overall smaller I would think

just more range proof wastefulness

The incremental size for range proofs grows quite slowly as the number of outputs goes up. If you have to split into 4 txes, you restart the log from 0.

I'm curious what the verification is like for 4x 16 batched (and non) vs 1x64

probably been tested somewhere

There are performance tests hidden somewhere in the monero tree.

I'll tell you in... some as yet unknown amount of minutes.

You also need to pad generators to the next power of 2

So for verifiers, 17 == 33

*32

And fees need to account for this of course

Hrm. Need to patch the source to allow for 64 -_-

Since max inputs is 185 I think it would make sense to have 64 or 128 be max outputs

Also better for batching to have fewer unique generators

Two 32out proofs share their 2x32 generators

One 64out proof needs 2x64 unique generators

Plus the others that are per proof, but there are fewer of these with log scaling

I don't agree that max inputs should match

well it makes sense for MoJoin

185 max input/128 max output gives the most flexibility, even though if it's 1 input per output the balance is closer to 100/100

<sarang> You also need to pad generators to the next power of 2 <= this is what I meant by more range proof wastefulness

mojoin is pretty secondary in consideration for me at this point

does that wastefulness refer to transaction weight or transaction verification speed? or code-side

It's no size difference between powers of 2

Verification does scale within those values tho

so a 64-rp will take longer than 4x 16-rp?

Hence needing fees to scale accordingly

koe: probably... The shared generator benefit becomes more apparent with higher counts

Because of those per proof elements that can't be shared

Batching enabled.

That's on a laptop with various other VMs running, so take with mucho salt.

Oh, that's just the bulletproofs. I don't have tests for whole tx for this...

Makes sense

if Im reading this right, it's suggesting 4x 16-rp is 10x faster than 1x 64-rp

What is rp ?

rangeproofs. My mistake the loop counts are different, more like 2.5x

sounds in range

Do you have proof ?

without batching, looks like 64-rp is 20% faster

under what conditions may range proofs be batched for verification?

It's pretty forgiving. I think all they need to be is bulletproofs.

Do they have to be the same power of 2?

That's only enabled within a block currently. I have a patch to make it batch "free standing" txes but it was not deemed worth it. We could also batch a set of blocks when downloading historical data, in theory.

No.

what if you batched 4x 64-rp and compared with 16x 16-rp?

All BPs can be batched. The extent to which hey share generators depends on size and implementation

*they

Generators not shared are an extra marginal cost in the multiexp

The number of unique generators (excluding per proof) is based on the largest in the batch

Looks to me like 40% faster for the 16x 16-rp over the 4x 64-rp

implies smaller rangeproofs are better (in terms of verification speed), assuming transaction volume or verification procedure is enough to sustain batching, although there are diminishing returns as batching volume rises

another pro of bigger max tx output count: to disperse a large amount amongst many recipients, currently it takes a chain of transactions to accomplish, since first you break the large amount into 16 smaller amounts, then (assuming <=256 recipients) construct a bunch of tx

that would happen less with bigger output sets

it actually means more blockchain bloat to do that chaining, from the intermediate outputs

Isthmus what is the proportion of tx volume with max output count?