<mj-xmr[m]> "BigmenPixel: It should make..." <- Thanks for answers :)

<hyc> "in practice that 10 block..." <- That's not really the case tho. The 10 blocks delay is a big UX problem for Haveno and getting rid of it will improve the experience of the user drastically. Right now people must wait at least 20 minutes after funding a wallet before opening a trade. We will be very happy if we manage to get rid of that limit

^ spam

<ErCiccione> "That's not really the case tho..." <- That's just one uescase, the number of situations where one would be willing to spend unconfirmed outputs is virtually infinite given some parties trust each other.

<UkoeHB> "alex: with Seraphis/Lelantus-..." <- That's great, it's useful for parties who trust each other.

I can add anecdotally that the 10 block limit has been a pain point for most of my friends when starting out. It is less of an issue for old wallets, yes, but it is frequently inconvenient for younger ones. It's certainly not the biggest problem monero has, but I think it warrants improvement if the opportunity presents itself.

<BusyBoredom[m]> "I can add anecdotally that the 1..." <- Absolutely. If we can abolish it without network-wide implications for privacy: we should abolish it as soon as the new protocol is rolled out, along with integrated addresses.

I don’t think it will ever be abolished. Just some niche workarounds that shouldn’t be widely used.

Do we have data on chain-reorg frequency and depth for the last year or so? AFAIK, chain reorgs is the main reason for the 10-block wait time.

can pretty much guarantee that lowering or removing the 10block wait will encourage more double-spend attacks

hyc: Do you mean deliberate chain-reorgs by malicious miners or just users hoping to get lucky?

both

<hyc> "can pretty much guarantee that..." <- Bitcoin doesn't have a mandatory wait time, the ecosystem is doing fine, standard consumer wallets have protections built in, commercial operators are free to use the efficiency-maximizing capability of spending unconfirmed coins between trusted wallets/entities. We aren't reinventing the wheel here.

Bitcoin is not monero. the impact of reorgs is not the same, their threat model is not the same

the comparison is useless.

If there are network privacy/security implications that's one question. Calling it a useless feature is clearly wrong.

monero reorgs invalidate txns, bitcoin reorgs don't.

there are fundamental differences in how the two blockchains work that makes the comparison meaningless

We've explained how spending unconfirmed coins are useful in a commercial setting. Whether that's technically feasible post-Seraphis is not for me to say. If it's feasible - it should be done.

* to say, I don't have the expertise. If

s/We've explained how spending unconfirmed coins are useful in a commercial setting. Whether that's technically feasible post-Seraphis is not for me to say. If it's feasible - it should be done./We've explained how spending unconfirmed coins is useful in a commercial setting. Whether that's technically feasible post-Seraphis is not for me to say, I don't have the expertise. If it's feasible - it should be done./

Bitcoin reorgs invalidate transactions if there is a double-spend. It is only the subset of the transactions that have double-spent outputs that are invalidated, however. Not all transactions, as is the case with Monero, due to Monero's reference-by-index-number system.

yes

From the user perspective, I think the mechanism of more confirmations = more secure transaction is pretty intuitive. I've never seen a new user misunderstand it. I think it's reasonable to ask users to exercise their own common sense on how many confirmations they should be waiting for when making a sale.

so eliminating the 10block wait would make "benign" reorgs destructive.

btw, hyc , how were the reorgs not destructive back when the 10-block wait time wasn't enforced at the protocol level?

BusyBoredom[m]: that's just BS. just like Zcash relying on users to decide if they need privacy or not.

alex[m]123456721: they were enforced by the wallets.

im aware

Despite that, there were txs that spent unconfirmed coins made by custom wallets.

Weren't there?

and then people started patching their wallet software to bypass the wait. and then users started losing txns.

you think moving the enforcement into the protocol level was just done for fun'n'games?

So coins were getting lost?

the coins don't get lost - the txns become invalid, so the coins go back to the wallets.

