--- Day changed Fri Oct 13 2017
03:01 -!- wxss [~chatzilla@125.212.220.154] has joined #joinmarket     
04:19 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
04:33 -!- Hans2 [~Hans@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
05:12 < trotski2000> I'm getting this error: Estimated fee per kB greater than absurd value: 150000, quitting.
05:14 -!- timothy [~tredaelli@redhat/timothy] has joined #joinmarket     
05:15 < timothy> hi, ledger guys told me they are implementing bip173 aka bech32 for segwit addresses. do you plan to do the same?
05:45 < waxwing> timothy, have they already implemented bip49 though? i'm pretty sure i read that they did.
05:52 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 1.9]     
06:17 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Quit: Page closed]     
06:48 < adlai> trotski2000: if you didn't figure this out yourself - that 150k is configurable in joinmarket.cfg
06:52 < timothy> waxwing: actually they only support bip49
06:53 < timothy> upcoming electrum (3.x) and bitcoin core supports bip173
07:10 < waxwing> timothy, right that's what i understood. joinmarket is bip49 compatible.
07:10 < waxwing> i already tested it out on a trezor, works fine. i was asking for someone to test it on a ledger.
07:10 < timothy> what do you mean on a ledger?
07:10 < waxwing> sorry bip149 not bip49
07:11 < waxwing> timothy, i mean try out recovering a joinmarket wallet to a ledger. should work. but i don't know details, never had one.
07:12 < timothy> ledger uses 24 words :P
07:12 < waxwing> right, sure, so does trezor, but it supports 12
07:12 < waxwing> bip39 allows for 12 as well as 24
07:13 < waxwing> oh i'm thinking now you were confused, when i said bip49 (i meant bip149) i think you might have thought i was saying bip39
07:13 < waxwing> 149 is specifically about hd wallet path for p2sh segwit addresses in bip44 style wallets.
07:13 < waxwing> oh hang on lol is it 49 or 149? let me check
07:15 < timothy> actually ledger uses m/49'/0'/0' as first derivation path
07:15 < timothy> for segwit
07:15 < waxwing> sorry it is 49. 44 is the main hd wallet path standard used by most of these wallets, 49 is an amendement for segwit
07:15 < waxwing> yep that's it. same as trezor, as i was saying. the same will apply. you should be able to recover the JM wallet to it.
07:15 < timothy> ok     
07:15 < waxwing> oh, but, as you say, it depends on if they allow 12 instead of 24 words in recovery. trezor does.
07:16 < timothy> it SHOULD support 12 words for bip39 backward compatibility
07:16 < timothy> I did it once
07:16 < waxwing> right, i'd expect the same
07:37 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
08:24 < arubi> I have 12 word seeds on both a trezor and ledger, (not segwit yet though but that shouldn't matter)
08:31 -!- Timmy [~Timmy@ns334669.ip-5-196-64.eu] has joined #joinmarket     
08:32 -!- Timmy [~Timmy@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
09:15 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
09:16 < quitobro> belcher: hello m8. when i was trying to test the “segwit wallets are still ‘seeing’ non-segwit wallet transactions in its history” theory (related to all the uknown type transactions)… basically i just did a `bitcoind —rescan` right? did we also do something like `mv wallet.dat wallet.dat.bak`?
09:26 < undeath> it's related to the history tool passing an empty name for the wallet to bitcoind as second try
09:27 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
09:29 -!- puddinpop_u [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 258 seconds]     
10:02 < belcher> quitobro yes
10:02 < belcher> maybe i only thought that and didnt say it
10:02 < belcher> but yes creating a new wallet.dat importing all the addresses and rescanning will work
10:02 < belcher> since the old transactions wont be in there
10:03 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:12 < quitobro> belcher: creating a new wallet.dat and then import from my recovery seed? i wonder if just doing a rescan would have the same result?
10:16 < belcher> no because if you rescan there will still be the old addresses in there
11:00 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has quit [Ping timeout: 260 seconds]     
11:17 -!- a87ry5 [~a87ry5@cpe-24-193-56-83.nyc.res.rr.com] has joined #joinmarket     
11:50 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
11:51 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]     
11:51 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
12:03 -!- a87ry5 [~a87ry5@cpe-24-193-56-83.nyc.res.rr.com] has quit []     
12:05 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]     
12:08 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket     
12:18 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 1.9]     
12:29 -!- coins123 [~coins123@2.43.139.135] has joined #joinmarket     
12:29 -!- coins123 [~coins123@2.43.139.135] has quit [Changing host]     
12:29 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
12:35 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 248 seconds]     
12:44 < waxwing> coinjoin showerthought: 2 party tumbler algo with all the transactions pre-signed. "poor man's tumbler" :) pay into 2 of 2, make timelock backouts, then cooperatively presign all 10 txs going from last to first
12:45 < waxwing> you still get the 'bleed out' effect to multiple destinations, exercise for reader how much worse it is with 2 parties (a lot :) , also such a thing may work with N parties too i guess, haven't thought about it.
12:45 -!- coins123 [~coins123@unaffiliated/coins123] has quit []     
12:46 < waxwing> yeah i guess 2 parties over and over again is (modulo some details) going to be ultra-rubbish, but it's more the principle of the idea that interests me.
12:47 -!- coins123 [~coins123@2.43.139.135] has joined #joinmarket     
12:47 -!- coins123 [~coins123@2.43.139.135] has quit [Changing host]     
12:47 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
12:48 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
12:50 < arubi> I'm more amazed at the sign-backwards comment.. segwit is live, txids aren't malleable, why aren't we (coinswap) exchanging all possible transaction paths and signing backwards too?
12:51 < arubi> not assuming it'll make the process simpler, just never considered it
12:53 < waxwing> i was sort of trying to abstract things out arubi and asked "what can go in the box that we sign between each other while the backouts are there available". natural first thought was a single path chain. there, it occurred to me that to make the whole thing trustless the only thing that's required is signing backwards from the last.
12:53 < waxwing> but it's a very limited model (wasn't initially thinking about coinjoin at all), because it'd be only what shenanigans you play with whatever goes into your funding 2 of 2
12:55 < waxwing> oh not just 'only what goes in' but also, crucially, every tx is 2 of 2 signed (or N of N? haven't started thinking about N yet)
12:58 < arubi> does alice mind signing completely the 2-of-2 from her funds to carol before she funded it?  she shouldn't mind, so should carol
12:59 < arubi> I mean I'm probably confused by something here
12:59 < arubi> maybe?  the backwards thing is really messing with me
13:00 < waxwing> well it's like the backouts. consider the case illustrated in the scriptless script blog post. you pre-co-sign the backout before broadcasting the funding, right.
13:01 < waxwing> so, maybe i'm wrong but i think you can extend that to another layer down. call funding TX F, then you create F, create OUT1 spending F, create OUT2 spending OUT1. So, you cosign OUT2, then cosign OUT1, then cosign F. Does it sound right?
13:01 < arubi> yes, all backouts still need to be signed for and all, but somehow it seems to me as if it doesn't matter if this "final" sig goes first
13:02 < waxwing> oh. but in my example above, the reason i don't want to cosign OUT1 *before* OUT2 is: what if OUT1 assigns more coins to Alice than Bob?
13:03 < waxwing> i'm trying to make a set of transactions atomic, basically. or technically 'trustless' rather than atomic i think.
13:03 < arubi> ah yes there's the different amounts 
13:03 < arubi> right this isn't accounted for at all
13:03 < waxwing> understand, i'm trying to generalise here. "how could you arrange it so that whatever weird stuff happens in the post funding phase, it will always be a trustless contractual agreement"
13:04 < waxwing> in specific cases there might be another sequence of things you could do.
13:06 < arubi> yea I'll have to go over this by scribbling
13:14 < waxwing> so i guess that single-chain case still works fine with other inputs "grafted in" from alice and bob, along the chain, since at least one of the inputs always comes from the previous point link the chain. so while superficially it looks like it wouldn't really enable even 2 party coinjoins, maybe it would.
13:15 < waxwing> because you could be grafting in inputs from alice and bob's normal wallet along the way. still needs both parties' sign off at every step all the same.
13:16 < waxwing> im ignoring the 2/2 N/N fingerprint issue either by hand waving schnorr or having alice and bobs wallets be 2 of 2 anyway.
13:29 < belcher> great insight you guys.. signing backwards, very cool
13:32 < arubi> yes the poor man's tumbler case does work nicely, that's for sure, what I was trying to parse is if we set the final (success) signing transaction to say L-1 nlocktime, further than L0 even, if we can't now just play around with backouts until we're left with the tx we signed first which was the nlocktime, but I think I see why the separate steps are required anyway.  dinner and then I'm going back to this :)
13:32 -!- wxss_ [~chatzilla@184.75.213.133] has joined #joinmarket     
13:34 -!- wxss [~chatzilla@125.212.220.154] has quit [Ping timeout: 260 seconds]     
13:35 -!- wxss_ is now known as wxss     
13:35 < waxwing> i'm thinking that the idea is really more about coinjoins than coinswaps, because it's about direct-path chains. but i'm also thinking that "coinjoin" and 'coinswap' categories may not fully capture it. maybe there's some mixed up thing. but then i guess that was the point .. "you can do a bunch of stuff inside that box, protected by the backout"
13:36 < waxwing> have in mind that you could look at it like this: lightning style stuff is "vertical"; keep updating/changing terms of contract without hitting chain, whereas this is "horizontal": contracts on chain, so you can just pre-arrange a bunch of transactions, but you still broadcast all of them.
13:38 < waxwing> so if it works it's like, remove long term interactivity (just swap a bunch of messages immediately), also takes away a big hot wallet problem, and allow changes in ownership on-chain .. hmm maybe there is a coinswap element here too, getting quite hazy.
13:39 < belcher> yes, hold on so why exactly doesnt it work with coinswap? from what i see you dont even need the backout txes
13:40 < belcher> A and C swap pubkeys, make two 2of2 addresses, create transactions that pay into them (but dont sign them)
13:41 < belcher> then create and sign the transactions spending from the 2of2 addreses, after that sign the transactions that pay into the 2of2
13:42 < waxwing> in coinswap you're trying to make 2 separate tx chains atomic with each other via the secret
13:42 < belcher> oh there might be doublespending... for example C doublespends the coin thats the input to the funding tx, then the funding tx is invalid and C gets both moneys
13:42 < waxwing> the "signing backward" thing may help .. i'm hazy on that; but even if it does it's not the whole story right
13:42 < belcher> i think with this way theres no secret X needed at all, you dont need backout txes
13:42 < belcher> but the doublespend thing cant be solved... i think
13:46 < waxwing> belcher, yes i guess that point is why you have to have backouts. 2 sides have to enter into a shared control state before the contract-exchanging process begins.
13:47 < waxwing> which in practice means F is buried under N blocks. 
13:47 < waxwing> sorry F = funding tx.
13:47 < belcher> yes... the 2of2 thing is fundamentally a way to stop the coin being doublespent
13:48 < waxwing> i had to spend some time thinking about that before that blogpost, because it was super-confusing that there were 3 different types of coinswaps.
13:48 < waxwing> the weird one is the traditional atomic swap; in that one the two sides' transactions are isolated, trustless in themselves so you don't need an initial 2 of 2. something like that.
13:49 < belcher> yes because the output they're sent to is pubkey + H(X)
13:49 < arubi> yes they pay into the backout itself
13:49 < belcher> yes, thats a better way of putting it
13:49 < waxwing> right i'd say it's more because they have the cltv part, but w/e.
13:51 < belcher> the cltv is to add a time limit, to one side halting it indefinitely
13:52 < waxwing> well but just saying the H(X) branch is the successful contract completion branch, the cltv branch is the one where the contract failed to execute, so that's the backout.
13:53 < arubi> man this is confusing
14:00 < waxwing> i'm not currently seeing why you can't extend from a single chain to a whole tree.
14:03 < waxwing> arubi, what's confusing?
14:08 < arubi> I'm rethinking, at first I thought about signing the "last" tx (that I actually want to sign first) at a locktime /after/ L0, but now I don't think there's a point to that.  perhaps there's use to one without a locktime
14:08 < waxwing> arubi, i didn't have in mind any of the transactions having locktime, except the backouts.
14:08 < arubi> I can see the single chain (non coinswap) clearly, the tree less
14:08 < arubi> yes right, was talking about the think I mentioned before with L-1
14:09 < waxwing> although i did wonder about if that is a good idea, to address the timing correlation issue, if you were indeed trying to replicate tumbler behaviour; but putting that aside for now.
14:10 < waxwing> for the tree, you're just trying to enforce nothing happens unless everything is in place. which suddenly makes me realise, exact backwards order doesnt matter, only that the first is signed last, right.
14:12 < arubi> yea that's the thing, and it's all possible to make collapsible into that "final" first tx because it's all based on 2-of-2 with backouts initially.  there are still backouts at any step onwards, but they're already set up
14:12 < arubi> is that right? ^
14:13 < arubi> yea I think I appreciate the trustless box now
14:13 < waxwing> yeah i had it scribbled on paper like "F" with a "backout" branch and then a big box as a separate branch, in the box you can do all kinds of crap
14:13 < waxwing> yeah you get it :)
14:14 < arubi> it's getting pretty close to LN, where you commit to secrets then reveal them backwards from a tree
14:14 < arubi> only now you exchange signatures down a tree
14:14 < waxwing> i guess you mean the htlc part of lightning right
14:15 < waxwing> well, yeah except like i just mentioned, the order doesn't matter, it's just that initial unlock happening only after everything you want to happen is in place. as long as both sides have all txs, signed.
14:16 < waxwing> so the thing that makes it work is at least one input in each tx is under shared control. i think that's the part that's most interesting, since then you can mix and match in funds from other wallets (and of course outpoints can be to external anywhere in the tx network too)
14:18 < waxwing> i suppose there is nothing stopping this be N of N too, except in a schnorr-less world it gets harder and harder to "cover" the anonymity set problem (4 of 4 would look icky). but say 2 of 2 now, for sanity :)
14:19 < arubi> so it's kinda like sharing a wallet, but before you fund the address you take care of the spending tx first
14:19 < arubi> (and your insurance in backout)
14:20 < waxwing> i dunno that doesn't quite fit to me somehow. for 2 of 2 wallet just do 2 of 2 multisig wallet :)
14:21 < arubi> ah right, I'm wandering into coinswap territory again instead of tumbler :)  you want the funds /back/, tumbled
14:22 < waxwing> oh well, no i didn't mean that. tumbler is particularly good if the funds go *out*
14:22 < waxwing> but yeah of course they can go back too
14:23 < arubi> out?  I thought tumbling means you join your coins with others by paying back to your own wallet from these joins
14:24 < waxwing> imagine like 15 transactions, txs 10, 14,15 are "sweeps" out of a mixdepth(account) that send the funds out of the wallet.
14:25 < waxwing> tumbler specifically empties the wallet (could be to another JM wallet of course)
14:25 < arubi> ah!     
14:25 < waxwing> and could be to another mixdepth in the same wallet (thats how i do it in tests usually actually)
14:26 < arubi> yes the point about depth sweeping I didn't know.  I guess if you wanted to keep it all in the same wallet you'd better be a maker anyway
14:27 < waxwing> you can do a few individual coinjoins and/or a short tumbler run through say 3-4 mixdepths then keep holding the coins in mixdepth 5 say. that works fine, although it's functionally equivalent to moving to a new JM wallet.
14:27 < waxwing> or like you say you can run a maker if you have time.
14:28 < waxwing> perhaps more interesting is what new patterns are enabled by such a scheme (than, how well you can do an existing scheme)
14:28 < waxwing> the first thing that comes to mind is because each tx does not have to preserve balance for both/all parties
14:28 < waxwing> so e.g. unequal coinjoins and whatnot.
14:30 < arubi> so let's say we have one trustless box set up, easy.  and then we hear about another box that was set up but some other two people
14:31 < arubi> is the point now that we can continue this?  backout outputs might go to 2-of-2 themselves, as if back to the original single box of each pair
14:32 < waxwing> mindblown.gif
14:33 < waxwing> (i don't quite understand it ... but ... you mean repeat the pattern at a higher level?)
14:33 < arubi> yes, the 2-of-2 are already confirmed, just do what you did before
14:34 < arubi> I mean, yes, higher level as in the inputs from the two boxes might successfully go into one box for all 4 participants
14:34 < waxwing> i'll have to think about that :) it does sound cool, but it's really late here now :)
14:35 < waxwing> in very vague terms it sounds like it'd make sense
14:35 < arubi> or back to the two single boxes if it doesn't go through.  you just sign everything in advance, until the final 2-of-2 + 2-of-2..  I think it should work the same..
14:36 < arubi> pretty late here too.  I'll think about it more tomorrow
14:43 < quitobro> hey guys, if i want to import/recover my JM wallet in another wallet client (just kinda messing around with wallet recovery for diff wallets), any recommendations on which would be a good one to start with - e.g. electrum?
14:44 < arubi> ah, one thing that'll have to happen is to recursively sign backouts out of backouts.  so if backout_0 happens from the x4 box setup back to the x2 boxes, now the same participants are in the 2-of-2 as before, but the txid of the fund is changed and there might be a deadlock
14:44 < arubi> it's not un-doable, just many many paths the more levels
14:46 < waxwing> quitobro, it won't work for anything for joinmarket-org/joinmarket and for joinmarket-clientserver it will only work with trezor and i *think* ledger and *possibly* samourai (it's bip49)
14:48 < waxwing> you can export private keys though quitobro (in both versions, but for the latter, it's generally not going to be useful since the coins are stored on p2sh/pwpkh outputs, not p2pkh outputs)
14:50 < quitobro> waxwing: ok good to know, thanks
14:59 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 246 seconds]     
15:40 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
15:44 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
16:20 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
16:40 -!- wxss [~chatzilla@184.75.213.133] has quit [Remote host closed the connection]     
17:03 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
17:42 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
17:43 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
18:07 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Ping timeout: 260 seconds]     
20:39 -!- quitobro_ [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #joinmarket     
20:40 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Ping timeout: 255 seconds]     
20:40 -!- quitobro_ is now known as quitobro     
21:19 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]