01:27:40 <Alex|LocalMonero> Any native Vietnamese speakers here?
02:24:31 <Alex|LocalMonero> <Torr> "Switching to Semver is a big..." <- We're already on semver. Semver accounts for the v0.x.x usecase https://semver.org/#spec-item-4 `Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.`
02:25:21 <Alex|LocalMonero> v1 implies that with seraphis the API will stabilize. It most likely won't.
02:25:21 * pyromaniaco[m] uploaded an image: (82KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/NTJNVEGUgtfFCTpdNKMyedcZ/IMG_20230322_232418.jpg >
02:25:27 <Alex|LocalMonero> pyromaniaco[m]: Do you have TG?
02:25:34 <pyromaniaco[m]> sorry for not answering you, I can't see the messages 
02:25:39 <pyromaniaco[m]> Alex|LocalMonero: yep
02:25:57 <Alex|LocalMonero> pyromaniaco[m]: I can see your messages, PM it to me.
02:26:04 <pyromaniaco[m]> t.me/pyromaniaco
02:55:10 <GorillaQuest[m]> Hello
02:58:42 <DanIsnotthemanBr> Hi Seth
03:22:00 <Torr> Alex|LocalMonero: No, we're not: https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions
03:23:00 <Torr> Alex|LocalMonero: Semver only has 3 core fields, i.e., 2 dots.
03:23:53 <Torr> Alex|LocalMonero: Realse data has to be appended with a dash or plus.
03:24:19 <Alex|LocalMonero> Oh yeah, I forgot that we use 3 dots.
03:24:22 <Alex|LocalMonero> My mistake.
03:24:24 <Torr> This "v0.18.2.0", is not Semver.
03:25:55 <Alex|LocalMonero> Still, I'd prefer if we stayed on v0 until we at least get rid of the major pain points for mass adoption, like the 10-block-lock.
03:26:19 <Alex|LocalMonero> Announcing version v1 without the 10-block-lock eliminated would be rather premature, I feel.
03:26:32 <Torr> Indeed, there are some big things cooking.
03:27:20 <Torr> Depending on how long they take to come out, it may not be too much of a deal.
03:28:06 <Torr> There will be big changes in the near future regardless of Seraphis, just for the nature and age of crypto in general.
03:32:34 <Alex|LocalMonero> On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies
03:32:34 <Alex|LocalMonero> “For instance, our analysis reveals that in the widely deployed Lightning Network, with 1% strategically chosen colluding nodes, the adversary can uniquely determine the originator for ≈ 50% of the total transactions in the network. In Dandelion, an adversary that controls 15% of the nodes has, on average, uncertainty among only 8 possible originators. Moreover, we observe that due to the way Dandelion and Dandelion++ are
03:32:34 <Alex|LocalMonero> designed, increasing the network size does not correspond to an increase in the anonymity set of potential originators. Alarmingly, our longitudinal analysis of the Lightning Network reveals rather an inverse trend—with the growth of the network, the overall anonymity decreases.”
03:32:45 <Alex|LocalMonero> https://pure.mpg.de/rest/items/item_3500837/component/file_3500838/content
03:34:08 <Alex|LocalMonero> > <@alex:agoradesk.com> On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0c0db099087798f89d528f7d17dca2b4497fde40>)
03:35:30 <Torr> 2nd layer "privacy" for ya
03:36:46 <Torr> Heading off now
03:36:49 <Torr> 'til later
03:41:44 <xmrfn[m]> You may wish to set some specific goals and get a known payout for the work, if you like: https://repo.getmonero.org/monero-project/ccs-proposals
03:42:31 <xmrfn[m]> s/repo/ccs/
04:04:24 <xmrfn[m]> I'd love to see the wallet pick a random available node from https://monero.fail/?onion=true and use it to broadcast
04:05:22 <xmrfn[m]> (I just wish there were an .onion for monero.fail ; if there is, it isn't noted in the HTTP reponse)
04:17:43 <politicalweasel[> Alex | LocalMonero | AgoraDesk: Dandelion++ does better: "Dandelion and Dandelion++ provide a low median entropy of 3 and 5 bit, respectively, when 20% of the nodes are adversarial." But yeah it's still not great
04:18:20 <politicalweasel[> 32 originators instead of 8
04:19:22 <Alex|LocalMonero> politicalweasel[: I would guess that once you've narrowed things down to 32 nodes it's very easy to narrow down further based on other metadata that you might possess.
04:21:47 <Alex|LocalMonero> Tor/i2p is aggressively censored in some regions, so for those regions a fallback to clearnet with dandelion would be OK.
04:22:07 <Alex|LocalMonero>  * Didn't expect the number to be so bad with dandelion. Perhaps natively integrating Tor/I2P for tx broadcasting is the preferable way to go. It certainly results in much faster tx propagation.
04:23:15 <politicalweasel[> Do you mean only use dandelion(++) when anon networks aren't available, or preferably use both but drop Tor if necessary?
04:24:02 <politicalweasel[> because the first wouldn't be possible without attaching extra metadata about where the tx was broadcasted from
04:29:38 <politicalweasel[> agreed that Tor/I2P should be used by default though regardless of the propagation system
04:31:23 <xmrfn[m]> > wouldn't be possible without attaching extra metadata about where the tx was broadcasted from
04:31:25 <xmrfn[m]> I don't think that's the case. Check for Tor/I2p connectivity, if not found use D++. The actual txn broadcast is the same no matter what network envelope it's sent in
04:32:36 <politicalweasel[> what happens at the next node, though? The first node could check for Tor but then what?
04:34:38 <xmrfn[m]> Oh, I was thinking client check. I mean, once the node gets it, it needs to know if it's D++ and if so possibly forward. But if a txn comes in over an anonymity network, its source is already obfuscated, right? Just process it
04:34:53 <xmrfn[m]> * thinking client (wallet) check. I
04:36:22 <xmrfn[m]> * thinking client (wallet) check. I, * process it (broadcast, "fluff phase" right away)
04:37:21 <politicalweasel[> yeah that's the metadata I was talking about. For the network to dynamically switch between D++ and "fast" propagation, the txn would need to have a flag attached to tell nodes which protocol to use
04:37:36 <xmrfn[m]> The only metadata that's leaked is that whoever did the txn, they were on <i2p/tor> and picking this .onion service node to broadcast to
04:38:59 <xmrfn[m]> I would think any txn that comes over anonymity wants "fast". Its source is already obfuscated.
04:40:38 <Alex|LocalMonero> politicalweasel[: AFAIK there's no way for a node to tell if it received a tx as a result of a d++ fluff or just a straight up broadcast
04:42:05 <Alex|LocalMonero> But for sending yeah the node would need to support both modes, as it does now because you can broadcast on tor/i2p without d++
04:43:17 <xmrfn[m]> Right D++ for clearnet only. If we get a txn over Tor, it's like the "stem" phase is done by the Tor network; we just broadcast. No "mode" necessary.
04:43:34 <xmrfn[m]> * just broadcast/fast mode. No
04:43:36 <Alex|LocalMonero> Right
04:45:09 <xmrfn[m]> The wallet client needs to know an .onion node to connect to, which is why I mentioned monero.fail
04:45:09 <xmrfn[m]> There are dozens of community-run open .onion nodes it's quite beautiful actually
04:45:10 <politicalweasel[> xmrfn:  That extra metadata should still be avoided. It gives attackers more information to work with. Plus the idea that Tor txns "want" fast propagation might not always be right. If anything Tor/I2P should be standardized and D++ could be modified to more aggressively "fluff" to reduce propagation times
04:45:31 <politicalweasel[> Alex|LocalMonero: Not right now, sure. But that could be changed easily
04:46:26 <politicalweasel[> (which is not what I want, to be clear)
04:46:28 <xmrfn[m]> What metadata? That someone somewhere picked this node? That's like knowing that "someone somewhere" used Silk Road. As long as different clients don't pick specific nodes, there's really nothing leaked
04:47:47 <xmrfn[m]> (ie, if everytime node "X" broadcasts, it means MyDumbWallet.exe did the txn)
04:48:04 <politicalweasel[> Knowing the node would be even worse, I was just thinking a flag to tell whether it was broadcasted via Tor or not. Either way that information is still attached to the transaction. If it really were "some transaction somewhere was broadcasted via Tor" then yeah that wouldn't be a big deal
04:48:16 <politicalweasel[> but that's not the case
04:49:15 <xmrfn[m]> The information about what network transport was used isn't really attached to the txn. It certainly never makes it into the blockchain.
04:50:14 <politicalweasel[> Then how do nodes know which mode to use? And yeah it doesn't make it on-chain but this whole conversation is about propagation-time attacks so that's not really the point
04:50:25 <xmrfn[m]> A malicious node could keep track of what IP addresses if got txns from and report them all to the FBICIAGAFAM. But that's why we use Tor/I2P -- the IP address won't tell them anything useful.
04:51:32 <xmrfn[m]> Oh... propagation-time attacks. Hm. Well there's always adding a random delay, quite apart from D++. I'm pretty sure we don't do that now.
05:03:09 <xmrfn[m]> I don't think of D++ as being primarily intended to obfuscate the time a txn was broadcast, but rather the IP address (and therefore potential geographic location). D++ stem phase is just a few network hops, a few seconds of "fuzzing" at most.
05:06:53 <xmrfn[m]> s/could/_could_/, s/if/it/
05:11:10 <politicalweasel[> Yes, D++ is intended to obscure where a txn came from. I'm pretty sure preventing basic timing fingerprinting is hopeless unless you're willing to wait days before your txn is confirmed. It's more than just a "few" seconds, IIRC. Transactions sometimes take a little while to appear in a wallet. Ideally we could get reliable network-wide broadcasting within a couple seconds
05:11:29 <politicalweasel[> 0-conf is quite slow right now, relatively speaking
05:17:00 <Alex|LocalMonero> <politicalweasel[> "0-conf is quite slow right now..." <- Try switching your broadcaster node to tor mode with d++ disabled. Tx propagation will be as fast as the pre-d++ days, it's awesome.
05:17:11 <xmrfn[m]> > preventing basic timing fingerprinting is hopeless unless you're willing to wait days before your txn is confirmed. 
05:17:11 <xmrfn[m]> I'm not sure. There are ~17k tx/day which comes down to 1 txn per ~5 sec. So adding a random delay up to (say) 20 seconds would potentially add value.
06:24:06 <DanIsnotthemanBr> https://nitter.net/stack_wallet/status/1638699864765915137#m
06:56:21 <Ponyeatitall[m]> .xmr
06:56:22 <Wallet> Ponyeatitall[m]: You must have bot account & be logged in
06:56:52 <xmrlover[m]> <DanIsnotthemanBr> "https://nitter.net/stack_wallet..." <- Wierdly enough i use both elite wallet and stack wallet 
13:44:17 <bridgerton[m]> <᷾s> bridge down?
13:48:14 <bridgerton[m]> <᷾s> last message was at 6:56 am utc
13:48:33 <bridgerton[m]> s/was/is/
14:18:23 <charuto> it's not down
17:45:32 <anarkiocrypto[m]> Kuno Fundraisers beta is live now: https://kuno.bitejo.com Will release the source code (as well as Bitejo's source code) soon. The source code is messy but functional.
20:01:12 <bridgerton[m]> <salami donators!> Like waas but without hosting it yourself
20:32:16 <anonimauzanto[m]> Are there any updates on when 0.18.2.1 will be released?
20:55:38 <Alex|LocalMonero> https://localmonero.co/the-monero-standard/weekly/46
21:01:44 <xmrack[m]> Alex | LocalMonero | AgoraDesk: matrix is messed up and can’t decrypt the PM you sent me. Can you try again
21:02:10 <Alex|LocalMonero> xmrack[m]: done
21:02:44 <xmrack[m]> Still broken. I had this issue with Ruck a while back, are your clients up to date?
21:02:57 <Alex|LocalMonero> yup
21:03:25 <Alex|LocalMonero> Hold on, let me try something.
21:04:02 <xmrack[m]> Okay
21:21:59 <ceetee[m]> <anarkiocrypto[m]> "Kuno Fundraisers beta is live..." <- Is bitejo.com also created and run by you?
21:54:12 <anarkiocrypto[m]> Yes, will release Bitejo's source code after Kuno.
23:39:12 <modul8[m]> <anarkiocrypto[m]> "Kuno Fundraisers beta is live..." <- Exciting. All the info at the bottom is great for new people.
23:40:45 <anarkiocrypto[m]> Here is the code: https://codeberg.org/Anarkio/kuno I apologize that it's messy, amateur-level and not fully tested. Hopefully some of it may be useful. The source code for Bitejo will hopefully be published tomorrow.
23:42:46 <bridgerton[m]> <Bon 💗> Thanks thats a w