01:29:53 Thomas[m]4 afaik without output indices you can’t do batching, which is necessary for next get tx protocols with 100+ ring members 03:22:03 is this related to the whole use the hash ID of an output instead of its index when creating a transaction? 03:22:08 thing? 03:22:29 Thomas[m]4, UkoeHB ? 03:27:19 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. 03:30:35 right, yeah i think we're talking about the same thing 03:31:03 and if so, I don't understand how it would effect batching 03:34:06 especially if you can include the key offset post hoc. 03:34:56 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 03:35:31 for me, I think its in the maybe pile because it opens up new cans of worms. 03:36:01 like, it technically allows transaction chaining in the mempool, and what are the implications of this re: ring sigs 03:37:01 because, perhaps, you'd have to have the ring members selected from the mempool by default, because otherwise it sticks out 03:37:25 so this requires an always populated mempool to create a tx 03:37:42 maybe 03:38:06 fun to think about. needs a whiteboard 03:38:18 and I don't have any whiteboards. 06:15:41 > signing a transaction that spends an output that hasn't been included yet. 06:15:41 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 06:15:41 make a tx, if batching is used 06:17:49 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. 06:29:15 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? 06:30:06 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? 06:30:19 I don't know anything about batching so I might be wrong. 06:31:02 Batching is a way of selecting groups of ring members. It uses less storage than referencing each member individually. 06:31:18 But batching maps to indices 06:31:58 I guess batching is something that a wallet does then? 06:32:45 It doesn’t do it now, but it would if triptych is implemented. A standard part of making every ring sig 06:33:03 Right. Would it be mandatory? 06:33:08 Yeah 06:35:37 How is batching affected if you only spend a single output? 06:36:09 But... not a lot of research has gone into batching. It mayyy be possible to create batch generators after selecting random indices 06:36:34 Batching is within a single ring sig - each output gets its own ring sig 06:37:07 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) 06:38:10 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? 06:39:53 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. 06:40:53 Gtg ttyl 06:41:10 k thx! 14:02:54 FWIW, I have been using the term "binning" to refer to fixed sets of outputs 14:03:11 and the term "batching" to refer to verification of independent proofs all at once 14:03:35 In case this has caused any confusion 14:04:11 I thought binning was selecting several contiguous outputs. 14:07:54 Sure, it has been talked about in terms of contiguous outputs, possibly with verifiable shuffling imposed 14:09:38 I was just clarifying previous use of the terms "binning" and "batching" 14:21:40 Oh yeah my bad