08:33:10 <dEBRUYNE> Would it be prudent to schedule a meeting next week to discuss the plan re: Triptych? 
12:44:54 <rbrunner> A meeting within a reasonable time frame sounds good to me.
12:45:30 <rbrunner> Although personally I have a big practical problem there: I can't read the report, https://github.com/cypherstack/triptych-multisig/blob/main/main.pdf
12:46:19 <rbrunner> 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?
12:46:56 <rbrunner> Many more "rounds" than today to construct wallets? Much more complicated syncing after transacting? That sort of stuff.
12:54:51 <sgp_[m]> Just to be extremely clear though: Triptych is stalled for a reason
12:55:08 <sgp_[m]> It effectively wouldn't allow things like Haveno and Thorchain to work
12:55:54 <sgp_[m]> So it's probably best not to consider it a Triptych meeting; better as a "what to for next-gen protocol" meeting
12:56:46 <sgp_[m]> Because Seraphis and Lelantus Spark seem more appealing with easy multisig and no significant tradeoffs
12:59:51 <UkoeHB> Both would require moving to a new address format, which is a big tradeoff to think about (the main one).
13:05:09 <rbrunner> 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?
13:07:20 <UkoeHB> Wallets would make new address strings out of existing private keys.
13:07:47 <nioc> sgp_[m]: why wouldn't Haveno no longer work?  
13:08:28 <sgp_[m]> Haveno relies on efficient multisig as well
13:08:33 <rbrunner> I see. Is already clear what would happen with subaddresses in this scenario?
13:09:05 <UkoeHB> Yes you'd need to generate new subaddresses at each index.
13:09:06 <sgp_[m]> <UkoeHB> "Both would require moving to a..." <- Indeed, but it was generally decided that this is a better compromise than permanently complicated / inefficient multisig
13:10:38 <nioc> sgp_[m]: thx for understanding my bad grammar :)     
13:10:41 <nioc> didn't realize that that decision was made already
13:10:45 <rbrunner> Hmm, probably hard to tell how new addresses would play out in the real world.
13:11:42 <rbrunner> We don't make decisions, we only have "loose consensus", if anything :)
13:12:09 <nioc> even that :)
13:14:29 <sgp_[m]> Loose consensus is that we're open to changing addresses if it makes everything else easier
13:16:21 <Inge> 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
13:16:40 <Inge> changing addresses will still be a major pain, but not insurmountable
13:17:52 <rbrunner> 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.
13:18:20 <rbrunner> Or did I just miss that?
13:19:44 <UkoeHB> It's not clear to me either. IIRC sarang said it would require 1 or 2 more rounds of communication to make tx.
13:20:50 <rbrunner> Ah, ok. So not just signing and forward to next signer then, with finally submitting if enough signatures accumulated, right?
13:23:06 <rbrunner> 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.
13:23:07 <sgp_[m]> <rbrunner> "A little unfortunate that nobody..." <- It wasn't considered a priority when Triptych was designed
13:24:03 <rbrunner> 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.
13:29:02 <selsta> 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
13:30:55 <rbrunner> 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.
13:31:19 <rbrunner> On top of something which is already now about a magnitude more complicated than Bitcoin multisig
13:31:21 <selsta> Considering that safe multisig already requires 4 or more rounds, the multisig flow would be bothersome either way.
13:32:07 <rbrunner> And it might finally make multisig "by hand", like with single CLI wallet commands, infeasable.
13:35:10 <rbrunner> 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
13:35:30 <rbrunner> That was OpenBazaar. Result: A major PITA already with the multisig we have now.
13:45:02 <sgp_[m]> Unworkable in practice, not impossible
13:45:32 <tobtoht> 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 
13:45:33 <tobtoht> success of multisig and imo Triptych is dead in the water for this reason.
13:56:34 <Lyza> +1
13:56:51 <Lyza> improving multisig is vital to the ecosystem imo
13:58:51 <utxobr[m]> dn markets certainly appreciate
13:59:55 <utxobr[m]> *specially dnm, I mean
14:00:12 <rbrunner> Is that within reach with any Triptych alternative, setting up a multisig wallet without mandatory vendor or arbiter interaction?
14:00:27 <rbrunner> That would be a breakthrough ...
14:02:14 <tobtoht> rbrunner: The state of the art: https://github.com/haveno-dex/haveno/issues/86#issuecomment-901944553
14:04:35 <rbrunner> I see. The bleeding edge, so to say.
14:06:11 <rbrunner> UkoeHB: Is this an implementation of the approach you outlined in your book?
14:09:26 <tobtoht> 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.
14:09:33 <tobtoht> Monero is unlikely to support nLockTime since we hard fork transaction formats occasionally - but perhaps short term locks can be added in the future.
14:11:02 <UkoeHB> rbrunner: yes
14:11:23 <rbrunner> Alright, interesting.
14:16:28 <Lyza> <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
14:18:49 <Lyza> notor maybe I
14:20:36 <Lyza> 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?
14:20:53 <Lyza> or some 2 parties
14:22:22 <nioc> <sgp_[m]> Just to be extremely clear though: Triptych is stalled for a reason
14:22:22 <nioc> It effectively wouldn't allow things like Haveno and Thorchain to work
14:22:43 <nioc> woodser commented on Jul 11
14:22:43 <nioc> Note that efficient multisig creation is more an optimization than necessity now for Haveno.
14:22:44 <nioc> The protocol will lock both traders into multisig with only 1 output with or without efficient multisig.
14:23:29 <nioc> the peanut gallery is confused
14:26:55 <rbrunner> 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?
14:27:55 <nioc> https://github.com/haveno-dex/haveno/issues/86#issuecomment-901944553
14:29:50 <wfaressuissia> "https://raw.githubusercontent.com/cypherstack/triptych-multisig/main/main.pdf#page=2" the same possible with Triptych, there is only single "sends"
14:30:29 <wfaressuissia> the problem arises only when all members want to spend something from multisig wallet, not receive
14:30:56 <rbrunner> Yeah, I understood it as that, "tx creation"
14:43:17 <tobtoht> 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 
14:43:17 <tobtoht> bounds communication between buyer and vendor is required. Without an established relationship, buyers have little incentive to seek direct communication with a vendor.
14:43:35 <tobtoht> 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.
14:46:36 <Lyza> 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
16:04:48 <crypto_grampy[m]> What kind of advantages does Triptych have over Lelantus/Seraphis multisig aside?  
16:11:51 <UkoeHB> 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.
16:15:54 <UkoeHB> 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).
16:22:25 <gingeropolous> is there anything besides the new address format? that just seems a cumbersome thing to deal with, not really an advantage / disadvantage. 
16:23:38 <midipoet> where are the papers/outline for Spark/Seraphis found?
16:23:39 <crypto_grampy[m]> 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. 
16:23:39 <crypto_grampy[m]> 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.  
16:23:43 <UkoeHB> Not that I know of
16:24:10 <crypto_grampy[m]> * formats.  Any from-scratch chain can
16:24:44 <UkoeHB> midipoet: https://github.com/UkoeHB/Seraphis https://firo.org/blog/assets/Lelantus_Spark_230821.pdf
16:26:03 <midipoet> UkoeHB: thank you
16:26:41 <midipoet> Maybe we should just all move to Firo. Might be easier than trying to implement Spark onto Monero. 
16:27:01 <UkoeHB> 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.
16:31:53 <UkoeHB> 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.
16:35:17 <gingeropolous> who could we even get to review seraphis
16:35:37 <UkoeHB> Anyone who understands RingCT can understand Seraphis.
16:37:11 <sgp_[m]> So there are a few handful open to projects
16:37:28 <sgp_[m]> JP, Sarang, Surae, etc
16:37:54 <sgp_[m]> ZenGo probably
16:41:55 <gingeropolous> can seraphis do more than multisig? is there a way for it to get scripting?
16:42:16 <UkoeHB> scripting, for example?
16:42:32 <gingeropolous> ?
16:42:58 <UkoeHB> What's an example of something you want to do with scripting?
16:43:08 <gingeropolous> yah know all the smart contract nonsense
16:43:14 <atomfried[m]> 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
16:43:14 <atomfried[m]> 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 :/
16:43:16 <UkoeHB> Idk any of that stuff
16:44:01 <UkoeHB> atomfried[m]: https://github.com/UkoeHB/Seraphis
16:44:43 <UkoeHB> Seraphis is pretty similar to RingCT, it just rearranges a bit how tx proofs are done.
16:46:03 <UkoeHB> 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).
16:46:22 <atomfried[m]> 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?
16:46:35 <atomfried[m]> UkoeHB: thank a lot, i will read it right now
16:49:24 <Rucknium[m]> 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
16:49:24 <Rucknium[m]> https://electriccoin.co/blog/ecc-exploring-zcash-shielded-assets/
16:52:29 <gingeropolous> next we'll need masternodes and staking!
16:53:25 <atomfried[m]> <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
16:53:39 <UkoeHB> No this is the right channel
16:56:20 <UkoeHB> Yes an abstraction for the an tx protocol
16:56:26 <UkoeHB> an entire*
17:09:02 <luigi1111w> I don't think removing multisig is on the table
17:13:52 <UkoeHB> 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.
17:14:06 <isthmus> 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). 
17:14:06 <isthmus> 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
17:15:36 <hyc> private stablecoin? sounds like "Zcash is now aggressively pursuing new ways to scam users and investors"
17:16:45 <Rucknium[m]> 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". 
17:17:14 <isthmus> Here's a non-binding poll from august, programmability and user defined assets both garnered a decent amount of support https://vote.heliosvoting.org/helios/elections/5dd57b92-01ed-11ec-a0a8-ae3066fac55d/view
17:19:07 <hyc> 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
17:19:11 <rbrunner> 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.
17:19:15 <Rucknium[m]> BCH is also probably going to add a number of features at the protocol level in May. For more details see
17:19:15 <Rucknium[m]> https://read.cash/@Mr-Zwets/the-proposals-for-a-bitcoin-cash-smart-contract-upgrade-almost-nobody-knows-about-19eb3b4e
17:20:34 <rbrunner> And with quickly adding complex functionality, don't we know already how that will turn out?
17:20:37 <hyc> 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.
17:20:51 <rbrunner> I think hyc and I channel each other :)
17:20:59 <hyc> lol yeah, we seem to be on same page
17:21:31 <isthmus> 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
17:21:53 <isthmus> snarks/starks/whatever
17:22:14 <Rucknium[m]> rbrunner:  hyc  That may be the case. I am just providing information. Adding new features might not be right for Monero.
17:22:14 <hyc> if you're talking about implementing in a sidechain, that's already what Tari is doing right?
17:22:28 <hyc> so why do we even need to discuss it in monero itself?
17:23:50 <Rucknium[m]> 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.
17:24:18 <atomfried[m]> imo moneros killer feature is default privacy and thats works out pretty well for me ...
17:26:50 <UkoeHB> 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.
17:27:18 <hyc> +1 ^
17:27:40 <hyc> at the end of the day, anything that affects txn uniformity, and thus harms fungibility, is an automatic non-starter
17:28:10 <isthmus> "anything that affects txn uniformity ... is an automatic non-starter"< 100% agree
17:28:24 <tobtoht> hyc: +1
17:41:33 <Rucknium[m]> 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.
17:41:54 <Rucknium[m]> Of course, a rise in tx volume should not come at the cost of lower tx uniformity
17:42:44 <atomfried[m]> the anonymity set is everytime the same, currently 11 (if i am not wrong about this) 
17:44:15 <Rucknium[m]> The anonymity set, broadly defined, is more than just the ring size.
17:46:44 <UkoeHB> There are upper limits to how high tx volume can go before there are issues
17:48:00 <Rucknium[m]> Could you explain? Issues with node syncing? Orphaned blocks? Slow block construction by miners?
17:49:39 <atomfried[m]> initial block download and blockchain bloat are also an issue i guess 
17:51:08 <mcfranko[m]> 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
17:54:44 <UkoeHB> 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.
17:55:00 <UkoeHB> good*
17:58:15 <hyc> 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?
17:58:42 <UkoeHB> This can be done with Seraphis
17:58:49 <Rucknium[m]> 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
17:59:28 <UkoeHB> section 4.6.4 adjustment 1: https://github.com/UkoeHB/Seraphis
18:00:33 <mcfranko[m]> Are there any benchmarks that show how much monero's current software can handle?
18:01:04 <UkoeHB> MobileCoin's Fog is also designed to find outputs without reading amounts
18:01:15 <UkoeHB> mcfranko[m]: not that I know of
18:01:25 <mcfranko[m]> Ah
18:01:58 <UkoeHB> Well there is `tests/performance_tests` which has a bunch of stuff
18:02:10 <Rucknium[m]> mcfranko[m]: Does someone want to work on that? Seems important
18:03:24 <UkoeHB> > This can be done with Seraphis
18:03:24 <UkoeHB> Ah, actually it is independent of Seraphis, I just wrote about it there :p
18:03:37 <mcfranko[m]> 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
18:04:32 <mcfranko[m]> This would actually be a cool github feature come to think of it
18:04:33 <Rucknium[m]> I mean, first code for the benchmarks would have to be written
18:04:35 <hyc> would be good to get benchmarks across 4G networks etc
18:04:59 <mcfranko[m]> UkoeHB: I haven't looked at this, but this might be usable
18:05:36 <hyc> essentially we would want infrastructure like speedtest.net
18:05:46 <mcfranko[m]> Those tests probably don't handle stuff like bandiwdth and p2p stuff
18:06:02 <Rucknium[m]> A lot of BCH people have written stress tests for the BCH network and nodes. Could look to inspiration there.
18:06:12 <mcfranko[m]> Maybe something like scalenet but for monero would be useful as well
18:07:19 <hyc> 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
18:08:40 <mcfranko[m]> 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
18:08:56 <tobtoht> "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.
18:09:53 <mcfranko[m]> 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
18:11:15 <UkoeHB> To test upper limits of a testnet you'd probably need to disable dynamic block sizes.
18:11:33 <mcfranko[m]> Yeah, that's true
18:12:08 <mcfranko[m]> The dynamic block cap is determined by twice the median block size over some period of time right?
18:12:12 <mcfranko[m]> How long is that period of time
18:12:25 <UkoeHB> 69 days
18:12:55 <UkoeHB> You could probably just hack the block weight check to always return true.
18:21:32 <hyc> just assume a maxed out network. e.g. 1gbit network, continuous txn flow, max size blocks every 2 minutes
18:22:07 <hyc> then measure how fast a router+CPU+disk etc you need to successfully scan all txs
18:22:49 <Rucknium[m]> hyc: Is there a max block size? I do not fully understand how the adjustable blocksize works
18:23:21 <hyc> at a given network rate there are only so many txs that can be braodcast
18:23:43 <hyc> so assume every tx gets mined in first available block, then that's your max blocksize
18:24:04 <hyc> we don't care about the adjustment algo that reaches that size. we only care about the peak values.
18:24:28 <hyc> do the same measurement at other network rates, like 100Mbit, etc.
19:01:12 <hyc> UkoeHB: what's the status of Seraphis then, reviews of security model, PoCs, audits, etc?
19:02:20 <UkoeHB> The main content is done, PoC for performance testing is in progress, security model is in progress (coinstudent2048[ is working on this).
19:44:09 <dEBRUYNE> UkoeHB: What happens if a user sends funds to an address of the old format after a HF?
19:44:19 <dEBRUYNE> In case we switch to a protocol with a new address format
19:51:31 <UkoeHB> It would make an unspendable output
19:52:40 <UkoeHB> You’d need a new serialization to detect invalid addresses
20:16:08 <rbrunner> 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,
20:16:20 <rbrunner> and the new would not support old addresses in any way, seems to me
20:37:06 <UkoeHB> If hypothetically you made a old-style output, it would be unspendable
20:38:49 <dEBRUYNE> I guess it would be imperative for wallet software to reject old-style addresses
20:38:58 <dEBRUYNE> That combined with services upgrading should ensure no unspendable outputs are created
20:39:52 <UkoeHB> Right. Thankfully (in this case) there are only a couple transaction-builder implementations.
20:40:54 <dEBRUYNE> So basically a different address format is the only caveat (in a sense)?
20:42:40 <UkoeHB> Yeah. There is an option for longer addresses that are more powerful as well (built-in Janus mitigation https://github.com/monero-project/research-lab/issues/62#issuecomment-870147617, and more possible wallet permission structures).
20:44:16 <dEBRUYNE> How much longer would they factually be?
20:45:01 <UkoeHB> 1/3rd longer (32 bytes)
20:45:11 <dEBRUYNE> Due to the additional key right?
20:45:17 <UkoeHB> Yeah the ancillary key
20:54:38 <dEBRUYNE> ty
21:05:10 <atomfried[m]> 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?
21:06:23 <kayabaNerve> 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.
21:06:58 <atomfried[m]> 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
21:07:17 <UkoeHB> atomfried[m]: there is a network byte; we could probably increment all existing network bytes by 32 or something: https://xmr.llcoins.net/addresstests.html
21:12:25 <UkoeHB> 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 
21:12:25 <UkoeHB> data to another person who can finish your membership proof whenever they want, then submit the completed tx.
21:19:00 <UkoeHB> dEBRUYNE: here is a summary of address schemes https://usercontent.irccloud-cdn.com/file/Vwyk9iKg/seraphis_address_schemes.png
21:21:57 <UkoeHB> In practice it would probably be fine to remove Tier 1 from Plain B and Janus A
21:22:58 <UkoeHB> Due to change outputs, Tier 1 can usually detect spent outputs anyway (like in our current scheme).
21:24:12 <UkoeHB> IMO Plain B without Tier 1, and Janus C are the best options.
21:57:32 <sgp_[m]> > <@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
21:57:32 <sgp_[m]> > https://electriccoin.co/blog/ecc-exploring-zcash-shielded-assets/
21:57:32 <sgp_[m]> I think some people will use UDAs on Zcash, but this isn't a feature we need to bend over backwards for
21:57:46 <sgp_[m]> Paying transaction fees in ZEC is frankly terrible UX
21:58:21 <sgp_[m]> Haven at least allows paying fees other colored coins in their implementation
21:58:53 <sgp_[m]> But with wrapped assets and all sorts of other workarounds, I don't see this as something worth making huge compromises for
22:10:37 <dEBRUYNE> UkoeHB: ty