00:04:17 <newyearday> what is the meaning here "CURRENT_TRANSACTION_VERSION < version) return false;"
00:11:40 <moneromooo> To reject txes with unsupported format.
00:12:22 <newyearday> so v12 is not supported
00:13:06 <moneromooo> Oh. I thought you had v12 blocks, not txes.
00:13:16 <newyearday> one of the reason that new chain cant start with v12
00:13:49 <newyearday> new chain will have txes too....
00:16:40 <moneromooo> Presumably not v12 txes though ?
00:17:52 <newyearday> is strange because if i pas this line i still have error and gdb says taht cant access txes memory!
00:18:03 <newyearday> so txes are not v12 format
00:22:33 <moneromooo> If you did not change it from monero, currnet txes are v2.
00:23:03 <moneromooo> gdb saying can't access memory is either a bug (ie, stray pointer) or optimized code where gdb can't find the correct pointer value.
00:23:37 <newyearday> where to change v2 txes
00:23:56 <moneromooo> In the tx serialization code (cryptonote_basic.h)
00:25:19 <newyearday>   version = 1;  this one line 185
00:27:08 <newyearday> or size_t   version; to make size_t   version = 12;
00:43:07 <newyearday> which line to change
00:48:04 <newyearday> i change  size_t   version = 12;
00:49:07 <moneromooo> You have no idea what you're doing, are you.
00:50:12 <newyearday> i dont have knowledge of c++
00:50:35 <moneromooo> You said you changed *block* version earlier. Block and txes are independent versioning.
00:50:52 <newyearday> yes
00:51:15 <moneromooo> The size_t version is the tx version.
00:51:26 <moneromooo> Block version is uint8_t major_version;
00:51:31 <moneromooo> (IIRC)
00:51:55 <newyearday> i change it both so is ok
00:51:57 <moneromooo> Unless you originally changed tx version thinking it was block version. In that case changing tx version checks will indeed fix it :)
00:52:18 <moneromooo> Why do you need to change version anyway ?
00:52:36 <newyearday> for chain to start with v12
00:52:39 <moneromooo> If you start your own chain, you can just make the changes you need to the tx structure, and keep hte version as is.
00:52:49 <moneromooo> Ah, yes, nvm.
00:53:14 <newyearday> is not fork is new chain
00:53:27 <newyearday> from block 1
01:04:22 <newyearday> what changes except version i can do to the tx structure
01:07:52 <moneromooo> Well, anything you like in the serialization code (the BEGIN_SERIALIZE chunk).
01:37:52 <Homer> howdy, if someone's running RandomX mining on MacOS could you please shoot me a message - cheers in advance.
03:03:14 <dorenom> Hello, is this a place to ask a support question?
03:06:45 <ndorf> yes
03:08:29 <RowanSkye> testing IRC connection, hello Monero users
04:45:25 <ribbit220> hey can anyone please point me to a guide on how to set up a full node on tails?
04:47:46 <ribbit220> or a local node that is, I have a large enough drive for it.
05:07:08 <ribbit220> anyone around tonight?
10:56:32 <yanmaani> So how come p2pool for Monero isn't a thing? If you'd have multiple chains in parallel, it should work
10:59:09 <yanmaani> Also I've come up with a convoluted way to sort of implement PPS. Each block you mine, instead of having an address to credit you to encoded directly, gives you a coin, and when you get this coin you must specify an address to send the reward to.
10:59:14 <selsta> yanmaani: did you see https://youtu.be/-IE8rkSx__k ?
11:00:04 <yanmaani> But anyone in posession of the coin can change this address. So you could 'sell' your reward for Monero by cross-chain atomic swaps.
11:00:16 <yanmaani> selsta: no, will watch
11:00:20 <yanmaani> what's it about? p2pool?
11:01:14 <selsta> pools in general and also touches p2pool topic
11:11:58 <yanmaani> P2pool starts at 12:20
11:12:19 <yanmaani> recommend watching at 1.25x
11:15:16 <yanmaani> Hmm, so a way you could do it is that miners bid on which transactions to include, and get the fees from them.
11:15:46 <yanmaani> So if I have a set of 1000 transactions, I'll put them to the chain, and say that I'll give this amount of money to whoever mines them
11:15:53 <yanmaani> and in return, I get whatever transaction fees above that
11:19:58 <yanmaani> Or, you just violently sync the transaction pool.
11:20:32 <yanmaani> So, whenever someone gets a transaction, you send it to all your friends. You define your friends based on whoever send you the txn first. Crucially, you don't ask first
11:20:57 <yanmaani> so there's no round-trip delay, where you say "I have TXN X -> Yeah give me it -> OK here", just "Here is TXN X"
11:21:12 <yanmaani> It's O(n^2) but as long as the nodes have gigabit internet it should be fine
11:23:38 <yanmaani> Or, you somehow determine what the txn fees 'should' be, and require for blocks to send that back
11:24:01 <moneromooo> I'd looked at adding minisketch for this, but it'll only be worth it once we get larger txpools.
11:24:51 <yanmaani> It has to be scalable from the onset, I think
11:25:05 <yanmaani> cause otherwise you're betting against your own success
11:36:21 <yanmaani> moneromooo: Minisketch might improve it, but it doesn't solve the txn inclusion problem
11:36:48 <yanmaani> So, if you're in p2pool, and you see a mini-block that also is a valid mainchain block that pays all the previous miners their share, is it valid?
11:36:55 <yanmaani> Yes, as long as it's a valid block and all that.
11:37:22 <yanmaani> But nothing prevents miners from picking transactions themselves, without involving the pool, and collecting fees out of band.
11:38:05 <yanmaani> As long as txn selection isn't on-chain, that can't be helped.
11:38:36 <yanmaani> One solution may be to have the sub-blocks include transactions, so that the mempool is on the chain. That's a very ugly solution, but it might work
11:38:42 <yanmaani> And then the txns can be chosen deterministically
11:40:16 <yanmaani> Because fundamentally, this is the like the transaction censorship problem: just as a miner can censor transactions (bad), they can also steal fees (bad). With a pool, we trust them not to censor transactions and not to steal. Since the latter is easy to prove, we don't often think about it.
11:40:37 <yanmaani> But if we replace 'pool' with 'random people on the Internet', the problem becomes clear.
11:43:36 <moneromooo> What is the txn inclusion problem ?
11:44:40 <yanmaani> It's the one I decribed four minutes ago
11:44:48 <yanmaani> How do you pick what transactions to include?
11:45:04 <yanmaani> How do you make sure the miners in p2pool don't charge fees out of band and only take the block reward?
11:45:32 <asymptotically> like "transaction accelerators" when btc was getting spammed?
11:45:51 <yanmaani> asymptotically: Would those have required fees out of band?
11:45:54 <yanmaani> If so, yes, those
11:46:47 <moneromooo> You pick transactions are you see fit. The fees you add are whatever the txes pay. They only take the block reward because the block would be rejected otherwise. Other p2pool miners will likely also check consensus to avoid being DoSed.
11:47:35 <moneromooo> They also check their own address is paid what they should before mining on a block they got.
11:48:09 <yanmaani> Right, but this isn't incentive compatible
11:48:35 <yanmaani> I'm a miner. I can either charge standard fees, and get maybe 1% of them or whatever the share ratio is (e.g. 100 shares per block)
11:48:54 <yanmaani> Or I can charge zero fees, share 1% of zero, and take transactions out of band, and I won't have to share them.
11:49:15 <yanmaani> I'm no longer incentivized to include the transactions with the highest fee in the block.
11:49:49 <moneromooo> Because you only get 1% of them (if you have 1% of the p2pool miners' overall hash rate)?
11:49:52 <yanmaani> Thus, it can't be up to miners which transactions to include. This has to be a consensus rule, so that it's deterministic given the blockchain at height H which transactions to include.
11:49:57 <yanmaani> moneromooo: correct.
11:50:11 <moneromooo> You also get 1% of the coinbase award.
11:50:21 <yanmaani> whereas for standard miners, it's indifferent whether the fees are direct (in block) or indirect (out of band)
11:50:32 <yanmaani> Sure, but the transaction fee auction completely breaks down
11:51:09 <moneromooo> By "indirect", do you mean a p2pool miner will also mine other blocks with juicy txes on the side ?
11:51:31 <yanmaani> A rational p2pool miner will mine p2pool blocks, but get their transactions out of band, and charge zero fees on chain.
11:51:34 <moneromooo> Oh I think I see what you mean.
11:51:49 <yanmaani> In fact, this would even be parasitic. They only have 1% exposure to the block reward, right?
11:52:09 <yanmaani> So what's to prevent them from adding in 0-fee transactions that cost them 1% of the penalty, but they get paid say 50% of the rational fee?
11:52:17 <moneromooo> That's a problem that also exists for non p2poo, isn't it ?
11:52:27 <yanmaani> Sure, but there the pool is trusted.
11:52:38 <yanmaani> Here it's just "random clowns on the Internet"
11:52:55 <yanmaani> the pool won't transparently screw over their miners
11:52:57 <moneromooo> I do not understand hte difference.
11:52:58 <Quotes> But it's easy! https://www.youtube.com/watch?v=RXJKdh1KZ0w
11:53:00 <yanmaani> So, as I see it, there's two solutions
11:53:13 <yanmaani> 1) make txn selection a part of consensus
11:53:25 <yanmaani> e.g. keep the mempool on the chain
11:54:01 <yanmaani> 2) make txn selection decided by the highest bidder
11:54:36 <yanmaani> e.g. I pay 1 XMR for the privilege to select ALL the transactions in the block, I get ALL of the txn fees, and it's entirely opaque to the miners
11:54:53 <yanmaani> moneromooo: So, if you're a pool, the situation is kind of the same
11:55:50 <yanmaani> You only get 1% of the reward, but if you take fees out of band, those won't be distributede
11:56:29 <yanmaani> e.g. if you mine 2 XMR reward + 1 XMR fees, then miners will come knocking for their share of 3 XMR, but if you only have a reward of 2 XMR, then they'll just want their share of 2 XMR
11:56:43 <yanmaani> But! If a pool consistently has suspiciously low txn fees, then miners will just use another one.
11:57:50 <asymptotically> i think you overestimate how much miners care (there are still people using minergate...)
11:58:06 <asymptotically> also with the lack of adoption with things like stratum self select
11:58:10 <yanmaani> Here's a practical example in how pools might screw miners over in this way: some pools do merged mining with Namecoin; the pool might just take that money and not give anything back
11:58:33 <yanmaani> But! I have missed an important point which undermines my entire argument! Miners only stand to gain from this if they actually mine the winning block
11:58:38 <moneromooo> Well, as long as it doesn't pretend otherwise.
11:58:48 <yanmaani> So it's equivalent to solo mining, in a way
11:58:52 <yanmaani> And it's trivial to fix
11:59:15 <yanmaani> Instead of having payouts be determined like (submitted_shares/total_shares)*block_reward
11:59:35 <yanmaani> determine them like (mined_notional/total_notional)*block_reward
11:59:53 <yanmaani> This would mean that miners would again have no incentive to take the zero fee txns
12:00:07 <yanmaani> since in expectation, it reduces their rewards by as much as if they'd have done it solo mining
12:00:19 <yanmaani> (which is to say, ±0)
12:01:28 <yanmaani> in other words, this was an idiotic objection and isn't actually a problem
12:02:48 <moneromooo> So, p2pool miner Bob has low hash rate. If Alice sends a tx with that system (pay tiny fee in the tx, but separate extra payment to Bob), Bob has to mine it for it work. The tx can't be relayed to other p2pool miners. So it'll take quite a while to be mined.
12:03:16 <moneromooo> Like, months, mossibly.
12:03:51 <yanmaani> moneromooo: That depends on Bob's hash rate. If he has 1% of the hash rate, and there's a block every 10 minutes, then in expectation that should be 1000 minutes or 16.7 hours
12:04:16 <yanmaani> Also, Alice could do this with multiple miners.
12:04:35 <yanmaani> If P2Pool has 100 miners, she could tell each one that she'll pay them the txn fee out of band.
12:50:22 <duso> I just heard about this HTC Exodus 1S monero mining phone.
12:50:53 <duso> What do people think of this? More nodes on a network just secures the network more. Seems a gimmick  though
15:11:21 <johnnycash> latest dload Monero CLI OS X daemon won't connect
15:11:24 <johnnycash> W Failed to connect to any of seed peers, continuing without seeds
15:11:36 <johnnycash> I 0Connect failed to [ip]
15:11:54 <johnnycash> I Failed to connect to any, trying seeds
15:13:15 <dEBRUYNE> Is this the first time you are using Monero?
15:13:35 <johnnycash> on current device, yes
15:14:05 <dEBRUYNE> Which version of the CLI, 0.15.0.5?
15:14:22 <johnnycash> Monero 'Carbon Chamaeleon' (v0.15.0.5-release)
15:14:24 <johnnycash> yup
15:16:00 <moneromooo> You temporarily need to tell it to connect to a peer, as all the seeds it knows about are down:
15:16:42 <johnnycash> how would I go about doing that
15:16:48 <moneromooo> --add-peer 88.198.163.90:18080
15:17:16 <moneromooo> This should be a one off thing. Once it's found the network, it'll build its own peer list and won't need that option again.
15:18:08 <moneromooo> There'll soon be more seeds around.
15:18:58 <johnnycash> how would I enter that command? (sorry)
15:19:59 <moneromooo> Add this at the end of your usual monerod command line.
15:20:11 <moneromooo> eg, ./monerod --add-peer 88.198.163.90:18080
15:20:24 <johnnycash> thank you!
15:21:06 <selsta> moneromooo: you sure that all seed nodes are down?
15:21:10 <moneromooo> No.
15:21:18 <selsta> at least 3 are up
15:21:27 <selsta> according to https://community.xmr.to/xmr-seed-nodes
15:21:41 <moneromooo> Among the ones already in 0.15.0.5 ?
15:21:47 <selsta> yep
15:22:08 <moneromooo> Odd. Could be shitty network then.
15:23:12 <moneromooo> johnnycash: could try running again without --add-peer, but with --log-level 2 until it connects, then paste the log to some pastebin ?
15:23:29 <moneromooo> That might give us some clues.
15:25:16 <binaryFate> 88.198.163.90 is in the list of seeds already so adding it on command line should not make any difference no? networking issue probably
15:25:50 <selsta> 88.198.163.90 is only in master
15:26:01 <selsta> but still think it is some network issue as the others should be good too
16:02:10 <johnnycash> https://uploads.kiwiirc.com/files/eb51f30babc921a57a3ed09aa6c1a453/pasted.txt
16:05:20 <sweeper_mate> I'm trying to read "Zero to Monero". On page 25, it says that EdDSA verification goes like:
16:05:31 <sweeper_mate> sent too soon, my mistake
16:09:31 <selsta> johnnycash: does it work with --add-peer?
16:09:46 <selsta> are you using mobile internet / some kind of VPN?
16:11:11 <sweeper_mate> I'm trying to read "Zero to Monero". On page 25, it says that EdDSA verification goes like:
16:11:12 <sweeper_mate> isn't 0)
16:11:59 <moneromooo> UkoeHB_: ^
16:33:34 <yanmaani> I remember vaguely we once discussed using DHT to bootstrap Monero
16:34:27 <yanmaani> so, you take the BitTorrent DHT port, and you generate random IPs. You then send out say 10k handshakes, and checks who responds.
16:34:52 <yanmaani> And then from that, you can build nodes in the BitTorrent DHT network, and from that you can find Monero nodes
16:34:56 <yanmaani> Was there any flaw with this?
16:34:59 <selsta> Still think it is over engineered.
16:37:36 <UkoeHB_> sweeper_mate: what's your question? Also the second edition is available https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
16:40:42 <yanmaani> well it's not too complex
16:40:45 <yanmaani> although it's a bit goofy
16:41:16 <yanmaani> but generally, sending out a bunch of udp packets, listening on a port, and then handing the IPs over to a library isn't tremendously hard
16:57:32 <JtH> Is there any more particular place where discussion about codesign'ing the monero*.app for macOS would be preferred ?
16:57:55 <JtH> curious if its in the plans to codesign the releases 
16:58:28 <JtH> currently I do this myself after verifying the integrity of the binaries.
17:00:53 <selsta> JtH: you codesign the .app ?
17:02:13 <selsta> I would like to at least notarize the mac monero GUI
17:02:26 <selsta> but I didn’t fully figure out how to do this yet
17:05:27 <selsta> re discussion: https://github.com/monero-project/monero-gui issue tracker
17:06:09 <JtH> yes I do. its pretty simple. let me grab the link I originally followed a couple years ago. Essentially you grab your cert from xcode, Add it to the system trust then you can "codesign -vfs 'U69YFA4G66' *.app"
17:06:37 <selsta> so we would need a monero apple id?
17:06:44 <JtH> e.g. U69YFA4G6 is my dev cert issued by apple
17:06:50 <JtH> correct
17:06:55 <selsta> ok, I think fluffy has one
17:07:20 <selsta> can you post the exact command? and is there a difference between code sign and notarize?
17:07:27 <JtH> I know the personal ones are free and issued by apple
17:07:41 <JtH> unsure about "Group Keys"
17:08:52 <JtH> yes. codesign'ing is essentially locking it down with the syst4m so the policies can/ or won't allow it to communicate or run depending
17:09:03 <JtH> but yes looking for the link now
17:10:18 <bb_runion> hello, i am unable to run monero-client-cli on my debian anymore
17:11:20 <bb_runion> monero-wallet-cli
17:11:22 <selsta> bb_runion: can you try https://github.com/monero-project/monero/releases/tag/v0.15.0.1 ?
17:12:20 <bb_runion> i'll try it
17:13:40 <JtH> selsta, essentially its this in reply #2 https://stackoverflow.com/questions/52699661/macos-mojave-how-to-achieve-codesign-to-enable-debugging-gdb
17:14:19 <JtH> except instead of generating your own x509 you'll export your certificate directly from the XCode.app
17:14:31 <selsta> nice, seems to work
17:14:57 <selsta> how can I check if I signed it correctly?
17:15:06 <JtH> under Settings >>> Account >>> Manage Certificates >> Right Click on the cert you want and export
17:15:26 <JtH> (codesign -vvv ${OBJECT} )
17:15:59 <JtH> https://stackoverflow.com/questions/52699661/macos-mojave-how-to-achieve-codesign-to-enable-debugging-gdb
17:16:01 <selsta> okay, one more question, I signed it with my private apple id
17:16:13 <selsta> if I share the file can others see my apple id?
17:16:25 <JtH> codesign -dvvv gives more information
17:16:31 <JtH> thats correct
17:18:33 <selsta> okay, and if others download the gui
17:18:44 <JtH> it'd help me out quite considerably having the gui signed. Policies for some of the macOS env are restritive and won't allow it to open.
17:19:09 <selsta> does it still say unrecognised developer?
17:19:17 <selsta> or is code signing the same as notarization
17:19:21 <JtH> yes whatever your app was signed with will remain with it
17:19:54 <JtH> assuming notary is the same as mac's CSC then yes.
17:20:16 <selsta> https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
17:20:24 <selsta> looks like notarization requires code signing first
17:20:30 <selsta> but I’m one step closer with this, thanks :D
17:20:36 <scanned> anyone using xmrig-proxy?
17:21:08 <JtH> your' welcome!
17:21:09 <bb_runion> selsta, not such file or directory, when i try to run binary. Wrong architectore maybe (linux 32 bit)
17:21:35 <JtH> selsta, im guessing here but, assuming you are involved with releases ;)
17:21:39 <scanned> is it possible to use: xmrig-proxy --> xmrig-proxy -->pool
17:21:53 <moneromooo> scanned: try #monero-pools
17:21:58 <scanned> okay thanks
17:22:23 <selsta> JtH: I’m a bit involved with releases
17:22:48 <JtH> k googd that makes me feel better that we'll see it signed at some point ;)
17:23:12 <JtH> and thanks for taking all that up
17:24:05 <selsta> yep, will have to ask fluffy for the monero apple id and then I can experiment more :)
17:24:48 <JtH> funny how when ya first start looking into codesign'ing stuff that its all so elusive
17:25:37 <selsta> the problem is we don’t use xcode which means even less good documentation
17:26:25 <JtH> yep that's esesentially where I was at about 3 years ago.
17:27:10 <JtH> until apple started enorcing it for built in applications or policies that enforced only identified developers
17:27:23 <JtH> had to learn real quick like
17:28:37 <JtH> workflows with our devs changed drasticly
17:28:59 <selsta> problem is also we can’t really sign CLI release because it does not play well together with reproducible builds
17:29:07 <selsta> but GUI is not reproducible yet so we can sign it
17:31:09 <JtH> while it'd be nice for the CLI its not neccesarily called for since it doesn't directly interact with the desktop. In this instance its easy to just permit the cli app to allow netwmork connectivity etc..
17:32:53 <JtH> alot of times people are using Term.app or iTerm2.app in which they already permitted certain access and then everything run within just follows
17:44:50 <netrik182[m]> i'm not sure who manages https://repo.getmonero.org but I'm unable to get a confirmation email from it
17:44:55 <netrik182[m]> I get to this page but the email never arrives https://repo.getmonero.org/users/almost_there
17:46:14 <JtH> netrik182[m], ? no script blocker or similiar ? ... all browsers used ? etc etc. .. ?
17:47:10 <netrik182[m]> let me check
17:47:44 <yanmaani> moneromooo: A problem with this p2pool idea is that it's also very vulnerable
17:48:11 <JtH> sometimes just activating private mode will solve that to. Given this is github it would lean me to believe this is a client side problem.
17:48:23 <yanmaani> if you pay out based on notional amount, then miners can make transactions with obscenely large fees, and only include them in their own blocks
17:49:11 <moneromooo> netrik182[m]: I see a login from an account that matches your name.
17:49:57 <netrik182[m]> i'm logged in, yes. It's that I changed my email
17:51:28 <bb_runion> selsta,  v0.15.0.1 works, i will now try to make transfer, thank you.
17:51:54 <selsta> bb_runion: okay, the next release should work again
17:52:06 <selsta> just skip v0.15.0.5
17:52:32 <netrik182[m]> JtH moneromooo I just tested with a fresh FF profile w/o addons or custom settings
17:54:05 <moneromooo> I found logs about this, and AFAICT the email was delivered. Maybe stuck in a spool file somewhere on the way.
17:54:42 <moneromooo> yanmaani: and this opens what kind of vulnerability ?
17:55:22 <yanmaani> Well, miners can do parasitic mining: they submit shares, but if they happen to solve a block they don't get anything.
17:55:32 <netrik182[m]> moneromooo: thanks for checking. I'll wait some more days idk and get back here if needed
17:55:34 <yanmaani> That said, they have to expose their transaction with obscene fees to the network
17:55:39 <yanmaani> to collect the fees
17:55:45 <yanmaani> so it maybe is not such a great deal
17:56:14 <moneromooo> Feel free to write those things up precisely if you want them remembered. A github issue even maybe.
17:56:26 <yanmaani> although if they're fast, they could perhaps do some sort of race condition
17:56:54 <yanmaani> Well, the idea is that I discuss it with people on IRC, precisely so that if they do happen to be stupid, I don't have to remember them :)
17:57:06 <yanmaani> (and if they are, I'll just go through the logs and rewrite them from there)
17:57:16 <moneromooo> Sure, that works.
17:58:31 <yanmaani> So, the attack I see is, if they have a winning block, they can create a transaction that relies on the winning block not existing (e.g. put a txn in the mempool which, if committed, would make it invalid)
17:58:41 <yanmaani> and that spends say 100 XBT in fees
17:59:21 <yanmaani> so, whenever they have found the winning block that spends some output they control, they create a transaction that spends the 100 XBT in fees, and solve a share for it
17:59:40 <yanmaani> so if they have 1% of hashrate, they get 1% of the 100 XBT in fees
18:00:11 <yanmaani> they then instantly send the block, causing the 100 XBT in fees to get invalidated
18:00:23 <yanmaani> Unless the miners are going to start 51% attacking of course
18:01:00 <JtH> seems a pretty minimal impact
18:01:13 <JtH> e.g. hard to achieve
18:01:16 <yanmaani> Well it's 1 XBT that they've managed to steal
18:01:29 <yanmaani> You'd need to do tricky race condition stuff to trigger it, sure
18:02:10 <yanmaani> but the general cost is not bad. You'll get paid for all your mining still, and you can submit the useless shares to p2pool to get paid for them
18:10:14 <JtH> yeah not that any should be lost period but on a large scale it could grow. the race condition though ... the type of race condition would be pretty hard to achieve.
18:12:22 <JtH> got a PoC ?
18:12:49 <yanmaani> no, I don't have a mining facility
18:13:47 <yanmaani> you'd need to create a bunch of outputs, and then start mining a block which spends one of them in secret. Any shares which aren't solutions, you put to the pool.
18:13:56 <yanmaani> So far, you're just a normal miner, getting paid normal money for normal work
18:14:50 <yanmaani> At one point, you'll find a block. You avoid broadcasting this, and instead start mining on the fee block. That fee spends the transaction with the obscene fee.
18:14:57 <yanmaani> that block*
18:15:03 <yanmaani> If you actually find a full block, you discard it
18:15:16 <JtH> hmm
18:15:18 <yanmaani> But the shares, you gather and submit
18:15:47 <yanmaani> The ideal thing ought to be to mine until you have two shares, and then submit them at once, immediately followed by the block
18:16:49 <yanmaani> So you'll get the fees for 2 shares' worth of XBT 110 notional reward, while being ~100% certain that this reward can't ever be collected
18:17:38 <yanmaani> The crucial bit is this: As long as you don't find a block, you don't take any risks. The attack only begins after you've found a complete block.
21:13:41 <synaps3> what do you get by running monero node ?
21:16:02 <selsta> increased privacy for yourself
21:17:18 <tryphe> you get to own monero
21:21:46 <jwinterm> synaps3, if you don't run your own node then you are trusting someone else to verify all tx history and proof of work for you
21:21:55 <jwinterm> which is most likely fine
21:22:09 <jwinterm> you also lose some privacy using a remote node also when sending txs
21:23:01 <moneromooo> In the same way than not being in jail means you don't rely on someone else to feed you. Which is most likely fine.
21:26:12 <yanmaani> what, thin nodes don't verify PoW??
21:28:46 <moneromooo> Nodes verify PoW. They're on about wallets.
21:29:25 <moneromooo> Well, nodes verify PoW, but have a default fast mode where they rely on builtin hashes.
21:35:43 <yanmaani> Well, you can run the monero-gui wallet with a remote node
21:35:49 <yanmaani> Surely that verifies PoW?
21:36:35 <moneromooo> The wallet ? No.
21:36:46 <moneromooo> The *daemon* verifies the PoW.
21:37:02 <yanmaani> Even if the daemon connects to a remote node?
21:37:07 <moneromooo> If it's your daemon you connected to, you just shot yourself in the face.
21:37:10 <moneromooo> Yes.
21:37:24 <moneromooo> You are not supposed to connect to a stranger's yucky node.
21:37:36 <moneromooo> Why not run your wallet on Amazon too.
21:37:50 <moneromooo> Or use a VPN owned by facebook.
21:37:56 <yanmaani> Because I don't have sufficient space to store the chain
21:38:01 <moneromooo> That is your problem.
21:38:12 <yanmaani> This is absurd - Electrum doesn't require you to store the chain
21:38:15 <yanmaani> and does not have these problems
21:38:16 <moneromooo> Then use that.
21:38:22 <yanmaani> how come Monero wallet can't verify PoW?
21:38:26 <yanmaani> Is it harder somehow?
21:38:29 <moneromooo> It can. RUN THE FUCKING NODEl
21:39:00 <yanmaani> Yeah but a thin wallet. Why are you so opposed to thin wallets? There's no other serious way to run Monero on mobile devices
21:39:36 <jwinterm> you could connect to your own node on mobile
21:40:02 <jwinterm> or connect to several remote nodes that you don't control and verify chains are the same
21:40:14 <jwinterm> or that the one you connect to matches with several explorers or mining pools
21:40:27 <yanmaani> jwinterm: The second suggestion is very sensible
21:40:31 <jwinterm> or just say fuck it and trust any random remote node like I do
21:40:33 <jwinterm> :P
21:40:44 <yanmaani> You connect to N different nodes, ask them for the hash at height H, and make sure they're the same
21:40:47 <jwinterm> not like I am holding much xmr on my phone anyway
21:40:49 <yanmaani> You know what this sounds like?
21:41:18 <yanmaani> A job that a computer should do! Querying servers from a list, getting back some data, and running strcmp()! It's the epitome of computer-friendly human-unfriendly business
21:41:42 <yanmaani> But seriously now, is there any technical reason for why the daemon can't verify PoW if you use a remote node?
21:41:59 <jwinterm> the daemon is the node
21:42:12 <jwinterm> the wallet connects to a single daemon that is uses as a remote node
21:42:23 <yanmaani> I mean if you use a random remote node on the internet
21:43:03 <jwinterm> I think maybe one or two of the mobile wallets do verify that any remote node they list is in agreement with the others
21:43:08 <jwinterm> not sure tho
21:43:39 <yanmaani> In the desktop wallet, unless I've misunderstood, you can only even use one wallet
21:43:53 <selsta> There is basically no reason to not run your own node. With pruning it only requires 27GB space and it can even run it on a raspberry.
21:45:25 <jwinterm> no I think you've misunderstood
21:45:36 <tryphe> yanmaani, you don't know what the other nodes are verifying unless it's your node, so you can't trust it
21:45:41 <yanmaani> only ever use one node*
21:45:58 <yanmaani> selsta: I don't have 27gb of space, I use a bargain-bin laptop
21:46:12 <jwinterm> well, you're supposed to use your node
21:46:22 <yanmaani> tryphe: I can verify the PoW for myself.
21:46:23 <jwinterm> I don't know how remote nodes are populated to choose from there
21:46:44 <yanmaani> jwinterm: Right, but this is the case in Bitcoin as well. It's still possible to use Electrum, and it's not like people lose all their money doing so.
21:46:51 <selsta> There is not Electrum like system with Monero yet.
21:47:00 <yanmaani> selsta: Is it possible?
21:47:36 <selsta> I don’t know.
21:47:52 <tryphe> they didn't lose all their money, just a bunch
21:47:53 <yanmaani> is there any technological obstacle?
21:48:47 <jwinterm> yea there have been some electrum mishaps for sure
21:49:32 <selsta> yanmaani: see e.g. https://github.com/monero-project/research-lab/issues/69
21:49:37 <yanmaani> tryphe: has there ever in the history of mankind been a single person who has lost money from using Electrum?
21:50:16 <tryphe> yanmaani, a ton more than monero-wallet-cli or bitcoin-cli
21:50:31 <synaps3> how can i help with hosting .onion service
21:51:05 <yanmaani> tryphe, jwinterm: Can you name one
21:51:20 <tryphe> yanmaani, i don't really know of any bugs where the monero or bitcoin wallets caused people to lose money, they just did silly things to lose it. otoh, electrum is historically full of silly bugs allowing coin theft
21:51:33 <tryphe> although, maybe from user stupidity as well, but easier to fall for
21:51:35 <jwinterm> https://cointelegraph.com/news/phishing-attack-on-electrum-wallet-nets-hacker-almost-1-million-in-hours-report
21:52:03 <jwinterm> yea, it was more from the software allowing malicious nodes to push a software update
21:52:15 <jwinterm> but it was electrum and people lost a lot of money
21:52:36 <yanmaani> selsta: right, so what's what I was looking for
21:52:44 <yanmaani> tryphe: Can you name one case?
21:53:03 <tryphe> yanmaani, sure, arbitrary popups with rich text
21:53:05 <yanmaani> synaps3: What, just hosting in general? Install tor and edit /etc/tor/torrc
21:53:16 <yanmaani> That's not due to it being a thin client though
21:53:25 <tryphe> no, it's due to being shit software
21:53:30 <tryphe> and nobody should use it
21:53:37 <synaps3> https://web.getmonero.org/resources/roadmap/ i saw that onion service is in plan, so im interested in how to help
21:53:43 <tryphe> use windows 95 if you want, i won't stop you
21:53:51 <yanmaani> Well, it's written in Python, but I do submit it looks far nicer than Bitcoin Core.
21:54:07 <selsta> tryphe: you can ask in #monero-site but I think no help is required
21:54:46 <yanmaani> I don't get why you don't just pay the $3k arbitration fee to get monero.org
21:55:13 <tryphe> yanmaani, looks can be deceiving :)
21:55:38 <yanmaani> But the architecture is sound?
21:55:53 <yanmaani> Cause I've heard a lot about SPV being dangerous, but in practice it seems to be entirely flawless
21:56:56 <yanmaani> Hmm, so back in 2015 Monero owned d/monero
21:57:06 <yanmaani> monero.bit, I mean
21:57:09 <yanmaani> the Namecoin domai
21:57:10 <yanmaani> n
21:57:22 <yanmaani> but since then it's changed hands several times