<j​oshdoesdart:matrix.org> Is there any kind of self hosted payment server that works?

<j​oshdoesdart:matrix.org> For XMR specifically

<r​ottenwheel:unredacted.org> [@joshdoesdart:matrix.org](https://matrix.to/#/@joshdoesdart:matrix.org) sure. BTCPayServer, Bitcart, or MoneroPay.

<j​oshdoesdart:matrix.org> Thank you

<j​oshdoesdart:matrix.org> Which one do you think is most mature

<g​ooglemozilla:matrix.org> BTCPayServer

<j​oshdoesdart:matrix.org> MoneroPay looks good its still being worked on maybe?

<g​ooglemozilla:matrix.org> @siren:kernal.eu

<j​oshdoesdart:matrix.org> Okay assuming this includes XMR

<g​ooglemozilla:matrix.org> sethforprivacy.com/guides/accepting-monero-via-btcpay-server

<g​ooglemozilla:matrix.org> Couple years old, but it should be fine to follow still.

<o​frnxmr:xmr.mx> Not sure if that guide still works

<o​frnxmr:xmr.mx> Btcpayserver had a major upgrade that changed some monero stuff

<g​ooglemozilla:matrix.org> Doesn't hurt to try.

<o​frnxmr:xmr.mx> Servers.guru uses bitcart

<g​ooglemozilla:matrix.org> It definitely is the most mature though out of the options rotten gave.

<r​ottenwheel:unredacted.org> Do you only neee to accept XMR, or you want to take other cryptocurrencies as well?

<r​ottenwheel:unredacted.org> Do you only need to accept XMR, or you want to take other cryptocurrencies as well?

<j​oshdoesdart:matrix.org> Only XMR, ideally to have webhooks on txnotify.

<j​oshdoesdart:matrix.org> Something with a backend UI would be nice but I can add

<j​oshdoesdart:matrix.org> I will see

<j​oshdoesdart:matrix.org> I am reading this now, is old?

<o​frnxmr:xmr.mx> Yeah. Btcpayserver had a big update recently

<j​oshdoesdart:matrix.org> The one for sethdoesprivacy

<o​frnxmr:xmr.mx> yeah

<j​oshdoesdart:matrix.org> So its updated already but documentation is not

<j​oshdoesdart:matrix.org> Maybe its fine

<o​frnxmr:xmr.mx> Yes

<o​frnxmr:xmr.mx> Btcpayserver works, but seth's documentation might need some changes. Try it and let us know

<o​frnxmr:xmr.mx> Seth is here and will fix if it needs to be fixed

<j​oshdoesdart:matrix.org> Sure thing

<r​ottenwheel:unredacted.org> Look into MoneroPay. moneropay.eu

<o​we_addams:matrix.org> Wow, are you saying it’s a tool that any XMR holder can use? To get started, the first step is figuring out where to buy Monero.

Some IP spamming one of my nodes with getheight and getblocktemplate requests every second. Its like 20 get height requests in 20 seconds then 1 getblocktemplate.

The IP has never done a submit block, so its not a miner

sounds like xmrig solo mining

yea probably

cpu peaking only at a couple % so not worried tbh

<c​ontrazene:matrix.org> hey I have a question; sorry if this isn't a right place.

<c​ontrazene:matrix.org> If the mining network notices that a miner or confederacy of miners is positioned to make a 51% attack, why doesn't simply ignore any blocks broadcast by that node?

<c​ontrazene:matrix.org> or confederacy

There is now way to "notice" it

*no way

<c​ontrazene:matrix.org> what do you mean? We can't notice that a certain miner has recieved a certain percentage of the last few blocks?

51% attack doesn't work like this. An attacker doesn't announce their blocks until they're done

Also, you can't know who mined which block in Monero because payout addresses are hidden

<m​onerobull:matrix.org> youd expect to see a sudden hashrate drop though

<m​onerobull:matrix.org> unless the attack is entirely mined with outside resources

<c​ontrazene:matrix.org> How is this possible?

<c​ontrazene:matrix.org> can't you only mine one block at a time

you can mine as many blocks as you want. 51% attack creates an alternative chain of blocks (more than 10 blocks in case of Monero), and then publishes them all at once

<c​ontrazene:matrix.org> then shouldn't the monero network prevent one node from mining more than 10 blocks at once. something like 1 out of every 10 blocks cannot be mined by the person who mined the other 9

<s​yntheticbird:monero.social> There is not really a way to enforce this as a miner could use 11 nodes to circumvent this, or broadcast 11 different addresses.

<m​onerobull:matrix.org> there is no "fix"

<m​onerobull:matrix.org> mining is the solution to the doublespend problem

<m​onerobull:matrix.org> if someone gets more hash than everyone else, they arent breaking any rulees

<m​onerobull:matrix.org> if someone gets more hash than everyone else, they arent breaking any rules

<m​onerobull:matrix.org> 51% attacks are just an inherent part of the design

<m​onerobull:matrix.org> 51% attacks arent even that destructive imo

<m​onerobull:matrix.org> the worst thing they can realistically do is mine empty blocks

"prevent one node from mining more than 10 blocks at once" impossible because payout addresses are hidden, and even if they were not, an attacker could use 10 different addresses

<f​:monero.social> In CCS terms, does "expiration" refer to "proposal not fully funded by date X" or "proposal funded but not completed by date X"?

<p​lowsof:matrix.org> you can interpret how you see fit - if the proposal needs to be merged/funded by a given date then state that. other forms of expiry are given to improve trust that the proposer is certain it will be completed - or funds are repurposed (these are not stringently enforced as we would expect, which needs to change)

<g​ooglemozilla:matrix.org> PoS.

<g​ooglemozilla:matrix.org> If you're talking about a 51% attack, I'm afraid PoS is actually more vulnerable. However, it does have several other advantages.

<m​onerobull:matrix.org> it makes the chain permissioned

<m​onerobull:matrix.org> you can "fix" 51% attacks by introducing a centralized authority

<m​onerobull:matrix.org> like "master nodes"

<m​onerobull:matrix.org> but then you have that, a centralized authority...

<g​ooglemozilla:matrix.org> Monero mining is centralized.

<m​onerobull:matrix.org> no its not

<g​ooglemozilla:matrix.org> At the moment.

<g​ooglemozilla:matrix.org> ...

<g​ooglemozilla:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/MkjOKkXkwvRTNQVeMbXicErz

<g​ooglemozilla:matrix.org> ~6.70% of the hash rate is being contributed to p2pool, while the remaining majority is concentrated among centralized pools.

<g​ooglemozilla:matrix.org> More than 60% of the hash power is concentrated in just a couple centralized pools. This situation is actually worse than PoS. Also, this hash rate is likely from botnets.

<g​ooglemozilla:matrix.org> Although Satoshi did say:

<g​ooglemozilla:matrix.org> `The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead`

<g​ooglemozilla:matrix.org> So perhaps having botnets on Monero isn't so bad after all, but they are using centralized pools unfortunately.

<f​:monero.social> Here are all the major details on the offline-signing concept I am designing:

<f​:monero.social> repo.getmonero.org/fullmetalScience…alscience-noshore.md?ref_type=heads

<f​:monero.social> Though it's elaborate, I am sure there will be questions, so feedback is very welcome!

yes, yes, it's exactly what I've been thinking about for years - why not connect to merchant's node to sync the wallet and send a transaction? But in you case, wallet doesn't even connect to the node directly?

I imagined it like wallet on the phone running in background, detecting a wi-fi network in the store, notifying user about available nodes and asking if it's ok to sync the wallet. And then at checkout, wallet is ready to send a transaction to merchant's node - merchant will see it immediately in their node's mempool.

<f​:monero.social> Care to re-phrase your first question? :)

