Would it be prudent to schedule a meeting next week to discuss the plan re: Triptych?

A meeting within a reasonable time frame sounds good to me.

Although personally I have a big practical problem there: I can't read the report, github.com/cypherstack/triptych-multisig/blob/main/main.pdf

What I would love to see was a "translation" of sorts of this: How different and how much more complicated would multisig transaction handling UI and UX be, with this implemented?

Many more "rounds" than today to construct wallets? Much more complicated syncing after transacting? That sort of stuff.

Just to be extremely clear though: Triptych is stalled for a reason

It effectively wouldn't allow things like Haveno and Thorchain to work

So it's probably best not to consider it a Triptych meeting; better as a "what to for next-gen protocol" meeting

Because Seraphis and Lelantus Spark seem more appealing with easy multisig and no significant tradeoffs

Both would require moving to a new address format, which is a big tradeoff to think about (the main one).

Just to make sure I understand that "new address format" thing right: Does that mean my wallets will convert and get a different address? Or I have to give up my existing wallets for new ones, with new addresses?

Wallets would make new address strings out of existing private keys.

sgp_[m]: why wouldn't Haveno no longer work?

Haveno relies on efficient multisig as well

I see. Is already clear what would happen with subaddresses in this scenario?

Yes you'd need to generate new subaddresses at each index.

<UkoeHB> "Both would require moving to a..." <- Indeed, but it was generally decided that this is a better compromise than permanently complicated / inefficient multisig

sgp_[m]: thx for understanding my bad grammar :)

didn't realize that that decision was made already

Hmm, probably hard to tell how new addresses would play out in the real world.

We don't make decisions, we only have "loose consensus", if anything :)

even that :)

Loose consensus is that we're open to changing addresses if it makes everything else easier

I think the community needed a little time to a) understand the issues with multisig and TripTych and b) the consequences of having impractical multisig moving forward

changing addresses will still be a major pain, but not insurmountable

A little unfortunate that nobody painted a clear picture so far just *how bad* that multisig would be. As I said, no chance for me to read the report and deduct that myself.

Or did I just miss that?

It's not clear to me either. IIRC sarang said it would require 1 or 2 more rounds of communication to make tx.

Ah, ok. So not just signing and forward to next signer then, with finally submitting if enough signatures accumulated, right?

Monero multisig as it is now can already be a pain if you can't get all participants to be online all the time, which can of course prove difficult.

<rbrunner> "A little unfortunate that nobody..." <- It wasn't considered a priority when Triptych was designed

I understand. I meant nobody sort of "translated" Sarang's report to practical UI / UX consequences. Maybe it's also a little bit too early to do that, who knows.

15:19 <UkoeHB> It's not clear to me either. IIRC sarang said it would require 1 or 2 more rounds of communication to make tx. <-- 1-2 extra rounds doesn't suddenly make multisig impossible for e.g. Haveno

Not impossible, no, I would not go as far as that. But it may make things slower and more brittle, with communication failures or people offline for some time.

On top of something which is already now about a magnitude more complicated than Bitcoin multisig

Considering that safe multisig already requires 4 or more rounds, the multisig flow would be bothersome either way.

And it might finally make multisig "by hand", like with single CLI wallet commands, infeasable.

I had investigated in detail how to put Monero 2/3 multisig into something that, unlike Haveno, wasn't designed with that already in mind

That was OpenBazaar. Result: A major PITA already with the multisig we have now.

Unworkable in practice, not impossible

The complexity of Monero's current multisig scheme makes it unworkable for escrowed transactions, which is multisig's primary real-world usecase. The lack of current multisig adoption indicates this. _Any_ added communication rounds and it's unlikely to see the light of day in any practical application. Efficient multisig (e.g. allowing buyers to set up multisig wallets without vendor interaction, and other optimizations) is critical to the

success of multisig and imo Triptych is dead in the water for this reason.

+1

improving multisig is vital to the ecosystem imo

dn markets certainly appreciate

*specially dnm, I mean

