--- Day changed Sat Oct 14 2017
00:56 < trotski2000> is getting this messages normal? "Dummy-2     ] [DEBUG]  cmd not in cmd_list"
01:09 < waxwing> yes it'll ignore commands it doesn't recognize (probably swreloffer etc.)
03:51 -!- wxss [~chatzilla@185.145.66.244] has joined #joinmarket     
04:20 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 240 seconds]     
05:48 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
06:01 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has joined #joinmarket     
06:04 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
06:19 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
06:24 -!- coins123 [~coins123@109.112.71.240] has joined #joinmarket     
06:24 -!- coins123 [~coins123@109.112.71.240] has quit [Changing host]     
06:24 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
06:27 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
06:34 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
06:51 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
07:01 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
07:06 < waxwing> sorry formatting isn't quite any good yet, but here's the current state of me writing up the idea i had yesterday: https://gist.github.com/AdamISZ/a5b3fcdd8de4575dbb8e5fba8a9bd88c
07:09 -!- Cory [~Cory@unaffiliated/cory] has joined #joinmarket     
07:12 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
07:25 -!- Guest64992 [~Cory@68-190-117-162.dhcp.mdsn.wi.charter.com] has joined #joinmarket     
09:09 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
09:11 < adlai> waxwing: reading, but i don't see yet how coinjoin fits into this meta-scheme?
09:22 < arubi> (F) --> TX1(out_0: Alice, 1 btc) --> TX2(out_0: Bob, 1 btc) --> ... , does this notation means a single output from F will be set to Alice as a single signer?  then the same is true for bob in TX2?
09:24 < waxwing> yes. that's the "silly" example.
09:25 < waxwing> just, it actually doesn't matter who are the signers in the "working area" part. i hadn't realized that yesterday.
09:25 < waxwing> as long as both sides can verify them all.
09:26 < arubi> in my mind any outputs in the graph would again be 2-of-2, otherwise alice could just double spend tx1
09:26 < waxwing> adlai, well, it doesn't fit in to just a single direct coinjoin of course. but it could fit in with a chain of them, and it could extend to a broader set of types is my thinking. like non-balancing.
09:27 < waxwing> arubi, i also had it in mind like that originally, but now you mention it, yes i was probably right the first time :) forgetting about double spend.
09:27 < adlai> i guess my conception of "coinjoin" is just quite inflexible :P
09:29 < waxwing> arubi, i actually rewrote parts of it based on thinking, oh it doesn't matter if there's shared control at each point. but right, it does.
09:29 < arubi> yea has to be unfortunately
09:29 < waxwing> yes it's a bit less flexible for sure, but from what we were discussing yesterday, there's still a lot that can be done with that extra restriction.
09:31 < arubi> oh sure, functionality wise it has no downside
09:34 < waxwing> i think there's a downside in as much as you have 2 of 2 (+) watermarking (without schnorr)
09:35 < arubi> true, like you said it's also possible to mix it up with some 2of3's.  but yes once schnorr is live this issue goes away on its own
09:35 < waxwing> adlai, i think with some effort you could come up with something quite close to joinmarket tumbler style sequences with this; first, extend to N of N, then choose to make JM style txs, grafting in inputs from counterparties wallets, but N of N inputs changes it (possibly a lot), also having to fix counterparty set in advance. and finally, to *enforce* delays you'd need locktimes, which is another watermark.
09:36 < waxwing> it starts to get a bit scifi, you could even imagine 10 participants but with only 3 or 4 participating in each individual JM style tx.
09:36 < waxwing> (and 10 of 10 signing .. uhh yeah, well :)
09:37 < arubi> you mean native nlocktimes right?  not in scripts?
09:37 < waxwing> that's what i was thinking; but for now no more than a thought.
09:37 < waxwing> hmm interesting point though, yeah
09:37 < arubi> watermarking in this case is very weak imo, as core wallet signs everything timelocked to "this" block
09:38 < waxwing> oh does it, that's cool
09:38 < arubi> a measure against fee sniping I think (brb)
09:42 < waxwing> i'll update it with arubi 's correction this evening and start to flesh out examples a bit. probably 3 examples is enough as long as they're explained properly.
09:46 < belcher> off topic but i wonder if you could add hashcash to http over tor to protect against DDOSes
09:46 < belcher> since obviously onion servers cant ban IPs because there arent any
09:49 < arubi> that would be cool, in this case the client probably has to supports this too from their side?
09:50 < waxwing> sounds like a decent idea, i bet someone's already suggested it somewhere
09:50 < belcher> thats okay, http/tor is already accessed almost solely via tor browser
09:50 < waxwing> does anyone remember that DOScoin thing where they put the pow into the (ECDH) TLS handshake so you could prove you DOSed the site. iirc.
09:50 < belcher> just have the tor browser calculate a PoW for about 30 seconds
09:51 < belcher> i dont know if DDOSes on tor happen at some lower layer though..
09:51 < belcher> yeah waxwing it seems an almost obvious idea, i cant have been the first person to think of it
09:51 < waxwing> yeah it's not easy to update protocols eh :)
09:52 < arubi> pow in the tls handshake :)  yea that'll work hehe
09:53 < belcher> isnt it? tor updates its protocol all the time to fix exploits
09:53 < belcher> cloudflare uses PoW doesnt it
09:54 < arubi> if it does, I bet it's javascript galore
09:55 < belcher> yes its javascript
09:55 < belcher> btw... https://blog.cloudflare.com/the-trouble-with-tor/ 
09:55 < belcher> "Some members of CloudFlare’s team have proposed a solution to the Tor Project that moves part of the process of distinguishing between automated and human traffic to the Tor browser itself. The Tor browser could allow users to do a sort of proof-of-work problem and then send a cryptographically secure but anonymous token to services like CloudFlare in order to verify that the request is not coming from an automated system."
09:56 < belcher> march 2016
09:57 < arubi> heh, there it is
09:57 < belcher> im asking on tor irc because why not
10:00 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket     
10:06 < belcher> remember how bitmessage uses PoW to prevent flooding, which at first i thought was a dumb idea but the more i think about it the better it seems... it has great UX (users dont need to buy any cryptocurrencies), you could set the difficulty by finding whats required for the PoW to take ~30 seconds on average hardware, make it memory hard so the GPUs dont speed it up too much
10:06 < belcher> and its non-interactive, you dont need to first obtain a nonce from any server or anything like that
10:07 < belcher> why did hashcash not catch on 20 years ago?
10:08 < adlai> kinda cute to call that "distinguishing between human and automated traffic"
10:08 < adlai> cf "one cpu, one vote" :D
10:09 < belcher> well i suppose maybe people will build massive ASIC farms in order to DDOS onions
10:09 < belcher> but its not like cryptocurrencies where theres a direct and massive monetary incentive
10:09 < adlai> nah it'll just steal some of the botnet / free/stolen server market from the shitcoins
10:10 < adlai> some, not all, but nowhere near "not coming from an automated system"
10:11  * adlai wonders how many bitcoin faucet operators have figured out the arbitrage between cluelessness and computing power
10:11 < belcher> PoW change can happen much easier in tor HS
10:11 < belcher> change the protocol to have the HS keypair also include which PoW algo it accepts
10:12 < belcher> if you remember the protocol, that keypair is sent to chosen introduction points
10:12 < adlai> again, there's nothing tying computing power to humans. it's just a cost.
10:12 < belcher> "hidden service descriptor" is the name
10:12 < belcher> if the server sees its getting DDOS'd it change the PoW algo in its descriptor
10:13 < belcher> i agree, but DDOSes are all about costs
10:13 < belcher> you want to create a system of asymmetric costs, where the defender spends less resources than the attacker
10:13 < adlai> that said, the system is almost certainly better than letting altcoin "investors" fund botnet hot-idling
10:13 < adlai> yeah it's also a cost increase
10:14 < adlai> i'm just nitpicking about this delusion that "one cpu, one vote" implies anything other than corporate personhood
10:15 < adlai> computing power can be leased or allocated on quite an automated basis, by one "person", according to their demands and funds
10:15 < adlai> so saying this distinguishes humans is just naive
10:16 < adlai> it's cute that they've learned of PoW, but they should also study how it's worked out over the past decade (:
10:16 < belcher> again, PoW as anti-DOS doesnt rely on "one cpu one vote"
10:16 < belcher> its about asymmetry resource usage
10:19 < arubi> thepiratebay even make it worth for them to be ddosed, they actually mine.. monero I think with it?
10:20 < arubi> well, worth until they go offline.  it's different right, they just don't serve you ads if you don't do pow
10:26 < belcher> its via javascript though.. so could the DDOSer constantly reload the HTTP and then never actually run the js
10:27 < arubi> I guess they don't care that you don't run it, just if you don't, you'll be served ads
10:28 < arubi> it's not used as a ddos protection, so why I said it's different
10:29 < arubi> also like you said the issue on tor is that there are no ips, so the simple "refresh" can defeat it really
10:38 < waxwing> mr assange is stirring the hornet's nest again
10:40 < adlai> how so?
10:40 < waxwing> he is twattering :)
10:42 < adlai> aha     
11:14 < adlai> waxwing: https://gist.github.com/adlai/77249cd6648417586b5bc13b57f1ff74
11:15  * adlai notes that he worked off revision 3
11:16 < adlai> numbering should probably be fiddled to make the unlinkability quanta coincide
11:18 < waxwing> belcher, ranvier, wtf :)
11:18 < waxwing> adlai, ah it seems we really need gist version control :)
11:18 < adlai> gisthub
11:19 < belcher> yeah i should grow up really..
11:19 < waxwing> i think i'm working on update 7 now, sorry, editing
11:19 < waxwing> adlai, loving the ascii stuff :) wonder if there's a program to do that for you. asciiart or whatever.
11:20 < waxwing> belcher, you should call yourself belcher32. or belch32 :)
11:20 < adlai> M-x artist-mode
11:20 < belcher> sold!
11:21 < adlai> :D     
11:22 < adlai> waxwing: so far it's a pain to use, though. probably the least-intuitive emacs mode i've encountered... but i've never used it for this much "art" before
11:22 < waxwing> adlai, fwiw i just made that example up, it's probably crap, but i guess by now you understand it almost doesn't matter :) if you come up with a short 2 or 3 tx set that has particularly nice properties let me know and i'll add it in.
11:22 < adlai> i'm not sure i understand the idea yet, this was mostly rote copying from revision 3 >_>
11:22 < waxwing> hopefully you saw the above correction from arubi ; you *must* have joint control of each transaction, either at least one input must be 2 of 2 (simplest to understand), or, i think also ok, if at least one input is controlled by each party.
11:23 < adlai> hmm     
11:23 < adlai> i guess the point with the X is confusing
11:23 < waxwing> if all inputs in any one transaction in the working area are under exclusive control, that party can attempt a double spend attack.
11:23 < waxwing> to break the chain.
11:23 < waxwing> yes the X confused me a bit.
11:25 < adlai> i have a fixed "artwork", should i wait for your next revision?
11:26  * adlai wonders whether the whole "gist" thing is just a false friend and we'd be better off editing IDEA.md in a fresh repo through the web interface
11:30  * adlai waits for waxwing to release next revision
11:31 < adlai> for the e-curious: http://ergoemacs.org/emacs/emacs_ascii_diagram.html
11:32  * adlai should have used picture-mode, which is keyboard driven... artist-mode is more intended for rat slingers
11:33 < arubi> pfft, I'm going to steal that
11:33 < adlai> such stealmanning
11:33 < adlai> so nobility
11:35 < waxwing> oh now im working through it again, i think i oversimplified badly eh: you can't add in external inputs with safety; they can get spent out from under you.
11:35  * adlai goes back to poring over taker.py in the context of https://github.com/JoinMarket-Org/joinmarket/issues/693
11:35 < adlai> waxwing: if you know they're going to be needed from the beginning, could you "thread" them unchanged through earlier txs?
11:36  * arubi still reading
11:37 < waxwing> adlai, maybe, not sure; but i was hoping to create mixing effects, if it all ties back to the start of the flow it's not achieving that goal, eh
11:41 < adlai> hmm, right, that prevents a single such flow from getting tangled with others that partially overlap it, in the eyes of the unmixer
11:42  * adlai is starting to appreciate the broader idea
11:42 < belcher> my cached thoughts for #693 is each taker requests the podle commitments for each maker's utxos
11:43 < belcher> its scales a bit badly but should still work
11:44 < adlai> you mean the idea where we can create proofs of null set intersection referencing merkle roots of sorted maker utxo podle trees?
11:45  * adlai recalls there being a gist of this somewhere? or is it only in logs
11:45 < adlai> this idea that we reinvented about twice, each :P
11:46 < adlai> my only concern is that it's way more "moving parts" than just incorporating maker input coinage in the weightings for the randomized selections
11:47 < adlai> the coinage idea should also accelerate the rate of cycle through all liquidity
11:48 < belcher> no thats a different thing
11:48 < belcher> and its not as good as the podle commitment idea
11:50 < waxwing> i guess at least you can still peel off *outputs* in an arbitrarily complex tree, or just a chain for simplicity
11:50 < waxwing> it occurs to me that this is best just looked at as a kind of souped-up "doing coinjoin with a multisig".
11:51 < arubi> at any point all the amounts have to be under joint control, but that doesn't mean multiple outputs and input aren't possible
11:51 < waxwing> because if you wanted to obfuscate ownership by using a 2 of 2 say, you would first have to address deadlock with a refund like this. and then the added idea is being able to create a complex output set.
11:51 < arubi> they're just outputs and inputs that are all 2-of-2, or m-of-n
11:51 < waxwing> arubi, right. but single owned inputs means risk of spending out from under.
11:52 < waxwing> right just not single control, exactly
11:52 < waxwing> outputs that are sinks can be single control (if that's actually needed)
11:52 < arubi> yes, but probably not needed at all
11:52 < arubi> (if the box is set up)
11:53 < waxwing> i'm just imagining a scenario where you want your coins to end up at specific destinations like we account for in tumbler (sending coins to your favourite gambling establishment :)
11:55 < arubi> right, so a lot is interesting here, because 1. maybe multisig usage goes up now that it's cheaper, 2. schnorr completely solves the watermark, 3. science fiction of multiple boxes interact to achieve a large coinjoin
11:55 < waxwing> yes i am more interested in multiple-box setups now i realise that the single box is more limited than i thought.
11:55 < waxwing> so if you feel like writing more about that be my guest :)
11:56 < arubi> I'm still implementing the scriptless scripts swap, but I do plan on taking notes about this :)
11:58 < adlai> belcher: perhaps not as good alone, but i think they're mostly orthogonal?
11:59 < belcher> the point of the merkle tree proof-of-non-intersection is so the maker doesnt have to reveal all utxos, the point of podle commitments is also that(?)
12:00 < arubi> I guess the main idea is, once you're in a box, negotiating a larger box is only as hard as setting up a backout from a m-of-n, then if you choose to make backouts back into boxes, then the backout from these boxes has to be set up in advance even too, or you could just break up everything in a simple backout to single ownership
12:01 < arubi> s/too//
12:03 < arubi> ah there's a problem :)
12:03 < arubi> oh or is it, hm
12:04 < adlai> belcher: oh i thought you meant podle/nonintersection vs coinage. i think the latter is orthogonal with the former, and the former are mutually exclusive to eachother.
12:04 < arubi> say I set up a box A with myself, then a second box B with bob, then we negotiate box AB, is there an m-of-n that can make it so I can deadlock or grab his funds?
12:05 < waxwing> arubi, wait, what do you mean by "box A with myself"?
12:05  * adlai isn't certain that he understands the exact sequence of the podle idea if it's not makers publishing a single merkle root commitment, and then proofs that the utxos belong to that set
12:05 < adlai> with the proofs being sent privately to the taker
12:05 < adlai> but the roots being published with the offers
12:05 < arubi> waxwing, I set up a mock box of 2-of-2, then a real box of 2-of-2 with bob
12:05 < arubi> mock == I just set it up, it looks just like any other real one
12:05 < waxwing> arubi, ok. not sure why that would make any difference? just cosmetically you mean?
12:06 < arubi> I initially thought I could take bob's money if I get to control most keys in a larger box with him, say we combine the 2of2 where I control both keys and the second 2of2 where I control one
12:06 < arubi> but I realize it's not possible
12:07 < arubi> phew :)
12:07 < belcher> adlai its simpler than you think, each maker publishes a podle commitment for every utxo in its wallet, takers check that none of the commitments overlap
12:07 < belcher> when the taker chooses makers to coinjoin with, the makers have to open the commitment for the utxos they use
12:08 < waxwing> arubi, i think at this point, i should just complete edits to the original writeup, where i show a simple example in the more restricted case of only shared control inputs. then i can maybe catch up with what you're thinking about the extensions.
12:08 < belcher> actually now that i think, it doesnt have to be polde commitments at all, it can be just sha256(utxo + ':' + nonce)
12:08 < arubi> waxwing, actually, to be putting myself in that situation pretty much assures I pay most fees and bob gets most privacy
12:08 < arubi> sure ^
12:09 < adlai> belcher: couldn't makers with shared utxos offer distinct nonces, to increase the odds they get picked, then fail silently if they don't have enough distinct utxos to ultimately provide distinct inputs?
12:10 < adlai> i think the advantage of a podle commitment is that it's 1:1 with the utxo
12:10 < adlai> or at least, with the pubkey :P
12:10 < belcher> adlai the taker chooses the nonce
12:10 < belcher> it would be a slightly different protocol, the nonce goes in !orderbook <nonce>
12:10 < belcher> it stops a replay attack which can make takers unfairly ban makers
12:11 < adlai> how about we that the makers' commitments have to have sufficient leading zeros, too :P
12:12 < adlai> so these commitments wouldn't be published, they'd be in the private messages sent in response to each !orderbook ?
12:14 < belcher> yes     
12:15 < belcher> there would be no more public offers anymore
12:15 < belcher> which is obviously a little bit rubbish
12:19 < adlai> well, the offers are almost-public, you just need to "pay" a single podle commitment per snapshot?
12:24 < waxwing> arubi, ah as i'm writing it i'm seeing the crucial nuance (maybe you were thinking about it): shared ownership of inputs is required, but ancestry to the F of that working area is not, necessarily.
12:25 < arubi> exactly
12:27 < waxwing> ok updated the gist to correct errors
12:27 < waxwing> now just one example at the end, maybe take a quick look at that to see if it makes sense.
12:27 < arubi> oh wait, what's the url now?  I guess I was on adlai's gist
12:28 < adlai> arubi: i am reforking now
12:28  * adlai updates 'artwork'
12:29 < waxwing> oh damn the final alice bob out amounts are wrong, fixing
12:29 < arubi> ah okay, but from here right : https://gist.github.com/AdamISZ/a5b3fcdd8de4575dbb8e5fba8a9bd88c
12:30 < adlai> from waxwing's [upcoming] latest
12:30 < waxwing> yeah just fixed it. probably that example has zero privacy gain, heh. i'll probably think about it more.
12:31 < waxwing> but it's less interesting than whether we can find a trick with this whole "use shared inputs from outside this particular flow" to improve it. not sure.
12:31 < adlai> hmmm. i'm not sure the twisted picture is much clearer than this one with one line per tx
12:32 < waxwing> i wouldn't worry; will probably make a svg or something at some point
12:32 < adlai> alice on the left, bob on the right, txs and multisigs going down the middle
12:32 < adlai> ok     
12:32 < arubi> it could be that adding inputs to the tree just means that new backouts have to be set up, then the tree replayed to the chain up until the new input is added, and then the new box begins
12:33 < waxwing> so we just ride the kicks back up the layers? :)
12:33 < arubi> well actually it could be carol wanting to join on alice and bob's box maybe
12:33 < arubi> then the box is 3-of-4
12:34 < arubi> I guess it's the same as joining with another box, just set up the backouts to boxes or break
12:35 < arubi> 3of3 or 3of4 
12:35 < arubi> er, or more, you get it
12:42 < arubi> maybe interesting that parting outputs from the box if say bob wants out mid tree, alice and carol can easily agree to pay bob and continue
12:45 < arubi> maybe a parameter that sets some a number of parting outputs over some duration, so you get some amount privacy
12:46 < arubi> something like that with schnorr really just looks like a bunch of normal transactions
12:46 < waxwing> arubi, i need a concrete example of what you mean i think. start with the simplest. last time it started with making a box with myself, and i couldn't see the value of that.
12:46 < arubi> there's no value in that, I thought there was an issue but there isn't, I'm just thinking out loud :)
12:47 < arubi> I     
12:47 < arubi> er, sorry
12:56 < arubi> so a box is defined as a state where 2 or more parties have sent their funds into a mofn script, and that there are backouts set up for each side to get their own funds back, and at this point they can plan a tree of possible transactions where the amounts given back to backouts are always under the joint control of all m parties in the box.  if the amounts never change, that is nothing is added or removed, no new backouts need to be made and 
12:57 < arubi> we can continue building the tree without signing the root transaction.  at some point if amounts are added, the participants in the box want assurance that there isn't going to be a double spend of that input (destroying the tree from the root), and so the joiner's transaction has to be confirmed, and a new set of backouts set up with the joiner
12:58 < waxwing> cut off at "set up with the joiner"
13:00 < arubi> not cut off, but at that point there's a new box with the joiner
13:01 < waxwing> i def want to unpick this but just updating my example again so it actually does something sensible (and is correct), just a minute
13:01 < arubi> sure sure
13:03 < waxwing> ok done. it actually does some coinjoining now and adds up.
13:03 < arubi> will read up soon after dinner
13:03 < waxwing> so arubi first i don't quite understand this: " they can plan a tree of possible transactions where the amounts given back to backouts are always"
13:03 < waxwing> are you saying outputs in the tree pay back to backouts? like the timelocked refunds?
13:04 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has quit [Ping timeout: 246 seconds]     
13:04 < arubi> no I mean just the initial backouts
13:04 < waxwing> ok     
13:04 < arubi> they have amounts, the amounts in the tree are always some sum of these amounts minus fee right?
13:05 < waxwing> yes the total output from the tree = the output from F so it's the same as the backout
13:05 < waxwing> ok so 'new set of backouts set up with the joiner' yes i think that makes sense to me.
13:05 < arubi> right so re. adding inputs, there has to be a new backout set up once this happens, is what I mean, to account for that
13:06 < waxwing> so that's like a new box, hmm, yes with you so far i think.
13:06 < waxwing> but it's connected. hmm will have to think about it.
13:06 < arubi> but then sending out isn't so hard
13:06 < arubi> because that send out is dependent on the backout being larger
13:07 < arubi> so it could be "planned in" the tree
13:07 < waxwing> what do you mean specifically by 'sending out'?
13:07 < arubi> I mean if we have want a box's amounts to decay somewhat over a few outputs, so maybe it seems like a 2of2 or 2of3 wallet is just being used normally
13:08 < waxwing> right. this seems non-problematic in the basic form, no? just peel off amounts into outputs of transactions.
13:08 < waxwing> my example has that (although it also coinjoins).
13:08 < arubi> right that's what I think
13:08 < arubi> ah cool
13:27 < waxwing> i'm happy (more or less) with the document as-is now, thanks for input arubi adlai ... i think the example at the end nicely illustrates that you can get some useful mixing effect even in a trivial example. you lose a lot compared to a general sampling from big counterparty set a la JM, but you gain from being able to make non-balancing joins, and of course practicality of immediate negotiation.
13:33 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has joined #joinmarket     
13:39 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has quit [Remote host closed the connection]     
13:40 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has joined #joinmarket     
14:52 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 1.9]     
15:44 -!- moa [~moa@2001:bb6:9d4:7b58:18f8:45bc:1789:6689] has quit [Quit: Leaving]     
15:57 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket     
16:10 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has joined #joinmarket     
17:06 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer]     
17:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
17:30 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: lnostdal]     
17:32 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
17:39 -!- wxss [~chatzilla@185.145.66.244] has quit [Remote host closed the connection]     
18:02 -!- delinquentme [~delinquen@2602:306:ceb7:990:7df3:ce:3589:29f2] has joined #joinmarket     
18:12 < delinquentme> <waxwing> quite happy for people to switch to it slowly, it's up to them. it'd be nice for it all to be in one group, but i fear sending to '1' addresses in a coinjoin where everything else is a '3' address is too much of a privacy downgrade.
18:12 < delinquentme> Question: what is the normal use for these '3' addresses?
18:12 < delinquentme> you say its a privacy downgrade to use 1s when everyone is 3... but what about using 3s .. when everyone is a 1 waxwing ?
18:14 < belcher> '3' addresses are called p2sh
18:14 < belcher> they have existed since 2011 and before segwit were mostly used for multisig
18:15 < belcher> this has been discussed before but im happy to have my mind changed, i think the address format doesnt matter much for privacy in joinmarket when using tumbler
18:17 < delinquentme> oh. ok so theres plenty of 3 addresses out there already?
18:18 < delinquentme> Is it trivial to switch addresses for jm-cs back to 1 addresses?
18:18 < delinquentme> belcher, ^
18:19 < belcher> you have to make transactions moving the bitcoins if you want to switch between the wallet types
18:19 < belcher> even if there were no 3 addresses out there, joinmarket privacy would still be good
18:19 < belcher> good = unaffected by whether 3 or 1 addresses are used
18:20 < belcher> the only issue might be that different amounts of makers might be using the 1 orderbook or the 3 orderbook
18:20 < belcher> but hopefully that everyone will adopt segwit/p2sh soon, theres no downside and it saves you mining fees
18:20 < delinquentme> right but what is the pool size of the 1s and 3s
18:20 < belcher> you can look with ob-watcher.py
18:20 < delinquentme> I think id prefer to use 1 addresses if its a trivial fix
18:20 < belcher> theres an option to see with segwit and without segwit
18:21 < belcher> why would you prefer 1 addresses? you know joinmarket coinjoins are very visible even if they were all 1 addresses
18:21 < delinquentme> Oh so 3 addresses previously had been multi-sig .. but now are used by segwit?
18:21 < belcher> its very unlikely you get a transaction looking exactly like a joinmarket coinjoin by chance
18:21 < delinquentme> (well are still multi-sig)
18:21 < belcher> 3 addresses are a way of encoding addresses that is useful, in the past it was used for multisig but today its also used for segwit
18:22 < belcher> p2sh means 'pay to script hash' where you pay to a hash of the script needed to unlock the money, the spender has to provide the full script which has the correct hash
18:22 < delinquentme> now do I need to be worried about any kinds of issues when sending between the 1s and the 3s?
18:22 < belcher> no you dont
18:23 < delinquentme> ok cool
18:47 < delinquentme> belcher, and with all the default settings I should expect to pay ~5-10USD for a default setting tumbler run?
18:47 < belcher> ummm... i dont know, hold on
18:48 < belcher> i think cheaper than that
18:48 < belcher> because miner fees are low(er than they've been), especially if you use segwit
18:49 < delinquentme> and it certainly wont cost me $50 right?  and thats determined strictly by tx_fees = 3
18:50 < belcher> actually theres no guarantees... its possible, joinmarket is coded in a bit of crap way in this respect right now
18:50 < belcher> basically someone could attack it and do this, its unlikely though, we would've heard about it
18:51 < delinquentme> isnt the tumbler involving just one codebase?
18:52 < delinquentme> IE the tumbler is something I can run by myself?  Is it stupid for me to put $50 usd into this and try to run my first tumble?
18:52 < belcher> yes tumbler is something you run yourself, but theres a way to trick it into paying more than you might expect for miner fees
18:52 < belcher> basically you might be made to pay for some maker's utxos to be mined
18:54 < belcher> i mean this has basically never happened
18:54 < belcher> plenty of people use it all the time
18:54 < delinquentme> So whats the minimum total value that I should deposit into my external addresses to "make it go" + minimize my possible losses.
18:54 < delinquentme> and where do I read more about this bug?
18:54 < delinquentme> (assuming its up on githoob)
18:55 < belcher> https://github.com/JoinMarket-Org/joinmarket/issues/120
18:55 < delinquentme> cool
18:55 < belcher> $50 is a fine minimum, remember that the miner fee is the same regardless of the amount
18:55 < belcher> because you're buying space on the blockchain
18:55 < delinquentme> ok     
19:40 < delinquentme> hmmm belcher 
19:40 < delinquentme> Run tumbler.py with your wallet file and at least one address. Ex:
19:40 < delinquentme> $ python tumbler.py wallet.json HASH1 HASH2 HASH3
19:40 < delinquentme> It will print out an estimate of the time taken,
19:41 < delinquentme> it didnt give me an estimate on the time it would take ... instead it jumped right into the pit 
19:41 < delinquentme> =/     
19:43 < delinquentme> 2017-10-14 19:40:30,516 [MainThread  ] [DEBUG]  ERROR not enough liquidity in the orderbook n=5 suitable-counterparties=3 amount=600393 totalorders=3
19:44 < delinquentme> "yes tumbler is something you run yourself,"  I had thought I was asking: " Is a tumbler run a single-party operation?"
19:45 < delinquentme> I wasn't expecting the IRC bot to be needed if its just switching between a bunch of my own addresses .....?
19:47 < delinquentme> also I sent all my coins to addresses in mixdepth 0 .. 
19:47 < delinquentme> per : 
19:47 < delinquentme> https://github.com/JoinMarket-Org/joinmarket/wiki/Using-the-JoinMarket-internal-wallet#funding-wallet-and-displaying-balance
19:47 < delinquentme>     "Bitcoins should be sent to empty external addresses"
19:47 < delinquentme>     "First create a wallet and send bitcoins to the zeroth mixing depth."
20:17 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer]     
20:47 < adlai> delinquentme: "switching between a bunch of my own addresses" << theoretically, you could run miniircd locally, configure your IRC server to localhost, run a bunch of yield generators yourself, and tumble against yourself
20:47 < adlai> might go without saying, but you MUST use separate wallets for each bot, when operating in this manner
20:47 < adlai> otherwise you're unlikely to get even a single coinjoin accomplished
20:47 < adlai> (because your yield generators will probably be sending your taker duplicate utxos)
20:49 < adlai> delinquentme: now, let's say you want the tangled history created by your tumble run to have a "thickness" of five; this would mean you'd need five wallets funded with /well/ more than the amount you're tumbling
20:50 < adlai> so, it's much cheaper, in terms of the capital temporarily tied up, to negotiate such a series of transactions against liquidity from the public market
20:51 < adlai> thus the "something you run yourself" will most definitely need to connect to the public IRC server, and talk with other bots
20:52  * adlai wonders whether anyone else has misunderstood JM's workings in such a manner?
21:38 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #joinmarket     
22:42 < delinquentme> adlai, I do use separate wallets.  I've sent a number of btc to 5 diff wallets on mixdepth 0
22:44 < adlai> delinquentme: if all those coins are easily tracable to you, though, you're not gonna accomplish much by mixing with yourself
22:44 < delinquentme> adlai, so a default tumbler run will incorporate other transactions?
22:44 < delinquentme> transactions + wallets that arent my own.
22:46 < adlai> if you run yield generators on those 5 wallets while tumbling, you run a risk of tumbling with yourself
22:46 < adlai> but it's quite likely that many of your counterparties will be others
22:46 < adlai> the details depend on, well, the details :P
22:47 < delinquentme> ok so wait joinmarket-clientserver ... will allow me to run yield generators ... on each wallet I have ?
22:47 < delinquentme> thats a TIL.
22:47 < adlai> it doesn't just allow you, it'll even pay you! :P
22:48 < adlai> (what did you think it did?)
22:48 < delinquentme> well I knew I could run yield generators... but I had no idea they were tied to individual wallets
22:48 < delinquentme> nor did I know I could simultaneously run a yield generator ... and attempt to tumble
22:49 < adlai> if you're not under time pressure, i'd recommend studying how JM works a bit more before using it in anger/confusion
22:49  * adlai is still around for a bit, to answer questions
22:50 < adlai> tbh you seem to have some fundamental misconceptions about it >_>
22:54 < delinquentme> adlai, im sitting here thinking about market adoption tbh.
22:54 < delinquentme> like... a user come in... and I just put $50 into my wallets... and I cant do a tumble.
22:55 < adlai> what, you mean like getting exchanges to provide liquidity with their hot wallets?
22:55 < delinquentme> adoption of ppl using joinmarket.
22:55 < delinquentme> like if i come in wanting to do a tumble ... and I cant...
22:55 < delinquentme> thats absolutely not helpful for adoption. agreed?
22:55 < adlai> i think JM is sufficiently experimental that nobody wants a point-and-click-just-take-my-money-and-maybe-make-me-think-i'm-anonymous thingy
22:56 < adlai> others are welcome to disagree.
22:56 < adlai> by the time you figure out how to drive the car, you'll probably have a better idea of its gas mileage.
22:56 < delinquentme> with the discussion of how coinjoin txs are "blockchain ready" ... i was of the thought that it was ready to do this?
22:57 < delinquentme> Anyways Im asking: why dont we run a bunch of pre-configured bots in the pit?
22:57 < adlai> you can make coinjoins by hand with bitcoin core, that's orthogonal to the question of how much privacy JM gets you at what price
22:57 < adlai> uhhh
22:57 < delinquentme> if people come in and want to run tumbles ... dont we have enough btc in the community to allow that to happen?
22:57 < adlai> https://joinmarket.me/ob/
22:57 < adlai> there are hundreds if not thousands of BTC available for participating in your coinjoins
22:58 < delinquentme> oh, ok so its not a lack of bots or funds available for tumbling...
22:58  * adlai hasn't tried making giant coinjoins but they do appear to happen often enough to make those offers credible
22:58 < delinquentme> I mean im trying to run the *bare minium* transaction just to see what happens during a tumble.
22:58 < adlai> no, it's that the high-level algorithm doesn't provide the magic instant anonymity promised by every other project (including EVERY SINGLE FUCKING SHITCOIN) in this space
22:59 < adlai> the bare minimum transaction is not a tumble. use sendpayment.py
22:59 < delinquentme> the bare minimum USD in my wallets to run a tumble.
22:59 < delinquentme> or well btc :P
22:59 < delinquentme> I was told I cant run them with $2 in each wallet... so i upped it a little
22:59 < adlai> https://github.com/JoinMarket-Org/joinmarket/wiki/Sending-payments-with-CoinJoin
23:00 < delinquentme> adlai, yeah I dont want to send payments. I want to run the tumbler + see the codebase at work
23:00 < adlai> send yourself a payment
23:00 < delinquentme> ... that doesnt sound like a tumble.
23:00 < delinquentme> 2017-10-14 22:54:34,607 [MainThread  ] [DEBUG]  Got invalid maxsize: -29046990 from J54By9EtbtZ7WG82
23:00 < delinquentme> 2017-10-14 22:54:34,607 [MainThread  ] [DEBUG]  Got invalid minsize: -29016990 from J54By9EtbtZ7WG82
23:01 < adlai> On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. Charles Babbage 
23:01 < adlai> Read more at: https://www.brainyquote.com/quotes/quotes/c/charlesbab141832.html
23:01 < adlai> well that's an obnoxious website.
23:01 < delinquentme> 2017-10-14 22:55:04,007 [MainThread  ] [INFO ]  Choosing a destination from mixdepth: 1
23:01 < delinquentme> 2017-10-14 22:55:04,008 [MainThread  ] [DEBUG]  ERROR not enough liquidity in the orderbook n=6 suitable-counterparties=3 amount=650302 totalorders=3
23:01 < delinquentme> 2017-10-14 22:55:04,008 [MainThread  ] [INFO ]  Taker not continuing after receipt of orderbook
23:01 < adlai> delinquentme: ok, let's clear up some basic definitions
23:01 < delinquentme> okes.
23:02 < adlai> a coinjoin is a single transaction that has several outputs which are not trivially linkable to the inputs of that transaction
23:02 < delinquentme> right.
23:02 < delinquentme> multiple inputs, multiple outputs.
23:02 < adlai> sendpayment.py, the script that's explained in the "Sending payments with Coinjoin" tiki page, lets you create a coinjoin
23:03 < delinquentme> right.
23:03 < delinquentme> ive done this.
23:03 < delinquentme> ive swept through the mixdepths and sent all my coins to a single addy. That works 
23:03 < delinquentme> Essentially it was my understanding that the thing preventing "a tumbler run" was the lacking funds in wallets.  That apparently isn't the case.
23:03 < adlai> is that address still in your JM wallet?
23:04 < delinquentme> ( which is a sensical assumption given that the magic is extrapolated from numerous transactions )
23:04 < adlai> the tumbler creates MANY coinjoins, so it'll cost you a lot of fees
23:04 < delinquentme> ^^ exactly.
23:04 < adlai> if you want to just play around and "see it in action" but you "don't want to send payments", use regtest or testnet
23:04 < delinquentme> I didnt send the payments to an internal jm wallet.
23:04 < adlai> "internal jm wallet"?
23:05 < adlai> this sounds like another mix of terms... there are external and internal addresses. wallets are just wallets.
23:05 < delinquentme> I didnt send the output to a wallet that was created witj joinmarket.
23:05 < adlai> ok     
23:05 < delinquentme> yeah badly worded on my part.
23:05 < adlai> so, the tumbler is not a toy
23:05 < delinquentme> adlai, right ... but what im getting seeming hesitation from you on is the tumbler.
23:05 < delinquentme> Im saying "tumblers that run as expected, when expected is good for market adoption"
23:06 < delinquentme> but you dont seem to think its ready for that kinda thing?
23:06 < adlai> if you use the tumbler with $50, you could find yourself paying half of that in fees. or all of it.
23:06 < delinquentme> ( or am i picking up on this incorrectly? )
23:06 < delinquentme> adlai, right. I was also told I could tailor the mixing to something that would approximate a full tumble but while running the same script.
23:07 < adlai> the tumbler is more for the case of "I bought a couple bitcoins from brian armstrong, and i want to spend 0.01 btc and two weeks making it -EV for him to spy on which poker site I use them on"
23:07 < delinquentme> so sure I understand that a coinjoin + sending payments w ( i believe ) the sweep function is a "coinjoin" and that a tumbler run is "many coinjoins"
23:07 < adlai> the tumbler works
23:07 < delinquentme> -EV?
23:07 < adlai> negative expected value
23:08 < delinquentme> ok so heres another problem.
23:08 < delinquentme> i read the wiki...
23:08 < delinquentme> and the displayed behaviors in the wiki... arent the ones I see.
23:08 < delinquentme> IE:     
23:08 < delinquentme> Run tumbler.py with your wallet file and at least one address. Ex:
23:08 < delinquentme> $ python tumbler.py wallet.json HASH1 HASH2 HASH3
23:08 < delinquentme> It will print out an estimate of the time taken,
23:08 < delinquentme> waits in total for 19 blocks and 35.96 minutes
23:08 < delinquentme> estimated time taken 225.96 minutes or 3.77 hours
23:08 < delinquentme> tumble with these tx? (y/n):
23:08 < delinquentme> Type 'y' if you're happy to tumble. Bot will then connect to the JoinMarket pit and start doing transactions.
23:09 < delinquentme> I did not get this confirmation.
23:09 < adlai> "Two friends come upon a grizzly bear in the woods. One begins backing away slowly, the other takes off his hiking boots and starts tying on his sneakers. The first whispers, 'those won't help you outrun the bear'. The second replies, 'but they will help me outrun you'"
23:09 < delinquentme> adlai, dont get me wrong I like the metaphors
23:09 < adlai> which confirmation?
23:09 < delinquentme> but Im getting at a point here.
23:10 < delinquentme> that its stupid to not have a ... environment
23:10 < delinquentme> where users can "see the thing work"
23:10 < delinquentme> does that make sense?
23:10 < adlai> if your point is "the documentation is outdated", check when it was written. this project is entirely managed by a small number of volunteers.
23:10 < adlai> no, it doesn't
23:10 < delinquentme> the confirmation: "It will print out an estimate of the time taken,"
23:10 < delinquentme> how does that not make sense adlai ?
23:11 < delinquentme> you sell someone a car
23:11 < adlai> do you want to see your internal combustion engine work?
23:11 < delinquentme> " let me take it for a test drive "
23:11 < delinquentme> "ehh sorry, its not sunday"
23:11 < delinquentme> wtf. lol
23:11 < delinquentme> thats not how you get product adoption.
23:11 < delinquentme> what im suggesting is that in the community
23:11 < delinquentme> of DEVELOPERS.
23:11 < delinquentme> we deploy sufficient numbers of bots ...
23:12 < adlai> you can be our volunteer community manager, since i'm evidently quite bad at this :)
23:12 < delinquentme> and give REASONABLE defaults to allow users to run a tumbler
23:12 < delinquentme> without having so sit and learn "why it doesnt work"
23:12 < delinquentme> adlai, Im displeased that I cant run a tumbler for seemigly some reason I dont understand...
23:12 < adlai> i'm 100% unconvinced that the reason for your issue is that there's insufficient liquidity
23:13 < adlai> there could be a problem with the way you're running it. maybe it's not connecting to the IRC server?
23:13 < delinquentme> adlai you probably know better than me :D
23:13 < delinquentme> are the output logs completely safe to post in their entirety?
23:13 < adlai> they don't contain private keys, but they might contain your addresses.
23:14 < adlai> there's a scrub-log.py script in the same directory as the logs, but it's STRONGLY RECOMMENDED to visually inspect the scrubbed output for anything it may have missed.
23:16 < adlai> you're probably better off using testnet if your purpose is to take the car for a test drive
23:16 < delinquentme> https://pastebin.com/raw/PSc6bgK4
23:17 < adlai> and yes, a criticism of "we need more liquidity on testnet" is valid
23:17 < delinquentme> adlai, Im also hahah being kind of self-serving here... bc its something Id love to do
23:17 < adlai> delinquentme: delete that paste
23:17 < delinquentme> IE hunt down a bunch of nerd friends, configure pis for them
23:20 < delinquentme> fuck was public
23:20 < adlai> waxwing: there's no scrub-log.py in CS?
23:21 < delinquentme> adlai, ??
23:22 < adlai> which scrub-log script did you use?
23:22 < delinquentme> no idea. are my coins at risk?
23:22 < adlai> no     
23:22 < delinquentme> what is the problem?
23:22 < adlai> your privacy is arguably a little less
23:22 < delinquentme> because of?
23:23 < adlai> did you read the log before pasting it?
23:24 < delinquentme> adlai, why the fuck would you ask that just fucking tell me what the issue is
23:24 < adlai> the log lists your utxos
23:24 < adlai> now i'm trying to figure out how you ended up with a scrubbed log of a joinmarket-clientserver run, when there isn't a scrub-log.py in joinmarket-clientserver
23:24 < adlai> and your scrubbed log includes txids, which is a bug i fixed in the original joinmarket's scrub-log.py
23:25 < delinquentme> i manually replaced my inputs wallets. but just the 5 addresses that I sent coins to.
23:27 < delinquentme> So i should regenerate my wallet after sweeping the coins out?
23:27 < adlai> if you're worried about privacy, sure.
23:27 < adlai> for better or worse, it seems that the dollar has become too weak for $50 to be a realistic amount to tell people to tumble >_>
23:28 < delinquentme> well I was told I can adjust tumbling parameters to allow me to run one 
23:28 < adlai> at least not in the segwit pit
23:28 < delinquentme> so then we need to fix the users tutorial to make the default configs to allow them to run something on the tumbler 
23:28 < adlai> hmm     
23:28 < delinquentme> IMHO
23:29 < delinquentme> onboarding is always "convention over configuration"
23:29 < adlai> which tutorial? the wiki on github was written for the original JM, you're using the SW JM
23:30  * adlai is a lot less familiar with the latter
23:30 < delinquentme> right . the clientserver defaults to segwit.
23:31 < adlai> oh are you following tumblerguide.md?
23:31 < delinquentme> ok but I can leave my coins in their respective wallets over-night and I can sweep those out tomorrow right?
23:31 < delinquentme> I believe theres a singular tumble guide and its only on joinmarket classic
23:31 < delinquentme> https://github.com/JoinMarket-Org/joinmarket/wiki/Step-by-step-running-the-tumbler
23:31 < delinquentme> or am I wrong?
23:31 < adlai> there appear to be two - there's also https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/tumblerguide.md
23:34 < adlai> delinquentme: if you want something more interactive you could also try the joinmarket-qt.py but please please please read the SOURCE CODE because i've not read this myself so who knows what mistakes i could be unwittingly leading you into
23:34 < delinquentme> adlai, understood
23:36 < adlai> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/scripts/sample-schedule-for-testnet#L10 << looks like you should make sure your scheduled amounts are large enough that there is liquidity at those sizes
23:36 < adlai> if this is just a "test drive", you could also reduce the number of counterparties
23:37 < adlai> but there are only a couple counterparties at the amounts that were being tried in that log, so it's hardly any privacy improvement... just a demo run
23:39 < delinquentme> hmmm yeah it feels less a "feature" more a bug when there need to be people looking for ammounts similar to mine to do txs with in order for me to do a tumbler.
23:39  * adlai thinks out loud, cc: waxwing & belcher - a better failure should be during tumbler schedule generation?
23:40 < delinquentme> schedule generation?
23:40 < adlai> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/tumblerguide.md#tumbler-schedule-and-logging
23:41 < delinquentme> IDK how "realy world" you guys want to make this but if its easier to dump money into monero and the back into btc
23:41 < delinquentme> it seems like thats a fatal problem no?
23:42  * adlai breathes in, breathes out. and smiles!
23:42 < adlai> no, it's not a fatal problem.
23:42 < delinquentme> anyways if the output addys are the only thing compromised 
23:42 < delinquentme> why not adlai ?
23:42 < adlai> the main thing compromised is my patience, tbh. i'm sorry that we are such incompatible conversation partners :-\
23:43 < delinquentme> adlai, I understand... I am kinda pushing on this with the expectation of "Ive put time into it, and now funds to cover the tx costs ... why doesnt it go"
23:43 < delinquentme> though I do understand if the fees are > $50 usd thats problematic 
23:43 < adlai> well you've found a real problem, i agree
23:44 < delinquentme> even if I like the project enough to install it on a raspi + work on documentation
23:44 < adlai> fees aren't that high, the problem is that for such an amount, the smallest coinjoins generated, are smaller than the liquidity currently offered
23:44 < delinquentme> but then maybs thats not a problem
23:44 < delinquentme> well it is for some... 
23:44 < adlai> and the correct approach (imo) would be to find the smallest amounts that have enough liquidity, before generating the schedule
23:45 < delinquentme> but if I can run a "real multi-coinjoin tumbler" just by inputting btc ... thats OK... but I suppose we can automate the answer to:
23:45 < delinquentme> "how much btc is needed"
23:45 < adlai> imo it's also a bad habit, especially while the dollar is so volatile, to discuss such amounts in dollars
23:45 < adlai> $50 could be enough next week, if the dollar strengthens
23:46 < delinquentme> yeah its a bad habit of being an american :P
23:46 < delinquentme> but i suppose we americans have far worse habits :PPP
23:46 < delinquentme> but! 
23:46  * adlai always thought to himself "need at least 0.01 btc for joinmarket fees to be sensible", but that's a lot of dollars these days
23:46 < delinquentme> it would be lovely to know 'how much btc is needed to run the default tumbler settings and "make it go" '
23:47 < adlai> and it apparently isn't enough for the current segwit liquidity
23:47 < delinquentme> adlai, but how do we calculate that #
23:47 < adlai> you could try using the original JM
23:47 < delinquentme> Clearly its dumb for me to complain about the hard constraints of tx fees.
23:47 < delinquentme> So I wont. because they're well "hard constraints"
23:48 < adlai> we calculate that number using the code that someone might write
23:48 < delinquentme> but as a user knowing how much I need to put in, and having "convention over configuration" 'just work'
23:48 < delinquentme> is a reasonable thing to expect of a codebase.
23:48 < delinquentme> adlai, sure and thats how development works ... we hardcore some things, others not...
23:49 < delinquentme> but being that Im motivated to sort this out
23:49  * adlai realizes that there's also a tweak_tumble_schedule...
23:49 < adlai> delinquentme: i'm probably out of my depth here. this is not code which i wrote and i'm not familiar with its innards to this level of detail
23:49 < delinquentme> I would be more than happy to write the code that calculates out the minimum values to make it easy for new users to adopt the code.
23:50 < delinquentme> adlai, you're doing a stellar job so far but I understand... maybe a better question for wax or belch*
23:50 < adlai> ok it looks like this is really just a liquidity issue, not one of fees at all
23:50 < adlai> there is just not enough liquidity below 0.01 btc, in the segwit pit
23:51 < delinquentme> adlai, so then it is just a matter of "what is the minimum ammount needed to make it go" at a given time of day / date....
23:51 < adlai> the quickest way to get to your test-drive would be a non-segwit wallet, where there is liquidity even below 1mbtc
23:52 < adlai> note that you can use JMCS without segwit
23:53 < adlai> this section mentions how - https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/SEGWIT-UPGRADE.md#if-you-do-have-an-existing-joinmarket-wallet
23:54 < delinquentme> adlai, cool
23:55 < delinquentme> adlai, im soonish to go to bed here ... idk how well you know wax and belcher but
23:55  * adlai apologizes to the lords of bitcoin for the cardinal sin of suggesting that someone not use segwit
23:55 < adlai> ah, and i am just off to my first scheduled stuff of the day
23:55 < delinquentme> if you want to mention this to them ... I would be *more than happy* to help with things related to onboarding new users.
23:55 < adlai> i'm sure they'll notice the highlights in their logs
23:55 < adlai> if not, i'll remind them.
23:56 < delinquentme> if you guys think it would helpful to establish "minimum requirements of deposits" for running the tumblers
23:56 < delinquentme> i could help w that
23:56 < delinquentme> and it would be IMMENSELY useful ... because getting more people onboard is a matter of simplicity... AND it increases total liquidity.
23:56 < delinquentme> <3     
23:56 < delinquentme> adlai, ty for putting my with my assholishness.
23:57 < adlai> yw, and you mine :)