You describe it like offline signing through merchant's PoS terminal, right? So wallet doesn't even connect to the node to sync first?

It can work for 1-2 transactions, depending on how many available inputs a user has. Then he has to sync to get new inputs from the network.

<f​:monero.social> The merchant's PoS is mostly there to coordinate between the client wallet (offline) and their "home tower" (an RPC instance that has everything synced).

yes, but user's wallet is not synced. Syncing through the PoS terminal will still be slow because it's CPU-limited

It's better to sync through merchant's local node using merchant's wi-fi - while walking around the store and picking goods to buy

<f​:monero.social> The home tower has an up-to-date view on the wallet (but no spend-key). It prepares the unsigned transaction and returns it to the merchant.

<f​:monero.social> Merchant in turn hands it to the customer for signing.

and who runs the home tower?

I assume it's the user because it's their wallet

<f​:monero.social> Who "runs" it, is flexible. It's controlled by the customer.

No one will run a server somewhere 24/7

Max you can expect from users, is to install a phone app

<f​:monero.social> I will. And I will run it for close others too. And what I've learnt in life is that, if there's one human interested in something, then there's probably a second somewhere :)

If it gets mass adopted, the "banks" will emerge that will run thousands and millions of wallets for their users

It's bad from privacy standpoint, and from centralization standpoint

thought experiment, maybe a nice working proof of concept at best. not realistic to gain any real world usage with this - a bluetooth ledger/trezor can just pay for transactions at a terminal ,, multicoin / off the shelf, no hardware enclosures have to be funded

Mass adoption and the average user will not run servers

<f​:monero.social> This design isn't for users who want crypto just for play. It's for those interested in circular economies. I've only briefly mentioned scenarios in the "use cases" section, since the document is already very long. I could write out the entire vision, but it wouldn't change opinions much of those who already have a different view on how they think things have to work.

A phone app that picks up wi-fi in store, finds a running node and syncs using it in the background - that can work. Because once users have to pay, their wallet is synced and ready, and it will submit the transaction to merchant's node so it will be "instant". That can work even in a busy grocery store

