1 2016-07-26T00:01:08  *** pedrobranco has joined #bitcoin-core-dev
  2 2016-07-26T00:03:48  *** justanotheruser has quit IRC
  3 2016-07-26T00:03:57  *** justanot1eruser has joined #bitcoin-core-dev
  4 2016-07-26T00:05:16  <sipa> luke-jr: don't forget marker and flag byte
  5 2016-07-26T00:05:28  *** pedrobranco has quit IRC
  6 2016-07-26T00:06:14  *** fengling has joined #bitcoin-core-dev
  7 2016-07-26T00:11:06  *** fengling has quit IRC
  8 2016-07-26T00:20:29  <luke-jr> sipa: ah, right, so +36
  9 2016-07-26T00:35:48  *** Ylbam has quit IRC
 10 2016-07-26T00:47:37  *** justanot1eruser is now known as justanotheruser
 11 2016-07-26T01:00:00  *** ryan-c has joined #bitcoin-core-dev
 12 2016-07-26T01:07:44  *** fengling has joined #bitcoin-core-dev
 13 2016-07-26T01:12:26  *** fengling has quit IRC
 14 2016-07-26T01:13:11  *** fengling has joined #bitcoin-core-dev
 15 2016-07-26T01:17:08  *** frankenmint has quit IRC
 16 2016-07-26T02:40:04  *** TomMc has quit IRC
 17 2016-07-26T02:47:02  *** Chris_Stewart_5 has quit IRC
 18 2016-07-26T03:27:26  *** d_t has quit IRC
 19 2016-07-26T04:03:58  *** anu0 has joined #bitcoin-core-dev
 20 2016-07-26T04:07:36  *** anu1 has quit IRC
 21 2016-07-26T04:22:19  *** harrymm has quit IRC
 22 2016-07-26T04:26:16  *** harrymm has joined #bitcoin-core-dev
 23 2016-07-26T04:32:44  *** Arnavion has quit IRC
 24 2016-07-26T04:32:48  *** Arnavion3 has joined #bitcoin-core-dev
 25 2016-07-26T04:32:52  *** Arnavion3 is now known as Arnavion
 26 2016-07-26T04:50:25  *** d_t has joined #bitcoin-core-dev
 27 2016-07-26T04:54:52  *** d_t has quit IRC
 28 2016-07-26T05:07:32  *** Arnavion has quit IRC
 29 2016-07-26T05:07:36  *** Arnavion3 has joined #bitcoin-core-dev
 30 2016-07-26T05:07:40  *** Arnavion3 is now known as Arnavion
 31 2016-07-26T05:16:22  *** Arnavion has quit IRC
 32 2016-07-26T05:23:12  *** Arnavion has joined #bitcoin-core-dev
 33 2016-07-26T05:24:20  *** d_t has joined #bitcoin-core-dev
 34 2016-07-26T05:30:12  *** Alopex has joined #bitcoin-core-dev
 35 2016-07-26T05:33:04  *** go1111111 has quit IRC
 36 2016-07-26T05:46:39  *** go1111111 has joined #bitcoin-core-dev
 37 2016-07-26T06:02:50  *** molly has joined #bitcoin-core-dev
 38 2016-07-26T06:06:22  *** molz has quit IRC
 39 2016-07-26T06:06:54  *** netsinn has quit IRC
 40 2016-07-26T06:26:20  *** BashCo has quit IRC
 41 2016-07-26T06:48:43  *** BashCo has joined #bitcoin-core-dev
 42 2016-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
 43 2016-07-26T07:11:12  *** aalex has quit IRC
 44 2016-07-26T07:15:25  *** aalex has joined #bitcoin-core-dev
 45 2016-07-26T07:16:38  *** d_t has quit IRC
 46 2016-07-26T07:20:23  <jonasschnelli> wumpus: do you think we should have an optional "keep-seed" argument when encrypting the wallet in 0.13?
 47 2016-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)
 48 2016-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.
 49 2016-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.
 50 2016-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.
 51 2016-07-26T07:25:08  <jonasschnelli> We could add wallet initialization/creating to a (new) bitcoin-txish tool. "./bitcoin-wallet"
 52 2016-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.
 53 2016-07-26T07:25:26  <gmaxwell> yuck
 54 2016-07-26T07:25:26  <sipa> jonasschnelli: i would be fine with just a function to import or export a seed from the wallet
 55 2016-07-26T07:25:27  <jonasschnelli> People could do all sorts of things with it. Dump, enctypt, create, export/import seeds.
 56 2016-07-26T07:25:53  <jonasschnelli> sipa: there is a PR to exporting the xpriv (over dumpwallet)
 57 2016-07-26T07:25:58  <sipa> jonasschnelli: if you want to keep the seed when encrypting, export the seed before and import after
 58 2016-07-26T07:25:58  <jonasschnelli> import is not possible now.
 59 2016-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. :)
 60 2016-07-26T07:26:25  <jonasschnelli> Importing should be done together with a flexible keypath option.
 61 2016-07-26T07:26:36  *** Guyver2 has joined #bitcoin-core-dev
 62 2016-07-26T07:27:03  <sipa> that makes sense
 63 2016-07-26T07:27:43  <jonasschnelli> I guess users will would complain otherwise if you only can "import" seeds with m/0'/0'
 64 2016-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.
 65 2016-07-26T07:28:47  <gmaxwell> There is a lot of complexity required to property handle multiple derrivation schemes within a wallet.
 66 2016-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
 67 2016-07-26T07:29:26  <jonasschnelli> Wait... last three: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0
 68 2016-07-26T07:29:44  <gmaxwell> also unclear import with an explicit path would interact with implied chains (e.g. for chains)
 69 2016-07-26T07:30:19  <jonasschnelli> Yes. The whole importing situation is not yet clear to me....
 70 2016-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.
 71 2016-07-26T07:30:37  <jonasschnelli> People might expect a lookup of the 0-n after importing a seed, etc.
 72 2016-07-26T07:30:51  <sipa> by import i guess i just meant "override deterministic keypath"
 73 2016-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
 74 2016-07-26T07:31:17  <jonasschnelli> sipa: yes.
 75 2016-07-26T07:31:30  <gmaxwell> jonasschnelli: except that won't actually work reliably, and it would hobble security and functionality.
 76 2016-07-26T07:33:09  <jonasschnelli> gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
 77 2016-07-26T07:39:06  *** kadoban has quit IRC
 78 2016-07-26T07:40:58  *** aalex has quit IRC
 79 2016-07-26T07:45:24  *** aalex has joined #bitcoin-core-dev
 80 2016-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
 81 2016-07-26T07:49:20  <wumpus> that wallets are 'born' unencrypted and later encrypted keeps causing difficulties
 82 2016-07-26T07:49:48  <wumpus> though I also don't like the idea of forcing people to set a passphrase on first use
 83 2016-07-26T07:56:52  <warren> Don't force them upon starting Core, only if they want receive addresses?
 84 2016-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
 85 2016-07-26T07:57:46  <wumpus> warren: yes, that's an option
 86 2016-07-26T07:58:37  <gmaxwell> setting the passphrase prematurely is a sure path to funds loss.
 87 2016-07-26T07:58:49  <wumpus> right
 88 2016-07-26T07:59:03  <warren> Make them type the passphrase if they want a receive address?
 89 2016-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?"
 90 2016-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.
 91 2016-07-26T08:00:05  <sipa> what does electrum do?
 92 2016-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
 93 2016-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.
 94 2016-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.
 95 2016-07-26T08:01:29  <gmaxwell> It also doesn't have hours/days lag between install and usability. :)
 96 2016-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
 97 2016-07-26T08:01:59  <sipa> gmaxwell: also... our wallet model is really that you should not lose your wallet.dat
 98 2016-07-26T08:02:07  <wumpus> gmaxwell: there have been plenty of ideas of discouraging creating receive addresses at all before syncing up?
 99 2016-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!
