01:37:25 <gingeropolous> idea - maybe i can do it, probably someone here can accidentally do this when they poop - basically, get this code: https://apollo.open-resource.org/flight-control/noncewatch/
01:37:31 <gingeropolous> and host it and actually keep it up to date
01:37:49 <gingeropolous> to get fancy, run stats on the data to detect new patterns when they emerge and highlight them
01:42:54 <Adreik> What statistical patterns in nonces would be considered interesting? Is there a specific banding pattern that would be considered indicative of ASIC activity; why?
01:54:54 <gingeropolous> usually its anything that deviates from random, or deviates from the existing patterns
01:55:48 <gingeropolous> and it wouldn't really indicate ASIC activity, but it would indicate that there is something new. It could be a tweaked mining software, or a new mining software, etc
01:56:42 <gingeropolous> actually, what you could do is correlate the block receive times to the nonces, and see if the quick block sets have different nonce patterns
01:56:47 <gingeropolous> though the n is probably too small
01:59:03 <gingeropolous> Adreik, u can check out a lot of the nonce sleuthing that occurred circa 2019 to see how nonce analysis suggested / confirmed ASICs
01:59:34 <Adreik> Yeah, I remember reading something about that which was why I asked about ASIC patterns in nonces
02:01:11 <Adreik> Why is there banding in the first place since if it's a cryptographic hash function it should be completely flat distribution?
02:02:12 <Adreik> (Unless software was choosing non-random nonces to test)
02:23:10 <rehrar> ok, computers plugged in
02:27:57 <Prox1> I see we're talking about XMR.
02:28:12 <Prox1> It's much more private than BTC, but as was said by seth, it's not perfect.
02:28:20 <Prox1> You should use it if privacy is your main concern.
07:08:06 <yanmaani> where does the line go between a SPV and a non-SPV node? Is a node which scans but doesn't download the blockchain SPV?
07:14:01 <Adreik> Is there any way to specify the transaction key when signing a transaction, or is it generated automatically?
07:14:17 <Adreik> Only generated automatically, I mean
07:19:37 <UkoeHB_> he left.. what situation would you want to sign a transaction with a different transaction's key?
10:54:08 <gingeropolous> yanmaani.... i think that difference exists if you think of a wallet connected to a remote node as SPV....
10:54:11 <gingeropolous> but its not really a node
11:05:33 <s4rc1na[m]> in your opinion, what is the best exchange service for XMR to € or $?
11:07:21 <asymptotically> s4rc1na[m]: if you don't mind sending off photos of your id, stool sample, etc., kraken is nice
11:07:29 <asymptotically> otherwise you might like localmonero.co
11:08:46 <s4rc1na[m]> but localmonero is trading website and at the end you'll be recognizable through your bank account or paypal or ... and that's something I'm not a big fan of
11:10:55 <s4rc1na[m]> but sending stool sample is no issue :)) there is shitexpress.com that can do that on my behalf with about 12 bucks
11:23:43 <charolastra> they should rename it to notsolocalmonero then
11:29:58 <yanmaani> gingeropolous: Yeah, but what if you'd make it so that the local node downloads a reduced blockchain?
11:30:13 <yanmaani> Only the stuff it needs the view key to decrypt, adn there's some kind of tree so it can see it's legitimate
11:30:28 <yanmaani> is that a full or a SPV node? It doesn't check the validity of transactions, but it has all the other trappings of a full node
11:30:44 <yanmaani> s4rc1na[m]: You can use money orders in the mail
11:32:07 <gingeropolous> yanmaani, id hazard a guess that what your saying is close to a headers-only sync, and yeah thats possible. Will it ever end up in the monero core software itself? probably not.
11:32:16 <gingeropolous> but someone can make a standalone client that scrapes the network
11:32:34 <yanmaani> Well, except for the bit where it needs to be bug-for-bug compatible
11:32:34 <Adreik> Like Electrum for Bitcoin
11:32:38 <gingeropolous> yep
11:32:38 <yanmaani> right
11:33:00 <gingeropolous> just waiting for that mythical Someone
11:33:07 <gingeropolous> SomeOne ,  the Legend
11:33:15 <yanmaani> yeah but it's not even possible. There can be only one implementation, ever
11:33:23 <yanmaani> (also it'd require changes to monero)
11:33:26 <gingeropolous> there's electrum
11:33:35 <yanmaani> yeah but that has an electrum server
11:33:51 <Adreik> You could checkpoint the hash at which we RingCT starts being mandatory (new wallets don't need ring member data from before then)
11:33:57 <yanmaani> and it doesn't do things very securely
11:33:57 <gingeropolous> naw it wouldn't. i mean, the wallet already is kinda doing that. it just currently discards block information it deems unnecessary
11:34:12 <gingeropolous> it dloads a block, scans it with keys, and then makes the data go poof afaik
11:34:21 <Adreik> There can absolutely be multiple implementations of Monero, they just need to be compatible otherwise you get a fork
11:34:22 <gingeropolous> from a "trusted" remote node
11:34:26 <yanmaani> gingeropolous: Yeah, but if you want to have only the "is this for me" cleanly separated
11:34:30 <yanmaani> you wouldn't have to trust the remote node
11:34:33 <gingeropolous> its the trust thing. you remove actual tx verification, you introduce trust
11:34:38 <yanmaani> Adreik: Yeah, and they have to be bug-for-bug compatibel
11:34:38 <gingeropolous> well, u trust the hashes
11:34:40 <Adreik> Someone could make Monero on brainfuck for all the rest of the network cares
11:34:42 <yanmaani> gingeropolous: with respect to the miners
11:34:56 <yanmaani> but you can only do that if the signatures are separated
11:34:59 <gingeropolous> and i agree.... trusting hashes might be enough. there's been lotsa discussions on this
11:35:03 <yanmaani> from the diffie hellman things
11:35:11 <yanmaani> Adreik: No. See Bitcoin's database troubles.
11:35:20 <gingeropolous> well an spv node wouldn't provide data for new nodes to sync from
11:35:22 <gingeropolous> that bollucks
11:35:37 <yanmaani> It could keep a cache of X megabytes
11:35:41 <gingeropolous> i mean, i guess you could have an unverified data set, and then feed it to someone else for them to verify
11:35:43 <yanmaani> that's better than the current remote node system
11:35:52 <yanmaani> It can let it be verified by the hashes
11:36:20 <yanmaani> "I'd like the block with the hash asdasd1213123123 please" "OK here's some data which hashes to that, this is what you asked for, validation is your problem"
11:36:59 <gingeropolous> right. l, like i said, its a slippery slope adding those kinds of shortcuts to trustlessness
11:37:02 <Adreik> Realistically many times you recieve a payment you know what block range it's in, and may even know the transaction hash. So the SPV XMR wallet could request a specific block range, plus some other randomly generated ones for making ring sigs with
11:37:30 <yanmaani> gingeropolous: Well as long as you trust the miners. If you don't trust the miners, they might as well do a 51%
11:37:35 <Adreik> No need to download the full block to check every transaction if the user knows what transaction(s) are theirs and where they are
11:37:36 <gingeropolous> there's a great bitcoin PR thread about this on their github. it set me right about the philosophy of the core software
11:38:01 <yanmaani> and I imagine you could do fraud proofs - "this mined block is invalid, because this UTXO comes from nowhere"
11:38:14 <Adreik> The core software shouldn't have it, but it's fine for something like cake/electrum
11:38:37 <gingeropolous> yep
11:38:58 <gingeropolous> the core software has one goal. to create the monero network. if the core software doesn't do that, there is no network.
11:40:20 <gingeropolous> bbbuuuut if it does more, more people will download it and use it!
11:40:22 <gingeropolous> you say.
11:40:23 <gingeropolous> indeed
11:40:33 <yanmaani> No, that's not my complaint
11:40:43 <yanmaani> something like cake or electrum would be fine
11:40:48 <gingeropolous> thats what i say :)
11:40:52 <yanmaani> but you need changes to the actual block format in the protocol
11:40:53 <gingeropolous> im talking to meself :)
11:40:58 <yanmaani> to make it secure
11:41:12 <gingeropolous> i think monero has that in place
11:41:42 <yanmaani> Oh ok. Yeah, but there's also the second issue: you will need a bug-for-bug compatible re-implementation of monerod
11:42:01 <gingeropolous> why?
11:42:03 <Adreik> Not "bug for bug", just consensus rules
11:42:14 <gingeropolous> an spv node shouldn't be sharing its information
11:42:19 <yanmaani> gingeropolous: Are you familiar with Bitcoin's database woes?
11:42:22 <gingeropolous> its effectively your own dumbed down node
11:42:25 <yanmaani> Adreik: Bugs are consensus rules.
11:42:29 <gingeropolous> you shouldhn't spread your dumb
11:42:30 <Adreik> Depends
11:42:36 <yanmaani> no, always
11:42:42 <Adreik> If it's a bug with flush-tx pool, for example
11:42:44 <yanmaani> for a re-implementation to be useful, it has to:
11:42:46 <Adreik> Or anything else internal
11:42:56 <yanmaani> 1) see all invalid blocks as invalid
11:43:01 <yanmaani> 2) see all valid blocks as valid
11:43:13 <yanmaani> if it sees a valid block as invalid, it will fork off. That's extremely bad.
11:43:39 <yanmaani> If it sees an invalid block as valid, that's less bad, because of the miner stuff, but it's still not good. If you're not mining with it, it's acceptable, but bugs can go both ways.
11:44:03 <Adreik> yes, but a "bug" could also be something like "freezes for a minute if block starts with hash 012", which isn't really as much of a problem
11:44:19 <yanmaani> That's not what I'm talking about
11:44:28 <yanmaani> for an actual example, see bitcoin's database woes
11:44:34 <Adreik> Yes, you are talking about consensus rules
11:44:42 <yanmaani> yeah, and some of those are bugs
11:44:45 <yanmaani> and you do not want to fix them
11:45:27 <yanmaani> Bitcoin has bugs that would cause hardforks if fixed. A successful re-implementation must implement those bugs on purpose
11:45:47 <Adreik> Monero is not cowardly in the face of scheduled hardforks where everyone agrees that they should upgrade to the latest implementation
11:46:10 <yanmaani> That's entirely irrelevant here
11:46:13 <Adreik> Bitcoin can have the first coinbase unspendable or whatever forever, that's their problem
11:46:23 <yanmaani> if monero has some weird bug, you have to implement it too up until the hardfork
11:47:07 <Adreik> It's likely moot because the SPV server would share pretty much all the logic from regular monerod.
11:47:11 <yanmaani> And your implementation will always have flaws. So unless you can maintain a slimmed fork of Monero, it's basically impossible
11:47:27 <Adreik> With regards to block validation
11:47:51 <Adreik> The responses to the wallet's RPC requests or whatever would be different of course
11:48:06 <yanmaani> yeah if the SPV server is just gutted monero then it's fine. But then you can't run it as part of the normal network anymore
11:48:51 <Adreik> I think there has been a misunderstanding: SPV node (meaning client) vs SPV server
11:49:11 <Adreik> SPV server would be basically a full node with slight modification in how it responds to requests from wallets
11:49:28 <Adreik> SPV client will be a heavily modified version of wallet
11:50:56 <yanmaani> Sure, but then you need that distinction. If you can gut monero sufficiently, you can just have all the nodes be SPV servers
11:52:29 <Adreik> So backup a minute: what's the main problem that people say is an issue with the current remote node system, that it takes too long to download the blocks and check if any transactions are yours using the private viewkey?
11:52:31 <Adreik> Or something else
11:52:53 <yanmaani> that you must trust your remote node
11:53:07 <Adreik> That's true for any SPV implementation
11:53:34 <Adreik> To a certain degree anyway
11:54:34 <yanmaani> Not in this case. You only have to trust miners.
11:55:19 <Adreik> What are you talking about here, checking the difficulty of block headers?
11:56:51 <asymptotically> yanmaani: the remote node can't just make up blocks to send you, they still need to be valid
11:57:09 <yanmaani> asymptotically: With the current system?
11:58:58 <yanmaani> Adreik: I'm talking about the current system. You could make a trustless one
12:01:50 <Adreik> If the remote node makes up a valid block that does not have the highest PoW, does the wallet not discard if it sees a higher PoW? I would have thought it would definitely do that
12:03:41 <Adreik> @Yan
12:04:16 <moneromooo> The wallet does not. It is the node's job to follow the correct chain.
12:04:54 <Adreik> Right, so any "monero SPV" should check PoW totals at least
12:04:57 <moneromooo> (IIRC yanmaani wants a mode where the wallet queries multiple nodes and votes)
12:05:07 <Adreik> votes?
12:05:21 <yanmaani> Adreik: It can't right now
12:05:33 <yanmaani> it only asks one, and from what I understand it trusts it to check the PoW
12:05:38 <yanmaani> moneromooo: no voting involved
12:05:47 <yanmaani> simply check highest PoW and assume miners aren't doing 51%
12:06:32 <Adreik> asymptotically actually the problem with SPV, the defining characteristic is that a node can just make up a garbage block because the wallet cannot check that, for example, the funds haven't already been spent (key images)
12:07:11 <Adreik> because it hasn't verified the full blockchain
12:07:33 <asymptotically> Adreik: but the evil node operator would have to spend a lot of energy mining a fake block that they'd get no reward for
12:08:33 <Adreik> If they're scamming a business they know uses an SPV for a lot it's worth it, which is why for any large amount (large being personal) you ought to use a full node
12:08:36 <yanmaani> Sure, but that's only a valid deterrent if it asks more than one remote node
12:10:24 <Adreik> Sybil attacks
12:11:01 <Adreik> SPV is always going to be less safe, but that's ok because people in different situations with different priorities make different decisions
12:11:01 <yanmaani> not really, more like eclipse attacks
12:11:15 <yanmaani> If your threat model is "all the nodes I'm connecting to are bad" then a full node won't help you
12:11:34 <yanmaani> With proper SPV, it will be safe as long as you have at least one honest node.
12:11:41 <Adreik> It will reject their garbage block sending you a commitment of 1,000,000 XMR though
12:11:46 <Adreik> a full node that is
12:12:07 <yanmaani> You can't just say that SPV is less safe and then apply it across the board
12:12:18 <yanmaani> sure but so would SPV, as long as it could query nodes and look for the longest chain
12:13:37 <moneromooo> Hmm. Actually since we can now pay for RPC service, maybe coding such a voting system would not disincentivize running your own node too much...
12:14:18 <yanmaani> the pay for RPC service is bad, I think. There's never any incentive to pay for it, nor to operate a for-profit node.
12:14:23 <Adreik> If it can't find the longest chain, or if a powerful miner is against you the SPV wallet might believe it, whereas the full node will not accept their bullshit. But yeah, SPV wallets might be "less safe" but in a supermajority of situations they are "safe enough"
12:14:36 <moneromooo> That's the point :)
12:14:50 <moneromooo> Well the first one is.
12:15:18 <yanmaani> If nobody will pay for it, how can there be any profit to running one?
12:16:03 <yanmaani> Miners already have an incentive to run validating full nodes, and to run RPC nodes: to get those sweet, juicy transaction fees a few milliseconds before everyone else
12:16:47 <moneromooo> There's no profit if noone pays for it. There is profit if everyone pays for it.
12:16:51 <Adreik> The better thing about hash for RPC is as spam prevention for public nodes. Has there even been a recorded instance of a block mined with RPC hashes?
12:17:06 <moneromooo> So I expect there'll be a push both sides.
12:17:16 <yanmaani> But why pay for it though? You will always have people who are financially incentivized to run free nodes
12:17:19 <yanmaani> (miners)
12:17:44 <moneromooo> Fair point about miners.
12:20:12 <Adreik> Isn't a mining node also incentivised to choose not to broadcast high-fee transactions to the other nodes until they have a block solved with it? So a remote node user should want to connect to many nodes to broadcast their transaction.
12:21:08 <moneromooo> Ugh. Mining nodes may be incentivized to spam lots of invalid txes to other mining nodes.
12:21:49 <Adreik> Or the SPV wallets should connect to other nodes to poll them for their tx pool to check that their remote node has been honest
12:21:55 <yanmaani> moneromooo: why?
12:22:10 <moneromooo> To get them to waste cycles on verification.
12:22:13 <yanmaani> Adreik: that's true, but if one pool is say 100ms earlier that's an edge
12:22:29 <moneromooo> Anyway. I should not waste time on IRC.
12:22:33 <yanmaani> probably cheaper to just rent a trillion gigabits of botnet
12:23:14 <hv-bridge> <xmrig> 356
12:23:37 <yanmaani> xmrig: what?
12:23:55 <hv-bridge> <xmrig> cat + keyboard, sorry
16:30:51 <xmrpow> gineropolous: Concerning our reddit discussion....
16:31:41 <xmrpow> Maybe pos would not do a better job.
16:34:24 <xmrpow> What do you mean by massive barrier to the physical?