--- Day changed Mon Oct 16 2017 00:50 -!- nono1 [~nono@38.132.107.139] has joined #joinmarket 00:50 < nono1> Hi 00:51 < nono1> I have just installed joinmarket-vleintserver with segwit and before starting to use it, i want to know if it is really suitable for production 00:54 < nono1> clientserver* 00:59 -!- nono1 [~nono@38.132.107.139] has quit [Ping timeout: 255 seconds] 01:18 -!- nono1 [~nono@38.132.127.75] has joined #joinmarket 03:01 -!- wxss [~chatzilla@190.112.223.98] has joined #joinmarket 03:26 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket 03:27 -!- reallll [~belcher@unaffiliated/belcher] has joined #joinmarket 03:27 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 03:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 03:46 -!- coins123 [~coins123@c-208-25.net-185.wadsl.it] has joined #joinmarket 03:46 -!- coins123 [~coins123@c-208-25.net-185.wadsl.it] has quit [Changing host] 03:46 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 03:48 < waxwing> nono1, well a fair number of us are using it, there's been lots of transactions since it started 03:48 < waxwing> also the code was being used by a few people even before segwit, although that was only taker side (before segwit that code only implemented Taker not Maker, now it does both) 04:03 < nono1> thanks 04:03 < nono1> Hmm 04:04 < nono1> I have watch at https://joinmarket.me/ob/toggleSW 04:05 < nono1> if i have unserstoodt is the order boot for the new client-server implementation with segwit 04:05 < nono1> there is only 9 orders found by 9 counterparties 04:06 < nono1> while on the https://joinmarket.me/ob/ there is 48 orders found by 33 counterparties 04:07 < nono1> so there is less chance t do coinjoin with the new client-server right? 04:07 < nono1> maybe i have not well unserstood 04:12 < Sentineo> hm ok, so when I want to start with joinmarket now ... which to start with? 04:12 < Sentineo> https://github.com/JoinMarket-Org/joinmarket or the one nono1 suggests? 04:13 < Sentineo> another question, is there like a minimum BTC for a market maker? Like an amount under which the probability of a trade is miniscule? 04:21 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 248 seconds] 04:37 < waxwing> i think people should start with the segwit version (-clientserver), because the more of us use segwit the better. and i think there are some other reasons (installation script, gui, other things). 04:37 < waxwing> to use '1' addresses you'd need to use the previous version. 04:38 < waxwing> there is no absolute minimum Sentineo ; i'd think something like 5 million satoshis might be a practical lower limit, note that whatever you start with will get split up over time. others might have more concrete opinions, not sure. 04:40 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket 04:40 < Sentineo> is there a testnet version as well? 04:41 < waxwing> arubi, if you're around, i'm now realizing that you don't need an F at all... 04:41 < Sentineo> to familiarize my self with it first 04:41 < waxwing> Sentineo, yes certainly; it all works on testnet 04:41 < waxwing> see "network" setting in joinmarket.cfg 04:41 < Sentineo> ah ok 04:41 < waxwing> but to find counterparties on testnet is more difficult; i have i think two long running testnet bots on freenode and cgan 04:42 < waxwing> the code automatically directs to joinmarket-pit-test channel instead of joinmarket-pit, so you don't need to change the channel name 04:42 < Sentineo> ok cool 04:42 < waxwing> i did have 3 running but shut one down for an obscure reason i can't remember 04:43 < Sentineo> ah I though nono1 pointed to a repo, but it is a order book. waxwing could you please post the correct link to go with for the segwit version? 04:44 < waxwing> arubi, my mistake was thinking like the coinswap case. but the coinswap case only needs an on-chain funding before continuation, because it is contracting between two transaction graphs. with only one graph, there is no risk. you can treat F as just the last to be pre-signed transaction instead. i think. 04:44 < waxwing> Sentineo, joinmarket-org/joinmarket-clientserver 04:44 < waxwing> sorry github.com/ 04:44 < Sentineo> ty 04:46 -!- wxss [~chatzilla@190.112.223.98] has left #joinmarket [] 05:03 < arubi> waxwing, I was also thinking about it more after yesterday. the join control in F is eventually what mixes two amounts into one output which is drained slowly into the sink, or to be used as backout for each side if the other right double spends a uni controlled output. I also think that it might be possible to not use the 2of2 in F, we can still build a tree, but any amounts\outputs used are always only mixed with older amounts\outputs by 05:03 < arubi> the same sender (impossible to promise a backout otherwise). 05:03 < waxwing> nono1, there are 18 counterparties now on the segwit pit; note that the info on /ob is not reliable (there is a bug where it "loses" counterparties over time; i just restart it) 05:03 < waxwing> you can run that script locally 05:04 < arubi> so I think yes, it's possible to run that kind of tree, even might be less dangerous in the sense that your inputs are always under your control, but they will only mix with other inputs of yours 05:04 < waxwing> arubi, ok yes; so you agree that F can be part of the negotiation, i.e. you don't have to wait for it confirming before start? 05:05 < waxwing> it's of crucial practical importance, because if that's true the whole thing can be negotiated without waiting. 05:05 < arubi> oh, yes, sorry I was talking about something else :) let me think about this 05:07 < arubi> right, if you use block height for nlocktimes then I think it's fine 05:07 < waxwing> yeah. i personally find the idea of using unix times quite weird, although i suppose it might be good in certain usecases 05:08 < arubi> guess so, I also like block height better 05:21 < Sentineo> what is this F thing? 05:22 < waxwing> Sentineo, we are discussing this idea: https://gist.github.com/AdamISZ/a5b3fcdd8de4575dbb8e5fba8a9bd88c 05:24 < waxwing> although i'm in the process of tweaking it (yet again), one possible implication might be the ability to make sequences of coinjoins, coinjoins with different patterns, and doing all the negotiation/interactivity upfront instead of repeatedly over time for each transaction. 05:25 < nono1> thanks for your asvice i go to migrate to the new segwit version 05:38 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 248 seconds] 05:43 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 06:07 -!- lnostdal [~lnostdal@85-118-74-33.mtel.net] has joined #joinmarket 06:55 -!- nono1 [~nono@38.132.127.75] has left #joinmarket [] 07:11 -!- lnostdal [~lnostdal@85-118-74-33.mtel.net] has quit [Ping timeout: 255 seconds] 07:28 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 07:39 < Sentineo> wow that went easy 07:39 < Sentineo> even created a wallet 07:39 < Sentineo> withouth errors! :P 07:39 < Sentineo> just want to say nice job guys! 07:41 < Sentineo> ah 07:42 < Sentineo> the joy was too early :P 07:44 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Quit: Page closed] 07:48 < Sentineo> hm ok, though I can run the bitcoin-core node without wallet on 07:48 < Sentineo> seems it is not the case as RPC is failing for getaddressbyaccount 07:49 < waxwing> yes core needs wallet enabled 07:52 < Sentineo> does it need wallet just to access that rpc 07:53 < Sentineo> cause am wondering if I should just create a new wallet.dat or om ok with the old (not being comprimised somehow) 07:54 < waxwing> Sentineo, it uses importaddress into watch-only addresses 07:54 < waxwing> but i think things are simpler if you use an empty wallet.dat. 07:56 < Sentineo> ok, ty 08:00 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Ping timeout: 240 seconds] 08:08 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #joinmarket 08:41 -!- nono1 [~nono@38.132.127.75] has joined #joinmarket 08:41 -!- nono1 [~nono@38.132.127.75] has left #joinmarket [] 08:55 -!- quitobro_ [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 08:55 < quitobro_> belcher waxwing have u guys ever seen this error come out of wallet-tool.py? 08:55 < quitobro_> File "wallet-tool.py", line 465, in 08:55 < quitobro_> 'outpoint']['index']] 08:55 < quitobro_> IndexError: list index out of range 08:58 < quitobro_> belcher also i want to query my full node/the blockchain using listunspectutxos rpc command… which JM address should i query, the xpub key or just the normal pub key addr? 08:59 -!- Anduck [~Anduck@unaffiliated/anduck] has quit [Ping timeout: 264 seconds] 08:59 -!- Anduck [~Anduck@unaffiliated/anduck] has joined #joinmarket 09:02 < waxwing> you can find your utxos with wallet-tool.py walletname showutxos ; maybe that's useful 09:09 < quitobro_> waxwing: thanks. yea so when i query the blockchain via `listunspent`, it shows the balance that wallet-tool is reporting but as `spendable: false` 09:10 < quitobro_> although that just means that the bitcoin core wallet doesn’t have the private key to spend it so, perhaps that’s not actually relevant 09:10 < quitobro_> https://chainquery.com/bitcoin-api/listunspent 09:12 < waxwing> correct, they'll always show as unspendable because they're watch-only to Core 09:13 < quitobro_> waxwing: showutxos is actually returning some unspent utxos… but when i try to spend them/take them out of the wallet, sendpayment reports there are no spendable utxos 09:16 < Sentineo> how is the joinmarket wallet notified waxwing ? 09:17 < waxwing> quitobro_, are you specifying the right mixdepth? 09:18 < quitobro_> waxwing: trying them all, yep 09:18 < waxwing> Sentineo, in this context, it's synced on startup. 09:18 < waxwing> quitobro_, pass --fast to sendpayment (it shouldn't fix whatever this is, but i'm curious in case it changes something) 09:20 < Sentineo> waxwing: trying to understand how it forks, is it like an SPV wallet then? I tought joinmarket registers its addresses to core (watch address) and core notifies it when there is tx for it. How is the notification happening? 09:20 < waxwing> i presume you're doing `python sendpayment.py -N 0 -m mixdepth wallettool amount address` ? 09:20 < waxwing> quitobro_, ^ 09:20 < quitobro_> waxwing: yes exactly 09:20 < quitobro_> going to try all MDs again w/o --fast 09:20 < quitobro_> then try with that flag 09:21 < waxwing> Sentineo, during running, the old version uses walletnotify and the new segwit version polls with listtransactions. on startup, in both cases, the wallet syncs by querying the addresses in the wallet. 09:21 < waxwing> quitobro_, hmm, this is an interesting one, given showutxos is showing it. haven't heard of something like that before. 09:22 < quitobro_> waxwing: hm was actually just able to send a tx, not sure which UTXO(s) it spent however... 09:22 < quitobro_> so strange i tried all the MDs i thought… need to keep better records/logs of what i’m doing here 09:22 < waxwing> heh. so; what changed? using --fast? or just different mixdepth. 09:23 < waxwing> thing is, if non- --fast version, i could imagine it failing, but not with error 'no spendable utxos', that'd be a different error iirc 09:24 < quitobro_> waxwing: i suppose i wasn’t trying to spend from the correct mixdepth 09:25 < waxwing> yeah should be that 09:25 < quitobro_> i’m juggling SW and non-SW wallets to compare how well YG does in each pool 09:27 < quitobro_> waxwing: the I’ndexError: list index out of range’ happens when i query the non-SW wallet’s history via wallet-tool.;y 09:27 < quitobro_> .py* 09:27 < waxwing> "query the history"; you mean you use the history method in the command? 09:28 < quitobro_> yes 09:28 < waxwing> ok i'll defer to others on that, never really looked at that code much. 09:31 < quitobro_> belcher_: so yea i still have reported unspent UTXOs at the address my JM (SW) wallet is watching 09:31 < quitobro_> but i am fairly certain i already spent/moved those coins! 09:32 < quitobro_> or somehow my BTC balance magically doubled... 09:32 < quitobro_> :P 09:33 < Sentineo> hm 09:33 < Sentineo> that is nice 09:33 < Sentineo> what command to run for that? :) 09:35 < quitobro_> i think i need to resync my node *again* or something :( 09:37 < Sentineo> having a pruned one? 09:37 < waxwing> quitobro_, your joinmarket wallet will be reporting its balance right, are you querying the balance of the account at the core node or something? 09:43 < arubi> quitobro_, if you did 'move' or played with any account stuff in core, you've done a mess :) 09:44 < quitobro_> arubi: you mean if i issued RPC commands direct to the node to try and move money? 09:44 < quitobro_> i’ve only gone thru JM wallet interface for spending coins 09:44 < arubi> ah that's fine 09:44 < quitobro_> waxwing: yea i’m just doing `bitcoin-cli listunspent` 09:44 < quitobro_> JM watches that wallet address right? 09:46 < waxwing> yes; but iirc there are technical reasons you can't trust that as showing coins that *you* own, only. i think there's a code path where addresses get added to the account, which aren't actually under your control. 09:46 < waxwing> don't treat Core's wallet as a representation of your JM wallet (even that account); in general, it isn't. 09:47 < waxwing> i mean feel free to play around looking at that stuff, but it's up to you to figure out what it means, if you do. 09:48 < quitobro_> waxwing: sure, okay… but when i do JM’s `wallet-tool.py wallet.json` it should be stripping away the non-controlled, non-owned addresses/accounts correct? 09:48 < waxwing> sure of course; note it's showing balances for specific addresses in that wallet. 09:48 < waxwing> and showutxos shows exactly those utxos you own. 09:50 < quitobro_> waxwing: so when i try to spend these unspent utxos, a transaction is generated and the same tx id returned by `sendpayment.py` every time i run the sendpayment script… 09:50 < quitobro_> that tx id does not correspond to a tx on the blockchain, however... 09:51 < quitobro_> the unspent UTXOs are in an internal address fyi 09:52 < quitobro_> two separate internal addresses in one particular MD 09:54 < quitobro_> belcher `bitcoind —reindex` is sufficient or i also need to e.g. `mv wallet.dat wallet.dat.bak` 09:55 < arubi> you'd need -rescan, not -reindex for balance stuff 09:58 < arubi> quitobro_, btw, do you use the node as your active wallet too, or just for joinmarket? 09:58 < quitobro_> arubi: i’m running pruned node so can’t rescan 09:58 < quitobro_> afaik 09:58 < quitobro_> arubi: just for JM stuff… wdym active wallet tho? 09:58 < quitobro_> i transact in and out of it... 09:58 < arubi> yea you can't rescan unfortunately, even more so reindex 09:59 < arubi> right, so it also hosts your own wallet 10:02 < arubi> I'm trying to figure out if it makes sense to direct folks to bitcoin knots instead.. it has multiwallet support, so you can just have jm use its own watchonly wallet without importing a bunch of stuff to the main wallet. I'm in the process of setting up a local interactive regtest with some bots to check 10:03 < arubi> also security, jm won't be using the main wallet's rpc credentials (thought this is possible now too, but not with segregating wallets) 10:04 < Sentineo> that would be nice, had to set up a new node to run JM ... do not want to mess with the main wallet.dat 10:06 < arubi> I'll let you know if it works well. I don't expect any issues at all. jm doesn't even have to know it's using multiwallet 10:11 < waxwing> quitobro_, so what exactly is happening? i don't get it 10:11 < waxwing> i thought we'd fixed your problem by spending out of the right mixdepth? 10:12 < waxwing> so now are you saying that you run `python sendpayment.py -N 0 -m mixdepth walletname amount address`, you accept and it shows that the transaction is broadcast, and you get a txid. 10:12 < waxwing> but that that transaction doesn't show up anywhere, e.g. blockexplorers? 10:14 < arubi> hmm, if this is a correct summary ^, do you by accident have "walletbroadcast=0" in your bitcoin.conf ? 10:16 < waxwing> Sentineo, fwiw i run multiple wallets off one core node (have been doing for years), no issues. there should never be a need to query the wallet.dat directly; but if you *also* use your node as a wallet, directly, you should make sure not to send coins between JM and that Core wallet. 10:16 < waxwing> well only because you can get balances being reported incorrectly, there's no other risk of course. 10:30 < quitobro_> waxwing: exactly, correct. tx id generated, attempting to spend the coins in the mixdepth which reports having a balance, but that tx is like a ghost! 10:30 < quitobro_> arubi: no walletbroadcast, no 10:31 < arubi> can you see if 'gettransaction ' returns anything? 10:32 < arubi> (bitcoin-cli, not joinmarket command) 10:33 < quitobro_> arubi: invalid id 10:34 < arubi> hopefully you're not adding '<' and '>', just the 64 character string is the parameter 10:34 < quitobro_> bro. lol 10:34 < quitobro_> c'mon 10:34 < quitobro_> :) 10:34 < arubi> sorry, I'm just making sure. invalid id isn't an actual error out of bitcoin-cli that I know 10:35 < quitobro_> error code: -5, Invalid or non-wallet transaction id 10:35 < arubi> ah, okay. 10:36 < arubi> do you have any unconfirmed transactions going out \ into the joinmarket wallet? 10:37 < quitobro_> arubi: how could i check that? i think i may, i was sending tx’s with super low fees for a while there 10:38 < waxwing> i guess one thing you could do is try to sanity check whether the utxo (shown by showutxos) that you were spending in that transaction, exists. 10:39 < waxwing> but i guess it really ought to, since every time you start sendpayment it's resyncing the wallet and should only populate it with valid utxos. 10:40 < arubi> quitobro_, the only way to check right now is 'getrawtransaction ' . if it's in your mempool, that will return it 10:40 < quitobro_> waxwing: yea that’s the curious part… how can one look for uncofirmed tx’s associated with a JM wallet? or any ideas as far as where to go looking next? 10:40 < quitobro_> arubi: does JM wallet keep a log of tx ids somewher 10:40 < arubi> ie 'gettransaction' says it's not in your wallet, so that's the only way 10:40 < arubi> don't know 10:41 < waxwing> quitobro_, by default, when you run wallet-tool it shows unconfirmed utxos. but now i remember, by default, it *doesn't* spend unconfirmed utxos unless you specify listunspent_args=[0] or similar in the joinmarket.cfg. that could be what's going on here. 10:41 < waxwing> so does the utxo which you are trying to spend show up on a block explorer? 10:44 < quitobro_> waxwing: yea... 10:44 < waxwing> as unconfirmed or confirmed? 10:44 < quitobro_> when i list the unspent utxos, the ‘address’ field is the address at which it has most recently been sent, right? 10:44 < quitobro_> many confirmations 10:44 < waxwing> oh, i see, that's different. 10:44 < waxwing> Core node is synced right. 10:44 < quitobro_> yes 10:45 < waxwing> the address is the one that received that utxo. 10:45 < waxwing> you should be able to see it in the default wallet-tool display output. 10:46 < quitobro_> yes and it is reported when i run that 10:46 < quitobro_> and when i spend it, a tx is made and a tx id returned 10:46 < quitobro_> but no actual tx is (apparently) broadcast to the network... 10:46 < waxwing> ok as an experiment can you try to push the tx to the network via another route (one of the blockexplorer APIs) maybe 10:47 < waxwing> because everything here lines up to suggest the tx should go through. 10:47 < quitobro_> waxwing: push how? 10:47 < quitobro_> waxwing: to be clear i’m fairly sure these coins have already been spent 10:47 < quitobro_> i sent them to another wallet via sweepouts 10:47 < waxwing> oh. this i didn't know. so why are you asking why the transaction doesn't go through? :) 10:47 < quitobro_> waxwing: i’m asking why the UTXOs are still unspent! 10:47 < quitobro_> sorry 10:47 < waxwing> there's no room for doubt eh, if you see it on a block explorer as already spentl. 10:48 < quitobro_> i’m asking why JM is reporting unspent UTXOs. that seems to be b/c my node thinks there are unspent UTXOs 10:48 < waxwing> well it's interesting, it indicates that the wallet sync is not operating correctly for some reason. 10:48 < waxwing> which version of JM? 10:48 < quitobro_> it could be because i queried it prior to it syncing fully… i recently reindexed 10:48 < waxwing> and also is the behaviour repeatable with and without --fast. 10:48 < quitobro_> yea both with and w/o fast same behavior 10:49 < waxwing> yes not fully synced can cause such weirdness of course. 10:49 < quitobro_> it is synced though 10:49 < waxwing> and which version? 10:49 < quitobro_> meaning CS or old? 10:49 < waxwing> yes 10:50 < quitobro_> waxwing: CS 10:52 < arubi> if you spend utxos from under the wallet and the node is off at that time, then it has no way of knowing it happened 10:53 < waxwing> arubi, sure but the wallet is synced when you start the script. 10:53 < waxwing> i'm getting a bit stuck, never seen such behaviour. 10:53 < arubi> but is the spend even confirmed? 10:53 < waxwing> yes he said it was several confs 10:53 < waxwing> if it wasn't, the behaviour of sendpayment would depend on listunspent_args, but it is. 10:54 < arubi> I thought he meant some inputs to the wallet are confirmed, but he has too many 10:55 < arubi> I'm wondering if the original wallet was moved and a new watchonly wallet was created by jm, missing past transactions? 10:56 < quitobro_> arubi: i think something like that is the culprit indeed... 10:56 < waxwing> a new wallet means new Core account and new set of addresses, don't see why that would interact? 10:56 < arubi> only a new wallet.dat, but keep the old jm wallet 10:57 < waxwing> oh a new wallet.dat, hmm. 10:57 < arubi> it knows about its own utxos, but unaware of the spend that happened 10:57 < quitobro_> i did make a backup of my wallet.dat 10:57 < arubi> because the watchonly only begun again after the spend already happened 10:57 < quitobro_> but pretty sure i used the same one when i reindexed my blockchain 10:57 < arubi> you can't reindex a pruned node 10:57 < quitobro_> you can, you cannot rescan 10:58 < arubi> there's no use to a pruned node index afaik 10:58 < quitobro_> arubi: as opposed to… 10:58 < arubi> an index by a non pruned node, which indexes all transactions 10:58 < arubi> maybe it's just ignored. anyway, do you have the raw transaction that spent the coins? we might be able to teach your pruned node about it 10:59 < arubi> if you can get it off a block explorer, you could try 'sendrawtransaction ', and this will make the node look for it 10:59 < arubi> and maybe the watchonly wallet will then list the spend 11:00 < waxwing> in general if you switch out the Core wallet you have to rescan; so don't do that. but, the pruned aspect is another dimension. just in terms of generally "what to do"; don't change the Core instance or the Core wallet unless you're OK with rescanning. 11:00 < arubi> s/look for it/look for the inputs/ 11:02 < quitobro_> ok thanks guys i’ll report back once i have some more clarity/something to report 11:02 < arubi> good luck 11:33 < Sentineo> hm nice hack with that sendrawtx 11:33 < Sentineo> waxwing: how do you run several wallets, renaming them? 11:37 < waxwing> Sentineo, to clarify i mean several *joinmarket* wallets; just generate them and use as normal. to Core they're isolated under the hood. you can run them out of the same joinmarket directory, if you're just doing individual payments. but if you want to run different jm wallets at the same time over a long period (yg) it's better to just run them in separate jm install directories (but can use same virtualenv), for simplicity. 11:38 < Sentineo> ah ok 11:39 < Sentineo> ty for c 11:39 < Sentineo> arifying 11:53 < arubi> l 11:53 < arubi> er, sorru 11:56 -!- delinquentme [~delinquen@108-235-112-153.lightspeed.sntcca.sbcglobal.net] has joined #joinmarket 12:18 < delinquentme> The order book thats available at: http://www.joinmarket.io 12:18 < delinquentme> gives the exact same info as the one that I would run with the ob-watcher right? 12:25 < waxwing> delinquentme, i don't know to what extent that's updated; the one in the topic is https://joinmarket.me/ob 12:28 < delinquentme> so chances are the one thats online is the most up-to-date? 12:29 < delinquentme> and other than segwit probs having fewer orders ... how can I tell when segwit is on / off? 12:31 < waxwing> not sure what you mean by "segwit is on/off". you mean, for you? 12:32 < waxwing> your local one will be just as good or better than https://joinmarket.me/ob usually, the script has a bug and tends to lose bots over time, so if you want an up to date view start it locally. 12:32 < waxwing> oh you mean the toggle, right. look at the left column and see "Sw reloffer" or similar" 12:33 < waxwing> but yeah that's a bit suboptimal, oh well nbd 12:39 < delinquentme> cool got it. 12:39 < delinquentme> is the code that runs the website https://joinmarket.me/ob/toggleSW on the github? 12:40 < delinquentme> typically im SSHed into my machine that has jm-cs so the website is easier ... but if thats bugged ...maybs i fix 12:41 < waxwing> delinquentme, basically yes; it's in script/ob/ob-watcher.py 12:42 < waxwing> sorry scripts/obwatch/ob-watcher.py 12:42 < waxwing> PRs welcome, as mentioned above ^ there is a long-standing bug although it might be a little difficult to find. 12:42 < delinquentme> cool and thats all the code running the website / service? 12:42 < waxwing> tweaked a tiny bit for public running, but not anything that matters 12:48 < delinquentme> and the dropping bug is on all pieces of the code or just the public website? 12:48 < delinquentme> per the "tends to lose bots over time" 12:48 < waxwing> latter .. i hope :) 12:51 < delinquentme> dun dun dunnn! 12:52 -!- quitobro_ [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro_] 13:13 -!- quitobro [~quitobro@pool-71-190-202-18.nycmny.fios.verizon.net] has joined #joinmarket 13:16 -!- quitobro [~quitobro@pool-71-190-202-18.nycmny.fios.verizon.net] has quit [Client Quit] 13:44 -!- quitobro [~quitobro@pool-71-190-202-18.nycmny.fios.verizon.net] has joined #joinmarket 14:10 -!- quitobro [~quitobro@pool-71-190-202-18.nycmny.fios.verizon.net] has quit [Quit: quitobro] 14:35 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 14:46 < delinquentme> waxwing, belcher_ I assume you guys heard about the WPA2 crack + the Infineon RSA issues? 15:43 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket 16:00 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 16:25 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Quit: (┛◉Д◉)┛┻━┻] 16:56 < grubles> hm i'm getting a CompileError when firing up wallet-tool.py 16:56 < grubles> https://0bin.net/paste/n8AY+4NiEarxRv5-#Q0kLmuObFa3824SdYHFhADPE2NfkfQHWnfcerhVUt0w 17:31 < delinquentme> grubles, how did you install btccore? 17:31 < delinquentme> gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory 17:40 < grubles> btccore? 17:42 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 248 seconds] 17:47 < delinquentme> grubles, bitcoin core 17:47 < delinquentme> or what install process did you use to install joinmarket? 17:56 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #joinmarket 18:03 < grubles> i built core from source 18:03 < grubles> and cloned the jm github 18:28 < delinquentme> what machine are you running it on grubles 18:52 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro] 18:53 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 19:22 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro] 19:23 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 19:24 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Client Quit] 19:24 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 19:45 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Quit: quitobro] 21:10 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket 21:10 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Client Quit] 23:44 < Sentineo> grubles: is there a package suplying that redhat-hardened-cc1 file?