--- Day changed Tue Sep 26 2017
00:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
00:10 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
00:16 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket     
00:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
00:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
00:51 < trotski2000> hi guys
00:51 < trotski2000> is there a way to remove a watch-only address from Core?
00:51 < trotski2000> joinmarket imported an external address as an internal one and now Core is showing an incorrect balance
00:53 < waxwing> good question, don't know. did you pay to your JM wallet from the same Core wallet instance?
00:53 < waxwing> belcher, i read the backscroll but i can't figure out what plan you're referring to
00:55 < trotski2000> waxwing: yes. This already happened in the past and we already discovered why this happens - normally if I make a transaction and empty the destination (external) address the balance shows up correctly, but this time I cannot make a tx from that addy
00:56 < trotski2000> see: [2017-07-19 12:46:47] <waxwing> yes i can see the complete logic now. (1) a sweep to an external destination means there are no joinmarket wallet outputs, (2) so we import that address to check when the transaction has occurred (c) Core thinks that therefore the funds are in that account - because, well, they are, because we imported that address to the account.
00:56 < trotski2000> [2017-07-19 12:47:13] <waxwing> there's a code comment somewhere to that effect 'we should really import this into a separate account but it's simpler not to'.
01:10 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 240 seconds]     
01:11 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
01:54 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 248 seconds]     
02:08 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket     
02:27 -!- MaxSan [~one@213.152.161.85] has joined #joinmarket     
02:44 -!- MaxSan [~one@213.152.161.85] has quit [Ping timeout: 264 seconds]     
02:47 -!- MaxSan [~one@213.152.161.85] has joined #joinmarket     
03:47 < belcher> waxwing should we promote joinmarket-clientserver more so that the liquidity isnt split in two
03:47 < belcher> iv never found a way to remove watch-only addresses trotski2000 
03:48 < belcher> except by creating a new wallet.dat and importing everything except that address
03:48 < trotski2000> belcher: which one is more liquid? clientserver or the other one?
03:48 < belcher> hard to say
03:50 < waxwing> go home J54By9EtbtZ7WG82 you're drunk
03:50 < waxwing> on topic (of split), no strong feelings about it to be honest.
04:07 -!- MaxSan [~one@213.152.161.85] has quit [Ping timeout: 260 seconds]     
05:04 < GitHub12> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/vdLrI
05:04 < GitHub12> joinmarket-clientserver/master 1da304f Daniel McNally: Update INSTALL.md...
05:04 < GitHub12> joinmarket-clientserver/master c046888 AdamISZ: Merge #92: Update INSTALL.md...
05:04 < GitHub133> [joinmarket-clientserver] AdamISZ closed pull request #92: Update INSTALL.md (master...patch-1) https://git.io/vdkbv
05:16 < belcher> are there any downsides to promoting joinmarket-clientserver to everyone?
05:16 < belcher> i think i heard its harder to install on windows?
05:18 < waxwing> belcher, i'm not sure how possible it is.
05:18 < belcher> possible in what sense?
05:18 < waxwing> i haven't tried to do the command line install.
05:18 < belcher> oh installing on windows
05:18 < waxwing> the first thought is that it requires twisted, which is a pretty meaty python package with a lot of dependencies.
05:18 < waxwing> if you can install twisted, my guess is it should probably work as well as the previous one.
05:19 < waxwing> i.e. the process should be more or less the same.
05:19 < waxwing> well, hmm, i'm pretty sure it's possible, i must have done it myself to build the binary :)
05:20 < waxwing> i'll try to rebuild for the latest version in a couple of weeks.
05:20 < belcher> ok     
05:20 < belcher> apart from the windows thing, is there anything else?
05:21 < waxwing> (but i only tried for windows 7, in the past people have said that things worked ok on windows 10, but who knows)
05:21 < waxwing> i understand the motivation of this line of thinking, i just don't really have an answer; it's there, it's *arguably* better (at least because of segwit), but not everyone wants to use p2sh segwit addresses right now anyway, so, shrug.
05:23 < belcher> joinmarket is harmed by having the liquidity split
05:23 < waxwing> i was thinking about it earlier this morning belcher, consider the single join case: if you send to a '1' address and all other outputs are '3', it's strictly worse than if all are '3', because while it's *usually* obvious which cjout is from the taker, it is not categorical proof - it could have been a maker that spent an output early in another arbitrary-kind-of-transaction from their jm wallet. whereas if it's a '1' address it *cannot* belong 
05:23 < waxwing> a Maker in our software.
05:23 < belcher> not harmed very much admittedly, but still a bit
05:24 < belcher> right but one coinjoin doesnt provide much privacy anyway, even if all outputs were 3 addresses
05:24 < belcher> privacy is gained when theres many coinjoins
05:24 < waxwing> yes, it doesn't in itself, but it's helpful for the overall system (i mean both joinmarket, and bitcoin)
05:24 < belcher> in that situation if the last coinjoin has a mixture of 1 and 3 its still fine
05:27 < waxwing> i preferred to complete what i considered the most realistic task in good time, and i had hoped that the overall bitcoin "market" would have moved to '3' addresses fast. in that scenario it seemed far better to have it available and people could switch in line with that. other software has been much slower than i expected to adopt.
05:27 < belcher> id say it doesnt matter, joinmarket coinjoins are already mostly visible
05:28 -!- MaxSan [~one@185.156.175.43] has joined #joinmarket     
05:29 < waxwing> i have a suspicion that people wouldn't actually like to use it with unpredictable mixtures of address types. it's another variable they can't easily assess that they also can't control.
05:31 < belcher> the only mixture of address types is when a taker sends to a 1 address ?
05:31 < waxwing> yes, right now, i was talking about the suggestion of not having it like that.
05:31 < waxwing> that scenario is something the Taker  controls, if they want to do that, it's up to them.
05:32 < belcher> you mean where its reprogrammed to have both 1 and 3 addresses ? i was thinking of the situation where all makers use segwit addresses
05:33 -!- MaxSan [~one@185.156.175.43] has quit [Ping timeout: 252 seconds]     
05:34 < waxwing> i guess i'm not sure which particular thing you're suggesting as an alternative to what we have now; i just know at this point you're mainly concerned about the liquidity split
05:35 < waxwing> i thought simpler was probably better. tbh i always just assumed we'd have to do it, mixed address types just seemed too difficult to analyze.
05:35 < belcher> yep, im thinking to post on forums/twitter and use the alerts system to try to get more people to use the segwit code
05:35 < waxwing> but i think some people will want to use 1-only joins for a while, if their habitual destinations are also 1-
05:37 < belcher> they wont be harmed more if their destination addresses are p2pkh, because single coinjoins dont provide much privacy anyway
05:37 < belcher> also bitgo has adopted segwit, so that means bitstamp/kraken/coinbase all use it
05:38 < belcher> well actually its an option, i dont know which if any have adopted segwit
05:38 < waxwing> hmm you sure about that? i don't use those services so don't know. i get the vague impression maybe it's not the case.
05:38 < waxwing> right
05:38 < belcher> but even if they havent, it wont matter for privacy
05:38 < waxwing> i know e.g. bitpay, coinbase retail api stuff isn't using 3 addresses, last time i used them (week or two back)
05:39 < belcher> right so you're spending from your wallet there right? its a single coinjoin but your wallet is made of hundreds of coinjoins isnt it
05:39 < belcher> so bitpay/coinbase cant go backwards to see where your money came from
05:39 < waxwing> afaict it strictly shaves off one ambiguity, whether you do a large tumbler run, a single join, or a few joins.
05:39 < belcher> how?
05:39 < waxwing> in the former case, you can argue, it's almost irrelevant.
05:40 < belcher> i dont understand what you mean, can you rephrase
05:41 < waxwing> ok, but i'm referring to what i said above starting with "i was thinking about it earlier.."
05:42 < waxwing> if it's a 3, even if its *next* spend is some really weird tx type that *usually* would be e.g. an exchange, it *could* be a Maker. If it's a '1' that's not possible, that ambiguity is removed.
05:43 < belcher> id say that ambiguity never helped much anyway, you always needed multiple coinjoins to get some privacy
05:43 < waxwing> sure i get your argument. but it's a strict reduction.
05:44 < waxwing> and in an alternative approach to the current one, you have to think about stuff like that, details depending on the suggestion.
05:44 < belcher> so we have to weigh up whether that reduction is worse than splitting the orderbook in two
05:45 < waxwing> not sure there's much point discussing it at this point. someone *could* code something that allows spending both types (and decide how to manage the wallet, again i deliberately chose bip49, which trezor, ledger and samourai are apparently using too) to keep it as simple and unambiguous as possible.
05:45 < waxwing> or maybe there's some trick to do it simply, but i wouldn't have thought so.
05:46 < waxwing> ok my mistake, i guess you're only trying to argue we should push people to switch.
05:46 < belcher> yes, my suggestion doesnt involve any code
05:47 < waxwing> feel free to give it more of a push; i'm kind of agnostic about it. maybe with a push they'll go over a bit faster, but there'll for sure be stragglers :)
05:47 < belcher> interesting question, does jm-cs receive the alerts in the /topic ?
05:47 < waxwing> last time it took months and months
05:47 < waxwing> i can't remember now. i *think* i kept it in, certainly intended to.
05:47 < waxwing> will take a look
05:48 < belcher> im looking now
05:48 < waxwing> although i guess you only really need it on the other side, for this purpose :)
05:48 < belcher> looks like it does
05:48 < belcher> yep     
05:49 < belcher> although one issue might be the versions are the same, checking that now too
05:49 < waxwing> yeah it's there
05:50 < waxwing> and yes the versions are the same (the message protocol version)
05:50 < belcher> ok, so that would require making a new release with a new version so that people can make the alert disappear
05:50 < belcher> ok well ill leave it for another week to see how it goes
05:52 < waxwing> belcher, i'm going to finally read your multi-tx thing now, i got distracted by lightning for a while :)
05:53 < waxwing> i mean, read it again and this time try to get the details...
05:56 < waxwing> on the topic of liquidity split, i continue to be amazed at the guy(s) slinging 1-400 btc for joins at this like it's nothing. oh well i guess it's been long enough they feel safe-ish, but ... damn.
05:58 < belcher> its probably only 1% of their stash so they're thinking its not too bad if they lose it ;)
06:30 < xcvvcx> which coin is that address PKZbjtZYASUO3aPhyqqjr6TuK7djOxou ?
06:42 < belcher> this is probably not the right channel for that, i dont think many here know their altcoins
06:50 -!- kristapsk [~neonz@62.63.157.78] has joined #joinmarket     
07:13 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]     
07:13 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
07:30 < trotski2000> hi guys
07:30 < trotski2000> do you know why I get the "Exception: Not enough funds" error during tubling? Normally at tx 7 or 8
07:30 < trotski2000> *tumblin
07:31 < trotski2000> *tumbling
08:10 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
10:41 < belcher> https://www.reddit.com/r/Bitcoin/comments/72io3l/alternative_to_joinmarket_bitcoin_mixer_is_in_the/
10:44 < waxwing> sounds interesting. surprised they don't mention any details though.
10:45 < waxwing> 'an alternative to joinmarket' suggests a similar market-based mixing approach ... but only suggests.
10:48 < arubi> asked if they mean an alternative client or alternative market
10:49 < waxwing> it's a shame that coinshuffle thing never got off the ground. but, i guess, you could say the same thing about N different proposals that were never realised.
10:49 < belcher> ideas are cheap i guess
10:50 < waxwing> let's see if nopara moves forward with his zerolink/chaumian server idea; i was still quite hopeful that NTumblebit would actually be instantiated, it's pretty serious work.
10:50 < waxwing> at some point some weird rsa blinding obscure thing cropped up but i never chased it up. i do know they've been doing testnet runs, so maybe it'll make it to mainnet soon.
10:51 < belcher> that would be great
12:02 < waxwing> arubi, did that epic thread end with the guy managing to install it?
12:03 < arubi> it did, the solution is very weird
12:03 < arubi> it all started working after he ran `apt-get upgrade`
12:04 < waxwing> right that's what i saw
12:04 -!- zxccxz [6dc7e505@gateway/web/freenode/ip.109.199.229.5] has quit [Quit: Page closed]     
12:04 < arubi> the libsecp256k1 being built was really old, not sure how that got in there at all
12:04 < arubi> I mean, secp256k1-py pulls it right?
12:05 < waxwing> yes but that repo has not been updated for a long time. what's weird is i don't think there's any change in the API such that that matters, but somehow it maybe does matter in a particular distro. i'm quite lost.
12:05 < waxwing> i think we should maybe do the coincurve thing, but i really don't know
12:06 < arubi> the only thing that stood out was the cryptography library installed system wide was old
12:07 < arubi> and `pip install --upgrade` was mentioned, maybe that's what did it..  I don't know if raspbian has unattended-upgrades installed or not.  that should generally remove the need for `apt-get upgrade` manually
12:11 < arubi> really I don't know the nature of the libsecp error.  I tried to build qemu statically to try chrooting into a raspbian install but my pc actually failed mid way of the build.  was over ssh and by the time I connected a screen there was nothing no output, but the drive was crunching hard.  I ended up REISUB'ing it :(
12:21 < belcher> this makes no sense lol https://www.reddit.com/r/Bitcoin/comments/72io3l/alternative_to_joinmarket_bitcoin_mixer_is_in_the/dnjjspd/?context=3
12:22 < belcher> maybe its a communications fail
12:22 < belcher> if it talks to the joinmarket irc server then its just another joinmarket client
12:23 < waxwing> belcher, they probably have ambitious plans "do all the things", that's not uncommon. and hey, go for it.
12:23 < belcher> yeah ofc i dont want to discourage anyone, but also hope they do their work intelligently
12:24 < belcher> ill just leave it, i mean this irc is on the sidebar of r/joinmarket, they can come talk to us if they need help
12:25 < belcher> oh shi- iv just had some inspiration for an alternative messagechannel to irc..
12:26 < belcher> btw these two issues are the same https://github.com/JoinMarket-Org/joinmarket/issues/248 and https://github.com/JoinMarket-Org/joinmarket/issues/650 arnt they?
12:30 < waxwing> yeah sure, more or less
12:30 < waxwing> so what's your idea belcher ? interested to know...
12:31 < belcher> im writing it now
12:31 < waxwing> joinmarket over twitter, slack, reddit? :)
12:31 < waxwing> how about joinmarket over bitcoin - embed the messages in sign-to-contract.
12:32 < arubi> :)     
12:32 < waxwing> heck, joinmarket over joinmarket coinjoins.
12:33 < arubi> coinjoin over avian carrier
12:33 < belcher> here https://github.com/JoinMarket-Org/joinmarket/issues/248#issuecomment-332310481
12:33 < belcher> no its a solution to the problem of the p2p network
12:33 < belcher> basically encrypt the maker's offers, then intermediate makers cant read them and wont know what to censor
12:34 < belcher> well, maybe, idk
12:35 < arubi> censorship still possible
12:35 < belcher> theres still DOS issues and scalability issues, as always
12:35 < waxwing> hmm yeah it's interesting; i was never completely sold on the censorship problem; it clearly exists, but not sure it should block. and then, the idea of using encryption, it doesn't seem like it cuts out the problem, to whatever extent it exists.
12:35 < belcher> but not selective censorship, the maker p2p node would have to block everything
12:35 < waxwing> yes it clearly makes the situation better
12:35 < belcher> the original censorship problem happens because of incentives which lead to a tragedy of the commons
12:35 < belcher> the encryption removes that small incentive
12:36 < belcher> with encryption, the only censorship is someone being nasty for free
12:36 < arubi> not sure, they could still learn the other makers' orderbook right?
12:36 < waxwing> it doesn't completely remove it, there still might be an at-the-margin value to censoring depending on details, don't you think?
12:36 < arubi> and can still know the takers' message
12:36 < belcher> yes arubi but they cant censor them
12:37 < belcher> well maybe by timing actually... they see an "!orderbook <pubkey>" message then a second later some encrypted blob
12:37 < arubi> they don't know other makers are making an offer to a taker based on this takers' request (which they know) and their offers (which they know) ?
12:38 < belcher> they can know the orderbook by sending their own "!orderbook <pubkey>" out too
12:38 < arubi> right, and still some key agreement for ephemeral keys needs to be done in the open right?
12:39 < belcher> "!orderbook <pubkey>" is all you need i think
12:40 < arubi> yea agree.  I can't think of anything else
12:41 < belcher> there may be DOS issues though, someone could connect and constantly request the orderbook to waste everyones bandwidth and cpu
12:42 < belcher> maybe require people to solve a PoW that takes ~2sec to solve on average?
12:43 < arubi> hashcash? :)
12:43 < belcher> yup     
12:44 < belcher> bitmessage works a little bit like this..
12:44 < belcher> another way is to require a temporary fidelity bond
12:44 < belcher> but that would be bad UX
12:44 < belcher> a third way is to have a PoDLE commitment, which can be banned if you waste too much bandwidth
12:45 < belcher> although the commitment only proves the UTXO exists, someone could make a million UTXOs with a very small face value and spam all they want
12:45 < arubi> that's it
12:45 < arubi> was just going to ask if it's txid+index or just txid
12:45 < arubi> but I remember the whole thing now
12:46 < arubi> you really can't have just txid
12:46 < belcher> it actually works by the pubkey
12:46 < belcher> an EC point
12:46 < arubi> right but the hashed stuff includes the index, right?
12:46 < waxwing> yes i believe arubi proposed fixing it to *also* use the txid (not assuming no address reuse), but i never added it
12:47 < waxwing> my bad really ... still, in JM itself, it doesn't matter, but for external utxos it could.
12:47 < belcher> i think PoW could work fine, we pick some algo that doesnt have much of a speedup when hashed with a GPU
12:48 < belcher> or allow both methods: relay the packet if it has a valid PoW OR a fidelity bond
12:49 < belcher> so makers might choose to pay some coins to a fidelity bond so they dont have to solve PoWs all the time
12:49 < belcher> finally a thing to think about, what does IRC actually lack? especially if we move to the crowdfunded model
12:50 < waxwing> you always have the concern of selective censorship, federation never removes that entirely. and the second thing is metadata, albeit tor makes that less of a concern.
12:51 < waxwing> but as you argue, there is a theoretical censorship concern with p2p too, just depends on details really
12:51 < waxwing> i guess the big plus of p2p is how hard it is to bring the whole system down, but coinjoin isn't a broadcast system like bitcoin
12:51 < waxwing> where you just care that your message "gets out there" mainly
12:51 < arubi> that's because we don't have covenants yet
12:52 < belcher> is p2p really that hard to bring down? cant you just ddos every node
12:52 < arubi> contracts are made to specific pubkeys and hashed as part of sighash.  if any pubkey could participate in a contract based on some covenant, then you could just publish a "coinswap start" transaction and anyone would be able to complete it
12:53 < waxwing> belcher, well .. you first have to find every node .. i dunno, i would guess in most contexts, for a well designed p2p network then yes it's harder
12:53 < waxwing> it can adapt more dynamically to attack i guess
12:54 < waxwing> arubi, what exactly do you mean by covenant in this context?
12:54 < arubi> a contract where the outputs can determined before the inputs
12:55 < waxwing> ah right the whole 'constrain output' thing, 'coincovenant' thread
12:55 < arubi> yes that's it
12:56 < waxwing> i see so you're looking at that whole holy grail of non interactive coinjoining/swapping
12:57 < waxwing> like when we had those crazy acp|single ideas
12:57 < arubi> exactly.  I belive it might actually be possible with jl2012's proposal
12:58 < waxwing> link for the uninformed?
12:58 < arubi> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014963.html
12:58 < arubi> bip YYY specifically
12:58 < arubi> in the previous proposal, the pubkey used in the checksig operation was always part of the sighash
12:59 < arubi> with this one, I don't see evidence of that
12:59 < arubi> (brb)
13:02 < waxwing> arubi, thanks, ok, so this version doesn't have that feature you're looking for?
13:02 < waxwing> ok nvm it's late here anyway :)
13:03 < belcher> where are you lol?
13:03 < belcher> its only 9pm here
13:04 < arubi> waxwing, this version does have it.  the previous bip114 didn't
13:04 < arubi> I'm still debugging it, but I can't find anywhere where you /have/ to sign a the pubkey that the script's checksig consumes
13:05 < arubi> at the moment, everywhere else in bitcoin, you eventually sign the previous txid (the one in the input).  this means also signing the scriptpubkey where the funds were sent to
13:06 < waxwing> belcher, i'm not a proper hacker like Amir, i don't stay up all night :)
13:06 < arubi> maybe it's a hash of the redeemscript, that doesn't really matter.  information about the pubkey is propagated in these hashes until it's used in sighash at the outpoint
13:06 < waxwing> or like he used to be anyway, not sure about now :)
13:07 < arubi> with this bip YYY, it seems that you can turn off enough fields to make the previous scriptpubkey go away
13:07 < waxwing> arubi, so you're talking about the sighash including .. wait no i don't get it. the input would somehow have to encode the destination, no
13:07 < arubi> yes, the destination, but the not the inputs
13:08 < arubi> we want to encode checksig operations into the scriptpubkey to make sighash sign outputs but not all inputs (or not some specific things about the inputs)
13:09 < waxwing> ok so this is variations/advanced forms of sighash_single?
13:09 < arubi> yes, it's a change of the previous proposal which was also a new form of sighash
13:09 < waxwing> i see so nhashtype now has a bunch of different bits/options
13:10 < arubi> but the old version had a "pubkey" field where no matter what, the pubkey used in checksig was encoded there
13:10 < arubi> yea, very specific into each field.  you can encode pretty much anything
13:10 < arubi> but the best part, there are also opcodes being enabled like cat, substr..
13:11 < waxwing> right but now you're talking about MAST generally right
13:11 < arubi> yea, the other bips in that proposal
13:11 < arubi> bip WWW
13:11 < arubi> it might be that bip ZZZ does everything I want already out of the box..  it's not too detailed so I can't tell
13:12 < waxwing> so you're saying that a previous version of *this* bip enforced the pubkey of the checksig operation to be one thing in particular.
13:12 < arubi> correct
13:12 < arubi> the previous bip114 was just one document with a lot of the same info
13:12 < arubi> this bip 114 is in parts
13:12 < waxwing> ah ok so this is 'upgrade' of bip114
13:13 < waxwing> but i'm still quite confused trying to understand this 'enforced pubkey' thing
13:13 < waxwing> do you have a link to the old version that documented that? is it just bip114?
13:13 < arubi> just as you have a "version" field in sighash, you had a "pubkey" field.  so when a checksig was executed, it consumes a pubkey and a signature.  the pubkey it consumed was the "pubkey" field
13:17 < arubi> this was the previous one : https://github.com/bitcoin/bips/blob/9da1f65e390ca18c1d63abea8c4a112a6c95049d/bip-0114.mediawiki
13:18 < arubi> back in the previous client version, this was in : https://github.com/jl2012/bitcoin/blob/mast_v3_master/src/script/interpreter.cpp#L1820
13:19 < arubi> can see '<< pubkey' is passed in the stream
13:20 < arubi> not present : https://github.com/jl2012/bitcoin/blob/vault/src/script/interpreter.cpp#L1778-L1779
13:21 < arubi> of course it's inside hashprevouts, the scriptpubkey..
13:21 < arubi> but these can be turned off, afaict
13:22 < arubi> anyway, hopefully with an upcoming holiday I can make some progress :)
13:48 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
13:49 < belcher> apparently this guys secp256k1 isnt installing properly on windows https://www.reddit.com/r/joinmarket/comments/72ku2t/unable_to_run_joinmarket_scripts_on_windows/
13:56 -!- RainMan28 is now known as RainMan28-[away]     
14:05 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 255 seconds]     
14:10 -!- Pasha [~Cory@unaffiliated/cory] has joined #joinmarket     
14:13 -!- Pasha is now known as Cory     
14:41 < trotski2000> so guys would you recommend joinmarket-clientserver over the regular joinmarket?
14:41 < trotski2000> Is it more stable? I see it has a GUI
14:41 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds]     
14:41 -!- RainMan28-[away] is now known as RainMan28     
14:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
14:44 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
14:48 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
14:49 < trotski2000> furthermore, is it worthwhile to migrate to a segwit wallet for coinjoins?
15:01 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
15:08 -!- zxccxz [6dc7e505@gateway/web/freenode/ip.109.199.229.5] has joined #joinmarket     
15:08 -!- MaxSan [~one@213.152.161.30] has joined #joinmarket     
15:17 -!- RainMan28 is now known as RainMan28-[away]     
15:18 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 248 seconds]     
15:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
15:44 -!- RainMan28-[away] is now known as RainMan28     
16:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
17:25 < dan__> I am running ob-watcher.py.  I say my orders this morning.  I just refreshed it and I do not see my orders.  My maker bot last message is still JM daemon setup complete.  Is this normal behavior?
17:49 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
18:44 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
20:00 -!- RainMan28 [~RainMan28@unaffiliated/rainman28] has left #joinmarket ["Leaving"]     
20:53 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has quit [Ping timeout: 260 seconds]     
21:27 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #joinmarket     
21:37 -!- Netsplit over, joins: technonerd, MaxSan
21:45 < adlai> dan__: did you try the button for refreshing offers?
21:45 < adlai> dan__: long-running ob-watchers have been known to "forget" offers, thus, the button
22:08 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
22:13 < waxwing> dan__, adlai i've said many times (on here at least, probably other places i think) that it clearly has a bug but it's just not a priority to me to figure it out. it may even be very simple to fix, don't know.
22:13 < waxwing> i'm not sure that the refresh button does its job. i think not, although not sure why.
22:15 < waxwing> trotski2000, i would recommend it for various reasons, first segwit, which makes txs cheaper, second in terms of stability it has extra features to make tumbler more stable and, you can restart the tumbler later, which is useful in many situations.
22:33 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]     
22:40 -!- zxccxz [6dc7e505@gateway/web/freenode/ip.109.199.229.5] has quit [Ping timeout: 260 seconds]     
22:47 -!- zxccxz [d41591cb@gateway/web/freenode/ip.212.21.145.203] has joined #joinmarket     
23:44 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket