<t​hemisplacedphilosopher:matrix.org> If you convert XLM to USDC on Stellar, you can withdraw cash at Moneygram outlets.

<k​inghat:matrix.org> SNIPA!

Yash?

<k​inghat:matrix.org> miss you long time 🤗

Not like I ever really left IRC. :P

<j​ay_edwards:matrix.org> Isn't it better to use some services like simpleswap, changenow, Exolix? No route to Stellar, direct swap only and no KYC

<u​mask777:decred.org> it depends on what better means really

<u​mask777:decred.org> if you're just trying to do a cheap swap, they're worse

<u​mask777:decred.org> they're extra intermediaries so they take their cut

<o​we_addams:matrix.org> you are right, but on the other side, it's comfortable to use and if you don't swap a huge sum, the fee won't be very high

<u​mask777:decred.org> comfort costs ;)

<b​asses:matrix.org> redlib.nadeko.net/r/Monero/comments…adoption/lye387j/?context=3#lye387j

<b​asses:matrix.org> >replace it by a new one. UI and UX is terrible normal users don’t need to see or understand why a wallet needs to be “synchronized” no one wants to wait 5 minutes until your wallet is synchronized if it hasn’t been opened during a whole month.

<b​asses:matrix.org> Looking forward for github.com/vtnerd/monero-lws

<o​frnxmr:monero.social> Unstoppable wallet sync wallets too

<o​frnxmr:monero.social> Its faster than monero, but far from instant

<p​lowsof:matrix.org> is monero-lws a better solution for merchants who want to only view incoming transactions with private view key than wallet-rpc 🤔

<o​frnxmr:xmr.mx> Probably yes, since it uses push instead of pull

<o​frnxmr:xmr.mx> Zmq vs autorefresh

<o​frnxmr:xmr.mx> Xmrchat is a good example, probably

<s​ervers.guru:matrix.servers.guru> Would it be possible to setup some subscription system in monero?

<s​ervers.guru:matrix.servers.guru> I mean technically.

<o​frnxmr:xmr.mx> Luke Profits has an app called "moneor subscription wallet"

<s​ervers.guru:matrix.servers.guru> Not sure how, but a way to setup something that x wallet is allowed to take y amount from z wallet every x2 time until z wallet cancel it.

<s​ervers.guru:matrix.servers.guru> I know about that I think but it requires to have the app constantly running.

<s​ervers.guru:matrix.servers.guru> I mean integrated inside the monero protocol.

<o​frnxmr:xmr.mx> Anything like this would have to be custodial

<o​frnxmr:xmr.mx> I imagine the better route would be to just send payment notifications like anything else

<s​ervers.guru:matrix.servers.guru> I was thinking more something in a smart contract kind of way.

<s​ervers.guru:matrix.servers.guru> Integrated in the block chain.

<s​ervers.guru:matrix.servers.guru> Integrated in the blockchain.

does something exist outside of monero like this?

<o​frnxmr:xmr.mx> Atomic swaps for service :P

<s​ervers.guru:matrix.servers.guru> Due to monero being one of the only crypto actually used for payment that could be a big advantage if possible

<s​ervers.guru:matrix.servers.guru> Not that I am aware of. Hence the advantage.

<s​ervers.guru:matrix.servers.guru> People already use monero for payment. If they could use it for subscription that would be huge.

<o​frnxmr:xmr.mx> but user would probably have to lock funds ahead of time into a contract that would be released once the service sends their key half.

<o​frnxmr:xmr.mx> i dont think it sounds realistic just yet

<s​ervers.guru:matrix.servers.guru> Couldn't it be more simple? Like transfer x amount if it in the wallet if not cancel?

<s​ervers.guru:matrix.servers.guru> Couldn't it be more simple? Like transfer x amount if it is in the wallet if not cancel?

<o​frnxmr:xmr.mx> The amount would have to be predetermined / signed. So if i'm sending 0.1xmr/mth, my wallet would have to sign and spend my funds without my interaction

<o​frnxmr:xmr.mx> Its possible, for sure, just like pocketchange

<s​ervers.guru:matrix.servers.guru> Yes. That's something like that I'm thinking about.

good for the merchant but not the person who doesnt want to pay for the service anymore

<s​ervers.guru:matrix.servers.guru> Well you can setup a way to cancel it

<o​frnxmr:xmr.mx> You'd still need your wallet online for the tx to he broadcasted

<o​frnxmr:xmr.mx> So i think luke profits subscription wallet is probably the best POC for this

<s​ervers.guru:matrix.servers.guru> I think it is not convenient enough. No way to set something in a way that require zero interaction?

