01:43:26 Is there any kind of self hosted payment server that works? 01:43:59 For XMR specifically 01:46:07 [@joshdoesdart:matrix.org](https://matrix.to/#/@joshdoesdart:matrix.org) sure. BTCPayServer, Bitcart, or MoneroPay. 01:46:47 Thank you 01:52:41 Which one do you think is most mature 01:53:36 BTCPayServer 01:53:37 MoneroPay looks good its still being worked on maybe? 01:53:56 @siren:kernal.eu 01:54:00 Okay assuming this includes XMR 01:55:16 https://sethforprivacy.com/guides/accepting-monero-via-btcpay-server/ 01:55:49 Couple years old, but it should be fine to follow still. 01:55:53 Not sure if that guide still works 01:56:16 Btcpayserver had a major upgrade that changed some monero stuff 01:56:17 Doesn't hurt to try. 01:56:37 Servers.guru uses bitcart 01:56:56 It definitely is the most mature though out of the options rotten gave. 01:57:50 Do you only neee to accept XMR, or you want to take other cryptocurrencies as well? 01:57:57 Do you only need to accept XMR, or you want to take other cryptocurrencies as well? 02:02:54 Only XMR, ideally to have webhooks on txnotify. 02:04:12 Something with a backend UI would be nice but I can add 02:09:06 I will see 02:18:15 I am reading this now, is old? 02:18:49 Yeah. Btcpayserver had a big update recently 02:18:54 The one for sethdoesprivacy 02:19:50 yeah 02:20:40 So its updated already but documentation is not 02:20:56 Maybe its fine 02:21:46 Yes 02:22:24 Btcpayserver works, but seth's documentation might need some changes. Try it and let us know 02:22:46 Seth is here and will fix if it needs to be fixed 02:46:23 Sure thing 02:47:55 Look into MoneroPay. moneropay.eu 06:42:04 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. 07:42:36 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. 07:42:44 The IP has never done a submit block, so its not a miner 07:44:30 sounds like xmrig solo mining 07:46:58 yea probably 07:47:27 cpu peaking only at a couple % so not worried tbh 08:14:41 hey I have a question; sorry if this isn't a right place. 08:14:41 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? 08:14:47 or confederacy 08:43:37 There is now way to "notice" it 08:43:40 *no way 09:06:30 what do you mean? We can't notice that a certain miner has recieved a certain percentage of the last few blocks? 09:14:03 51% attack doesn't work like this. An attacker doesn't announce their blocks until they're done 09:14:32 Also, you can't know who mined which block in Monero because payout addresses are hidden 09:16:41 youd expect to see a sudden hashrate drop though 09:16:51 unless the attack is entirely mined with outside resources 09:20:59 How is this possible? 09:21:12 can't you only mine one block at a time 09:30:31 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 09:32:12 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 09:33:17 There is not really a way to enforce this as a miner could use 11 nodes to circumvent this, or broadcast 11 different addresses. 09:53:18 there is no "fix" 09:53:23 mining is the solution to the doublespend problem 09:53:45 if someone gets more hash than everyone else, they arent breaking any rulees 09:53:45 if someone gets more hash than everyone else, they arent breaking any rules 09:54:30 51% attacks are just an inherent part of the design 09:55:15 51% attacks arent even that destructive imo 09:55:45 the worst thing they can realistically do is mine empty blocks 10:13:57 "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 11:00:41 In CCS terms, does "expiration" refer to "proposal not fully funded by date X" or "proposal funded but not completed by date X"? 11:05:44 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) 11:19:10 PoS. 11:21:34 If you're talking about a 51% attack, I'm afraid PoS is actually more vulnerable. However, it does have several other advantages. 11:21:48 it makes the chain permissioned 11:22:13 you can "fix" 51% attacks by introducing a centralized authority 11:22:19 like "master nodes" 11:22:29 but then you have that, a centralized authority... 11:23:31 Monero mining is centralized. 11:23:45 no its not 11:23:57 At the moment. 11:24:56 ... 11:25:11 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/MkjOKkXkwvRTNQVeMbXicErz 11:26:28 ~6.70% of the hash rate is being contributed to p2pool, while the remaining majority is concentrated among centralized pools. 11:28:17 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. 11:30:52 Although Satoshi did say: 11:30:53 `The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead` 11:30:55 So perhaps having botnets on Monero isn't so bad after all, but they are using centralized pools unfortunately. 11:40:08 Here are all the major details on the offline-signing concept I am designing: 11:40:09 https://repo.getmonero.org/fullmetalScience/ccs-proposals/-/blob/noshore/fullmetalscience-noshore.md?ref_type=heads 11:40:11 Though it's elaborate, I am sure there will be questions, so feedback is very welcome! 11:43:58 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? 11:45:13 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. 11:46:08 Care to re-phrase your first question? :) 11:46:35 You describe it like offline signing through merchant's PoS terminal, right? So wallet doesn't even connect to the node to sync first? 11:47:33 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. 11:47:45 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). 11:48:21 yes, but user's wallet is not synced. Syncing through the PoS terminal will still be slow because it's CPU-limited 11:48:52 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 11:49:24 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. 11:49:39 Merchant in turn hands it to the customer for signing. 11:49:41 and who runs the home tower? 11:50:12 I assume it's the user because it's their wallet 11:50:19 Who "runs" it, is flexible. It's controlled by the customer. 11:50:20 No one will run a server somewhere 24/7 11:50:33 Max you can expect from users, is to install a phone app 11:51:52 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 :) 11:53:06 If it gets mass adopted, the "banks" will emerge that will run thousands and millions of wallets for their users 11:53:17 It's bad from privacy standpoint, and from centralization standpoint 11:53:58 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 11:54:01 Mass adoption and the average user will not run servers 11:55:17 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. 11:55:22 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 11:55:56 The less moving parts (from user side), the better 11:56:10 Having users to run their servers (or rely on someone's servers) is a no-go 11:56:31 Merchants have to run their nodes anyway, so it's better to use them as much as possiblel 11:57:09 Why would it be a "no-go"? If someone wanted to use the setup, they can. 11:57:36 People who can run their server = 0.1% of the general population 11:57:53 People who can install a phone app = 99.9% of the general population 11:58:08 Merchants will not put an effort for 0.1% 11:58:38 Note that this proposal is not about "mass adoption", it's about providing a tool for those who want to use it. 11:58:48 (Actually it's not that different from most other proposals in this regard.) 12:00:00 okay, I see 12:00:13 Regardless of the mass adoption, the only weak point in this scheme is "towers" 12:00:21 I mean centralization point 12:01:14 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 12:02:31 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. 12:03:34 (Not to mention users holding "their" XMR on exchanges.) 12:03:53 So in this regard, what we can do is make it as easy as possible for users to deploy the tool themselves. 12:04:31 yes 12:06:25 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. 12:13:55 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.) 12:14:55 monero-lws 12:15:15 I think it should be working with the mymonero app 12:17:58 Is there anything on Linux or Android working with this? 13:59:10 f: MyMonero is the only one currently. On Android there's also Edge wallet 14:03:55 Edge doesnt work with lws (cant specify daemon) 14:21:25 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 ... 14:25:53 you can actually, but doesn't always seem to work 14:46:39 Oh yeah? When did they add 14:47:03 I requested years ago but deleted ago years ago as well 😆 14:50:50 it's buried in settings somewhere 14:50:55 I'd tell you but the wallet won't load now 14:52:02 settings -> asset settings -> monero 14:52:15 thing is I can't tell which server is being used for wallets that were already created 14:54:17 Will probably have to try pcap 14:55:56 Someone need to fork edge, remove server backup, remove other coins 14:56:48 at that point you might as well start fresh 16:51:17 Warning to developers in the community, the core monero teams are scamming people for their time.... And justifying it be spreading lies. 16:51:32 Warning to developers in the community, the core monero teams are scamming people for their time.... And justifying it by spreading lies. 16:52:25 I will post proof in kewbits defence on reddit and github communities 16:53:20 But has completed 4 months of work and scammed 16:54:32 By PsychoticBird 16:57:28 MOM, I AM FAMOUS 17:06:53 If anyone has any evidence of wrong doing you can submit it to me 17:07:24 For monero team in general, or anyone in positions of authority 21:24:37 Ok who was it that yawned and caused the price to drop 10% 21:26:48 my fault 21:26:51 I yawned 21:35:16 What the hell I blink and it drops from 200 was it? 21:35:31 Blessed 21:37:08 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? 21:37:37 Anyone know why do I keep getting: 21:37:38 Invoke-WebRequest : 401 Unauthorized 21:37:38 At line:1 char:13 21:37:39 + $response = Invoke-WebRequest -Uri "http://127.0.0.1:18083/json_rpc" ... 21:37:39 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21:37:40 + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc 21:37:40 eption 21:37:41 + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand 21:37:41 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! 21:52:32 Core is busy = is the node synced? Sounds like "no" 21:57:47 m-relay: Alright, i see, thanks for the insight 21:59:44 Your Monero node is probably not synchronized yet