but people think they sent a txn and it doesn't happen.

Not a big deal, send a new tx.

and users have to do a rescan_bc to see their coins again

Not rescan_spent?

"not a big deal" - waiting for 10 blocks isn't a big deal either

Yes it is, if it has to happen literally every time.

Whereas rebroadcasting a tx only rarely.

it only has to happen the first time anyone receives funds.

it's like having to wait a short while before you can use a newly opened bacnk account. big deal.

You seem to be ignoring the fact that trading platforms create a situation where new wallets are created all the time, such as in Haveno.

is it more than once per user?

It's once per trade.

I see hyc's point here too now, users sending monero and the monero not being sent is very bad UX even if it's rare.

I like Rucknium's approach -- let's get some data on how common reorgs are at different depths, and consider lowering the 10 block limit based on that data.

alex[m]123456721: the problem in Monero is you can maliciously invalidate other people’s tx with a reorg. This is very different (ie allows/causes much more frequent invalidation) from bitcoin where tx are only invalidated if a sender double-spends.

Would this be the same post-Seraphis?

consistency is better than guessing games, yes. a 10block wait for everyone is better UX than some users occasionally/randomly getting screwed.

To avoid 10-block lock with Seraphis, you don’t actually submit a tx to the blockchain. You make a partial tx spending an output from past 10 blocks, send it to the recipient, then when the output is spent they complete the tx and submit it.

spendable*

so the wait time doesn't go away

Monerujo is currently raising funding to work on, among other things, the following: "One-click creation of extra outputs allowing frequent spending"

This isn't just about frequent spending, it's also about essentially instant txs between wallets that trust each other.

I'm not saying "expose this feature to the consumer wallet", there are consumer needs and then there are enterprise needs, complete with their own risk/error tolerance/correction.

nioc: To me, creation of many outputs that will later need to be re-combined may create a privacy concern. A slight privacy concern, but a privacy concern nevertheless.

That already exists (assuming monerujo is using wallet2).

Maybe not super discoverable...

yes 1 click for the handicapped :)

or maybe not accessible in their wallet

<hyc> "consistency is better than..." <- Not "some users" and "randomly". Advanced users (mostly in the enterprise realm) that will be consciously implementing this, thus accepting the risk in order to reap the efficiency gains and having the know-how to deal with the failed txs, just like enterprise applications use other advanced features that consumers never touch.

I don't think one should base a protocol restriction purely on the average consumer risk profile and ignore enterprise applications.

It's one thing to say that this has network-wide privacy/security implications. If it does (post-Seraphis), then I don't think anyone would argue in favor of this. However, if the implications are purely that the advanced users that choose to implement this capability will have to deal with the complications that arise from it, then I think the protocol restriction needs to be lifted.

If 10-block lock was lifted, then you’d be able to fingerprint tx made by wallets that don’t internally enforce the lock. With the Seraphis method, tx chaining is done off-chain, so the locktime isn’t directly relevant (until you want finality).

Removing 10-block lock is only possible after changing how transactions reference ring members. They reference them by index, not by hash now, so any reorg invalidates them

UkoeHB: so it's like holding a tx signed by two wallets until the input from the parent transaction has 10 confirmations?

sech1: that point has been made multiple times. people like alex seem to think it's unimportant.

We could make txes reference ring members by offset or output pubkey. The downside of output pubkey only is tx size, but if we only do that for recent outputs, then most of the size increase does not apply.

this dependency could be "fixed" by using hashes for newly broadcasted txns, while still only storing indices in the DB.

It's not clear how to design the cutoff though. If it's wallet chosen, we create puddles again.

and the cost of 32byte hash per output vs 8byte index per output will be significant in terms of txn broadcast bandwidth

Unless someone finds a drawback to the mixed system, it might fix that wait while avoiding the drawback.

Ring indices are typically 2 byte (amortised). Does not change the point though.

use hashes for all tx members, but calculate its size/store them using indexes?

