10:20:57 <Steven_M> Hi, I'd like some advice for running a monero node on a virtual private server please, who here has done that?
10:25:49 <ErCiccione[m]> Steven_M: https://web.getmonero.org/resources/user-guides/vps_run_node.html it's a good start
10:33:25 <Steven_M> ErCiccione[m]: it's keeping the server secure that I worry about. I know nothing about server security.
10:34:55 <ErCiccione[m]> Simple good practices are: close the ports you don't use, stop services you don't need, uninstall packages you don't use, do not login using "root", use a different port for ssh
10:35:34 <ErCiccione[m]> That's just what pops up in my mind
10:36:24 <Inge-> "different port for ssh" is low on the list - way higher is switching off passwords entirely and use a key instead. or at the very least to have a long and strong password
10:36:30 <ErCiccione[m]> also disable password login and use a ssh key instead
10:36:33 <Inge-> ^
10:43:27 <Steven_M> ErCiccione[m]: Inge-: Okay, thanks guys. :-) Can you recommend a good VPS provider?
10:46:06 <asymptotically> scaleway are very cheap and seem to be friendly to bitcoin, monero and tor (but you need to do a little dance to get enough disk space for the blockchain on their cheapest vpses)
10:46:09 <asymptotically> digitalocean and vultr are good too
10:46:27 <ErCiccione[m]> Use one that accepts Monero or Bitcoin. like vultr, bitvps, bitlaunch
10:47:00 <asymptotically> no privacy with vultr though. you can pay with bitcoin, but only after you've activated your account by paying normally
10:48:03 <Zero-ghost[m]> never use bitcoin, use monero, what bitcoin was supposed to be, the only private cryptocurrency
10:48:29 <ErCiccione[m]> true
10:48:34 <ErCiccione[m]> there is a good list of VPS providers here: https://web.getmonero.org/community/merchants/#services
10:48:43 <Zero-ghost[m]> shit oops thought i was in a different non crypto chat
10:48:44 <ErCiccione[m]> actually they are a lot, would make sense to have a section dedicate to that
10:52:34 <Steven_M> Zero-ghost[m]: very true. :-)
10:53:07 <Zero-ghost[m]> Steven_M: thought i was in another chat with someone talking about paying with bitcoin and thats just my normal text puke whenever i see people saying that
10:54:35 <Steven_M> Zero-ghost[m]: fair enough :)
11:06:07 <Steven_M> ErCiccione[m]: ironically, bitvps and bitlaunch are not on the https://web.getmonero.org/community/merchants/#services page, but since you recommend them, I will check them out.
11:17:52 <ErCiccione[m]> We only list services that accept Monero on that page. bitvps and bitlaunch only accept bitcoin afaik
11:19:30 <Steven_M> ErCiccione[m]: just checked, bitvps accepts monero. :)
11:19:53 <ErCiccione[m]> Oh, cool. I stand corrected :)
11:20:02 <Steven_M> :)
11:20:43 <Steven_M> bet time for me, goodnight.
11:21:49 <Steven_M> *bed
11:23:26 <ErCiccione[m]> Goodnight
14:52:23 <guernsey> hello
14:54:08 <guernsey> do anyone here knows what happen from v3 to v4 hardware fork so that is impossible to start new chain with version bigger than 3
14:55:21 <moneromooo> The README has the main changes for each version.
14:56:22 <guernsey> RingCT transactions are the new changes
14:57:18 <guernsey> but in which part this is checked is not possible to understand
14:59:03 <guernsey> i found parse_and_validate_tx_from_blob
15:03:09 <UkoeHB_> You can start new chains with bigger version but it requires a bunch of patches, which apparently none of the various forkers bothered to write down
15:08:26 <guernsey> yep tx version required some change on basic.h
15:08:54 <guernsey> i hope that will be enough...
15:31:37 <fort3hlulz> Always great to see the amount of remote RPC usage my node experiences
15:31:50 <fort3hlulz> Thankful for all the people who have worked so hard on a strong, decentralized public node system
15:32:52 <fort3hlulz> Its incredible to me that something similar doesn't really exist for Ethereum or Bitcoin
15:34:15 <guernsey> fort3hlulz do u have gains from this?
15:34:34 <fort3hlulz> No, I haven't enabled mining for RPC at this point (and have no plans to)
15:35:43 <fort3hlulz> Happy to provide the service for free to the community, as I have plenty of processing power and bandwidth :)
15:35:49 <fluffypony> fort3hlulz: it does exist for Bitcoin, it's called Electrum
15:36:02 <fluffypony> all the Electrum nodes are volunteer-run
15:36:11 <fort3hlulz> Well, but that is a whole separate service with its own pitfalls (and many exploited issues)
15:36:21 <fort3hlulz> Its not a part of bitcoind/btcd
15:36:41 <fort3hlulz> But yeah, I did forget that that exists (have run EPS in the past to work around those issues)
15:36:42 <fluffypony> ok but spv is native
15:36:55 <fluffypony> Bread, for instance, connects to random Bitcoin nodes
15:37:08 <fluffypony> and uses spv to interact for lightweight interaction with them
15:37:08 <fort3hlulz> Had not heard of Bread
15:37:19 <fort3hlulz> Have always seen SPV as a "I need to know the nodes address"
15:37:19 <fluffypony> any spv wallet should work the same way
15:37:35 <fort3hlulz> I'll have to look into that more!
15:37:53 <fort3hlulz> I've used SPV a bit with Decred, but didn't bitcoind just deprecate SPV entirely?
15:37:55 <fluffypony> although there are some that use spv but with a centralised server
15:37:56 <fluffypony> which is kinda lazy
15:38:06 <fluffypony> https://github.com/breadwallet/breadwallet-core
15:38:11 <fort3hlulz> thanks
16:16:42 <anon_82579487598> Can one of the monero subreddit admins approve this post (already did a message to the mods in reddit): https://www.reddit.com/r/Monero/comments/h7nnon/push_notifications_for_monero_transactions_to/
16:17:17 <anon_82579487598> Any btw, you guys might be interested in this new monero project: https://github.com/apprises/apprise-transactions
16:25:12 <moneromooo> "Thankful for all the people who have worked so hard on a strong, decentralized public node system" <- The "decentralized public node system" is a band aid because people do not like decentralized. It's like disinfecting a knife before sticking you with it.
16:26:09 <moneromooo> The reason I made the RPC payment stuff is to try and get rid of those people having free public RPC in the first place.
16:26:27 <moneromooo> Because people making thier RPC server free to use encourage others to not decentralize.
16:29:31 <fort3hlulz> While I agree that everyone should run their own full node, I think its important to have the option (with strong wording against it/about the risks) for those that absolutely cannot for some reason
16:29:53 <fort3hlulz> I have, and always will, push people to use their own full node, as its dead simple and integrated well into the GUI/CLI
16:30:15 <fort3hlulz> But I think its especially important for mobile adoption that there are strong remote node options available
16:30:43 <yanmaani> A fullnoe isn't always feasible, e.g. TAILS
16:30:48 <moneromooo> Then set up payment. Those who really can't run their node can mine a bit. Here you're just telling everyone who can "look, I'll help you centralize for free".
16:30:55 <yanmaani> I think it's important to support such facilities
16:31:01 <yanmaani> miners will always have incentive to run such nodes
16:31:44 <fort3hlulz> Thats actually not true, yanmaani, I'm a VERY strong advocate for self-select to be used by miners which would be best with their own full node, and not remote RPC
16:32:03 <fort3hlulz> moneromooo: So no one should expose RPC without pay-for-rpc?
16:32:18 <fort3hlulz> I think a bunch of new users using things like cake/monerujo would be offput if that were to actually happen
16:32:19 <yanmaani> Let me rephrase, miners have an incentive that free full nodes exist
16:32:35 <yanmaani> Since it increases transaction volume, meaning there are more fees to collect
16:32:47 <fort3hlulz> huh never thought of that angle
16:32:58 <moneromooo> My aim was that everyone would end up setting it up. And the only ones offering for free would be spies and the like.
16:33:22 <fort3hlulz> Interesting...
16:33:30 <fort3hlulz> But no mobile service supports pay-for-rpc AFAIK
16:33:38 <fort3hlulz> But they all run their own nodes, so I guess that would be fine.
16:33:49 <moneromooo> They're spies then :)
16:33:52 <fort3hlulz> :P
16:34:04 <fort3hlulz> Guess it's time to get around to setting up my pay-for-rpc settings
16:34:08 <yanmaani> If people have to pay $0.1 in RPC mining credits to send a transaction, it stands to reason that they would be inclined to pay $0.1 less in fees. This is a loss of $0.1 for the miners as a group, and a gain of $0.1 for the individual running the node.
16:34:15 <hyc> hm, yeah, my moneroworld node is still free
16:34:24 <fort3hlulz> same hyc
16:34:51 <Spaceguide> Moneromooo : actually, I'm looking for a machine, I can set up with enough memory, and enough cores avail, to come online, avail for all, not to spy
16:35:03 <yanmaani> Also, people would just pick the cheapest node. If you can either use Tor and use the chainalysis catamites' node for $0.0, meaning no/little privacy loss, or pay $0.1 and use some trusted guy's node, meaning no privacy loss, people would go with the former.
16:35:31 <yanmaani> So it's arguably better that everyone provide free nodes, as it would decrease spies' expected gain from doing so
16:35:50 <yanmaani> How much does it cost in hardware to run an RPC node anyway?
16:35:54 <Spaceguide> I don't consider myself a spy
16:36:17 <fort3hlulz> yanmaani not much, honestly, it's a pretty light usage server on my HW which is also running many other procs and mining at the same time
16:36:25 <fort3hlulz> good to know Spaceguide lol
16:36:43 <moneromooo> If people don't want to pay extra, they run their own node. That's the idea. Push them.
16:37:01 <yanmaani> moneromooo: But that also is a cost. On TAILS fo rexample, there is no point
16:37:06 <moneromooo> And spies will start charging a bit too when it becomes obvious free ones are likely spies :)
16:37:12 <yanmaani> all you are doing is introducing new rent-seekers to a systme which doesn't need them
16:37:29 <yanmaani> If I do submit my txns to adversarial remote nodes using Tor, WCGW?
16:37:39 <moneromooo> They only get rent from people who'd be useless to the network.
16:37:46 <yanmaani> won't Monero's encryption protect me still?
16:37:47 <moneromooo> But yes, fair point.
16:37:54 <yanmaani> Or are you talking about fake chain attacks etc?
16:39:23 <fort3hlulz> Are there any good guides on setting up the pay-for-rpc system?
16:39:31 <fort3hlulz> Best I found was: https://monero.stackexchange.com/questions/11731/how-do-the-new-rpc-payment-options-for-monerod-work
16:44:07 <yanmaani> Anyway, it seems like it wuold be smarter to simply make it more secure to use remote nodes
16:45:06 <d4ndo[m]> dandelon++ helps
16:46:36 <moneromooo> Making it more secure to use remote nodes makes it less secure for the network, even though more secure locally for the person surrendering.
16:48:21 <fort3hlulz> Well I added the payment for RPC option with my address, and now I can't use Cake Wallet with my own node :P
16:49:23 <yanmaani> moneromooo: What is the harm?
16:49:38 <yanmaani> There is no good alternative with TAILS, anyway. The spies can just run for-payment nodes.
16:50:28 <moneromooo> You can see the harm when you push it to the extreme: everyone uses one node.
16:50:55 <moneromooo> Spies will run for payment nodes, sure, but the process will have pushed some proportoin of people to run their own damn node, which was the goal.
16:51:22 <yanmaani> No, I can't see the harm
16:51:27 <yanmaani> everyone is using one node. What now?
16:51:50 <yanmaani> (assuming that they check PoW from multiple sources)
16:51:57 <d4ndo[m]> moneromooo has seen some shit. He knows there will be a Google 2.0 for blockchain.
16:53:16 <d4ndo[m]> And i agree with him
16:53:18 <fort3hlulz> yanmaani the main risk would be a node lying about the contents of a block, or censoring transactions, etc etc
16:53:19 <yanmaani> what is the risk tho
16:53:30 <fort3hlulz> There are MANY risks if there is only one entity running a full node
16:53:39 <fort3hlulz> Because they become the source of truth for the entire network
16:53:48 <Spaceguide> indeed
16:53:50 <fort3hlulz> YOu're trusting them to verify transactions
16:53:50 <yanmaani> fort3hlulz: This is trivial to fix though. If it doesn't match the hash, it won't verify
16:54:01 <fort3hlulz> The hash that you get from where?
16:54:03 <yanmaani> No, remote nodes are not verifying transactions
16:54:24 <fort3hlulz> You're trusting that they verified other TXs, and they will be the ones verifying yours
16:54:24 <yanmaani> that's the exact same question for the rest of the network. There is no good argument for why I can't interrogate like ten nodes and see if they're all lying to me.
16:54:41 <fort3hlulz> Not sure what you mean.
16:54:44 <yanmaani> fort3hlulz: No, remote nodes do not verify transactions. You download the blockchain from them, look for your transactions, and discard it.
16:54:51 <fort3hlulz> If there was only one node/entity you can't interrogate others
16:54:53 <yanmaani> If they insert junk into it, it won't validate or anything
16:54:59 <fort3hlulz> What would you compare it against?
16:55:04 <fort3hlulz> If you didn't run your own full node?
16:55:06 <yanmaani> SOmeone who just offers hashes +PoW
16:55:31 <fort3hlulz> That's a lot of trust in two entities to not lie to you/collude
16:55:33 <yanmaani> there's only one full node that serves the full blocks, but you should trivially be able to get block headers
16:55:38 <yanmaani> they are tiny
16:55:43 <yanmaani> no, I don't trust the block serving node at all
16:55:49 <yanmaani> and serving block headers is absurdly cheap
16:55:54 <asymptotically> couldn't a bad node only withhold full blocks from you, not just singular transactions from a block?
16:55:56 <asymptotically> and never insert bad ones
16:56:01 <fort3hlulz> that as well
16:56:01 <yanmaani> ^
16:56:04 <fort3hlulz> There are many, many attacks
16:56:04 <yanmaani> they'd have to make fake blocks
16:56:12 <asymptotically> make fake blocks aka. mining? :D
16:56:14 <yanmaani> no you are just spreading FUD
16:56:20 <fort3hlulz> ?
16:56:22 <fort3hlulz> llol
16:56:25 <yanmaani> asymptotically: Mining, while concealing other blocks
16:56:28 <yanmaani> so as to drive down the difficulty
16:56:43 <yanmaani> Your argument is the same for full-nodes, that's my problem
16:56:51 <yanmaani> what prevents all your peers, as a full node, from lying to you?
16:57:07 <fort3hlulz> Nothing, thats why I connect to many and verify what I see against the rules my full node has set
16:57:19 <fort3hlulz> Thats kinda the whole point of a p2p network thats decentralized
16:57:30 <yanmaani> And what prevents a thin node from doing the same?
16:57:33 <fort3hlulz> multiple bad actors can be present while I still verify the true state of the chain
16:57:35 <asymptotically> yanmaani: but then they'd be mining on their own chain, earning only worthless coins
16:57:44 <d4ndo[m]> I guess the best way to get more decentralization is to keep the blackchain small. So no one bothers to setup a remote node.
16:57:46 <yanmaani> Electrum (Bitcoin) is thin, and that interrogates multiple nodes
16:57:57 <yanmaani> asymptotically: yes, but if the difficulty is low enough that's immaterial
16:58:01 <d4ndo[m]> Maybe DAG? dont know
16:58:03 <yanmaani> the idea is that they double-spend etc
16:58:19 <moneromooo> Guys, clearly trolling if "not seeing" why only a chain with one node is a risk. Don't feed.
16:58:43 <yanmaani> The threat model I'm describing is that there's only one node serving the full chain, but several nodes serving block headers.
16:58:46 <moneromooo> ("decentralized" chain - it's not a risk if it's meanbt to be centralized)
16:58:53 <yanmaani> I'm not trolling here. Electrum does this, and it works fine!
16:58:59 <endogenic> Tell me more
16:59:03 <yanmaani> It has some prbolems, but Monero's equivalent thing mode doesn't have these
16:59:19 <yanmaani> Bad Electrum nodes can spy on you, Monero nodes can't as I understand it
16:59:29 <asymptotically> endogenic: i hear mymonero only sends transactions that include tithes to endogenic. is this true?
16:59:37 <fort3hlulz> If there is only one full node/entity, it holds all of the economic power of the network
16:59:45 <fort3hlulz> As its the only one able to create and publish block templates
16:59:47 <endogenic> True
17:00:31 <yanmaani> fort3hlulz: That's not what's being discussed
17:00:40 <fort3hlulz> <moneromooo> Guys, clearly trolling if "not seeing" why only a chain with one node is a risk. Don't feed. <- probably true, I've never heard anyone argue that no one needs to run a node for a network to properly function
17:00:50 <endogenic> Some Monero nodes can be given permission by a user to spy on the user...
17:00:51 <fort3hlulz> So many risks associated
17:00:53 <yanmaani> Everyone *using* one node is not the same thing as there only being one node.
17:01:35 <yanmaani> You still haven't explained these "risks" to me very well, other than meaningless nonsense about "connecting to many [nodes] and verifying what I see against the rules my full node has set".
17:01:47 <yanmaani> I'll ask you again, what prevents a thing node from doing the same?
17:02:07 <fort3hlulz> Can a thin node verify transactions? Or just that a block validates PoW?
17:02:27 <fort3hlulz> *historical transactions
17:02:28 <yanmaani> A thin node verifies transactions, yes.
17:02:43 <yanmaani> I set the block height, and it downloads the blocks from that height and looks for my transactions in there.
17:02:48 <yanmaani> That is how the current remote node system works.
17:03:17 <yanmaani> The only attacks are feeding someone a false chain via 100% node domination, which is the exact same risk as for full nods
17:04:15 <Spaceguide> can't full nodes verify eachother ?
17:05:12 <yanmaani> "Verify" how? There is nothing that obligates a full node to act in any way
17:14:22 <fort3hlulz> Unless I've misunderstood everything I've read to this point on the importance of full nodes, you're giving the node you use trust that they serve you the proper/accurate blocks for your wallet to scan against, and that trusting one entirely would be putting full economic weight on them
17:14:40 <fort3hlulz> Yes, if you did that and checked headers against some other node/entity, that would help with completely false blocks being provided
17:14:47 <yanmaani> What prevents you from using multiple nodes?
17:15:05 <yanmaani> The current implementation is that you set one remote node. Why couldn't you ask 10 of them? This would make Sybil attacks far harder
17:15:10 <fort3hlulz> But that wouldn't prevent against the node/entity you're using from denying/delaying your TXs that you're sending them
17:15:27 <yanmaani> No, but you can just mass send them.
17:15:35 <yanmaani> Again, same with full nodes.
17:15:36 <fort3hlulz> we were talking about if everyone used one node
17:15:41 <fort3hlulz> I guess you've moved on from that now
17:15:47 <yanmaani> No, one node for the chain
17:16:11 <fort3hlulz> I mean thats not the point moneromooo brought up, but if you want to change it to that, sure
17:16:19 <yanmaani> "You can see the harm when you push it to the extreme: everyone uses one node."
17:16:24 <fort3hlulz> yeah
17:16:31 <yanmaani> that's what I meant, in an RPC context
17:16:42 <fort3hlulz> anyway
17:16:50 <yanmaani> broadcasting transactions has the same problems as feeding you fake chains: everyone must collude
17:17:06 <yanmaani> if even one defects, it'd done for. And txns have a direct financial incentive to be broadcasted
17:17:20 <yanmaani> I remain unconvinced of the dangers of SPV.
17:17:31 <fort3hlulz> If there is one full node for the entire network, they are the only source of historical transaction verification, are they not?
17:17:34 <fort3hlulz> Are we talking about SPV?
17:17:43 <fort3hlulz> I thought we were talking about one RPC full node serving all users
17:17:57 <yanmaani> If there is only one full node that users use for RPC stuff. This doesn't prevent there from being other full nodes not serving RPC.
17:18:10 <fort3hlulz> Ok, not sure why you keep moving the goalposts but sure :)
17:18:14 <moneromooo> yanmaani: we might just be missing each other's points, so let me state clearly my point here:
17:19:08 <moneromooo> - being decentralized here is a design goal for the purposes of the argument
17:19:13 <yanmaani> there's no moving of goalposts; this is moneromooo's threat model. My suggestion is, to be clear, that clients query multiple (say, 10) remote nodes, picking them from a big list. Remote nodes could sign their queries as well, so that you'd have clear proof if anyone does somethign shady.
17:19:19 <yanmaani> moneromooo: Agree on the first point thus far.
17:19:50 <moneromooo> - I take the trend to the extreme to show why it ends in somehting bad - it might well be that *some* of it isn't very bad
17:20:26 <moneromooo> - if everyone decides to not run their own node because using someone else's is easier, or cheaper, or otherwise, then you end up, at the extreme, with one node
17:20:29 <yanmaani> Second point, agreed, that's an useful epistemiological strategy
17:20:31 <moneromooo> - one node is not decentralized
17:20:38 <yanmaani> third point is sort of self-evident
17:20:48 <yanmaani> fourth point does not seem too credible. Electrum doesn't have this problem
17:21:00 <yanmaani> despite Bitcoin full nodes being extremely expensive to run
17:21:07 <moneromooo> Electrum works on Bitcoin. Bitcoin has tons of nodes.
17:21:38 <yanmaani> fifth point I contest. One RCP-serving node is safe, as long as you have some way to obtain independent confirmation of block hashes and some independent way to submit txns.
17:21:56 <yanmaani> moneromooo: Sure, but far from all of those are Electrum servers.
17:22:39 <moneromooo> How is that relevant ?
17:23:06 <moneromooo> Eletrum is not a parallel network AFAIK (admittedly, I don't really know much about it)
17:24:24 <yanmaani> Electrum is a separate network. You need a full node to run an Electrum server.
17:24:41 <yanmaani> With it, you can send transactions, get block headers, and ask what transactions are sent to an address.
17:24:56 <yanmaani> The client keeps the state of the latest block headers, and the servers send proofs of inclusion within the blocks.
17:25:09 <moneromooo> It's a view over the Bitcoin network, right ?
17:25:20 <yanmaani> The miners are trusted to create valid blocks, and the servers are trusted not to exclude transactions, and not to log your addresses
17:25:25 <yanmaani> "view over"?
17:25:59 <yanmaani> In Monero's equivalent, the miners aren't trusted to create valid blocks, the servers aren't trusted not to exclude transactions, and them logging your IP is immaterial.
17:26:00 <moneromooo> I'm surprised by "Electrum is a separate network". AFAIK an electrum server is a server that allows a client to query the Bitcoin chain.
17:26:20 <yanmaani> Yes, but Electrum servers are distinct from Bitcoin full nodes
17:26:39 <d4ndo[m]> How did the Unix and Gnu philosophy survive the onslaught of idiocy?
17:27:05 <moneromooo> Do you mean: Alice runs a electrum client, connects to an electrum srever run by bob, which connects to a bitcoin server run by carol ?
17:27:06 <hyc> I give up. How?
17:27:38 <d4ndo[m]> XD. I'm asking you.
17:27:41 <fluffypony> no, typically the Electrum server and the Bitcoin node are on the same machine
17:27:56 <d4ndo[m]> Maybe a manifesto?
17:27:58 <fluffypony> but I agree that it's a separate network in that Electrum clients can't connect to Bitcoin nodes
17:28:00 <yanmaani> moneromooo: Bob=Carol generally
17:28:05 <fluffypony> and Bitcoin clients can't connect to Electrum servers
17:28:10 <yanmaani> ^
17:28:11 <yanmaani> that
17:28:17 <moneromooo> In any case, it doesn't matter. The fact that Alice doesn't run her own bitcoin node is not impacted by whether carol and bob are the same person.
17:28:47 <yanmaani> ehhh this is all semantics. let's say for the sake of arguments 99% of bitcoin fullnodes run electrum servers too. what's your point?
17:29:02 <yanmaani> with small modifications to Monero, you could get good security for remote nodes
17:29:37 <hyc> security against what threats?
17:30:04 <moneromooo> You consistently try to reinterpret nmy point about security of the network in terms of security of a single Alice.
17:30:33 <yanmaani> hyc: Now, your remote node could serve you a "fake" chain. This gets exponentially harder with multiple remote nodes.
17:30:42 <moneromooo> You could make it more secure than currently for Alice (assuming she already decided not to run her node).This is not my point in the first place.
17:30:56 <yanmaani> moneromooo: Say that it degenerates to Bitcoin's status quo: some people run full node, but there's say 1000x more users of electurm than there are full nodes
17:31:36 <yanmaani> Not "one node", but a few hundred or so. Some of whom are run by mining pools, some of whom are run by chainalysis catamites, and some of whom are run by random people
17:31:46 <moneromooo> In the extreme, those multiple remote node are all the same, beause nobody runs their damn node.
17:31:54 <moneromooo> Bah. Whatever.
17:32:00 <yanmaani> There's 10.5k bitcoin full nodes
17:32:04 <yanmaani> and ~millions of bitcoin users
17:32:12 <yanmaani> yet the security is ... fine?
17:32:50 <hyc> because bitcoin's security model completely lacks a privacy model
17:33:26 <yanmaani> what are you saying is the danger if we do the same for Monero? The Monero equivalent is "streaming" the chain, which is private
17:33:50 <moneromooo> I don't think that's really a factor. It's the old "look, this dude took a step towards the cliff, he's still alive, so it's fine, so let's take more steps" argument.
17:34:03 <moneromooo> So year, trolling I think.
17:34:18 <yanmaani> look, I get that you may disagree with me, that is fine and natural and good
17:34:33 <yanmaani> but it is shockingly offensive to accuse me of arguing in bad faith, and of not actually holding these opinions
17:34:58 <yanmaani> I do use Electrum for my everyday transactions, and I do use Monero in remote node mode. I am serious when I say that it's a shame Monero's support for it is bad.
17:36:17 <moneromooo> I also find it shockingly offensive that you just again go for the single user security argument after I specifically explained by this is not ny point ^_^ Bye :)
17:36:55 <moneromooo> And FWIW it someone makes a patch to use several remote nods and compre, I think I'd be ok with it, as things go.
17:37:12 <moneromooo> Even if it gives even more incentive for people to not run thier own node :/
17:37:57 <moneromooo> It kinda sucks. You make better software, but the very act of doing so makes something else worse that's more important in the big picture :(
17:38:33 <moneromooo> Like when I kinda regretting patching the privacy leaks to the daemon when making a tx.
17:38:46 <yanmaani> seems like there's a bit of a Platonic ideal thing there. It's sort of like with science
17:39:22 <yanmaani> if some worldview is intrinsically more correct than another, that's whither the consensus will trend
17:39:40 <moneromooo> Ironically, if we didn't have this node/wallet split, people wouldn't be so eager to use a stranger's node.
17:39:45 <yanmaani> if you have buggy software then that will theoretically speaking trend towards less buggy software, assuming people only merge the good PRs
17:40:39 <yanmaani> What's the minimum limit to be a full node, in your view?
17:40:45 <yanmaani> A pruning node is still a full node, right?
17:40:52 <yanmaani> And a node that discards old blocks isn't?
17:42:38 <moneromooo> Depends on your definition of "full node" really.
17:42:59 <yanmaani> what's youre definition?
17:43:01 <Spaceguide> for me, both would not be full node
17:43:02 <moneromooo> For the purposes of my argument above, "you sync and verify all" was what I was on about.
17:43:23 <moneromooo> Being able to serve others historical data is also important.
17:43:31 <Spaceguide> indeed
17:43:36 <yanmaani> Aren't Monero's present implementation of remote nodes full nodes too, then? If I use a remote node, don't I stream the whole of the chain?
17:43:47 <moneromooo> Pruned nodes can serve an eigth of the hostirical data (by design). So they're not just useless nodes.
17:44:09 <yanmaani> serving the chain by hash is literally just dumb 100% sybil resistant block storage CDN stuff, and can be decoupled from "making assertions about the correct tip"
17:44:13 <moneromooo> Actually, let's agree on a definitin here:
17:44:58 <moneromooo> most people use "remote node" to mean a node run by another party, rather than a node which might or might not be yours that's running on another host. Here, you mean the former, right ?
17:45:26 <yanmaani> yes
17:46:28 <moneromooo> So if you have a wallet, but use a stranger's remote node, you don't stream the whole of the chain.
17:46:40 <yanmaani> What do I miss out on?
17:46:42 <moneromooo> You stream pruned txes, and scan their outputs.
17:46:56 <yanmaani> What is the downside of this?
17:46:57 <moneromooo> You miss the non pruned part (signatures) and block headers.
17:47:07 <yanmaani> Oh wait what?
17:47:10 <moneromooo> The wallet does not do any verificatiuon, since the node already did it.
17:47:16 <yanmaani> Why don't the block headers commit to the non-pruned part?
17:47:18 <yanmaani> like in BC SW
17:47:22 <moneromooo> It could do some more, but that's the node's job ffs :D
17:47:39 <moneromooo> What is BC SW ?
17:47:44 <yanmaani> bitcoin segwit
17:47:54 <moneromooo> No clue what this does.
17:48:06 <yanmaani> The block header is (roughly) hash(hash(pruned txns) || hash(signatures))
17:48:40 <moneromooo> Monero blocks include tx hashes.
17:48:54 <yanmaani> yeah but not of the pruned ones
17:49:06 <yanmaani> with SW-style headers, I could verify that the block header matched the pruned TXes
17:49:16 <moneromooo> Modern monero txes also commit to their pruned part (I forget the details).
17:49:34 <moneromooo> (not old ones)
17:49:35 <yanmaani> Oh, OK. So could I verify it it if my remote node did send block headers too?
17:49:59 <moneromooo> You could verify more stuff. I won't give a list because I don't know off the top of my head.
17:50:21 <moneromooo> But you could verify PoW for one thing. You could verify tx sigs, even when pruned.
17:51:26 <yanmaani> If you have a full node that didn't serve 1/8 of historical data, would it still be a full node?
17:51:28 <kinghat[m]> iirc, a 1/8th pruned node != 1/8th future transaction bandwidth?
17:55:12 <moneromooo> As I said, it depends how you define it. If you define it as such, yes. If not, no.
17:55:25 <moneromooo> If it's a reference to a bitocin definition, I don't know it.
18:00:42 <yanmaani> you seemed to have a clear definition in mind
18:00:54 <yanmaani> paraphrasing roughly, "it's bad if there's not enough full nodes"
18:04:21 <moneromooo> I don't. If you're going to consider nodes that can only do part of the things others can, then being able to do more is better.
18:05:16 <moneromooo> But it's subjective. In a way, the pruned node ability is similar to a remote node in that running an unpruned node would, ceteris paribus, lead to a stronger network.
18:06:03 <moneromooo> Very different in terms of impact though.
18:19:55 <Mochi101> The ability to prune should make more people run nodes.
18:22:00 <d4ndo[m]> A pruned node  is ok for smart phones.
18:22:40 <Mochi101> Some people have to pay for storage space d4ndo[m]
18:22:58 <Mochi101> Pruned nodes help lessen the cost.
18:31:07 <yanmaani> So my question is, if you run pruned nodes that don't serve the blockchain and discard transactions after validating it, is that a full node?
18:31:27 <yanmaani> If so, how is it functionally different to remote nodes?
18:31:34 <yanmaani> If not, then where does the line go?
18:34:43 <moneromooo> Is touching someone ok ? If so, how hard is it fine to touch someone ? Can I punch someone hard ? Where is the line ? Well, guess what, there is no line.
18:44:05 <yanmaani> Could you create a secure remote node implementation, that verifies enough to give security to the network?
18:44:17 <d4ndo[m]> We could use a manifesto: Run your own node. etc. See the gnu manifesto. The linux kernel dev deny propertary source code for drivers.
18:46:06 <moneromooo> You mean write some software that talks monero p2p which could strengthen the network more than a normal monero node could ?
18:46:35 <moneromooo> If that was the case, then the normal monero node could be made to do so, since your difference seems to be "remote", as in a stranger's.
18:48:00 <moneromooo> From what I understand of what you said, you want to make "software run by bob only" to be more secure than "same software run by bob *and* alice", which seems nonsensical, *unless* the very fact that alice runs a stranger's node is what increases network security. Which seems absurd to me.
18:48:28 <moneromooo> At least for a decentralized network. It would be the case if the network was supposed to rely on trust in bob.
18:49:09 <yanmaani> in Bob we trust
18:49:10 <moneromooo> If you just mean "make using bob's node safer for alice", then sure, we already established that.
18:50:06 <yanmaani> My point is that a "remote" node could be a full participant in the network
18:50:20 <yanmaani> get the block hashes, only get the pruned transactions, but participate in the P2P network and peer discovery and all
18:50:51 <moneromooo> It is currently a full participant.
18:52:33 <moneromooo> But it is *one* full participant. If Alice were to use her own node and not Bob's, there would be *two* full participants. That is my point.
20:05:35 <yanmaani> No, Alice just connects to the broader network
20:05:44 <yanmaani> no Bob involved. Or rather, all the nodes in the P2P network are Bob
20:10:17 <Mochi101> Bob and Alice are sure a big part of the Monero dev community. We should all thank them.
21:16:54 <guernsey> hello
21:20:28 <guernsey> do anyone knows how to insert tx version +3 on basic.h or on some other file
21:20:37 <guernsey> monero code is huge
21:24:14 <guernsey> sorry no googling for this.
21:24:18 <guernsey> too deep
21:57:33 <guernsey> is anyone on this chat
21:57:52 <yanmaani> yes
21:58:24 <guernsey> how to insert tx version +3 on basic.h or on some other file
22:01:12 <guernsey> simple for monero folks
22:25:30 <moneromooo> You'd think so. It's definitely possible, but I'd just go through every error and fix till it works.
22:32:21 <guernsey> ss << tx_blob;
22:32:28 <guernsey> this is the error line
22:33:31 <guernsey> i insert on basic.h class transaction_prefix version 4 but is not enough
22:34:05 <guernsey> maybe is need a other type of inserting
22:34:21 <guernsey> im not c++ guru
22:35:02 <guernsey> maybe tx u can change on other file
22:35:09 <guernsey> code is really huge
22:37:39 <guernsey> monero folks
22:37:45 <guernsey> anyone?
22:43:11 <yanmaani> what are you trying to accomplish?
22:43:29 <guernsey> new chain with version 4
22:45:22 <yanmaani> why
22:46:31 <guernsey> version 4 has ringct
22:56:43 <guernsey> monermooo maybe u are the greatest folk here so help on this
22:56:53 <guernsey> with yoru experience is nothing
22:59:36 <moneromooo> As I said. I don't know, I'd have to debug each error till they're all gone.
23:01:24 <guernsey> i told the line ss << tx_blob;
23:01:45 <guernsey> the reason is that tx +3 need smth else
23:01:48 <guernsey> dont know
23:01:58 <guernsey> with tx <=3 wokr
23:02:00 <guernsey> wrok
23:02:05 <guernsey> work
23:03:08 <guernsey> maybe class transaction_prefix we need some other structure to insert
23:27:47 <guernsey> back
23:27:56 <guernsey> any help
23:34:54 <Bobtette> Hi guys. I´m experiencing an issue with Monero GUI.
23:34:58 <Bobtette> Maybe somebody can help.
23:35:31 <guernsey> #monero-gui
23:37:55 <Bobtette> Sorry, i´ll ask there.
23:39:00 <guernsey> moneromooo where to insert tx version +3
23:39:23 <guernsey> is very basic for monero this really
23:47:13 <guernsey> alive here
23:56:20 <yanmaani> "Quality, low noise discussions expected"
23:56:46 <yanmaani> anyone who can understand your question already understood it in the first three messages. there's no need to shit up the channel