Is that within reach with any Triptych alternative, setting up a multisig wallet without mandatory vendor or arbiter interaction?

That would be a breakthrough ...

rbrunner: The state of the art: haveno-dex/haveno #86#issuecomment-901944553

I see. The bleeding edge, so to say.

UkoeHB: Is this an implementation of the approach you outlined in your book?

utxobr[m]: Any market that can disappear in the blink of an eye needs nLockTime in addition to efficient multisig to guarantee vendor payout. Vendors have little incentive to use it otherwise.

Monero is unlikely to support nLockTime since we hard fork transaction formats occasionally - but perhaps short term locks can be added in the future.

rbrunner: yes

Alright, interesting.

<tobtoht> markets will make it mandatory, I think. Then if the market disappears, it would still be in the interest of the buyer and seller to coordinate to release the funds either to maintain the relationship or if say the seller offers the buyer a fee for their help unlocking

notor maybe I

sorry maybe I'm missing the point I'm reading about nLockTime and missing the relevance. seems to ensure multisig wallets aren't paid out early, but doing so would require coordination between buyer and marketplace no?

or some 2 parties

<sgp_[m]> Just to be extremely clear though: Triptych is stalled for a reason

It effectively wouldn't allow things like Haveno and Thorchain to work

woodser commented on Jul 11

Note that efficient multisig creation is more an optimization than necessity now for Haveno.

The protocol will lock both traders into multisig with only 1 output with or without efficient multisig.

the peanut gallery is confused

You mean in sharp contrast to all the other people here who have total overview? :) Have a link to woodser's comment from July 11?

"raw.githubusercontent.com/cyphersta…ptych-multisig/main/main.pdf#page=2" the same possible with Triptych, there is only single "sends"

the problem arises only when all members want to spend something from multisig wallet, not receive

Yeah, I understood it as that, "tx creation"

Lyza: nLockTime (not to be confused with unlock time) works like this: a signed transaction becomes valid only after a certain time/blockheight in in the future. After the order is filled, the mediator provides the vendor with a (partially signed) nLockTime transaction that becomes valid, say, 90 days in the future. Should the mediator disappear, the vendor can withdraw their funds from escrow after the lock expires. This way, no out of

bounds communication between buyer and vendor is required. Without an established relationship, buyers have little incentive to seek direct communication with a vendor.

If the vendor attempts to use this mechanism to exit scam, the mediator can work with buyers to refund all escrowed funds before the lock expires.

okay yeah that's what I was initially thinking you meant --- it definitely sounds desirable, but I believe dnms would enforce multisig with or without it. right now xmr markets are completely custodial so anything is a step up, and I don't think this would be enough to keep most btc markets from wanting to switch. just my 2c, but yeah def useful

What kind of advantages does Triptych have over Lelantus/Seraphis multisig aside?

crypto_grampy[m]: Lelantus-Spark/Seraphis require a new address format (gotta gen new addresses from your privkeys, toss out old addresses), so Triptych would be easier to implement/roll out.

On the other hand, Spark/Seraphis can potentially: be more efficient, allow improved information recovery (i.e. robust full balance recovery with a view-only type wallet, including for multisig), allow transaction chaining (can improve atomic swaps UX), have better compatibility with future research (maybe/maybe not - just my feeling).

is there anything besides the new address format? that just seems a cumbersome thing to deal with, not really an advantage / disadvantage.

where are the papers/outline for Spark/Seraphis found?

Very cool. I think it would be valuable to the layman to see a rough comparison of the possible techs, upsides and downsides as well as what would still set Monero apart from say Firo in the event say Lelantus is adopted.

In my opinion, I think Monero's ability to adopt the best privacy technology and migrate whenever needed outweighs keeping things like stable address formats. Any chain can implement a new tech, but continually adapting is the challenge/value.

Not that I know of

* formats. Any from-scratch chain can

midipoet: github.com/UkoeHB/Seraphis firo.org/blog/assets/Lelantus_Spark_230821.pdf

UkoeHB: thank you

Maybe we should just all move to Firo. Might be easier than trying to implement Spark onto Monero.

