--- Log opened Wed Jul 07 00:01:00 2021
00:26 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 244 seconds]
00:28 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #joinmarket
01:00 -!- undeath [~undeath@user/undeath] has joined #joinmarket
01:19 -!- jungly [~jungly@host-79-35-191-110.retail.telecomitalia.it] has joined #joinmarket
02:02 < waxwing> openoms, do you need some input into the 0.9 release. i mean specifically, have you had time to decide how to deal with integration into joininbox?
02:02 < waxwing> i'm asking because it seems like a slightly nontrivial exercise
02:52 < openoms[m]> @waxwing thanks, haven't looked into into it yet.
02:52 < openoms[m]> The good thing is I tried to expose the scripts as far as possible so the wallet generation is for example happening by directly interacting with the wallet-tool.
02:54 < openoms[m]> will the QT GUI have any new or changed effect buttons for example?
02:55 < openoms[m]> I think it will mainly about adding more info and explanation and maybe  a few extra menu options to display the new info about the Fidelity Bonds.
02:56 < openoms[m]> Will need to sit down and try the workflow on signet first of all. Do you think we are that stage that should go ahead with that?
03:11 < waxwing> no GUI changes yet, in fact, the fidelity bond wallet won't even be supported on GUI yet unfortunately
03:11 < waxwing> yes it's time to test stuff on signet if you want to do that. merge is imminent i believe.
03:11 < waxwing> there are certainly details that can change but that'll always be true :)
03:11 < waxwing> openoms[m], ^
03:12 < waxwing> main thing is for yielders to be able to create the new wallet type (or recover their existing seed to create a new wallet file with the FB feature included)
03:12 < waxwing> and the function to actually create a timelocked output (wallet-tool gettimelockaddress)
03:16 < openoms[m]> ok, thanks will get to testing (hoping tomorrow) and let you know of any problems
03:24 -!- davterra [~davterra@178.128.106.205] has quit [Ping timeout: 252 seconds]
06:17 -!- davterra [~davterra@178.128.106.205] has joined #joinmarket
07:02 < waxwing> so from what you said, openoms[m] , is the inability to spend out of a FB wallet with the Qt gui, going to be an issue?
07:03 < waxwing> Or is it more like, only a few users are hooking up the Qt gui and they're mostly spending via CLI or your interface?
07:13 < waxwing> i'm still a bit concerned about two things, first the syncing time has increased considerably and it's fine on my machine but may be very slow on constrained devices
07:13 < waxwing> and second, the increased data transfer on !orderbook, which i mentioned earlier somewhere.
07:14 < waxwing> see: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/872#issuecomment-872212579
07:15 < undeath> any idea what might be the cause for increased sync time?
07:27 < waxwing> i believe it's the generation of all the potential future FB addresses
07:27 < waxwing> i think we could stand to reduce the number of years further but i'll let belcher_ chime in on that
07:28 < waxwing> undeath, ^
07:28 <+JoinMarketRelay> [hackint/sqhqa^AWkyOkKkMLkS\VIat\rBdBdBz] a few bytes more or less
07:32 < undeath> was that already introduced in an earlier pr? i don't see any changes to wallet syncing in #872
07:34 -!- technonerd [~techno@user/technonerd] has quit [Remote host closed the connection]
07:34 -!- technonerd [~techno@user/technonerd] has joined #joinmarket
07:57 <+JoinMarketRelay> [hackint/sqhqa^AWkyOkKkMLkS\VIat\rBdBdBz] don't care about extra bytes. not all will send it anyway soon I guess?
08:01 < undeath> the matter is not one of personal preference but whether the irc networks' spam protections will kick in and block messages
08:32 <+JoinMarketRelay> [hackint/sqhqa^AWkyOkKkMLkS\VIat\rBdBdBz] In the git pr comment I read, they are getting truncated. the networks flood protection triggers by msgs/time as far I know. also remember the builtin delay of jm irc message channel.
08:33 <+JoinMarketRelay> [hackint/sqhqa^AWkyOkKkMLkS\VIat\rBdBdBz] limits    messages / second https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmdaemon/jmdaemon/irc.py#L174-L181
08:34 <+JoinMarketRelay> [hackint/sqhqa^AWkyOkKkMLkS\VIat\rBdBdBz] truncated* & splitted over multiple msgs
08:36 < undeath> yes, and with the messages being split into multiple messages the spam protection is more likely to kick in
10:47 -!- Guest9654 [~takinbo@2a01:4f8:160:60aa:fee::10] has joined #joinmarket
11:26 -!- surfer91 [~surfer91@102.67.16.112] has joined #joinmarket
13:14 < belcher_> undeath yes it was introduced in the earlier PR which added fidelity bond wallets, but that code was disabled until now
13:15 < belcher_> id be against reducing the number of years of locktime because i think the de-facto standard will end up lasting decades so the year 2050 or 2070 isnt that far away, but how about reducing the number of addresses per year instead? right now the possible locktimes are monthly, i.e. users can choose the 1st of any month as the locktime, so thats 12 addresses per year... if instead we made the options be bimonthly (6 addresses per year) or quarterly (4 
13:15 < belcher_> addresses per year) it would reduce the number of addresses a lot
13:16 < belcher_> so in concrete terms, being able to choose quarterly instead of monthly means you have to choice of 1st january, 1st april, 1st july or 1st october
13:23 -!- jungly [~jungly@host-79-35-191-110.retail.telecomitalia.it] has quit [Ping timeout: 252 seconds]
13:56 < undeath> when scanning for timelocked addresses, how about a logarithmic approach?
13:56 < undeath> scan the next twelve months, following year in quarters and then one address per year
13:57 < undeath> realistically that's all people are going to use
13:59 < undeath> it's unlikely to be of use to be able to pin a specific month in year 2037 at this time we live in
13:59 < belcher_> when a user types in a seed phrase, how does the wallet know what "the next twelve months" are?
14:00 < belcher_> but yes its a good observation that far away times dont really need such granuality
14:00 < undeath> twelve months from now()
14:00 < undeath> rounded to the first of each month
14:01 < belcher_> so if i create a seed in 2021 and send money to an address there, then recover the seed in 2030, what happens?
14:01 < undeath> interesting point about past dates
14:01 < belcher_> bip39 seed phrases dont have a creation date, which would make this easier
14:02 < belcher_> you know in the long term with watch-only fidelity bond wallets, the sync time will be way less of an issue because few people will store fidelity bonds on their hot wallets
14:03 < belcher_> in the rare occasions when you sync your cold storage fidelity bond wallet, you can wait a little bit longer... in the common occasions when you're sync'ing your hot wallet sync will still be fast because no fidelity bonds
14:04 < undeath> and "hide" the fb recovery behind a switch that will then go back the years
14:04 < undeath> with an optional user-supplied start year/date
14:05 < belcher_> in a way we already have a switch to hide fidelity bonds, which is to create non-fidelity-bond wallets
14:06 < belcher_> my concern with adding more options is that it moves further away from the draem of
14:06 < belcher_> err
14:06 < belcher_> my concern with adding more options is that it moves further away from the dream of "store these 12 words and thats all you need"
14:06 < belcher_> though admittedly bip39 has already failed at this, because you need to remember derivation paths and/or bip numbers (like e.g. bip84)
14:07 < undeath> …and incremental testing isn't feasible because it'll require a -rescan each time
14:07 < belcher_> yeah, however scantxoutset can make that slightly easier
14:08 < belcher_> it only finds unspent balance but for most people finding a weird piece of paper with 12 words thats what they're most interested in really
14:08 < undeath> so right now jm has a hardcoded date, the start of fb, and at every point in the future will scan for fbs in all addresses up to that date?
14:08 < undeath> or rather, starting from that date
14:09 < belcher_> what do you mean by the start of fb?
14:09 < undeath> well, there's a lower limit for when people could have created a fb with their jm wallet
14:10 < undeath> which is the date of implementation of fb
14:10 < belcher_> how it works today: for each public key, it creates the timelocked address for that pubkey plus locktimes going from 1st jan 2020 for each month until the year 2??? (i forgot exactly but i think 2070)
14:10 < belcher_> but instead of generating 6 pubkeys by default it generates just 1
14:11 < undeath> i see
14:11 < undeath> yeah, that's a lot of addresses
14:11 < belcher_> 2020 was chosen because i coded fidelity bond wallets around feburary 2020, i guess we could bump the year up but its a round number and wont make much difference overall
14:11 < undeath> recovering expired addresses is a big pain
14:12 < undeath> in the end it's only a difference of twelve addresses
14:12 < belcher_> expired addresses are still needed because the wallet needs to know if the pubkey was used so it can generate the next pubkey
14:12 < belcher_> moving to bimonthly, quarterly or thirdly(?) reduces those number of addresses by a factor
14:12 < undeath> couldn't you tie the pubkey to the locktime?
14:12 -!- belcher_ is now known as belcher
14:13 < belcher> it could, whats the benefit of doing that?
14:13 < undeath> you don't need to know anything about the already used keys then
14:15 < belcher> ok so just typing it out so i understand, we get a pubkey from the HD wallet, then the pubkey used in the address is pubkey+G*locktime (with the corresponding privkey being privkey+locktime)
14:15 < belcher> and then you still import and watch loads of addresses, but once an address is used what happens?
14:15 < belcher> oh i get it
14:15 < belcher> you just need one pubkey
14:16 < undeath> and you don't need to know what keys have been associated with a fb to scan for the next one
14:16 < belcher> if someone used to have coins in a timelocked address with a locktime of 1st jan 2022, they can send the coins to another address with a locktime of 1st jan 2025
14:17 < belcher> hmm, however with my scheme an observer of the blockchain can know they belong to the same wallet by doing one pubkey minus G*locktime
14:17 < belcher> ok to fix that, change the scheme to be pubkey+G*locktime+random_nonce_generated_from_HD_seed
14:18 < undeath> or hardened derivation as defined in some bip?
14:18 < belcher> you know i think an equivalent way to do this is to use a new pubkey for each locktime
14:18 < undeath> that would work too
14:18 < belcher> i.e. addresses are ("m/84/0/2/0" + 1st jan 2020) ("m/84/0/2/1" + 1st feb 2020), etc
14:18 < undeath> exactly
14:19 < undeath> that was my initial thought actually
14:19 < belcher> thats a good idea i think
14:19 < belcher> so then the wallet only ever imports 600 addresses or however many it is, but no more
14:19 < undeath> yep
14:20 < belcher> the only limitation is the user cant reuse a datetime without reusing an address and pubkey, but i dont think theres a need for anyone to ever do that anyway
14:20 < undeath> you could add another dervation step
14:21 < belcher> right now when a user funds a single timelocked address, the wallet will generate *another* pubkey and import *another* ~600 addresses
14:21 < undeath> but likely hardly needed by anyone
14:21 < belcher> so funding one address actually means watching 1200 addresses not 600
14:21 < belcher> an unnecessary amount with this new scheme
14:21 < belcher> and then with something like bimonthly locktimes we can reduce the number of addresses more
14:22 < undeath> and for future addresses a logarithmic approach as described earlier and you're down even more
14:23 < belcher> an important thing worth noting... takers (i.e. what i always considered the users of the app, people who want privacy) will never suffer from this long sync time, only makers (i.e. people who i consider service providers), i assume makers generally start up their bots once and then leave them running for weeks
14:23 < undeath> yeah, probably even months to years
14:23 < belcher> i know some people disagree with me on that which is why they work on adding yield generators to the GUI app, i suppose this issue also gets at the heart of that
14:24 < undeath> with fbs it will be considerably harder for casual users to run a maker
14:24 < belcher> the problem the logarithmic approach needs to know a starttime somehow?
14:24 < undeath> now() ?
14:25 < undeath> it's only about the addresses in the future
14:25 < belcher> that seems wrong? now() will change as time goes forward, so there'll be different behaviour if you recover a wallet today or in the future
14:26 < belcher> and for past times you have to import addresses monthly again dont you? so if you wait long enough it all becomes linear against instead of log
14:27 < undeath> yes, nothing changes for past dates
14:27 < undeath> if you start jm now it will show you addresses for august 21 to july 21 and more addresses in the farther future with less granuality
14:28 < undeath> if you start in a few months it'll show you oct 21 to sep 22 and more addresses with fine granuality
14:28 < undeath> *july 22
14:29 < belcher> how would the method gettimelockaddress work in that case, since it asks for a year-month
14:29 < belcher> i suppose it could return an error if the user puts an out-of-bound month
14:29 < undeath> yeah, and suggest to round up/down to next january 1st or so
14:29 < belcher> but then as time moves forward previous invalid times now become valid, thats confusing
14:29 < belcher> oh right rounding
14:30 < undeath> it's not so much about becoming valid/innvalid and more about being made available to the user
14:31 < belcher> right yes
14:31 <+JoinMarketRelay> [hackint/JoinMarketChannelsBridgedRelays] [darkscience/k​GYjeVk^CehgGPYd] thats confusing for me too :/
14:32 < belcher> ill sleep on it, the idea of the addresses being scanned for changing as time goes on is weird/feels dangerous (even if im sure it can be made not-dangerous)
14:32 < belcher> the idea of using a new pubkey for each locktime is great and ill definitely do that
14:32 < undeath> yep, i see your point about #1
14:34 < undeath> not sure if it'll actually cause much confusion for users who will use the functionality
14:35 < undeath> i think of it as a "pick what you like best from these options i provide: xxx"
14:38 < belcher> another reason i dont really want to do it is i think it would be a lot of coding work for not that much benefit
14:38 < belcher> especially because of the point of "takers wont need this, only makers who will only do it rarely"
14:39 < undeath> true
14:56 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
14:59 < belcher> posted a comment on the PR about the idea
14:59 < belcher> waxwing has a good point that the whole PR is basically done and that they'll always be more stuff to add
15:43 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 244 seconds]
15:44 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #joinmarket
17:22 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
17:24 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
21:56 < technonerd> ImportError: Error loading shared library libffi.so.6: No such file or directory
21:56 < technonerd> i tried to build on alpine
21:57 < technonerd> ls -l /usr/lib/libffi.so
21:57 < technonerd> libffi.so        libffi.so.7      libffi.so.7.1.0
--- Log closed Thu Jul 08 00:00:00 2021