01:00:17 <revuoxmr> Revuo Monero. Issue 158: February 2 - 9, 2023. http://revuo-xmr.com/issue-158.html
07:47:46 <LZA_MENACE> cool repo plowsof11 :)
08:56:08 <hyc> so it seems both Tor and i2p networks are under massive DDOS attacks now
08:56:19 <hyc> anyone noticing problems with tor or i2p on their monerod?
09:05:22 <cockliuser[m]> Tor was always being massively DDOSed
09:29:19 <DanIsnotthemanBr> When isn’t it
11:58:12 <selsta> hyc: what problems are you seeing?
12:27:29 <hyc> my monerod had no i2p connections today, i2pd was logging a continuous stream of garbage
12:28:01 <hyc> 06:25:25@195/error - Streaming: No packets have been received yet
12:28:11 <hyc> over and over, filling the log file
12:28:44 <hyc> I upgraded from 2.42 to 2.45 today just in case. started getting connections again after restart.
12:29:45 <hyc> now I'm getting a ton of this
12:29:46 <hyc> 7:28:52@425/warn - Transports: Session to peer 5zK8kR2onFu2G~B9An8DISLAIiUO2PJSSyZK~T9RzJU= has not been created in 15 seconds
12:29:57 <hyc> so apparently sessions are timing out
13:36:44 <selsta> i still have i2p in / out peers but seems less than usual
13:41:52 <plowsof11> one of my nodes is seeing "Unable to send transaction(s), no available connections" in the logs - but the other not / is fine 
13:46:23 <selsta> hyc: https://www.reddit.com/r/i2p/comments/10wln04/news_and_weather_updates/
13:46:54 <selsta> i2p has been getting ddosed for the past 5 days
13:47:59 <selsta> java i2p is handling the issue better than i2pd according to the devs
14:30:38 <ocb> i2pd crashing here every few weeks, haven't had the time to debug
14:55:57 <bridgerton[m]> <Encore> ocb: Build i2pd from scratch
14:56:01 <bridgerton[m]> <Encore> or wait for the binary release
14:56:23 <bridgerton[m]> s/scratch/source/
14:57:02 <ocb> will give it a try in the evening
14:57:22 <bridgerton[m]> <Encore> careful because the makefile will overwrite your i2pd.conf and tunnels.conf
14:57:36 <bridgerton[m]> <Encore> found that out the hard way
14:59:23 <xfedex[m]> i2p is way smaller than tor however it seems to be handling DDoS better
15:00:22 <xfedex[m]> i wonder who is ddosing i2p, and why
15:00:31 <bridgerton[m]> <Encore> it hasn't suffered DoS attacks much, and all this will accomplish in the end is a more resilient i2p network
15:02:40 <ocb> thanks for the heads up
15:08:01 <bridgerton[m]> <᷾s> I'd say the scale of the DDOS is much smaller than the perpetual TOR DDOS
15:26:15 <dANBs[m]> ZHOSKA[xmpp]: I2P developers are already working on the causes and vulnerabilities that broke the network recently
20:13:42 * ofrnxmr[m] uploaded an image: (32KiB) < https://libera.ems.host/_matrix/media/v3/download/monero.social/ZKwLMLfLrOzJVFmDaOnLrREE/kv0c61zp06xxmcay.jpg >
20:18:53 <ofrnxmr[m]> https://twitter.com/HodlDee/status/1624110183558283269
20:18:59 <ofrnxmr[m]> "What are we going to do?!?! We cant just fork"
20:19:02 <ofrnxmr[m]> Lmfao
20:19:22 <atomfried[m]> <ofrnxmr[m]> "kv0c61zp06xxmcay.jpg" <- what the actual hel
20:19:25 <atomfried[m]> s/hel/hell/
20:19:38 <ofrnxmr[m]> Its purging transactions too
20:20:41 * ofrnxmr[m] uploaded an image: (44KiB) < https://libera.ems.host/_matrix/media/v3/download/monero.social/PNgLFNGnaPaUuVJBJwBngYZm/aunjnogyrafq5p5m.jpg >
20:21:06 <ofrnxmr[m]> This is bitcoin scalingb
20:21:22 <ofrnxmr[m]> Wheres lightning? 🙊
20:22:24 <ofrnxmr[m]> "Pay more for an inscription like an nft"
20:22:24 <ofrnxmr[m]> So much for "it IS fungible"
20:37:13 <xfedex[m]> bitcoin borkchain
20:39:20 <xfedex[m]> up to 3 TPS, 1 TPS when someone is uploading NFTs
20:48:09 <bridgerton[m]> <BobbedBort> also the mempool.space transaction fee predictions don't tell you the full story
20:48:53 <bridgerton[m]> <BobbedBort> checking the last block for example the average fee was $1.55 for 5.3k fees in total
20:49:04 <bridgerton[m]> <BobbedBort> highest fee paid was $205.16
20:49:40 <Rucknium[m]> Median or another percentile is more informative than average sats/byte
20:54:53 <bridgerton[m]> <BobbedBort> True, it's kind of hard to describe Bitcoin fees because they can reach from cents to hundreds of dollars. The median seems to be $0.78 btw, with R giving me a SD of 6.7.
21:05:35 <Rucknium[m]> What are you using to parse the data? Just curious.
21:07:58 <drewski[m]> any atomic swaps / CEX that support xmr > btc lightning?
21:08:51 <bridgerton[m]> <kemosabe> https://trocador.app
21:09:26 <drewski[m]> thanks
21:11:35 <drewski[m]> this should be on kycnot.me
21:12:45 <ofrnxmr[m]> It is
21:13:16 <drewski[m]> hmm, it gives me error 500 when I click exchange though
21:13:42 <ofrnxmr[m]> https://kycnot.me/service/trocador
21:13:46 <bridgerton[m]> <BobbedBort> > What are you using to parse the data? Just curious.
21:13:46 <bridgerton[m]> A while ago wrote some quick python script to get the transactions from blockchain.info and an accompanying very basic R script to make some plots with it.
21:13:56 <bridgerton[m]> <kemosabe> can retry or select a different exchange?
21:15:51 <drewski[m]> looks like fixedfloat is the only one
21:15:56 <drewski[m]> guess I'll just try their site
21:17:09 <Rucknium[m]> BobbedBort: If you want to parse data directly from the bitcoin daemon into R you can use https://cran.r-project.org/package=rbtc
21:18:08 <Rucknium[m]> If you want Bitcoin Cash data you can use this package, which is a port of rbtc by me: https://cran.r-project.org/package=rbch
21:18:51 <bridgerton[m]> <BobbedBort> Oh nice didn't know about them.
21:19:46 <bridgerton[m]> <kemosabe> 👍🏾
21:24:29 <Rucknium[m]> BobbedBort I've used the package for a couple of projects, e.g. https://rucknium.me/posts/pre-fork-btc-bch-spending/
21:28:24 <drewski[m]> oh, that's why it wasn't working. I was trying to use a btc lightning invoice rather than an address
21:28:49 <drewski[m]> is there any service that will exchange xmr > lightning invoice
21:35:11 <kurokame[m]> I have a question concerning view keys? Do they reveal outgoing txs or incoming txs or both?
21:50:30 <geonic> only incoming
21:51:42 <geonic> you need key images for outgoing
22:09:24 <caveman> i have an algorithm that may augment monero, but is not a cryptocurrency.  basically it's an algorithm to facilitate physical package deliveries in an anonymous-ish manner.  it may benefit from smart contracts.  does this channel welcome such discussions?
22:10:25 <caveman> the reason i care about anonymising physical deliveries is to complete the cycle of producing work (e.g. goods/services) and getting paid.  once this cycle is completed, we can have end-to-end free trade.
22:12:10 <caveman> here are the details: https://codeberg.org/ideas/delivery (work in progress)
22:13:13 <caveman> moneromooo: the link we spoke about https://codeberg.org/ideas/delivery 
22:13:43 <plowsof11> view keys give a high probability in seeing outgoing tx's too :( "heuristics" and crypto magic 
22:14:05 <caveman> moneromooo: the reason i care about anonymising physical deliveries is to complete the cycle of producing work (e.g. goods/services) and getting paid.  once this cycle is completed, we can have end-to-end free trade.
22:15:57 <plowsof11> caveman relax with the pings 
22:20:21 <caveman> plowsof11: i and moneromooo were in touch in another channel.  he asked me to post it here.  i'm not highlighting people randomly.  thanks for housekeeping the channel though (i agree, random highlights are a bad thing; spam = vandalism).
22:20:27 <moneromooo> Well, this really does not make any progress vs the oracle issue, does it.
22:20:55 <plowsof11> i can trade monero for uber eats voucher and have a delivery agent deliver me pizza 
22:21:01 <caveman> moneromooo: clarify please?
22:21:41 <moneromooo> I mean, how to tell whether the recipient received the package and/or the sender sent it, in a way that's verifiable ?
22:22:47 <moneromooo> Also, how to hide the set of hops from other hops. Tor does this: a router only sees the next hop, the rest is encrypted with the next hop's key, recursively (broadly speaking).
22:23:55 <caveman> both are addressed.  1st, when you deliver something to someone else, he can give you the decryption key of his hop meta-data.  you --too-- can decrypt it to verify that it is him.  if this is not desired, we can have a separate hop meta-data, maybe hop-external meta-data to let you verify that it is indeed him.
22:23:59 <anarkiocrypto[m]> For physical deliveries, it would be useful to have a place to pickup the package (I can't receive any mail to my home address). Where I live, there are convenience stores that allow you to send mail there and pick it up with a SMS code (no ID) as well as parcel lockers. But they only work for domestic mail and specific couriers. I wrote about a more decentralized network here: https://agorism.blog/anarkio/second-realm-ideas Dead drops
22:23:59 <anarkiocrypto[m]> or taxi delivery could also work.
22:24:08 <moneromooo> I'd reached the idea of physical remailers putting up a security on chain (and they'd lose it if they fail to remail), but this is still subject to the oracle problem really. Though at least people know to only send pakcages with a value below the posted bond.
22:24:25 <moneromooo> Anyway, this is an interesting problem.
22:24:26 <caveman> moneromooo: within the hop meta-data is a random number.  that random number, once uploaded, is a proof that he got it.
22:25:05 <moneromooo> Do you mean "the recipient will upload a number after receiving the package, proving htey got it" ?
22:25:19 <caveman> moneromooo: as for keeping hops constant, this is already in the algorithm.  in fact, number of hops are not corresponding with real hops either.  so, you may see 100 hops, but in reality there could be just 5 hops.  either way, this quantity does not shrink hop-to-hop.
22:25:46 <plowsof11> if they don't do that then they're mean imo
22:25:55 <caveman> <moneromooo> Do you mean "the recipient will upload a number after receiving the package, proving htey got it" ? 
22:25:56 <caveman> ^ anyone can upload.  at least so far as i think about it.  once that number is leaked, is a proof that the recipient got it.  i'm open to changing this, but this is my thought so far.
22:25:59 <moneromooo> This is backward. The sender needs to prove the recipient got it. The recipient needs to prove the sender sent it. All participants (sender, recipient, hops) need to prove all others did their job.
22:26:23 <anarkiocrypto[m]> Proxysto.re offers a physical place to pickup the packages as well as lockers (but it is only in Germany). ShopInBit.com lets you pickup your purchase at a cooperating crypto meetup.
22:26:43 <caveman> anarkiocrypto[m]: thanks for the link.  i'll read it.
22:27:35 <moneromooo> One thing that could maybe possibly work is drones running secure[1] software where the recipient can upload a route while the drone is being loaded. This implies short range though.
22:27:56 <plowsof11> if the customer has to 'decrypt the final hop' before being handed the package (somehow?)
22:28:04 <plowsof11> signed delivery
22:28:05 <moneromooo> [1] secure as is, the recipient can upload the route, and the route cannot be read back by the sender, and the route will be erased upon landing at the destination.
22:28:24 <moneromooo> Remote attestation could help ensure this.
22:28:34 <anarkiocrypto[m]> Many stores can only send to a residential address, so it's difficult to receive mail if you can't receive a package or letter to where you are currently staying (e.g. informal apartment rental without a name on the mailbox, staying with friends, van living, etc.). That's why last hops are necessary vs. a simple forwarding service that requires a residential address.
22:28:52 <anarkiocrypto[m]> Codeberg link isn't loading but will try it again to read the part about drones.
22:29:00 <moneromooo> The drone would need a key, with which the route would be encrypted, so only the drone's CPU can decrypt it.
22:29:19 <moneromooo> Very niche though.
22:29:40 <moneromooo> And of course anyone can follow the drone with another drone to see where it goes.
22:30:01 <moneromooo> Drones have short range though. Will get better with time.
22:30:54 <moneromooo> And you still get the issue of not being able to prove the package was loaded onto the drone. You get back to photos of the thing, which is really the oracle problem again.
22:31:18 <anarkiocrypto[m]> https://www.listennotes.com/podcasts/agora-the-podcast/episode-24-agorist-delivery-Kf3-LPYa8TW/
22:32:46 <anarkiocrypto[m]> I think the regular postal system works fine in most cases (stealth packaging works for DNMs) but the issue is receiving the packages somewhere (= finding a maildrop).
22:33:27 <caveman> anarkiocrypto[m]: my approach does not require a specific location, because it --instead-- uses an online database (distributed; off-topic though) that maps delivery agent's public key against the region that the agent is responsible of.  agents deliver to agents, in a hop-by-hop manner, until it reaches the destination.  
22:33:29 <caveman> agents are not different than senders ore receivers.  so worst case, a sender/receiver could lie that he is just a delivery agent.  plus, their locations can change all the time as they please to maximise their anonymity.
22:34:27 <anarkiocrypto[m]> Would you need to agree a time and place for in person delivery or a place for a dead drop?
22:35:14 <caveman> <moneromooo> This is backward. The sender needs to prove the recipient got it. The recipient needs to prove the sender sent it. All participants (sender, recipient, hops) need to prove all others did their job. 
22:35:14 <caveman> which one is backwards?  are you implying that my approach requires a specific order of verification that is backwards?
22:36:14 <caveman> anarkiocrypto[m]: the online distributed database should share such information for each delivery agent, including anonymous communication/messaging addresses so that they coordinate exact location and time to do the delivery.  because an agent could be responsible to a large area, so knowing the exact location/time helps.
22:36:19 <moneromooo> I meant "the recipient will upload a number after receiving the package, proving htey got it" is backward. It's not quite clear whether that is your scheme.
22:37:26 <caveman> anarkiocrypto[m]: further, there must be a reputation database, where senders, agents, receivers (all of which technically are indistinguishable from each other; they all look like delivery agents) can and should vote on each other.  some misbehaving people will essentially get bad reputation, which excludes them from future deliveries (or increase cost on them).
22:38:56 <caveman> <moneromooo> I meant "the recipient will upload a number after receiving the package, proving htey got it" is backward. It's not quite clear whether that is your scheme. 
22:38:57 <caveman> yeah.  that document is work in progress.  in reality, i'm open to changes.  as i said earlier, we could make it in such a way that there is a handshake between both the sender and receiver, at every delivery hop/agent, by which after the handshake both get the random number which serves as the proof of successful handover.  then either one can upload the number to confirm the delivery.
22:43:00 <caveman> anarkiocrypto[m]: glad that you thought about such a thing.  i'll bookmark your page and read it carefully in the future.  the amazing thing about such approaches is that, during peace-time, people can /tune/ their parameters in such a way that they function as distributed delivery systems at a lower cost than centralised ones, yet achieves the same reliability if not more.
22:51:39 <caveman> anarkiocrypto[m]: so far, my problem with your approach is that the sender/receiver is different than delivery agents.  e.g. a store can identify who is a sender/receiver at the registration phase.  my approach doesn't have this limitation.  instead, everyone looks like a delivery agent.  
22:51:43 <caveman> further, a delivery agent is not limited to a fixed area, but can change its operation.  a delivery agent carries its reputation with it, as reputations are bound to agents' public keys.  if an agent (be it, sender, receiver, middleman) cheats or misbehaves, he will get negative reputations, which effectively no only loses money for the current delivery, but also future deliveries as less people
22:51:43 <caveman> would use him.
22:56:50 <caveman> one of the side ideas that i have, which works with yours also (if i understood your idea right) is as follows:  we can automate such deliveries, such that agents operate autonomously.  i.e. a delivery agent sets up a drone with gps and remote controlling mechanism, then lets it operate on its own without radio signal to/from the master operator.
22:58:01 <caveman> in this setup, packages will have stickers on it with barcodes, qrcodes, RFIDs, nfc, bluetooth, etc -- whatever works, and the operator sets up the drone initially with gps coordinates, timing, etc.  then, the operator lets the drone work on its own.
22:58:47 <caveman> the more such drones that operate, the harder it will become for a central authority to suppress them.  this is because of the fact that it is harder for a central authority to hunt all drones on air than it is for individuals to manage a few drones each.
23:01:01 <caveman> the reason such ideas are very important in the context of cryptocurrencies is that they close the end-to-end trading loop:  payment and goods delivery.  currently, cryptocurrencies have done a reasonable job being anonymous.  however, physical delivery remains challenging, which is a reason why anonymous goods delivery is too hard/rare.
23:01:45 <caveman> once a physical delivery becomes anonymous enough, imo, we'll see a significant boost in the usage of cryptocurrencies.
23:04:24 <caveman> a neat side effect that i didn't think about is that, imo, the success of an anonymous-ish delivery system will highly likely boost the value of cryptocurrencies (as a direct side effect of increased usage of the cryptocurrencies)
23:05:33 <caveman> my focus is the utility of such approaches.  but it's hard to decouple their utility from increased value of cryptocurrencies.
23:24:22 <anarkiocrypto[m]> Maybe you would be interested in this (about accessing services without government ID, including mail, sim cards, apartments, etc.): https://agorism.blog/anarkio/survival-outside-the-state
23:27:47 <caveman> thanks.  great link.  reading..