a private spend key that is only able to send 0.1 xmr to this address every x blocks

unless the 'revoke contract' transaction is broadcast

<s​ervers.guru:matrix.servers.guru> Yeah something like that.

<s​ervers.guru:matrix.servers.guru> Jsut my 2 cents but I think something like that would be dope for adoption.

<o​frnxmr:monero.social> matrix.monero.social/_matrix/media/…ero.social/DYCcaujLJMeczqjHFibNziMm

<d​arkijah:matrix.org> "I mock only with my feeble mockery, so that those who live now, AND THOSE WHO COME AFTER US, SHALL KNOW WHAT I HAVE THOUGHT ABOUT THE POPE, THE ACCURSED ANTICHRIST, and so that anyone who wishes to be a Christian can be WARNED AGAINST SUCH AN ABOMINATION." - Martin Luther 1545 - Against the Papacy in Rome, founded by the Devil, page 16.

<o​frnxmr:monero.social> github.com/lukeprofits/Monero_Subscriptions_Wallet

<s​ervers.guru:matrix.servers.guru> Is that the luke thing?

<o​frnxmr:monero.social> Yea

<s​ervers.guru:matrix.servers.guru> Yeha but you need to have the wallet open.

<s​ervers.guru:matrix.servers.guru> You forgot to open your wallet, you lose your service.

<s​ervers.guru:matrix.servers.guru> Not ideal.

so the idea would need to not have the user online to create/broadcast the tx

<o​frnxmr:monero.social> You need the wallet open regardless to broadcast the tx

<o​frnxmr:monero.social> If you presign the tx, you cant cancel it, and those outputs need to be frozen

<s​ervers.guru:matrix.servers.guru> I'm not sure about the technical but plowsof seems to have some ideas about it.

here are 10 unspent 0.1 xmr outputs, theyre yours. but you can only spend each after x blocks unless ive cancelled them with some tx

<u​mask777:decred.org> is this a metal thing? 🤘

i have no idea about the technicals xD

<o​frnxmr:monero.social> but of i use my wallet in the meantime, those tx either have to be frozen or will be invalidated by my spends

<s​ervers.guru:matrix.servers.guru> Haha I mean what you says kinda make sense to me but I also have no idea.

<d​arkijah:matrix.org> "I mock only with my feeble mockery, so that those who live now, AND THOSE WHO COME AFTER US, SHALL KNOW WHAT I HAVE THOUGHT ABOUT THE POPE, THE ACCURSED ANTICHRIST, and so that anyone who wishes to be a Christian can be WARNED AGAINST SUCH AN ABOMINATION." - Martin Luther 1545 - Against the Papacy in Rome, founded by the Devil, page 16.

<d​arkijah:matrix.org> #JesusGod-Pope666.Info:matrix.org

<s​ervers.guru:matrix.servers.guru> But I can't imagine how that wouldn't be possible in some way.

<o​frnxmr:monero.social> If frozen, im essentially paying in advance, so i might as well oay in advance

perhaps bch has a similar solution via flipstarter cc Rucknium

a locked output - that can be spent by me before it becomes available would be the approach i think

<o​frnxmr:monero.social> What plowsof is saying about "only spend after x" only works if its a multisig or an atomic key half

<u​mask777:decred.org> are you into melodic black metal or technical death metal?

<o​frnxmr:monero.social> Either multi or atomic, both require the tx to be signed at release

<s​ervers.guru:matrix.servers.guru> Maybe first step would be ( bare with me if what I say makes no sense)

<s​ervers.guru:matrix.servers.guru> -> create private spending keys that can only send x amount every x bloc

i pre send 0.1 amount to your address. merchant confirms these amounts are deposited but locked. and i can spend each whenever i choose before the lock time is up

<s​ervers.guru:matrix.servers.guru> -> master spending key can revoke those keys

<o​frnxmr:monero.social> Plowsof this is same as bsx

nice

<o​frnxmr:monero.social> Funds are locked in contract with half of the key

<o​frnxmr:monero.social> But to unlock, the parties have to exchange the other half

ive almost invented the wheel, give me another week to brainstorm

<s​ervers.guru:matrix.servers.guru> Wouldn't be possible to create additional spending keys which are limited in spending limits?

<o​frnxmr:monero.social> Thats a multisig or an atomic key half

<o​frnxmr:monero.social> To remove the limit youd need the other key or other half of the key

<s​ervers.guru:matrix.servers.guru> Multi sig don't have limit no?

<s​ervers.guru:matrix.servers.guru> It's different

