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

<ajs_[m]> "I was thinking about setting up..." <- did you see github.com/xmrsale/xmrSale

I saw the css proposal. is it working now?

yeah, a donation button and WordPress plugin is nice, but not useful for current store.

we are using Shopify with Globee for XMR payments and Coinbase Commerce for BTC, ETH, LTC, DOGE

Is that all xmrsale is? Just a donation button? (the aggressive logo(?) makes it look like a randsomware page also)

SerHack gave a great response to the ccs proposal (ignore me^)

from what I can tell

100 XMR just for a donation button does seem a little excessive

Speaking of donations.. a little bird just told me there's a donation to the general fund > 10 XMR about to be tweeted 😄

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

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.

it's very useful for directories submissions, a lot of people get radio streams from syndicated stuff like tune.in, etc

ais-edge08-live365-dal02.cdnstream.com/a64305 (this has been working since 29th July)

anhdres: above CDN link has been working for a few weeks

don't know it will change though

I'll set up a subdomain and point to it, so it changes I can update it from DNS

anhdres stream.xmr.radio

I've submitted station to a few directories

previously aired podcasts will be uploaded to Spotify open.spotify.com/show/73cTJseUbL7lIie5MCsNDc

and DJ mixes to MixCloud

<ajs_[m]> "mixcloud.com/xmr_rad" <- instant follow!

<ajs_[m]> "anhdres stream.xmr.radio" <- giving out errors. I'll explore further

maybe it0s me

* maybe it's me

check with vpn

stream is geoblocked since licensing only covers US, Canada, UK

Ohhhh

Not cool, damn licensing

🤷‍♂️

Well, step by step! Keep the great work ajs_ this is a cool project

This seems like a neat idea (zero knowledge proofs for recursive compression of the blockchain): masked.medium.com/the-coda-protocol-bbcb4b212b13

Is there a reason we couldn't do something like it?

^That project rebranded to "Mina" now, here's the github: github.com/MinaProtocol/mina

treat it as expensive compressing with very small archive size, so who is going to do this compressing for others is open question

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

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.

The proofs do not reduce nodes storage reqs, as to produce proofs they have to have the entire blockchain.

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.

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.

Ohhhhhh, man, that is disappointing, I understand now. Thank you guys for clearing that up for me.

It's an interesting trick that can lighten load for clients, but they're using buzzwords to make it seem bigger than it is.

IMO

Yeah, I was picking up on the strong money grab vibes. Figures the constant size blockchain was too good to be true.

Yeah it's just simply a marketing lie, sadly :/

The blockchain is what it is

They're just implementing clients that can verify a simple SNARK and merkle tree

Well in that case, I'm back to liking this idea: reddit.com/r/Monero/comments/59is0u…oposal_radical_pruning_for_longterm

Just delete old blocks, haha. Kills long term storage, but I'd be a fan anyway.

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?

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.

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

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...

Imagine singlehandedly deleting people's money by removing old blocks...

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.

I am sure there will still be people who lose their money, even if you try to "get users ready".

If you want that functionality you could just rely on centralized checkpoints and ignore old blocks.

You don't have to verify old blocks.

You can opt-in to that type of radical pruning anytime.

Can do the same with wallets by just sweeping all funds and setting a new restore height just before that TX.

Oh man I like that idea Seth

Obviously you would "lose" transaction history but not funds.

And you're not ruining other people's lives/wallets by doing it against the whole shared blockchain haha

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'

Lose == not have unless you restored from original restore height.

plowsof[m]: You could AFAIK, though hard forks could possibly affect that if there were major changes, not sure.

But not sure the reasons to do that, could just restore seed before then, send TX, restore seed at new height

I guess it would save the initial early sync

Wallets could even have a 'sweep all' offline tx in a 'recovery' folder for us to find in 10 years

Then debruyne would be like ' Hello, welcome to the year 2031, just transmit that file in the recovery folder '

XD

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?

Well, the wallet would see the transaction, but wouldbn't be able to verify it with the information available from my mini remote node?

<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.

Or could just request that block from a full node, like current pruned nodes do.

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.

Would zero conf be less secure on my theoretical mini node? I don't really understand what checks exist on zero conf.

> <@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.

>

> Would zero conf be less secure on my theoretical mini node? I don't really understand what checks exist on zero conf.

Yes, because you couldn't validate the inputs properly.

Got it, bummer. Thanks for entertaining all my questions Seth

After that exchange with Seth i guess you could say that you'll ... OptOut™️ of that proposal 😎😎 .... oh come on.. tough crowd?

Haha, yeah, losing zero conf security in the opt in idea would be a dealbreaker for me.