hey guys

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?

computational power?

yes, like, instead of being the nodes executing some shady smart contract code, it would be the parts involved (their computers)

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.

I'm not saying that it's possible, it's just an idea.

I guess that every contract would need to have its own address.

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?

However, I could be mistaken about what the tech can achieve.

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

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.

this can be done on bitcoin, but making it private would be dynamite

I guess it's hard for me to visualize without a concrete example.

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.

that's an oracle

the oracle says what is true, and reflects that reality on the blockchain

mystik: Who is the oracle ?

the company that verifies the race results and says "this team won" (and does so on the blockchain)

mystik: You mean miners

no, it's a second layer

mystik: Pos?

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.

nothing fancy so far

The thing is, how to make the whole thing private, without compromising anyone's identity?

<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.

is there any planned date for the next point release?

But sb. needs to look there too, who can tell how this can affect the end result.

sech1: when everything is reviewed

hi, the `node_server.bind_same_p2p_port` unit test is failing in my multisig rework, any idea what could be the problem?

`--gtest_filter='-node_server.bind_same_p2p_port'` just disable it, it isn't important for your tests likely

Is acceptable workaround for you ?

sure I can just ignore it if it isn't important

looks like it is passing CI anyway, maybe a local issue

do you use mac?

yeah

ugh lots of spam users joining from matrix side

I have seen it on mac too

ok thanks :}

we had this fix for linux but I don't know if it also applies to mac

wfaressuissia: I might be missing something... it seems you can't pass `--gtest_filter ...` to `ctest` (at least straightforwardly): gitlab.kitware.com/cmake/cmake/-/issues/20470

UkoeHB: ./unit_tests --gtest_filter='-node_server.bind_same_p2p_port' --gtest_break_on_failure

`[ PASSED ] 1134 tests.` thanks :)

What default ring size will we likely have in a year or two?

~64-256

feeling optimistic UkoeHB ? :)

perhaps

>_< 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()`.

fortunately, I should not touch anything in src/wallet now, but that code is very ugly

UkoeHB: did you use debug build ?

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

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

yeah I stepped through with debugger to figure out where my keys got screwed up

Did you notice any missing/optimized out information in debugger ?

hmm well you can't tell the difference between a regular private key and an encrypted private key

the encryption is done directly to the bitstring

Unencrypted with have a 0 at the penultimate character.

this guy: github.com/monero-project/monero/bl…rc/cryptonote_basic/account.cpp#L87

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).

Encrypted might too, with ~6% chance :)

The byte goop my debugger spit out is not that clear

A) \xd2,\x947\xbe|\x9d\U0000001c\xae\xcdJ\x9c\U00000014\xa6V\x9a\xdb\xf04\xfb]\xc5\f\xbe&\xb0\xbdb\xd3\xf2\xc0\U00000002

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

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.

Run it with MONERO_FASTER_POW=1, it goes a lot faster

(also, --filter '*multisig*'

)

can you give an example invocation?

unfortunately the docs for tests seem very outdated and incomplete

./build/Linux/cc/release/tests/core_tests/core_tests --generate_and_play_test_data --filter \*pool\*

`Failed to parse arguments: unrecognised option '-MONERO_FASTER_POW=1'`

Env var

Actually, wait, it's not upstream, nvm. --filter is though.

? upstream?

Term of art, means the original codebase you're hacking on.

I can send you the patch though.

could you add it to the repo as a PR? seems useful...

It was IIRC. Got rejected.

(due to adding complexity to hashing)

Actually, I'm seeing this isn't even the faster patch. Let me dig up the faster one...

Didn't merge that one to monero it seems.