04:26:37 <ajs_[m]> I was thinking about setting up BTCPayServer for xmr.radio store, but it might be not worth the hassle and monthly expense to setup a bitcoin full node
10:25:44 <tarkdools[m]> <ajs_[m]> "I was thinking about setting up..." <- did you see https://github.com/xmrsale/xmrSale/
11:19:59 <ajs_[m]> I saw the css proposal. is it working now?
11:34:15 <ajs_[m]> yeah, a donation button and WordPress plugin is nice, but not useful for current store.
11:35:30 <ajs_[m]> we are using Shopify with Globee for XMR payments and Coinbase Commerce for BTC, ETH, LTC, DOGE
12:23:25 <plowsof[m]> Is that all xmrsale is? Just a donation button? (the aggressive logo(?) makes it look like a randsomware page also) 
12:31:28 <plowsof[m]> SerHack gave a great response to the ccs proposal (ignore me^)
12:51:41 <ajs_[m]> from what I can tell
12:52:44 <ajs_[m]> 100 XMR just for a donation button does seem a little excessive
13:29:27 <plowsof[m]> Speaking of donations.. a little bird just told me there's a donation to the general fund > 10 XMR about to be tweeted 😄
13:38:13 <plowsof[m]> in about 15 minutes, a transparent piggy bank with a cute Monero logo on his nose is going to check here, and on github, for any messages from binaryfate with tx_id's in, if all is well it will be tweeted oink oink
13:44:56 <anhdres[m]> hey ajs_ would it be possible to set up a permanent url for the radio's audio stream? I'm a bit of a foobar/vlc guy.
13:47:31 <anhdres[m]> it's very useful for directories submissions, a lot of people get radio streams from syndicated stuff like tune.in, etc
13:52:22 <plowsof[m]> https://ais-edge08-live365-dal02.cdnstream.com/a64305 (this has been working since 29th July)
13:53:18 <plowsof[m]> https://twitter.com/WatchFund/status/1427266945418731521
13:57:26 <ajs_[m]> anhdres: above CDN link has been working for a few weeks
13:57:44 <ajs_[m]> don't know it will change though
13:58:34 <ajs_[m]> I'll set up a subdomain and point to it, so it changes I can update it from DNS 
14:03:16 <ajs_[m]> anhdres https://stream.xmr.radio
14:03:46 <ajs_[m]> I've submitted station to a few directories 
14:04:16 <ajs_[m]> https://xmr.radio/pages/directory-listings
14:05:51 <ajs_[m]> previously aired podcasts will be uploaded to Spotify https://open.spotify.com/show/73cTJseUbL7lIie5MCsNDc
14:06:04 <ajs_[m]> and DJ mixes to MixCloud 
14:06:30 <ajs_[m]> https://www.mixcloud.com/xmr_radio/
14:14:22 <anhdres[m]> <ajs_[m]> "https://www.mixcloud.com/xmr_rad" <- instant follow!
14:17:23 <anhdres[m]> <ajs_[m]> "anhdres https://stream.xmr.radio" <- giving out errors. I'll explore further
14:17:32 <anhdres[m]> maybe it0s me
14:17:40 <anhdres[m]>  * maybe it's me
14:18:04 <ajs_[m]> check with vpn
14:20:50 <ajs_[m]> stream is geoblocked since licensing only covers US, Canada, UK
14:23:13 <anhdres[m]> Ohhhh
14:23:24 <anhdres[m]> Not cool, damn licensing 
14:23:37 <anhdres[m]> 🤷‍♂️
14:24:11 <anhdres[m]> Well, step by step! Keep the great work ajs_ this is a cool project
17:25:06 <rottenwheel> https://mashable.com/archive/big-data-pregnancy
19:19:50 <BusyBoredom[m]> This seems like a neat idea (zero knowledge proofs for recursive compression of the blockchain): https://masked.medium.com/the-coda-protocol-bbcb4b212b13
19:19:50 <BusyBoredom[m]> Is there a reason we couldn't do something like it? 
19:20:35 <BusyBoredom[m]> ^That project rebranded to "Mina" now, here's the github: https://github.com/MinaProtocol/mina
19:31:24 <wfaressuissia> treat it as expensive compressing with very small archive size, so who is going to do this compressing for others is open question
19:32:13 <wfaressuissia> it isn't constant size blockchain, it's constant size proof for others that their balance is equal to M, but blockchain remains as large as everything else + someone is generating this recursive proofs for others
19:45:49 <BusyBoredom[m]> Would it not work to just roll it into how the nodes work? Node operators would be incentivized to calculate the proofs because the proofs reduce their storage requirements. 
19:47:14 <sethsimmons> The proofs do not reduce nodes storage reqs, as to produce proofs they have to have the entire blockchain.
19:48:45 <sethsimmons> It's just essentially a somewhat-trustless system for light nodes/light wallets if you have an account-based blockchain, which is awful for privacy, BTW.
19:48:52 <wfaressuissia> It doesn't reduce storage requirements for node operators, mining node would need full blockchain. The only benefit of that compression is that full node can provide constant size proof that some address A has balance M.
19:56:27 <BusyBoredom[m]> Ohhhhhh, man, that is disappointing, I understand now. Thank you guys for clearing that up for me. 
19:56:56 <sethsimmons> It's an interesting trick that can lighten load for clients, but they're using buzzwords to make it seem bigger than it is.
19:57:13 <sethsimmons> IMO
19:59:10 <BusyBoredom[m]> Yeah, I was picking up on the strong money grab vibes. Figures the constant size blockchain was too good to be true. 
19:59:31 <sethsimmons> Yeah it's just simply a marketing lie, sadly :/
19:59:33 <sethsimmons> The blockchain is what it is 
20:00:00 <sethsimmons> They're just implementing clients that can verify a simple SNARK and merkle tree
20:04:48 <BusyBoredom[m]> Well in that case, I'm back to liking this idea: https://www.reddit.com/r/Monero/comments/59is0u/a_modest_proposal_radical_pruning_for_longterm/
20:04:48 <BusyBoredom[m]> Just delete old blocks, haha. Kills long term storage, but I'd be a fan anyway.
20:08:28 <anarkiocrypto[m4> The point of a blockchain is that it's a historical ledger... you can't just delete old blocks... also what if the blocks that contain your unspent inputs from a few years ago are deleted and no node has them anymore... Unless I misunderstood this?
20:13:43 <BusyBoredom[m]> Haha, no you're 100% understanding. The proposal is to completely remove permanence from the currency -- old funds would just be lost forever if not moved before the rolling cutoff. 
20:15:29 <BusyBoredom[m]> It's pretty radical, but personally I support the idea. In my opinion (and for my use case), moving money once every couple years is a small price to pay for having an eternally manageable blockchain
20:15:55 <anarkiocrypto[m4> RIP hodlers, people with paper wallets, people who have Monero as emergency funds, people who found a forgotten Monero wallet on an old HDD from 2016...
20:17:06 <anarkiocrypto[m4> Imagine singlehandedly deleting people's money by removing old blocks...
20:17:12 <BusyBoredom[m]> Yeah, those people would be very hurt. It wouldn't be a decision to make on a whim, and it would need a long lead up to get users ready. 
20:17:44 <anarkiocrypto[m4> I am sure there will still be people who lose their money, even if you try to "get users ready".
20:17:47 <sethsimmons> If you want that functionality you could just rely on centralized checkpoints and ignore old blocks.
20:17:54 <sethsimmons> You don't have to verify old blocks.
20:18:04 <sethsimmons> You can opt-in to that type of radical pruning anytime.
20:18:27 <sethsimmons> Can do the same with wallets by just sweeping all funds and setting a new restore height just before that TX.
20:20:33 <BusyBoredom[m]> Oh man I like that idea Seth
20:22:15 <sethsimmons> Obviously you would "lose" transaction history but not funds.
20:22:33 <sethsimmons> And you're not ruining other people's lives/wallets by doing it against the whole shared blockchain haha
20:22:58 <plowsof[m]> It would be nice if we could create an 'offline' transaction of that same process (sweep all to ourselves) then in say 10 years, 'broadcast it'
20:23:02 <sethsimmons> Lose == not have unless you restored from original restore height.
20:23:27 <sethsimmons> plowsof[m]: You could AFAIK, though hard forks could possibly affect that if there were major changes, not sure.
20:23:54 <sethsimmons> But not sure the reasons to do that, could just restore seed before then, send TX, restore seed at new height
20:24:10 <sethsimmons> I guess it would save the initial early sync
20:25:56 <plowsof[m]> Wallets could even have a 'sweep all' offline tx in a 'recovery' folder for us to find in 10 years 
20:27:01 <plowsof[m]> Then debruyne would be like ' Hello, welcome to the year 2031, just transmit that file in the recovery folder ' 
20:27:07 <sethsimmons> XD
20:28:35 <BusyBoredom[m]> So if I were to opt in to something like this, and my node on my little server at home were only storing say, the last 100,000 blocks, what would happen if I received monero that hadn't been moved in 100,001 blocks? I wouldn't be able to see that transaction in my wallet without connecting to a normal node, right?
20:29:32 <BusyBoredom[m]> Well, the wallet would see the transaction, but wouldbn't be able to verify it with the information available from my mini remote node? 
20:39:55 <sethsimmons> <BusyBoredom[m]> "So if I were to opt in to someth" <- You couldn't validate it (I.e. mine it) but could still accept it.
20:40:59 <sethsimmons> Or could just request that block from a full node, like current pruned nodes do.
20:57:58 <BusyBoredom[m]> Oh I see, the fact that it is in the most recent block already means miners confirmed it's legit. So miners would be the only ones who'd need the full blockchain. 
20:57:58 <BusyBoredom[m]> Would zero conf be less secure on my theoretical mini node? I don't really understand what checks exist on zero conf. 
21:03:57 <sethsimmons> > <@busyboredom:monero.social> Oh I see, the fact that it is in the most recent block already means miners confirmed it's legit. So miners would be the only ones who'd need the full blockchain. 
21:03:57 <sethsimmons> > 
21:03:57 <sethsimmons> > Would zero conf be less secure on my theoretical mini node? I don't really understand what checks exist on zero conf. 
21:03:57 <sethsimmons> Yes, because you couldn't validate the inputs properly.
21:27:04 <BusyBoredom[m]> Got it, bummer. Thanks for entertaining all my questions Seth
21:42:08 <plowsof[m]> After that exchange with Seth i guess you could say that you'll ... OptOut™️ of that proposal 😎😎 .... oh come on.. tough crowd? 
22:06:33 <BusyBoredom[m]> Haha, yeah, losing zero conf security in the opt in idea would be a dealbreaker for me.