-
m-relay
<judger90:matrix.org> helloe
-
m-relay
<judger90:matrix.org> I came with news of a new coin initiative. The era of Pi is over, it is a 1 week project, come to Kivanet, it does not require ID etc. It is mined from the browser or if you want a mobile application, it is a new project at this stage, I say sign up and try it without giving any critical information, an e-mail and password are enough. It is started with coin transaction, in near f<clipped message>
-
m-relay
<judger90:matrix.org> uture you can trade it in a market and get some dollars. Here is my invitation link that boosts your mining rate:
-
m-relay
-
BlueyHealer
dude, sober up
-
m-relay
<monero.arbo:matrix.org> the fucking monerod database is so fragile fml (power outage, DB corrupt, lfg)
-
m-relay
<kevino:tchncs.de> it didn't experience it that much
-
m-relay
<kevino:tchncs.de> i had faced it only once when i was doing initial sync
-
m-relay
<basses:matrix.org> spam
-
m-relay
<basses:matrix.org> plowsof
-
m-relay
<321bob321:monero.social> Wes inclusive
-
m-relay
<monero.arbo:matrix.org> ya, testing initial sync for 0.18.4.0
-
m-relay
<kevino:tchncs.de> refer tips in [#monero-support:monero.social](https://matrix.to/#/%23monero-support:monero.social) group
-
m-relay
<kevino:tchncs.de> fast sync has the possibility of corruption
-
m-relay
<monero.arbo:matrix.org> yeah I know
-
m-relay
<monero.arbo:matrix.org> Bitcoin Core has options like pop-blocks to roll back the database, Monero is just like, tough shit start over
-
m-relay
<syntheticbird:monero.social> LMDB don't have the durability flag during sync
-
m-relay
<syntheticbird:monero.social> once you sync, monerod add it back and you should be resistant to power outage
-
m-relay
<syntheticbird:monero.social> db corrupt however is completely unrelated to the db system
-
m-relay
<elongated:matrix.org> Is there anything out there that is better than lmdb? and can be used with monero?
-
m-relay
<monero.arbo:matrix.org> Cuprate will have the option to not use LMDB, will see how much better is it, but at the least it's a bajillion times faster
-
m-relay
<ofrnxmr:xmr.mx> Cuprate is currently using lmdb
-
m-relay
<ofrnxmr:xmr.mx> i think the alternative is redDB. Or something like that
-
m-relay
<syntheticbird:monero.social> i want to experiment with Fjall
-
m-relay
<boog900:monero.social> Redb
-
m-relay
<syntheticbird:monero.social> which seems way better than redb
-
m-relay
<syntheticbird:monero.social> There is also mdbx that we haven't tried fwiw
-
m-relay
<ofrnxmr:xmr.mx> after initial sync you can switch to `db-sync-mode=safe:sync`
-
m-relay
<monero.arbo:matrix.org> corruption is one thing, I'm talking about not being able to recover from it with something like pop-blocks offered by bitcoin core
-
m-relay
<syntheticbird:monero.social> shouldn't it be done automatically??
-
m-relay
<monero.arbo:matrix.org> guys. guys. I know all the monerod options and stuff. I appreciate it. I'm mostly just bitching
-
m-relay
<syntheticbird:monero.social> bitching is great
-
m-relay
<ofrnxmr:xmr.mx> that is, `db-sync-mode=fast:async`
-
m-relay
<boog900:monero.social> Fwiw we have no shutdown code, when we shutdown everything is just abruptly stopped. With redb this causes it to scan the whole db for corruption on startup which takes forever, so we will need to fix that before making redb a legit option
-
m-relay
<ofrnxmr:xmr.mx> Soomtm
-
m-relay
<ofrnxmr:xmr.mx> one problem, imo, is that we store the txpool in the same db as the blockchain
-
m-relay
<ofrnxmr:xmr.mx> so were constantly modifying the db
-
m-relay
<monero.arbo:matrix.org> yikes! that does seem crazy
-
m-relay
<monero.arbo:matrix.org> I don't know shit about databases but I also notice the bitcoin core database is like 1 million different tiny files as opposed to a giat scary monolithic file
-
m-relay
<syntheticbird:monero.social> considering the txpool is ephemeral, i don't even understand why we're putting this shit into a DB to begin with, it don't need persistence? ( boog900 feel free to correct me )
-
m-relay
<monero.arbo:matrix.org> that was my thought as well Synthetic
-
m-relay
<ofrnxmr:xmr.mx> afaik, its Simply to avoid downloading it 💀
-
m-relay
<syntheticbird:monero.social> That's because we're part of the Hive mind Lyza
-
m-relay
<kevino:tchncs.de> one to one comparison with bitcoind is not sensible
-
m-relay
<ofrnxmr:xmr.mx> Its set to a max of 650mb to begin with, so i dont see jt as a ram issue at all
-
m-relay
<boog900:monero.social> You could lose a tx of you are the only one to have it
-
m-relay
<boog900:monero.social> You could lose a tx if you are the only one to have it
-
m-relay
<boog900:monero.social> And restart
-
m-relay
<kevino:tchncs.de> one to one comparison with bitcoind is not practical.
-
m-relay
<ofrnxmr:xmr.mx> The wallet would lose the tx too
-
m-relay
<ofrnxmr:xmr.mx> ..So no harm done
-
m-relay
<ofrnxmr:xmr.mx> Do different than having a tx that failed to relay, then doing a flush_txpool
-
m-relay
<ofrnxmr:xmr.mx> No different than having a tx that failed to relay, then doing a flush_txpool
-
m-relay
<syntheticbird:monero.social> i see
-
m-relay
<syntheticbird:monero.social> extremely unlikely to happen tho
-
m-relay
<ofrnxmr:xmr.mx> Even if it did, it wouldnt be an issue
-
m-relay
<ofrnxmr:xmr.mx> unless you and merchant were using the same node .. and doing 0 conf tx's
-
m-relay
<ofrnxmr:xmr.mx> in any event, i dont think it makes sense to store the txpool in the _same_ db as the blockchain
-
m-relay
<syntheticbird:monero.social> cuprate have its separate
-
m-relay
<ofrnxmr:xmr.mx> cuprate uses a 2nd db aiui
-
m-relay
<syntheticbird:monero.social> cuprate have it separate
-
m-relay
<shuroii:matrix.org> so I'm trying to host a restricted monero rpc node publicly (but with a login) and I'm not sure if I should be using an SRV record or an A record. Seems only SRV is supported?
-
m-relay
<ofrnxmr:xmr.mx> A works
-
m-relay
<ofrnxmr:xmr.mx> I'm no dns guru, but A works
-
m-relay
<ofrnxmr:xmr.mx> You have to open ports on the node, of course
-
m-relay
<shuroii:matrix.org> and should it be 18081 or 18089?
-
m-relay
<shuroii:matrix.org> since I use restricted I would think it's the latter
-
m-relay
<ofrnxmr:xmr.mx> --rpc-restricted-bind-ip=0.0.0.0 --rpc-restricted-bind-port=18089
-
m-relay
<ofrnxmr:xmr.mx> then allow incoming for 18089 in your firewall, and port forward it if youre behind a router
-
m-relay
<mrnaif:matrix.org> Hi, don't want to raise the heated topic much, but just letting you know that personally I see no point in "improving btcpay because other solutions don't have that many integrations/not as mature" etc when bitcart has existed for all this time (if btcpay was released in 2017 somewhere, bitcart first commit was early 2019) with monero support for quite some time which was proven q<clipped message>
-
m-relay
<mrnaif:matrix.org> uite stable because after some fixes I made noone has ever reported issues in XMR processing, it works butter smooth. And if one node fails it falls back to the next node in the list, so it is very stable
-
m-relay
<mrnaif:matrix.org> As for the integrations we support shopify, whmcs, woocommerce, even fossbilling (in fact we were the first to add crypto integration to them), odoo and more can be added easily as I just added one endpoint which does all the integration stuff for any e-commerce solution which all btcpay plugins duplicate in each of the plugins:
docs.bitcart.ai/integrations
-
m-relay
<mrnaif:matrix.org> And in general I don't understand the point of improving it much. Okay v2 was released, but I log in sometimes and it's always the same, it's centric at one wallet setup, with BTC being always displayed. And monero was always via some hacks or plugins they tried to make
-
m-relay
<mrnaif:matrix.org> While bitcart supports unlimited number of wallets, it is centered at the concept that you can have many wallets bind to the store. You can even enable a setting and it will pick a random wallet for each new invoice out of those connected of same currency
-
m-relay
<mrnaif:matrix.org> And as for BTC + XMR scenario bitcart obviously supports it, but it supports literally any currency one would ever need, including those btcpay wouldn't add (e.g. BCH, ETH and more)
-
m-relay
<mrnaif:matrix.org> I remember I DMed you in twitter asking to try it out but I guess you didn't (:
-
m-relay
<mrnaif:matrix.org> And if there's something missing that would help merchants onboard easier I am open to adding it. That's the point, Bitcart has all the features already implemented years ago, even email notifications to customers, notifications to merchant itself via telegram discord matrix literally anything with custom templates.
-
m-relay
<mrnaif:matrix.org> And the main thing is, CCS requires funding but I am fine with adding it for free if it boosts visibility of Bitcart as that's the only issue Bitcart has
-
m-relay
<mrnaif:matrix.org> Sorry, end rant from my side
-
m-relay
<shuroii:matrix.org> So I made an A record in my registrar for xmr.domain.com pointing to my public IP. Nginx is configured to forward traffic for that domain at port 443 to my monero daemon at port 18089. This doesn't work, connection times out.
-
m-relay
<shuroii:matrix.org> Port forwarding port 18089 allows me to connect to my daemon via my public IP, but I'd rather not forward another port, and just go through nginx.
-
m-relay
<shuroii:matrix.org> This leads me to believe A records are *not* supported.
-
Snipa
What're you trying to do exactly? A records just resolve a DNS address to an IP, they have nothing to do with ports.
-
m-relay
<shuroii:matrix.org> I'm trying to set up cloudflare for my semi-public monero node so I can let certain people access it for development purposes
-
m-relay
<shuroii:matrix.org> so the people I work with don't have to set up their own node but also don't have to trust one not hosted by a trusted party
-
m-relay
<shuroii:matrix.org> I don't have a vps to route through so cloudflare's my next best bet for not getting ddossed for hosting a monero node
-
Snipa
If you're going to use cloudflare anyway, I'd suggest looking at a cloudflare tunnel, as it does exactly what you're trying to do.
-
m-relay
<shuroii:matrix.org> ah I need a tunnel for this? that's unfortunate
-
Snipa
No, it's just simpler.
-
m-relay
<shuroii:matrix.org> well, what are my options if I don't want to use a tunnel?
-
Snipa
You can reverse-proxy RPC all day, but cloudflare only provides marginal protection unless you do a bunch of protection work.
-
m-relay
<shuroii:matrix.org> I host other things on the machine hosting this node that I don't want to tunnel, and I feel like specifying what I do and don't want to tunnel is going to be a pain
-
Snipa
That being said, what error did you run into reverse proxying it?
-
Snipa
Tunnel is a dedicated application that is essentially cloudflare's version of ngrok, AKA: They give you a DNS hostname listening on 443, and it tunnels it to whatever port is listening on the box the tunnel service is on.
-
Snipa
It's not a full "route everything" tunnel.
-
Snipa
If you've already got a reverse proxy up, the only likely error is somewhere in your nginx config.
-
m-relay
<shuroii:matrix.org> connection drops when trying to connect to either xmr.domain.com:443 or xmr.domain.com:18089 with this command `monero-wallet-cli --daemon-address xmr.domain.com:443 --daemon-login domain --trusted-daemon`
-
m-relay
<shuroii:matrix.org> says the daemon's not running
-
m-relay
<shuroii:matrix.org> if I replace xmr.domain.com:443 with publicip:18089 it does work because I port forwarded that port to make it work
-
Snipa
What's in your nginx logs?
-
m-relay
<ofrnxmr:xmr.mx> Do you have ssl certs configured on the node? Is 443 expecting ssl?
-
m-relay
<shuroii:matrix.org> no errors, no info related to domains
-
m-relay
<shuroii:matrix.org> yes
-
m-relay
<shuroii:matrix.org> but what do you mean with that last part?
-
m-relay
<shuroii:matrix.org> should I be specifying
xmr.domain.com:443 instead?
-
m-relay
<shuroii:matrix.org> you mentioned RPC, I don't explicitly proxy RPC connections, just TCP (I use nginx proxy manager)
-
m-relay
<shuroii:matrix.org> so I should specify something to proxy the RPC connection?
-
m-relay
<shuroii:matrix.org> gonna look into how to do that
-
Snipa
That's a unique setup to try to stuff behind cloudflare, sorry I thought you were using standard Nginx, so this one's a bit outside my normal. :) In theory, if it's just proxying the TCP, it should be mostly fine, but I've not played with nginx proxy manager before, so I'll back outta this one.
-
m-relay
<shuroii:matrix.org> I've been meaning to replace it with regular nginx but I haven't had the time
-
binaryFate
New binaries for v0.18.4.0 are now available on getmonero.org
-
m-relay
<shuroii:matrix.org> mrnaif is there a way to run bitcart with IP addresses in BITCART_HOST instead of domain names? I ask because I'd like to check it out in a Nix shell, which means hosts file can't be edited
-
m-relay
<shuroii:matrix.org> I'd like to explore the API and develop against it locally
-
m-relay
<mrnaif:matrix.org> Of course!
-
m-relay
<mrnaif:matrix.org> export BITCART_HOST=1.2.3.4
-
m-relay
<mrnaif:matrix.org> export BITCART_REVERSEPROXY=nginx
-
m-relay
<mrnaif:matrix.org> ./setup.sh
-
m-relay
<shuroii:matrix.org> ok cool, ty
-
m-relay
<shuroii:matrix.org> is there any reason for using nginx in this context though? I'd be running containerless
-
m-relay
<shuroii:matrix.org> as far as I can tell it's just redis and postgres together with the actual bitcart service
-
m-relay
<shuroii:matrix.org> could even roll with sqlite since it's for dev anyway
-
m-relay
<shuroii:matrix.org> or did I misread that about sqlite support
-
m-relay
<shuroii:matrix.org> might've done
-
m-relay
<shuroii:matrix.org> by god I now understand why you ship this with install scripts and docker
-
m-relay
<shuroii:matrix.org> ig that's required thanks to the sheer amount of currencies you support
-
m-relay
<shuroii:matrix.org> and them all needing a daemon
-
m-relay
<mrnaif:matrix.org> There is no sqlite support only postgres. docker is recommended because it configures all env vars. I mean you could set reverseproxy to none then it will expose daemons at ports 5000X, backend to 8000 etc
-
m-relay
<mrnaif:matrix.org> as for manual you can do but you need is python and nodejs if you want containerless
-
m-relay
<mrnaif:matrix.org> that's the beauty of it, it's modular and each currency and it's dependencies are in separate container, one daemon implements all blockchain features it represents
-
m-relay
<mrnaif:matrix.org> and they all have the same universal api
-
m-relay
<mrnaif:matrix.org> basically you can even roll out your own docker compose but I see no reason to because if in updates I change something you need to update it as well too somehow
-
m-relay
<mrnaif:matrix.org> and the env vars customize every aspect of how compose is generated
-
m-relay
<mrnaif:matrix.org> in fact you can even write custom rules or components
-
m-relay
<mrnaif:matrix.org> this way I even wrote sub applications running under one bitcart deployment
-
m-relay
<mrnaif:matrix.org> but what the scripts do basically is, install docker if not there, persist env vars, re-build compose file and start
-
m-relay
<mrnaif:matrix.org> and plugins handling if you installed any