--- Day changed Sat Jul 22 2017
03:17 -!- zxccxz [6dc7e415@gateway/web/freenode/ip.109.199.228.21] has joined #joinmarket     
03:21 < zxccxz> will jm 0.2.3 work after 1st august?
03:26 < waxwing> yes     
03:27 < waxwing> at the moment it's good to wait for more confirmations. from now till .. not sure, but probably some time after aug 1.
03:28 < waxwing> of course my 'yes' was based on the assumption there won't be a large scale fork on Aug 1, that is still technically possible, then i think JM is the least of your worries :)
03:29 < zxccxz> taker_utxo_age ?
03:30 < waxwing> right, that's *one* way in which participants might disagree if they were on different chains. a more simple way is, they disagree about which inputs are valid/exist.
03:34 < zxccxz> well I'll shut it down before 1st august, too much risk getting fork-coins, how you increase confirm for maker, or taker_utxo_age is valid for both?
03:39 < waxwing> i agree that for prudency's sake it's probably better to shut down even today.
03:39 < waxwing> belcher_: do you agree? we can set the alert if so.
03:42 < waxwing> (and we could do kicking in irc if appropriate)
03:49 < adlai> i don't see why to shut down. you can only get coins that are valid on the chain you're using.
03:50 < waxwing> adlai: yes, i also thought this, but then again how does a reorg get handled
03:51 < adlai> same way reorgs always get handled: your wallet tries to spend a nonexistent coin, realizes it doesn't exist, refreshes utxos.
03:51 < adlai> at least, i believe this is how it'd work with a dedicated node. i'm not certain whether this flow works with the blockr interface.
03:52 < waxwing> *if* we all run the same Core, no problem, except that our code has no explicit handling (so re sync the wallet needed), but what if people aren't all running off the same bitcoin client
03:53 < waxwing> there may be people using non-Core based JM, although that is currently almost not supported, or there may be people running different Core versions.
03:55 < adlai> won't this lead to recovery from a reorg too? https://github.com/JoinMarket-Org/joinmarket/blob/master/joinmarket/maker.py#L72-L82
03:56 < waxwing> oh, yes, fair point, i forgot we had that built in resync
03:57 < adlai> i'm fine with declaring, for the duration of the fork risk, that JM only works on BTC core, and that running as a maker *requires* an independent node; although it looks as though this code is independent of the interface
03:58 < waxwing> adlai: so what happens if someone is running say segwit2X code (yeah, i know). just hypothetically. then, there is some small risk currently of divergence persisting, right.
03:59 < waxwing> in case it isn't obvious, i haven't figured out the scenarios. i find it hard enough to figure out what is going on with just pure Bitcoin itself :)
04:01 < adlai> with current code, if a maker and taker are on different chains after a fork, they'd either be able to transact, if their utxos are still unspent on both chains; or treat eachother as presenting invalid commitments (from the taker) and bad inputs (from the maker)
04:04 < adlai> in case it isn't obvious, i might be further out of the loop than you :P
04:04 < waxwing> i'd come to a similar conclusion the other day when i was saying 'coinjoin is a single tx protocol, therefore it doesn't suffer the same risks'. but i'm not yet convinced that the possibility of a large reorg doesn't introduce a risk we haven't thought about.
04:06 < adlai> most importantly, the worst thing that can happen is that your funds end up on different addresses in each chain, but they're both addresses you either control, or wanted to send the coins there anyway
04:07 < adlai> i don't see any way that someone can actually lose coins through JM-fork interactions
04:07 < waxwing> how would your funds end up on different addresses?
04:07 < adlai> if taker and maker are on different chains, all utxos exist on both chains, but then the tx only gets broadcast on one
04:08 < waxwing> oh in that sense, gotcha
04:08 < adlai> and then the confused taker retries with a different set of makers, and gets a different tx (to the same address!) on the other chain
04:09 < adlai> thus my suggestion to simply tell everybody not to use JM with the non-main chain... better yet, not to use anything with the non-main chain :P
04:11 < waxwing> but part of the problem is, what is main chain is not *only* defined by the client that users such as JM users use, it's defined by what miners use. there can be two forks, one is preferred by current main Core clients, but then it gets reorged out due to rules set by mining clients, not your client.
04:13 < adlai> the worst case scenario for makers would be losing some fees. they wouldn't even need to reset the wallet file - it'd just have a higher index_cache than necessary, so if they rescan on the new chain, it'll still pick up all their funds
04:14 < adlai> i believe for takers the situation is similar
04:21  * waxwing puts down his code and picks up a pen and paper :)
05:13 -!- coins123 [~coins123@31.159.234.177] has joined #joinmarket     
05:13 -!- coins123 [~coins123@31.159.234.177] has quit [Changing host]     
05:13 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
05:20 < waxwing> adlai: how i see it, the disruption risks are obvious (imagine tumbler), but nbd. there are probably some privacy risks, based on reusing addresses (you mentioned), but i suspect only corner cases (e.g. using pushtx to makers), it's pretty minor. i can't see any risk w.r.t. funds; there is of course the risk for any wallet, that of thinking you received funds when you transacted, but you didn't - but that has nothing to do with JM per se.
05:21 < waxwing> the subtlety on that last point being, of course, that a coinjoin is a "trade" entirely on trade, not a trade of btc for something else, so it doesn't carry that type of risk. "losing" fees because history changed is, meh.
05:22 < waxwing> but having said all that JM is in the same position as a lot of things today; given a substantial risk of reorgs starting in a few hours, it's probably better just to not transact.
05:23 < waxwing> a "trade" entirely on *blockchain* i meant, ofc
05:27 < adlai> i don't disagree, although i also think that kicking bots off IRC is too extreme. if people want to take the risk, let'em.
05:27 < waxwing> yes probably. i'm just worried we've missed something.
05:28 < waxwing> i mean technically they could just use their own channel :)
05:35 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]     
07:36 -!- MaxSan [~one@185.9.19.107] has quit [Quit: Leaving.]     
08:40 -!- MaxSan [~one@185.9.19.107] has joined #joinmarket     
09:08 -!- coins123 [~coins123@37.176.92.57] has joined #joinmarket     
09:08 -!- coins123 [~coins123@37.176.92.57] has quit [Changing host]     
09:08 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
13:05 -!- MaxSan [~one@185.9.19.107] has quit [Ping timeout: 240 seconds]     
15:02 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]     
16:14 -!- deep-book-gk_ [~1wm_su@5.62.43.15] has joined #joinmarket     
16:15 -!- deep-book-gk_ [~1wm_su@5.62.43.15] has left #joinmarket []     
20:03 -!- HostFat_ [~HostFat@93-39-178-182.ip77.fastwebnet.it] has joined #joinmarket     
20:06 -!- HostFat [~HostFat@93-39-178-182.ip77.fastwebnet.it] has quit [Ping timeout: 255 seconds]     
20:24 -!- HostFat_ [~HostFat@93-39-178-182.ip77.fastwebnet.it] has quit [Quit: Leaving]