--- Day changed Tue Jul 26 2016
00:11 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]
00:15 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
00:16 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:20 < jonasschnelli> wumpus: do you think we should have an optional "keep-seed" argument when encrypting the wallet in 0.13?
00:20 < jonasschnelli> I think it can be useful, but I think we can also add this in 0.14 (though the implementation is easy and relatively risk free)
00:22 < gmaxwell> keeping around a key that has been stored unencrypted on many systems is no better than not using encryption at all.
00:23 < gmaxwell> Probably a better thing to do is restructure things so the wallet doesn't even contain any keys until first use, so if the first thing you do is encrypt there is nothing to keep.
00:24 < jonasschnelli> gmaxwell: Yes. I though of that. The problem is the current way how the wallet works and how it always generate a first address during initialization.
00:25 < jonasschnelli> We could add wallet initialization/creating to a (new) bitcoin-txish tool. "./bitcoin-wallet"
00:25 < gmaxwell> There is no particular need for it to work that way... (e.g. there doesn't need to be a wallet.dat until we attempt to use one)-- it just is that currently.
00:25 < gmaxwell> yuck
00:25 < sipa> jonasschnelli: i would be fine with just a function to import or export a seed from the wallet
00:25 < jonasschnelli> People could do all sorts of things with it. Dump, enctypt, create, export/import seeds.
00:25 < jonasschnelli> sipa: there is a PR to exporting the xpriv (over dumpwallet)
00:25 < jonasschnelli> import is not possible now.
00:25 < sipa> jonasschnelli: if you want to keep the seed when encrypting, export the seed before and import after
00:26 < gmaxwell> jonasschnelli: thats going down a path of _more_ mucking inside the wallet and with keys directly, which has a remarkable track record for resulting in funds loss. :)
00:26 < jonasschnelli> Importing should be done together with a flexible keypath option.
00:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:27 < sipa> that makes sense
00:27 < jonasschnelli> I guess users will would complain otherwise if you only can "import" seeds with m/0'/0'
00:27 < gmaxwell> Importing should be a rarely used functionality-- manual mucking with things is dangerous. Sometimes it can make sense, sure, but the basic functionalitty needs to work.
00:28 < gmaxwell> There is a lot of complexity required to property handle multiple derrivation schemes within a wallet.
00:29 < jonasschnelli> Call for last two 0.13 PR review: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+author%3Ajonasschnelli+milestone%3A0.13.0
00:29 < jonasschnelli> Wait... last three: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0
00:29 < gmaxwell> also unclear import with an explicit path would interact with implied chains (e.g. for chains)
00:30 < jonasschnelli> Yes. The whole importing situation is not yet clear to me....
00:30 < gmaxwell> I think at this level of development it's wrong to pretend that any compatiblity of keys across wallets can exist-- kind-of-sort-of compatibility will only result in funds loss.
00:30 < jonasschnelli> People might expect a lookup of the 0-n after importing a seed, etc.
00:30 < sipa> by import i guess i just meant "override deterministic keypath"
00:31 < jonasschnelli> I just think people would like to stick to bip44 or something in order to use the seed in other wallets once they want to move away from Core
00:31 < jonasschnelli> sipa: yes.
00:31 < gmaxwell> jonasschnelli: except that won't actually work reliably, and it would hobble security and functionality.
00:33 < jonasschnelli> gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
00:39 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
00:40 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]
00:45 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
00:48 < wumpus> jonasschnelli: I don't know, I think any solution to this is quite ugly. People expect a wallet to have only one seed, but on the other hand, keeping using the unencrypted seed when encrypting the wallet is risky
00:49 < wumpus> that wallets are 'born' unencrypted and later encrypted keeps causing difficulties
00:49 < wumpus> though I also don't like the idea of forcing people to set a passphrase on first use
00:56 < warren> Don't force them upon starting Core, only if they want receive addresses?
00:57 < wumpus> Probably a better thing to do is restructure things so the wallet doesn't even contain any keys until first use, so if the first thing you do is encrypt there is nothing to keep. <- the funny thing is that from a user viewpoint this is already the case. If you haven't used any keys, and encrypt the wallet, all pre-encryption keys were never used and will never be dealed out, just take a bit of space in the wallet
00:57 < wumpus> warren: yes, that's an option
00:58 < gmaxwell> setting the passphrase prematurely is a sure path to funds loss.
00:58 < wumpus> right
00:59 < warren> Make them type the passphrase if they want a receive address?
00:59 < sipa> "It looks like you received yoir first bitcoins! Congratulations! Maybe now is a good time to encrypt yoir wallet so your funds are safe?"
00:59 < gmaxwell> What electrum does is what I think is the best option, but it is very difficult to get observational data on the actual effects on users.
01:00 < sipa> what does electrum do?
01:00 < wumpus> sipa: but then the first bitcoins were sent to the address associated with an unencrypted key, so it's sort of too late already
01:00 < gmaxwell> it forces you to write down an unencrypted recovery code... and by forces it disables printing and copy-paste, then when you say you've written it down it challenges you to reenter.
01:01 < gmaxwell> so it does the encrypting at install, but it makes you make an encryption free backup at the same time.
01:01 < gmaxwell> It also doesn't have hours/days lag between install and usability. :)
01:01 < wumpus> sipa: it'd be succesful way of encouraging people to encrypt in the first place, but wouldn't make any of the implementation/working around it easier
01:01 < sipa> gmaxwell: also... our wallet model is really that you should not lose your wallet.dat
01:02 < wumpus> gmaxwell: there have been plenty of ideas of discouraging creating receive addresses at all before syncing up?
01:02 < gmaxwell> wumpus: well it's perfectly fine to recieve before synced, if you know that you won't see the results right away!
01:02 < wumpus> gmaxwell: but confusino about that almost no one knows that, and it results in 99% of support mails I get
01:02 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
01:03 < sipa> sure, with deterministic seeds there is a way to recover your funds from catastrophic lost
01:03 < sipa> but not the rest...
01:03 < wumpus> gmaxwell: I'm not saying it should be impossible ofc
01:03 < gmaxwell> I think the wallet encryption is mostly snake oil that causes a net loss of funds. Don't forget this... the failure modes it protects against aren't the most interesting, esp wrt user's ability to remember cryptographic keys.  Personally, I use wallet encryption only as authorization; so that it's really clear when I'm about to spend funds in a production wallet. 
01:04 < gmaxwell> wumpus: we could very easily be scanning ahead of where we've synced ... probably with <50 lines of code changed to just catch advertised unconfirmed transactions.
01:04 < wumpus> wallet.dat encryption helps against exploit that allow grabbing a named file from the file system, but not more
01:04 < gmaxwell> wumpus: wallet.dat encryption also gives you an authorization hook. A user doesn't have to worry when screwing around with bitcoin-qt that they're acidentally going to send funds.
01:05 < wumpus> it's not exactly a panacea, but encryption never is, it only helps if it's used in the right way
01:05 < gmaxwell> but for that sort of thing a passphrase such as "goat" is perfectly fine. :P
01:05 < wumpus> in any case I don't think arguing about this makes sense - we're not considering removing wallet encryption I hope?
01:05 < sipa> i'm sure more funds have been lost from forgotten passphrases than from theft
01:06 < sipa> wumpus: hell no
01:06 < gmaxwell> wumpus: yea, not going to remove it. (I say with some regret.)
01:06 < gmaxwell> (because as sipa says, I'm pretty confident that more funds have been lost to lost passphrases, than saved from theft by it)
01:06 < wumpus> sipa: we have no statistics about that. Theft is also quite common, it can't be coincidence almost all malware has wallet.dat-stealing hooks these days.
01:07 < gmaxwell> wumpus: same malware also has keylogging hooks.
01:07 < wumpus> gmaxwell: that's not an argument against theft happening
01:07 < wumpus> gmaxwell: just that the current security may not be good enough
01:07 < gmaxwell> wumpus: no, it's an argument that the encryption doesn't protect much against theft. If you note, my repeat of sipa states it somewhat differently.
01:08 < gmaxwell> forgotten vs protected from theft by encryption.
01:08 < wumpus> hw wallets would be preferable, and I think we need to support those in the future
01:08 < gmaxwell> I do know of cases protected from theft by encryption, but few. 
01:08 < gmaxwell> wumpus: yes.
01:08 < wumpus> but repeating this discussion for/against wallet encrption every few months is not going to help :)
01:09 < gmaxwell> I wasn't making an argument against wallet encryption, I was reminding that its value is limited and please don't "improve" it in ways that it more harmful.
01:10 < wumpus> there's certainly a compromise between theft and loss due to forgetting, we've been aware of this since the beginning, and there's not really a solution that works for everyone
01:11 < gmaxwell> There are knobs we can to make things better or worse. E.g. encoraging an unencrypted offline backup can mitigate risk, while prompting at install for a key would exacerbate.
01:11 < gmaxwell> can't spell tonight.
01:12 < wumpus> One thing I can think of where encryption helps, somewhat, is simple protection against local users. Stealthily copying someone's wallet.dat when you are on someone's computer for a few minutes is trivial. Installing a keylogger or trojan is more involved, and leaves much more evidence.
01:14 < wumpus> gmaxwell: yes, we agree there, I started this off with stating that I don't like forcing the user to set a passphrase
01:14 < wumpus> and I don't think a goal should be to encourage people to use the encryption
01:14 < wumpus> but if they want to use it, they should be able to
01:14 < gmaxwell> I think the way most people who would trojan your machine e.g. on windows/mac would be installing something innocent looking, which requires preparation. 
01:14 < wumpus> and then it should also be as secure *as possible given the constraints of local usage tc*
01:15 < gmaxwell> I'm even fine with encouraging it, if it got them to make an unencrypted backup at the same time. I ~think~ that the combination is useful.
01:17 < wumpus> indeed, an unencrypted backup makes sense combined with physical security
01:17 < sipa> then again we don't even have a user-friendly way to recover from a backup...
01:17 < wumpus> if only they don't put it in the cloud :(
01:18 < gmaxwell> wumpus: electrum works hard to make you actually write it down... it does all it can to prevent your backup from being electronic.
01:18 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has joined #bitcoin-core-dev
01:18 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has quit [Changing host]
01:18 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:18 < wumpus> gmaxwell: yes that is good
01:19 < wumpus> sipa: yes, which wouldnthere the ugly problem of lack of people actually interested in working on it rears its head again 
01:19 < wumpus> which wouldn't be rocket science*
01:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
01:20 < wumpus> I mean there is a 'backup wallet' menu option, could add an 'import wallet' option too
01:20 < wumpus> although it would work better with multi-wallet support I guess
01:20 < gmaxwell> I'm looking at the PR list and seeing 4 unmerged wallet PRs from phantomcircuit; who has had roughly that number of open wallet PRs at any given time throught all of 0.13's development.
01:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lrsjvxliphuhxalq] has joined #bitcoin-core-dev
01:21 < gmaxwell> Restore is mostly a disaster until something is done about rescan.
01:21 < btcdrak> greenaddress has encrypted seeds so you put in a passohrase and it gives you an encrypted seed
01:21 < wumpus> why? it doesn't matter if restore takes a while, it will be an infrequent operation
01:21 < btcdrak> that is part of the initialisation process.
01:22 < wumpus> gmaxwell: there's not really a lack of wallet PRs, but many of the ideas that have been proposed here over and over have never been implemented
01:22 < gmaxwell> wumpus: there is "a while" and then there is ">8 hours" which is what a rescan takes on my laptop.
01:22 < wumpus> gmaxwell: that long? oh last time I did it it was much faster
01:22 < wumpus> yes, >8 hours is bad
01:22 < btcdrak> rescan? ouch
01:22 < gmaxwell> I think on a fast machine its about 5 hours now, down from about 12 prior to 0.12.0.
01:23 < wumpus> that's longer than a reindex takes in good circumstances
01:23 < btcdrak> good case for keeping an addrindex
01:23  * btcdrak ducks
01:23 < wumpus> why is a rescan so slow? it's a fairly simple scan over data right?
01:23 < gmaxwell> deseralizes every block and every transaction.
01:24 < wumpus> so deserialization-bound? ok
01:24 < gmaxwell> and then is constantly opening and closing the wallet database.
01:24 < gmaxwell> I believe that one of phantomcircuit's wallet fixes (maybe in the pipeline) fixed the latter part.
01:24 < wumpus> I guess there's room for optimization there, it wouldn't need to deserialize everything
01:25 < wumpus> many operations could be done in-place on the data
01:25 < gmaxwell> or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
01:26 < gmaxwell> where for each block (or group of blocks) we would store a small lossy map for the block; and hits on the map would result in deciding which blocks to scan, or not.
01:26 < wumpus> anyhow: why would importing a wallet.at require a rescan?
01:26 < wumpus> it's no different from replacing your wallet.dat with a different one and restarting the client
01:27 < gmaxwell> it always requires _some_ rescanning; assuming it was offline more than one blocktime :P
01:27 < gmaxwell> but presumably a backup is old.
01:27 < wumpus> the transaction should already be in there. Sure, it may need to catch up a bit, but no full rescan should be needed
01:27 < gmaxwell> well the first 300k blocks rescan in pretty much no time. :P
01:27 < wumpus> partial rescans are pretty fast at least in my experience
01:28 < wumpus> I just don't think this is a blocker issue for implementing wallet import, if someone really wanted to implement it
01:28 < wumpus> optimizing rescan would be awesome still
01:28 < gmaxwell> I have data on the partial rescan.
01:29 < sipa> the wallet should be able to tell the node code that some range of blocks is to be downloaded agaim
01:30 < gmaxwell> 2016-07-25 06:57:24 Rescanning last 5556 blocks (from block 416625)...
01:30 < gmaxwell> 2016-07-25 07:02:23  rescan               298400ms
01:30 < wumpus> but on the other hand, importing a wallet is already possible by the (circuitous, and possibly risky) work of replacing wallet.dat manually, which users already do. Would be nice if it was more userfirendly
01:30 < gmaxwell> that was a backup restore I did a day ago.
01:30 < sipa> gmaxwell: many matching transactiond in that range?
01:30 < wumpus> a lot things never get done because too many other things are dragged into it, the old scope creep again
01:30 < gmaxwell> sipa: none.
01:31 < sipa> gmaxwell: ugh
01:31 < sipa> well, 1 second per week
01:31 < wumpus> oh so you want to implement wallet importing? we first need to improve rescan performance. Oh never mind then...
01:32 < gmaxwell> pft. it's not gating, I'm suggeting why it's not as interesting to actually work on, even testing it (with mainnet) would be painful. Thats all.
01:32 < wumpus> gmaxwell: yes, that's a very bad data point.
01:33 < gmaxwell> I'm not complaining, but sharing info. Performance with the wallet is painful, people are working on it... and it has improved quite a bit. Though that also means that most of the really dumb things are already fixed.
01:34 < wumpus> talking about rescanning, did anyone ever notice this issue: https://github.com/bitcoin/bitcoin/issues/8116
01:34 < wumpus> the rescan suddenly started over
01:34 < wumpus> I'm sure it can be really slow if it's done multiple times :p
01:37 < gmaxwell> freaky, I don't think I've seen it do that before.
01:37 < gmaxwell> oh I see you imported while it was already rescanning, and so it started over?
01:37 < gmaxwell> oh no your import is what triggered the rescan and the new block restarted it.
01:37 < wumpus> no, that's not even possible
01:38 < wumpus> if it's rescanning everything is blocked
01:38 < wumpus> yes, that seems to be the case
01:38 < gmaxwell> weird. pretty sure I've seen it connect blocks while rescannign and not start over.
01:41 < wumpus> maybe it was just a fluke. But it could explain some very slow rescans
01:42 < gmaxwell> not the ones I've been expirencing at least.
01:42 < wumpus> the end result was correct so I didn't make a big issue out of it
01:42 < gmaxwell> but some of the complaints for sure.
01:43 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
01:43 < da2ce7_mobile> I would really like the option of importing extended private keys, ie. m/44'/0'/2' or m/44'/0'/3'  etc.  Where I can have my HD seed stored somewhere more secure.
01:46 < gmaxwell> da2ce7_mobile: what you're asking there could describe several different actual usecases which have different supporting development requirements.
01:47 < gmaxwell> For example, do you ask that in terms of just having a system that can securely getnewaddress for a remote wallet?  That would best be accomplished by a standalone keygen tool.
01:47 < gmaxwell> Or do you hope to form transactions on an online wallet and transfer them to an offline wallet for signing? That requires a large suite of tools for offline wallet support  (and doesn't technically require public derrivation)
01:48 < da2ce7_mobile> For example, One could generate a HD seed from a Trezor. Import that seed onto a offline computer and create a few extended private keys.
01:49 < da2ce7_mobile> You could import these seeds into your Bitcoin Core to act as hot-wallets.
01:50 < gmaxwell> you mean extended public keys there.
01:50 < gmaxwell> IIRC trezor has absolutely no private key export.
01:50 < gmaxwell> also it uses public derrivation exclusively, and leaking one public derrivation described key lets you unzip and go and recover all the other keys.
01:50 < da2ce7_mobile> It has no private key export, but you can re-import your HD seed into a offline computer to generate the private keys.
01:51 < gmaxwell> yes, but the public derrivation lets someone with the extended public key and any one private key derrive all other private keys. pretty fragile.
01:51 < da2ce7_mobile> yeah. It would be great if BIP44 had a 'hardened only' option.
01:52 < gmaxwell> I think what you're mostly saying though is that you'd like to have a single master secret and generate seperate wallets off it, with {details} in the generation.
01:53 < da2ce7_mobile> Well, I already use this method for my hot-wallets.  I import an extended private key (via a round-about-way) into copay on my iPhone.
01:53 < gmaxwell> The other issue with the whole public derrivation split is that an attacker who can compromise the front end can make it start issuing bad keys (e.g. ones they have the private key) silently. :(  still an improvement (and thats the use case I came up with public derrivation for) but not a panacea. 
01:55 < da2ce7_mobile> I really don't like public derivation.  I don't see any point of it if you have a hardware wallet.
01:56 < da2ce7_mobile> it is userfull for 'watch only'
01:56 < da2ce7_mobile> but most people don't use watch only accounts.
01:57 < da2ce7_mobile> also, why not just derive 10k public keys; and export those; it doesn't take up so much space; and the 'watch only' wallet can warn you when you are running out of keys.
01:57 < gmaxwell> at one point I had a proposal for a new address type which would encode pubkey P plus  scalar offset s, and then you pay to P+sG. And so an attacker that compromises the front end causes a publically visible change when all the addresses it gives out begin with a different prefix. 
01:57 < jonasschnelli> da2ce7_mobile: indeed
01:58 < gmaxwell> da2ce7_mobile: indeed. Public derrivation causes a lot of trouble for a very narrow improvement.
01:58 < gmaxwell> it's useful, but the utility is often overhyped.
01:58 < sipa> ... says the man who invented iy
01:58 < sipa> :)
01:58 < sipa> *iy
01:59 < sipa> **it
01:59 < jonasschnelli> hehe
01:59 < jonasschnelli> I think there are serval usecases for pubkd... but not for the novice wallet user
01:59 < gmaxwell> sipa: yup.
02:00 < jonasschnelli> So... I'm kinda no longer sure if we even want to allow flexible keypath... with or without pubckd
02:00 < jonasschnelli> We should probably work more towards supporting cold storages with something like "importmulti"
02:01 < gmaxwell> Back in early 2011 the FSF complained that they wanted unique addresses for donations, but didn't want their wallet on their webserver (duh!), ... and with it being on a website if they had any fixed number of addresses, some user fetching the site might easily exhaust them... which was the original motivation.  Though it doesn't really fully fix that case, since some user making to scan a milli
02:01 < gmaxwell> on addresses is also undesirable. :P
02:02 < gmaxwell> I think supporting offline wallets, HW wallets, and multisig with these things should be a higher priority than anything about derrivation paths.
02:02 < gmaxwell> Some things like multisig might imply things about derrivation paths, and thats fine.
02:03 < jonasschnelli> I think the address part in the offline wallet/HW wallet signing is the simplest part. More difficult is probably how you would design the API/interface between the twos.
02:03 < gmaxwell> I do offline signing today, using raw transactions; but the usability is not good. :)  (OTOH, it's also a workflow that allows me to have a second person review the transactions... which is quite handy)
02:04 < jonasschnelli> rawtx is possible because fundrawtx has a custom change address in 0.13.
02:04 < jonasschnelli> But somehow we first would need a feature that stops generating addresses inside the wallet. Something where you can fill your keypool from the "outside"
02:04 < gmaxwell> well I suggested before a general design, where bitcoin-core wallet just has a simple interface to call another process to ask it to get signatures, providing it with the relevant data... and then that external process can implement the approrpiate call out to whatever is in use.
02:05 < jonasschnelli> gmaxwell: I though it would be most simple if it would be TCP/HTTP
02:05 < jonasschnelli> A json call goes out to a configurable URL, a response might come back.
02:05 < jonasschnelli> Would also possible allow to sign on a cold storage attached to a different computer in your LAN
02:05 < gmaxwell> Then you get CSRF from js running on the users machine...
02:06 < jonasschnelli> You can avoid that...
02:06 < gmaxwell> different computer; now the communication needs to be cryptographically protected.
02:06 < gmaxwell> Sure you can but you just said, most simple.
02:06 < da2ce7_mobile> I think that it is a good opportunity to make a standard 'Segwit Offline Signing Protocol and Format";  something that both copy-paste and a hardware wallet could use.
02:06 < gmaxwell> Having to avoid CSRF and provide link layer encryption is not simple.
02:06 < jonasschnelli> Launching a process... yes. Why not...
02:06 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
02:06 < jonasschnelli> It would also eliminate the need for a background daemon
02:07 < jonasschnelli> Can you check if a certain process (application at path) is already running?
02:07 < gmaxwell> jonasschnelli: yea, and if you did want it to talk to some daemon-- it could do that... with the complexity to communicate with it encapsulated in the process that it launches.
02:07 < jonasschnelli> Or how would you prevent from spinning off to many processes?
02:08 < gmaxwell> well my suggestion would be that it would launch it on demand, communicate via stdio. If the operations are 'blocking', then you wouldn't have to worry about too many being launched.
02:10 < jonasschnelli> gmaxwell: I think very likely there is a GUI attached to that launched process (signing verification or similar), the stdio com should be async/nonblocking... 
02:11 < gmaxwell> By blocking I just meant bitcoin core wouldn't open multiple processes.
02:11 < jonasschnelli> But right, you could track on the bitcoincore side if there is already a signing in process and refuse anotherone.
02:11 < gmaxwell> Not the actual mechenism for talking to the file descriptors.
02:12 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
02:12 < jonasschnelli> You could also retrive pubkeys over that process by sending different commands over stdio
02:12 < gmaxwell> And yes, for some kinds of usage, there would be a UI.. or things like hardware access.  other kinds, ("connect to bob.com and get him to SMS you then sign the transaction") perhaps not or only in error cases.
02:27 < GitHub176> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/517eee3e8f8b...618c9dd8c651
02:27 < GitHub176> bitcoin/master ab942c1 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
02:27 < GitHub176> bitcoin/master 618c9dd Wladimir J. van der Laan: Merge #8365: Treat high-sigop transactions as larger rather than rejecting them...
02:28 < GitHub182> [bitcoin] laanwj closed pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (master...unifysigopcost) https://github.com/bitcoin/bitcoin/pull/8365
02:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 260 seconds]
02:36 < sipa> anyone have any intuition about what hashrate you could get out of a raspberry pie?
02:37 < sipa> i'm writing an answer on quora, and being able to claim it would take a trillion years to redo the chainwork on a pi would be a nice statement...
02:37 < sipa> but that requires its hashrate to be at most 1.2 Mhash/s
02:40 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:42 < jonasschnelli> install CGMiner...
02:45 < gmaxwell> jonasschnelli: has no cpu mining.
02:45 < gmaxwell> sipa: openssl has a nice benchmark.
02:45 < jonasschnelli> Oh. I'm not familiar with mining, maybe install cpuminer..
02:45 < kinlo> sipa: raspberry pi will not get 1.2 Mhash/s
02:46 < kinlo> it's not that powerfull
02:46 < gmaxwell> you can scale that for actual use, e.g. three compression function runs, early termination, and asicboost if you want (maybe a 10% speedup). 
02:47  * gmaxwell goes to find the old bitcoin wiki page.
02:49 < gmaxwell> https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#ARM
02:50 < sipa> ok, http://qr.ae/1x0nad
02:50 < gmaxwell> funny how much slower original rpi is compared to sensible arm computers.
02:50 < gmaxwell> in any case those numbers are going to be too slow by about 10% or so because they don't implement asicboost.
02:51 < gmaxwell> "more energy than a whole country" is ... laughable
02:52 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
02:53 < gmaxwell> $35 million a month (a reasonable upper bound on mining's energy consumption)-- I wonder if any country uses that small an amount of electricity? Would the vatican count?
02:54 < gmaxwell> sipa: nice answer. :P
02:56 -!- G1lius [~stefangil@85.17.25.23] has joined #bitcoin-core-dev
02:56 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
03:04 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Remote host closed the connection]
03:08 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds]
03:10 -!- Giszmo [~leo@ppp-83-171-181-188.dynamic.mnet-online.de] has joined #bitcoin-core-dev
03:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 240 seconds]
03:23 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
03:24 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-ucagpuuhaaxxktkf] has quit [Quit: https://fnordserver.eu]
03:27 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
03:29 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
03:34 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
03:34 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
03:34 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
03:40 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:47 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-nzbxyaftiyzfltzg] has joined #bitcoin-core-dev
04:35 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
04:36 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:57 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:03 -!- anu1 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
05:07 -!- anu0 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 265 seconds]
05:07 < GitHub15> [bitcoin] jonasschnelli opened pull request #8407: [Qt] Add dbcache migration path (master...2016/07/qt_dbcache) https://github.com/bitcoin/bitcoin/pull/8407
05:08 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 276 seconds]
05:24 < GitHub29> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/618c9dd8c651...4b1a4d8810f9
05:24 < GitHub29> bitcoin/master 1ffaff2 Johnson Lau: Make witness v0 outputs non-standard before segwit activation
05:24 < GitHub29> bitcoin/master c59c434 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs
05:24 < GitHub29> bitcoin/master 4b1a4d8 Wladimir J. van der Laan: Merge #8381: Make witness v0 outputs non-standard...
05:24 < GitHub118> [bitcoin] laanwj closed pull request #8381: Make witness v0 outputs non-standard (master...patch-15) https://github.com/bitcoin/bitcoin/pull/8381
05:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
05:26 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
05:26 < GitHub164> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/86edc20a178c...4f7f531af6e1
05:26 < GitHub164> bitcoin/0.13 f84ee3d Johnson Lau: Make witness v0 outputs non-standard before segwit activation...
05:26 < GitHub164> bitcoin/0.13 4f7f531 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs...
05:28 < GitHub160> [bitcoin] laanwj closed pull request #8364: Fix counting of sigops cost in mempool check (master...fix-mempool-sigops) https://github.com/bitcoin/bitcoin/pull/8364
05:32 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
05:40 < GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4b1a4d8810f9...beadffae6d65
05:40 < GitHub30> bitcoin/master faa5931 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)
05:40 < GitHub30> bitcoin/master beadffa Wladimir J. van der Laan: Merge #8358: [doc] gbuild: Set memory explicitly (default is too low)...
05:40 < GitHub38> [bitcoin] laanwj closed pull request #8358: [doc] gbuild: Set memory explicitly (default is too low) (master...Mf1607-docBuild) https://github.com/bitcoin/bitcoin/pull/8358
05:41 < GitHub192> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/cfd1280f23bf687a38d3d00355ac94a3646cb59f
05:41 < GitHub192> bitcoin/0.13 cfd1280 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)...
05:45 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: brrb]
05:46 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
05:46 < GitHub199> [bitcoin] NicolasDorier closed pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (master...wallet-min-output) https://github.com/bitcoin/bitcoin/pull/8356
05:47 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
05:54 < sdaftuar> sipa: BlueMatt: i'm not sure i followed your discussion of the sendcmpct semantics
05:55 < sdaftuar> if a node supports version 1 and version 2, sure it can send 2 messages.  but since we attempt to keep track of which peers are announcing to us, how is that supposed to be calculated?
05:56 < sdaftuar> also, how do you know what version the compactblock announcements that you receive are generated with?
06:00 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-nzbxyaftiyzfltzg] has quit [Quit: https://fnordserver.eu]
06:02 < sipa> sdaftuar: for example: if a node sends a sendcmpct version 2 at any time, and received one, then getdata cmpctblocks must be version 2
06:02 < sdaftuar> sipa: ah okay, so we are looking at responses then. that makes sense to me.
06:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:04 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
06:05 < sipa> for unsollicited cmpctblocks, you can say that the last received sendcmpct takes effect (as that is the one with the announce bit set)
06:05 < sipa> but it's probably easier to just say that the last understood sendcmpct is what countd?
06:06 < sdaftuar> last one with an understood version number?  yes, i think that.
06:07 < sdaftuar> i guess changing version numbers should only really happen during initial handshake, otherwise we get race conditions
06:07 < sipa> so that means you'd send v1 and then v2 initially, without announce bit
06:09 < sipa> if the peer never sends you a v2, you never ask for announce and never ask for cmpctblock
06:10 < sipa> i don't think there is any race
06:10 < sdaftuar> i mean, you shoulnd'
06:10 < sdaftuar> you shouldn't later try to negotiate up to v2 
06:11 < sdaftuar> if several hours into our connection, i try to send you an announce=true, version=2 sendcmpct message, and you do the same, right before you make a compactblock announcmeent
06:11 < sdaftuar> then it would be unclear how the announcement is encoded
06:11 < sdaftuar> as i wouldn't know whether my message to you was received before that point, or not.
06:12 < sdaftuar> (if we previously negotiated to v1)
06:13 < sipa> right, there is a possible race
06:28 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-jvrghvkeunhyaymx] has joined #bitcoin-core-dev
06:36 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: brrb]
06:36 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
06:37 -!- cryptapus [~cryptapus@87.254.202.129] has joined #bitcoin-core-dev
06:37 -!- cryptapus [~cryptapus@87.254.202.129] has quit [Changing host]
06:37 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:43 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
06:48 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
06:55 < AaronvanW> https://twitter.com/spair/status/757908557949984769
06:55 < AaronvanW> "the #bitcoin core developers deserve a lot of credit for sticking to their guns on the block size issue" <- Stephen Pair on Twitter
06:55 < jonasschnelli> AaronvanW. :)
06:56 < jonasschnelli> "[...] sticking to their guns [...]" I think this is the US version for "being loyal"?
06:58 < AaronvanW> more like, not being intimidated or persuaded to do the wrong thing. doing what you believe is right.
06:59 < AaronvanW> (though I'm also no US native)
07:00 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
07:19 < kanzure> AaronvanW: wrong channel i think
07:29 < AaronvanW> o
07:29 < AaronvanW> k
07:45 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
07:45 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:47 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has joined #bitcoin-core-dev
07:48 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
07:50 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:25 -!- YOU-JI [~youyouyou@FL1-125-195-1-168.chb.mesh.ad.jp] has joined #bitcoin-core-dev
08:46 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has quit [Remote host closed the connection]
08:47 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
08:50 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
08:51 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:51 -!- netsinn is now known as netsin_
09:09 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has joined #bitcoin-core-dev
09:17 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
09:17 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
09:18 -!- cryptapus_ is now known as cryptapus
09:24 -!- netsin_ [~jiggalato@unaffiliated/jiggalator] has quit []
09:39 -!- YOU-JI [~youyouyou@FL1-125-195-1-168.chb.mesh.ad.jp] has quit [Quit: Leaving...]
09:48 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
09:53 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
09:55 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:01 < jtimon> ping #8348 #8346 and #8391
10:05 -!- netzin [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev
10:06 -!- netzin [~jiggalato@198.16.176.10] has quit [Client Quit]
10:48 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 258 seconds]
10:50 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
10:50 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
10:54 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
10:56 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has quit []
10:58 -!- netzin [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev
11:06 -!- netzin [~jiggalato@198.16.176.10] has quit []
11:06 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg]
11:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:50 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
11:52 < luke-jr> I have a fresh Core master build, that I started on an old testnet dir. It rewound the blockchain, and has not made any attempt to sync onward since
11:53 < luke-jr> for 22 minutes now
11:53 < luke-jr> sorry, 1 hour 22 minutes..
11:53 < luke-jr> getpeerinfo shows no blocks inflight from anyone
11:53 < luke-jr> two peers are 0.12.1
11:53 < luke-jr> sipa: ^ any ideas?
11:55 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:02 < sdaftuar> you need node_witness peers to download blocks from.  i wonder if the logic to query the dnsseeds needs to improved?  i would imagine that would solve your problem
12:03 < luke-jr> sdaftuar: are not 0.12.1 all NODE_WITNESS? O.o
12:03 < sdaftuar> uh, no released code is NODE_WITNESS
12:03 < luke-jr> got something I can addnode?
12:04 < luke-jr> right, I'm confusing segwit with csv now. :|
12:04 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has joined #bitcoin-core-dev
12:04 < instagibbs> there are reports that syncing on testnet is near impossible with master/0.13
12:04 < sdaftuar> this might work: x9.testnet-seed.bitcoin.jonasschnelli.ch
12:05 < sdaftuar> or you could restart with -forcednsseed maybe
12:08 < luke-jr> -forcednsseed seems to have worked, although I restarted in the process :x
12:10 < sdaftuar> my guess is we should more proactively use the dns seeds if the addrman is light on NODE_WITNESS nodes
12:11 < sdaftuar> i imagine this could be an annoying problem for people on mainnet down the road, if someone is upgrading from older software that doens't have the recent addrman improvements
12:11 < sdaftuar> which, i think, improved the bookkeeping on peer services
12:16 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
12:23 -!- netzin [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev
12:23 -!- netzin [~jiggalato@198.16.176.10] has quit [Client Quit]
12:24 -!- netsin_ [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev
12:34 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
12:34 -!- KwukDuck [~chatzilla@82-197-210-65.dsl.cambrium.nl] has quit [Read error: Connection reset by peer]
12:52 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
12:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
12:57 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:58 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
13:06 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 276 seconds]
13:08 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:28 -!- frankenmint [~frankenmi@67-5-255-55.ptld.qwest.net] has quit []
13:38 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
13:46 < luke-jr> is testnet really at 3.125 BTC subsidy? O.o
13:53 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
13:58 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
13:59 < Lightsword> yep
14:03 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
14:04 -!- netsin_ [~jiggalato@198.16.176.10] has quit []
14:04 -!- netsin_ [~jiggalato@198.16.176.10] has joined #bitcoin-core-dev
14:05 -!- netsin_ [~jiggalato@198.16.176.10] has quit [Client Quit]
14:05 -!- cryptapus_afk is now known as cryptapus
14:05 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
14:10 < luke-jr> anyone who can easily send a bunch of segwit txs on testnet? :x
14:15 -!- ad0r [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has joined #bitcoin-core-dev
14:15 -!- ad0r is now known as cdecker
14:18 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:21 < GitHub66> [bitcoin] sdaftuar opened pull request #8408: Prevent fingerprinting, disk-DoS with compact blocks (master...cb-misbehaving) https://github.com/bitcoin/bitcoin/pull/8408
14:25 < arubi> luke-jr, I made a few,  I don't have many funds
14:25 < luke-jr> arubi: hm, seems to have not relayed to me; can you pastebin them raw?
14:26 < arubi> hmm let's see.  might have easier time if I set it to output raw hex this time
14:27 < arubi> oh oops it was set to segnet :)  moment
14:27 < luke-jr> XD
14:28 < arubi> making some more txes
14:28 -!- cryptapus is now known as cryptapus_afk
14:30 < luke-jr> arubi: if you have a limited #, hold off a bit, I have a crash to debug XD
14:31 < arubi> no problem :).  I'm off to bed now anyway, will be doing some more tomorrow.  these are the ones I have from now, if you see them: http://paste.debian.net/hidden/b0b0c9ca/
14:32 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 244 seconds]
14:33 < arubi> and txs themselves http://paste.debian.net/hidden/283a36ab/
14:33 < arubi> heh, should've uniq, but you get what it means :)
14:35 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:40 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
14:54 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
14:59 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
15:10 < luke-jr> crap, someone mined the witness stuff
15:10 < luke-jr> anyone else? XD
15:24 < luke-jr> yay for invalidateblock <.<
15:37 < luke-jr> someone screwing with me by sending bitcoins to random mining addresses? <.<
15:37 < luke-jr> [testnet]
15:47 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds]
15:50 < luke-jr> Lightsword: can you mine a testnet block on top of mine? :p
15:50 < luke-jr> 000000000296ba9a3ef21c0978962203ee8b75a2e0b0a5a8ec57517ebb6b8e07
15:50 < luke-jr> (should be current best block)
15:50 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
15:50 < luke-jr> (anyone else is fine too, but preferably not using libblkmaker code)
15:56 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
15:57 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
16:01 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
16:03 -!- netzin [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection]
16:06 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev
16:08 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]
16:10 < luke-jr> thanks
16:27 -!- Giszmo [~leo@ppp-83-171-181-188.dynamic.mnet-online.de] has quit [Quit: Leaving.]
16:40 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds]
16:52 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
17:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
17:01 < luke-jr> https://github.com/bitcoin/libblkmaker/pull/6 review requested
17:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
17:14 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
17:19 -!- Guest19449 [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev
17:21 -!- Guest19449 is now known as roidster
17:37 < phantomcircuit> wumpus: what else more do i need to do on https://github.com/bitcoin/bitcoin/pull/8152 ?
17:37 < phantomcircuit> jonasschnelli: same question ^
17:43 -!- roidster [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]
18:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lrsjvxliphuhxalq] has quit [Quit: Connection closed for inactivity]
18:27 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
18:29 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
18:30 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:33 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:36 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
19:00 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds]
19:05 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
19:17 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
19:21 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
19:29 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
20:23 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
20:49 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds]
21:05 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
21:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:39 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
21:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:47 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:50 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
21:54 -!- d_t [~textual@185.69.203.10] has quit [Ping timeout: 250 seconds]
22:07 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds]
22:08 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 258 seconds]
22:09 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
22:10 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
22:12 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
22:23 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
22:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:06 -!- Yv7trNY [~IUTYVExrY@79.115.58.210] has joined #bitcoin-core-dev
23:10 -!- adiabat [~tx@159.203.193.74] has joined #bitcoin-core-dev
23:25 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
23:28 -!- squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds]
23:28 -!- Yv7trNY [~IUTYVExrY@79.115.58.210] has quit [Ping timeout: 250 seconds]
23:35 -!- Yv7trNY [~IUTYVExrY@79.115.58.210] has joined #bitcoin-core-dev
23:35 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:42 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:52 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-bcwfshnpybdflran] has quit [Ping timeout: 250 seconds]
23:52 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-vrmatxqqogmrpfzo] has joined #bitcoin-core-dev