no "cutoff" needed, but indeed, broadcasting bandwidth

That's the old idea, but it makes for massive txes.

Hence why it never got done.

The problem is if you want big rings >100 members, and you can't reference them deterministically in any awy (which requires fixed indices), then your reference storage gets pretty big.

yeah, for large rings addressing by 32byte pubkey is kind of large

The mixed system still allows for procedural generation.

could leave the cutoff to 10 blocks :)

Mixed system?

<hyc> "sech1: that point has been..." <- I never said it's unimportant, I'm just asking if it's possible to remove the cap post-Seraphis without network-wide privacy/security implications. If the consequences of removing the restriction are only borne by the advanced user that is attempting to implement it then it's a good trade-off for the efficiency gains that one can get. I am also stating that there are important commercial

applications for spending unconfirmed outputs. If it's a possibility to do along with the protocol upgrade, I am, as a member of the Monero ecosystem, proposing that it should be done.

Mixed as in, use offsets for outputs older than, say, 10 blocks, pubkey otherwise.

then the issue is about outputs that disappear due to reorgs, that make decoys used on other transactions invalid

I don't have the technical expertise, I can only provide the commercial outlook on this question.

a listener that discovers these decoys disappearing could make assumptions about which of the other decoys is "real"

and transaction gets invalidated as well

Yes, that's a good point. Invalidated spends will get recreated soon with a new ring.

The wallet could maybe see that and blacklist those outputs for the next couple txes out, if possible.

so yes - there are significant privacy/security implications for such a change

For the network or just for the ones that choose to implement it?

for the network

Understood, thanks.

Do we have an ability to attach a bounty to a feature request?

If "I pledge N for completion of Y", sure. Manual though. That's what haveno is doing AIUI.

You could probably make a github issue and state the bounty there.

moneromooo: for the relevant usecase, being to immediately spend from newly created wallets, the blacklist won't help. there won't be any other outputs available to spend.

That is true, but it also will not happen a lot.

And if it happens, then you do lose some privacy, but not others.

(or you wait)

you wind up knowing with 100% certainty that some output has been spent. then all other wallets have to blacklist that output, and never use it as a decoy.

Not 100% certainty. Close, maybe :)

I think it's already technically possible to have some kind of payment channel between highly trusted parties. You just make a pair of unbroadcasted tx each spending money owned by one of the parties. Then with each state change of the channel, you update the tx to have new outputs (i.e. change outputs + outputs spending to the other party) to reflect the current state. Then send these updated tx to each other after each state change. If

you want to leave the channel, then you need to cross the 10block lock boundary. With Seraphis, this can be extended one step: close one 'channel' (i.e. send a message saying: this is the final state, let's be done), then open a new channel with another trusted party (where the initial state of the new channel is chained off the final state of the prior channel).

Wait. It does not get invalidated (unless the sender tries to double spend).

But there is really a lot of trust involved...

UkoeHB: Is this possible with the current wallet/daemon or would it need to have its source code be modified?

btw, sech1, any other rpi users, can you test PR#8001

it's working fine for me on my android phone

Not sure... my guess is you'd need new code.

<alex[m]123456721> "Do we have an ability to..." <- What we (Haveno) do is: we set bounties for a feature on our repository and then we open an issue in the monero repo where we refer to our issue with the bounty. We have 5 bounties at the moment. most of them already in progress: github.com/haveno-dex/haveno/issues…Aissue+is%3Aopen+label%3Aa%3Amonero

<alex[m]123456721> "Do we have an ability to..." <- You could do that "unofficially" by opening a bounty here that is connected to an open issue, like I have done here for Monerujo:

Then anyone who wants to see that feature implemented can donate to the bounty freely.

.merges

is there any documentation on how to parse the output of "/get_transaction_pool_hashes.bin"? Or can I get a pointer on where in the codebase to start looking?

IIRC it's the binary key value serialization code in contrib/epee/storages

Cool, thanks 👍️