--- Day changed Sat Dec 31 2016 00:15 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #joinmarket 01:01 -!- ]Golden [~gd@pool-100-8-68-102.nwrknj.fios.verizon.net] has joined #joinmarket 01:04 -!- ]GD [~gd@pool-100-8-68-102.nwrknj.fios.verizon.net] has quit [Ping timeout: 258 seconds] 01:32 -!- fqtw_ [~me@port-92-192-77-238.dynamic.qsc.de] has quit [Ping timeout: 265 seconds] 02:26 -!- freespirit [ac624354@gateway/web/freenode/ip.172.98.67.84] has joined #joinmarket 05:34 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket 05:40 -!- lbin [5fd394c6@gateway/web/freenode/ip.95.211.148.198] has quit [Ping timeout: 260 seconds] 06:09 -!- ]Golden [~gd@pool-100-8-68-102.nwrknj.fios.verizon.net] has quit [Ping timeout: 256 seconds] 06:11 < belcher> weex not that many are stale, some are just work-in-progress 07:01 -!- ManuelHidalgo [bbc0f089@gateway/web/freenode/ip.187.192.240.137] has joined #joinmarket 07:03 < GithubBot5678> [joinmarket] instagibbs opened pull request #691: fixup README installation steps (develop...fixup) https://git.io/vMt8G 07:04 < GithubBot5678> [joinmarket] instagibbs closed pull request #688: fixup README installation instructions (master...readmefixup-1) https://git.io/vMtUp 07:04 -!- ManuelHidalgo [bbc0f089@gateway/web/freenode/ip.187.192.240.137] has quit [Client Quit] 07:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 07:18 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 08:47 < weex> belcher: it's great that there's so much developer interest. From having just been introduced to the project, going through the setup process, and realizing this thing about anonymity sets I'd like to help make the onboarding process easier. 08:48 < belcher> yep 08:48 < belcher> one small issue is i find its a lot more fun to work on your PRs than review and test other people's PRs, so sometimes it takes a while to get them merged 08:48 < belcher> on the other hand many people (including me) open a PR when the branch isnt actually done (see my tor broadcast method PR for an example) 08:49 < belcher> like if we merged that on the same day it wouldve been a problem when i later realised that issue that requires a rewrite of parts of it 09:00 < weex> Code review is not sexy but it's an important responsibility if you want the project to be high quality. are any prs in particular that you would like to see reviewed / tested? 09:09 < waxwing> unfortunately about 2 months ago i stopped working on the repo more or less full time, just as a bunch of people started to make contributions. the large majority of them are simple. you'll see comments asking for testers in a few recent ones. 09:10 < waxwing> to be clear, i haven't stopped working on joinmarket, but am working on a refactored code base. 09:11 < waxwing> also, the things that in my opinion are actually badly needed are (1)other message channel implementations (see 650), (2) some way to prevent duplication of offers from makers - this is extremely important but we don't have a solution 09:12 < waxwing> arguably (3) we need more blockchaininterface implementations, but there's a lot of nuance there. you can say people just need to run their own nodes full stop, but there are counterarguments 09:13 < waxwing> note there are two existing PRs for other blockchaininterfaces, they remain open, i did some detailed testing of both but the authors haven't continued on them unfortunately 09:13 < waxwing> also belcher has a lot of ideas around this blockchaininterface problem, worth mentioning 09:14 < waxwing> weex: that wall of text was to you :) 09:16 < weex> waxwing: thanks 09:17 < weex> i was looking for a roadmap of sorts as well 09:18 < weex> like a lot of people, i had heard of joinmarket but not really considered getting involved or using it until getting reminded of the importance of privacy technologies for bitcoin 09:18 < waxwing> yes that'd be interesting, we tried to have one for the 0.2 update (which included an update to the protocol), but it wasn't really done like that, mostly just gathered some of the discussion into one github issue. it'd be good to do something like that for a 0.3 but there is no fixed idea yet, just a few ideas knocking around 09:19 < waxwing> belcher will i'm sure have thoughts about that. 09:19 < weex> my theory is that bitcoin users would do well to invest some btc in open source infrastructure projects like joinmarket 09:19 < waxwing> to me the obvious thing is p2sh + segwit (together), but i wouldn't feel right about updating the protocol again without better defence against maker utxo duplication 09:19 < belcher> i think i know how to solve the blockchain interface problem, just needs to be coded 09:19 < waxwing> ok, then that would be in any 0.3 i guess :) cool 09:20 < weex> the question for me then was how do you make that process simpler, donations are a thing, some people make companies and seek vc but the vc has their own goals 09:21 < belcher> waxwing i dont think we have an issue about the maker utxo duplication 09:21 < belcher> ill open one? 09:21 < weex> so i developed and continue to develop a freelancing system makes using multisig escrows easier 09:22 < waxwing> yeah belcher that's a good point. although i will not be betting much bitcoin that it isn't in one of them :) 09:22 < weex> i don't know if people have expressed interest in funding dev for joinmarket but it makes sense to me that they would 09:23 < weex> there are only a few projects that really seem aligned with Bitcoin... bitsquare, this, openbazaar 09:23 < weex> so i feel like each should be well resourced just out of bitcoiner self-interest 09:25 < waxwing> as for me i'm just going to keep plugging away at the update to joinmarket-qt and the electrum plugin (both *kind* of work but there's lots of details to do), if anyone wants to help out i'd be grateful 09:26 < waxwing> although there are question marks around some of the decisions in that repo, i think it's a more workable model, in particular if you want to extend or plug-in to joinmarket. but of course, for now, and especially for Maker side, people will stay with the existing repo. 09:27 < weex> that repo? 09:27 < waxwing> it's at https://github.com/AdamISZ/joinmarket-clientserver for now 09:27 < belcher> theres also the bitcoin-qt integration which works but the testing can be made better now that bitcoin 0.13.0 has been out 09:29 < weex> my example roadmap https://bitcointalk.org/index.php?topic=1232915.msg17244400#msg17244400 and I'd love to see something like this for joinmarket 09:32 < weex> https://github.com/JoinMarket-Org/joinmarket/issues/650 means replacing irc with something distributed? 09:33 < waxwing> it's been a discussion point very often, but (a) it mostly means *adding* new message channel backends, not replacing and (b) there is a bit of an issue with p2p arch because counterparties are incented to censor their competitors 09:34 < waxwing> re (a) the idea for now is we have 2 IRC servers by default, we could hvae more, for redundancy and for a bit more censorship-resistance 09:34 < weex> is that a vanilla irc server or anything special for jm? 09:34 < waxwing> there's also anonymity of course, one difficulty is that most IRC servers don't like supporting Tor while most of our users really want that 09:36 < weex> if you were a maker and liquidity provider you might want to run an irc server 09:36 < waxwing> indeed, and the code already supports that; you can just add an extra server in the config and restart. 09:37 < waxwing> an IRC server operator does get a *bit* more info than others though (even ignoring censorship), so it's not *absolutely* nothing in terms of trust. 09:37 < waxwing> but generally what is not e2e encrypted is kind of visible anyway on the blockchain 09:38 < waxwing> or visible to all participants - e.g. podle hash commitments 09:39 < weex> an irc server for non-tor users can associate different bot nicks i guess, is there anything else they get? 09:39 < waxwing> well apart from associating there is the actual IPs right. 09:41 < weex> what's the tldr on the maker order duplication issue? 09:41 < waxwing> weex: just that when you make an offer, you claim to own X amount of btc, that's fine, but you can create multiple bots offering the same utxos. 09:42 -!- kakobrekla [~kako@unaffiliated/kakobrekla] has left #joinmarket ["Leaving"] 09:42 < waxwing> if you do that in a dumb way you can create problems for your own bot and others, but if you do it smarter, you will get an unfair advantage. 09:42 < weex> are the utxos not published with the offer? 09:43 < waxwing> well ironically 0.2 was precisely to prevent the Taker from getting that information for free :) 09:43 < waxwing> because before 0.2 there were attackers attempting to "read" all maker utxos by repeatedly requesting and then dropping. 09:44 < weex> is a hash of a utxo equivalent in terms of that kind of leakage? 09:44 < waxwing> yes it is, which is why podle is not a hash of a utxo :) 09:45 < waxwing> there's an explanation here of the reasoning: https://joinmarket.me/blog/blog/poodle/ 09:46 < weex> are there any posts on the blockchaininterface question? 09:47 < weex> is it just about making it easier? 09:47 < weex> as I was going through setup, and with blockr.io having a cert issue, it was made pretty clear that i need a full node on this 09:48 < weex> so it's almost simpler to just say, yeah you need a node 09:48 < waxwing> the big concern was always privacy; anything other than your own, local full node can be a big downgrade in that regard. 09:48 < waxwing> the fact that we lacked redundancy on non-full node connections was just the uh "icing on the cake" :) 09:49 < waxwing> but again belcher has been looking into this a lot, as he mentioned above. maybe he can point you at a link. 09:50 < weex> i had a random thought about coinjoin market analytics and wonder if it would work 09:50 < belcher> i believe these two features will solve that problem https://github.com/JoinMarket-Org/joinmarket/issues/470 and https://github.com/JoinMarket-Org/joinmarket/issues/653 09:50 < belcher> #470 is where you choose to connect to your own node, it would give full node security and privacy but much lower bandwidth 09:51 < belcher> but requires running your own node (though many people already do this) 09:51 < belcher> #653 is about connecting to the p2p network and downloading full blocks, it would give spv security but full privacy (except for the wallet creation date) 09:52 < belcher> #653 would work without any setting up by the user, so once it gets made i think we should delete the blockr.io code and use this as the default instead 09:52 < weex> so 470 is for bandwidth, 653 for ease of setup? 09:53 < belcher> yeah 09:53 < belcher> 470 would be great for tails since i doubt people will sync and entire full node on tails only to delete it all once they shut down 09:53 < belcher> sync an entire* 09:55 < weex> in the tails scenario, they're connecting to their own node via Tor? 09:56 < weex> or they can make the full node connection non-tor and have that full node only joining the Bitcoin network via tor? 09:57 < belcher> yes, they could connect with #470 to their own node 09:57 < belcher> since bitcoin core 0.12 it automatically detects tor on the same computer and creates its own onions 09:57 < belcher> so the tails with 470 could just connect to one of those opinions 09:58 < belcher> bitcoin's p2p protocol isnt encrypted so there has to be either tor, ssh tunnel, local LAN or some other method to stop eavesdroppers spying on users 10:02 < weex> one last question before i gotta go, how do you see joinmarket's utility long term... these things like mimblewimble, tumblebit, and lightning all seem to attack parts of the privacy issue. do you think joinmarket will have utility or will adopt those over time or if one in particular becomes popular does that make jm obsolete? 10:04 < belcher> in my view probably very long term jm will be obsolete, but until then its still useful 10:04 < weex> i love that it's working now 10:04 < belcher> jm is on-chain and MW and LN are off-chain also 10:05 < waxwing> i agree that it'll probably be obsolete, but i have a suspicion that long term on-chain coinjoin *might* have a use-case anyway 10:05 < belcher> oh yes, for cheaper miner fees 10:05 < belcher> especially if schnorr gets added to bitcoin 10:05 < waxwing> actually yeah i forgot the schnorr one. but that needs a new protocol anyway, still the idea of JM might still apply. 10:07 < weex> oh my analytics thought was that a maker ends up with more bitcoin after a transaction than when they started. So if i scan the blockchain for transactions where one input is matched by two outputs that sum up to slightly more, can I figure out how much is being made by all makers? 10:07 < belcher> yeah you could 10:07 < belcher> look up adlai's cjhunt project 10:08 < belcher> i dont see how you could do coinjoin without something like joinmarket, since coinjoins involve an economic problem that jm solves 10:08 < weex> any reason that change output isn't split to hide the maker? 10:09 < weex> guess we just look for 3 to add up then 10:09 < belcher> how would that work? 10:09 < belcher> theres an issue about using more than one change address that is coinjoined too 10:10 < weex> oh ok, lots to read ;) 13:12 -!- grbs [~grubles@unaffiliated/grubles] has joined #joinmarket 13:56 < instagibbs> any reasons I should be getting "You do not have any coins left. Cannot be an active maker with no funds." when I do have a balance according to wallet-tool? 13:57 < belcher> maybe the coins are unconfirmed 13:59 < instagibbs> 40+ confirms for both outputs on Core instance 14:01 < belcher> hmm.. i dont know 14:02 < instagibbs> I'll do some pdb'ing when I have the time 14:02 < belcher> maybe you have too small of a value? theres a minimum size 14:02 < belcher> below that it considered it as if you dont have any coins 14:03 < instagibbs> is that `minsize` param? I'm doing much larger(assuming that's satoshis) 14:03 < belcher> yeah its satoshis 14:03 < belcher> only about 1000000 (0.01btc) iirc 14:03 < belcher> the minsize is also affected by your reloffer fee 14:04 < instagibbs> oh, so the lower the relative fee, the larger the minsize, that might be it actually 14:05 < instagibbs> that's it, thanks 14:06 < belcher> theres a calculation that sets the minsize to make sure you always make money 14:06 < belcher> since by default you contribute a bit to the miner fee 14:06 < belcher> that bit is a bit of a mess with some perverse incentives 14:51 < instagibbs> ok, so a mix may still include an output in your wallet that is less than minsize, but you can't advertise and order unless you have some output larger than that 14:52 < belcher> it looks at your total balance in a mixdepth rather than size of individual UTXOs 14:56 < instagibbs> right, s/wallet/mixdepth/ 15:16 -!- fqtw_ [~me@port-92-192-77-238.dynamic.qsc.de] has joined #joinmarket 17:46 -!- fqtw_ is now known as fqtw 17:47 -!- fqtw is now known as boscop 17:47 -!- boscop [~me@port-92-192-77-238.dynamic.qsc.de] has quit [Changing host] 17:47 -!- boscop [~me@unaffiliated/boscop] has joined #joinmarket 18:30 -!- fqtw_ [~me@port-92-192-76-75.dynamic.qsc.de] has joined #joinmarket 18:31 -!- fqtw_ [~me@port-92-192-76-75.dynamic.qsc.de] has quit [Changing host] 18:31 -!- fqtw_ [~me@unaffiliated/boscop] has joined #joinmarket 18:31 -!- fqtw_ is now known as boscop_ 18:34 -!- boscop [~me@unaffiliated/boscop] has quit [Ping timeout: 265 seconds] 20:22 -!- boscop_ is now known as fqtw 20:30 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection] 21:14 -!- Empty2k12 [~Empty2k12@p57906416.dip0.t-ipconnect.de] has joined #joinmarket 21:40 -!- Empty2k12 [~Empty2k12@p57906416.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:32 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Read error: Connection reset by peer] 22:32 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #joinmarket 23:42 <+JM-IRCRelay> [J54QC4kwg5MkpLmp] !reloffer 0 750000 3658550018 1000 0.002 ~