07:41:18 doktoroesperanto: saluton, I can help 07:41:22 you can at least do the course on duolingo.com that should be enough to get you started 07:41:42 also since you are on freenode there is the freenode channel 11:27:07 moneromooo: this is Debian Stretch with boost 1.62 11:28:25 there's no mismatched boost libraries, they're all 1.62 11:35:30 Are you able to buil with -fsanitize=adress (done by the fuzz target) ? 11:35:36 Are you able to buil with -fsanitize=address (done by the fuzz target) ? 11:40:33 I'll try 11:47:39 And when you do can you please also paste the output of the cmake part of the build (at the start) ? From the beginning to "Configuring done". 12:00:38 moneromooo: here's the cmake output: https://paste.debian.net/hidden/7a4f17bb/ 12:08:19 Thanks, nothing wrong so far. 13:05:01 I was discussing with someone the other day who said: "With Monero there is a danger of hidden inflation through faulty source code, because you can't check the blockchain". 13:05:01 I argued that the source code responsible for the double spend is very small and that the risk is manageable.Bitcoin also has risks from lack of fungibility etc. (risk management). Does anyone have any argument against that? 13:07:06 It's fairly small, though it's not the only way to have hidden inflation (broken range proofs would also be a way). 13:07:39 Lack of fungibility doesn't impact hidden inflation fwiw. 13:08:20 Bitcoin did have an inflation bug IIRC. Monero too (it didn't get exploited, though the Bitcoin one did get exploited AFAIK). 13:09:36 /usr/bin/ld: ../../contrib/epee/src/libepee.a(net_helper.cpp.o): TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `_ZN5boost4asio6detail15keyword_tss_ptrINS1_10call_stackINS1_15task_io_serviceENS1_27task_io_service_thread_infoEE7contextEE6value_E' at 0x176f in section 13:09:41 `.text._ZN5boost4asio6detail15task_io_service3runERNS_6system10error_codeE[_ZN5boost4asio6detail15task_io_service3runERNS_6system10error_codeE]' failed 13:09:44 /usr/bin/ld: final link failed: Nonrepresentable section on output 13:09:47 But you could fix the bug in Bitcoin because you see the infaltion. 13:09:47 hmm 13:10:08 * rah tries a "make clean" 13:10:37 That's no fun. Might need CLANG, IIRC some versions of GCC cause similar issues. 13:13:33 What do you mean by »broken range proof«? The theoretical concept, or the implementation? 13:15:17 Both would qualify. 13:17:08 But the source code can be narrowed down, which is responsible, isn't it? 13:17:33 Shit. 13:17:58 Sorry - i need to reboot my PC. Fixing some stuff at the moment. 13:36:15 moneromooo: I have clang installed 14:51:51 Unfortunately it seems the IRC-to-Mattermost bridge held only a few days this time. pigeons, can I bother you already again? If there is anything I could help here (other than write such notices) please do tell. 18:44:59 well the matrix bridge is doing good 18:45:00 room needs upgrading though, been waiting a year for that 19:05:48 :) 20:56:39 happy that I can reach the irc chats through matrix 21:15:28 is there an easy way to crosscompile monero for a different architecture using just the cmake stuff, not gitian? 21:17:40 Howdy folks .. I'm trying to setup a hot (view-only) wallet + cold wallet (for spending) 21:17:40 Can the cold wallet compute the correct balance on its own, without revealing key-images to the hot wallet ? 21:18:42 it's the other way around, the hot wallet's spent key images must be revealed to the cold wallet. 21:18:54 otherwise the cold wallet's balance will be the sum of all received transactions, not counting any spent ones. 21:19:26 mm .. I don't care about the hot wallet knowing the correct balance 21:19:31 err, sorry. i got that backwards, ig nore the first half 21:19:48 Yes (in theory). 21:19:53 so I basically .. exported outputs from the hot wallet .. imported into cold wallet 21:20:03 if you don't care about the correct balance in the view-only wallet, you don't need to do anything 21:20:04 now both wallets show wrong (larger) balance 21:20:25 The spend wallet also shows larger balance 21:20:32 are both wallets up to date with respect to the blockchain? 21:20:43 The spend wallet has never been online 21:22:34 so can the spend wallet compute the correct balance without help from the hot wallet ? 21:22:59 I want to keep the spend wallet offline all the time 21:23:34 only communicating with the hot wallet if some info is needed 21:23:52 kim0: Yes (in theory). 21:24:12 so why only in theory :) 21:24:16 kim0: did you look at `show_transfers` and see what kind of transactions are missing/incorrect? incoming or outgoing? 21:24:35 Presumably because there is a bug. 21:24:41 One output that was spent .. is not marked as spent 21:25:17 i suspect you didn't export & import the spent key image properly? either that or there is a bug like mooo says 21:25:24 This wallet received 10 .. spent 1 .. ofc got 9 back as change 21:25:24 Now the spend wallet, thinks it has 19 21:26:02 The only step I did so far, was to export outputs from hot wallet .. and import that into cold wallet 21:26:54 I think step-2 .. is to export key-images from cold and import that into hot wallet .. but I do not wish to reveal total balance to hot wallet .. so was wondering if there's a way to compute correct balance, without doing this step (i.e. without revealing balance to hot wallet) 21:26:55 A bug or just not implemented. 21:28:22 moneromooo: and ndorf .. Thanks for your help .. but please check my line above .. bec I am not doing that step .. and hoping there's a way without revealing key-images to hot wallet 21:31:40 so it's the spend wallet that's not recognizing a spent output? one that it itself actually spent? 21:32:08 not exactly that .. I deleted the wallet files .. and that's a new spend wallet 21:33:46 I guess it's actually "no in theory". Or at least not without extra work. 21:33:51 ah i see. so you deleted and recreated the wallet from seed. then you imported the received outputs from watch wallet, but not spent key images from old, deleted spend wallet. is that right? 21:34:01 The hot wallet gives outputs to the cold wallet, which computes key images. 21:34:05 ndorf: exactly 21:34:17 But the cold wallet does not have the blocks, so can't actually see what's spent yet. 21:34:42 So you'd have to do the full set twice before the cold wallet can tell. 21:35:09 so cold wallet .. has to give hot wallet the key-images .. to compare with blockchain .. to know which outputs were spent right 21:35:13 But that involves telling the hot wallet which outputs are spent. 21:35:32 and this way, the hot wallet, has to know total balance (even before cold wallet) 21:35:44 or, just not deleting the spent outputs from the cold wallet, right? 21:36:46 Yeah .. just trying to understand the limitations :) 21:37:57 So you would have to get the cold wallet to parse the blocks to see if any of the key images are there for this to work. 21:38:27 So new code (since you don't want to connect the cold wallet to the daemon). 21:39:04 It would be enough for the hot wallet to send just the height/key images I think. 21:39:57 (of all blocks not yet sent to the cold wallet) 21:40:01 you could set up a new daemon on a clean machine. sync it, then disconnect it from the internet. connect it directly to your cold wallet so it can scan the blocks. then destroy the temporary daemon setup without ever reconnecting it to the internet. 21:41:21 maybe someone smarter than me should review that first but it seems safe?