<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.

<h​bs:matrix.org> Am I alone to not be bothered that much by the 10 block lock?

<r​avfx:xmr.mx> If you use monero like it mean to be used the 10 block lock is like non existant

<r​avfx:xmr.mx> Like I totally forget it exist, I just use the monero and it just work

<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

hbs: 20 minutes is too long to wait if you just wanna buy something from the vending machine

<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...

<k​iersten5821:matrix.org> i thought i would be able to pay twice in a row but suddenly it was only once

or pay fo a cup of coffee

<h​bs:matrix.org> If you use Monero regularly why would you have to wait 20 minutes?

20 minutes is how long it takes for the 10 block lock

to complete

some programs (like moneropay) let you wait for transactions as soon as they come (0-conf)

<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.

but it's super risky because the user could just send a broken transaction

or double-spend that'll obviously not pass the first vaildation

validation*

rucknium: really?

<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.

<r​ucknium:monero.social> Cindy_ : Do you know what the 10 block lock is supposed to do?

<k​iersten5821:matrix.org> i see... i didn't know it was a privacy thing

rucknium: properly validate transactions?

<r​ucknium:monero.social> If you don't, read this: rucknium.me/posts/monero-18-block-reorg

<r​ucknium:monero.social> Cindy_: No.

<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

<r​ucknium:monero.social> Accepting low-conf txs _was_ unsafe during the Qubic disruptions.

<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

<r​ucknium:monero.social> since some txs were invalidated by the 18-block re-org.

rucknium: oh so it's supposed to prevent transaction invalidation

<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.

sorry if i'm dummb

<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.

but isn't 0-conf risky?

because a invalid transaction cannot be mined into a new block

<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.

<k​iersten5821:matrix.org> is there any plan to add rbf

<r​ucknium:monero.social> 0-conf can be risky, but the risk is probably below the risk of credit card fraud.

<r​ucknium:monero.social> XMR.to used zero-conf for years without issues.

<r​ucknium:monero.social> AFAIK

<r​avfx:xmr.mx> Plenty of merchands still do use 0 conf or 1 conf

okay so it prevents spending the new outputs because a new transaction could use the global output indexs for its own rings

and in the case of a reorg, that transaction would become invalid

if the outputs it got it from also got invalidated

i mean the transaction where those outputs came from

<r​ucknium:monero.social> kiersten: I don't know of serious plans yet, but see monero-project/research-lab #128

<r​ucknium:monero.social> Not having RBF (Replace By Fee) makes 0-conf safer.

<r​avfx:xmr.mx> Yeah, can't simply send the same output (to yourself to cancel the TX) with higher fees

<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

i remember most of the reason why steam stopped using bitcoin is because of RBF

<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)

<r​avfx:xmr.mx> non, it was because it was too volatil

<r​avfx:xmr.mx> you can detect RBF in the initial transaction, it have to be enabled when you do the first transfer.

<r​avfx:xmr.mx> If you pay something with RBF on, the merchand can simply force you to wait 1 or more confirmations

<r​avfx:xmr.mx> if you send with RBF off, you can't use it later to cancel the TX

<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

<k​iersten5821:matrix.org> this is false, bitcoin has full-rbf now and its glorious

<r​avfx:xmr.mx> what, are you tell you can't turn it off in the transaction settings anymore?

<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

<k​iersten5821:matrix.org> you can turn it off but miners will ignore it and still accept an rbf

<r​avfx:xmr.mx> Lol

<r​avfx:xmr.mx> That coin is a mess

<k​iersten5821:matrix.org> good design decision imo, false sense of security with it

<r​avfx:xmr.mx> Sure, so now they can't have safe 0 conf

<k​iersten5821:matrix.org> never could 🤷

<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.

<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 😂

<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 😂

<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

<r​avfx:xmr.mx> Yeah I guess, it was like a false sense of security for the sellers to accept 0-conf

<r​avfx:xmr.mx> so just wait 1+ conf always instead

<r​avfx:xmr.mx> Make eet simple!

<r​avfx:xmr.mx> matrix.monero.social/_matrix/media/…oad/xmr.mx/qvAvCsLijrKAFCGNwBFnacNZ

is 1-conf better than 0-conf?

the fact that the transaction got mined into a block is a good thing

<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

<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...

<r​avfx:xmr.mx> Monero block time are smaller so 1 conf on XMR are usually a lot faster

like 2 minutes :P

or less!

<r​avfx:xmr.mx> It can be 10 minutes sometime

no way

<r​avfx:xmr.mx> the equivalent of BTC 50 minutes sometime

<r​avfx:xmr.mx> I did see it in the past...

no blocks for 10 minutes, how bad does the hashrate have to be

<r​avfx:xmr.mx> just badluck on the miners side, that append

<r​avfx:xmr.mx> sometime you get 30 seconds block...

<r​avfx:xmr.mx> The network aim for 2 minutes but it vary of course

.merge+ 10039

Added