100 2016-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
101 2016-07-26T08:02:50  *** AaronvanW has quit IRC
102 2016-07-26T08:03:01  <sipa> sure, with deterministic seeds there is a way to recover your funds from catastrophic lost
103 2016-07-26T08:03:07  <sipa> but not the rest...
104 2016-07-26T08:03:12  <wumpus> gmaxwell: I'm not saying it should be impossible ofc
105 2016-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.
106 2016-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.
107 2016-07-26T08:04:06  <wumpus> wallet.dat encryption helps against exploit that allow grabbing a named file from the file system, but not more
108 2016-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.
109 2016-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
110 2016-07-26T08:05:23  <gmaxwell> but for that sort of thing a passphrase such as "goat" is perfectly fine. :P
111 2016-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?
112 2016-07-26T08:05:54  <sipa> i'm sure more funds have been lost from forgotten passphrases than from theft
113 2016-07-26T08:06:09  <sipa> wumpus: hell no
114 2016-07-26T08:06:14  <gmaxwell> wumpus: yea, not going to remove it. (I say with some regret.)
115 2016-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)
116 2016-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.
117 2016-07-26T08:07:04  <gmaxwell> wumpus: same malware also has keylogging hooks.
118 2016-07-26T08:07:18  <wumpus> gmaxwell: that's not an argument against theft happening
119 2016-07-26T08:07:27  <wumpus> gmaxwell: just that the current security may not be good enough
120 2016-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.
121 2016-07-26T08:08:09  <gmaxwell> forgotten vs protected from theft by encryption.
122 2016-07-26T08:08:24  <wumpus> hw wallets would be preferable, and I think we need to support those in the future
123 2016-07-26T08:08:29  <gmaxwell> I do know of cases protected from theft by encryption, but few.
124 2016-07-26T08:08:38  <gmaxwell> wumpus: yes.
125 2016-07-26T08:08:57  <wumpus> but repeating this discussion for/against wallet encrption every few months is not going to help :)
126 2016-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.
127 2016-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
128 2016-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.
129 2016-07-26T08:11:17  <gmaxwell> can't spell tonight.
130 2016-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.
131 2016-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
132 2016-07-26T08:14:25  <wumpus> and I don't think a goal should be to encourage people to use the encryption
133 2016-07-26T08:14:34  <wumpus> but if they want to use it, they should be able to
134 2016-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.
135 2016-07-26T08:14:55  <wumpus> and then it should also be as secure *as possible given the constraints of local usage tc*
136 2016-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.
137 2016-07-26T08:17:17  <wumpus> indeed, an unencrypted backup makes sense combined with physical security
138 2016-07-26T08:17:31  <sipa> then again we don't even have a user-friendly way to recover from a backup...
139 2016-07-26T08:17:33  <wumpus> if only they don't put it in the cloud :(
140 2016-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.
141 2016-07-26T08:18:31  *** AaronvanW has joined #bitcoin-core-dev
142 2016-07-26T08:18:31  *** AaronvanW has quit IRC
143 2016-07-26T08:18:31  *** AaronvanW has joined #bitcoin-core-dev
144 2016-07-26T08:18:47  <wumpus> gmaxwell: yes that is good
145 2016-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
146 2016-07-26T08:19:36  <wumpus> which wouldn't be rocket science*
147 2016-07-26T08:20:03  *** Guyver2 has quit IRC
148 2016-07-26T08:20:46  <wumpus> I mean there is a 'backup wallet' menu option, could add an 'import wallet' option too
149 2016-07-26T08:20:54  <wumpus> although it would work better with multi-wallet support I guess
150 2016-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.
151 2016-07-26T08:21:17  *** Ylbam has joined #bitcoin-core-dev
152 2016-07-26T08:21:21  <gmaxwell> Restore is mostly a disaster until something is done about rescan.
153 2016-07-26T08:21:31  <btcdrak> greenaddress has encrypted seeds so you put in a passohrase and it gives you an encrypted seed
154 2016-07-26T08:21:38  <wumpus> why? it doesn't matter if restore takes a while, it will be an infrequent operation
155 2016-07-26T08:21:46  <btcdrak> that is part of the initialisation process.
156 2016-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
157 2016-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.
158 2016-07-26T08:22:33  <wumpus> gmaxwell: that long? oh last time I did it it was much faster
159 2016-07-26T08:22:39  <wumpus> yes, >8 hours is bad
160 2016-07-26T08:22:46  <btcdrak> rescan? ouch
161 2016-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.
162 2016-07-26T08:23:01  <btcdrak> good case for keeping an addrindex
163 2016-07-26T08:23:01  <wumpus> that's longer than a reindex takes in good circumstances
164 2016-07-26T08:23:06  * btcdrak ducks
165 2016-07-26T08:23:41  <wumpus> why is a rescan so slow? it's a fairly simple scan over data right?
166 2016-07-26T08:23:51  <gmaxwell> deseralizes every block and every transaction.
167 2016-07-26T08:24:17  <wumpus> so deserialization-bound? ok
168 2016-07-26T08:24:20  <gmaxwell> and then is constantly opening and closing the wallet database.
169 2016-07-26T08:24:40  <gmaxwell> I believe that one of phantomcircuit's wallet fixes (maybe in the pipeline) fixed the latter part.
170 2016-07-26T08:24:44  <wumpus> I guess there's room for optimization there, it wouldn't need to deserialize everything
171 2016-07-26T08:25:25  <wumpus> many operations could be done in-place on the data
172 2016-07-26T08:25:50  <gmaxwell> or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
173 2016-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.
174 2016-07-26T08:26:34  <wumpus> anyhow: why would importing a wallet.at require a rescan?
175 2016-07-26T08:26:51  <wumpus> it's no different from replacing your wallet.dat with a different one and restarting the client
176 2016-07-26T08:27:09  <gmaxwell> it always requires _some_ rescanning; assuming it was offline more than one blocktime :P
177 2016-07-26T08:27:16  <gmaxwell> but presumably a backup is old.
178 2016-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
179 2016-07-26T08:27:44  <gmaxwell> well the first 300k blocks rescan in pretty much no time. :P
180 2016-07-26T08:27:49  <wumpus> partial rescans are pretty fast at least in my experience
181 2016-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
182 2016-07-26T08:28:23  <wumpus> optimizing rescan would be awesome still
183 2016-07-26T08:28:52  <gmaxwell> I have data on the partial rescan.
184 2016-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
185 2016-07-26T08:30:05  <gmaxwell> 2016-07-25 06:57:24 Rescanning last 5556 blocks (from block 416625)...
186 2016-07-26T08:30:09  <gmaxwell> 2016-07-25 07:02:23  rescan               298400ms
187 2016-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
188 2016-07-26T08:30:23  <gmaxwell> that was a backup restore I did a day ago.
189 2016-07-26T08:30:37  <sipa> gmaxwell: many matching transactiond in that range?
190 2016-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
191 2016-07-26T08:30:53  <gmaxwell> sipa: none.
192 2016-07-26T08:31:00  <sipa> gmaxwell: ugh
193 2016-07-26T08:31:28  <sipa> well, 1 second per week
194 2016-07-26T08:31:35  <wumpus> oh so you want to implement wallet importing? we first need to improve rescan performance. Oh never mind then...
195 2016-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.
196 2016-07-26T08:32:22  <wumpus> gmaxwell: yes, that's a very bad data point.
197 2016-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.
198 2016-07-26T08:34:22  <wumpus> talking about rescanning, did anyone ever notice this issue: https://github.com/bitcoin/bitcoin/issues/8116
199 2016-07-26T08:34:35  <wumpus> the rescan suddenly started over
200 2016-07-26T08:34:47  <wumpus> I'm sure it can be really slow if it's done multiple times :p
201 2016-07-26T08:37:07  <gmaxwell> freaky, I don't think I've seen it do that before.
202 2016-07-26T08:37:35  <gmaxwell> oh I see you imported while it was already rescanning, and so it started over?
203 2016-07-26T08:37:57  <gmaxwell> oh no your import is what triggered the rescan and the new block restarted it.
204 2016-07-26T08:37:59  <wumpus> no, that's not even possible
205 2016-07-26T08:38:06  <wumpus> if it's rescanning everything is blocked
206 2016-07-26T08:38:16  <wumpus> yes, that seems to be the case
207 2016-07-26T08:38:43  <gmaxwell> weird. pretty sure I've seen it connect blocks while rescannign and not start over.
208 2016-07-26T08:41:48  <wumpus> maybe it was just a fluke. But it could explain some very slow rescans
209 2016-07-26T08:42:28  <gmaxwell> not the ones I've been expirencing at least.
210 2016-07-26T08:42:35  <wumpus> the end result was correct so I didn't make a big issue out of it
211 2016-07-26T08:42:38  <gmaxwell> but some of the complaints for sure.
212 2016-07-26T08:43:22  *** jtimon has joined #bitcoin-core-dev
213 2016-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.
214 2016-07-26T08:46:26  <gmaxwell> da2ce7_mobile: what you're asking there could describe several different actual usecases which have different supporting development requirements.
215 2016-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.
216 2016-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)
217 2016-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.
218 2016-07-26T08:49:08  <da2ce7_mobile> You could import these seeds into your Bitcoin Core to act as hot-wallets.
219 2016-07-26T08:50:04  <gmaxwell> you mean extended public keys there.
220 2016-07-26T08:50:14  <gmaxwell> IIRC trezor has absolutely no private key export.
221 2016-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.
222 2016-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.
223 2016-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.
224 2016-07-26T08:51:45  <da2ce7_mobile> yeah. It would be great if BIP44 had a 'hardened only' option.
225 2016-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.
226 2016-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.
227 2016-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.
228 2016-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.
229 2016-07-26T08:56:15  <da2ce7_mobile> it is userfull for 'watch only'
230 2016-07-26T08:56:29  <da2ce7_mobile> but most people don't use watch only accounts.
231 2016-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.
232 2016-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.
233 2016-07-26T08:57:57  <jonasschnelli> da2ce7_mobile: indeed
234 2016-07-26T08:58:12  <gmaxwell> da2ce7_mobile: indeed. Public derrivation causes a lot of trouble for a very narrow improvement.
235 2016-07-26T08:58:33  <gmaxwell> it's useful, but the utility is often overhyped.
236 2016-07-26T08:58:52  <sipa> ... says the man who invented iy
237 2016-07-26T08:58:55  <sipa> :)
238 2016-07-26T08:58:59  <sipa> *iy
239 2016-07-26T08:59:02  <sipa> **it
240 2016-07-26T08:59:20  <jonasschnelli> hehe
241 2016-07-26T08:59:42  <jonasschnelli> I think there are serval usecases for pubkd... but not for the novice wallet user
242 2016-07-26T08:59:58  <gmaxwell> sipa: yup.
243 2016-07-26T09:00:21  <jonasschnelli> So... I'm kinda no longer sure if we even want to allow flexible keypath... with or without pubckd
244 2016-07-26T09:00:54  <jonasschnelli> We should probably work more towards supporting cold storages with something like "importmulti"
245 2016-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
246 2016-07-26T09:01:48  <gmaxwell> on addresses is also undesirable. :P
247 2016-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.
248 2016-07-26T09:02:38  <gmaxwell> Some things like multisig might imply things about derrivation paths, and thats fine.
249 2016-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.
250 2016-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)
251 2016-07-26T09:04:08  <jonasschnelli> rawtx is possible because fundrawtx has a custom change address in 0.13.
252 2016-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"
253 2016-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.
254 2016-07-26T09:05:16  <jonasschnelli> gmaxwell: I though it would be most simple if it would be TCP/HTTP
255 2016-07-26T09:05:33  <jonasschnelli> A json call goes out to a configurable URL, a response might come back.
256 2016-07-26T09:05:58  <jonasschnelli> Would also possible allow to sign on a cold storage attached to a different computer in your LAN
257 2016-07-26T09:05:59  <gmaxwell> Then you get CSRF from js running on the users machine...
258 2016-07-26T09:06:12  <jonasschnelli> You can avoid that...
259 2016-07-26T09:06:15  <gmaxwell> different computer; now the communication needs to be cryptographically protected.
260 2016-07-26T09:06:27  <gmaxwell> Sure you can but you just said, most simple.
261 2016-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.
262 2016-07-26T09:06:43  <gmaxwell> Having to avoid CSRF and provide link layer encryption is not simple.
263 2016-07-26T09:06:50  <jonasschnelli> Launching a process... yes. Why not...
264 2016-07-26T09:06:55  *** harding has joined #bitcoin-core-dev
265 2016-07-26T09:06:59  <jonasschnelli> It would also eliminate the need for a background daemon
266 2016-07-26T09:07:22  <jonasschnelli> Can you check if a certain process (application at path) is already running?
267 2016-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.
268 2016-07-26T09:07:37  <jonasschnelli> Or how would you prevent from spinning off to many processes?
269 2016-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.
270 2016-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...
271 2016-07-26T09:11:09  <gmaxwell> By blocking I just meant bitcoin core wouldn't open multiple processes.
272 2016-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.
273 2016-07-26T09:11:25  <gmaxwell> Not the actual mechenism for talking to the file descriptors.
274 2016-07-26T09:12:13  *** jannes has joined #bitcoin-core-dev
275 2016-07-26T09:12:36  <jonasschnelli> You could also retrive pubkeys over that process by sending different commands over stdio
276 2016-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.
277 2016-07-26T09:27:57  <GitHub176> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/517eee3e8f8b...618c9dd8c651
278 2016-07-26T09:27:57  <GitHub176> bitcoin/master ab942c1 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
279 2016-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...
280 2016-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
281 2016-07-26T09:33:47  *** spudowiar has quit IRC
282 2016-07-26T09:36:54  <sipa> anyone have any intuition about what hashrate you could get out of a raspberry pie?
283 2016-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...
284 2016-07-26T09:37:48  <sipa> but that requires its hashrate to be at most 1.2 Mhash/s
285 2016-07-26T09:40:52  *** pedrobranco has joined #bitcoin-core-dev
286 2016-07-26T09:42:53  <jonasschnelli> install CGMiner...
287 2016-07-26T09:45:07  <gmaxwell> jonasschnelli: has no cpu mining.
288 2016-07-26T09:45:26  <gmaxwell> sipa: openssl has a nice benchmark.
289 2016-07-26T09:45:47  <jonasschnelli> Oh. I'm not familiar with mining, maybe install cpuminer..
290 2016-07-26T09:45:54  <kinlo> sipa: raspberry pi will not get 1.2 Mhash/s
291 2016-07-26T09:46:01  <kinlo> it's not that powerfull
292 2016-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).
293 2016-07-26T09:47:07  * gmaxwell goes to find the old bitcoin wiki page.
294 2016-07-26T09:49:52  <gmaxwell> https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#ARM
295 2016-07-26T09:50:29  <sipa> ok, http://qr.ae/1x0nad
296 2016-07-26T09:50:32  <gmaxwell> funny how much slower original rpi is compared to sensible arm computers.
297 2016-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.
298 2016-07-26T09:51:38  <gmaxwell> "more energy than a whole country" is ... laughable
299 2016-07-26T09:52:37  *** Ginnarr has joined #bitcoin-core-dev
300 2016-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?
301 2016-07-26T09:54:34  <gmaxwell> sipa: nice answer. :P
302 2016-07-26T09:56:02  *** G1lius has joined #bitcoin-core-dev
303 2016-07-26T09:56:32  *** spudowiar has joined #bitcoin-core-dev
304 2016-07-26T10:04:48  *** devrandom has quit IRC
305 2016-07-26T10:08:26  *** [Author] has quit IRC
306 2016-07-26T10:10:31  *** Giszmo has joined #bitcoin-core-dev
307 2016-07-26T10:16:04  *** spudowiar has quit IRC
308 2016-07-26T10:23:59  *** [Author] has joined #bitcoin-core-dev
309 2016-07-26T10:24:58  *** crudel has quit IRC
310 2016-07-26T10:27:04  *** jtimon has quit IRC
311 2016-07-26T10:29:35  *** spudowiar has joined #bitcoin-core-dev
312 2016-07-26T10:34:56  *** afk11 has joined #bitcoin-core-dev
313 2016-07-26T10:34:56  *** afk11 has quit IRC
314 2016-07-26T10:34:56  *** afk11 has joined #bitcoin-core-dev
315 2016-07-26T10:40:30  *** pedrobranco has quit IRC
316 2016-07-26T10:47:58  *** crudel has joined #bitcoin-core-dev
317 2016-07-26T11:35:46  *** fengling has quit IRC
318 2016-07-26T11:36:35  *** Ginnarr has quit IRC
319 2016-07-26T11:57:46  *** jtimon has joined #bitcoin-core-dev
320 2016-07-26T12:03:56  *** anu1 has joined #bitcoin-core-dev
321 2016-07-26T12:07:13  *** anu0 has quit IRC
322 2016-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
323 2016-07-26T12:08:36  *** afk11 has quit IRC
324 2016-07-26T12:24:39  <GitHub29> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/618c9dd8c651...4b1a4d8810f9
325 2016-07-26T12:24:40  <GitHub29> bitcoin/master 1ffaff2 Johnson Lau: Make witness v0 outputs non-standard before segwit activation
326 2016-07-26T12:24:40  <GitHub29> bitcoin/master c59c434 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs
327 2016-07-26T12:24:41  <GitHub29> bitcoin/master 4b1a4d8 Wladimir J. van der Laan: Merge #8381: Make witness v0 outputs non-standard...
328 2016-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
329 2016-07-26T12:26:02  *** laurentmt has joined #bitcoin-core-dev
330 2016-07-26T12:26:04  *** laurentmt has quit IRC
331 2016-07-26T12:26:14  <GitHub164> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/86edc20a178c...4f7f531af6e1
332 2016-07-26T12:26:14  <GitHub164> bitcoin/0.13 f84ee3d Johnson Lau: Make witness v0 outputs non-standard before segwit activation...
333 2016-07-26T12:26:15  <GitHub164> bitcoin/0.13 4f7f531 Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs...
334 2016-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
335 2016-07-26T12:32:17  *** fengling has joined #bitcoin-core-dev
336 2016-07-26T12:40:42  <GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4b1a4d8810f9...beadffae6d65
337 2016-07-26T12:40:42  <GitHub30> bitcoin/master faa5931 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)
338 2016-07-26T12:40:43  <GitHub30> bitcoin/master beadffa Wladimir J. van der Laan: Merge #8358: [doc] gbuild: Set memory explicitly (default is too low)...
339 2016-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
340 2016-07-26T12:41:32  <GitHub192> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/cfd1280f23bf687a38d3d00355ac94a3646cb59f
341 2016-07-26T12:41:32  <GitHub192> bitcoin/0.13 cfd1280 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)...
342 2016-07-26T12:45:45  *** spudowiar has quit IRC
343 2016-07-26T12:46:01  *** spudowiar has joined #bitcoin-core-dev
344 2016-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
345 2016-07-26T12:47:06  *** fengling has quit IRC
346 2016-07-26T12:54:32  <sdaftuar> sipa: BlueMatt: i'm not sure i followed your discussion of the sendcmpct semantics
347 2016-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?
348 2016-07-26T12:56:07  <sdaftuar> also, how do you know what version the compactblock announcements that you receive are generated with?
349 2016-07-26T13:00:33  *** crudel has quit IRC
350 2016-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
351 2016-07-26T13:02:29  <sdaftuar> sipa: ah okay, so we are looking at responses then. that makes sense to me.
352 2016-07-26T13:04:20  *** laurentmt has joined #bitcoin-core-dev
353 2016-07-26T13:04:38  *** laurentmt has quit IRC
354 2016-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)
355 2016-07-26T13:05:41  <sipa> but it's probably easier to just say that the last understood sendcmpct is what countd?
356 2016-07-26T13:06:15  <sdaftuar> last one with an understood version number?  yes, i think that.
357 2016-07-26T13:07:25  <sdaftuar> i guess changing version numbers should only really happen during initial handshake, otherwise we get race conditions
358 2016-07-26T13:07:26  <sipa> so that means you'd send v1 and then v2 initially, without announce bit
359 2016-07-26T13:09:37  <sipa> if the peer never sends you a v2, you never ask for announce and never ask for cmpctblock
360 2016-07-26T13:10:00  <sipa> i don't think there is any race
361 2016-07-26T13:10:18  <sdaftuar> i mean, you shoulnd'
362 2016-07-26T13:10:24  <sdaftuar> you shouldn't later try to negotiate up to v2
363 2016-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
364 2016-07-26T13:11:19  <sdaftuar> then it would be unclear how the announcement is encoded
365 2016-07-26T13:11:39  <sdaftuar> as i wouldn't know whether my message to you was received before that point, or not.
366 2016-07-26T13:12:01  <sdaftuar> (if we previously negotiated to v1)
367 2016-07-26T13:13:13  <sipa> right, there is a possible race
368 2016-07-26T13:28:57  *** crudel has joined #bitcoin-core-dev
369 2016-07-26T13:36:14  *** spudowiar has quit IRC
370 2016-07-26T13:36:35  *** spudowiar has joined #bitcoin-core-dev
371 2016-07-26T13:37:55  *** cryptapus has joined #bitcoin-core-dev
372 2016-07-26T13:37:55  *** cryptapus has joined #bitcoin-core-dev
373 2016-07-26T13:43:56  *** fengling has joined #bitcoin-core-dev
374 2016-07-26T13:48:46  *** fengling has quit IRC
375 2016-07-26T13:55:05  <AaronvanW> https://twitter.com/spair/status/757908557949984769
376 2016-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
377 2016-07-26T13:55:31  <jonasschnelli> AaronvanW. :)
378 2016-07-26T13:56:25  <jonasschnelli> "[...] sticking to their guns [...]" I think this is the US version for "being loyal"?
379 2016-07-26T13:58:58  <AaronvanW> more like, not being intimidated or persuaded to do the wrong thing. doing what you believe is right.
380 2016-07-26T13:59:05  <AaronvanW> (though I'm also no US native)
381 2016-07-26T14:00:37  *** laurentmt has joined #bitcoin-core-dev
382 2016-07-26T14:19:02  <kanzure> AaronvanW: wrong channel i think
383 2016-07-26T14:29:34  <AaronvanW> o
384 2016-07-26T14:29:35  <AaronvanW> k
385 2016-07-26T14:45:31  *** fengling has joined #bitcoin-core-dev
386 2016-07-26T14:45:38  *** cryptapus_ has joined #bitcoin-core-dev
387 2016-07-26T14:47:25  *** frankenmint has joined #bitcoin-core-dev
388 2016-07-26T14:48:34  *** cryptapus has quit IRC
389 2016-07-26T14:50:26  *** fengling has quit IRC
390 2016-07-26T15:25:51  *** YOU-JI has joined #bitcoin-core-dev
391 2016-07-26T15:46:10  *** frankenmint has quit IRC
392 2016-07-26T15:47:31  *** fengling has joined #bitcoin-core-dev
393 2016-07-26T15:50:25  *** netsinn has joined #bitcoin-core-dev
394 2016-07-26T15:51:46  *** fengling has quit IRC
395 2016-07-26T15:51:57  *** netsinn is now known as netsin_
396 2016-07-26T16:09:54  *** frankenmint has joined #bitcoin-core-dev
397 2016-07-26T16:17:48  *** cryptapus_ has quit IRC
398 2016-07-26T16:17:58  *** cryptapus_ has joined #bitcoin-core-dev
399 2016-07-26T16:18:10  *** cryptapus_ is now known as cryptapus
400 2016-07-26T16:24:54  *** netsin_ has quit IRC
401 2016-07-26T16:39:56  *** YOU-JI has quit IRC
402 2016-07-26T16:48:33  *** fengling has joined #bitcoin-core-dev
403 2016-07-26T16:53:26  *** fengling has quit IRC
404 2016-07-26T16:55:50  *** kadoban has joined #bitcoin-core-dev
405 2016-07-26T17:01:48  <jtimon> ping #8348 #8346 and #8391
406 2016-07-26T17:05:43  *** netzin has joined #bitcoin-core-dev
407 2016-07-26T17:48:15  *** arubi has quit IRC
408 2016-07-26T17:50:01  *** arubi has joined #bitcoin-core-dev
409 2016-07-26T17:50:02  *** fengling has joined #bitcoin-core-dev
410 2016-07-26T17:54:26  *** fengling has quit IRC
411 2016-07-26T17:56:05  *** frankenmint has quit IRC
412 2016-07-26T17:58:48  *** netzin has joined #bitcoin-core-dev
413 2016-07-26T18:06:03  *** netzin has quit IRC
414 2016-07-26T18:06:47  *** spudowiar has quit IRC
415 2016-07-26T18:29:24  *** Guyver2 has joined #bitcoin-core-dev
416 2016-07-26T18:50:44  *** fengling has joined #bitcoin-core-dev
417 2016-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
418 2016-07-26T18:53:04  <luke-jr> for 22 minutes now
419 2016-07-26T18:53:14  <luke-jr> sorry, 1 hour 22 minutes..
420 2016-07-26T18:53:41  <luke-jr> getpeerinfo shows no blocks inflight from anyone
421 2016-07-26T18:53:52  <luke-jr> two peers are 0.12.1
422 2016-07-26T18:53:57  <luke-jr> sipa: ^ any ideas?
423 2016-07-26T18:55:26  *** fengling has quit IRC
424 2016-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
425 2016-07-26T19:03:20  <luke-jr> sdaftuar: are not 0.12.1 all NODE_WITNESS? O.o
426 2016-07-26T19:03:34  <sdaftuar> uh, no released code is NODE_WITNESS
427 2016-07-26T19:03:35  <luke-jr> got something I can addnode?
428 2016-07-26T19:04:03  <luke-jr> right, I'm confusing segwit with csv now. :|
429 2016-07-26T19:04:16  *** frankenmint has joined #bitcoin-core-dev
430 2016-07-26T19:04:25  <instagibbs> there are reports that syncing on testnet is near impossible with master/0.13
431 2016-07-26T19:04:40  <sdaftuar> this might work: x9.testnet-seed.bitcoin.jonasschnelli.ch
432 2016-07-26T19:05:02  <sdaftuar> or you could restart with -forcednsseed maybe
433 2016-07-26T19:08:21  <luke-jr> -forcednsseed seems to have worked, although I restarted in the process :x
434 2016-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
435 2016-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
436 2016-07-26T19:11:15  <sdaftuar> which, i think, improved the bookkeeping on peer services
437 2016-07-26T19:16:25  *** jtimon has quit IRC
438 2016-07-26T19:23:01  *** netzin has joined #bitcoin-core-dev
439 2016-07-26T19:24:00  *** netsin_ has joined #bitcoin-core-dev
440 2016-07-26T19:34:23  *** BashCo has quit IRC
441 2016-07-26T19:34:49  *** KwukDuck has quit IRC
442 2016-07-26T19:52:10  *** fengling has joined #bitcoin-core-dev
443 2016-07-26T19:53:42  *** BashCo has joined #bitcoin-core-dev
444 2016-07-26T19:57:06  *** fengling has quit IRC
445 2016-07-26T19:58:46  *** jtimon has joined #bitcoin-core-dev
446 2016-07-26T20:06:21  *** anu1 has quit IRC
447 2016-07-26T20:08:25  *** cryptapus has quit IRC
448 2016-07-26T20:28:29  *** frankenmint has quit IRC
449 2016-07-26T20:38:43  *** belcher has joined #bitcoin-core-dev
450 2016-07-26T20:46:17  <luke-jr> is testnet really at 3.125 BTC subsidy? O.o
451 2016-07-26T20:53:45  *** fengling has joined #bitcoin-core-dev
452 2016-07-26T20:58:26  *** fengling has quit IRC
453 2016-07-26T20:59:53  <Lightsword> yep
454 2016-07-26T21:03:30  *** zooko has joined #bitcoin-core-dev
455 2016-07-26T21:04:38  *** netsin_ has quit IRC
456 2016-07-26T21:04:57  *** netsin_ has joined #bitcoin-core-dev
457 2016-07-26T21:05:18  *** cryptapus_afk is now known as cryptapus
458 2016-07-26T21:05:37  *** netzin has joined #bitcoin-core-dev
459 2016-07-26T21:10:23  <luke-jr> anyone who can easily send a bunch of segwit txs on testnet? :x
460 2016-07-26T21:15:06  *** ad0r has joined #bitcoin-core-dev
461 2016-07-26T21:15:33  *** ad0r is now known as cdecker
462 2016-07-26T21:18:09  *** spudowiar has joined #bitcoin-core-dev
463 2016-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
464 2016-07-26T21:25:04  <arubi> luke-jr, I made a few,  I don't have many funds
465 2016-07-26T21:25:47  <luke-jr> arubi: hm, seems to have not relayed to me; can you pastebin them raw?
466 2016-07-26T21:26:41  <arubi> hmm let's see.  might have easier time if I set it to output raw hex this time
467 2016-07-26T21:27:29  <arubi> oh oops it was set to segnet :)  moment
468 2016-07-26T21:27:35  <luke-jr> XD
469 2016-07-26T21:28:25  <arubi> making some more txes
470 2016-07-26T21:28:58  *** cryptapus is now known as cryptapus_afk
471 2016-07-26T21:30:30  <luke-jr> arubi: if you have a limited #, hold off a bit, I have a crash to debug XD
472 2016-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/
473 2016-07-26T21:32:38  *** spudowiar has quit IRC
474 2016-07-26T21:33:19  <arubi> and txs themselves http://paste.debian.net/hidden/283a36ab/
475 2016-07-26T21:33:38  <arubi> heh, should've uniq, but you get what it means :)
476 2016-07-26T21:35:39  *** spudowiar has joined #bitcoin-core-dev
477 2016-07-26T21:40:15  *** spudowiar has quit IRC
478 2016-07-26T21:54:48  *** fengling has joined #bitcoin-core-dev
479 2016-07-26T21:59:46  *** fengling has quit IRC
480 2016-07-26T22:10:03  <luke-jr> crap, someone mined the witness stuff
481 2016-07-26T22:10:39  <luke-jr> anyone else? XD
482 2016-07-26T22:24:14  <luke-jr> yay for invalidateblock <.<
483 2016-07-26T22:37:37  <luke-jr> someone screwing with me by sending bitcoins to random mining addresses? <.<
484 2016-07-26T22:37:46  <luke-jr> [testnet]
485 2016-07-26T22:47:33  *** zooko has quit IRC
486 2016-07-26T22:50:06  <luke-jr> Lightsword: can you mine a testnet block on top of mine? :p
487 2016-07-26T22:50:16  <luke-jr> 000000000296ba9a3ef21c0978962203ee8b75a2e0b0a5a8ec57517ebb6b8e07
488 2016-07-26T22:50:24  <luke-jr> (should be current best block)
489 2016-07-26T22:50:44  *** cdecker has quit IRC
490 2016-07-26T22:50:47  <luke-jr> (anyone else is fine too, but preferably not using libblkmaker code)
491 2016-07-26T22:56:23  *** fengling has joined #bitcoin-core-dev
492 2016-07-26T22:57:46  *** Guyver2 has quit IRC
493 2016-07-26T23:01:06  *** fengling has quit IRC
494 2016-07-26T23:03:33  *** netzin has quit IRC
495 2016-07-26T23:06:48  *** aalex_ has joined #bitcoin-core-dev
496 2016-07-26T23:08:15  *** aalex has quit IRC
497 2016-07-26T23:10:10  <luke-jr> thanks
498 2016-07-26T23:27:51  *** Giszmo has quit IRC
499 2016-07-26T23:40:51  *** pmienk has quit IRC
500 2016-07-26T23:52:36  *** pmienk has joined #bitcoin-core-dev