Is there any documentation/setup for wallet "push" notifications over JSON-RPC? (a la --tx-notify)

Hey everyone - how's it going?

There is no wallet "push" notifications over JSON-RPC? There is over 0MQ though.

Try commit messages probably.

theorem: I don't think GitFlow is well suited to organised-through-chaos FOSS projects like Monero

that said, we already have something similar with releases

major releases go into their own branch

and then bug fixes get pushed both to master *and* to the branch

so that the point release can be built off of the branch

whilst master continues to be the main development point

we just don't do feature branches on the main repo, although individual developers do

<moneromooo "There is no wallet "push" notifi"> From discussion with vtnerd, JSON-RPC supports server->client messages, if we currently are not implementing it, is there any docs I could have a look at relating to this? (I didn't know JSON-RPC over HTTP supported this). Also 0MQ is only available on the daemon AFAIK.

Oh really. That's weird. I thought I'd remembered something like that.

Maybe that got added when I wasn't looking :)

No worries, see issue #7408 for context

What happens if I import the Blockchain without verifying it? (Parameter "--verify 0")

You are vulnerable to bad data not being detected.

Bad data, as for example just a bit flip or could the blockchain have been tampered with?

Did you generate that blockchain file ?

No

It's just an example. Let's say I got it from an untrustworthy source.

So you're asking if a third party could have tampered with the data they send you if you don't check it ?

Assuming that's no trick question, I'm going to go with yes :)

Please leave the messages etc warning about it.

Sorry if I'm not typing clearly. English isn't my first language.

I know third parties could tamper with data. My question is: if I import it without verifying it, at what point could/would I know?

You might never know if you don't check.

Thank you for your answers :)

Where is it specified that you can only lock funds for 1,000,000 blocks and why was 1,000,000 chosen?

src/simplewallet/simplewallet.cpp IIRC, and arbitrary. The limit is just client, the daemon will accept larger values.

Why was a block time of 2 minutes chosen? Why not 1 minute?

I imagine there's some security/privacy reason, correct?

Yes.

Arbitrary really.

Mutliples of 1 minute are easier code wise.

It used to be 1 minute originally.

Do you think that the block time will increase in the future?

IE If I wanted to lock away funds for 5 years, that is dependent on block time, and therefore an increase to 3 minutes would turn that 5 years to 7.5 years suddenly.

You can lock till a given time too. UNIX time in seconds since the epoch (1970).

Ooooo, awesome

rather unlikely the block time changes again

Like ever?

Or for the considerable future?

moneromooo: that lock time is not limited to 32 bits is it? if so it will run out in 2038

it's 64 bit

cool

~584.5 billion years ought to be enough for everyone

in my head the only rational to increase blocktime would be to mitigate orphan rates caused by large blocks

but that should also just be a force to drive smaller blocks

as the network reaches an equilibrium

interesting point. Is there anything in current monerod that notices if its last block was orphaned, and dials down block size in response?

No.

What would happen to fees if we reached a rate of 5,000 tps for a significant amount of time? What about 10,000 tps?

certainly not urgent

Not sure it really matters since most txes will be already known to peers, so only txids get sent.

Try #monero, this doesn't really seem development related.

Oops, sorry about that

Where is the dictionary mapping the triplets of mnemonics to bytes?

src/mnemonics

hyc, i think this would be a response by miners. i don't think its necessary for the protocol to dial it back. miners would notice that large blocks are getting orphaned so they'd dial it back

of course, we could end up seeing the same thing that bitcoin has seen, with the development of a secondary high speed block relay network overlay thing

so that natural equilibrium could be irrelevant, and 2 minute block target could be fine

moneromooo, you might want to take a look:

I'll be back later.

Sure.

(I've not looked in detail, but the concept seems fine)

How can I fix `Submodule 'external/miniupnp' is not up-to-date.` on release-v0.17?

Trying to build mymonero-lws which relies on release-v0.17, but not sure how to get past the miniupnp error.

theres a thing on the pr

<iDunk> git submodule sync

<iDunk> git submodule update

hi iDunk

Perfect, thanks :D

on line 281 in electrum-words.cpp there's this line "const size_t expected = len * 8 * 3 / 32;"

I don't understand why it's necessary, why are we multiplying by 24 and then dividing by 32? Also why not just multiply by 3 then divide by 4? Thanks

Grepping for calls, len is sizeof(dst), so len is the nunmber of bits in dst. I think the seed is 3 words for 32 bits (so 24 words for 256 bits).

Is there any code for the atomic swaps yet on github?

I think they're still in the specs stage.

Ok so I tried to decode what was happening on this line but I absolutely gave up

        w[0]= w[1] + word_list_length * (((word_list_length - w[1]) + w[2]) % word_list_length) +

          word_list_length * word_list_length * (((word_list_length - w[2]) + w[3]) % word_list_length);

What the heck is going on there? I think w[0] represents the bytes of a triplet of words, right?

A bit of a complex way to convert between 32 byte words and word list indices.

Where is the private spend key used to generate the private view key?

Sorry if it seems like I'm asking a bunch of noob questions, but I have an idea for something I'd like to make, and I'd like to know what I'm doing lol

It's typically generated by getting random bytes off the OS PRNG.

WillSellBodyForX: grep for keccak in src/cryptonote_basic/account.cpp