07:17:28 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:17:18 h​bs:matrix.org: Am I alone to not be bothered that much by the 10 block lock?
16:18:32 r​avfx:xmr.mx: If you use monero like it mean to be used the 10 block lock is like non existant
16:18:52 r​avfx:xmr.mx: Like I totally forget it exist, I just use the monero and it just work
16:19:17 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:39:41 Cindy_: hbs: 20 minutes is too long to wait if you just wanna buy something from the vending machine
16:40:05 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:40:14 k​iersten5821:matrix.org: i thought i would be able to pay twice in a row but suddenly it was only once
16:40:14 Cindy_: or pay fo a cup of coffee
16:40:45 h​bs:matrix.org: If you use Monero regularly why would you have to wait 20 minutes?
16:41:14 Cindy_: 20 minutes is how long it takes for the 10 block lock
16:42:07 Cindy_: to complete
16:42:56 Cindy_: some programs (like moneropay) let you wait for transactions as soon as they come (0-conf)
16:43:13 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:43:17 Cindy_: but it's super risky because the user could just send a broken transaction
16:43:34 Cindy_: or double-spend that'll obviously not pass the first vaildation
16:43:37 Cindy_: validation*
16:43:50 Cindy_: rucknium: really?
16:44:34 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:44:51 r​ucknium:monero.social: Cindy_ : Do you know what the 10 block lock is supposed to do?
16:44:57 k​iersten5821:matrix.org: i see... i didn't know it was a privacy thing
16:45:14 Cindy_: rucknium: properly validate transactions?
16:45:18 r​ucknium:monero.social: If you don't, read this: https://rucknium.me/posts/monero-18-block-reorg/
16:45:49 r​ucknium:monero.social: Cindy_: No.
16:47:06 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:47:13 r​ucknium:monero.social: Accepting low-conf txs _was_ unsafe during the Qubic disruptions.
16:47:22 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:47:35 r​ucknium:monero.social: since some txs were invalidated by the 18-block re-org.
16:48:33 Cindy_: rucknium: oh so it's supposed to prevent transaction invalidation
16:49:14 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:49:32 Cindy_: sorry if i'm dummb
16:50:02 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:06 Cindy_: but isn't 0-conf risky?
16:51:15 Cindy_: because a invalid transaction cannot be mined into a new block
16:51:37 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:51:48 k​iersten5821:matrix.org: is there any plan to add rbf
16:52:35 r​ucknium:monero.social: 0-conf can be risky, but the risk is probably below the risk of credit card fraud.
16:53:21 r​ucknium:monero.social: XMR.to used zero-conf for years without issues.
16:53:32 r​ucknium:monero.social: AFAIK
16:53:38 r​avfx:xmr.mx: Plenty of merchands still do use 0 conf or 1 conf
16:53:50 Cindy_: okay so it prevents spending the new outputs because a new transaction could use the global output indexs for its own rings
16:53:56 Cindy_: and in the case of a reorg, that transaction would become invalid
16:54:06 Cindy_: if the outputs it got it from also got invalidated
16:54:15 Cindy_: i mean the transaction where those outputs came from
16:54:33 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:56:24 r​ucknium:monero.social: Not having RBF (Replace By Fee) makes 0-conf safer.
16:57:21 r​avfx:xmr.mx: Yeah, can't simply send the same output (to yourself to cancel the TX) with higher fees
16:58:35 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
16:59:40 Cindy_: i remember most of the reason why steam stopped using bitcoin is because of RBF
16:59:52 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:00:17 r​avfx:xmr.mx: non, it was because it was too volatil
17:01:02 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:03 r​avfx:xmr.mx: If you pay something with RBF on, the merchand can simply force you to wait 1 or more confirmations
17:01:27 r​avfx:xmr.mx: if you send with RBF off, you can't use it later to cancel the TX
17:02:33 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:10 k​iersten5821:matrix.org: this is false, bitcoin has full-rbf now and its glorious
17:07:38 r​avfx:xmr.mx: what, are you tell you can't turn it off in the transaction settings anymore?
17:08:28 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:02 k​iersten5821:matrix.org: you can turn it off but miners will ignore it and still accept an rbf
17:11:32 r​avfx:xmr.mx: Lol
17:11:33 r​avfx:xmr.mx: That coin is a mess
17:11:59 k​iersten5821:matrix.org: good design decision imo, false sense of security with it
17:12:16 r​avfx:xmr.mx: Sure, so now they can't have safe 0 conf
17:14:04 k​iersten5821:matrix.org: never could 🤷
17:16:09 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:11 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:16:57 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:17:27 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:17:53 r​avfx:xmr.mx: Yeah I guess, it was like a false sense of security for the sellers to accept 0-conf
17:18:01 r​avfx:xmr.mx: so just wait 1+ conf always instead
17:23:04 r​avfx:xmr.mx: Make eet simple!
17:23:06 r​avfx:xmr.mx: https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/qvAvCsLijrKAFCGNwBFnacNZ
17:25:07 Cindy_: is 1-conf better than 0-conf?
17:25:41 Cindy_: the fact that the transaction got mined into a block is a good thing
17:25:53 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:01 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:03 r​avfx:xmr.mx: Monero block time are smaller so 1 conf on XMR are usually a lot faster
17:27:38 Cindy_: like 2 minutes :P
17:27:40 Cindy_: or less!
17:28:08 r​avfx:xmr.mx: It can be 10 minutes sometime
17:28:19 Cindy_: no way
17:28:20 r​avfx:xmr.mx: the equivalent of BTC 50 minutes sometime
17:28:33 r​avfx:xmr.mx: I did see it in the past...
17:28:38 Cindy_: no blocks for 10 minutes, how bad does the hashrate have to be
17:28:52 r​avfx:xmr.mx: just badluck on the miners side, that append
17:29:32 r​avfx:xmr.mx: sometime you get 30 seconds block...
17:29:33 r​avfx:xmr.mx: The network aim for 2 minutes but it vary of course
18:11:34 selsta: .merge+ 10039
18:11:34 xmr-pr: Added