-
plowsofan issue on -site asks for a better description of "suggested_confirmations_threshold" , currently it is "Estimation of the confirmations needed for the transaction to be included in a block." but this seems wrong. block reward / unlock time / network hashrate effect it github.com/monero-project/monero/bl…let/wallet_rpc_server.cpp#L102-L117 is trying to prevent some kind of attack?
-
moneromoooIt is definitely wrong.
-
moneromoooIt is the number of confirmations needed for the amount received to be lower than the accumulated block reward (or close to that).
-
moneromoooThe field name is not great either I suppose.
-
moneromoooThe original intent was to signal the rough point where it would not be worth it for a sender to pay miners to undo their work till the tx in question is reorg'd away, and made invalid.
-
moneromoooBut it's not perfect, especially since it only knows the output sent to the wallet calculating that number, and the attacker might have more in that tx.
-
moneromoooAlso, for large amounts, you get a value that's impractical. Like, receive 100 monero, you'll get, er... 130 confirnatins. Which is actually not impractical...
-
moneromoooOK, so for huge amounts it will be :)
-
UkoeHBA double spend can also target someone else’s tx, so confirmation time is about aggregate risk
-
plowsofthank you moneromoo ukoehb x
-
woodser[m]so maybe there is an easy way to get the height at which a key image is spent? I don’t think it’s practical to scan every tx client side
-
woodser[m]basically I want to know when multisig funds are spent without being notified by the final signer. ideally I can get the spending tx with its height. I can check that the key images are spent, but the api only shows they’re spent and confirmed, not when or what tx
-
woodser[m]maybe it would require a new call to monerod
-
moneromoooI have a patch for that somewhere.
-
moneromoooNot sure why I did not PR it. I'll look.
-
moneromoooAh, it was to go with historical reserve proofs. I think I actually did PR that...
-
moneromooo
-
rbrunnerIsn't it a little strange that this PR #6616 was never merged? I don't see any reasons against it in the discussion at the PR.
-
moneromoooNobody cared about it I guess. It's a niche use. I thought it'd be helpful for people who want to pay their taxes but that might be a minority among monero ousers :)
-
UkoeHBOn Monday Oct 24th at 1700 UTC I will be hosting an architecture walkthrough of the seraphis library via VDO.ninja screenshare. It's primarily for the seraphis migration working group ( github.com/seraphis-migration ), but it would be great if other devs could attend since seraphis would impact everyone (ping for vtnerd who rarely reads chat). If you want to attend, let me know so I can send an invite on the 24th (I may
-
UkoeHBlimit attendance if too many people want to join). Otherwise, we will try to have a video recording made. Note that you can join with no audio or video and just type in the chat if you want.
-
UkoeHBThe meeting will probably be ~1-2hrs long.
-
moneromoooSeems like a very useful thing to do. I'd watch such a downloadable video.
-
jtgrassieSounds great UkoeHB, I should be able to join
-
jeffro256[m]I'd love to long, Ukoe. Sounds interesting!
-
jeffro256[m]*join
-
UkoeHBok