crypto_grampy[m]: The preprints are still in-progress. It is better to wait until they are done before making big public-facing comparison infographic type things.

Btw to be clear: Seraphis is a tx protocol 'abstraction' - from my point of view Spark is technically a valid implementation of Seraphis. However the Seraphis paper has different implementation recommendations.

who could we even get to review seraphis

Anyone who understands RingCT can understand Seraphis.

So there are a few handful open to projects

JP, Sarang, Surae, etc

ZenGo probably

can seraphis do more than multisig? is there a way for it to get scripting?

scripting, for example?

?

What's an example of something you want to do with scripting?

yah know all the smart contract nonsense

is it ok to ask a stupid question in this channel? if not, just delete it :D I know that Triptych would allow bigger ring sizes and that the monero privacy comes from ring signatures(which in my understanding would be optimized with Triptych), stealth addresses and bulletproofs. Now with seraphis, which parts of the monero system would change? is it just a better version of Triptych or does it also change the bulletproof and

stealth addresses part of the protocol? where can i read about this? i am comfy reading papers, but i research graph theory so cryptography is not realy my professional expertise :/

Idk any of that stuff

atomfried[m]: github.com/UkoeHB/Seraphis

Seraphis is pretty similar to RingCT, it just rearranges a bit how tx proofs are done.

It is an 'abstraction', so it doesn't require any specific proof structures. Triptych is built around Groth/Bootle proofs - which can be used in Seraphis if you want (in practice, that's what you would use).

UkoeHB: with some scripting, HTLC, something like a monero lightning network could be possible (if thats something anybody would want to build) or am i wrong?

UkoeHB: thank a lot, i will read it right now

I don't know if anyone case what Zcash is doing, but it looks like they are adding "tokens". My concern is if Monero does not eventually add basic features that other coins have like scripting, or even removes features like multisig, it could be cruising for a bruising

next we'll need masternodes and staking!

<UkoeHB> "It is an 'abstraction', so it..." <- havent read into the pdf, so maybe this is a stupid question, but is it an abstraction for the whole transaction ecosystem(bulletproofs, stealth addresses, ring signatures) or just for one of the three parts. Again if this is the wrong channel for asking such stuff, just stop me :D

No this is the right channel

Yes an abstraction for the an tx protocol

an entire*

I don't think removing multisig is on the table

Rucknium[m]: IMO the first priority is making sure the core tech is solid. Then, if there are nice things to add, they can be added if they don't degrade privacy.

Hmm, for years Monero and Zcash have been roughly at feature parity. Zcash is now aggressively pursuing new functionality (user defined assets, zero knowledge comps, private stablecoin).

IIRC there might be a way that Monero could implement colored coins (fully encrypted & indistinguishable with no privacy concessions??) which might be an interesting avenue to explore if we want to keep our eye on ways to provide user defined assets without undercutting or impacting Monero's functionality as cash

private stablecoin? sounds like "Zcash is now aggressively pursuing new ways to scam users and investors"

BCH is having a boom in functionality as well. There is now the smartBCH sidechain that is ETH (EVM) compatible. It uses BCH for "gas".

Here's a non-binding poll from august, programmability and user defined assets both garnered a decent amount of support vote.heliosvoting.org/helios/electi…92-01ed-11ec-a0a8-ae3066fac55d/view

I see the worth in pursuing more buzzwords to boost marketing, public awareness and adoption. but from a technical standpoint, none of it is germane to the purpose of functioning as electronic cash

That's called "FOMO", people. "Coins are adding features left and right, quick, we want to be left behind." Yeah, right. Mostly chasing hypes, if you ask me.

BCH is also probably going to add a number of features at the protocol level in May. For more details see

And with quickly adding complex functionality, don't we know already how that will turn out?

pretty much every smart contract platform out there now has been abused/hacked/whatever. at least on those public chains the stolen funds can be traced and possibly retrieved.

I think hyc and I channel each other :)

lol yeah, we seem to be on same page