<s​ervers.guru:matrix.servers.guru> Oh I see what you mean.

<o​frnxmr:monero.social> There are no spending limits. Just ability to lock certain outputs

<o​frnxmr:monero.social> plowsof please do the mod thing

<d​arkijah:matrix.org> "I mock only with my feeble mockery, so that those who live now, AND THOSE WHO COME AFTER US, SHALL KNOW WHAT I HAVE THOUGHT ABOUT THE POPE, THE ACCURSED ANTICHRIST, and so that anyone who wishes to be a Christian can be WARNED AGAINST SUCH AN ABOMINATION." - Martin Luther 1545 - Against the Papacy in Rome, founded by the Devil, page 16.

<d​arkijah:matrix.org> #JesusGod-Pope666.Info:matrix.org

<u​mask777:decred.org> this album's getting reptitive, you need new riffs

<s​ervers.guru:matrix.servers.guru> Well, food for thoughts. But if you guys could pull that through. With no interaction, no "frozen funds" and ability to cancel.

<s​ervers.guru:matrix.servers.guru> Then credit card have nothing better than monero anymore.

<o​frnxmr:monero.social> i dont think theres a trustless way to do this

<s​ervers.guru:matrix.servers.guru> It would need to give access to the wallet to a 3rd party and somehow have a mechanic to limit it.

<s​ervers.guru:matrix.servers.guru> But again I don't know much about the technicalities.

<o​frnxmr:monero.social> nor a way to spend automatically without the wallet coming online.

<o​frnxmr:monero.social> user could send provider pre-signed transactions, and provider could broadcast those transactions on behalf of the wallet owner

<o​frnxmr:monero.social> But those would have stale decoys and are liable to have spend outputs

<o​frnxmr:monero.social> Spent*

<s​ervers.guru:matrix.servers.guru> No it would need the provider to have access to the wallet. If not it is the same thing as what the luke guy did.

<s​ervers.guru:matrix.servers.guru> Also that would mean the client need to have the money for a while already available no?

<s​ervers.guru:matrix.servers.guru> That would defeat the purpose.

<o​frnxmr:monero.social> no, if i send anyone an offline signed tx, any node csn broadcast it

<s​ervers.guru:matrix.servers.guru> Do you need to have the money to do that?

<o​frnxmr:monero.social> I can send plowsof (custodian) a tx that is going to guru on the 29th. Plowsof them submits it to thr network on the 29th

<o​frnxmr:monero.social> Yes

<s​ervers.guru:matrix.servers.guru> That's an issue.

<o​frnxmr:monero.social> but if i spend the funds before the 29th, the tx that plowsof submits will fail

<s​ervers.guru:matrix.servers.guru> Could you pre sign transaction without the fund. And when the transaction is set to occur it only occur if the funds are there?

<s​ervers.guru:matrix.servers.guru> If not all futur transactions are canceled as well?

<o​frnxmr:monero.social> no, you buiild decoys against your current output

<o​frnxmr:monero.social> And the specific outputs being used in the transaction

if i send the merchant a normal locked transaction (rip) it wouldnt need a middle man, its just that when they try and spend it , there is a chance it has been spent already

<o​frnxmr:monero.social> I csnt say "send 1xmr" i have to say "send output 3 + 4"

<s​ervers.guru:matrix.servers.guru> Because there is a couple issues

<s​ervers.guru:matrix.servers.guru> 1. You need to set a time-frame. That means it cannot be a forever subscription until canceled

<s​ervers.guru:matrix.servers.guru> 2. You need to already have the money for the whole subscription period which defeat the purpose

<o​frnxmr:monero.social> 2. Exactly

<o​frnxmr:monero.social> Not just the amount, but the specific outputs

<s​ervers.guru:matrix.servers.guru> What about introducing some kind of IOU transaction type in the algorithm?

<o​frnxmr:monero.social> Without locking specific inputs, you cant guarantee the subscription tx

<s​ervers.guru:matrix.servers.guru> I'm going wild here.

<s​ervers.guru:matrix.servers.guru> But I don't know. Something like a promise to fill that you would sign and when times come if it doesn't match a proper transaction it will fail?

<o​frnxmr:monero.social> An iou would require a messaging protocol, monero wouldn't change hands but a promise to would. But this goes back to the "wallet online" problem

<o​frnxmr:monero.social> Youd still need the wallet onkine

<o​frnxmr:monero.social> At the time of the tx to spend valid outputs, unless you locked / froze /reserved outputs beforehand

