--- Day changed Mon Jan 02 2017 04:38 -!- DrRobotic [~DrRobotic@unaffiliated/drrobotic] has joined #joinmarket 05:05 -!- fqtw [~me@port-92-192-44-99.dynamic.qsc.de] has joined #joinmarket 05:51 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #joinmarket 06:41 -!- jouke_ is now known as Jouke 06:43 < belcher> since our modified bitcoin library is now better than the original pybitcointools, should we make it a separate repos for other people that might need it? 07:01 -!- DrRobotic [~DrRobotic@unaffiliated/drrobotic] has quit [Quit: Leaving] 07:13 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection] 08:32 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 09:32 -!- quitobro [640c6e95@gateway/web/freenode/ip.100.12.110.149] has joined #joinmarket 09:44 < midnightmagic> belcher: People like myself would appreciate it. :) 09:44 < midnightmagic> belcher: Is it in a scripting language? 09:44 < belcher> its in python 09:44 < midnightmagic> belcher: People like myself would appreciate it. :) x 2 09:44 < belcher> its based on pybitcointools but with lots of fixes, tests and it uses libsecp256k1 09:45 < midnightmagic> I can't think of anything I would use it for immediately but availability of fresh and especially actively-used software is extremely valuable. 09:45 < belcher> maybe we could put back the pure python functions in case people dont want to install libsecp256k1 09:46 < belcher> pybitcointools is unmaintained, i dont think they ever fixed the highS, and vbuterin has gone on to code scamcoins 09:46 < gmaxwell> they did finally fix it so it wouldn't accept 0,0 as a valid signature for any pubkey,message. 09:47 < belcher> oh man i forgot about that 09:48 < gmaxwell> better than his "ed25519" code that uses H(privatekey) as the nonce, which last I checked is still unfixed. 09:51 -!- iinaj [sid110431@gateway/web/irccloud.com/x-tumzdqxemyncepgy] has quit [Ping timeout: 245 seconds] 09:52 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-cfqbxjjntlhvgzlk] has quit [Ping timeout: 260 seconds] 09:55 -!- iinaj [sid110431@gateway/web/irccloud.com/x-wxueyiozpvggdlhu] has joined #joinmarket 09:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-euxyuxjomobthsex] has joined #joinmarket 10:13 -!- deafboy [quasselcor@cicolina.org] has quit [Remote host closed the connection] 10:31 -!- xpub [5fd394c6@gateway/web/freenode/ip.95.211.148.198] has joined #joinmarket 11:21 -!- deafboy [quasselcor@cicolina.org] has joined #joinmarket 12:03 -!- quitobro [640c6e95@gateway/web/freenode/ip.100.12.110.149] has quit [Ping timeout: 260 seconds] 12:09 -!- kreate1994 [~kreate199@112.210.192.250] has joined #joinmarket 12:15 < fluffypony> belcher: might be worth dropping the fork and re-pushing it to a new non-fork repo 12:15 < fluffypony> call it pybitcointools-classic or something 12:15 < fluffypony> because forks are hidden from searches on Github 12:15 < fluffypony> so your fork won't show up 12:43 < kreate1994> what is this about? 12:43 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 12:55 < belcher> haha 12:56 < belcher> kreate1994 since our modified bitcoin library is now better than the original pybitcointools, should we make it a separate repos for other people that might need it? 13:06 * midnightmagic stabs the huge extra string that appending -classic does to a name. 13:15 <+JM-IRCRelay> [mrnice] Would like to report a problem I just encountered: When the jm hosted filesystem is full, wallet.json ends up with a siero size file. 13:15 <+JM-IRCRelay> [mrnice] zero. 13:20 < belcher> hmm 13:21 < belcher> you'd think it would raise an exception 13:21 < belcher> idk how python behaves when the filesystem is full 13:22 <+JM-IRCRelay> [mrnice] it did. When I ctrl-c'd the script and tried restarting, I found the wallet file zero size... 13:22 < belcher> wow theres nothing on google about it 13:22 < belcher> i guess its specific to bitcoin a bit since a full node slowly fulls up your disk 13:22 < belcher> non-pruned 13:23 <+JM-IRCRelay> [mrnice] the bitcoind writes to a seperate fs 13:24 <+JM-IRCRelay> [mrnice] It was the logging part of jm that ate up the free space... ended up with a 4Gb logfile ;-) 13:24 < belcher> wow 13:25 < belcher> do you have the mnemonic seed? 13:25 < belcher> of your wallet 13:25 <+JM-IRCRelay> [mrnice] yeah. still not quite sure what is in it... 13:25 <+JM-IRCRelay> [mrnice] yes, sure do have. just trying a more recent backup now tho. Will that miss some of the later used addresses? 13:26 <+JM-IRCRelay> [mrnice] restoring from seed takes *forever* on a RPI 2. 13:26 <+JM-IRCRelay> [mrnice] Specially with all the spamming that we had some time back... 13:26 < belcher> unfortunately :( 13:27 < belcher> mrnice open up the backup of wallet.json and look at the index_cache 13:27 <+JM-IRCRelay> [mrnice] yes? 13:28 < belcher> if you increase the numbers in there and run joinmarket with --fast it should get you your addresses back without rescanning 13:28 < belcher> "index_cache": [[237, 5309], [164, 6616], [250, 6618], [221, 5697], [166, 5036]] 13:29 < belcher> the second number in each tuple is the external branch (the ones in the 5000s) 13:29 <+JM-IRCRelay> [mrnice] got the numbers, yes. Increase by how much? 13:29 < belcher> depending on how long ago the backup was 13:29 <+JM-IRCRelay> [mrnice] "index_cache": [[6, 728], [0, 931], [0, 1139], [0, 802], [0, 795]] 13:29 < belcher> how many addresses were requested since then 13:29 <+JM-IRCRelay> [mrnice] This is from end oct. 13:30 <+JM-IRCRelay> [mrnice] been running 0.2.2 since then. 13:31 < belcher> okay well i _think_ if you just increase it by 100 and use --fast it shouldnt matter if you increase by too much 13:31 <+JM-IRCRelay> [mrnice] so this is the *old* jm wallet file, which was moved to 0.2.2 13:31 < belcher> waxwing would know better since he coded --fast 13:31 < belcher> 0.2.2 didnt change anything about the wallet format 13:31 <+JM-IRCRelay> [mrnice] let me try it then and see if all coins are found. Is the 4gb log file not strange? 13:32 <+JM-IRCRelay> [mrnice] this is over a couple days. 13:32 < belcher> it is.... my biggest log file is about 10mg and its been running for a long time 13:36 <+JM-IRCRelay> [mrnice] Seems to have a long string of never ending "wrongly selected stale utxos! utxo_data = [None]" messages. 13:36 <+JM-IRCRelay> [mrnice] When trying to do a cj... 13:36 <+JM-IRCRelay> [mrnice] which caused the problem. This went on for 2 days. 13:37 < belcher> arent you running yield generator? 13:37 < belcher> hmm no, are you running with a full node? 13:38 < belcher> running with blockr mightve caused that since last few days its been broken 13:39 <+JM-IRCRelay> [mrnice] full nod with yg, yes. 13:39 <+JM-IRCRelay> [mrnice] I also see "Could not spend from a mixdepth which is not max" towards the end of the logfile. 13:41 <+JM-IRCRelay> [mrnice] I see the logfile also give a more recent "key=index_cache" version... 13:42 < belcher> ah good find 13:42 < belcher> i have no idea what caused the repeated line.. 13:43 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 258 seconds] 13:43 <+JM-IRCRelay> [mrnice] I is not one line, but several reapeated cj attempts seemingyl failing in the same error(s). 13:45 < belcher> did you say all those lines were one after another? 13:45 < belcher> very soon after each other (since they all have timestamps) 13:45 < belcher> this loop here could become an infinite loop if populate_utxo_data() always failed https://github.com/JoinMarket-Org/joinmarket/blob/78470c3aeeff31595f21eb70de179edb235e096d/joinmarket/maker.py#L72-L80 13:47 < belcher> for example: 13:47 < belcher> 2016-10-27 18:39:22,231 [MainThread ] [DEBUG] key=on_order_seen 13:47 < belcher> 2016-10-27 18:39:22,265 [MainThread ] [DEBUG] > 13:47 < belcher> 2016-10-27 18:39:22,266 [MainThread ] [DEBUG] key=mc_status 13:47 < belcher> the timestamps are on the left there 13:51 <+JM-IRCRelay> [mrnice] This error logged about every 2s with lots of other stuff inbetween for about 2 days until the fs was full. 13:52 < belcher> ok i guess 2 seconds is the time it takes for the rpc listunspent to happen 13:52 <+JM-IRCRelay> [mrnice] 2016-12-29 13:25:29,011 [MCThread ] [DEBUG] wrongly selected stale utxos! utxo_data = [None] 13:52 <+JM-IRCRelay> [mrnice] 2016-12-29 13:25:30,803 [MCThread ] [DEBUG] wrongly selected stale utxos! utxo_data = [None] 13:52 <+JM-IRCRelay> [mrnice] 2016-12-29 13:25:33,141 [MCThread ] [DEBUG] wrongly selected stale utxos! utxo_data = [None] 13:52 <+JM-IRCRelay> [mrnice] 2016-12-29 13:25:35,759 [MCThread ] [DEBUG] wrongly selected stale utxos! utxo_data = [None] 13:52 <+JM-IRCRelay> [mrnice] this is "grep" output... 13:53 < belcher> i dont know what the cause of it is but i can fix the infinite loop filling up your disk 13:55 < belcher> in case you didnt know, you can use "tail" to only get the last few lines of a file so you dont have to print all 4gb to your terminal 13:55 <+JM-IRCRelay> [mrnice] yeah, thanks. am aware. 13:56 < belcher> also in that infinite loop it does update_cache_index() 13:57 <+JM-IRCRelay> [mrnice] Which would explain the zero length file? 13:57 < belcher> so if it ran out of disk space it wouldve been unable the wallet file and wouldve left an empty file 13:58 <+JM-IRCRelay> [mrnice] yeah. makes sense. 13:58 < belcher> id ask you to scrub your log file and upload it, but i dont think any pastebin can accept 4gb files 13:58 < belcher> perhaps if you somehow found where it started printing "wrongly selected..." and deleted everything after, then uploaded 13:59 <+JM-IRCRelay> [mrnice] I can see how much gzip would help. do you have an ftp dump? 13:59 <+JM-IRCRelay> [mrnice] This one is only 1.8gb I see now. The previous one was 4gb, seems like it has been going on for a while... 14:07 <+JM-IRCRelay> [mrnice] ;-) "python scrub-log.py xxx.log" -> File "scrub-log.py", line 31, in 14:07 <+JM-IRCRelay> [mrnice] logfile = fd.read() 14:07 <+JM-IRCRelay> [mrnice] MemoryError 14:07 <+JM-IRCRelay> [mrnice] seems too large to process in memory? 14:09 <+JM-IRCRelay> [mrnice] index_cache has large numbers of magnitude 150000+ 14:09 <+JM-IRCRelay> [mrnice] Does it make sense to move coins to a new wallet to increase processing speed? What is the recommended method? 14:10 < belcher> yeah scrub-log loads the entire file into RAM.. 14:11 < belcher> mrnice this infinite loop will have increased the numbers in your index_cache even though no new bitcoins were there 14:11 < belcher> so dont increase index cache to 150000+, ideally find the last index_cache value before the infinite loop started 14:11 < belcher> or just guess 14:12 <+JM-IRCRelay> [mrnice] oki, but I had previous wasted addresses from the spamming period. 14:12 -!- Evolyn_ [Evolyn@HSI-KBW-109-193-227-248.hsi7.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 14:15 < belcher> as long as you get all your bitcoins back 14:16 < xpub> quick question maybe someone can answer. Pantientsend will send to bip32 xpub. Is it a specific format (like joinmarket wallet) only or other xpubs like electrum? 14:17 <+JM-IRCRelay> [mrnice] belcher: do you still want to take a look at the logfile? 14:17 -!- kreate1994 [~kreate199@112.210.192.250] has quit [Read error: Connection reset by peer] 14:17 < belcher> yes mrnice 14:17 < belcher> xpub it wont send yet unless you get the latest version from github... i wrote that wiki page 2 days ago 14:18 < belcher> maybe i should put a nice saying ==not live yet, only in release 0.2.whatever== 14:20 < belcher> but to answer your question it sends to any xpub key but you if you have a master public key like from electrum you'll need to decend the tree a bit 14:20 < belcher> idk how much you know about hierarchical deterministic wallets, but they can have many branches and nodes 14:20 < xpub> it looked like a new feature. Is there a newer version than 2.2? 14:21 < belcher> nope 14:21 < belcher> ill add a short explaination of HD wallets to the wiki page as well.. 14:21 < xpub> I need to study up a bit. Very cool feature. 14:24 < xpub> this may be a dumb question, but when jm wallet is "importing 240 addresses into account" what roughly is it doing. importing addresses from core or into the core wallet? 14:26 < belcher> into the core wallet 14:26 < belcher> running the importaddress rpc call 14:28 <+JM-IRCRelay> [mrnice] belcher: I can trimmed the logfile to 1.9Mb 14:28 < belcher> great 14:30 <+JM-IRCRelay> [mrnice] belcher: can you accept the file on CG please? 14:36 <+JM-IRCRelay> [mrnice] pastebin: "You have exceeded the maximum paste size of 512 kilobytes per paste. PRO users don't have this limit!" 14:36 <+JM-IRCRelay> [mrnice] any ideas anybody? Have a 2mb logfile to share... 14:40 < belcher> how big is the file when compressed? maybe you could email me it 14:40 <+JM-IRCRelay> [mrnice] 142kb ok, doing that now. 14:40 <+JM-IRCRelay> [mrnice] DCC does not work here? 14:41 < belcher> yeah text normally compresses a lot 14:41 < belcher> idk DCC has always been dodgy.. 14:41 <+JM-IRCRelay> [mrnice] becler: are you not getting a DCC request? 14:41 < belcher> it requires a direct connection so any kind of things can go wrong.. i think it requires all your ports to be open 14:41 < belcher> my email is belcher@riseup.net 14:41 < belcher> otherwise i think bitcointalk forums allows attachments with PMs 14:42 <+JM-IRCRelay> [mrnice] belcher: dodgy as in problem ridden or security wise? 14:42 < belcher> problem ridden 14:42 < belcher> security wise too i guess hexchat doesnt have any particular bad bugs.. probably 14:45 -!- xpub [5fd394c6@gateway/web/freenode/ip.95.211.148.198] has quit [Ping timeout: 260 seconds] 14:56 -!- Empty2k12 [~Empty2k12@p4FEDFE63.dip0.t-ipconnect.de] has joined #joinmarket 14:58 < belcher> mrnice let me know what do you (if you sent the email already) 14:59 < belcher> last resort you could copypaste the file on a bitcointalk forum post, i bet the limits are larger 15:03 < lebeev> lol 15:04 < lebeev> cat log| curl -F 'sprunge=<-' http://sprunge.us 15:10 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 15:26 < instagibbs> Getting this after a while: 2017-01-02 18:22:52,239 [PingThread ] [WARNI] irc ping timed out 15:26 < instagibbs> 2017-01-02 18:22:52,240 [PingThread ] [INFO ] errored while trying to quit: error(9, 'Bad file descriptor') 15:26 < instagibbs> 2017-01-02 18:23:11,584 [PingThread ] [WARNI] irc ping timed out 15:26 < instagibbs> 2017-01-02 18:23:11,584 [PingThread ] [INFO ] errored while trying to quit: error(9, 'Bad file descriptor') 15:29 < adlai> belcher: thank you for writing this up! not to be a wet blanket, but waxwing and i already came up with this scheme, it's just not documented anywhere other than a bunch of lurkers' irc logs 15:29 < adlai> your writeup makes it much more digestible 15:30 < belcher> instagibbs thats been reported before once or twice.. never figured out why 15:30 < adlai> waxwing: sorry to hear you're ill! hope you at least were well to celebrate whatever of this season you celebrate 15:30 < belcher> adlai okay, well at least its written up now 15:30 < belcher> did you guys know about the sorted merkle trees? i got that from a conversation with someone in slack iirc 15:31 < adlai> yes. 15:32 < belcher> i was talking a bit to bramc whos written a small merkle tree library which does at least some of what we'd need for it 15:33 < belcher> since this merkle tree commitment would require revealing the number of UTXOs in the wallet, could there be a problem with passive observers learning something? 15:34 < adlai> of course. leakage leakage leakage! 15:34 * adlai finds the relevant bit of logs around oct 19th 15:35 < adlai> 2016-10-19 13:33:01 waxwing well that's what i meant about 'unique to transaction' (actually it would have to be unique to offer, wouldn't it) 15:35 < adlai> 2016-10-19 13:33:27 waxwing horrifying for many reasons i think, e.g. leaking the number of utxos even if perfectly hiding 15:35 < adlai> 2016-10-19 13:33:55 adlai it seems to me to be an inferior solution... although you could pad with dummy commitments 15:35 < adlai> 2016-10-19 13:33:59 waxwing yes, and the number of utxos changes at certain points, even worse 15:35 < adlai> 2016-10-19 13:34:19 waxwing padding: yeah just what that idea needs, more data :) /jk 15:35 < adlai> 2016-10-19 13:34:43 waxwing sometimes it seems like a good idea to mention bad ideas, though :) can spark new thoughts maybe 15:35 < adlai> 2016-10-19 13:35:06 * adlai bbl, errands; but this was a good brainstorm! 15:35 < adlai> 2 15:35 * adlai is not convinced that makers can't just dump new utxos in continuously 15:35 < instagibbs> belcher, ok, if there's anything I can do to get your more info let me know, it's the 2nd time I've seen it 15:36 < adlai> so the tree grows indefinitely (with log scaling) periodically you can flush 15:36 < belcher> i think your scheme is slightly different from mine, my one doesnt involve an indefinitely growing tree 15:45 < adlai> i think neither scheme is fully specified to the point where there's a large overlap between their eigenstates 15:45 < adlai> in other words - i think you imagine 'flushing' after each transaction, whereas i'm saying "if it's yellow, let it mellow" 15:47 < adlai> my point is that if trees could contain an arbitrary S/U ratio (spent/un), the average commitment depth gives snoops less info about tree size 15:47 < belcher> ah ok, keeping spent utxos in the tree for a while 15:48 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #joinmarket 15:48 < adlai> so each reannouncement needs a new root hash, but it could share most of the branches with previous one 15:48 < belcher> if you keep the TXOs in there even if they're spent, the root hash wont change 15:50 < adlai> sorry, you don't need a new root if you're reannouncing to exclude unconfirmed spends, you do need a new root when you want to include confirmed outputs 15:51 < belcher> so including confirmed outputs would require a new root but the same utxo-count 15:52 < belcher> since its the publicly-known utxo-count thats the problem isnt it 15:53 < adlai> hang on. why does the count need to be published? 15:54 * adlai rereads the gist, slowly 15:54 < belcher> i think you cant construct the right merkle tree without knowing the number of elements it has 15:55 < adlai> this sounds avoidable, but i'm not a professional voidologist 15:55 < belcher> the wikipedia page mentions something like this https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack 15:55 < belcher> hey maybe you could commit to the depth in the hash 15:55 < belcher> N = hash(depth | N_left | N_right) 15:56 < belcher> i only skimmed this.. now that i read it again i dont understand it 15:56 < adlai> i'm not sure the 2PIA is a practical pain-in-the-ass, so to speak 15:56 < adlai> "a document other than the original that has the same Merkle hash root" << "good luck" 15:57 < adlai> especially considering that in this case, the catastrophe of such a collision is not theft, but a SINGLE instance of a maker having multiple offers. 15:58 < adlai> for them to consistently have multiple offers, the hash function would need to nod just be weak, but... 15:59 < belcher> okay so lets go through it without the public utxo-count, the taker knows the merkle root, when it receives signatures it also gets a merkle proof that the maker owns the utxos it says it does, and doesnt own the utxos it says it doesnt 15:59 < belcher> could that proof, sent encrypted only to the taker, just contain the utxo-count? 16:00 < adlai> why should it? 16:00 < belcher> i think it can..... because even if the real tree was the wrong size you still need to get a sha256^2 collision to make a fake proof 16:00 < belcher> adlai you need to reconstruct the tree, maybe not with the utxo-count but at least a path-to-the-utxos 16:01 < adlai> so? 16:01 < belcher> i agree with you 16:01 < belcher> its not public so its fine 16:01 < adlai> the proof-of-exclusion requires makers to send a full path anyway 16:01 -!- fqtw [~me@port-92-192-44-99.dynamic.qsc.de] has quit [Ping timeout: 268 seconds] 16:01 < belcher> yep 16:01 < belcher> and only encrypted to the taker, so a passive observer doesnt see anything 16:01 < adlai> so if you have seven bajillion exclusion proofs, you have an O(7bj)-precise idea of how large the tree is 16:01 < belcher> okay so this problem is basically solved 16:02 < adlai> but good luck turning that into practical deanonimization 16:02 < adlai> *deanonimisation 16:02 < belcher> this is a nice link, if only for the gif image animation https://bitcoin.org/en/developer-reference#parsing-a-merkleblock-message 16:02 < adlai> all that's left now is to write the code! :D 16:03 < belcher> a while ago i was learning about bip37's merkleblock 16:03 < belcher> they have this flags thingy, a bit string 16:03 * adlai will have to queue this one (bip37) 16:04 < belcher> bip37 is the bloom filter p2p thing that breadwallet and multibit uses, it doesnt offer any privacy 16:04 < belcher> i was thinking about it for the connect-joinmarket-to-your-own-node method of syncing 16:06 < belcher> adlai so waxwing and you were talking about leakages earlier, was there anything else? 16:08 < adlai> i'm pretty sure at one point we tried estimating the data overhead of this scheme, and i spewed a bunch of nonsense which later while showering turned out to overloop some of the info 16:09 < belcher> well makers try to keep their UTXO-count low anyway to cheap out on fees, so i doubt the trees will be very big 16:09 < belcher> if you read bramc's code its all super-optimized because he expects it to have hundreds of millions of elements 16:10 < adlai> re:nodes, i have at times used a remote node, syncing its wallet from scratch and all. shouldn't it should be possible to keep multiple nodes synced on a wallet using the xpub, for failover? 16:10 < adlai> i don't think makers have a fee-incentive to reduce utxo count ~today~ 16:10 < belcher> if they ever want to spend their money they have to spend more in miner fees if they have more utxos 16:11 < adlai> for withdrawing, sure. you're right. i thought you meant during operation 16:11 < belcher> re:multiple nodes, i dont have anything against that idea 16:11 < adlai> although the utxosize distribution seems powerlawish, there are usually large utxos that suffice 16:11 < belcher> but i think multiple nodes would need to know when to skip addresses, i.e. a gap limit 16:11 < adlai> unless you're spending a large percent of the wallet 16:12 < belcher> ultimately people are saving in bitcoin and generating yield because one day they want to spend it on goods and services, so withdrawing is an important part of all this, at least thats my view and thats why i run with merge_algo = gradual 16:13 < belcher> btw any chance of you finishing that "use these different merge_algos depending on how many utxos you have" PR ? it was good 16:13 < adlai> sure 16:13 * adlai doesn't remember what work remains, there 16:14 < adlai> huh, maybe it was merged? 16:14 < belcher> it was to write a test 16:14 < adlai> oh here we go 16:15 < adlai> ( https://github.com/JoinMarket-Org/joinmarket/pull/414) 16:15 < adlai> ( https://github.com/JoinMarket-Org/joinmarket/pull/414 ) 16:17 < belcher> at this point it would need a rebase onto the head 16:21 < adlai> right, but any monkey can rebase. it takes a real biped to write good tests! preferably one without an overdue lab report :( 16:22 < belcher> oh yeah hows university going 16:25 < adlai> politely? fine, thank you, und fur dich? (but honestly -- terrible, it's all about manually compiling Proofs-of-Understanding, the difficulty readjustment window is biannual, and deflation is rapidly eroding any semblance of a social environment; but i hope it'll get better in the next epoch) 16:30 < belcher> speaking of the utxo count, this guy just sent me the log of his maker and he has about 75 utxos 16:31 < belcher> log2(75) is only about 6 anyway... 16:36 < adlai> i think i'll rebase & sketch out the test, but then get back to 'work' 16:50 -!- Empty2k12 [~Empty2k12@p4FEDFE63.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 17:03 < adlai> lol 17:03 < adlai> Some people believe that opposition to segwit is astroturfing. 17:03 < adlai> Some people believe that support for segwit is astroturfing. 17:04 < adlai> Some people believe that any attempt to control bitcoin through the software is inevitably doomed to fail because Nakamoto consensus ensures that rational actors will automatically be incentivised to fork away. 17:04 < adlai> Some people think that if anti-segwit sentiment is astroturfing, and that their is an attempt to take control of bitcoin by some third party (e.g. BU) that the same incentive mechanism (Nakamoto consesnsus) will prevail. 17:04 < adlai> Some people think whats good for the goose is good for the gander! 17:04 < adlai> I think you should HODL. 17:04 < adlai> (from reddit) 17:13 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 17:45 < GithubBot5678> [joinmarket] chris-belcher opened pull request #694: Removed an infinite loop that resulted in a 4gb log file (develop...inf-loop-fix) https://git.io/vMmrS 17:54 < adlai> rereading code that's rotted for months and realizing you wrote that noise yourself... the best trip 17:55 < belcher> story of my life 17:55 < belcher> "who wrote this crap" git blame .... "oh" 18:00 < adlai> https://github.com/JoinMarket-Org/joinmarket/pull/414/files#r94354676 18:08 < belcher> are you saying that should be [-0] not [-1] adlai ? 18:12 < adlai> give or take a sign :) 18:12 < adlai> looks like the old version defaults to reducing privacy when the idiot misconfigures 18:14 < adlai> this behavior would reduce cost, but also reduce privacy - for others 18:14 * adlai can't fathom how /he justified that to /himself 18:43 < adlai> ... i'm so confused. how does 1343 lead to 1341!? https://travis-ci.org/JoinMarket-Org/joinmarket/builds/188417634#L1341 20:28 -!- wexx [~x@46.166.190.194] has joined #joinmarket 20:28 < wexx> hi, how can i sweep from internal addresses? my coins are stuck 20:44 <+JM-IRCRelay> [AlexCato1] you can use sendpayment.py with with the amount "0". that sweeps the whole mixdepth 20:46 <+JM-IRCRelay> [AlexCato1] if it was a tumbler run, you can also just restart the tumbler with the lowest mixdepth with coins in it 20:55 -!- wexx [~x@46.166.190.194] has quit [Ping timeout: 258 seconds] 22:01 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 264 seconds] 22:10 -!- fqtw [~me@port-92-192-68-135.dynamic.qsc.de] has joined #joinmarket 22:48 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket