01:09:49 <cannon-c[m]> is monero reproducible build?
01:10:07 <cannon-c[m]> I heard rumors the cli was (cli > gui anyways) but cannot confirm
01:10:32 <cannon-c[m]> and does cli monero wallet work with hardware wallets? asking for a friend
01:11:59 <rottensox_> cannon-c[m]: https://wiki.trezor.io/Monero_(XMR)
01:12:29 <nioc> cli has reproducible builds, the gui does not but that is being worked on
01:12:32 <cannon-c[m]> cool cool,
01:13:25 <cannon-c[m]> so I can use the cli without having to compile massive amounts of dependencies, while still trusting the cli? where can I have info on the cli reproducible ?
01:14:01 <cannon-c[m]> as in using the pre-compiled cli, with trusting that it was from the source code and not anything else
01:18:26 <cannon-c[m]> since the open source only matters if compile yourself, or can confirm it actually came from the source code. The issue with having to compile, is the massive amounts of dependencies and compiling each dependency. with each dependency in turn having more dependencies. manually compiling dependency tree is almost a week long project when work for a living
01:18:27 <cannon-c[m]> reproducible build is the unicorn of open source software
01:24:44 <as2333> moar bloatware!
01:28:06 <selsta> cannon-c[m]: see https://github.com/monero-project/gitian.sigs
01:28:29 <selsta> the signatures from community members
01:28:39 <selsta> you can download the CLI and compare the hashes
01:30:49 <ndorf> cannon-c[m]: if you do ever feel like doing the reproducible build yourself, you don't need to worry about dependencies as the gitian scripts take care of everything for you. you just need time and cpu.
01:31:22 <cannon-c[m]> gitian script support cross compilling?
01:31:25 <ndorf> yes.
01:31:40 <ndorf> it will build all the supported platforms automatically.
01:31:47 <cannon-c[m]> nice
01:31:55 <cannon-c[m]> just. beautiful.
01:32:05 <ndorf> everything is done in containers, the only thing you need to install is docker (i think there is support for lxc as well, but not sure)
01:32:31 <ndorf> the dependencies aren't going to clutter up your main system, though
01:33:50 <cannon-c[m]> because uses docker right?
01:34:00 <ndorf> yep
01:34:12 <ndorf> .io has been around for a while
01:34:14 <ndorf> oops
01:34:27 <cannon-c[m]> .io?
01:34:38 <ndorf> wrong channel, sorry. i suck at irc
01:53:39 <cannon-c[m]> one more question for now
01:53:43 <cannon-c[m]> two
01:53:52 <cannon-c[m]> 1. any privacy/security issues with using remote nodes?
01:54:17 <cannon-c[m]> 2. Monero support pruning? Like if I want to have a monero client on my computer but dont want to take up 70 GB or whatever
01:54:59 <ndorf> Monero does support pruning. I'm not sure how much the space savings are as I don't use it myself, but it's significantly less than the full 70GB
01:55:06 <moneromooo> ~25 GB.
01:55:19 <cannon-c[m]> thanks
01:55:24 <cannon-c[m]> any thoughts on question 1?
01:55:25 <moneromooo> For remote nodes: use SSL. Make sure you run it.
01:55:58 <cannon-c[m]> so pruned node is way to go over remote node ran by someone else?
01:56:04 <ndorf> that's definitely a good idea
01:56:09 <cannon-c[m]> how long for sync over tor?
01:56:12 <cannon-c[m]> average
01:56:14 <ndorf> i would prefer a pruned local node, personally
01:56:26 <cannon-c[m]> I might run full node eventually
01:56:32 <cannon-c[m]> im thinking for my laptop though
01:56:33 <ndorf> remote node automatically sees your IP address, and your submitted transactions, for one thing
01:57:02 <cannon-c[m]> <ndorf "remote node automatically sees y"> even if I use tor? can see that multiple transactions are linked together?
01:57:14 <ndorf> er, no, not if you use tor of course
01:58:14 <cannon-c[m]> I'll use pruned then, any idea how long for download and sync assuming I use a Tor router?
01:58:23 <cannon-c[m]> everything is transparently routed through tor
01:59:22 <ndorf> not sure about that, but i'd guess a long time.
01:59:30 <ndorf> few days maybe?
02:00:12 <cannon-c[m]> I just do not want to broadcast that I am a monero user to my isp
02:00:13 <cannon-c[m]> live in a police state
02:00:31 <cannon-c[m]> yes I'm sure I'm a known tor and i2p user
02:00:37 <cannon-c[m]> but at least that does not reveal anything else
02:01:14 <ndorf> sorry to hear that. i'm not really an expert with the tor stuff, so i really want to avoid giving you any bad advice
02:01:34 <ndorf> there is some built-in tor support in monero, but i *think* it only handles tx submission, not syncing blocks
02:02:10 <cannon-c[m]> sinking blocks?
02:02:42 <ndorf> downloading the blockchain, and then new blocks as they become available
02:02:59 <cannon-c[m]> yes, I just need to find way to do that over tor
02:03:16 <cannon-c[m]> I have strong ip tables that block any non tor traffic
02:05:14 <ndorf> i'm not confident i could give you completely correct advice on this topic, if you are seriously concerned about government surveillance you should wait for someone more knowledgeable in this area to show up.
02:05:52 <cannon-c[m]> or just see if it works
02:06:05 <cannon-c[m]> worst case scenario if non-tor will just be blocked at iptables level
02:06:07 <ndorf> my uninformed guess is that if you have a system-wide tor proxy/filter set up, it should just work
02:06:10 <ndorf> but
02:06:19 <ndorf> for sending txs, i'd advise you to look into the special support monero has for it
02:06:32 <ndorf> esp. if you're concerned about linkability of transactions
02:06:43 <ndorf> you'd want to be careful not to submit them using the same tor circuit, i'd imagine
02:06:54 <moneromooo> If your government really wants to know at the ISP level, then they probably could tell you run a monero node by traffic analysis, even via tor.
02:07:11 <ndorf> ^ that
02:07:11 <moneromooo> (ie, see you get traffic when a monero block is found).
02:07:30 <ndorf> however, that seems to be a much higher bar than "alert us when any port 18080 traffic is seen"
02:07:40 <moneromooo> Right.
02:08:22 <moneromooo> If you can run your node on a VPS somewhere your government/ISP does not see, then use that node from your laptop, it seems safer from that point of view.
02:08:46 <moneromooo> You'd likely need to disable the auto refresh in simplewallet too.
02:09:02 <ndorf> yeah but trusting a VPS node has its own problems doesn't it?
02:09:08 <cannon-c[m]> "monero node by traffic analysis, even via tor."
02:09:12 <ndorf> it might as well be a remote node owned by the VPS provider
02:09:13 <cannon-c[m]> how?
02:09:28 <moneromooo> And if you want to really screw with this, transfer some random amount of other data to/from your VPS when you start simplewallet.
02:09:32 <cannon-c[m]> or maybe just leech off library wifi for few days to download blocks
02:09:53 <ndorf> actually worse if the provider has your real name
02:09:55 <cannon-c[m]> plant a blackbox in ceiling tile or something
02:10:00 <cannon-c[m]> pick up few days later
02:10:10 <moneromooo> How ? By looking for packets. Tor sends TCP packets to other nodes. Those are timed and sizes mostly the same as the real packets.
02:11:25 <moneromooo> So if you get traffic timing that correlates with txes/blocks on the monero network, the probability you run monero goes up as time goes.
02:11:58 <cannon-c[m]> yeah need to mix tor with other traffic of course
02:12:42 <cannon-c[m]> block compression would be nice also
02:12:50 <cannon-c[m]> for transmitting
02:13:00 <moneromooo> monerod does have support traffic but for txes only (to hide whn you send one of yours).
02:13:11 <moneromooo> Transactions won't compress well.
02:36:17 <as2333> cannon-c[m], do a search for tor and "website fingerprinting"
02:44:40 <cannon-c[m]> so how can I make download of new blocks over outbound anon network only?
02:45:11 <cannon-c[m]> "Only handshakes, peer timed syncs and transaction broadcast messages are supported over anonymity networks."
02:45:13 <cannon-c[m]> https://github.com/monero-project/monero/blob/411f1b0ee30f1d424621eb856841dc82d2f161c2/ANONYMITY_NETWORKS.md
02:47:20 <moneromooo> Your tor rules ?
02:47:52 <moneromooo> This mode is for people who just run a tor router. If you have a set of iptables rules that proxy all traffic, that'll go there.
02:48:29 <moneromooo> ie, like Qubes does. If you live in a police state, you night want that.
02:48:42 <cannon-c[m]> hmmm, maybe I can add ip tables for tor traffic redirect, i.e. all traffic from this user route to Tor socks5
02:50:30 <cannon-c[m]> but would be really nice to have tor support for all connections natively
02:50:41 <cannon-c[m]> instead of having to rely on iptable hacks
03:25:30 <cannon-c[m]> ok Kivori is exciting
03:26:42 <cannon-c[m]> Kovri
04:55:01 <cannon-c[m]> monero wallet does not seem to let pass be entered on Trezor T screen?
04:55:46 <cannon-c[m]> and monero cli wallet requires local copy of blockchain (either full or pruned) right?
05:02:06 <cannon-c[m]> and wow sync over tor is fast
05:05:34 <nioc> yes wallet need to connect to a node in order to get the blockchain info
05:05:46 <nioc> they are separate in monero
05:06:11 <cannon-c[m]> but cli wallet requires local node right?
05:06:30 <cannon-c[m]> and is there a way to have the wallet use trezor screen for password or no?
05:06:34 <nioc> AIUI it can be a remote node
05:06:47 <nioc> I don't know about trezor
05:07:29 <nioc> I use my own local node so am unfamiliar with how to use a remote node with the CLI
05:08:38 <nioc> syncing the blockchain is fast to begin with and will slow down later
05:09:10 <cannon-c[m]> yeah even over tor its fast right now
05:09:15 <nioc> txs changed several times throughout it's history so this is part of it
05:09:23 <nioc> also there are checkpoints
05:09:31 <cannon-c[m]> checkpoints?
05:10:17 <nioc> they are added at each hardfork and among other things make it easier to sync
05:12:15 <cannon-c[m]> I just wish could use the trezor screen for password entry
05:12:28 <nioc> not familiar with syncing over tor but if you have a HDD that will be the bottleneck
05:12:38 <cannon-c[m]> i know lots of questions, im a xmr noob
05:12:41 <nioc> a SSD is much much faster
05:12:50 <cannon-c[m]> yes using ssd
05:12:56 <nioc> that's how we all start :)
05:13:03 <cannon-c[m]> and in a VM behind tor router
05:13:45 <cannon-c[m]> definately pruning though since its my laptop
05:14:20 <nioc> did you set it to prune before starting to sync?
05:14:29 <cannon-c[m]> not at first
05:14:42 <cannon-c[m]> then I cancelled ctrl+c and restarted the monerod with prune flag set
05:15:10 <cannon-c[m]> --prune-blockchain
05:15:17 <cannon-c[m]> will see what happens
05:15:54 <nioc> someone is usually here to help but not many people are on at this time
05:16:07 <cannon-c[m]> yeah it is early
07:45:36 <nonie> @( * O * )@
08:00:28 <Inge-> Monero wallets should have a "Why don't I see my funds?" info for users.
08:05:58 <midipoet> Inge-: did you lose your XMR again?
08:09:11 <Inge-> what XMR?
08:09:35 <Inge-> I'm more thinking about UX - since this is like half of all monero support
08:09:59 <Inge-> "they say they sent me the monero, but I don't see it"   "I revocered my wallet, but it is empty"
08:11:15 <Inge-> a few small sanity-checks could provide the user with good information on why this could be (e.g. your wallet was restored with height X which means that if your funds arrived BEFORE date Y then it would not show up. Rescan from an earlier point in time?)
08:11:18 <midipoet> i agree - it may be helpful to have some info readily available for users
08:13:26 <Inge-> also, it could probably fairly easily sanity-check other things such as the top block on the connected node vs a few other points (other open nodes, xmrchain etc) - "The node you are connected to looks like it might not be entirely up-to-date.." - I can see some potential attack vectors, but a better UX would be very helpful.
09:18:13 <nonie> https://www.youtube.com/watch?v=eGpa45y4_HQ
09:30:29 <nonie> ^- Titel: MCC 2019: Future of Privacy Coins Panel
09:36:42 <newyearday> hello
09:39:13 <nonie> ㋡ hi
09:48:04 <newyearday> how to measure impact of different reward between genesis block  and next blocks for new blockchain
09:53:08 <newyearday> genesis block is 100X of next blocks
09:54:21 <newyearday> can reward of next blocks change in far future because of emission or smth else
09:54:34 <newyearday> i mean without changing anything else
09:54:50 <newyearday> just genesis 100x and no other change
09:55:08 <newyearday> same emission etc
10:06:49 <newyearday> anyone here
10:07:28 <Inge-> monero looks at current total emitted to calculate emission of next block
10:07:32 <Inge-> BTC does not AFAIK
10:07:55 <Inge-> this has bit a few forks that made changes
10:10:00 <newyearday> smth more precise?
10:10:21 <newyearday> how to keep reward of next blocks the same
10:10:58 <newyearday> even after 10000000 blocks
10:28:37 <nonie> Maybe the whitepaper can help: https://cryptonote.org/whitepaper.pdf
10:29:00 <nonie> Chapter 6.1 Smooth emission
10:30:02 <newyearday> code changed a lot after original cryptonote
10:34:18 <nonie> BaseReward = (MSupply−A)>>18
10:39:22 <nonie> True.
10:44:07 <newyearday> what do u mean by true
10:44:37 <asymptotically> newyearday: he's agreeing with you that monero has changed a lot since the original cryptonote
10:44:44 <newyearday> yep
10:46:14 <nonie> https://github.com/monero-project/monero/blob/84ce43a23956ac6b5e07dc4c7cd5777d3992046f/src/cryptonote_basic/cryptonote_basic_impl.cpp
10:47:01 <nonie> Maybe this function can help: get_block_reward
10:47:37 <newyearday> this function help only for changing block 0
10:48:41 <newyearday> im not sure but there are other function that changes rewards of next blocks for any reason
10:49:01 <newyearday> i didnt change anything except block 0
10:50:22 <newyearday> to say the truth i dont know why "difficulty targets must be a multiple of 60" and not "multiple of X"
10:50:35 <newyearday> for version2
10:59:51 <nonie> I couldn't tell you - Need to understand for myself.
11:25:14 <nonie> target_minutes = target / 60; So the time is converted from seconds to minutes.
11:27:58 <nonie> I guess the assert on the top of the function is not necessary - but you never know. Probably something to be on the safe side.
11:40:20 <nonie> It does test if DIFFICULTY_TARGET_V2 is devideable by 60 (DIFFICULTY_TARGET_V2 modulo 60).
14:25:59 <mfoolb> .usd
15:23:53 <Inge-> this seems like unreasonably high rates of SME adoption: https://bitcoinist.com/rising-crypto-adoption-growing-cyber-threat/
16:53:48 <mfoolb> by the way, a part from temperature anomalies, is there a way or an average time to know if thermal paste has dried out?
16:57:16 <asymptotically> take the heatsink off and look at it. some of the higher end pastes recommend that you change it every couple of years
16:57:53 <gingeropolous> i just weld it
16:57:56 <mfoolb> asymptotically: I'm ok.. I was just curious
17:37:36 <kinghat> https://it.slashdot.org/story/20/02/06/1429205/academics-steal-data-from-air-gapped-systems-using-screen-brightness-variations
17:39:59 <moneromooo> While people eat these up, no reason not to recycle the same paper over and over again using a different hardware part...
17:46:45 <asymptotically> news: you can output data through an output device :O
17:58:11 <Mochi102> omg
17:58:17 <Mochi102> What a concept.
20:09:14 <nonie> insane.
21:49:00 <newyearday> hello
22:02:02 <Skirmant> newyearday: hey fam
22:02:35 <newyearday> fam ?
22:02:55 <Skirmant> famagotchi
22:06:26 <newyearday> famagotchi ?