The less moving parts (from user side), the better

Having users to run their servers (or rely on someone's servers) is a no-go

Merchants have to run their nodes anyway, so it's better to use them as much as possiblel

<f​:monero.social> Why would it be a "no-go"? If someone wanted to use the setup, they can.

People who can run their server = 0.1% of the general population

People who can install a phone app = 99.9% of the general population

Merchants will not put an effort for 0.1%

<f​:monero.social> Note that this proposal is not about "mass adoption", it's about providing a tool for those who want to use it.

<f​:monero.social> (Actually it's not that different from most other proposals in this regard.)

okay, I see

Regardless of the mass adoption, the only weak point in this scheme is "towers"

I mean centralization point

If it's easy to setup (like with ready to go docker files), then maybe there will be many such towers from people in the community

<f​:monero.social> I hear your concern. However, it can be done, meaning there's nothing holding anyone back from doing it this way today. Actually, wallet's like MyMonero already used the client's view key in order to spare the user sync time.

<f​:monero.social> (Not to mention users holding "their" XMR on exchanges.)

<f​:monero.social> So in this regard, what we can do is make it as easy as possible for users to deploy the tool themselves.

yes

<f​:monero.social> Yes, see the note on Docker files in the document. There's probably affordable hosting where one provides a dockerhub URI and gets a running server. I will have to research options, but I'm leaving this for after implementation, as I highly doubt it would fail there.

<f​:monero.social> Thinking about MyMonero - on mobile, I did like this wallet the most, simply for not having to cope with syncing. Now if such a wallet would offer me to provide my own "tower", I could have the best of both worlds: No sync on device and no key with third party. (This plays into the idea in the last paragraph of the document.)

<o​frnxmr:monero.social> monero-lws

<o​frnxmr:monero.social> I think it should be working with the mymonero app

<f​:monero.social> Is there anything on Linux or Android working with this?

<i​ntr:envs.net> f: MyMonero is the only one currently. On Android there's also Edge wallet

<o​frnxmr:xmr.mx> Edge doesnt work with lws (cant specify daemon)

<f​:monero.social> This may actually be a great tool to cover most of "tower's" functionality. To how many wallets is this likely to scale? Probably far beyond what a handful of users require if they wanted to share an instance ...

<i​ntr:envs.net> you can actually, but doesn't always seem to work

<o​frnxmr:xmr.mx> Oh yeah? When did they add

<o​frnxmr:xmr.mx> I requested years ago but deleted ago years ago as well 😆

<i​ntr:envs.net> it's buried in settings somewhere

<i​ntr:envs.net> I'd tell you but the wallet won't load now

<i​ntr:envs.net> settings -> asset settings -> monero

<i​ntr:envs.net> thing is I can't tell which server is being used for wallets that were already created

<o​frnxmr:xmr.mx> Will probably have to try pcap

<o​frnxmr:xmr.mx> Someone need to fork edge, remove server backup, remove other coins

<i​ntr:envs.net> at that point you might as well start fresh

<j​oshdoesdart:matrix.org> Warning to developers in the community, the core monero teams are scamming people for their time.... And justifying it be spreading lies.

<j​oshdoesdart:matrix.org> Warning to developers in the community, the core monero teams are scamming people for their time.... And justifying it by spreading lies.

<j​oshdoesdart:matrix.org> I will post proof in kewbits defence on reddit and github communities

<j​oshdoesdart:matrix.org> But has completed 4 months of work and scammed

<j​oshdoesdart:matrix.org> By PsychoticBird

<s​yntheticbird:monero.social> MOM, I AM FAMOUS

<j​oshdoesdart:matrix.org> If anyone has any evidence of wrong doing you can submit it to me

<j​oshdoesdart:matrix.org> For monero team in general, or anyone in positions of authority

<p​reland:monero.social> Ok who was it that yawned and caused the price to drop 10%

<s​yntheticbird:monero.social> my fault

<s​yntheticbird:monero.social> I yawned

<a​dmindom:unfilteredrealm.com> What the hell I blink and it drops from 200 was it?

<a​dmindom:unfilteredrealm.com> Blessed

Hello, I'm setting up xmrig, looking to solomine. Running xmrig to `-o localhost:18081` returns `error: "Core is busy", code: -9`. I've done a bit of browsing but haven't found anythin, any suggestions for what the issue might be?

Anyone know why do I keep getting:

Invoke-WebRequest : 401 Unauthorized

At line:1 char:13

+ $response = Invoke-WebRequest -Uri "127.0.0.1:18083/json_rpc" ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc

   eption

    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

When trying to issue any command or connect to monero-wallet-rpc? Tried with SSL, certificates, completely disabled ssl now and still the same error!

<o​frnxmr:monero.social> Core is busy = is the node synced? Sounds like "no"

m-relay: Alright, i see, thanks for the insight

Your Monero node is probably not synchronized yet