Probably only obvious things like monerokon

<n​ickyviki:matrix.org> Townforge game based on monero Blockchain

<n​ickyviki:matrix.org> Overview

<n​ickyviki:matrix.org> Townforge is a blockchain based game where you create buildings which will provide you with income.

<n​ickyviki:matrix.org> Buildings and land cost a one off sum as well as regular maintenance costs. Payout is earned at every game tick, which happens every 720 blocks. A portion of the block rewards go to the game, to be redistributed to players. A research "tech tree" allows players to improve their buildings' efficiency. Peer to peer trade allows players to exchange goods and money. A 3D world view al<clipped message>

<n​ickyviki:matrix.org> lows players to bring their buildings to life, and a decentralized chat is available in game.

<n​ickyviki:matrix.org> Every game action is stored on a blockchain, ensuring that what you own cannot be taken away from you unless the game rules allow it. No exit scam, no central database corruption, no rules change at a whim without notice. The game state is stored on every game user's copy of the blockchain.

<n​ickyviki:matrix.org> In game currency is gold and its mined. Not issued my the developer

<n​ickyviki:matrix.org> www.townforge.net

<n​ickyviki:matrix.org> t.me/townforge

<a​tomfried:matrix.org> monero-hackerindustrial: bitbox.swiss/blog/roll-the-dice-generate-your-own-seed what about this?

<m​onerobull:matrix.org> why is there a townforge ad lol

<k​illercat103:matrix.org> why even run a game on a blockchain?

<k​illercat103:matrix.org> I feel like thats just some cryptobro/cryptobloat thing

<r​ucknium:monero.social> Killercat103: If on blockchain, a central server cannot change the rules, shut down, take player resources, or cheat. That question should be added to the FAQ I guess.

<r​ucknium:monero.social> Has anyone considered possible entropy issues when generating the CCS wallet on Qubes? QubesOS/qubes-issues #673

<r​ucknium:monero.social> Virtual machines can have entropy issues.

<h​into.janaiyo:matrix.org> oh wow that is probably it - i'm not sure why i didn't think of this immediately when hearing fluffy used qubes

<r​ucknium:monero.social> AFAIK it would be easier to tell if your brute force attack hit the CCS wallet's private key since its view key was public.

<h​into.janaiyo:matrix.org> this would mean that someone was aware of this and bruteforced whatever set of keys are possible with the lower entropy, then scanned the chain for each key (probably skipped to known tx's)

<h​into.janaiyo:matrix.org> maybe it just took 7~ years to find the right key :)

<h​into.janaiyo:matrix.org> i propose the new wallet's spend key should be created via physical entropy

<r​ucknium:monero.social> I think scanning the chain on each brute force attempt would take too long. They would attempt to match public view keys or public XMR addresses.

<h​into.janaiyo:matrix.org> ooo right that could be done extremely quickly

<r​ucknium:monero.social> Kearney, J. J., & Perez-Delgado, C. A. (2021). "Vulnerability of blockchain technologies to quantum attacks." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=80

<r​ucknium:monero.social> "However, Monero’s privacy system gives it some added level of security. An attacker would not know the amount being transferred in a target transaction. Hence, transactions of value are unobservable without prior attacks. Further, the use of RingCT means that the quantum assailant would need to solve multiple Pedersen commitments in order to find the correct public key used in <clipped message>

<r​ucknium:monero.social> the transaction. This makes Monero slightly more secure against—or at least a slightly less attractive target for—quantum assailants than other blockchain networks."

<h​into.janaiyo:matrix.org> i'm assuming the attacker had regular computer(s) and the entropy was low enough for a bruteforce

<h​into.janaiyo:matrix.org> unless the first person with a practical quantum computer decided the CCS wallet was target #1

<r​ucknium:monero.social> I quoted that article because it shows that you can't just perform a database lookup of addresses on Monero, unlike other blockchains. The only easy lookup would be view keys and public addresses AFAIK.

<r​ucknium:monero.social> I don't think it could be a quantum attack. Could be a regular brute force attack with a classical computer.

"whatever set of keys are possible with the lower entropy" I think it's too far-fetched

Entropy must be less than 50-60 bits to crack the known wallets in a reasonable amount of time

Even if you're in a VM, it's possible to get more bits of entropy

and the attacker must know the exact version of Qubes that was used to replicate the entropy issues

<h​into.janaiyo:matrix.org> unless qubes 2016~ really did have 50-60 bits of effective entropy QubesOS/qubes-issues #6939

<h​into.janaiyo:matrix.org> seems like the daemon responsible for counteracting the low vm entropy did not work

<h​into.janaiyo:matrix.org> if `monero-wallet-cli` just takes what it can from `/dev/urandom` without blocking then the pool may have been used up by other stuff running

<m​xgrafics:matrix.org> monerobull: can you approve my post on r/monerochan reddit.com/r/monerochan/s/Mu8nhLmXfP

<4​rkal:monero.social> If I send x monero to y address. How can I prove to a third party that i sent the x amount to y address?

txproof

<4​rkal:monero.social> Can tx proof verify the amount?

well, why not use txid though?

<4​rkal:monero.social> Asking whether or not a third party can verify that I sent you x monero

docs.featherwallet.org/guides/prove-payment

<l​za_menace:monero.social> the check can be done via the `check_tx_key` wallet RPC call or with an explorer - the onion explorer uses this route `xmrchain.net/prove{tx_hash}/{address}/{tx_key}`

<l​za_menace:monero.social> ohai dsc_

whatsup :)