07:18:15 <m-relay> <r​brunner7:monero.social> Yeah, but I guess it will take a lot of work to provide good UI/UX in wallet apps to handle such pre-signing, it's not exactly trivial to get that easy and foolproof. Right now I somehow doubt that devs will really put in the necessary effort. Look how long it took for a comparatively harmless feature like subadresses to get universal support.
16:18:05 <m-relay> <h​bs:matrix.org> Am I alone to not be bothered that much by the 10 block lock?
16:19:20 <m-relay> <r​avfx:xmr.mx> If you use monero like it mean to be used the 10 block lock is like non existant
16:19:39 <m-relay> <r​avfx:xmr.mx> Like I totally forget it exist, I just use the monero and it just work
16:20:04 <m-relay> <r​avfx:xmr.mx> It only affect people who buy it to send it all of that kind of collect only one output in there wallet
16:40:29 <Cindy_> hbs: 20 minutes is too long to wait if you just wanna buy something from the vending machine
16:40:52 <m-relay> <k​iersten5821:matrix.org> the default behavior of the wallet is to select two inputs to any tx so you only have one output remaining and it destroys outputs... i had two outputs of some size and sent some coins (total sent smaller than either output) and suddenly i have 1 output...
16:41:01 <m-relay> <k​iersten5821:matrix.org> i thought i would be able to pay twice in a row but suddenly it was only once
16:41:02 <Cindy_> or pay fo a cup of coffee
16:41:33 <m-relay> <h​bs:matrix.org> If you use Monero regularly why would you have to wait 20 minutes?
16:42:01 <Cindy_> 20 minutes is how long it takes for the 10 block lock
16:42:55 <Cindy_> to complete
16:43:43 <Cindy_> some programs (like moneropay) let you wait for transactions as soon as they come (0-conf)
16:44:01 <m-relay> <r​ucknium:monero.social> Cindy_: You don't have to wait 10 blocks. You don't even have to wait for the first confirmation if it's a low-value tx.
16:44:05 <Cindy_> but it's super risky because the user could just send a broken transaction
16:44:21 <Cindy_> or double-spend that'll obviously not pass the first vaildation
16:44:24 <Cindy_> validation*
16:44:38 <Cindy_> rucknium: really?
16:45:21 <m-relay> <r​ucknium:monero.social> kiersten: AFAIK, the consolidation behavior is designed to thwart statistical analysis of ring signatures. When FCMP is deployed, it may be a good idea to rethink that wallet behavior.
16:45:38 <m-relay> <r​ucknium:monero.social> Cindy_ : Do you know what the 10 block lock is supposed to do?
16:45:45 <m-relay> <k​iersten5821:matrix.org> i see... i didn't know it was a privacy thing
16:46:02 <Cindy_> rucknium: properly validate transactions?
16:46:06 <m-relay> <r​ucknium:monero.social> If you don't, read this: https://rucknium.me/posts/monero-18-block-reorg/
16:46:36 <m-relay> <r​ucknium:monero.social> Cindy_: No.
16:47:54 <m-relay> <k​iersten5821:matrix.org> maybe after the fcmp update, the default behavior could be to target a fixed number of outputs or something, to improve the payment ux and avoid the coins always being locked
16:48:00 <m-relay> <r​ucknium:monero.social> Accepting low-conf txs _was_ unsafe during the Qubic disruptions.
16:48:09 <m-relay> <k​iersten5821:matrix.org> maybe after the fcmp update, the default behavior could be to target a fixed number of outputs in your wallet or something, to improve the payment ux and avoid the coins always being locked
16:48:23 <m-relay> <r​ucknium:monero.social> since some txs were invalidated by the 18-block re-org.
16:49:20 <Cindy_> rucknium: oh so it's supposed to prevent transaction invalidation
16:50:02 <m-relay> <r​ucknium:monero.social> kiersten: IMHO, that would be reasonable. There's a lot of logic in the wallet code to reduce privacy issues with ring signatures, which won't be necessary after FCMP are deployed. For example, there is a `monero-wallet-cli` warning about spending multiple outputs that are close together in time, but old.
16:50:20 <Cindy_> sorry if i'm dummb
16:50:50 <m-relay> <r​ucknium:monero.social> Cindy_: Yes, if there is a re-org. It prevents _spending_ the new outputs, but does not prevent a merchant from accepting a Monero payment as valid and releasing the good/service.
16:51:53 <Cindy_> but isn't 0-conf risky?
16:52:03 <Cindy_> because a invalid transaction cannot be mined into a new block
16:52:25 <m-relay> <r​ucknium:monero.social> The invalidation can occur because the global output index is altered when a re-org occurs. Therefore, the ring signatures, which use an index instead of the actual tx IDs to reference outputs, would be invalid.
16:52:36 <m-relay> <k​iersten5821:matrix.org> is there any plan to add rbf
16:53:22 <m-relay> <r​ucknium:monero.social> 0-conf can be risky, but the risk is probably below the risk of credit card fraud.
16:54:09 <m-relay> <r​ucknium:monero.social> XMR.to used zero-conf for years without issues.
16:54:19 <m-relay> <r​ucknium:monero.social> AFAIK
16:54:26 <m-relay> <r​avfx:xmr.mx> Plenty of merchands still do use 0 conf or 1 conf
16:54:37 <Cindy_> okay so it prevents spending the new outputs because a new transaction could use the global output indexs for its own rings
16:54:44 <Cindy_> and in the case of a reorg, that transaction would become invalid
16:54:54 <Cindy_> if the outputs it got it from also got invalidated
16:55:03 <Cindy_> i mean the transaction where those outputs came from
16:55:20 <m-relay> <r​ucknium:monero.social> kiersten: I don't know of serious plans yet, but see https://github.com/monero-project/research-lab/issues/128
16:57:12 <m-relay> <r​ucknium:monero.social> Not having RBF (Replace By Fee) makes 0-conf safer.
16:58:09 <m-relay> <r​avfx:xmr.mx> Yeah, can't simply send the same output (to yourself to cancel the TX) with higher fees
16:59:23 <m-relay> <r​avfx:xmr.mx> the 10 output lock don't protect agains double spend and things like that right? It's like, to prevent people from using decoy that can get reordered and so invalidated
17:00:27 <Cindy_> i remember most of the reason why steam stopped using bitcoin is because of RBF
17:00:39 <m-relay> <r​avfx:xmr.mx> if the 10 confirmation lock get removed it have to get removed for everyone too (so xmr tx look like other xmr tx, without extra reconizable wallet induced patterns)
17:01:04 <m-relay> <r​avfx:xmr.mx> non, it was because it was too volatil
17:01:50 <m-relay> <r​avfx:xmr.mx> you can detect RBF in the initial transaction, it have to be enabled when you do the first transfer.
17:01:50 <m-relay> <r​avfx:xmr.mx> If you pay something with RBF on, the merchand can simply force you to wait 1 or more confirmations
17:02:14 <m-relay> <r​avfx:xmr.mx> if you send with RBF off, you can't use it later to cancel the TX
17:03:20 <m-relay> <r​avfx:xmr.mx> Some merchands that accept 0 conf on bitcorn will force you to wait confirmation(s) if you enable RBF, it's not hard too do and it's usually like all the 0 conf implementation I saw work
17:06:57 <m-relay> <k​iersten5821:matrix.org> this is false, bitcoin has full-rbf now and its glorious
17:08:26 <m-relay> <r​avfx:xmr.mx> what, are you tell you can't turn it off in the transaction settings anymore?
17:09:16 <m-relay> <r​avfx:xmr.mx> It's very rare I use that coin lol, but it used to be an optional feature, would be dumb to force it on for everyone considering you can't have 0 conf with that
17:11:49 <m-relay> <k​iersten5821:matrix.org> you can turn it off but miners will ignore it and still accept an rbf
17:12:20 <m-relay> <r​avfx:xmr.mx> Lol
17:12:20 <m-relay> <r​avfx:xmr.mx> That coin is a mess
17:12:46 <m-relay> <k​iersten5821:matrix.org> good design decision imo, false sense of security with it
17:13:04 <m-relay> <r​avfx:xmr.mx> Sure, so now they can't have safe 0 conf
17:14:52 <m-relay> <k​iersten5821:matrix.org> never could 🤷
17:16:57 <m-relay> <r​avfx:xmr.mx> yeah, so at the end the miner can still make more money by accepting transaction "fee replacement" even if it was disabled in the initial transaction. LOL.
17:16:58 <m-relay> <r​avfx:xmr.mx> I guess because the miner don't care if you try to scam as they make more fees money at the end 😂
17:17:44 <m-relay> <r​avfx:xmr.mx> Yeah, reading on the net they all say it can be "disabled" in the wallet and you read more and yeah the miners don't care 😂
17:18:14 <m-relay> <k​iersten5821:matrix.org> i mean, they could always do that from the beginning 😂 it just became deliberate common policy like 3 years ago i think
17:18:41 <m-relay> <r​avfx:xmr.mx> Yeah I guess, it was like a false sense of security for the sellers to accept 0-conf
17:18:49 <m-relay> <r​avfx:xmr.mx> so just wait 1+ conf always instead
17:23:51 <m-relay> <r​avfx:xmr.mx> Make eet simple!
17:23:54 <m-relay> <r​avfx:xmr.mx> https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/qvAvCsLijrKAFCGNwBFnacNZ
17:25:55 <Cindy_> is 1-conf better than 0-conf?
17:26:28 <Cindy_> the fact that the transaction got mined into a block is a good thing
17:26:40 <m-relay> <r​avfx:xmr.mx> Well, at least on bitcoin you have to now considering bitcoin core node literally have an option to ignore whatever the transaction signal as for RBF support
17:27:49 <m-relay> <r​avfx:xmr.mx> Yeah, it just that for bitcorn, that one block can be 5 minutes... or 40 minutes.... Or 1hr... never know in advance...
17:27:50 <m-relay> <r​avfx:xmr.mx> Monero block time are smaller so 1 conf on XMR are usually a lot faster
17:28:25 <Cindy_> like 2 minutes :P
17:28:28 <Cindy_> or less!
17:28:55 <m-relay> <r​avfx:xmr.mx> It can be 10 minutes sometime
17:29:06 <Cindy_> no way
17:29:07 <m-relay> <r​avfx:xmr.mx> the equivalent of BTC 50 minutes sometime
17:29:21 <m-relay> <r​avfx:xmr.mx> I did see it in the past...
17:29:26 <Cindy_> no blocks for 10 minutes, how bad does the hashrate have to be
17:29:39 <m-relay> <r​avfx:xmr.mx> just badluck on the miners side, that append
17:30:20 <m-relay> <r​avfx:xmr.mx> sometime you get 30 seconds block...
17:30:20 <m-relay> <r​avfx:xmr.mx> The network aim for 2 minutes but it vary of course
18:12:22 <selsta> .merge+ 10039
18:12:22 <xmr-pr> Added