--- Day changed Sun Oct 15 2017
01:20 -!- delinquentme [~delinquen@2602:306:ceb7:990:7df3:ce:3589:29f2] has quit [Ping timeout: 246 seconds]     
03:18 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has joined #joinmarket     
03:21 -!- wxss [~chatzilla@oannetoccalg.hosted.co.za] has joined #joinmarket     
03:23 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds]     
03:39 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
03:41 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
03:47 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
04:20 -!- delinquentme [~delinquen@2602:306:ceb7:990:7df3:ce:3589:29f2] has joined #joinmarket     
05:12 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
06:04 -!- shmoon [~shmoon@li847-102.members.linode.com] has joined #joinmarket     
06:43 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Quit: Page closed]     
06:49 < waxwing> arubi, re unilaterally controlled inputs:condition: Alice accepts unconstrained input from Bob in TX_n on condition that she has a net positive to her balance up to TX_n-1.
06:50 < arubi> how does she assert a positive balance?  I have a hard time following
06:51 < waxwing> well remember one of the ideas here is that individual transactions in the chain may actually give out more coins to one side than the other.
06:52 < waxwing> imagine TX1 has input from F which is 2btc, outputs are: 0.8 btc to Alice, 0.8 to shared, 0.4 to another shared.
06:53 < waxwing> ah but now i write it out i realise it's much more restrictive (to the point perhaps not interesting). if bob invalidates the remainder, then alice has to be assured of getting *all* her coins before that point.
06:53 < waxwing> so yeah almost like a corner case, not really what i wanted.
06:54 < arubi> yea I see what you're saying, that's pretty much what I was thinking yesterday when I said that if inputs want to enter the tree, then the tree has to be replayed until the point where the inputs enter, then new backouts be made, and then continue
06:54 < waxwing> one thing i did notice though is that TX1 (first one coming out of F) can have unilaterally controlled inputs, because if it's invalidated, we're still able to appeal to backout.
06:54 < arubi> (continue planning a tree)
06:55 < arubi> hmm     
06:55 < arubi> ah yes, it's almost the "naive" case here, we're starting a tree, so of course it's allowed
06:55 < waxwing> right, just a minor point.
06:56 < waxwing> i don't know what you mean by replayed?
06:56 < waxwing> if unilaterally controlled inputs are going to be involved, they'll just be proposed at the start right?
06:57 < arubi> replayed == broadcast the transactions (until the point where new inputs are coming in)
06:58 < arubi> right, at the start, or maybe in the middle, we just need to make new backouts interactively when it happens
06:58 < waxwing> yes i remember thinking along those lines, but it's basically just another way of saying it doesnt' work right :)
06:58 < waxwing> because you're coming out of the "trustless box" (and you may choose to make a new one)
06:59 < arubi> the making of new backouts can be made from an existing box
06:59 < arubi> it is messy I agree.  much simpler to propose everything at the start
07:00 < waxwing> ok. you mean like from their final outpoints right? yes, messy, basically hoping to condense the interactivity into one negotiation. i guess.
07:01 < arubi> the way I see it, interactivity is always needed when new unilaterally controlled inputs are added to the box.  so you can add those at any point when you're making backouts
07:02 < arubi> it's kinda both ways, you're making backouts for your unilaterally controlled inputs, and if the other side wants to add inputs, they will want new backouts too
07:06 < waxwing> afk will think about that, thanks
07:07 -!- wxss [~chatzilla@oannetoccalg.hosted.co.za] has left #joinmarket []     
07:20 < arubi> (for later) waxwing, or hm, say alice does commit to a future uni controlled input by way of signing a timelocked transaction sent to the box to be valid at the specified block height, but she and bob also set up a backout from F specifically for that input as well, so if the tree fails to execute and her timelocked tx is relayed to the box, she has a way to get it out
07:21 < arubi> and bob will ask for a backout for his /remaining/ balance from that point in the tree, so if alice double spends that future input, bob still isn't screwed
07:23 < arubi> alice might not need a backout of her own remaining balance at that point in the tree, because she does have bob's signature for continuing the tree normally as was already planned
07:24 < arubi> bob's backout just has to be at timelock that lets alice broadcast the cooperative tx first
07:25 < arubi> I think that might work, alice backs out the future input from F and bob backs out his remaining balance from TX(input from alice joins)
07:26 < arubi> (afk too :) )
07:30 < arubi> back, "alice backs out the future input from F" makes no sense.  it's just being negotiated as if an input is sent to F right
07:31 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 1.9]     
07:37 < arubi> waxwing (and everyone), this is what I think : https://gist.github.com/fivepiece/b2562729a55a68456ff83205eb021572 
07:58 < arubi> updated
09:02 < waxwing> arubi, cool; the basic concept feels right. trying to make sure i understand the details.
09:06 < waxwing> my first thoughts are: bob's backout can have the same timelock as the main backouts (correct?) for simplicity.
09:06 < waxwing> and my second one is: does alice really need any backout in this case?
09:07 < waxwing> (i mean, any extra backout apart from the default one.)
09:12 < waxwing> if i am understanding correctly, can we extend/generalize as follows: consider a single branch/chain of txs. at every step, we can create backouts with the same timelock as the original backout. this ensures that if the process breaks at any step, whatever remains to be delivered to one party gets recovered to them, after the timeout.
09:12 < waxwing> this may not be acceptable for some cases, but in others both parties may feel it's OK to have the chain be only partially complete (example: a chain of coinjoins), and accept this in return for being able to graft in inputs from other wallets.
09:13 < waxwing> and it's still ok to negotiate this entire set of transactions in advance, right. or am i missing something?
09:17 < arubi> thing is, alice's input K is external to the tree and afaict she will have to sign it into the box.  even if the whole tree never executes, her input K is still going to be signed and valid to spend, so she'd like insurance in case it happens
09:18 < waxwing> but if the whole tree never executes that tx can't occur right.
09:18 < arubi> it can still be sent to a 2of2, regardless of the execution of the tree
09:19 < arubi> it can't go forward, but her tx is signed K -> 2of2
09:19 < waxwing> remember the spend from F gets signed last, and only if everything else is signed, which guarantees the whole tree is valid and gets broadcast if at least 1 party wants it to.
09:19 < arubi> especially because it gets signed last, it means K was signed before
09:19 < waxwing> but her input is part of a multi-input tx, it's not being signed off to go to a 2 of 2 on its own right.
09:20 < arubi> ah, I thought she would be sending it to a 2of2
09:20 < waxwing> if it were just directly K to a 2 of 2 then yes that'd be a problem but it won't be like that.
09:21 < waxwing> well i believe we're still stuck in a world where each tx has to have F as ancestor. i'm thinking of coinjoins where you co-use an input from an external wallet (that'd be K) with stuff from within tree.
09:21 < waxwing> in your diagram TX3 outs are co-spent with K, right.
09:22 < arubi> bad notation, it's supposed to mean K is sent to the same 2of2 that TX3 sends to
09:22 < waxwing> ok, i see. but you can see that i'm thinking of a different thing where K would then be an input to TX3.
09:23 < waxwing> maybe your idea works too, but it makes K much more "out of the box" and so yeah you're probably right, maybe that works with backouts.
09:23 < waxwing> but i'm happy with the less ambitious goal of just allowing non-F-ancestor inputs being joined with F-ancestor inputs.
09:24 < arubi> so you mean K is joined to the tree at F, correct?
09:25 < waxwing> what i was envisioning was doing coinjoins at each point in the chain; so TX3 is coinjoin of coins from TX2 with coins from Alice (utxo K). From a different wallet/account.
09:26 < waxwing> So that only poses a risk to Bob, so I think in that specific setup only Bob would need an extra backout to get the remainder.
09:26 < arubi> yes!  I understand
09:27 < arubi> that's right, bob would want backouts in case alice pulls the rug
09:27 < waxwing> But, like i was mentioning above, this tends to lead to a new model where we just create backouts at every step, if both sides are ok with incomplete tree traversal. (see above comments)
09:28 < arubi> yep, mostly if bob is okay with it
09:29 < waxwing> two models: "ensure entire tree is atomic" (requires no external inputs), "ensure only ordering" (allow non-completion) (allows external inputs)
09:35 < arubi> also I'm wondering what if we send K too to its own box starting at TX3, and the outputs that are parting from the tree to their own 2of2 where both keys are controlled by either bob or alice.   it might look like a single user who is transacting normally with a 2of2 wallet
09:36 < arubi> for K it has the benefit that we don't need gradual backouts anymore, and for the whole thing, it might make it look more "normal"
09:36 -!- beIcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]     
09:37 < waxwing> in what sense are you thinking the existing setup doesn't look normal (not saying it *does* look normal, but to precise-ify)
09:38 < arubi> in a 2of2, the change is also sent to 2of2 scripts, here it slowly leaks.  I guess though it does need to send to p2pkh to look normal
09:39 < arubi> here if we constantly use inputs from 2of2, it looks like the wallet is constantly using its change, not that it can't happen
09:39 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
09:39 < arubi> if we join inputs to their own 2of2 inputs, it looks like the wallet is being funded and used
09:40 < waxwing> i guess there are lots of different models; my only focus in what we're discussing here, though, is to make it possible to use utxos that aren't descendants of F.
09:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds]     
09:40 < waxwing> because that massively expands the use-cases, i think, in terms of creating privacy (and i'm not sure this construction has any other applications than privacy)
09:40 < waxwing> at least, i haven't thought of any yet
09:41 < waxwing> hmm probably there are some in some kind of weird multisig payment thing
09:41 < arubi> yea maybe we should look at how exchanges wallets behave :)
09:47 < waxwing> arubi, the non-technical concept here is "promise" :)
09:47 < waxwing> Alice promises to pay K, Bob says "sure, but if you don't deliver, I'm out"
09:51 < arubi> yep, it's exactly that.  so pretty much the only way alice could be stuck is if one of the tx's gets stalled and bob is able (and willing) to back out his amount
09:51 < waxwing> as i'm writing it out, i'm thinking just for simplicity each one of these backouts can just refund to both parties their current amounts.
09:52 < arubi> okay yes, that's better
09:52 < waxwing> debatable, but i think so yeah
09:52 < arubi> it's the only way to protect alice in this ^ scenario
09:55 < arubi> we could ask for very long locktimes for bob in exchange of alice not being able to back out, but I think breaking the whole thing up and refunding everyone is cleaner.  maybe there's a real issue in the network and no transactions are confirmed for some time, then it's not alice's fault
09:56 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
09:56 < arubi> oh well, we can make block height locktimes right..
09:57 < arubi> I mean, it should be block height anyway, disregard that scenario :)
09:57 < arubi> ah no, don't.  blocks could still be mined with no transactions
09:58 < arubi> I don't know why locktimes always confuse me, *shrug*
10:18 < waxwing> arubi, do you see any issues if both Bob and Alice add utxos at TX_n? seems to me we can generalise naturally, backout at each step, any number of external inputs at the following step.
10:19 < arubi> right it looks to me that if we can do one, we can do a bunch the same way if we keep them independent of each other
10:20 < arubi> the "anchor" that keeps the tree going is the joint controlled input(s), and if these can't be spent, then it all should just break at that point
10:21 < waxwing> right
10:22 < arubi> .. do we need the anchor if we make backouts for everyone at every step?
10:22 < arubi> waxwing ^
10:25 < waxwing> hmm i think so; the anchor (you mean F?) gets the ball rolling and then TX1 and backout are the two paths from there. It could just be a matter of nomenclature what you count as first.
10:26 < waxwing> we just need a chain of 2 of 2 ownership i think
10:28 < arubi> thinking, I see what you mean but going over it
10:30 < arubi> oh right, there's no way to show commitment otherwise.
10:35 < arubi> it has to be made that bob has the option to spend both his and alice's inputs to the next tx in the tree, and the same for alice.  okay, easy enough if you both share at least one input in a transaction.  I can't easily see if it's possible without
10:36 < waxwing> don't quite get what you're saying there
10:36 < arubi> they could plan a tx tree with just individual coins, but that doesn't achieve much
10:36 < arubi> no nevermind, I get it, the 2of2 is needed
10:37 < arubi> I mean, that 2of2 is what connects both alice and bob's funds and allows building the tree or backing out if they can't
10:38 < arubi> hard to keep track of all coinjoin \ coinswap \ scriptles scripts \ now this :)
10:39 < waxwing> well if you want to have fun build a setup that uses all of those :)
10:39 < waxwing> it's probably eminently possible. the hardest part of the work with this stuff, though, is analyzing what the effect is on privacy, that part is really tricky.
10:40 < waxwing> just finishing off a significant expansion on my gist, i'll let you know when it's finished. then i'll finally get round to drawing some proper diagrams.
10:40 < arubi> great, I'm back to at least getting scriptless scripts swap done :)
10:58 -!- Guest64992 [~Cory@68-190-117-162.dhcp.mdsn.wi.charter.com] has quit [Ping timeout: 260 seconds]     
11:04 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
11:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
11:28 < waxwing> updated (a lot) https://gist.github.com/AdamISZ/a5b3fcdd8de4575dbb8e5fba8a9bd88c
11:28 < waxwing> it will be a minor miracle if the example at the bottom doesn't contain errors :) well at least it's a lot more interesting now.
11:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
11:40 < arubi> I appreciate the mention :), reading now
13:10 < arubi> waxwing, that was awesome.  I see you found the double A_n typo :),  there's also "outs: out(0): Alice 0.8 btc, out(1): 22AB_1, 0.8 btc, out(1): 22AB_2, 0.4 btc" where the second out(1) should be out(2)
13:25 -!- delinquentme [~delinquen@2602:306:ceb7:990:7df3:ce:3589:29f2] has quit [Ping timeout: 255 seconds]     
14:27 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]     
14:40 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket     
14:58 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #joinmarket     
15:11 -!- delinquentme [~delinquen@50-0-244-119.dsl.dynamic.fusionbroadband.com] has joined #joinmarket     
15:12 < delinquentme> Ok cool so belcher waxwing  do you guys have any stances on the convos i had w adlai last night?
15:12 < delinquentme> Basically onboarding matters, and accordingly we need to have scripts that run cleanly.
15:14 < delinquentme> If I come into joinmarket + want to run the tumbler... I should need to know 1) what the cost of running the tumbler will be given the current activity in the mempool 2) Convetion over configuration for all scripts...
15:15 < belcher> i didnt follow the conversation in detail
15:16 < belcher> those ideas sound good, i think 2) is already true
15:16 < belcher> pull requests are always welcome
15:26 < delinquentme> belcher I think we talked about how the tumbler could be configured to run cheaper mixing if we wanted... The details of that are in one of the mixing guides?
15:26 < belcher> theres only one thing you can change afaik, make tx_fees higher
15:26 < delinquentme> Last night I had attempted to run the tumbler to no avail ... I can post the log if it helps but adlai thought there wasn't enough liquidity @ that ammount to run it
15:27 < belcher> i.e. the target block count
15:27 < delinquentme> right. but that should simply change the time it takes no?
15:27 < delinquentme> IE higher the fees, more likely for the tx to be picked up in the next block
15:28 < delinquentme> adlai, seems to think that $50 usd isnt sufficient to get the tumbler to go ... so I had suggested that if given the size of the mempool, its an easy calc to give new users a minimum wallet value ... in order to make the tumbler go
15:29 < belcher> yes     
15:29 < belcher> pull requests welcome!
15:30 < delinquentme> yeap haha I do want to help here but I think b efore automating that ... I need to be able to run one myself
15:30 < belcher> the minimum value is probably better calculated from the joinmarket orderbook rather than the mempool though
15:30 < delinquentme> what was the URL on that?
15:30 < belcher> you can see it by running ob-watcher.py
15:31 < adlai> delinquentme: in principle, there was enough liquidity for you to tumble that amount. the trouble is that the current code tried again and again to make coinjoins at a size without enough liquidity.
15:32 < delinquentme> adlai, i dont follow. You mean that the value was too low therefore insufficient liquidity.
15:32 < delinquentme> ?     
15:32 < adlai> after discussing JM on a very very high level with some folks tonight, the best "solution" to this issue UX-wise would be a fire-and-forget that is fed the moneyXtime you're willing to pay for max privacy, and it does its best with all the rest
15:33 < adlai> delinquentme: for a specific coinjoin.
15:33 < delinquentme> adlai, yeah that sounds solid.
15:33 < delinquentme> I would have been perfectly happy as a first time user to even get an approximation of time and costs
15:34 < delinquentme> so my current plan is 1) get a tumbler to run
15:34 < delinquentme> 2) figure out how to deploy more raspis in order to up the low-end liquidity
15:34 < delinquentme> to help us get more ppl involved.
15:34 < delinquentme> but so right now... how much do I need in my wallet, to allow me to make a tumbler run?
15:34  * adlai doesn't understand how butchering more chickens will get you a steak
15:35 < adlai> delinquentme: five hundred testnet coins.
15:36 < adlai> it doesn't feel right to me handhold you through a "tourist tumble" just for kicks, on mainnet
15:36 < adlai> maybe i'm just grumpy and tired.
15:37 < delinquentme> adlai, consider from the standpoint of someone who hears about joinmarket
15:37 < adlai> if it's not obvious - a bitcoin should be enough.
15:37 < adlai> "five bitcoins should be enough for anybody" - bill gates
15:37 < delinquentme> they're like "ok awesome" i want to see how this goes.
15:37 < delinquentme> hahaha
15:37 < delinquentme> I dont have a btc to blow.
15:38 < delinquentme> so they come in, do all the setup
15:38 < belcher> joinmarket is not a finished project
15:38 < delinquentme> and then someone tells them " you cant do that right now bc XYZ "
15:38 < adlai> again, what does "see how this goes" mean?
15:38 < delinquentme> adlai, they want to drive the car.
15:38 < delinquentme> they want to see it do the thing it does.
15:38 < adlai> humor me this scenario: the year is 2140. all coins are mined. peak oil is a meme so long dead that it's making oil already, and that oil costs... a bitcoin per barrel. do you let your kid drive the car for fun, or do you buy him a simulator?
15:39 < delinquentme> belcher, sure ... but I guess the question is then: Do you not want more people using the service?
15:39 < belcher> again, pull requests welcome!
15:39 < delinquentme> adlai, I appreciate the position of "dont fuck around w real things"
15:39 < delinquentme> belcher, Yeah thats the plan ... but I want to get the tumbler running :D
15:39 < adlai> thank you for getting my message :)
15:39  * adlai hangs up the phone
15:40 < delinquentme> adlai,  but you must also see that its against adoption to not be able to run it
15:40 < delinquentme> We dont need to play adults here and make decisions for people.
15:40 < delinquentme> Im saying "tell them and let them decide"
15:41 < delinquentme> I agree with everything thats being said here ... but when a new user wants to tumble... the default response shoudln't be "sorry doesn't work right now, come back in a week"
15:41 < delinquentme> that will drive people away.
15:41 < delinquentme> So thats what I can work on here... but first I need a wallet value that I need to deposit to make the tumbler go.
15:41 < adlai> honestly my conversation earlier just made me feel uneasy namedropping joinmarket all the time
15:41 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #joinmarket     
15:41 < delinquentme> what do you mean :D?
15:41 < adlai> do you realize how easy it is to compromise what little unlinkability joinmarket SELLS?
15:42 < belcher> delinquentme do you have a solution? right now what im hearing is you're telling us "please code this thing for me"
15:42 < quitobro> hey guys, i have an SW wallet which reports having a non-zero balance, but when trying to sweepout any of the mixdepths it (correctly) reports that there are 0 UTXOs in that mixdepth
15:42 < delinquentme> belcher, Im asking for a number that I need in my wallet to make it go.
15:42 < quitobro> this is fresh off a reindex of my node’s chainstate.dat
15:43 < delinquentme> after I make it go... then I will sort out how to fix this problem in the future.
15:43 < belcher> delinquentme run ob-watcher.py to see the orderbook and get an idea of what amounts have liquidity
15:43 < belcher> quitobro so your node thinks some addresses have a balance when in reality they dont?
15:43 < delinquentme> yeah I was right in the middle of that... suprised that the install of matplotlib went through :P
15:44 < quitobro> belcher yep
15:44 < belcher> can you query them on the console or bitcoin-cli? i forgot the exact command
15:44 < belcher> i think `listunspent <address>` will tell you the UTXOs on an address
15:44 < quitobro> yea i imagine that query will correctly tell me that there are 0 UTXOs as well
15:44 < quitobro> ok lemme look into this
15:45 < belcher> the way joinmarket obtains information is it just runs `listunspent` and `listtransactions` and stuff like that
15:45 < belcher> it would be very very strange if a node thought an address didnt have UTXOs but joinmarket thought it did
15:46 < adlai> delinquentme: how about this approach: read that log, if you still have it. see what the smallest attempted coinjoin was. divide the lowest level of liquidity with enough counterparties, by that amount; and multiply this by the amount you had in the wallet. that's how much you need.
15:46 < adlai> if you can't do this math, you shouldn't be using bitcoin anyway, let alone trying to roll and tumble
15:46 < delinquentme> oh also I paid sky-high fees last time I sent out a payment ... tx_fees is what controls that right?
15:46 < belcher> yep     
15:46 < delinquentme> cool adlai 
15:47 < delinquentme> why you gotta make fun of my mathing abilitees?
15:47 < delinquentme> that hurts.
15:47 < belcher> tx_fees = N, N is the number of blocks to target, unless N > 144 in which case it's the fee rate in satoshi-per-kilobyte
15:47 < adlai> note that you can pay rock bottom fees by setting tx_fees ... like belcher said.
15:47 < belcher> (actually this is probably documented in the comments in joinmarket.cfg)
15:47 < adlai> so if your transaction isn't urgent, set tx_fees to 145.
15:47 < delinquentme> yeah
15:47 < delinquentme> its in there
15:47 < belcher> (or in the wiki, somewhere)
15:47 < adlai> (and wait until it confirms, patiently)
15:47 < belcher> 145 probably wont even propagate :p by default nodes limit it to 1 sat/b (= 1000)
15:48 < adlai> re: making fun of math abilities - because ... i am sick of people treating bitcoin as something that anything with a pulse has a right to push around. i don't know where the bar is, but it's somewhere above numeration.
15:48 < quitobro> yea i tried finding the ‘propagation limit’ recently and iirc it was around 1500 or 2000 for N
15:48 < quitobro> which is still insanely cheap, like 1.5 satoshi/byte
15:49 < quitobro> delinquentme: you’ll know if it has propagated or not within minutes as your wallet balance will (or will not) be updated when you query `wallet-tool.py wallet.json`
15:49 < quitobro> you will see a ‘balance mismatch error’ output printed
15:49 < belcher> by default bitcoin core nodes dont propagate below 1 sat/b, but individual operators can configure it to what they want, so it depends who you're connected to (although probably defaults will rule)
15:49 < quitobro> as the tx is propagated but not confirmed on blockchain so wallet balance isn’t caught up
15:50 < quitobro> belcher: so if it doesn’t propagate it’s just like the tree that fell in the woods but no one heard it, right?
15:50 < quitobro> lots forever in the aether
15:50 < quitobro> lost*
15:50 < belcher> pretty much, except joinmarket and your node thinks it has so it can cause irritation
15:51 < belcher> i think you can fix it with abandontransaction but iv never tried it
15:51 < delinquentme> so my online wallet is telling me I can pay $0.06 for a transaction within the hour ... and the default tx_fees si giving me satoshis around $5 usd 
15:52 < delinquentme> Is it a bad idea to drop the tx_fees number until the satoshis are around that 0.06 usd ?
15:52 < belcher> note that your online wallet probably calculates it for typical transaction sizes, coinjoins are bigger
15:53 < belcher> the key metric is the fee-rate, fee-per-byte of block space
15:53 < belcher> (or since segwit, "virtual bytes" which takes into account the witness discount, but fee/byte is the same as fee/vbyte if theres no witness)
15:53 < delinquentme> 2017-10-15 15:53:20,914 [MainThread  ] [INFO ]  Using a fee of : 58950 satoshis.
15:54 < delinquentme> ^ this im assuming is the real-world fees its saying ill pay for the transaction?
15:54 < belcher> for that specific transaction
15:54 < delinquentme> Ohhh got it belcher 
15:54 < belcher> you can think of it like miners are selling block space to you :)
15:54 < delinquentme> is there a quick / dirty way I can confirm how many transactions will happen in a coinjoin?
15:54 < delinquentme> yeap!
15:54 < belcher> tumbler.py tells you at the start
15:55 < delinquentme> im using sendpayments
15:55 < delinquentme> I compromised my output addys last night so Im regenerating my wallets
15:55 < delinquentme> :P     
15:55 < delinquentme> 2017-10-15 15:53:20,802 [MainThread  ] [DEBUG]  rpc: listtransactions ['joinmarket-wallet-ae1476', 1000, 0, True]
15:59 < delinquentme> if Im collapsing / sweeping 5 wallets ... should I assume that I need to pay the price of 5 transactions?
16:04 < belcher> if you have bitcoins in each mixdepth (for example because you ran a yield generator) then yes
16:05 < delinquentme> they're all in mixdepth 0
16:05 < delinquentme> also for future ref ... when I want to run the tumbler ... should all of the funds be sent to the same mixdepth or different mixdepths?
16:06 < belcher> different mixdepths are like different identities, so send them to different ones if you dont want them linked
16:06 < belcher> send them to the same one if you dont mind them being linked together
16:09 < delinquentme> cool. noted.
16:11 < belcher> adlai you were reading about that wallet duplication issue
16:11 < belcher> i wrote a summary here: https://www.reddit.com/r/joinmarket/comments/5wyfju/wallet_duplication_by_makers/
16:12 < adlai> thank you belcher 
16:14 < adlai> ugh, doing the podle thing via bloom filters adds yet another probabilistic aspect
16:14 < belcher> bloom filters are a bad idea IMO
16:15 < belcher> i know its my idea but i dont think its worth it tbh
16:15  * adlai mumbles an aside: we shouldn't call them economical numbers, dick... they're actuarial
16:15 < belcher> im going to read over that entire issue now
16:15 < adlai> ( There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. )
16:16 < adlai> lol this website titles feynman as "US educator & physicist (1918 - 1988)", i didn't realize they had a nobel prize for education
16:16 < belcher> heh     
16:16 < belcher> im just becoming more convinced that the number of atoms in the universe isnt actually that big of a number
16:16 < adlai> in which sense are bloom filters not worth the trouble?
16:17 < belcher> only 10^80
16:17 < belcher> adlai for version 1 id say
16:17 < adlai> you know you've been spending too much time in the digital world when decimal powers don't compute
16:17 < belcher> you can get far higher numbers by working out the combinatorics of stuff
16:17 < delinquentme> ok so once this transaction goes through Im gonna ditch the existing wallet ... advice on this?
16:18 < delinquentme> or should I just make a new one and keep the old one?
16:18 < belcher> like, if every atom in your glass of water was a person, how many possible ways to have a threesome is there
16:18 < belcher> more than 10^80 (probably, let me work it out now)
16:18 < adlai> delinquentme: why delete a wallet instead of moving it aside and keeping the old copy just in case?  You should never delete a wallet.
16:18 < adlai> ;)     
16:18 < delinquentme> true ok. got it :D
16:20 < adlai> belcher: i don't think my registers can represent the final answer, but at least the denominator is ... oh wait, that's not trivial either
16:20 < adlai> math is hard
16:21  * adlai goes get a glass of water, for starters
16:21 -!- quitobro_ [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
16:22 < belcher> barbie was right after all
16:22 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Ping timeout: 248 seconds]     
16:22 -!- quitobro_ is now known as quitobro     
16:23 < belcher> (actually her exact words were "maths class is tough" turns out)
16:24 < belcher> " As of 2005, the collector's price for one of the estimated 3,500 Teen Talk Barbies including the phrase "Math class is tough" was around $500." <--- if the price gets any higher i wonder if they'll start manufacturing them again :P
16:25 < adlai> there must be some point where the intangible value that a collectible adds to your brand, is hugher than the tangible potential of reducing the former
16:26 < belcher> ok well lets choose an easier problem since we're all barbies
16:26 < adlai> "the artist is going critical! shut him down before our picasso devalues"
16:26 < belcher> imagine if all those atoms had houses
16:26 < belcher> how many ways of rearranging the atoms into different houses
16:27 < belcher> the answer is N!
16:27 < adlai> surely you don't mean N!?
16:27 < adlai> so n factorial ways, assuming the atoms and houses are distinct?
16:27 < belcher> yep     
16:28 < belcher> which isnt true physically because atoms are indistinguishable, oh well
16:28 < belcher> also atoms dont have houses..
16:28 < adlai> well if the single-electron universe theory holds water, couldn't you distinguish based on whether it's an electron moving back in time, or a positron going forth?
16:28 < belcher> anyway the number of atoms in a glass of water is 10^24 or so, so factorial of that is bigger than the atoms in the universe
16:29 < adlai> bigger than the atoms in the universe? you probably passed that number while re-housing a gold nanoparticle
16:29 < belcher> number of*
16:29 < belcher> which is 10^80
16:29 < adlai> *observable
16:31 < belcher> anyway i just worked it out, you only need 59 objects
16:31 < adlai> *femtoparticle?
16:32 < belcher> 59 objects and the number of ways of arranging them into 59 baskets is larger than the number of atoms in the universe
16:32 < belcher> i could get 59 objects here right now... from this box of breakfast cereal
16:34 < belcher> sadly a french pack of cards has only 52 cards..
16:35 < belcher> so each individual shuffle arrangement is not as unique as an atom in the universe
16:41 < delinquentme> weird ... Im getting a connection error when trying to use the ob-watcher....
16:41 < belcher> let me guess, to cyberguerilla?
16:42 < belcher> that network has been an irritating place for months... although we piggyback for free so we cant really complain
16:42 < delinquentme> RPC error.
16:42 < delinquentme> I think its local but all of my pws are good...
16:43 < belcher> ob-watcher.py doesnt even use RPC to talk to a node..?
16:43 < delinquentme> *shrugs* ;P
16:43 < delinquentme> joinmarket-clientserver
16:43 < delinquentme> scripts/obwatch/obwatcher.py ?
16:43 < belcher> yes     
16:44 < adlai> delinquentme: can you connect to that node with bitcoin-cli from the same box?
16:44 < adlai> belcher: iirc loading JM requires a working blockchaininterface
16:44 < delinquentme> yeap.
16:44 < adlai> jm the library, that is
16:44 < delinquentme> it gives me accurate getblockchaininfo readout
16:48 < belcher> oh ok
16:49 < belcher> yes then you need to set it up correctly even just for ob-watcher.py
16:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
17:07 < delinquentme> adlai, working blockchaininterface ?
17:07 < delinquentme> If I can get a valid readout from $bitcoin-cli getblockchaininfo 
17:07 < delinquentme> RPC should be configured correctly then right?
17:10 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
17:32 -!- delinquentme [~delinquen@50-0-244-119.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 240 seconds]     
18:00 -!- delinquentme [~delinquen@173-11-102-78-SFBA.hfc.comcastbusiness.net] has joined #joinmarket     
18:53 < delinquentme> Am I incorrect in thinking that ... IF I can send bitcoin payments ... that it is configured correctly belcher?
19:01 < belcher> if wallet-tool.py displays your wallet correctly and/or you can send payments then yes its configured correctly
19:04 < delinquentme> yeah so those work just fine.
19:05 < delinquentme> jmclient.jsonrpc.JsonRpcConnectionError: authentication for JSON-RPC failed
19:05 < delinquentme> im running master branch of https://github.com/JoinMarket-Org/joinmarket-clientserver.git
19:17 < delinquentme> Cool. Pulled down the most recent master + it looks good.
19:19 < delinquentme> started http server, visit http://localhost:62601/
19:28 < delinquentme> Oh i forgot im sshed into the server 
19:28 < delinquentme> :P     
19:36 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 246 seconds]     
19:43 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
20:37 -!- delinquentme [~delinquen@173-11-102-78-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]     
20:43 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
20:44 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
21:10 -!- delinquentme [~delinquen@156.72.30.1] has joined #joinmarket     
21:14 -!- delinquentme [~delinquen@156.72.30.1] has quit [Client Quit]     
21:28 -!- Michail1 [~michail@2603:3023:a04:2900:217:a4ff:fef0:e3fc] has quit [Ping timeout: 255 seconds]     
21:35 -!- Michail1 [~michail@michail.com] has joined #joinmarket     
22:08 < adlai> ;;later tell delinquentme man ssh | grep -e -L
22:29 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro]     
23:24 -!- iinaj [sid110431@gateway/web/irccloud.com/x-fpunelnfgsiaqzat] has quit [Ping timeout: 255 seconds]     
23:24 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-cslgoczemhnytsvs] has quit [Ping timeout: 246 seconds]     
23:25 -!- zmachine [sid67411@gateway/web/irccloud.com/x-hbwhotttkyohllni] has quit [Ping timeout: 255 seconds]     
23:26 -!- zmachine [sid67411@gateway/web/irccloud.com/x-wjxlcpzegosuqdci] has joined #joinmarket     
23:26 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-kdzmleqpjfdmimhr] has joined #joinmarket     
23:27 -!- iinaj [sid110431@gateway/web/irccloud.com/x-qfxifjkoptcyzgpy] has joined #joinmarket