01:28:26 <vdero133[m]> Is there any documentation/setup for wallet "push" notifications over JSON-RPC? (a la --tx-notify)
10:17:35 <librehash> Hey everyone - how's it going?
10:32:03 <moneromooo> There is no wallet "push" notifications over JSON-RPC? There is over 0MQ though.
10:32:35 <moneromooo> Try commit messages probably.
10:35:19 <fluffypony> theorem: I don't think GitFlow is well suited to organised-through-chaos FOSS projects like Monero
10:35:31 <fluffypony> that said, we already have something similar with releases
10:35:38 <fluffypony> major releases go into their own branch
10:35:51 <fluffypony> and then bug fixes get pushed both to master *and* to the branch
10:36:02 <fluffypony> so that the point release can be built off of the branch
10:36:12 <fluffypony> whilst master continues to be the main development point
10:36:44 <fluffypony> we just don't do feature branches on the main repo, although individual developers do
11:03:05 <vdero133[m]> <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.
11:16:36 <moneromooo> Oh really. That's weird. I thought I'd remembered something like that.
11:17:11 <moneromooo> Maybe that got added when I wasn't looking :)
13:30:35 <vdero133[m]> No worries, see issue #7408 for context
17:51:28 <newpseudonymn[m]> What happens if I import the Blockchain without verifying it? (Parameter "--verify 0")
17:56:37 <moneromooo> You are vulnerable to bad data not being detected.
18:04:13 <newpseudonymn[m]> Bad data, as for example just a bit flip or could the blockchain have been tampered with?
18:06:31 <moneromooo> Did you generate that blockchain file ?
18:08:10 <newpseudonymn[m]> No
18:08:10 <newpseudonymn[m]> It's just an example. Let's say I got it from an untrustworthy source.
18:08:55 <moneromooo> So you're asking if a third party could have tampered with the data they send you if you don't check it ?
18:09:18 <moneromooo> Assuming that's no trick question, I'm going to go with yes :)
18:09:52 <moneromooo> Please leave the messages etc warning about it.
18:11:38 <newpseudonymn[m]> Sorry if I'm not typing clearly. English isn't my first language.
18:11:38 <newpseudonymn[m]> 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?
18:12:36 <moneromooo> You might never know if you don't check.
18:13:44 <newpseudonymn[m]> Thank you for your answers :)
18:44:41 <WillSellBodyForX> Where is it specified that you can only lock funds for 1,000,000 blocks and why was 1,000,000 chosen?
18:46:26 <moneromooo> src/simplewallet/simplewallet.cpp IIRC, and arbitrary. The limit is just client, the daemon will accept larger values.
18:49:28 <WillSellBodyForX> Why was a block time of 2 minutes chosen? Why not 1 minute?
18:50:44 <WillSellBodyForX> I imagine there's some security/privacy reason, correct?
18:51:56 <moneromooo> Yes.
18:52:03 <moneromooo> Arbitrary really.
18:52:17 <moneromooo> Mutliples of 1 minute are easier code wise.
18:52:47 <moneromooo> It used to be 1 minute originally.
18:56:16 <WillSellBodyForX> Do you think that the block time will increase in the future?
18:57:04 <WillSellBodyForX> 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.
19:02:24 <moneromooo> You can lock till a given time too. UNIX time in seconds since the epoch (1970).
19:03:01 <WillSellBodyForX> Ooooo, awesome
19:15:20 <luigi1111> rather unlikely the block time changes again
19:16:22 <WillSellBodyForX> Like ever?
19:16:31 <WillSellBodyForX> Or for the considerable future?
19:20:14 <hyc> moneromooo: that lock time is not limited to 32 bits is it? if so it will run out in 2038
19:20:27 <sech1> it's 64 bit
19:20:31 <hyc> cool
19:21:08 <sech1> ~584.5 billion years ought to be enough for everyone
19:21:09 <gingeropolous> in my head the only rational to increase blocktime would be to mitigate orphan rates caused by large blocks
19:21:21 <gingeropolous> but that should also just be a force to drive smaller blocks
19:21:30 <gingeropolous> as the network reaches an equilibrium
19:22:53 <hyc> interesting point. Is there anything in current monerod that notices if its last block was orphaned, and dials down block size in response?
19:23:47 <moneromooo> No.
19:24:04 <WillSellBodyForX> 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?
19:24:05 <hyc> certainly not urgent
19:24:27 <moneromooo> Not sure it really matters since most txes will be already known to peers, so only txids get sent.
19:24:54 <moneromooo> Try #monero, this doesn't really seem development related.
19:25:22 <WillSellBodyForX> Oops, sorry about that
19:35:48 <WillSellBodyForX> Where is the dictionary mapping the triplets of mnemonics to bytes?
19:40:54 <moneromooo> src/mnemonics
19:47:05 <gingeropolous> 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
19:47:39 <gingeropolous> 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
19:48:10 <gingeropolous> so that natural equilibrium could be irrelevant, and 2 minute block target could be fine
19:48:51 <mj-xmr> moneromooo, you might want to take a look:
19:48:52 <mj-xmr> https://github.com/monero-project/monero/pull/7380#issuecomment-788222115
19:49:36 <mj-xmr> I'll be back later.
19:50:12 <moneromooo> Sure.
19:50:37 <moneromooo> (I've not looked in detail, but the concept seems fine)
20:13:51 <sethsimmons> How can I fix `Submodule 'external/miniupnp' is not up-to-date.` on release-v0.17?
20:14:13 <sethsimmons> Trying to build mymonero-lws which relies on release-v0.17, but not sure how to get past the miniupnp error.
20:14:34 <gingeropolous> theres a thing on the pr
20:14:52 <gingeropolous> <iDunk> git submodule sync
20:14:53 <gingeropolous> <iDunk> git submodule update
20:14:58 <gingeropolous> hi iDunk
20:15:22 <sethsimmons> Perfect, thanks :D
21:56:27 <WillSellBodyForX> on line 281 in electrum-words.cpp there's this line "const size_t expected = len * 8 * 3 / 32;"
21:56:27 <WillSellBodyForX> 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
22:05:20 <moneromooo> 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).
22:09:45 <WillSellBodyForX> Is there any code for the atomic swaps yet on github?
22:11:36 <moneromooo> I think they're still in the specs stage.
22:22:57 <WillSellBodyForX> Ok so I tried to decode what was happening on this line but I absolutely gave up
22:22:58 <WillSellBodyForX>         w[0]= w[1] + word_list_length * (((word_list_length - w[1]) + w[2]) % word_list_length) +
22:22:58 <WillSellBodyForX>           word_list_length * word_list_length * (((word_list_length - w[2]) + w[3]) % word_list_length);
22:22:59 <WillSellBodyForX> What the heck is going on there? I think w[0] represents the bytes of a triplet of words, right?
22:39:51 <moneromooo> A bit of a complex way to convert between 32 byte words and word list indices.
22:47:19 <WillSellBodyForX> Where is the private spend key used to generate the private view key?
22:49:48 <WillSellBodyForX> 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
22:53:46 <moneromooo> It's typically generated by getting random bytes off the OS PRNG.
22:55:21 <tobtoht> WillSellBodyForX: grep for keccak in src/cryptonote_basic/account.cpp