--- Day changed Sun Apr 15 2018
00:04 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
01:59 -!- Lairem [~User@unaffiliated/lairem] has left #joinmarket []     
03:02 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 264 seconds]     
03:07 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 260 seconds]     
03:38 -!- MaxSan [~user@86.105.9.67] has joined #joinmarket     
03:45 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket     
04:04 -!- MaxSan1 [~user@105.185.226.97] has joined #joinmarket     
04:06 -!- MaxSan [~user@86.105.9.67] has quit [Ping timeout: 260 seconds]     
04:53 -!- bsm117532 [~mcelrath@173-9-124-61-NewEngland.hfc.comcastbusiness.net] has quit [Killed (barjavel.freenode.net (Nickname regained by services))]     
05:06 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
05:08 -!- MaxSan1 [~user@105.185.226.97] has quit [Ping timeout: 260 seconds]     
05:26 -!- MaxSan [~user@105.185.226.97] has joined #joinmarket     
06:36 < waxwing> huh, this is weird, in regtest (0.16) i can call importaddress address wallet-name false as many times as I like (changing `wallet-name` each time) and it never errors.
06:40 < waxwing> yes, all the behaviour i'm seeing is consistent with the idea that `importaddress` always works (i.e. if add is in acc1 and i call importaddress into acc2, it follows the instruction without complaint. including default acct ""
06:40 < waxwing> what am i missing? can't be difference between regtest and main surely
06:41 < waxwing> wumpus, ping, ^ , should i expect this error is different between rpc and command line? (that seems unlikely). it's this error in RPC: https://github.com/bitcoin/bitcoin/blob/5f2a39946fd42535038e0143cbd289d3070b9f07/src/wallet/rpcdump.cpp#L217
07:06 < waxwing> oh, see what i'm missing, this is about importing *keys* (i.e. privkeys), not addresses
07:38 < waxwing> sanity check: is it sensible to advise a user who encounters this error condition, to use a new Bitcoin Core wallet file? (say before there is multiwallet support)
07:38 < waxwing> seems like a new Core wallet or a new JM wallet are the most sensible ways to "wipe the slate clean" here.
07:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket     
08:04 -!- GitHub80 [GitHub80@gateway/service/github.com/x-sgtjgyfgtohozleh] has joined #joinmarket     
08:04 < GitHub80> [joinmarket-clientserver] AdamISZ force-pushed master from 1f8e004 to 20e8bf6: https://git.io/v5bgz
08:04 < GitHub80> joinmarket-clientserver/master 20e8bf6 AdamISZ: Give user feedback when importaddress fails due to conflict with Core wallet....
08:04 -!- GitHub80 [GitHub80@gateway/service/github.com/x-sgtjgyfgtohozleh] has left #joinmarket []     
08:05 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
09:00 -!- MaxSan [~user@105.185.226.97] has quit [Ping timeout: 268 seconds]     
09:36 < arubi> personally I think it's safe to just ignore that error and continue importing.  If the user didn't import the key and purposely used it with a different address than what jm expects (imported from jm's p2sh-p2wpkh wallet and used as p2wpkh, p2pkh or some other exotic script), then it will be caught as used up when listing transactions by address is done.  maybe just output an info line to the log saying that this event happened or something..
09:37 < arubi> basically it seems to me that folks import privkeys from jm's wallet so they can spend already existing inputs that were sent to them in a coinjoin..  anything else would be pretty weird
09:37 < arubi> s/user didn't import the/user imported the key/ 
10:14 < waxwing> arubi, yes i'm not sure but think better to err on safety side. i imagined a case where someone batch-imports all the keys from a wallet. then tries to reload the JM wallet. JM wallet can't see that the addresses are owned (if this rpc error ignored), then treats them as new/unused. then tries to use them, reuses then perhaps other errors occur.
10:15 < waxwing> i wasn't thinking so much of the case of using them in a different address type (that seems unlikely relative to the more likely, using as same address type)
10:23 < arubi> I see, I was gonna suggest running a getaccount on an address before import but if it was imported to the "" account then getaccount will just return nothing (it will return the account name if there was an actual account set).  with the new getaddressinfo command it will return the "" label
10:25 < waxwing> would you give different advice to a user in this position? is the suggestion to swap out a new Core wallet sensible as far as you know? iiuc it basically means you'd need to rescan.
10:25 < waxwing> i just basically don't want to have the code automatically do anything that *could* be unsafe. if it's very inconvenient this way, i'd rather the user just deal with the inconvenience than take a risk.
10:26 < arubi> new wallet in what sense though?
10:27 < waxwing> i mean just new wallet.dat (i'm ignoring multiwallet for now, although from what you said that's a/the solution)
10:27 < arubi> I'm basically thinking about folks using the wallet for both jm and their actual personal wallet
10:28 < waxwing> yeah. it's fine if they do that, but if they start moving control of addresses between the two, we get this situation, which is nasty. JM's logic assumes control of the HD tree.
10:28 < arubi> it would mean new keys, new backups, losing labels or notes they already set in the wallet..  pretty big move
10:29 < waxwing> well; but they could keep the old wallet.dat and just use the new one for JM? but i dunno, the more i think about it, the more it's just annoying. i always avoided this issue since I never used Core as a wallet, so i'm probably the wrong one to look into it.
10:30 < waxwing> i think there's another edge case where people do a sweep from JM into their Core wallet; importaddress fail can happen there too. oh, damn, if i'm remembering that right, i def. have to revert that commit ...
10:31 < arubi> sweeping means sending the balance though?  or actually importing the keys?
10:31 < waxwing> oh yes, that was dumb. can't have it just exit during running.
10:32 < waxwing> well on that: sweeping means there's no change, meaning you have to watch the destination address which is not inside JM, but you can't import that into a custom acct/label if it's already in the default.
10:33 < waxwing> although the sender watches a txid not an address; i seem to have forgotten the exact circs of this corner case, but it exists.
10:35 < arubi> watching a txid has its own edge cases, like if someone rbf's.  yea basically multiwallet + labels (which can be changed it seems) would pretty much make this all much cleaner..
10:37 < arubi> import a key, run bumpfee or whatever..
10:38 < waxwing> dumb Q, but i've never coded rbf, does it require re-signing i presume? oh yeah it'd have to :)
10:38 < arubi> yep :)
10:38 < waxwing> so that wouldn't be an issue unless we added it into the code
10:38 < arubi> well unless they have one of the keys imported to core and run bumpfee from there
10:39 < arubi> but again, major edge case
10:49 < waxwing> hmm ok that sys.exit is only on initial sync, so no need to cancel it. will add a note though.
10:57 < waxwing> arubi, good point. failure of notification to pick up the tx changing state is not a funds loss risk, so that's something.
11:01 < arubi> it's pretty much always been a no-no, tracking txids
11:03 < arubi> not of an issue for coinjoins specifically as you'll need everyone's signature to change it
11:07 -!- GitHub114 [GitHub114@gateway/service/github.com/x-qzfnnsaggfcdjfwy] has joined #joinmarket     
11:07 < GitHub114> [joinmarket-clientserver] AdamISZ pushed 1 new commit to master: https://git.io/vpvkD
11:07 < GitHub114> joinmarket-clientserver/master 89ba10e AdamISZ: Add warning for during-run import of address under control of Core....
11:07 -!- GitHub114 [GitHub114@gateway/service/github.com/x-qzfnnsaggfcdjfwy] has left #joinmarket []     
11:07 < waxwing> arubi, it's not a no-no with segwit .. you need it for stuff like coinswap.
11:08 < arubi> even with segwit, rbf will change the txid
11:08 < waxwing> but your rbf point, that's good. it's kind of a decision i guess depending on protocol/app; in some cases watching txid might be desirable for its simplicity or even necessary, in others, you shouldn't.
11:08 < arubi> for these kinds of more advanced protocols - yea, you have to rely on the txid for the signatures
11:08 < waxwing> arubi, yes i know. that's what i was trying to say, is that it becomes a question.
11:09 < waxwing> whereas pre-segwit, it wasn't even a question, you couldn't do it.
11:10 < arubi> right
11:19 < waxwing> oh arubi thought you might like to answer this: https://news.ycombinator.com/item?id=16843633 :)
11:20 < arubi> haha, can you comment without an HN account? :)
11:20 < waxwing> prob not, i've never tried
11:20 < arubi> nope :(
11:26 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket     
12:14 < belcher_> for my yieldgen, these last few days with the price spike coincided with many more coinjoins
12:14 < belcher_> iv seen this pattern before, some bull runs correlated with coinjoins, some dont
14:16 < AgoraRelay> [agora-irc/AlexCato] heya everyone. Been reading the chat of the last few days now, and regarding waxwing's questions what I'd do UI-wise for the problem with the already importet addresses:
14:17 < AgoraRelay> [agora-irc/AlexCato] in general, I'd just give a useful error message if its something that can be easily fixed by the user himself (and really hard to fix in the program)
14:17 < AgoraRelay> [agora-irc/AlexCato] on this particular error, I'm not sure I entirely understand it yet. If an already imported address is the problem, why would clearing my JM wallet cache fix the problem?
14:20 < AgoraRelay> [agora-irc/AlexCato] if automatically fixing the problem by moving the address/key from the core wallet to the jm-label in core could potentially break the user's other wallet... I'd not do that and go with the error message route for sure
14:21 < AgoraRelay> [agora-irc/AlexCato] but as I do not totally understand it yet, do not listen to me about this particular issue for now.
14:25 < AgoraRelay> [agora-irc/ben] hello
14:25 < AgoraRelay> [agora-irc/AlexCato] hi
14:29 < AgoraRelay> [agora-irc/ben] how everybody today
14:34 < AgoraRelay> [agora-irc/belcher] thinking about improving bitcoin fungibility, as usual :)
14:48 -!- Jeromy21Pollich [~Jeromy21P@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 264 seconds]     
15:00 < AgoraRelay> [agora-irc/whisky] Did anyone make a wallet which tries to mix coins by default, and warns you if it isn't done?
15:02 < AgoraRelay> [agora-irc/belcher] there's an electrum plugin that creates coinjoins
15:07 < AgoraRelay> [agora-irc/whisky] I think fungibility would improve if more people were mixing passively. Just depends on if the fees aren't prohibitavely high.
15:16 -!- viasil [~viasil@185.212.171.206] has quit [Ping timeout: 256 seconds]     
15:25 -!- viasil [~viasil@185.212.171.206] has joined #joinmarket     
17:17 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
19:37 -!- MaxSan [~user@91.207.102.163] has joined #joinmarket     
20:18 -!- AgoraRelay [~jmrelayfn@p5486603E.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]     
20:36 -!- AgoraRelay [~jmrelayfn@p5DE4A529.dip0.t-ipconnect.de] has joined #joinmarket     
20:53 -!- Lairem [~User@unaffiliated/lairem] has joined #joinmarket     
21:15 < Lairem> how can we specify a fee when using sendpayment.py?
21:15 < Lairem> what flag should be used?
21:49 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 264 seconds]     
21:57 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
22:43 < AgoraRelay> [agora-irc/AlexCato] Lairem: its in the joinmarket.cfg, tx_fees=XXX
22:44 < AgoraRelay> [agora-irc/AlexCato] values 1-25=fee estimation of bitcoin core is used (1 = next block, 25 = next 25 blocks). Anything >144 is the fee/KB in satoshis
22:50 < Lairem> cool! thx
22:50 < AgoraRelay> [agora-irc/AlexCato] after looking at the current mempool, i'd set tx_fees=1500 for now, if it was my transaction
22:55 < Lairem> tx_fees = 145 should go thorugh aswell
22:57 < Lairem> no hurry tbh