Thomas[m]4 afaik without output indices you can’t do batching, which is necessary for next get tx protocols with 100+ ring members

is this related to the whole use the hash ID of an output instead of its index when creating a transaction?

thing?

Thomas[m]4, UkoeHB ?

Not really. This is primarily about the fact that committing to the output indices is unnecessarily limiting. What you want to commit to is the ring, which you can do by just hashing the ring members. Where they will be in the chain later on doesn't matter as long as the verifier is pointed to the exact ring members you hashed.

right, yeah i think we're talking about the same thing

and if so, I don't understand how it would effect batching

especially if you can include the key offset post hoc.

if indeed this is the same thing, then afaik its been in the "maybe we should do this" pile for a while, and is probably just waiting for someone to code it up

for me, I think its in the maybe pile because it opens up new cans of worms.

like, it technically allows transaction chaining in the mempool, and what are the implications of this re: ring sigs

because, perhaps, you'd have to have the ring members selected from the mempool by default, because otherwise it sticks out

so this requires an always populated mempool to create a tx

maybe

fun to think about. needs a whiteboard

and I don't have any whiteboards.

> signing a transaction that spends an output that hasn't been included yet.

Thomas[m]4: the problem is a tx has to reference all the outputs in its rings; if you have 100+ ring members, then it is inefficient to store an identifier for each one; you have to 'batch' ring members, which means e.g. 10 ring members can be referenced from a single identifier; batching only works if you know a fixed ordering of outputs; therefore, you can only spend things already in the chain when you

make a tx, if batching is used

We are not suggesting to change any of this. Just to actually commit to the public keys of the ring instead of the indices and include the indices in a part of the transaction that is not hashed for the signature to allow pre-computation of the signature hash prior to inclusion of all inputs in the chain.

How would you select ring members that will actually line up with a batch from the chain, if one of the indices isn’t know in advance?

I don't think the feature of pre-signing a transaction (where you don't know the index yet) plus batching would be used together much?

I don't know anything about batching so I might be wrong.

Batching is a way of selecting groups of ring members. It uses less storage than referencing each member individually.

But batching maps to indices

I guess batching is something that a wallet does then?

It doesn’t do it now, but it would if triptych is implemented. A standard part of making every ring sig

Right. Would it be mandatory?

Yeah

How is batching affected if you only spend a single output?

But... not a lot of research has gone into batching. It mayyy be possible to create batch generators after selecting random indices

Batching is within a single ring sig - each output gets its own ring sig

In protocol where you pre-sign transactions, you typically only have a single output you want to spend. So the TX would only have one input, and two outputs (just because it is enforced to be 2)

I am not fully getting it. If you have 11 ring members and only a single input in your TX, what exactly is batched together?

Say there are 121 ring members. A ‘batch’ would be 11 ring members referenced with a single identifier. Someone looking at the identifier finds all 11 ring members. The tx only needs 11 identifiers to find all 121 ring members.

Gtg ttyl

k thx!

FWIW, I have been using the term "binning" to refer to fixed sets of outputs

and the term "batching" to refer to verification of independent proofs all at once

In case this has caused any confusion

I thought binning was selecting several contiguous outputs.

Sure, it has been talked about in terms of contiguous outputs, possibly with verifiable shuffling imposed

I was just clarifying previous use of the terms "binning" and "batching"

Oh yeah my bad