I'll probably get downvoted for this (RIP karma), but I think _some_ of the features like user-defined assets could actually be pretty useful and as long as they're implemented in indistinguishable zksnarks I don't see a technical or philosophical problem with it. Monero's has a long track record of implementing complex functionality quickly, e.g. RingCT

snarks/starks/whatever

rbrunner: hyc That may be the case. I am just providing information. Adding new features might not be right for Monero.

if you're talking about implementing in a sidechain, that's already what Tari is doing right?

so why do we even need to discuss it in monero itself?

hyc: BCH has Simple Ledger Protocol (SLP) tokens that are defined on-chain. They have been sort of niche so far and their functionality will probably be supplanted by smartBCH.

imo moneros killer feature is default privacy and thats works out pretty well for me ...

isthmus: I am a bit concerned that increasing how much the Monero blockchain can do means increasing tx volume. Aside from doing many things, it is also valuable to do one thing as good as possible.

+1 ^

at the end of the day, anything that affects txn uniformity, and thus harms fungibility, is an automatic non-starter

"anything that affects txn uniformity ... is an automatic non-starter"< 100% agree

hyc: +1

Isn't it the case that a higher transaction volume is better for privacy since it increases the anonymity set? It also makes a FloodXMR attack more expensive, ceteris paribus.

Of course, a rise in tx volume should not come at the cost of lower tx uniformity

the anonymity set is everytime the same, currently 11 (if i am not wrong about this)

The anonymity set, broadly defined, is more than just the ring size.

There are upper limits to how high tx volume can go before there are issues

Could you explain? Issues with node syncing? Orphaned blocks? Slow block construction by miners?

initial block download and blockchain bloat are also an issue i guess

atomfried[m]: Re this, monero really needs UTXO commitments and probably state expiry as well, given that Monero's UTXO set is just the set of every TXO every

Rucknium[m]: Idk what would break first, but there is no way the network can support infinite tx volume ^.^. One hard upper limit is the rate of checking the chain for owned outputs - if tx are added to the chain at a similar rate to how fast a low-end PC can scan for owned outputs, that is not goo.

good*

ooo. what if we had a way to use homomorphic encryption, so that a 3rd party could scan for your outputs without seeing their cleartext values?

This can be done with Seraphis

UkoeHB: An object of research would be to determine what a bottleneck might be and what may be the current limit with minimal required hardware specs

section 4.6.4 adjustment 1: github.com/UkoeHB/Seraphis

Are there any benchmarks that show how much monero's current software can handle?

MobileCoin's Fog is also designed to find outputs without reading amounts

mcfranko[m]: not that I know of

Ah

Well there is `tests/performance_tests` which has a bunch of stuff

mcfranko[m]: Does someone want to work on that? Seems important

> This can be done with Seraphis

Ah, actually it is independent of Seraphis, I just wrote about it there :p

What would be useful is to have somewhere where people can submit their own benchmarks so that we get a sense of how different hardware handles it

This would actually be a cool github feature come to think of it

I mean, first code for the benchmarks would have to be written

would be good to get benchmarks across 4G networks etc

UkoeHB: I haven't looked at this, but this might be usable

essentially we would want infrastructure like speedtest.net

Those tests probably don't handle stuff like bandiwdth and p2p stuff

A lot of BCH people have written stress tests for the BCH network and nodes. Could look to inspiration there.

Maybe something like scalenet but for monero would be useful as well

it's easy enough to setup a testnet with fixed-difficulty=<a low number> and start mining like crazy. then see how fast a wallet can keep up on a remote link

hyc: I think that a testnet that just has constant spam on it would be a little more useful, because in this scenario wallets would have to be downloading a lot more data in headers than otherwise

"so that a 3rd party ... cleartext values" -> Wallet synchronization over Tor is already getting close to it's practical limits (with tx volume being within an order of magnitude before it becomes a serious usability issue, if pruned tx size is not decreased). The limitation here being Tor average circuit bandwidth. So I would LOVE to see this.

I'm sure someone has already written some transaction spamming script, if you just pointed that towards a new testnet, I'm sure it wouldn't be that hard to setup on a vps