<s​ervers.guru:matrix.servers.guru> Seems we're back to some specific kind of limited private keys.

<s​ervers.guru:matrix.servers.guru> Could a level of abstraction on top of monero solve that?

<s​ervers.guru:matrix.servers.guru> What I say probsbly makes no sense I'm just trying to wrap my head around that.

<o​frnxmr:xmr.mx> Fcmp will allow payment channels

<o​frnxmr:xmr.mx> Maybe thats needed

<s​ervers.guru:matrix.servers.guru> Payments channels like lightning?

<o​frnxmr:xmr.mx> Yea

<r​ucknium:monero.social> servers.guru: I can add Monero subscriptions as an open research question here if you want: monero-project/research-lab #94

Revuo Monero Issue 218: November 7 - 21, 2024. revuo-xmr.com/weekly/issue-218

<r​ottenwheel:kernal.eu> PSA: some sections in -xmr domain are outdated, look wrong; this will be the case until CDN cache gets refreshed for that domain. In the meantime, please visit issue 218 through -monero and you'll be alright. revuo-monero.com/weekly/issue-218

<s​tnby:kernal.eu> ofrnxmr: From git Blame I noticed you like to maintain the rpc docs 💀 docs.getmonero.org/rpc-library/monerod-rpc maybe you would find a minute to update it?

<s​tnby:kernal.eu> jeffro256 Please attempt to update docs when introducing something new in the RPC monero-project/monero dd47d03#diff-da6ab0aecdf9547f57bb822783cae11fcfbaf7a2eae0d9cb5dbb69c8fc3b660aR659

<s​tnby:kernal.eu> As it makes peoples life a living hell.

<j​effro256:monero.social> Lemme guess: old daemon with new wallet made it so that transfer responses came back invalid even though they actually submitted?

<s​tnby:kernal.eu> The actual issue I had was our software was setting unlock time to 10. But current release expects a hard 0. But overall other issue we constantly run into is docs being out of date. And using structs as docs is not the nicest thing out there. and even if its in struct doesn't mean its not a deprecated field.

<o​frnxmr:xmr.mx> What do you need updated? That unlock requires a hard 0 or to he omitted?

<o​frnxmr:xmr.mx> And rpc docs were recently migrated from getmonero.org (monero-site) to docs.getmonero.org (monero-docs). None of the rpc docs were written by myself

<o​frnxmr:xmr.mx> To be fair, jeffro and others had opened prs against -site, but those went unmerged for many months. With the new docs repo, it should be easier to keep rpc docs updated

<r​ucknium:monero.social> I think we found who made these nonstandard transactions 😂 : monero-project/research-lab #125#issuecomment-2430142343

<s​tnby:kernal.eu> In MoneroTopia I learnt that Zano uses autogenerated docs.

<s​tnby:kernal.eu> github.com/hyle-team/zano/blob/2817…pc_server_commands_defs.h#L210-L214

<s​tnby:kernal.eu> hyle-team/zano-docs 8d3e32c#diff-6e0952f91f765b459c6fe4e0f1c7b7ef22d29f58b2faa37a0edda94fb0b1196bR11

<s​tnby:kernal.eu> docs.zano.org/docs/build/rpc-api/wallet-rpc-api/get_bulk_payments

<s​tnby:kernal.eu> Maybe we can adopt something like this?

<r​ucknium:monero.social> Stnby: You should apply to MAGIC for funding for MoneroPay like someone at Monerotopia suggested :D

<r​ucknium:monero.social> monerofund.org/apply

<3​21bob321:monero.social> Skynet controlling docs?

<s​tnby:kernal.eu> I told them Monero RPC docs bring me to suicide every day. And asked if they have same issues. But lol seems they are light years ahead of us

<s​tnby:kernal.eu> probably us

<s​iren:kernal.eu> oopsie whoopsie

<s​tnby:kernal.eu> omitted should be the way.

<3​21bob321:monero.social> Rucanaylsis

<s​tnby:kernal.eu> It should not even be in the struct anymore.

<s​tnby:kernal.eu> We stopped using docs all together. Now use header files and chatgpt to make me structs in Go 💀

<s​tnby:kernal.eu> We stopped using docs all together. Now use header files and chatgpt to make me structs in Go 💀

<s​tnby:kernal.eu> More reliable this way

<d​ave.jp:matrix.org> When lws binaries ? vtnerd

haha you can docker build it

<3​21bob321:monero.social> yep

<d​ave.jp:matrix.org> Okay Paul

<s​nowman:tetaneutral.net> I use non binaries

lol:) when analogues. when simulations.

wen monero irl