--- Log opened Wed Sep 08 00:00:01 2021
00:09 < openoms[m]> thanks waxwing . Would this worth a discussion to be a configurable option like the YG fee randomizations?
00:12 < waxwing> yes. the argument for having it not configurable is 'protect people and don't load them cognitively', but the counterargument is perfectly reasonable. should be a trivial PR i think.
01:43 < openoms[m]> recorded in the issue as no time for a PR just yet: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1009
01:47 < openoms[m]> my other question would about funding multiple channels the same way which would require multiple recipients and same exact amounts.
01:47 < openoms[m]> Batch channel opens do hurt the LN privacy (by revealing which peer funded the channels) and funding multiple addresses like that might be out of scope of JM development for now. What do you think?
01:47 < openoms[m]> I am thinking of Electrum or Specter where one just needs to paste the list of
01:47 < openoms[m]> addresses followed by the amounts
01:48 < openoms[m]> and the PSBT signing does already work for these transactions constructed outside of JM, but from the JM wallet
01:49 -!- jonatack [~jonatack@user/jonatack] has joined #joinmarket
01:50 < openoms[m]> * by "same exact amounts" I mean needing defined amounts before knowing the recipient addresses, not equal amounts.
01:59 < waxwing> openoms[m], interesting. by 'already does work' are you referring to a workflow of: create psbt outside of JM with more than one output address, but using some JM inputs ..?
01:59 < waxwing> no wait hang on, i thought we could only create, not sign from external
02:00 < openoms[m]> waxwing: yes, that is the workflow opening muliple channels from a JM UTXO using Electrum or Specter
02:00 < openoms[m]> but would be nice to be able to do it from JM without importing watch-only wallets elsewhere
02:01 < waxwing> so you're just saying, you do the creation and signing outside of JM, the only connection to JM is that the utxo comes from there?
02:02 < waxwing> i don't know what to say re: multiple destinations and amounts, i mean obviously it can be done, and i can certainly see the desire for it. a likely starting point is simply a PR against jmclient.taker_utils.direct_send to accept multiple destinations and amounts.
02:02 < openoms[m]> depends I can just export the individual coin private key to Electrum and do everything there
02:02 < openoms[m]> or import the seed to Electrum/Specter
02:02 < openoms[m]> but mostly I am just using Specter as watch-only and sign the PSBT with the wallet-tool
02:03 < waxwing> oh there's a signpsbt right? i knew i was forgetting something :)
02:03 < waxwing> so much code i forgot that i wrote it :)
02:03 < openoms[m]> yes, very useful!
02:03 < waxwing> yes very dangerous^H^H useful ;)
02:04 < openoms[m]> feels much safer than throwing around the private keys
02:05 < openoms[m]> and there is a check before broadcasting too with LND
02:05 < waxwing> good point! yeah the joke is just because it has a "sign anything i can" logic which always worries me.
02:05 < waxwing> yeah was going to say, the "signresult" object from python-bitcointx is useful in this regard, because it tells you how many signings were done.
02:06 < waxwing> although huh, i just noticed, we only output the 'signresult' thing if we don't *fully* sign the transaction, which is probably not best.
02:07 < waxwing> but another point is that the PSBT code needs a lot of extra attention. not only because there have been some changes in BIP174, but even more important: we can't currently support *any* non standard inputs in the PSBT.
02:07 < waxwing> which is kinda stupid, that's one of the biggest advantages.
02:07 < waxwing> or at least for sure we can't support signing them, like our timelocked outputs.
02:10 < openoms[m]> a last thing for this usecase is the firm choice to not broadcast the transaction after signing - since it needs to be passed to the LN client
02:10 < openoms[m]> it works great with the --psbt flag with sendpayment.py , but it is counterintuitive in the QT - one needs to choose to "not accept" the transaction and scroll up for the hex output..
02:11 < waxwing> i see. yes we have not considered that use case in Qt
02:11 < openoms[m]> I might just open two more issues for these as it can be useful for others too
02:12 < waxwing> sure
02:12 < openoms[m]> well the QT came well before the LN funding usecases :)
02:13 < openoms[m]> it is just so much fast to use the wight-click multiple freeze-unfreeze for coin control than the wallet-tool freeze method
02:13 < waxwing> yes i noticed that as well after implementing the Coins tab. it's a huge advantage of the graphical UI.
02:14 < waxwing> i suppose we could make the CLI version better, but still.
02:14 < openoms[m]> the ideal would be point and click (tick) UTXO selection as in Electrum, but the right click freeze/unfeeze is workable
02:14 < waxwing> oh true. 1 click instead of 2 is better.
02:14 < waxwing> also the format of that tab is terrible but i have no time to make it look nicer, maybe someone else will.
02:15 < openoms[m]> right, worth a mention then, there are many UX people lurking around someone might pick it up
02:16 < openoms[m]> (ok not so many, bu tcan be added to the "what I can do for joinmarket" list)
02:16 < waxwing> wukong's initiative to use QtDesigner may cover that at some point.
02:19 < openoms[m]> sounds good, is that a discussion somewhere already?
02:21 < waxwing> openoms[m], see #932
02:22 < waxwing> oh he's updated the name, i think i can even merge that now. do give it a try.
02:25 -!- belcher_ is now known as belcher
06:50 < waxwing> belcher, https://github.com/JoinMarket-Org/joinmarket-clientserver/blame/cdd1a77d8553e9330c130d763da89f550ef96216/jmclient/jmclient/wallet_utils.py#L523
06:51 < waxwing> iteritems is a py2 thing, this seems to crash in our rpc-api-2 testing but haven't investigated in detail yet
06:51 < belcher> ok, thats weird since iv been using py3 for ages, certainly when this code was written
06:52 < belcher> i wonder where i got iteritems() from, my instinct is to use dict.items()
06:52 < waxwing> yeah. often happens when you're moving code around from old versions, though.
07:04 < belcher> oh yes could be that
08:29 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
09:48 -!- jonatack [~jonatack@user/jonatack] has joined #joinmarket
11:22 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
12:54 -!- jonatack [~jonatack@user/jonatack] has joined #joinmarket
15:15 -!- gene [~gene@gateway/tor-sasl/gene] has joined #joinmarket
16:59 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
17:13 -!- jonatack [~jonatack@user/jonatack] has joined #joinmarket
17:20 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:33 -!- belcher [~belcher@user/belcher] has joined #joinmarket
19:11 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
--- Log closed Thu Sep 09 00:00:02 2021