01:30:26 <mystik> hey guys
01:31:59 <mystik> wfaressuissia brought up a document about fully homomorphic encryption, and I was thinking, why not creating private smart contracts (as proposed by sed, another user), using the computational power of the interested parties in any given transaction?
01:32:26 <UkoeHB> computational power?
01:33:09 <mystik> yes, like, instead of being the nodes executing some shady smart contract code, it would be the parts involved (their computers)
01:34:41 <mystik> they agree to make transactions conditioned by some smart contract code, and it's their business, the network only waits until it's fully confirmed by all involved parties, then it confirms the transaction. The mempool would grow, I guess.
01:35:12 <mystik> I'm not saying that it's possible, it's just an idea.
01:36:49 <mystik> I guess that every contract would need to have its own address.
02:00:39 <UkoeHB> Hmm I think the main problem is trust. If you have to trust the other party not to cheat, then what do you gain from fancy cryptography?
02:03:00 <UkoeHB> However, I could be mistaken about what the tech can achieve.
02:20:49 <mystik> UkoeHB: if there is no agreement (cheating) then there's no transaction, let's say you and me trust an oracles provider. What that oracle says is accepted as truth by all parties. This oracles provider would be paid, a small fee. It's mission is just to verify an information and say true/false. This third party executes the contract code. And it requires one more signature to be a valid transaction (2 
02:20:55 <mystik> of 3). Once any of the parties accept what the oracle said is true signs, it's done. The parties execute the contract as well, to that end.
02:22:02 <mystik> this can be done on bitcoin, but making it private would be dynamite
02:23:01 <UkoeHB> I guess it's hard for me to visualize without a concrete example.
02:25:46 <mystik> UkoeHB: imagine we make a bet, who wins an F1 race. There is a company that verifies the result and pays the bettors. This company "approves" (signs) transactions that match the result in real life. 
02:26:55 <mystik> that's an oracle
02:27:06 <mystik> the oracle says what is true, and reflects that reality on the blockchain
02:27:36 <nikg83[m]> mystik: Who is the oracle ? 
02:28:18 <mystik> the company that verifies the race results and says "this team won" (and does so on the blockchain)
02:28:52 <nikg83[m]> mystik: You mean miners 
02:29:01 <mystik> no, it's a second layer
02:29:46 <nikg83[m]> mystik: Pos? 
02:30:31 <mystik> no, just someone running a program on their server, and a monero node. Their program simply signs transactions, that are broadcast on the monero blockchain.
02:30:50 <mystik> nothing fancy so far
02:31:39 <mystik> The thing is, how to make the whole thing private, without compromising anyone's identity?
08:38:50 <mj-xmr[m]> <selsta> "We need reviews for 7845 and 782..." <- I had a look at 7845. It doesn't seem to make things worse from my PoV.
08:39:40 <sech1> is there any planned date for the next point release?
08:43:30 <mj-xmr[m]> But sb. needs to look there too, who can tell how this can affect the end result.
08:57:46 <selsta> sech1: when everything is reviewed
13:42:35 <UkoeHB> hi, the `node_server.bind_same_p2p_port` unit test is failing in my multisig rework, any idea what could be the problem?
13:43:41 <wfaressuissia> `--gtest_filter='-node_server.bind_same_p2p_port'` just disable it, it isn't important for your tests likely
13:45:26 <wfaressuissia> Is acceptable workaround for you ?
13:45:39 <UkoeHB> sure I can just ignore it if it isn't important
13:48:20 <UkoeHB> looks like it is passing CI anyway, maybe a local issue
13:48:34 <selsta> do you use mac?
13:48:41 <UkoeHB> yeah
13:49:19 <selsta> ugh lots of spam users joining from matrix side
13:49:47 <selsta> I have seen it on mac too
13:52:16 <UkoeHB> ok thanks :}
13:52:17 <selsta> https://github.com/monero-project/monero/commit/176cea0ec6ca2f16f9dc9f4280a9c4513828139e
13:52:26 <selsta> we had this fix for linux but I don't know if it also applies to mac
14:08:24 <UkoeHB> wfaressuissia: I might be missing something... it seems you can't pass `--gtest_filter ...` to `ctest` (at least straightforwardly): https://gitlab.kitware.com/cmake/cmake/-/issues/20470
14:16:01 <selsta> UkoeHB: ./unit_tests --gtest_filter='-node_server.bind_same_p2p_port' --gtest_break_on_failure
14:22:52 <UkoeHB> `[  PASSED  ] 1134 tests.` thanks :)
14:31:55 <Rucknium[m]> What default ring size will we likely have in a year or two?
14:40:20 <UkoeHB> ~64-256
15:17:28 <gingeropolous> feeling optimistic UkoeHB ? :)
15:32:19 <UkoeHB> perhaps
19:56:47 <UkoeHB> >_< spent 3 hrs tracking down a failure to decrypt wallet keys in a unit test... I really wish the `account_base` API would error out if you try to access encrypted keys without calling like `get_encrypted_keys()`.
19:59:07 <wfaressuissia> fortunately, I should not touch anything in src/wallet now, but that code is very ugly
20:02:59 <wfaressuissia> UkoeHB: did you use debug build ?
20:03:35 * jberman[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/11b07c2a6da387f1d74944f927090f9f16c8d4f0/message.txt >
20:05:46 <jberman[m]> Also, on Ruck's first comment regarding correcting the analysis of general impact: I feel more detailed analysis on impact takes lower priority at the moment, and isn't necessary to get the PR's across the finish line. So I'm focusing on what gets the PR's across the finish line for now. Will get back to analysis on impact when the patches are complete. Users generally know what to look for to see if they have been impacted by the issue
20:05:46 <jberman[m]> on a case-by-case basis (and all signs still point to it not materially impacting users beyond those directly affected), so I'm personally not overly concerned with getting this analysis done ASAP
20:06:35 <UkoeHB> yeah I stepped through with debugger to figure out where my keys got screwed up
20:08:01 <wfaressuissia> Did you notice any missing/optimized out information in debugger ?
20:11:58 <UkoeHB> hmm well you can't tell the difference between a regular private key and an encrypted private key
20:12:28 <UkoeHB> the encryption is done directly to the bitstring
20:15:03 <moneromooo> Unencrypted with have a 0 at the penultimate character.
20:15:20 <UkoeHB> this guy: https://github.com/monero-project/monero/blob/dcba757dd283a3396120f0df90fe746e3ec02292/src/cryptonote_basic/account.cpp#L87
20:15:20 <UkoeHB> So I had to trace from where I initially set my private keys, all the way up the call stack, to find out where they were getting messed up (my errors were all crypto errors caused by junk keys).
20:15:26 <moneromooo> Encrypted might too, with ~6% chance :)
20:17:40 <UkoeHB> The byte goop my debugger spit out is not that clear
20:17:40 <UkoeHB> A) \xd2,\x947\xbe|\x9d\U0000001c\xae\xcdJ\x9c\U00000014\xa6V\x9a\xdb\xf04\xfb]\xc5\f\xbe&\xb0\xbdb\xd3\xf2\xc0\U00000002
20:17:40 <UkoeHB> B) 4\xf7\xcf!,\xb3VB#\xa3\U00000018\x95i\U0000001d\U00000005Q\xc5v\xf0\xbe\x9f\U0000001a\x91>K\xb5\xf4\xc7x\x8b%\xcdP\xdeA\U00000010\U00000001
20:20:13 <UkoeHB> In any case, I now have my multisig key exchange rework compiling, with most tests green. Core tests may be red, but it takes 1.5hr to find out.
20:20:40 <moneromooo> Run it with MONERO_FASTER_POW=1, it goes a lot faster
20:26:29 <moneromooo> (also, --filter '*multisig*'
20:26:31 <moneromooo> )
20:27:06 <UkoeHB> can you give an example invocation?
20:27:34 <UkoeHB> unfortunately the docs for tests seem very outdated and incomplete
20:27:35 <moneromooo> ./build/Linux/cc/release/tests/core_tests/core_tests --generate_and_play_test_data --filter \*pool\*
20:28:07 <UkoeHB> `Failed to parse arguments: unrecognised option '-MONERO_FASTER_POW=1'`
20:28:14 <moneromooo> Env var
20:28:27 <moneromooo> Actually, wait, it's not upstream, nvm. --filter is though.
20:28:59 <UkoeHB> ? upstream?
20:29:30 <moneromooo> Term of art, means the original codebase you're hacking on.
20:29:41 <moneromooo> I can send you the patch though.
20:31:08 <UkoeHB> could you add it to the repo as a PR? seems useful...
20:31:25 <moneromooo> https://paste.debian.net/hidden/a0e7f9ba/
20:31:36 <moneromooo> It was IIRC. Got rejected.
20:31:58 <moneromooo> (due to adding complexity to hashing)
20:33:07 <moneromooo> Actually, I'm seeing this isn't even the faster patch. Let me dig up the faster one...
20:34:12 <moneromooo> https://paste.debian.net/hidden/831e1475/
20:34:25 <moneromooo> Didn't merge that one to monero it seems.