<k​ayabanerve:matrix.org> 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.

<a​rticmine:monero.social> 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.

<a​rticmine:monero.social> The more I look at this POW to transact the less I like it

<a​rticmine:monero.social> How is this POW to transact going to be enforced!?

<a​rticmine:monero.social> What is the proposed n?

<j​berman:monero.social> 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<clipped message>

<j​berman:monero.social> ork after that point, which seems ok to me initially

<j​berman:monero.social> 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

<j​berman:monero.social> 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

<a​rticmine:monero.social> So if I understand correctly the POW can be renewed by a merciful node

<j​berman:monero.social> yep

<a​rticmine:monero.social> ... and TXs with 8 or less inputs would pass without the POW requirements

<j​berman:monero.social> 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

<j​berman:monero.social> that would force a reckoning with the windows problem I guess

<a​rticmine:monero.social> Then we are back to POW to transact

<j​berman:monero.social> I'm saying PoW as in do a single hash

<j​berman:monero.social> in that case

<a​rticmine:monero.social> Still it is POW to transact

<a​rticmine:monero.social> This has nothing to do with wallet fingerprinting

<j​berman:monero.social> er, ok, but the cost of that PoW computationally is astronomically less than the cost of making the tx in the first place

<a​rticmine:monero.social> So what is the point

<a​rticmine:monero.social> Do you mean the cost of making a valid TX?

<j​berman:monero.social> meh, ya nvm, I don't have a good argument in favor of enforcing PoW at 8 inputs or less

<a​rticmine:monero.social> ... and I don't have a good argument in not enforcing over 8 inputs

<j​berman:monero.social> as in you are ok with PoW-enforced relaying txs for txs with over 8 inputs?

<a​rticmine:monero.social> Yes I am fine for over 8 inputs with node relay for enforcement

<j​berman:monero.social> noice

<c​oncepcion:unredacted.org> youtu.be/5xi0ukN49bs

<g​ingeropolous:monero.social> jberman: your ideas re: tx-pow resemble some thoughts i had, and I tried to vibe code a simulator to test: 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

<g​ingeropolous:monero.social> ah, i found it: github.com/Gingeropolous/txsim/blob/main/vibeprompt.txt

<j​berman:monero.social> Yep very similar! I guess it would be an open question whether or not to implement a difficulty adjustment

<r​ottenwheel:unredacted.org> 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)

<r​ottenwheel:unredacted.org> x.com/monero/status/1918014582783705331

<r​ottenwheel:unredacted.org> nitter: xcancel.com/monero/status/1918014582783705331

<c​haser:monero.social> mainnet is now 500+ blocks past 3401782, the block height beyond which `unlock_time`s of new transactions won't be regarded post-FCMP++. monero-project/research-lab #125#issuecomment-2448077632