00:58:39 Seeking help in Launching a Song based on Monero - Its pretty kick ass and reaching out to Monero team to see if they want to listen to a demo 06:27:47 Thanks for the discussion so far, it's really been interesting and good learning.  But I still think I am missing something here. 06:27:48 If v is 20, yes mod 5 will make it 0. But v is only the private key(scalar), and you use mod only if you convert it over to a public key right? Or do you mod is before that as well? 10:49:13 Test 10:49:50 Huh weird. Missing messages just appeared after that test. Probably something on my matrix end. 14:11:26 on the CPFP topic, I recall some talk recently of removing the 10 block lock time. if I recall correctly, it's something that may be possible under seraphis? 14:11:51 no 14:12:49 hmmm I'm almost sure there was some convo about removing tx-chaining maybe not seraphis related I would trust you to know about that lol 14:13:07 adding* 14:14:53 removing tx chaining? seraphis has tx chaining... 14:15:07 10 block lock is a hard requirement 14:15:23 as in, you need to kill pow first before you can kill 10 block lock 14:15:30 okay then, maybe this is my point of confusion -- I thought tx-chaining was the ability to spend unmined transactions? 14:16:03 yes, but it doesn't solve 10 block lock, just lets you change the person who has to sit around waiting 14:16:48 but can't the next person also chain the tx, thus avoiding the wait? 14:17:06 The 10 block lock isn't an inherent feature of PoW. 14:17:20 I guess the point is you can only do it for unmined transactions, and once you get a confirmation then you have to wait to spend? that would be weird UX 14:18:18 yeah definitely not the locktime is pretty unique to monero / CN 14:20:40 it's a hard req for a privacy coin like monero... who cares about non-privacy coins? 14:22:15 You think it's a hard req just because transactions reference outputs by index -- am I understanding your position correctly? 14:37:57 no, because reorgs can invalidate any tx that references a reorged tx 14:38:11 it's an attack vector 14:38:57 okay that aside, tx chaining would still allow for CPFP transactions, no? 14:39:19 But isn't it this type of attack possible exactly because the reference is done by index rather than hash? 14:40:30 I do vaguely recall such a discussion ^^ 14:49:24 No, it’s because in a reorg you can double spend an output spent by the orphaned chain. Any reference (index, hash, or otherwise) to the orphaned tx containing the spent output is permanently dead (unless another reorg restores it). 14:49:43 What is CPFP? 14:51:14 "child pays for parent" -- if a transaction is stuck in the mempool due to low fees, the person on the receiving side can broadcast a new transaction to incentivize miners to include both by increasing the average fee per byte between them 14:52:14 Not quite permanent* since you could reproduce the output of the dead tx you want to spend, in another tx... but it’s questionable what the advantage would be. 14:53:32 a new transaction that spends the unmined output from the first* 14:54:34 Hmmm. I still think this is particular to reference-by-index. The orphaned transactions would still be in the mempool of the set of nodes and miners that do not follow the orphaned chain and they could include (and almost certainly would include) it in a block. 14:54:36 Lyza: I see. That is independent of tx chaining, because you’d need a whole new tx type (where the inputs don’t have ring signatures). 14:55:20 I don't think you would. 14:55:43 And double spending on another chain is also a bitcoin thing (hsah rate notwithstanding). 14:55:48 Is the 10 block lock and its rationale discussed in Zero to Monero? 14:56:05 Rucknium[m]: still no, in my scenario the orphaned tx are dead because the main chain double spends them 14:57:04 Hmmm ok. I guess I don't understand it yet. 14:57:34 Rucknium[m]: it isn’t discussed there, the analysis has improved since I wrote that 14:59:06 moneromooo: if you have a tx in the mempool, and another tx comes along and says ‘I want to bump the fee of that other tx’, doesn’t that require a new tx type? Especially if it’s child-pays-for-parent, where the real spend of the parent is known. 15:00:55 Lyza: sorry, I mean it would be a different/special kind of tx chaining, separate from normal tx chaining. 15:01:52 I don't think it does: 15:01:54 Replace by fee (RBF) would still work in Monero, though, right? 15:02:16 Alice sends tx0 spending outputs A0 to A10, creating outputs B0 and B1, B0 goes to Bob, B1 is change. 15:02:46 Bob wants that to be mined, so sends tx1 spending B0 to B10, creating C0 and C1, with high fee. 15:02:57 To claim the tx1 high fee, tx0 has to be mined. 15:03:48 er, Bob spends B0, B2..B11. Since B1 is unrelated. 15:04:14 Well, can spend B1 too I guess. Just does not have to. 15:07:43 Am I wrong in saying that tx1 using B0, B... cannot be created until tx0 is mined (+10 blocks), since B0 would be rejected as an invalid ring member? 15:08:51 No, but this is based on referencing oututs by pubkey. 15:10:38 Oh, was that what was meant by a new type of tx ? If so, then you're right. I thought it meant a type of tx specifically for that pays-for-parent usage. 15:11:05 Since it was in the context of referencing by pubkey in the first place. 15:12:06 (I assume "hash" means pubkey in the backlog above) 15:30:36 it might work, but would that kind of chaining diminish the ring sig obfuscation? 15:32:05 I think you could do it right, but wallets would have to be aware of transactions in the mempool so that decoys could be pulled from the mempool. 15:33:48 moneromooo: I see what you mean 15:34:07 moneromooo: I see what you mean 15:35:48 However, the reorg attack remains, so I think if you want that behavior then a special tx type without ring sigs is necessary. 15:38:20 sure, but the reorg attack is only a concern if you are the one being attacked... i.e., if someone is actually trying to double spend against you 15:38:53 if the ref by hash thing is in, orphan chain txs get dumped back into the mempool 15:41:57 a "natural" re-org would probably include most of those transactions in the "new" chain anyway 15:44:52 gingeropolous: no, it is a generic attack because your decoys can also be double spent 15:45:34 hrmmmm 15:45:58 so all the attacker has to do is double spend a bunch of his own transactions, and any time a reorg occurs anyone who referenced his tx's outputs as decoys will see their tx get yeeted 15:46:37 a reorg that switches out one of the attackers double spends* 15:50:16 Hmm. That seems less of a privacy issue and more of a user inconvenience issue. The privacy issue seems to be on the level of a FloodXMR attack. 15:50:32 of course my mind goes back to my prior thought on this which is to magically create ring sigs that "work" if n/m are present, but i remember that idea not having legs 15:51:29 it isn't a privacy issue... it is a protocol design issue 15:53:11 censorship-resistance * 15:53:33 yeah im not thinking of it as a privacy issue, i mean like you could still make a transaction function if, say, 3/11 of the ring members just disappeared 15:53:50 like, 8 of them are still there. good enough! says the protocol 15:53:52 I was responding to Rucknium[m] 15:53:58 roight roight 15:54:13 that idea doesn't work with any proof system I know about 15:54:25 time to go to the idea tree :)