04:15:27 <vtnerd> TrasherDK : the cmake for monero-lws should be relaxed now
04:15:41 <vtnerd> ZeroMQ chain subscription support was also added
07:15:34 <TrasherDK> vtnerd: Yes. cmake passes now :)
07:31:47 <TrasherDK> vtnerd: But "#error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options."
07:42:44 <TrasherDK> Adding CXX_STANDARD=11 to cmake yields: "Manually-specified variables were not used by the project: CXX_STANDARD" but the build run a bit further before crashing.
07:44:58 <TrasherDK> [  3%] Building CXX object src/CMakeFiles/monero-lws-common.dir/config.cpp.o
07:44:58 <TrasherDK> [  6%] Building CXX object src/CMakeFiles/monero-lws-common.dir/error.cpp.o
11:23:46 <selsta> .merges
11:23:46 -xmr-pr- 6111 6600 6607 6610 6613 6690 6693 6731 6746 6752 6753 6757 6771
11:32:05 <selsta> seems like we can add 6613, 6760, 6761, 6762 6763 to the list ^
12:13:18 <TrasherDK> How about #6766 Is that one in already?
16:31:28 <nandubatchu> Hi there
16:31:40 <nandubatchu> need help with monero transaction building and broadcasting via python
16:32:34 <nandubatchu> I am getting 'cannot load unsigned_txset'
16:32:47 <nandubatchu> while I try to hit RPC endpoing `sign_transfer`
16:32:53 <nandubatchu> any idea where am I going wrong?
16:33:15 <dEBRUYNE> Would probably help if you post logs and/or the code somewhere
16:38:21 <grydz> Hi there, I'm now able to go through the CLSAG signature part on Ledger's hardware wallet but I get an internal error at the end: "total_received < r.second.first". Could this be related to the algebra or something else?
16:38:23 <grydz> https://gist.github.com/grydz/f1a2514c47df4f62d0fe99931ec855fb
17:05:29 <grydz> Here is the patch applied to PR #6739: https://gist.github.com/grydz/dc34efb7e3cd6f91189bf27c2ce62b0b
17:07:24 <moneromooo> It looks like it's the code that checks whether the tx does pay each of the intended recipients before sending it.
17:07:39 <moneromooo> If it fails, it means your tx or the checking code is wrong.
17:08:14 <moneromooo> It's a sanity check to avoid sending a tx which is known to not do what it was meant to do.
17:08:46 <sarang> moneromooo: based on what grydz told me, the signature check should be failing (and perhaps generation as well, depending on sanity checks...)
17:09:12 <sarang> Or at least, there was an algebra error in the Ledger CLSAG generation code when the error was seen
17:09:23 <sarang> That's been fixed, but another algebra error could exist still
17:09:41 <sarang> I'm going through the Ledger stuff as well, to see if this is the case
17:10:47 <moneromooo> That's the outputs I think so that should not break if the input isgs are broken.
17:11:41 <sarang> Hm ok, so the signature check was not performed
17:11:52 <sarang> Which means it was incorrect, but this was not a source of the error
17:11:53 <sarang> ok
17:12:07 <sarang> At any rate, the algebra error was still there =p
17:26:07 <grydz> moneromooo, what's the func name of this check?
17:33:58 <moneromooo> sanity_check ?
17:34:13 <moneromooo> The one in which this assert is. Am I missing your point ? :)
17:41:44 <grydz> Got it ;)
17:49:31 <kayront> how much of the stuff in https://cryptonote.org/ is relevant to monero as it is today?
17:51:27 <fluffypony> like 20%
17:51:42 <kayront> as i feared
17:51:48 <kayront> .. is there a cryptonero.org ?
17:51:49 <hyc> the actual p2p protocol perhaps
17:52:01 <hyc> i.e. message formatting rules
17:52:24 <kayront> let me try another angle
17:52:58 <kayront> for some not-completely-beginner developer, is there some resource (besides the source code) where by reading, understanding and following along, eventually he'd be able to come up with a fully functional monero daemon?
17:53:10 <kayront> what all the rules and concepts are etc
17:53:18 <hyc> zero-to-monero?
17:54:08 <kayront> would that be enough to implement the whole thing?
17:55:21 <kayront> it's something i've wondered on and off for awhile, i don't really get how it works at lower levels. but for instance, if the rules have changed quite some times because of hardforks, doesn't that entire logic also have to be part of this hypothetical alternative implementation? actually when i phrase it like this the answer must be yes
17:56:25 <sarang> Yes
17:56:33 <kayront> i'm swimming a bit out of my depth here so if the questions seem confusing or unclear it's because i don't really know what i'm talking about
17:56:36 <sarang> Zero to Monero is the closest thing to a protocol spec that exists
17:56:53 <sarang> but even that doesn't try to fully address the state of consensus rules at each upgrade
17:57:28 <sarang> It would be far easier to build something on a new chain that doesn't require the baggage of earlier protocol rules
17:57:34 <kayront> should that stuff be documented? i imagine it would make the life of new programmers who'd like a stab at implementing the protocol much much easier
17:57:42 <sarang> Go for it :D
17:57:59 <sarang> But I hold little hope that such an effort would be maintained meticulously as things change
17:58:01 <kayront> hah, need to understand a lot more about it
17:58:06 <moneromooo> Can't hurt (unless it's documented wrong).
18:00:10 <kayront> and what about the architecture of monerod
18:00:32 <kayront> is that documented somewhere for developers?
18:00:38 <kayront> (besides source code :p)
21:46:14 <selsta> .merge+ 6613 6760 6761 6762 6763
21:46:29 <selsta> .merges
21:46:29 -xmr-pr- 6111 6600 6607 6610 6613 6690 6693 6731 6746 6752 6753 6757 6760 6761 6762 6763 6771
22:21:46 <Snipa> I'll dig through them tonight once I wake back up again.
22:22:13 <selsta> ty
23:57:32 <selsta> .merge- 6111
23:57:32 <xmr-pr> Removed
23:57:41 <selsta> ^ until moo looked at the functional test p2p stuff