00:09:18 I don't mind PoW to justify RPC requests. It's effectively the credits system, but something we could turn on overnight without it being a whole thing. 01:07:37 What happens with multi Sig? If a TX is not mined right away then it becomes invalid? I can see many issues here with just some demand on the TX rate. 01:07:38 The more I look at this POW to transact the less I like it 01:10:34 How is this POW to transact going to be enforced!? 01:12:50 What is the proposed n? 01:21:10 It's not PoW to transact, it's PoW for large-input txs to get the tx to enter the network's pool. A single multisig participant could do the PoW. If n is let's say 3, then the tx has ~3 blocks to propagate to the pools of all Monero nodes where it'll remain until it gets mined (or kicked from the pool). After n passes, then the tx wouldn't propagate to new nodes that join the netw 01:21:12 ork after that point, which seems ok to me initially 01:27:11 node receives a tx via relay, node checks the PoW and block ref included with the tx, if the PoW demonstrates single digit seconds of CPU time on some reference commodity CPU, and the block ref is within n blocks of chain tip, then node validates the tx and adds it to its pool, and relays it to nodes it is connected to along with the PoW so other nodes do the same 01:31:24 tbc, anyone can do the PoW, doesn't even have to be involved with the tx construction to be clear / needs no private keys associated with the tx to do it. Just attaches the PoW to the tx blob 01:35:35 So if I understand correctly the POW can be renewed by a merciful node 01:35:47 yep 01:39:28 ... and TXs with 8 or less inputs would pass without the POW requirements 01:41:08 possible yep. We may still want all txs to have a minimal PoW requirement because we might actually want all wallets to use this feature to avoid fingerprinting wallets 01:42:14 that would force a reckoning with the windows problem I guess 01:42:34 Then we are back to POW to transact 01:43:06 I'm saying PoW as in do a single hash 01:43:07 in that case 01:43:51 Still it is POW to transact 01:44:31 This has nothing to do with wallet fingerprinting 01:44:36 er, ok, but the cost of that PoW computationally is astronomically less than the cost of making the tx in the first place 01:45:08 So what is the point 01:45:46 Do you mean the cost of making a valid TX? 01:47:56 meh, ya nvm, I don't have a good argument in favor of enforcing PoW at 8 inputs or less 01:49:40 ... and I don't have a good argument in not enforcing over 8 inputs 01:50:56 as in you are ok with PoW-enforced relaying txs for txs with over 8 inputs? 01:51:54 Yes I am fine for over 8 inputs with node relay for enforcement 01:52:25 noice 09:18:49 https://youtu.be/5xi0ukN49bs 11:10:24 jberman: your ideas re: tx-pow resemble some thoughts i had, and I tried to vibe code a simulator to test: https://github.com/Gingeropolous/txsim . but basically, merciful nodes could re-load a tx with a PoW, based on some probability. I think i had another effort that wasn't this python code, I'll see if I can find it. Or I might have saved the prompt somewhere that described the architectu 11:15:18 ah, i found it: https://github.com/Gingeropolous/txsim/blob/main/vibeprompt.txt 17:07:46 Yep very similar! I guess it would be an open question whether or not to implement a difficulty adjustment 18:55:33 FYI. @monero finally tweeted about FCMP++ competition having open submissions now! cc. [@jberman:monero.social](https://matrix.to/#/@jberman:monero.social) [@xmrack:monero.social](https://matrix.to/#/@xmrack:monero.social) 18:55:39 https://x.com/monero/status/1918014582783705331 18:56:03 nitter: https://xcancel.com/monero/status/1918014582783705331 21:02:56 mainnet is now 500+ blocks past 3401782, the block height beyond which `unlock_time`s of new transactions won't be regarded post-FCMP++. https://github.com/monero-project/research-lab/issues/125#issuecomment-2448077632