To test upper limits of a testnet you'd probably need to disable dynamic block sizes.

Yeah, that's true

The dynamic block cap is determined by twice the median block size over some period of time right?

How long is that period of time

69 days

You could probably just hack the block weight check to always return true.

just assume a maxed out network. e.g. 1gbit network, continuous txn flow, max size blocks every 2 minutes

then measure how fast a router+CPU+disk etc you need to successfully scan all txs

hyc: Is there a max block size? I do not fully understand how the adjustable blocksize works

at a given network rate there are only so many txs that can be braodcast

so assume every tx gets mined in first available block, then that's your max blocksize

we don't care about the adjustment algo that reaches that size. we only care about the peak values.

do the same measurement at other network rates, like 100Mbit, etc.

UkoeHB: what's the status of Seraphis then, reviews of security model, PoCs, audits, etc?

The main content is done, PoC for performance testing is in progress, security model is in progress (coinstudent2048[ is working on this).

UkoeHB: What happens if a user sends funds to an address of the old format after a HF?

In case we switch to a protocol with a new address format

It would make an unspendable output

You’d need a new serialization to detect invalid addresses

That would not be so easy, sending with an address of the old format, right? The old software would not sync to top of blockchain anymore,

and the new would not support old addresses in any way, seems to me

If hypothetically you made a old-style output, it would be unspendable

I guess it would be imperative for wallet software to reject old-style addresses

That combined with services upgrading should ensure no unspendable outputs are created

Right. Thankfully (in this case) there are only a couple transaction-builder implementations.

So basically a different address format is the only caveat (in a sense)?

Yeah. There is an option for longer addresses that are more powerful as well (built-in Janus mitigation monero-project/research-lab #62#issuecomment-870147617, and more possible wallet permission structures).

How much longer would they factually be?

1/3rd longer (32 bytes)

Due to the additional key right?

Yeah the ancillary key

ty

does a transaction not contain a version byte or something? someone would need to get the version byte right, but sending to an old address. or am i wrong here?

UkoeHB: TX chaining alone can be accomplished by allowing not using global indexes yet rather hashes, I believe. They wouldn't even be noticeable post-mortem if saved to the chain using global indexes. I believe existing TX signing would need to be ported to using the hash-referential version though to have that property.

all transactions with a version byte < the new version would be rejected, but then someone would have to create a transaction for the new version to an old address, that needs some kind of intention to do it wrong

atomfried[m]: there is a network byte; we could probably increment all existing network bytes by 32 or something: xmr.llcoins.net/addresstests.html

kayabaNerve: That would work with the existing protocol, but wouldn't work with deterministic ring member references (which I think are worthwhile for large ring sizes) + the current protocol. Seraphis/Spark allow deterministic ring members + tx chaining to be compatible because membership proofs can be 'postponed' until after you sign a tx with your private spend key. You can send some (relatively) unimportant cached

data to another person who can finish your membership proof whenever they want, then submit the completed tx.

dEBRUYNE: here is a summary of address schemes usercontent.irccloud-cdn.com/file/V…yk9iKg/seraphis_address_schemes.png

In practice it would probably be fine to remove Tier 1 from Plain B and Janus A

Due to change outputs, Tier 1 can usually detect spent outputs anyway (like in our current scheme).

IMO Plain B without Tier 1, and Janus C are the best options.

> <@rucknium:monero.social> I don't know if anyone case what Zcash is doing, but it looks like they are adding "tokens". My concern is if Monero does not eventually add basic features that other coins have like scripting, or even removes features like multisig, it could be cruising for a bruising

> electriccoin.co/blog/ecc-exploring-zcash-shielded-assets

I think some people will use UDAs on Zcash, but this isn't a feature we need to bend over backwards for

Paying transaction fees in ZEC is frankly terrible UX

Haven at least allows paying fees other colored coins in their implementation

But with wrapped assets and all sorts of other workarounds, I don't see this as something worth making huge compromises for

UkoeHB: ty