14:45:00 <kayabanerve[m]> Is Seraphis keeping the 10-block lock? I know it has TX chaining, I just haven't heard about the lock.
14:47:55 <kayabanerve[m]> It doesn't sound decided yet
14:50:09 <tevador> There have been some proposals: https://github.com/monero-project/research-lab/issues/95 but AFAIK the plan is to stick with it for now.
17:06:33 <tevador> UkoeHB: Does your Seraphis library support pruning? How much work would it be to make tx_extra prunable? i.e. being able to calculate the txid without tx_extra (only knowing its hash).
17:08:27 <UkoeHB> tevador: I didn’t define a pruned tx type but it should be easy enough
17:08:44 <UkoeHB> I think the tx is depends on tx extra though
17:08:50 <UkoeHB> tx id
17:09:16 <UkoeHB> It’s part of a tx proposal which is one component of the tx hash
17:09:40 <UkoeHB> Since you need to sign on the tx extra
17:10:09 <tevador> Signing just the hash should be equally secure.
17:11:10 <UkoeHB> The tx proposal hash could be refactored as a merkle tree
17:11:53 <UkoeHB> I’m a little skeptical about pruning tx extra, since presumably it’s data that the recipients of a tx need.
17:12:35 <UkoeHB> Pruning is currently only about removing proof artifacts by assuming you won’t need to re-check signatures.
17:13:42 <tevador> IMO designing the protocol in a way that allows more pruning to be done later is beneficial. If possible, everything that's hashed should be a Merkle tree.
17:14:20 <UkoeHB> Doing more hashes does increase the cost of computing a tx id
17:15:02 <tevador> logarithmically
17:15:18 <UkoeHB> Right now it’s 4 hashes to get an id
17:16:32 <tevador> in any case, tx_extra is the only parts that has a potentially unbounded size
17:17:02 <tevador> so that 1 extra hash might be worth it
17:21:14 <UkoeHB> Yeah. I suppose selective pruning of tx extras could be quite desirable for many node operators. Perhaps ironically, the tx extra is a vector for censorship.
17:23:19 <tevador> Why are key images hashed twice when calculating the txid?
17:24:18 <tevador> To commit to the set of key images?
17:32:47 <UkoeHB> yeah input images are not available when making a tx proposal, only the key images, so input images need to be fully hashed separated for the tx id
17:35:34 <UkoeHB> actually maybe they are available hmm
17:40:45 <UkoeHB> My goal was to decouple the signed message from the details of input images so modifying an input image structure doesn't mean you need to re-implement the message. It also more concisely encapsulates what you want to commit to with a tx proposal.