12016-07-26T00:01:08  *** pedrobranco has joined #bitcoin-core-dev
  22016-07-26T00:03:48  *** justanotheruser has quit IRC
  32016-07-26T00:03:57  *** justanot1eruser has joined #bitcoin-core-dev
  42016-07-26T00:05:16  <sipa> luke-jr: don't forget marker and flag byte
  52016-07-26T00:05:28  *** pedrobranco has quit IRC
  62016-07-26T00:06:14  *** fengling has joined #bitcoin-core-dev
  72016-07-26T00:11:06  *** fengling has quit IRC
  82016-07-26T00:20:29  <luke-jr> sipa: ah, right, so +36
  92016-07-26T00:35:48  *** Ylbam has quit IRC
 102016-07-26T00:47:37  *** justanot1eruser is now known as justanotheruser
 112016-07-26T01:00:00  *** ryan-c has joined #bitcoin-core-dev
 122016-07-26T01:07:44  *** fengling has joined #bitcoin-core-dev
 132016-07-26T01:12:26  *** fengling has quit IRC
 142016-07-26T01:13:11  *** fengling has joined #bitcoin-core-dev
 152016-07-26T01:17:08  *** frankenmint has quit IRC
 162016-07-26T02:40:04  *** TomMc has quit IRC
 172016-07-26T02:47:02  *** Chris_Stewart_5 has quit IRC
 182016-07-26T03:27:26  *** d_t has quit IRC
 192016-07-26T04:03:58  *** anu0 has joined #bitcoin-core-dev
 202016-07-26T04:07:36  *** anu1 has quit IRC
 212016-07-26T04:22:19  *** harrymm has quit IRC
 222016-07-26T04:26:16  *** harrymm has joined #bitcoin-core-dev
 232016-07-26T04:32:44  *** Arnavion has quit IRC
 242016-07-26T04:32:48  *** Arnavion3 has joined #bitcoin-core-dev
 252016-07-26T04:32:52  *** Arnavion3 is now known as Arnavion
 262016-07-26T04:50:25  *** d_t has joined #bitcoin-core-dev
 272016-07-26T04:54:52  *** d_t has quit IRC
 282016-07-26T05:07:32  *** Arnavion has quit IRC
 292016-07-26T05:07:36  *** Arnavion3 has joined #bitcoin-core-dev
 302016-07-26T05:07:40  *** Arnavion3 is now known as Arnavion
 312016-07-26T05:16:22  *** Arnavion has quit IRC
 322016-07-26T05:23:12  *** Arnavion has joined #bitcoin-core-dev
 332016-07-26T05:24:20  *** d_t has joined #bitcoin-core-dev
 342016-07-26T05:30:12  *** Alopex has joined #bitcoin-core-dev
 352016-07-26T05:33:04  *** go1111111 has quit IRC
 362016-07-26T05:46:39  *** go1111111 has joined #bitcoin-core-dev
 372016-07-26T06:02:50  *** molly has joined #bitcoin-core-dev
 382016-07-26T06:06:22  *** molz has quit IRC
 392016-07-26T06:06:54  *** netsinn has quit IRC
 402016-07-26T06:26:20  *** BashCo has quit IRC
 412016-07-26T06:48:43  *** BashCo has joined #bitcoin-core-dev
 422016-07-26T06:58:54  <jonasschnelli> I'm impressed. A guy implemented bip151 in JS: https://github.com/bcoin-org/bcoin/blob/4af5273c0eb0f5fb5c9cfe68e4fe13afb005e410/lib/bcoin/bip151.js
 432016-07-26T07:11:12  *** aalex has quit IRC
 442016-07-26T07:15:25  *** aalex has joined #bitcoin-core-dev
 452016-07-26T07:16:38  *** d_t has quit IRC
 462016-07-26T07:20:23  <jonasschnelli> wumpus: do you think we should have an optional "keep-seed" argument when encrypting the wallet in 0.13?
 472016-07-26T07:20:50  <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)
 482016-07-26T07:22:45  <gmaxwell> keeping around a key that has been stored unencrypted on many systems is no better than not using encryption at all.
 492016-07-26T07:23:12  <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.
 502016-07-26T07:24:20  <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.
 512016-07-26T07:25:08  <jonasschnelli> We could add wallet initialization/creating to a (new) bitcoin-txish tool. "./bitcoin-wallet"
 522016-07-26T07:25:20  <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.
 532016-07-26T07:25:26  <gmaxwell> yuck
 542016-07-26T07:25:26  <sipa> jonasschnelli: i would be fine with just a function to import or export a seed from the wallet
 552016-07-26T07:25:27  <jonasschnelli> People could do all sorts of things with it. Dump, enctypt, create, export/import seeds.
 562016-07-26T07:25:53  <jonasschnelli> sipa: there is a PR to exporting the xpriv (over dumpwallet)
 572016-07-26T07:25:58  <sipa> jonasschnelli: if you want to keep the seed when encrypting, export the seed before and import after
 582016-07-26T07:25:58  <jonasschnelli> import is not possible now.
 592016-07-26T07:26:05  <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. :)
 602016-07-26T07:26:25  <jonasschnelli> Importing should be done together with a flexible keypath option.
 612016-07-26T07:26:36  *** Guyver2 has joined #bitcoin-core-dev
 622016-07-26T07:27:03  <sipa> that makes sense
 632016-07-26T07:27:43  <jonasschnelli> I guess users will would complain otherwise if you only can "import" seeds with m/0'/0'
 642016-07-26T07:27:51  <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.
 652016-07-26T07:28:47  <gmaxwell> There is a lot of complexity required to property handle multiple derrivation schemes within a wallet.
 662016-07-26T07:29:15  <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
 672016-07-26T07:29:26  <jonasschnelli> Wait... last three: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0
 682016-07-26T07:29:44  <gmaxwell> also unclear import with an explicit path would interact with implied chains (e.g. for chains)
 692016-07-26T07:30:19  <jonasschnelli> Yes. The whole importing situation is not yet clear to me....
 702016-07-26T07:30:27  <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.
 712016-07-26T07:30:37  <jonasschnelli> People might expect a lookup of the 0-n after importing a seed, etc.
 722016-07-26T07:30:51  <sipa> by import i guess i just meant "override deterministic keypath"
 732016-07-26T07:31:09  <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
 742016-07-26T07:31:17  <jonasschnelli> sipa: yes.
 752016-07-26T07:31:30  <gmaxwell> jonasschnelli: except that won't actually work reliably, and it would hobble security and functionality.
 762016-07-26T07:33:09  <jonasschnelli> gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
 772016-07-26T07:39:06  *** kadoban has quit IRC
 782016-07-26T07:40:58  *** aalex has quit IRC
 792016-07-26T07:45:24  *** aalex has joined #bitcoin-core-dev
 802016-07-26T07:48:58  <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
 812016-07-26T07:49:20  <wumpus> that wallets are 'born' unencrypted and later encrypted keeps causing difficulties
 822016-07-26T07:49:48  <wumpus> though I also don't like the idea of forcing people to set a passphrase on first use
 832016-07-26T07:56:52  <warren> Don't force them upon starting Core, only if they want receive addresses?
 842016-07-26T07:57:28  <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
 852016-07-26T07:57:46  <wumpus> warren: yes, that's an option
 862016-07-26T07:58:37  <gmaxwell> setting the passphrase prematurely is a sure path to funds loss.
 872016-07-26T07:58:49  <wumpus> right
 882016-07-26T07:59:03  <warren> Make them type the passphrase if they want a receive address?
 892016-07-26T07:59:23  <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?"
 902016-07-26T07:59:38  <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.
 912016-07-26T08:00:05  <sipa> what does electrum do?
 922016-07-26T08:00:30  <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
 932016-07-26T08:00:34  <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.
 942016-07-26T08:01:15  <gmaxwell> so it does the encrypting at install, but it makes you make an encryption free backup at the same time.
 952016-07-26T08:01:29  <gmaxwell> It also doesn't have hours/days lag between install and usability. :)
 962016-07-26T08:01:31  <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
 972016-07-26T08:01:59  <sipa> gmaxwell: also... our wallet model is really that you should not lose your wallet.dat
 982016-07-26T08:02:07  <wumpus> gmaxwell: there have been plenty of ideas of discouraging creating receive addresses at all before syncing up?
 992016-07-26T08:02:29  <gmaxwell> wumpus: well it's perfectly fine to recieve before synced, if you know that you won't see the results right away!
