--- Day changed Tue Jan 03 2017 01:30 < adlai> you can also use wallet-tool.py with the -pp flag, that accidentally the whole privkey 01:30 < adlai> but AlexCato's suggestion is safer 01:30 < adlai> btw, "internal" addresses doesn't mean your coins are stuck 01:30 < adlai> you can do a regular send and it'll use internal addresses to fund the tx 01:31 < adlai> they're just "internal" in the sense that you have to deliberately footgunn to print an unused internal address 01:31 < adlai> whereas external addresses SHOULD ONLY BE PRINTED IF UNUSED jeez ppl 01:31 < adlai> doesn't anybody here care about privacy!? 01:31 < adlai> where are all the UX Gurus 02:25 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #joinmarket 03:02 -!- q-biq [q-biq@unaffiiliated/q-biq] has quit [Ping timeout: 246 seconds] 03:40 -!- q-biq [q-biq@153.92.126.244] has joined #joinmarket 03:40 -!- q-biq [q-biq@153.92.126.244] has quit [Changing host] 03:40 -!- q-biq [q-biq@unaffiiliated/q-biq] has joined #joinmarket 03:49 <+JM-IRCRelay> [mrnice] when using sendpayment.py I get "ValueError: Estimated fee per kB greater than absurd value: 150000, quitting." 03:50 <+JM-IRCRelay> [mrnice] I am trying to sweep the wallet. 03:51 <+JM-IRCRelay> [mrnice] Is it an absurd value? 03:53 < waxwing> mrnice, if you're happy to pay more than 150000 satoshis per kB, then you can reset the value of absurd_fee_per_kb in the config. 03:54 < waxwing> the most likely way for this to happen is if you have tx_fees = 1 in the config, which means it uses the 1 block fee estimate from Core, which sometimes is unreasonably high. 03:54 < waxwing> if that is the situation, then reset tx_fees from '1' to '3' or higher, even figures higher than '10' can confirm in a reasonable time, often 03:55 <+JM-IRCRelay> [mrnice] waxwing: I have not made any modifications to the config... checking now what is there. 03:55 < waxwing> mrnice are you using bitcoin core? 03:56 <+JM-IRCRelay> [mrnice] core yes. tx_fees = 3 03:56 <+JM-IRCRelay> [mrnice] waxwing: 03:57 < waxwing> ok; can you do "estimatefee 3" with rpc? 03:57 < waxwing> everything i'm seeing looks sensible at the moment; blockcypher's reporting high per kB at 80 sat/b, my Core is estimating 68 sat/b for 3 block conf 03:59 <+JM-IRCRelay> [mrnice] waxwing: core returns 0.00196692 03:59 < waxwing> wow, for estimatefee 3? 03:59 < waxwing> that's .. out of whack for some reason 04:00 <+JM-IRCRelay> [mrnice] yeah. looks like. What can I do? 04:00 < waxwing> it has been common for a long time for 'estimatefee 1' to report very high values, but almost always it's much more reliable for 3+. i've never seen 3 as high as that 04:00 < waxwing> mrnice well, what does it give for 4,5,6 etc? 04:01 < waxwing> if i were you i would just reset tx_fees to whichever of those numbers looks normal-ish. you can take sites like bitcoinfees.github.io for example to give you a guide 04:01 < waxwing> but i don't know why your Core instance is showing such a weird number. has it recently been restarted perhaps? 04:02 <+JM-IRCRelay> [mrnice] waxwing: 4: 0.00069651; 5: 0.00064527; 6: 0.00056324; 7: 0.00056324; yes restarted about 30min ago. 04:02 <+JM-IRCRelay> [mrnice] but up to date. 04:02 <+JM-IRCRelay> [mrnice] the blockchain is up to date. 04:03 < waxwing> that must be it, i guess. interesting, a point to pay attention to. my estimatefee 3 is 69k and my estimatefee 2 is 77k 04:03 < waxwing> well, this is exactly why i put in the absurd check :) 04:03 < waxwing> annoying though, for sure 04:04 <+JM-IRCRelay> [mrnice] hm. so anything around 50k is reasonable at this time? 04:05 < waxwing> this gives a nice visualisation: https://bitcoinfees.github.io/#3h 04:05 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 265 seconds] 04:05 < waxwing> there's tons of other sites giving similar info. 04:07 < waxwing> so again, just reset tx_fees to 4 or 5 or something like that 04:07 <+JM-IRCRelay> [mrnice] ok, thanks. So the parameter is an estimate of fees for number of blocks to be included. Right. thanks. 04:08 < waxwing> yeah it's misnamed but it's explained in the comment above i thin 04:08 < waxwing> think 04:09 <+JM-IRCRelay> [mrnice] got it. thanks. 04:11 <+JM-IRCRelay> [mrnice] waxwing: It is a real pleasure btw to be able to chat to the devs of JM here through IRC and getting useful hints etc. 04:13 < waxwing> hey, no problem :) 04:24 < waxwing> used JM for a retail payment (via bitpay) today for the first time in a while, things are pretty much the same as ever, worked smoothly first time, but you do still need to bump your -N to account for the "sink" participants. (request 5, get 3 in this case) 04:25 < waxwing> that reminds me re: 693 belcher i'll add a comment about separating out at least two different threats/attacks/issues: the economic one and the DOS one (maybe a snooping one too, a more speculative point) 04:30 <+JM-IRCRelay> [mrnice] btw: is it possible to sweep all levels from a JM wallet at the same time? I guess this may compromise the levels security and is hence not recommended? 04:31 < waxwing> yeah we explicitly don't provide that because it defeats the point of having your funds in a JM wallet in the first place (well, at least somewhat). and it can affect others' privacy too. 04:32 < waxwing> the most convenient "get funds out" option available, at least the cheapest, is to use -N 0 so you can direct-send without coinjoin or IRC, from each mixdepth. 04:32 < waxwing> i mean you can also export private keys but i'd never recommend messing around with that, personally. 04:36 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket 04:37 <+JM-IRCRelay> [mrnice] ok. thanks for the info. 04:38 <+JM-IRCRelay> [mrnice] my wallet just takes over 1h just to fast sync by now... have over 150000 in the index_cache. 04:39 < waxwing> damn, 150k? that's huge. is that the sum of the values in index_cache, or the largest? 04:40 <+JM-IRCRelay> [mrnice] the two largest ones. the others are just a couple of 100. had an infinite loop problem running for at least 2 days... 04:40 < waxwing> i've been running this wallet for at least 6 months and i have: [[8, 1842], [4, 2141], [2, 1671], [1, 1076], [2, 976]] 04:41 <+JM-IRCRelay> [mrnice] chatted to becher about this yesterday. As a result I had a 1.8gb logfile and filesystem filled up, wallet.json was empty file etc. 04:41 < waxwing> oh i vaguely saw discussion of that, sorry i'm not up to date on it. it may be that you can remove it if it's inaccurate then. sorry don't know details. 04:42 <+JM-IRCRelay> [mrnice] I sent him log extracts fr debugging... The quickest to get up and running again will be to sweep to a new wallet I think. An this will take me best part of a day *probably*. 04:43 < waxwing> yes i see the dilemma. i'd have to look into it to know more 04:44 <+JM-IRCRelay> [mrnice] I think i have a solution now so no probs. just need to execute it. 05:30 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer] 05:30 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #joinmarket 05:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 05:33 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 05:46 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection] 05:46 < waxwing> lol! 05:46 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection] 05:46 < waxwing> Oct 19 01:43:20 waxwing https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/merbinnertree.py <--- possibly a proof-of-set-nonmembership thing you were looking for? 05:47 -!- juscamarena [~justin@47.148.176.74] has joined #joinmarket 05:47 < waxwing> on Oct 19 you pointed it out to me, then on Jan 2nd I pointed it out to you, neither of us remembered :) 05:47 -!- Netsplit *.net <-> *.split quits: Aleph0 05:47 -!- Netsplit over, joins: Aleph0 05:51 < waxwing> yes, reading the logs, it seems adlai proposed more or less exactly what is in the gist on Oct 19. but i also raised a potential attack vector coming out of this approach, i think it's worth repeating it. i'll pastebin a chunk of the log. 05:55 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 258 seconds] 05:56 -!- roasbeef [~root@104.131.26.124] has joined #joinmarket 06:07 < waxwing> https://0bin.net/paste/xABFzLjsWAyNiUbf#bWRLblIqSKHWvhoW0UZp+4sS6wGPepYyv3eYA6mzxz4 06:07 < belcher> mrnice you dont need to have index cache 150000 if theres no bitcoins in the addresses that far 06:07 < belcher> that infinite loop created addresses but didnt put any bitcoins in them 06:10 < belcher> reading the log waxwing 06:12 < belcher> in that log you're talking about quadratic blowup of the proofs 06:12 < belcher> im sure youre aware that merkle proofs can be combined 06:13 < belcher> the maker would actually send just one tree, with many nodes going down and reaching many leaves 06:14 < belcher> the biggest issue with the sorted merkle tree thing is convincing the takers that the commitment is actually of the real maker's wallet 06:15 < waxwing> i don't know about quadratic, but afair the question was mostly about how many proofs you need to publish, ofc it's understood that only one tree is used. 06:16 < waxwing> i think for my own case, i'll find it a bit easier to think about this if we sketch out the protocol; i guess you have the root being published in the offer, right, and in the gist somewhere you talk about proofs being offered at signing time? 06:18 < belcher> id imagine the root is published in an irc message before offers, the root is associated with the irc nick not with each order 06:18 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 06:18 < belcher> !root r34r325345345234!reloffer blahblahblah!absoffer blahblahblah 06:18 < waxwing> ok. but utxo set changes on reannouncement? or, i think you were already discussing that earlier. 06:18 < belcher> yep so if the maker reannounces offers they have to reannounce a new merkle root 06:19 < belcher> adlai had a good point its not proof-of-set-nonmembership but proof-of-sets-null-intersection 06:20 < waxwing> yes it's a good point, but i'm not aware of any math/crypto trick that allows us to do that 06:22 < waxwing> what do you think about my concern at the top of that paste? i believe without verification this creates a risk, doesn't it? 06:23 < belcher> yes 06:23 < belcher> wait no 06:23 < belcher> the scheme i wrote about doesnt involve banning utxos, only makers+merkleroots 06:24 < waxwing> i find it confusing too :) but: you ban merkleroots, but on what basis? 06:25 < waxwing> i guess the basic scenario is to consider tree M1 containing utxo U1 and tree M2 containing U1 also, while M1 is honest and M2 is fake, has "found" U1 on the blockchain. i *think* that was the idea. 06:26 < belcher> if theres a proof that the merkleroot isnt a genuine commitment to the maker's wallet 06:26 < belcher> a thing with that is its quite hard to learn what UTXOs other makers have, because of #156 and podle 06:27 < waxwing> well it's easy to distinguish maker change-outs :) if you only want to know some, not specifically which. 06:28 < waxwing> heck, if you're working probabilistically, it's fine to use the cjouts too :) 06:30 < belcher> if you learn the maker's utxos, you still construct the same merkle root as them 06:30 < belcher> you can get your own merkle root banned, not anyone elses 06:31 < waxwing> but wasn't part of the plan to require proofs of non-set membership of other makers' utxos? 06:31 < belcher> yes 06:31 < belcher> i dont see the attack sorry 06:33 < belcher> also the genuine owner of the utxo sends a signature for it the same time 06:33 < belcher> these proofs get sent to the taker at the same time as !sig in the scheme i wrote 06:35 < waxwing> yes, i think you're right. 06:37 < belcher> i thought of something yesterday, not written it down yet 06:37 < belcher> in my scheme the other honest makers will re-upload proofs of fraud to new takers 06:38 < belcher> but the fraudulent maker can see this, if they get found out they could just swap two utxos in their wallet and get a new merkle root... which is good until they get found out again 06:38 < waxwing> for the economic attack it seems OK to wait until !sig to get a "full" proof of honesty; if there are N fake bots and 1 honest one, it doesn't matter modulo practical problems, there is no economic advantage. 06:39 < belcher> so we still have the problem of convincing the taker that the merkle root is really a commitment to the real wallet 06:39 < waxwing> belcher: yes it occurred to me just now reading it, that publishing proof-of-fraud to others has limited value, but doesn't hurt either. 06:42 < waxwing> belcher: so the concern is, one can fake and get away with it some of the time at least (e.g. just swapping a pair of utxos and hoping you don't get found out for a bit)? 06:42 < belcher> yes 06:43 < belcher> there is that idea already written where the taker chooses random numbers and the maker has to send those indicies 06:44 < belcher> so the taker could ask the maker to reveal 10% of their utxos or something, which means a maker thats swapped two utxos get found out 10% (?)of the time 06:44 < waxwing> sure. this was one of the reasons i never got too enthused, i was more hoping to find a "complete" type of proof, but maybe this could be good enough. don't really have a handle on it. 06:44 < belcher> more than 10% i realise 06:47 < waxwing> so the protocol alterations - !root <> + offers, !tx (+challenges) -- !sig ? or are there more? 06:51 < belcher> when a new taker says !orderbook the other makers send !fraudproofinv , the new taker sends !getfraudproof to one taker and gets !fraudproof 06:51 < belcher> btw !tx doesnt need an extra (challenges) because the maker knows what utxos to send a proof for since they're in the unsigned transaction 06:51 < waxwing> ok, i was thinking of your proposed "indices" bit 06:52 < waxwing> but, not saying it should be there 06:52 < belcher> oh yes 06:52 < belcher> forgot about that, yes that would go in the !tx bit 06:53 < waxwing> was there a typo here? " the new taker sends !getfraudproof to one taker and gets !fraudproof " 06:55 < belcher> should be "to one maker" 06:55 < belcher> its the same idea as INV messages in the bitcoin p2p protocol, to stop duplicate information being sent 06:56 < waxwing> yeah i can't quite decide whether it's that useful to do this part, since a smart attacker just reconnects with a new fake tree. but, either way. 06:57 < belcher> yeah :( 07:00 < waxwing> belcher: did you read Todd's blog post on audits recently, specifically one-time seals. i wonder if there might be any overlap. 07:00 < belcher> nope 07:00 < waxwing> https://petertodd.org/2016/commitments-and-single-use-seals 07:01 < waxwing> i mean, probably not, but it's an interesting set of thoughts 07:01 < belcher> always good to have reading material 07:01 < belcher> i think thats ultimately how we'll think of a solution, reading lots and talking to people 07:17 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #joinmarket 08:00 < belcher> despite the price rally, the volatility is still quite low 08:00 < belcher> volatility is often low on the way up and higher on the way down, but it can be high on the way up if people are mindlessly buying and speculating 09:17 <+JM-IRCRelay> [belcher] mrnice if you use joinmarket often, would you be able to try out the code from pull-request? https://github.com/JoinMarket-Org/joinmarket/pull/662 09:17 <+JM-IRCRelay> [belcher] its for broadcasting transactions through a new connection through tor, so your ip address for sure cant be linked to it 09:22 <+JM-IRCRelay> [mrnice] yeah sure no problem, but it would take a couple of days, maybe coming weekend. Is that ok? 09:23 <+JM-IRCRelay> [belcher] yeah no problem 09:23 <+JM-IRCRelay> [belcher] let us know if you need help setting up the code from the tor-broadcast branch 09:57 -!- quitobro [b84b6304@gateway/web/freenode/ip.184.75.99.4] has joined #joinmarket 09:58 < quitobro> has anyone seen this error/bug output before after running a yield generator script for a while? 09:58 < quitobro> BUG ERROR: wallet balance (1.97605176) does not match balance from history (1.97604992) BUG ERROR: wallet utxo count (3) does not match utxo count from history (2) 10:03 < belcher> yes that sometimes happen.. its not actually know why but it seems to be to do with whether you have unconfirmed transaction (?) 10:03 < belcher> for many people the message seems to come and go 10:20 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 248 seconds] 10:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 10:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 11:11 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 11:12 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 11:35 -!- Netsplit *.net <-> *.split quits: Taek, coins123, luke-jr 11:35 -!- luke-jr [~luke-jr@2001:470:5:265:a45d:823b:2d27:961c] has joined #joinmarket 11:36 -!- luke-jr [~luke-jr@2001:470:5:265:a45d:823b:2d27:961c] has quit [Changing host] 11:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 11:36 -!- coins123 [~coins123@31.157.172.232] has joined #joinmarket 11:36 -!- coins123 [~coins123@31.157.172.232] has quit [Changing host] 11:36 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 11:36 -!- Netsplit over, joins: Taek 12:11 -!- quitobro [b84b6304@gateway/web/freenode/ip.184.75.99.4] has quit [Ping timeout: 260 seconds] 12:41 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #joinmarket 13:10 < belcher> https://www.deepdotweb.com/2017/01/03/bayesian-method-deanonymising-large-percentage-bitcoin-transactions/ 13:10 < belcher> paper: https://arxiv.org/pdf/1612.06747v3.pdf 13:10 < belcher> " To utilize our model, we carried out experiments by installing more than a hundred modi ed Bitcoin clients distributed in the network to observe as many messages as possible" 13:12 < belcher> paper actually has quite a nice explanation of this method of linking ip address to tx 13:14 < belcher> ironically enough web wallets and some lightweight wallets like electrum resist this attack better because they are centralized 13:16 < belcher> interesting i found this paper on the same day i finished the tor broadcast method PR 13:21 < belcher> the paper also say "Cheating (e.g. including invalid transactions in the blockchain) thus would require one entity to control more than 50% of the computing power that users dedicate to generating the blockchain" which is of course not true 13:35 < belcher> btw i found this on r/btc, presumably they upvoted it to pump monero 13:41 < belcher> other cryptocurrencies are also vulnerable to this attack btw, maybe more if they dont have the trickle tx relaying thing that bitcoin does 13:45 < belcher> As a result, 22363 users could be identified, and altogether 1797 IP addresses were assigned to them. The imbalance is caused by three outstanding IP addresses to which 20 680 users are assigned 13:45 < belcher> presumably the ip addresses of blockchain.info's web wallet 13:48 < belcher> For the remainder data, 1.07 IP addresses belong to one user on average. This is due to the fact that a user can use multiple IP addresses when connecting to the Bitcoin network. The maximum number of IP addresses identified as belonging to a single user is 11. 13:50 < belcher> this data collection happened during the late-2013 rally.. and they match the balances of the wallets and you can see the amounts change alongside the exchange rate, fascinating 13:51 < belcher> there could be some trading house doing this kind of collection and taking positions on the market based on it 13:52 < waxwing> belcher: so the study is from 2013? 13:52 < belcher> yes but only published a week ago 13:52 < belcher> not even published, on arxiv 13:52 < waxwing> hungarians 13:52 < waxwing> i see, rather interesting. x-post to wizards perhaps? 13:53 < waxwing> i guess it's not *technically* on topic there, arguably 13:53 < belcher> too late kek 13:53 < waxwing> just seems like the only place where people would be interested 13:53 < waxwing> yeah not like you're drowning anything out :) 13:54 < belcher> its weird they didnt seem to find any electrum wallet users 13:54 < waxwing> i agree about getting a market edge with this, that had crossed my mind before. 13:54 < belcher> unless one of those 3 ip addresses were actually electrum servers... but there are far more than 3 electrum servers 13:54 < waxwing> well not like "i'm sure you can get a market edge with this", more just seems obviously something people would try 13:55 < waxwing> in 2013 there were only like 5-10 iirc 13:55 < belcher> ah ok.. til 13:55 < waxwing> it's a stretch but when i first installed it in apr/may 13 i don't think i saw more than 5 on the list. but meh that's hard to remember. 13:56 < belcher> "We found a signifcant -0.91 linear correlation coefficient between the total amount of Bitcoin owned by the identified users and the exchange rate during the measurement period." 13:56 < belcher> so users who make regular transactions either sold, or handled less bitcoins as the exchange rate went up (maybe because all their economic activity was in USD not BTC?) 13:57 < waxwing> i think the latter is a reasonable first hypothesis 13:57 < waxwing> well there is no former :) 13:58 < waxwing> 0.91 is remarkably high, suspicious even 13:58 < belcher> this method requires the users to make several transactions 13:58 < belcher> they are finding people who use bitcoin a lot, not holders 13:58 < waxwing> what's the data collection period exactly? when in 2013? 13:59 < belcher> october to december 13:59 < waxwing> so post SR shutdown 13:59 < belcher> if someone uses tor or something like that then their baysian probability for the user match will never get above 0.5 so they are excluded 14:02 < belcher> they geolocate all the ip addresses so you get a geographic distribution of bitcoin users, and international bitcoin flows 14:02 < belcher> ARG is argentina right? thats the only surprising country in there in a significant amount 14:02 < waxwing> yeah figure 10, can't make much sense of it personally 14:03 < gmaxwell> that pages assumptions about relay don't match the actual behavior of nodes today. 14:03 < gmaxwell> e.g. they say if you have less than 20 peers you'll announce to all of them in under two seconds. 14:03 < belcher> yes, 2013 after all 14:03 < waxwing> arg-deutschland and nederlands-china . nah, that's clearly an artifact. 14:03 < gmaxwell> oh 2013, yes it would have been true then. 14:04 < belcher> what do nodes do today instead? 14:05 < waxwing> it's kind of amusing, it reminds me of brad setser reading the tea-leaves of treasury purchases data to try and figure out where the chinese were buying their bitcoin^H^H US treasuries .. ended up like belgium were "buying" half their countries GDP in UST. 14:05 < gmaxwell> belcher: there is a feerate sorted queue per peer, which gets announced based on a possion counter, with an expected time between announcements of 10 seconds for inbound peers, 5 seconds for outbound peers. Transactions that confirm, expire, get replaced, or are offered by the far side before the timer goes off aren't announced. 14:06 < gmaxwell> belcher: there are a number of further improvements I want to make to it, but thats where it is now. 14:07 < belcher> do announcements contain many txes? so they are in batches 14:08 < gmaxwell> yes, usually many now. 14:08 < gmaxwell> which was part of the purpose of the change. 14:08 < gmaxwell> They're technically 'decendant depth, feerate, id' sorted, so that parents are also always relayed before their children, which reduces use of the orphan pool. 14:08 < belcher> so it sends the higher fee-rate transactions first, then might be harder to track a transaction spreading across the network when higher fee ones spread at different speeds to lower fee ones 14:09 < gmaxwell> the difference in send time between high and low fee is small to zero though, only really matters when there are so many at once that it hits the maximum in the batch. 14:10 < gmaxwell> but the batching provides pretty considerable arrival time privacy. 14:12 < waxwing> good thing people actually use bitcoin so much :) 14:13 < gmaxwell> https://0bin.net/paste/JdDZXU4G-cFWsmTm#vkDTyx-9TfKemwVBQUFQqTAHhD+RVpLCVvKgItnPGLq 14:13 < waxwing> somebody seems to be !orderbooking every 20 seconds or so. oh well shrug. 14:13 < gmaxwell> ^ histrogram of my recieved inv sizes, keep in mind my peers also include older nodes that don't really batch. 14:13 < gmaxwell> (first column is the number of observations) 14:15 -!- quitobro [b84b6304@gateway/web/freenode/ip.184.75.99.4] has joined #joinmarket 14:15 < quitobro> hey guys 14:15 < quitobro> has anyone figured out a way to run a yield gen script as a background process? 14:15 < belcher> i use screen 14:15 < gmaxwell> https://0bin.net/paste/cw2IAHrR8Ni7VdhO#aURyN1WjUXyR6ak24l09H0mDg23RVTPKzofrTQuNT-z < there is my sent, probably more useful. 14:15 < quitobro> i've tried `python yield-gen-basic.py wallet.json &` (where the & ampersand background the process) 14:16 < quitobro> but then i need to enter my decryption passphrase for the wallet and it's not properly sent from STDIN back to the progrma 14:16 < belcher> what are the column labels gmaxwell ? 14:16 < belcher> quitobro use "screen" 14:16 < waxwing> yeah screen is the one i've used in the past too, belcher was the one who pointed me at it 14:16 < gmaxwell> belcher: count, number of txn in an inv. 14:16 < quitobro> cool i use tmux locally (i'm a web dev) - basically the same thing yea? 14:16 < belcher> then run yieldgen normally, then use ctrl+a + d to detach, then "screen -r" to go back 14:17 < waxwing> i've heard tmux as an alt. but never tried it. 14:18 < gmaxwell> so 32.3% of the invs I send have 10 or more txn in them. 14:19 < waxwing> what causes the majority of inv messages to hvae only 1 tx? 14:19 < waxwing> sorry noob question, never looked into it 14:19 < belcher> low traffic i assume 14:19 < waxwing> yeah seems so unlikely nowadays :) 14:19 < gmaxwell> low traffic or the possion process just has a low delay sometimes. 14:20 < gmaxwell> the low delays help randomize the overall ordering of transactions in the network... e.g. sometimes a txn will escape me fast and go to you quickly, then escape you.. and it will look like it came from closer to you than me. 14:22 < quitobro> heeeeeeeey this screen thing works pretty easily! thanks guys 14:22 < quitobro> in general what other services are competing with coinjoin/joinmarket? 14:23 < belcher> its not a for-profit project so i wouldnt use the word competition, but other ones might be tumblebit, centralized tumblers and bc.i's sharedsend thingy 14:24 < waxwing> it's a for profit project for some of the users :) 14:25 < belcher> oh yeah 14:25 < quitobro> bc.i discontinued that feature last i checked 14:25 < quitobro> is tumblebit live? 14:25 < belcher> nope 14:26 < belcher> it can be used on testnet from what i see 14:26 < belcher> they have a slack channel where you can talk to them 14:26 < quitobro> yea that's what i thought... i guess i was expecting more activity in this service considering the limited alternatives (i recently got scammed by bitcoin fog, that's what drove me here) 14:26 < waxwing> whoever is !orderbook-ing several times a minute, if you're here, you know that isn't needed right? :) it just spams up our logs. 14:28 < belcher> quitobro how is it compared to bitcoinfog? slightly harder to use i imagine :p 14:29 < belcher> does bitcoinfog warn you against amount correlation these days? it was famously broken with that method here https://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/ 14:33 < quitobro> belcher i sent a deposit and it never showed up - i suspect selective scamming 14:33 < quitobro> belcher how is what compared to bitcoin fog, coinjoin/joinmarket? 14:34 < belcher> yeah 14:43 < belcher> if anyone creates coinjoins with any regularity it would be great if you could try out this feature https://github.com/JoinMarket-Org/joinmarket/pull/662 14:48 -!- quitobro [b84b6304@gateway/web/freenode/ip.184.75.99.4] has quit [Ping timeout: 260 seconds] 16:00 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket 16:21 < grubles> what is with the !orderbook spam 16:21 < belcher> idk 16:21 < belcher> its possible its some accidental infinite loop? someone set some script to keep trying to send until it succeeds and it never gives up? 16:22 < grubles> it seems to be a different irc nick each time 16:27 < belcher> a new nick is generated when they disconnect and reconnect 16:27 < grubles> right 16:27 < grubles> what if you run ob-watcher.py 16:27 < grubles> ? 16:28 < belcher> ob-watcher wouldnt result in this 16:29 < grubles> what if you continually click the "check for expired orders" or whatever the functionality is (cant remember off the top of my head) 16:29 < belcher> it wouldnt change the nick though 16:29 < grubles> ok 16:30 < grubles> wasn't sure 16:30 < belcher> still only about half the bots on agora as on CGAN 16:31 -!- Giszmo1 [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #joinmarket 16:32 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Read error: Connection reset by peer] 16:34 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #joinmarket 16:34 -!- Giszmo1 [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Read error: Connection reset by peer] 17:45 -!- fqtw [~me@port-92-192-68-135.dynamic.qsc.de] has quit [Ping timeout: 272 seconds] 18:01 < GithubBot5678> [joinmarket] chris-belcher opened pull request #695: Removed configurable mixdepths from yieldgens, also reworded error message (develop...yg-fixup) https://github.com/JoinMarket-Org/joinmarket/pull/695 18:03 < belcher> need to figure out the github-merge.py script, im opening too many PRs 18:23 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 18:26 -!- freespirit [ac624354@gateway/web/freenode/ip.172.98.67.84] has quit [Quit: Page closed] 19:20 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 258 seconds] 19:34 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket 21:36 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 245 seconds] 21:36 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 250 seconds] 21:49 -!- grbs [~grubles@unaffiliated/grubles] has joined #joinmarket 21:50 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 22:01 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 248 seconds] 22:01 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 248 seconds] 22:14 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket 22:14 -!- grbs [~grubles@unaffiliated/grubles] has joined #joinmarket 22:39 -!- grbs [~grubles@unaffiliated/grubles] has quit [Ping timeout: 258 seconds] 22:39 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 248 seconds] 22:52 -!- grbs [~grubles@unaffiliated/grubles] has joined #joinmarket 22:52 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket