06:47:12 How would I go about creating a system which automatically does action upon first confirmation? Like some kind of digital goods shop which doesn't need human supervision? 06:47:46 :-X 06:57:08 Check existing ones, see what they do. Try #monero-community-dev, they'll likely have examples. 07:01:09 thank you 11:47:22 Exception: boost::wrapexcept --- my log is spammed by this all the time, is it normal? afterwards comes a stack trace 11:48:14 If by normal you mean expected, yes. If by normal you mean intended, no. 11:49:11 It is harmless, but fixing it would be nice. I fixed one years ago and a later patch reintroduced a similar one. Couldn't be arsed doing all the work again given the time it took the first time. 11:49:42 You can ignore it or silence it by adding *trace*:FATAL in the log settings if you're short on disk space. 14:40:42 I am trying to figure out which peer is giving me each transaction. If I `set_log net.p2p.msg:INFO` I get 14:41:03 ` I [:PORT> ] Received NOTIFY_NEW_TRANSACTIONS ( txes)` 14:41:06 Then 14:41:14 ` I Including transaction <>` 14:41:38 , one line for each of the `N` txs. But sometimes I get `NOTIFY_NEW_TRANSACTIONS` from two different peers at almost the same time. Then the specific `tx_hash`es from those two peers are mixed together in the list of log messages. Is there a better way to figure out which peer gave me each tx? Or should I try to use something like Wireshark? 14:42:10 Use the thread column to disentangle. 14:42:35 The format above suggests you're looking at hte console, but there's a bit more data in the log file. 14:43:42 Yes I am looking at the console. Thanks. I will see what I can learn from the thread column. 16:12:39 .merge+ 8396 16:12:39 Added 16:28:51 can someone who is familiar with out scaling algorithm review https://github.com/monero-project/monero/pull/8488 ? 17:24:15 does cuprate understand it boog900? 17:32:44 Hi, we are working on a draft CCS, not submitted yet, looking for reviewers and somebody that could do the work 17:34:16 to un-bork your i2p support and docs 17:34:54 What needs fixing for i2p? 17:36:00 get rid of unsupported and wonky i2p-zero and associated scripts; switch to our standard SAM API 17:38:03 that will work with both java and i2pd external routers 17:38:04 give up on trying to bundle or manage a router as was proposed in the existing bounty 17:38:04 this is the approach now used by bitcoin and libtorrent 17:41:23 it allows you to configure i2p tunnels to your needs from your side, remove the external scripts, and abandon any attempt to maintain your own router package that you clearly don't have the resources to do 17:43:59 we've done SAM presentations at several monerokons and DEFCON monero villages over the last 5 years, but no bites so far 17:46:44 so if we write up a step-by-step CCS, offer to contribute some of the funding, and promise to provide consulting, would that be enough to find somebody? Thats our hope 17:51:58 looking for reviewers "and someone that could do the work" hm 17:54:21 right. there's already 22.2 XMR on a i2p bounty with no progress. our proposal would, I think, be simpler, by abandoning the router management/control part 17:55:15 that you've been hung up on for over 10 years, first with kovri then i2p-zero 17:56:50 i2pd works fine? are you talking about the monero gui PR? https://github.com/monero-project/monero-gui/pull/4263 18:06:47 hadn't seen that 18:07:37 what's the status of it? 18:08:13 preland 18:08:42 our recommendation is that you switch to SAM, and don't attempt to bundle a router. Then your user docs become: 18:09:03 1) install i2pd or java i2p; 2) enable i2p in monero gui; done and done 18:09:50 "terrible" https://github.com/preland/monero-gui/commit/a7a4a0f0a990896af4a5c23de519c663f551d885 18:10:10 bitcoin now has thousands of monthy i2p nodes with this approach, and there's little to no maintenance burden 18:10:40 I had gotten i2pd bundled and running, although I was having issues with it connecting logs back to the gui 18:11:01 Tbh I was already thinking of making it so that you can use it non-bundled 18:11:32 I2P is *much* more usable when it isn’t constantly turned on and off anyways 18:12:22 I assume the bundling is why the pull and the bounty at https://bounties.monero.social/posts/32/ are stuck 18:12:22 right 18:12:35 Yeah the commit desc says it for that one 18:12:35 My current work on my local repo is better, but not rly ready atm 18:12:59 I could eventually pick up the i2p stuff, although it wasnt explicitly mentioned in my last funding proposal so it might be a while 18:13:42 so we're offering a detailed roadmap forward, with an offer of consulting help, some XMR from our side as motivation for somebody, following an approach proven by bitcoin 18:13:59 The reason is actually that the prior dev before me was trying to integrate using I2P-zero’s spec, which doesn’t rly work for any other implementation 18:13:59 Also wait is this the actual zzz? 18:14:14 yup 18:14:35 I thought you had died xD 18:14:47 resurrected 18:15:10 Yeah if the bounty can be reworded to make it not bundled I could probably get it working much quicker 18:16:03 The issue would then be more on the side of node discovery using I2P, since it’s a closed network as opposed to a more open one like Tor 18:17:23 Tbh I haven’t worked on the bounty in a bit over the week because of some other work I was/is/am doing for Haveno 18:19:43 Is there a link to this somewhere? 18:24:15 The gui is made for newbs. There’s a significant user benefit to being able to flip a switch and have a private mode enabled. We see this type of functionality in feather, stack wallet on mobile as well as cake, I believe and I imagine this feature gets a lot of use. Asking users to download and set up i2p eliminates a lot of people from ever using that feature. 18:26:29 This is fair, but you should be aware that there are significant downsides to having I2P ran in this way 18:26:30 From an engineering perspective, of course it’s more overhead. That overhead saves thousands of people a lot of time 18:30:34 These protocols should be made to be incorporated into apps. Asking users to set up tor/i2p is just not how 98% of people use their phones and even desktops today. Power users are probably not using Monero gui and they’re fluently using i2p/tor. I know this is going beyond the topic of this channel. Happy to see zzz here, too, but I thought I’d give a little perspective fro 18:30:34 m a non power user. 18:33:52 fwiw, @janowitz on twitter advised me a CCS would get "funded in no time", the crowd here sounds a lot more skeptical 18:34:16 which is fine, that's why I'm looking for somebody to take a look at our draft 18:34:29 I also think it would get funded in no time as well 😁 18:34:44 I hope it does 18:34:59 Id be happy to donate 18:35:12 Forgive me for asking, but do you still have access to your gpg keys? 18:36:12 yes 18:36:55 and I also have control of stats.i2p and zzz.i2p as always 18:37:25 as somebody who runs i2p on a separate machine, i would like to be able to just plug my config into monerod and have it use my existing setup 18:37:50 Are those sites back up? I haven’t been on i2p in a bit tbh 18:38:08 you can also look on our github or gitlab to see my signed checkins 18:38:09 yes 18:38:42 I think the best middle ground would be to have a direct download linked in the gui 18:39:05 Ooh I’ll have to check that when I’m back to my computer in a few 18:39:09 if you move away from socks to sam, then existing users would have to turn off their socks tunnels snex 18:42:00 ok can't get anybody to bite to even ask for the draft CCS? 18:42:15 To see if we are somewhat on the same page, would the idea be something like this: 18:42:16 Monero sends requests on port X, which has an eepservice running on it to handle tx stuff; and for node syncing we—(cont.) 18:42:29 I think I asked for a link a bit ago 18:42:41 so I'll do it this way. Link is in the top post on zzz.i2p :) 18:42:57 Lol 😂 18:43:13 that gives you the draft and proof :) 18:43:15 There still isn’t an iOS I2P router right😂 18:43:24 nope 18:43:47 do you need multiple ports? one for tx and one for syncing? 18:43:48 Tbh I may make one someday out of boredom 18:44:58 It depends tbh; I think I’d have to recheck to see, but the current way we were doing it would have one port for txs but would still sync on clearnet 18:45:45 our draft specifies you support a i2p-only mode 18:45:52 The extra port would come into play if you were to replace the clearnet with a connection with an http outproxy 18:45:52 Which does actually work, if you have a million years to sync from block 1 18:45:55 and a "mixed" mode 18:46:14 That’s good 18:46:39 It’s the way I would’ve done it anyways 18:46:49 we would highly discourage trying to do IBD or even syncing via outproxy, and we'd require you to get approval from our outproxy op for that 18:47:33 Ideally the outproxy would be one you setup yourself 18:47:34 Though tbh a solution not relying on an outproxy would be ideal 18:47:39 i2p-only means really i2p-only 18:47:51 Hmm 18:49:39 It should be noted that at some point there would be a connection outside of I2P (otherwise the network would be completely isolated 18:49:54 ofc 18:50:30 It’s unfortunately quite the mind bender: I2P is a closed network, so to integrate Monero into it will require some form of communication outside of the network 18:50:54 so provide two options, i2p-only and mixed, default mixed, and you'll have hundreds or thousands of i2p nodes and it will all stay synced 18:51:04 It’s simple to find a solution; difficult to find a satisfactory one 18:51:15 That should be good 18:52:01 We will probably have to add a disclaimer for the i2p only nodes that their node could risk becoming isolated from the rest of the network 18:52:28 Unless there was a way to check if the nodes you are connected to are i2p-only or mixed 18:52:32 what you have now that you didn't a couple years ago is bitcoin showing you exactly how to do it. Why they got there before a "privacy coin" I'm not sure... 18:53:27 Tbh I’m not sure either 18:53:32 Actually what am I saying lol 18:53:42 Most of it stems from i2pd 18:54:21 Only recently were contributions from Monero devs even allowed to i2pd 18:54:22 It was explicitly disallowed to be associated with Monero and develop for i2pd 18:54:45 well if you and them dont get along, why are you trying to bundle them? 18:54:54 And since i2pd is the only C++ i2p client (or at least the most well known) 18:55:12 It’s not an issue now; it’s resolved 18:55:13 Just explaining some past history 18:55:18 just use router-agnostic SAM, supported by both, let the users do the install 18:56:30 That is probably the best approach moving forwards 18:57:34 sure it's a long history, but we've been banging the SAM drum at your parties for years, and there's 500 lines of SAM code over there in bitcoin that you can yank and you're half done (license permitting) or a SAM lib we support (ditto) 18:57:39 Thinking of the onboarding experience, how long should a new I2P user have to wait for their connection to the network to be integrated? 19:00:42 first i2p install? 5 minutes usually good enough for low-bandwidth usage, esp. if not firewalled or they have UPnP 19:01:36 Ok, that’s good 19:02:36 I think I’ll take a look at it 19:02:57 so how many XMR you need to put this on the top of your list? 20:32:38 Haveno is currently in a bit of a lull, so I think I can return the i2p development to my attention. 23:49:06 .merge+ 8488 23:49:06 Added 23:50:15 .merge+ 9252 23:50:15 ...