--- Log opened Wed Aug 04 00:00:28 2021
00:21 < waxwing> belcher, should we maybe disadvise people from long lock times? what happens if anything needs to change in Joinmarket? my only concern is that people aren't considering that in their calculation of lockup times.
00:21 < waxwing> it's a bit #reckless to immediately start using timescales of 6months+ with a feature that's literally just been released. i mean it's only lock, not loss, but as we know, time is money :)
00:27 < belcher> fidelity-bonds.md already has some warnings against long lock times
00:29 < belcher> it is a bit reckless but i bet they'll do it anyway, some of them
00:30 < waxwing> well there's the anchoring effect: the example you gave is Jan 2025 :)
00:30 < belcher> hmm yes
00:30 < waxwing> i think also we have a different general sense of it. you recommend 6mnths to 2 years there, i had in mind at least for the first few months/year to only use timescales of months.
00:31 < belcher> the thing is, the default interest rate is 1.5% and over 6 months that isnt very much
00:31 < waxwing> i think if it got bedded down then going out longer starts to make more sense to me personally.
00:31 < waxwing> but for sure in incentive systems you have to face the reality that people like to take risk to get a positive outcome.
00:32 < waxwing> it's like a societal ill, almost. example: in China it is *extremely* common for people to invest in risky, 10%+ yielding financial products, and then to organize protests and petitions to the local government when it blows up.
00:32 < belcher> haha
00:32 < waxwing> people tend to think they should take more, not less risk because of this background "someone else will take responsibility", and maybe unconsciously this carries over into the bitcoin world.
00:33 < belcher> well if they do that on this channel ill just /ignore and say they knew what they were getting into
00:33 < waxwing> like if they thought about it consciously they know no one is coming to save them.
00:33 < belcher> but yes ok maybe spelling out some possible risks is worth it
00:33 < belcher> adding to fidelity-bond.md or something
00:33 < waxwing> i mean you could just tweet something about #reckless or whatever :)
00:34 < waxwing> there's only so much one can influence, people will, as you say, do whatever they feel like in the end.
00:34 < waxwing> just like in Lightning all the stuff about #reckless didn't really change much.
00:34 < belcher> yeah
00:34 < belcher> what kind of things actually could go wrong
00:35 < belcher> the locktime redeemscripts are quite simple, whatever happens the user will definitely get their money back after the locktime
00:35 < waxwing> i was mostly worried about something unanticipated meaning we wanted to change the protocol, but couldn't.
00:35 < waxwing> because tons of people have like $100M locked up
00:35 < belcher> we could still change the protocol if we need to
00:35 < waxwing> i mean we could but, sheesh
00:36 <+JoinMarketRelay> [hackint/kristapsk] xyy, i've done some testing of I2P IRC (Irc2P) with JM, there were problems, haven't got back to it
00:36 < belcher> iv always imagined the whole joinmarket thing as doing whats in the best interests of users who want privacy, if it turns out users who want to generate yield forgo a bit of income then thats their risk
00:37 < belcher> i remember someone on the telegram group a few days ago saying "with fidelity bonds people who have the most bitcoins will earn the most yield, is what the world we want to live in?!", to that my reply was "well yes as long as privacy is improved"
00:38 < waxwing> do they want people to provide a passport as an anti-Sybil mechanism?
00:38 < belcher> :p
00:38 < waxwing> huh that reminds me of Hearn's "proof of passport" little incident
00:39 < belcher> i just saw now we have 14 fidelity bonds, and the "sybil resistance from enemies within" table show the probability of success nicely below 50%
00:39 < belcher> as more get added the success probability should drop further
00:40 < waxwing> technically the non-FB version of Joinmarket is still, and will continue to run indefinitely. if people prefer it, they can still use it.
00:40 < waxwing> so that's nice.
00:40 < belcher> yep, and if they upgrade they can use the command line flag -R to go back to the non-FB version
00:41 < belcher> also someone on telegram suggested setting bondless_maker_allowance = 1 which should do the same thing
00:41 < belcher> however that would be strange.... you'd think takers would want sybil protection... and if they think the requested fees are too high they can lower their max fee values
00:42 < belcher> i dont see a reason for not using fidelity bonds as a taker *shrug*
01:02 -!- belcher [~belcher@user/belcher] has quit [Remote host closed the connection]
01:06 -!- belcher [~belcher@user/belcher] has joined #joinmarket
01:18 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer]
01:25 -!- belcher [~belcher@user/belcher] has joined #joinmarket
02:05 < waxwing> undeath belcher kristapsk turns out the whole discussion from before about how to spend these in coinjoins is pointless; we absolutely can't do that today: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/957#issuecomment-892486730
02:06 < waxwing> i'm willing to believe that some fancy footwork allows it in a backwards compatible way (i.e. not screwing up the existing !sig message format), but i haven't much inclination to do that, at least not now. maybe someone else does.
02:08 < waxwing> well, i should qualify: spending them in *taker* side coinjoins should be fine, once we address the related PoDLE issue.
02:28 < belcher> yes good find
02:28 < belcher> always interesting to see how protocols last for so long, that joinmarket protocol is the same one as in 2014
02:28 < belcher> btw back around then i remember trying out spending a multisig utxo on the taker side, so that should still work for sure
02:28 < belcher> or at least the protocol shouldnt stop it
02:41 -!- undeath [~undeath@user/undeath] has joined #joinmarket
03:42 < waxwing> there was somewhat of a change to the !sig message when segwit was introduced, but it was "fancy footwork" as mentioned above, to keep it backwards compatible.
03:42 < waxwing> and then something similar when we moved to native.
03:43 < waxwing> but those were different: we had a new offer type so both sides knew to interpret the message differently
03:43 < waxwing> i'm not sure we can do the same here. taker side def will work but there will be like a few extra checks in there to avoid using these utxos as podles.
03:44 < waxwing> i just feel bad not to have immediately noticed this before undeath started that PR
03:44 < undeath> I saw your comment, no worries
03:45 < undeath> we can still merge it, it just won't be of much use for now
03:50 < undeath> but it'll need some more code to make sure we don't spend timelocked utxos in cjs
03:52 < waxwing> yeah the original pessimistic idea "just auto-freeze TL-UTXOs on yg startup" seems good to me?
03:52 < waxwing> oh hang on freeze persists in the wallet right. that's slightly non-optimal.
03:52 < undeath> oh yes, that would be easy
03:52 < undeath> yes
03:52 < waxwing> i mean if that's the best way then we could remember and unfreeze on exit perhaps?
03:52 < undeath> otherwise it'll need a flag for UTXOManager.select_utxos() i think
03:53 < undeath> which needs to be passed all the way down
03:53 < waxwing> right. irksome.
03:55 < waxwing> (you know, here is one very easy win for users: warning-level log messages *whenever* utxo selection is called on a mixdepth with frozen utxos. at least gives them a clue when they're surprised a transaction doesn't work)
03:55 < waxwing> that's just a general comment, not specific to this
03:57 < undeath> a kinde easy way to implement this would be a select_utxos_cj() in BaseWallet that will, for fb wallets, add timelocked utxos to utxo_filter
03:57 < waxwing> oh, the filter. yes i suppose.
03:58 < undeath> but this will still cause problems with selecting the correct mixdepth
03:58 < waxwing> you don't like freezing?
03:58 < waxwing> because of the persistence i presume
03:58 < undeath> it's a bit of a hack, exactly
03:58 < undeath> if the yg crashes users might be confused when their timelocked addresses end up locked
03:58 < waxwing> yeah i thought of that, then i thought that's a negative outcome we can handle.
03:59 < waxwing> and that prompted my comment about warnings.
03:59 < undeath> otoh, just print a warning on startup saying they have been autolocked and move on
03:59 < undeath> seems reasonable to me
03:59 < waxwing> reasonable and low-brain-intensity, these are my favourite :)
03:59 < undeath> :)
04:01 < waxwing> kristapsk i am very tempted to merge #938 since i went through the delta and tried out an installation last week.
04:01 < waxwing> on balance i think we should merge, we could wait post-0.9.1 but then it might be months.
04:01 < undeath> what exactly happens when a fb expires while a yg is running?
04:01 < waxwing> it's still valid post-expiration
04:02 < undeath> will the wallet immediately try to spend it?
04:02 < undeath> oh, it's locked, isn't it?
04:02 < waxwing> the value falls off. i also forgot this. oh, you mean spending. yeah i believe so, the event isn't recognized in the wallet service, it only listens for transactions not time-based events.
04:03 < waxwing> yeah it's frozen on creation and i think auto-unfrozen on any startup where it's beyond the locktime. but i forget that exact logic.
04:18 < undeath> do you happen to know where this autofreezing is happening? i can't find the code
04:18 < waxwing> undeath, see sync_unspent->add_utxo
04:18 < waxwing> and then the fidelity bond version of add_utxo
04:19 < waxwing> actually `add_unspent_txo` is the name in wallet_service /sync_unspent
04:19 <+JoinMarketRelay> [hackint/kristapsk] waxwing, I have no objections to merging #938
04:19 < waxwing> should be around line 2268 in wallet.py
04:19 < waxwing> kristapsk ok then.
04:20 < undeath> thanks
04:22 < waxwing> amusingly you couldn't just remove the time check in that function, as then you'd *never* be able to spend it in any script.
04:24 < undeath> it might make sense to also prevent timeunlocked utxos from being spent by a taker in a cj
04:25 < undeath> if a maker cannot spend them it's obvious it must be a taker input otherwise
04:26 < waxwing> yeah
04:26 < waxwing> we can't do it yet, so it's debatable if we should as you say
04:26 < waxwing> but we mustn't accidentally prevent spending in a non-coinjoin :)
04:27 < JMBridge> [agora/coinjoin] What?
04:27 < JMBridge> [agora/coinjoin] No JM users should even like to try non-coinjoin tx
04:34 < undeath> but then, the case is not much different from adding external funds to joinmarket and doing an initial cj
04:44 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 244 seconds]
04:44 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #joinmarket
04:49 < waxwing> true
04:50 < waxwing> coinjoin: re your comment, there will always be cases where people want to spend without counterparties, that ability can't be removed. and in this special case it's particularly important that that ability exists (since spending timelocked outputs in a coinjoin is problematic).
04:54 < JMBridge> [agora/coinjoin] Ok, seem to need to read up the whole conversation to see the problematic, just got triggered by my maybe bad nickname choice in here. still wondering if the fb pubkey could make a maker more distinct identity than previously without.
04:56 < JMBridge> [agora/coinjoin] Example, maker user uses yg-enchancedprivacy.py, between restarts I may not know it could be the same individual, because the randomisation taken place of parameters bounds. but now he will continue to remain the same pseudonimity user with always the same fb key published until unlocked.
04:58 < JMBridge> [agora/coinjoin] Don't talking about not the actual fb utxo in the latter
06:06 < waxwing> i agree re: restarts. it's the reason i was interested in proposing this: https://gist.github.com/AdamISZ/52aa2e4e48240dfbadebb316507d0749
06:07 < waxwing> a couple of notable points about that are (a) it could generalize to not only joinmarket (b) there are a ton of tricky details that weren't fleshed out and (c) it should be easier in taproot (pubkeys are public immediately)
06:09 < waxwing> related: #960
07:05 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
07:52 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Ping timeout: 244 seconds]
08:00 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
11:51 -!- technonerd [~techno@user/technonerd] has quit [Ping timeout: 244 seconds]
12:04 -!- technonerd [~techno@user/technonerd] has joined #joinmarket
13:13 -!- gene [~gene@gateway/tor-sasl/gene] has joined #joinmarket
13:17 < waxwing> belcher, my last comment in that PR is wrong, i need to go back and check things before changing it
13:48 < waxwing> fixed up.
14:13 -!- gene_ [~gene@2a0a:3840:1337:127:0:b9c1:7fec:1337] has joined #joinmarket
14:13 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
14:14 -!- gene_ is now known as gene
14:16 -!- takinbo [~takinbo@user/takinbo] has quit [Quit: No Ping reply in 180 seconds.]
14:17 -!- takinbo [~takinbo@user/takinbo] has joined #joinmarket
15:36 -!- davterra [~davterra@143.198.56.186] has quit [Remote host closed the connection]
16:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 244 seconds]
18:14 -!- davterra [~davterra@143.198.56.186] has joined #joinmarket
19:25 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
19:28 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
--- Log closed Thu Aug 05 00:00:29 2021