1002016-07-26T08:02:49  <wumpus> gmaxwell: but confusino about that almost no one knows that, and it results in 99% of support mails I get
1012016-07-26T08:02:50  *** AaronvanW has quit IRC
1022016-07-26T08:03:01  <sipa> sure, with deterministic seeds there is a way to recover your funds from catastrophic lost
1032016-07-26T08:03:07  <sipa> but not the rest...
1042016-07-26T08:03:12  <wumpus> gmaxwell: I'm not saying it should be impossible ofc
1052016-07-26T08:03:32  <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.
1062016-07-26T08:04:06  <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.
1072016-07-26T08:04:06  <wumpus> wallet.dat encryption helps against exploit that allow grabbing a named file from the file system, but not more
1082016-07-26T08:04:58  <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.
1092016-07-26T08:05:19  <wumpus> it's not exactly a panacea, but encryption never is, it only helps if it's used in the right way
1102016-07-26T08:05:23  <gmaxwell> but for that sort of thing a passphrase such as "goat" is perfectly fine. :P
1112016-07-26T08:05:48  <wumpus> in any case I don't think arguing about this makes sense - we're not considering removing wallet encryption I hope?
1122016-07-26T08:05:54  <sipa> i'm sure more funds have been lost from forgotten passphrases than from theft
1132016-07-26T08:06:09  <sipa> wumpus: hell no
1142016-07-26T08:06:14  <gmaxwell> wumpus: yea, not going to remove it. (I say with some regret.)
1152016-07-26T08:06:39  <gmaxwell> (because as sipa says, I'm pretty confident that more funds have been lost to lost passphrases, than saved from theft by it)
1162016-07-26T08:06:49  <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.
1172016-07-26T08:07:04  <gmaxwell> wumpus: same malware also has keylogging hooks.
1182016-07-26T08:07:18  <wumpus> gmaxwell: that's not an argument against theft happening
1192016-07-26T08:07:27  <wumpus> gmaxwell: just that the current security may not be good enough
1202016-07-26T08:07:59  <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.
1212016-07-26T08:08:09  <gmaxwell> forgotten vs protected from theft by encryption.
1222016-07-26T08:08:24  <wumpus> hw wallets would be preferable, and I think we need to support those in the future
1232016-07-26T08:08:29  <gmaxwell> I do know of cases protected from theft by encryption, but few.
1242016-07-26T08:08:38  <gmaxwell> wumpus: yes.
1252016-07-26T08:08:57  <wumpus> but repeating this discussion for/against wallet encrption every few months is not going to help :)
1262016-07-26T08:09:38  <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.
1272016-07-26T08:10:26  <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
1282016-07-26T08:11:06  <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.
1292016-07-26T08:11:17  <gmaxwell> can't spell tonight.
1302016-07-26T08:12:27  <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.
1312016-07-26T08:14:04  <wumpus> gmaxwell: yes, we agree there, I started this off with stating that I don't like forcing the user to set a passphrase
1322016-07-26T08:14:25  <wumpus> and I don't think a goal should be to encourage people to use the encryption
1332016-07-26T08:14:34  <wumpus> but if they want to use it, they should be able to
1342016-07-26T08:14:47  <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.
1352016-07-26T08:14:55  <wumpus> and then it should also be as secure *as possible given the constraints of local usage tc*
1362016-07-26T08:15:37  <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.
1372016-07-26T08:17:17  <wumpus> indeed, an unencrypted backup makes sense combined with physical security
1382016-07-26T08:17:31  <sipa> then again we don't even have a user-friendly way to recover from a backup...
1392016-07-26T08:17:33  <wumpus> if only they don't put it in the cloud :(
1402016-07-26T08:18:14  <gmaxwell> wumpus: electrum works hard to make you actually write it down... it does all it can to prevent your backup from being electronic.
1412016-07-26T08:18:31  *** AaronvanW has joined #bitcoin-core-dev
1422016-07-26T08:18:31  *** AaronvanW has quit IRC
1432016-07-26T08:18:31  *** AaronvanW has joined #bitcoin-core-dev
1442016-07-26T08:18:47  <wumpus> gmaxwell: yes that is good
1452016-07-26T08:19:29  <wumpus> sipa: yes, which wouldnthere the ugly problem of lack of people actually interested in working on it rears its head again
1462016-07-26T08:19:36  <wumpus> which wouldn't be rocket science*
1472016-07-26T08:20:03  *** Guyver2 has quit IRC
1482016-07-26T08:20:46  <wumpus> I mean there is a 'backup wallet' menu option, could add an 'import wallet' option too
1492016-07-26T08:20:54  <wumpus> although it would work better with multi-wallet support I guess
1502016-07-26T08:20:57  <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.
1512016-07-26T08:21:17  *** Ylbam has joined #bitcoin-core-dev
1522016-07-26T08:21:21  <gmaxwell> Restore is mostly a disaster until something is done about rescan.
1532016-07-26T08:21:31  <btcdrak> greenaddress has encrypted seeds so you put in a passohrase and it gives you an encrypted seed
1542016-07-26T08:21:38  <wumpus> why? it doesn't matter if restore takes a while, it will be an infrequent operation
1552016-07-26T08:21:46  <btcdrak> that is part of the initialisation process.
1562016-07-26T08:22:07  <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
1572016-07-26T08:22:13  <gmaxwell> wumpus: there is "a while" and then there is ">8 hours" which is what a rescan takes on my laptop.
1582016-07-26T08:22:33  <wumpus> gmaxwell: that long? oh last time I did it it was much faster
1592016-07-26T08:22:39  <wumpus> yes, >8 hours is bad
1602016-07-26T08:22:46  <btcdrak> rescan? ouch
1612016-07-26T08:22:59  <gmaxwell> I think on a fast machine its about 5 hours now, down from about 12 prior to 0.12.0.
1622016-07-26T08:23:01  <btcdrak> good case for keeping an addrindex
1632016-07-26T08:23:01  <wumpus> that's longer than a reindex takes in good circumstances
1642016-07-26T08:23:06  * btcdrak ducks
1652016-07-26T08:23:41  <wumpus> why is a rescan so slow? it's a fairly simple scan over data right?
1662016-07-26T08:23:51  <gmaxwell> deseralizes every block and every transaction.
1672016-07-26T08:24:17  <wumpus> so deserialization-bound? ok
1682016-07-26T08:24:20  <gmaxwell> and then is constantly opening and closing the wallet database.
1692016-07-26T08:24:40  <gmaxwell> I believe that one of phantomcircuit's wallet fixes (maybe in the pipeline) fixed the latter part.
1702016-07-26T08:24:44  <wumpus> I guess there's room for optimization there, it wouldn't need to deserialize everything
1712016-07-26T08:25:25  <wumpus> many operations could be done in-place on the data
1722016-07-26T08:25:50  <gmaxwell> or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
1732016-07-26T08:26:32  <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.
1742016-07-26T08:26:34  <wumpus> anyhow: why would importing a wallet.at require a rescan?
1752016-07-26T08:26:51  <wumpus> it's no different from replacing your wallet.dat with a different one and restarting the client
1762016-07-26T08:27:09  <gmaxwell> it always requires _some_ rescanning; assuming it was offline more than one blocktime :P
1772016-07-26T08:27:16  <gmaxwell> but presumably a backup is old.
1782016-07-26T08:27:20  <wumpus> the transaction should already be in there. Sure, it may need to catch up a bit, but no full rescan should be needed
1792016-07-26T08:27:44  <gmaxwell> well the first 300k blocks rescan in pretty much no time. :P
1802016-07-26T08:27:49  <wumpus> partial rescans are pretty fast at least in my experience
1812016-07-26T08:28:12  <wumpus> I just don't think this is a blocker issue for implementing wallet import, if someone really wanted to implement it
1822016-07-26T08:28:23  <wumpus> optimizing rescan would be awesome still
1832016-07-26T08:28:52  <gmaxwell> I have data on the partial rescan.
1842016-07-26T08:29:10  <sipa> the wallet should be able to tell the node code that some range of blocks is to be downloaded agaim
1852016-07-26T08:30:05  <gmaxwell> 2016-07-25 06:57:24 Rescanning last 5556 blocks (from block 416625)...
1862016-07-26T08:30:09  <gmaxwell> 2016-07-25 07:02:23  rescan               298400ms
1872016-07-26T08:30:12  <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
1882016-07-26T08:30:23  <gmaxwell> that was a backup restore I did a day ago.
1892016-07-26T08:30:37  <sipa> gmaxwell: many matching transactiond in that range?
1902016-07-26T08:30:50  <wumpus> a lot things never get done because too many other things are dragged into it, the old scope creep again
1912016-07-26T08:30:53  <gmaxwell> sipa: none.
1922016-07-26T08:31:00  <sipa> gmaxwell: ugh
1932016-07-26T08:31:28  <sipa> well, 1 second per week
1942016-07-26T08:31:35  <wumpus> oh so you want to implement wallet importing? we first need to improve rescan performance. Oh never mind then...
1952016-07-26T08:32:11  <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.
1962016-07-26T08:32:22  <wumpus> gmaxwell: yes, that's a very bad data point.
1972016-07-26T08:33:38  <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.
1982016-07-26T08:34:22  <wumpus> talking about rescanning, did anyone ever notice this issue: https://github.com/bitcoin/bitcoin/issues/8116
1992016-07-26T08:34:35  <wumpus> the rescan suddenly started over
2002016-07-26T08:34:47  <wumpus> I'm sure it can be really slow if it's done multiple times :p
2012016-07-26T08:37:07  <gmaxwell> freaky, I don't think I've seen it do that before.
2022016-07-26T08:37:35  <gmaxwell> oh I see you imported while it was already rescanning, and so it started over?
2032016-07-26T08:37:57  <gmaxwell> oh no your import is what triggered the rescan and the new block restarted it.
2042016-07-26T08:37:59  <wumpus> no, that's not even possible
2052016-07-26T08:38:06  <wumpus> if it's rescanning everything is blocked
2062016-07-26T08:38:16  <wumpus> yes, that seems to be the case
2072016-07-26T08:38:43  <gmaxwell> weird. pretty sure I've seen it connect blocks while rescannign and not start over.
2082016-07-26T08:41:48  <wumpus> maybe it was just a fluke. But it could explain some very slow rescans
2092016-07-26T08:42:28  <gmaxwell> not the ones I've been expirencing at least.
2102016-07-26T08:42:35  <wumpus> the end result was correct so I didn't make a big issue out of it
2112016-07-26T08:42:38  <gmaxwell> but some of the complaints for sure.
2122016-07-26T08:43:22  *** jtimon has joined #bitcoin-core-dev
2132016-07-26T08:43:34  <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.
2142016-07-26T08:46:26  <gmaxwell> da2ce7_mobile: what you're asking there could describe several different actual usecases which have different supporting development requirements.
2152016-07-26T08:47:08  <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.
2162016-07-26T08:47:52  <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)
2172016-07-26T08:48:53  <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.
2182016-07-26T08:49:08  <da2ce7_mobile> You could import these seeds into your Bitcoin Core to act as hot-wallets.
2192016-07-26T08:50:04  <gmaxwell> you mean extended public keys there.
2202016-07-26T08:50:14  <gmaxwell> IIRC trezor has absolutely no private key export.
2212016-07-26T08:50:54  <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.
2222016-07-26T08:50:57  <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.
2232016-07-26T08:51:29  <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.
2242016-07-26T08:51:45  <da2ce7_mobile> yeah. It would be great if BIP44 had a 'hardened only' option.
2252016-07-26T08:52:06  <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.
2262016-07-26T08:53:04  <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.
2272016-07-26T08:53:09  <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.
2282016-07-26T08:55:46  <da2ce7_mobile> I really don't like public derivation.  I don't see any point of it if you have a hardware wallet.
2292016-07-26T08:56:15  <da2ce7_mobile> it is userfull for 'watch only'
2302016-07-26T08:56:29  <da2ce7_mobile> but most people don't use watch only accounts.
2312016-07-26T08:57:21  <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.
2322016-07-26T08:57:49  <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.
2332016-07-26T08:57:57  <jonasschnelli> da2ce7_mobile: indeed
2342016-07-26T08:58:12  <gmaxwell> da2ce7_mobile: indeed. Public derrivation causes a lot of trouble for a very narrow improvement.
2352016-07-26T08:58:33  <gmaxwell> it's useful, but the utility is often overhyped.
2362016-07-26T08:58:52  <sipa> ... says the man who invented iy
2372016-07-26T08:58:55  <sipa> :)
2382016-07-26T08:58:59  <sipa> *iy
2392016-07-26T08:59:02  <sipa> **it
2402016-07-26T08:59:20  <jonasschnelli> hehe
2412016-07-26T08:59:42  <jonasschnelli> I think there are serval usecases for pubkd... but not for the novice wallet user
2422016-07-26T08:59:58  <gmaxwell> sipa: yup.
2432016-07-26T09:00:21  <jonasschnelli> So... I'm kinda no longer sure if we even want to allow flexible keypath... with or without pubckd
2442016-07-26T09:00:54  <jonasschnelli> We should probably work more towards supporting cold storages with something like "importmulti"
2452016-07-26T09:01:41  <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
2462016-07-26T09:01:48  <gmaxwell> on addresses is also undesirable. :P
2472016-07-26T09:02:22  <gmaxwell> I think supporting offline wallets, HW wallets, and multisig with these things should be a higher priority than anything about derrivation paths.
2482016-07-26T09:02:38  <gmaxwell> Some things like multisig might imply things about derrivation paths, and thats fine.
2492016-07-26T09:03:41  <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.
2502016-07-26T09:03:42  <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)
2512016-07-26T09:04:08  <jonasschnelli> rawtx is possible because fundrawtx has a custom change address in 0.13.
2522016-07-26T09:04:42  <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"
2532016-07-26T09:04:43  <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.
2542016-07-26T09:05:16  <jonasschnelli> gmaxwell: I though it would be most simple if it would be TCP/HTTP
2552016-07-26T09:05:33  <jonasschnelli> A json call goes out to a configurable URL, a response might come back.
2562016-07-26T09:05:58  <jonasschnelli> Would also possible allow to sign on a cold storage attached to a different computer in your LAN
2572016-07-26T09:05:59  <gmaxwell> Then you get CSRF from js running on the users machine...
2582016-07-26T09:06:12  <jonasschnelli> You can avoid that...
2592016-07-26T09:06:15  <gmaxwell> different computer; now the communication needs to be cryptographically protected.
2602016-07-26T09:06:27  <gmaxwell> Sure you can but you just said, most simple.
2612016-07-26T09:06:40  <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.
2622016-07-26T09:06:43  <gmaxwell> Having to avoid CSRF and provide link layer encryption is not simple.
2632016-07-26T09:06:50  <jonasschnelli> Launching a process... yes. Why not...
2642016-07-26T09:06:55  *** harding has joined #bitcoin-core-dev
2652016-07-26T09:06:59  <jonasschnelli> It would also eliminate the need for a background daemon
2662016-07-26T09:07:22  <jonasschnelli> Can you check if a certain process (application at path) is already running?
2672016-07-26T09:07:33  <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.
2682016-07-26T09:07:37  <jonasschnelli> Or how would you prevent from spinning off to many processes?
2692016-07-26T09:08:51  <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.
2702016-07-26T09:10:52  <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...
2712016-07-26T09:11:09  <gmaxwell> By blocking I just meant bitcoin core wouldn't open multiple processes.
2722016-07-26T09:11:15  <jonasschnelli> But right, you could track on the bitcoincore side if there is already a signing in process and refuse anotherone.
2732016-07-26T09:11:25  <gmaxwell> Not the actual mechenism for talking to the file descriptors.
2742016-07-26T09:12:13  *** jannes has joined #bitcoin-core-dev
2752016-07-26T09:12:36  <jonasschnelli> You could also retrive pubkeys over that process by sending different commands over stdio
2762016-07-26T09:12:45  <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.
2772016-07-26T09:27:57  <GitHub176> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/517eee3e8f8b...618c9dd8c651
2782016-07-26T09:27:57  <GitHub176> bitcoin/master ab942c1 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
2792016-07-26T09:27:58  <GitHub176> bitcoin/master 618c9dd Wladimir J. van der Laan: Merge #8365: Treat high-sigop transactions as larger rather than rejecting them...
2802016-07-26T09:28:10  <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
2812016-07-26T09:33:47  *** spudowiar has quit IRC
2822016-07-26T09:36:54  <sipa> anyone have any intuition about what hashrate you could get out of a raspberry pie?
2832016-07-26T09:37:26  <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...
2842016-07-26T09:37:48  <sipa> but that requires its hashrate to be at most 1.2 Mhash/s
2852016-07-26T09:40:52  *** pedrobranco has joined #bitcoin-core-dev
2862016-07-26T09:42:53  <jonasschnelli> install CGMiner...
2872016-07-26T09:45:07  <gmaxwell> jonasschnelli: has no cpu mining.
2882016-07-26T09:45:26  <gmaxwell> sipa: openssl has a nice benchmark.
2892016-07-26T09:45:47  <jonasschnelli> Oh. I'm not familiar with mining, maybe install cpuminer..
2902016-07-26T09:45:54  <kinlo> sipa: raspberry pi will not get 1.2 Mhash/s
2912016-07-26T09:46:01  <kinlo> it's not that powerfull
2922016-07-26T09:46:30  <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).
2932016-07-26T09:47:07  * gmaxwell goes to find the old bitcoin wiki page.
2942016-07-26T09:49:52  <gmaxwell> https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#ARM
2952016-07-26T09:50:29  <sipa> ok, http://qr.ae/1x0nad
2962016-07-26T09:50:32  <gmaxwell> funny how much slower original rpi is compared to sensible arm computers.
2972016-07-26T09:50:48  <gmaxwell> in any case those numbers are going to be too slow by about 10% or so because they don't implement asicboost.
2982016-07-26T09:51:38  <gmaxwell> "more energy than a whole country" is ... laughable
2992016-07-26T09:52:37  *** Ginnarr has joined #bitcoin-core-dev
3002016-07-26T09:53:14  <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?
3012016-07-26T09:54:34  <gmaxwell> sipa: nice answer. :P
3022016-07-26T09:56:02  *** G1lius has joined #bitcoin-core-dev
3032016-07-26T09:56:32  *** spudowiar has joined #bitcoin-core-dev
3042016-07-26T10:04:48  *** devrandom has quit IRC
3052016-07-26T10:08:26  *** [Author] has quit IRC
3062016-07-26T10:10:31  *** Giszmo has joined #bitcoin-core-dev
3072016-07-26T10:16:04  *** spudowiar has quit IRC
3082016-07-26T10:23:59  *** [Author] has joined #bitcoin-core-dev
3092016-07-26T10:24:58  *** crudel has quit IRC
3102016-07-26T10:27:04  *** jtimon has quit IRC
3112016-07-26T10:29:35  *** spudowiar has joined #bitcoin-core-dev
3122016-07-26T10:34:56  *** afk11 has joined #bitcoin-core-dev
3132016-07-26T10:34:56  *** afk11 has quit IRC
3142016-07-26T10:34:56  *** afk11 has joined #bitcoin-core-dev
3152016-07-26T10:40:30  *** pedrobranco has quit IRC
3162016-07-26T10:47:58  *** crudel has joined #bitcoin-core-dev
3172016-07-26T11:35:46  *** fengling has quit IRC
3182016-07-26T11:36:35  *** Ginnarr has quit IRC
3192016-07-26T11:57:46  *** jtimon has joined #bitcoin-core-dev
3202016-07-26T12:03:56  *** anu1 has joined #bitcoin-core-dev
3212016-07-26T12:07:13  *** anu0 has quit IRC
3222016-07-26T12:07:24  <GitHub15> [bitcoin] jonasschnelli opened pull request #8407: [Qt] Add dbcache migration path (master...2016/07/qt_dbcache) https://github.com/bitcoin/bitcoin/pull/8407
3232016-07-26T12:08:36  *** afk11 has quit IRC
3242016-07-26T12:24:39  <GitHub29> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/618c9dd8c651...4b1a4d8810f9
3252016-07-26T12:24:40  <GitHub29> bitcoin/master 1ffaff2 Johnson Lau: Make witness v0 outputs non-standard before segwit activation
3262016-07-26T12:24:40  <GitHub29> bitcoin/master c59c434 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs
3272016-07-26T12:24:41  <GitHub29> bitcoin/master 4b1a4d8 Wladimir J. van der Laan: Merge #8381: Make witness v0 outputs non-standard...
3282016-07-26T12:24:54  <GitHub118> [bitcoin] laanwj closed pull request #8381: Make witness v0 outputs non-standard (master...patch-15) https://github.com/bitcoin/bitcoin/pull/8381
3292016-07-26T12:26:02  *** laurentmt has joined #bitcoin-core-dev
3302016-07-26T12:26:04  *** laurentmt has quit IRC
3312016-07-26T12:26:14  <GitHub164> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/86edc20a178c...4f7f531af6e1
3322016-07-26T12:26:14  <GitHub164> bitcoin/0.13 f84ee3d Johnson Lau: Make witness v0 outputs non-standard before segwit activation...
3332016-07-26T12:26:15  <GitHub164> bitcoin/0.13 4f7f531 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs...
3342016-07-26T12:28:39  <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
3352016-07-26T12:32:17  *** fengling has joined #bitcoin-core-dev
3362016-07-26T12:40:42  <GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4b1a4d8810f9...beadffae6d65
3372016-07-26T12:40:42  <GitHub30> bitcoin/master faa5931 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)
3382016-07-26T12:40:43  <GitHub30> bitcoin/master beadffa Wladimir J. van der Laan: Merge #8358: [doc] gbuild: Set memory explicitly (default is too low)...
3392016-07-26T12:40:57  <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
3402016-07-26T12:41:32  <GitHub192> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/cfd1280f23bf687a38d3d00355ac94a3646cb59f
3412016-07-26T12:41:32  <GitHub192> bitcoin/0.13 cfd1280 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)...
3422016-07-26T12:45:45  *** spudowiar has quit IRC
3432016-07-26T12:46:01  *** spudowiar has joined #bitcoin-core-dev
3442016-07-26T12:46:59  <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
3452016-07-26T12:47:06  *** fengling has quit IRC
3462016-07-26T12:54:32  <sdaftuar> sipa: BlueMatt: i'm not sure i followed your discussion of the sendcmpct semantics
3472016-07-26T12:55:17  <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?
3482016-07-26T12:56:07  <sdaftuar> also, how do you know what version the compactblock announcements that you receive are generated with?
3492016-07-26T13:00:33  *** crudel has quit IRC
3502016-07-26T13:02:00  <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
3512016-07-26T13:02:29  <sdaftuar> sipa: ah okay, so we are looking at responses then. that makes sense to me.
3522016-07-26T13:04:20  *** laurentmt has joined #bitcoin-core-dev
3532016-07-26T13:04:38  *** laurentmt has quit IRC
3542016-07-26T13:05:16  <sipa> for unsollicited cmpctblocks, you can say that the last received sendcmpct takes effect (as that is the one with the announce bit set)
3552016-07-26T13:05:41  <sipa> but it's probably easier to just say that the last understood sendcmpct is what countd?
3562016-07-26T13:06:15  <sdaftuar> last one with an understood version number?  yes, i think that.
3572016-07-26T13:07:25  <sdaftuar> i guess changing version numbers should only really happen during initial handshake, otherwise we get race conditions
3582016-07-26T13:07:26  <sipa> so that means you'd send v1 and then v2 initially, without announce bit
3592016-07-26T13:09:37  <sipa> if the peer never sends you a v2, you never ask for announce and never ask for cmpctblock
3602016-07-26T13:10:00  <sipa> i don't think there is any race
3612016-07-26T13:10:18  <sdaftuar> i mean, you shoulnd'
3622016-07-26T13:10:24  <sdaftuar> you shouldn't later try to negotiate up to v2
3632016-07-26T13:11:12  <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
3642016-07-26T13:11:19  <sdaftuar> then it would be unclear how the announcement is encoded
3652016-07-26T13:11:39  <sdaftuar> as i wouldn't know whether my message to you was received before that point, or not.
3662016-07-26T13:12:01  <sdaftuar> (if we previously negotiated to v1)
3672016-07-26T13:13:13  <sipa> right, there is a possible race
3682016-07-26T13:28:57  *** crudel has joined #bitcoin-core-dev
3692016-07-26T13:36:14  *** spudowiar has quit IRC
3702016-07-26T13:36:35  *** spudowiar has joined #bitcoin-core-dev
3712016-07-26T13:37:55  *** cryptapus has joined #bitcoin-core-dev
3722016-07-26T13:37:55  *** cryptapus has joined #bitcoin-core-dev
3732016-07-26T13:43:56  *** fengling has joined #bitcoin-core-dev
3742016-07-26T13:48:46  *** fengling has quit IRC
3752016-07-26T13:55:05  <AaronvanW> https://twitter.com/spair/status/757908557949984769
3762016-07-26T13:55:25  <AaronvanW> "the #bitcoin core developers deserve a lot of credit for sticking to their guns on the block size issue" <- Stephen Pair on Twitter
3772016-07-26T13:55:31  <jonasschnelli> AaronvanW. :)
3782016-07-26T13:56:25  <jonasschnelli> "[...] sticking to their guns [...]" I think this is the US version for "being loyal"?
3792016-07-26T13:58:58  <AaronvanW> more like, not being intimidated or persuaded to do the wrong thing. doing what you believe is right.
3802016-07-26T13:59:05  <AaronvanW> (though I'm also no US native)
3812016-07-26T14:00:37  *** laurentmt has joined #bitcoin-core-dev
3822016-07-26T14:19:02  <kanzure> AaronvanW: wrong channel i think
3832016-07-26T14:29:34  <AaronvanW> o
3842016-07-26T14:29:35  <AaronvanW> k
3852016-07-26T14:45:31  *** fengling has joined #bitcoin-core-dev
3862016-07-26T14:45:38  *** cryptapus_ has joined #bitcoin-core-dev
3872016-07-26T14:47:25  *** frankenmint has joined #bitcoin-core-dev
3882016-07-26T14:48:34  *** cryptapus has quit IRC
3892016-07-26T14:50:26  *** fengling has quit IRC
3902016-07-26T15:25:51  *** YOU-JI has joined #bitcoin-core-dev
3912016-07-26T15:46:10  *** frankenmint has quit IRC
3922016-07-26T15:47:31  *** fengling has joined #bitcoin-core-dev
3932016-07-26T15:50:25  *** netsinn has joined #bitcoin-core-dev
3942016-07-26T15:51:46  *** fengling has quit IRC
3952016-07-26T15:51:57  *** netsinn is now known as netsin_
3962016-07-26T16:09:54  *** frankenmint has joined #bitcoin-core-dev
3972016-07-26T16:17:48  *** cryptapus_ has quit IRC
3982016-07-26T16:17:58  *** cryptapus_ has joined #bitcoin-core-dev
3992016-07-26T16:18:10  *** cryptapus_ is now known as cryptapus
4002016-07-26T16:24:54  *** netsin_ has quit IRC
4012016-07-26T16:39:56  *** YOU-JI has quit IRC
4022016-07-26T16:48:33  *** fengling has joined #bitcoin-core-dev
4032016-07-26T16:53:26  *** fengling has quit IRC
4042016-07-26T16:55:50  *** kadoban has joined #bitcoin-core-dev
4052016-07-26T17:01:48  <jtimon> ping #8348 #8346 and #8391
4062016-07-26T17:05:43  *** netzin has joined #bitcoin-core-dev
4072016-07-26T17:48:15  *** arubi has quit IRC
4082016-07-26T17:50:01  *** arubi has joined #bitcoin-core-dev
4092016-07-26T17:50:02  *** fengling has joined #bitcoin-core-dev
4102016-07-26T17:54:26  *** fengling has quit IRC
4112016-07-26T17:56:05  *** frankenmint has quit IRC
4122016-07-26T17:58:48  *** netzin has joined #bitcoin-core-dev
4132016-07-26T18:06:03  *** netzin has quit IRC
4142016-07-26T18:06:47  *** spudowiar has quit IRC
4152016-07-26T18:29:24  *** Guyver2 has joined #bitcoin-core-dev
4162016-07-26T18:50:44  *** fengling has joined #bitcoin-core-dev
4172016-07-26T18:52:50  <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
4182016-07-26T18:53:04  <luke-jr> for 22 minutes now
4192016-07-26T18:53:14  <luke-jr> sorry, 1 hour 22 minutes..
4202016-07-26T18:53:41  <luke-jr> getpeerinfo shows no blocks inflight from anyone
4212016-07-26T18:53:52  <luke-jr> two peers are 0.12.1
4222016-07-26T18:53:57  <luke-jr> sipa: ^ any ideas?
4232016-07-26T18:55:26  *** fengling has quit IRC
4242016-07-26T19:02:53  <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
4252016-07-26T19:03:20  <luke-jr> sdaftuar: are not 0.12.1 all NODE_WITNESS? O.o
4262016-07-26T19:03:34  <sdaftuar> uh, no released code is NODE_WITNESS
4272016-07-26T19:03:35  <luke-jr> got something I can addnode?
4282016-07-26T19:04:03  <luke-jr> right, I'm confusing segwit with csv now. :|
4292016-07-26T19:04:16  *** frankenmint has joined #bitcoin-core-dev
4302016-07-26T19:04:25  <instagibbs> there are reports that syncing on testnet is near impossible with master/0.13
4312016-07-26T19:04:40  <sdaftuar> this might work: x9.testnet-seed.bitcoin.jonasschnelli.ch
4322016-07-26T19:05:02  <sdaftuar> or you could restart with -forcednsseed maybe
4332016-07-26T19:08:21  <luke-jr> -forcednsseed seems to have worked, although I restarted in the process :x
4342016-07-26T19:10:37  <sdaftuar> my guess is we should more proactively use the dns seeds if the addrman is light on NODE_WITNESS nodes
4352016-07-26T19:11:00  <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
4362016-07-26T19:11:15  <sdaftuar> which, i think, improved the bookkeeping on peer services
4372016-07-26T19:16:25  *** jtimon has quit IRC
4382016-07-26T19:23:01  *** netzin has joined #bitcoin-core-dev
4392016-07-26T19:24:00  *** netsin_ has joined #bitcoin-core-dev
4402016-07-26T19:34:23  *** BashCo has quit IRC
4412016-07-26T19:34:49  *** KwukDuck has quit IRC
4422016-07-26T19:52:10  *** fengling has joined #bitcoin-core-dev
4432016-07-26T19:53:42  *** BashCo has joined #bitcoin-core-dev
4442016-07-26T19:57:06  *** fengling has quit IRC
4452016-07-26T19:58:46  *** jtimon has joined #bitcoin-core-dev
4462016-07-26T20:06:21  *** anu1 has quit IRC
4472016-07-26T20:08:25  *** cryptapus has quit IRC
4482016-07-26T20:28:29  *** frankenmint has quit IRC
4492016-07-26T20:38:43  *** belcher has joined #bitcoin-core-dev
4502016-07-26T20:46:17  <luke-jr> is testnet really at 3.125 BTC subsidy? O.o
4512016-07-26T20:53:45  *** fengling has joined #bitcoin-core-dev
4522016-07-26T20:58:26  *** fengling has quit IRC
4532016-07-26T20:59:53  <Lightsword> yep
4542016-07-26T21:03:30  *** zooko has joined #bitcoin-core-dev
4552016-07-26T21:04:38  *** netsin_ has quit IRC
4562016-07-26T21:04:57  *** netsin_ has joined #bitcoin-core-dev
4572016-07-26T21:05:18  *** cryptapus_afk is now known as cryptapus
4582016-07-26T21:05:37  *** netzin has joined #bitcoin-core-dev
4592016-07-26T21:10:23  <luke-jr> anyone who can easily send a bunch of segwit txs on testnet? :x
4602016-07-26T21:15:06  *** ad0r has joined #bitcoin-core-dev
4612016-07-26T21:15:33  *** ad0r is now known as cdecker
4622016-07-26T21:18:09  *** spudowiar has joined #bitcoin-core-dev
4632016-07-26T21:21:46  <GitHub66> [bitcoin] sdaftuar opened pull request #8408: Prevent fingerprinting, disk-DoS with compact blocks (master...cb-misbehaving) https://github.com/bitcoin/bitcoin/pull/8408
4642016-07-26T21:25:04  <arubi> luke-jr, I made a few,  I don't have many funds
4652016-07-26T21:25:47  <luke-jr> arubi: hm, seems to have not relayed to me; can you pastebin them raw?
4662016-07-26T21:26:41  <arubi> hmm let's see.  might have easier time if I set it to output raw hex this time
4672016-07-26T21:27:29  <arubi> oh oops it was set to segnet :)  moment
4682016-07-26T21:27:35  <luke-jr> XD
4692016-07-26T21:28:25  <arubi> making some more txes
4702016-07-26T21:28:58  *** cryptapus is now known as cryptapus_afk
4712016-07-26T21:30:30  <luke-jr> arubi: if you have a limited #, hold off a bit, I have a crash to debug XD
4722016-07-26T21:31:13  <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/
4732016-07-26T21:32:38  *** spudowiar has quit IRC
4742016-07-26T21:33:19  <arubi> and txs themselves http://paste.debian.net/hidden/283a36ab/
4752016-07-26T21:33:38  <arubi> heh, should've uniq, but you get what it means :)
4762016-07-26T21:35:39  *** spudowiar has joined #bitcoin-core-dev
4772016-07-26T21:40:15  *** spudowiar has quit IRC
4782016-07-26T21:54:48  *** fengling has joined #bitcoin-core-dev
4792016-07-26T21:59:46  *** fengling has quit IRC
4802016-07-26T22:10:03  <luke-jr> crap, someone mined the witness stuff
4812016-07-26T22:10:39  <luke-jr> anyone else? XD
4822016-07-26T22:24:14  <luke-jr> yay for invalidateblock <.<
4832016-07-26T22:37:37  <luke-jr> someone screwing with me by sending bitcoins to random mining addresses? <.<
4842016-07-26T22:37:46  <luke-jr> [testnet]
4852016-07-26T22:47:33  *** zooko has quit IRC
4862016-07-26T22:50:06  <luke-jr> Lightsword: can you mine a testnet block on top of mine? :p
4872016-07-26T22:50:16  <luke-jr> 000000000296ba9a3ef21c0978962203ee8b75a2e0b0a5a8ec57517ebb6b8e07
4882016-07-26T22:50:24  <luke-jr> (should be current best block)
4892016-07-26T22:50:44  *** cdecker has quit IRC
4902016-07-26T22:50:47  <luke-jr> (anyone else is fine too, but preferably not using libblkmaker code)
4912016-07-26T22:56:23  *** fengling has joined #bitcoin-core-dev
4922016-07-26T22:57:46  *** Guyver2 has quit IRC
4932016-07-26T23:01:06  *** fengling has quit IRC
4942016-07-26T23:03:33  *** netzin has quit IRC
4952016-07-26T23:06:48  *** aalex_ has joined #bitcoin-core-dev
4962016-07-26T23:08:15  *** aalex has quit IRC
4972016-07-26T23:10:10  <luke-jr> thanks
4982016-07-26T23:27:51  *** Giszmo has quit IRC
4992016-07-26T23:40:51  *** pmienk has quit IRC
5002016-07-26T23:52:36  *** pmienk has joined #bitcoin-core-dev