1 2016-07-26 00:05:17	0|sipa|luke-jr: don't forget marker and flag byte
  2 2016-07-26 00:20:29	0|luke-jr|sipa: ah, right, so +36
  3 2016-07-26 06:58:54	0|jonasschnelli|I'm impressed. A guy implemented bip151 in JS: https://github.com/bcoin-org/bcoin/blob/4af5273c0eb0f5fb5c9cfe68e4fe13afb005e410/lib/bcoin/bip151.js
  4 2016-07-26 07:20:23	0|jonasschnelli|wumpus: do you think we should have an optional "keep-seed" argument when encrypting the wallet in 0.13?
  5 2016-07-26 07:20:50	0|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)
  6 2016-07-26 07:22:46	0|gmaxwell|keeping around a key that has been stored unencrypted on many systems is no better than not using encryption at all.
  7 2016-07-26 07:23:13	0|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.
  8 2016-07-26 07:24:21	0|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.
  9 2016-07-26 07:25:08	0|jonasschnelli|We could add wallet initialization/creating to a (new) bitcoin-txish tool. "./bitcoin-wallet"
 10 2016-07-26 07:25:20	0|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.
 11 2016-07-26 07:25:26	0|gmaxwell|yuck
 12 2016-07-26 07:25:27	0|sipa|jonasschnelli: i would be fine with just a function to import or export a seed from the wallet
 13 2016-07-26 07:25:28	0|jonasschnelli|People could do all sorts of things with it. Dump, enctypt, create, export/import seeds.
 14 2016-07-26 07:25:53	0|jonasschnelli|sipa: there is a PR to exporting the xpriv (over dumpwallet)
 15 2016-07-26 07:25:58	0|jonasschnelli|import is not possible now.
 16 2016-07-26 07:25:58	0|sipa|jonasschnelli: if you want to keep the seed when encrypting, export the seed before and import after
 17 2016-07-26 07:26:06	0|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. :)
 18 2016-07-26 07:26:25	0|jonasschnelli|Importing should be done together with a flexible keypath option.
 19 2016-07-26 07:27:04	0|sipa|that makes sense
 20 2016-07-26 07:27:43	0|jonasschnelli|I guess users will would complain otherwise if you only can "import" seeds with m/0'/0'
 21 2016-07-26 07:27:51	0|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.
 22 2016-07-26 07:28:47	0|gmaxwell|There is a lot of complexity required to property handle multiple derrivation schemes within a wallet.
 23 2016-07-26 07:29:16	0|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
 24 2016-07-26 07:29:27	0|jonasschnelli|Wait... last three: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0
 25 2016-07-26 07:29:44	0|gmaxwell|also unclear import with an explicit path would interact with implied chains (e.g. for chains)
 26 2016-07-26 07:30:20	0|jonasschnelli|Yes. The whole importing situation is not yet clear to me....
 27 2016-07-26 07:30:27	0|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.
 28 2016-07-26 07:30:37	0|jonasschnelli|People might expect a lookup of the 0-n after importing a seed, etc.
 29 2016-07-26 07:30:52	0|sipa|by import i guess i just meant "override deterministic keypath"
 30 2016-07-26 07:31:09	0|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
 31 2016-07-26 07:31:17	0|jonasschnelli|sipa: yes.
 32 2016-07-26 07:31:30	0|gmaxwell|jonasschnelli: except that won't actually work reliably, and it would hobble security and functionality.
 33 2016-07-26 07:33:09	0|jonasschnelli|gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
 34 2016-07-26 07:48:59	0|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
 35 2016-07-26 07:49:20	0|wumpus|that wallets are 'born' unencrypted and later encrypted keeps causing difficulties
 36 2016-07-26 07:49:48	0|wumpus|though I also don't like the idea of forcing people to set a passphrase on first use
 37 2016-07-26 07:56:52	0|warren|Don't force them upon starting Core, only if they want receive addresses?
 38 2016-07-26 07:57:29	0|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
 39 2016-07-26 07:57:47	0|wumpus|warren: yes, that's an option
 40 2016-07-26 07:58:37	0|gmaxwell|setting the passphrase prematurely is a sure path to funds loss.
 41 2016-07-26 07:58:49	0|wumpus|right
 42 2016-07-26 07:59:03	0|warren|Make them type the passphrase if they want a receive address?
 43 2016-07-26 07:59:24	0|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?"
 44 2016-07-26 07:59:39	0|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.
 45 2016-07-26 08:00:06	0|sipa|what does electrum do?
 46 2016-07-26 08:00:30	0|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
 47 2016-07-26 08:00:34	0|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.
 48 2016-07-26 08:01:15	0|gmaxwell|so it does the encrypting at install, but it makes you make an encryption free backup at the same time.
 49 2016-07-26 08:01:29	0|gmaxwell|It also doesn't have hours/days lag between install and usability. :)
 50 2016-07-26 08:01:31	0|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
 51 2016-07-26 08:01:59	0|sipa|gmaxwell: also... our wallet model is really that you should not lose your wallet.dat
 52 2016-07-26 08:02:08	0|wumpus|gmaxwell: there have been plenty of ideas of discouraging creating receive addresses at all before syncing up?
 53 2016-07-26 08:02:29	0|gmaxwell|wumpus: well it's perfectly fine to recieve before synced, if you know that you won't see the results right away!
 54 2016-07-26 08:02:49	0|wumpus|gmaxwell: but confusino about that almost no one knows that, and it results in 99% of support mails I get
 55 2016-07-26 08:03:01	0|sipa|sure, with deterministic seeds there is a way to recover your funds from catastrophic lost
 56 2016-07-26 08:03:07	0|sipa|but not the rest...
 57 2016-07-26 08:03:12	0|wumpus|gmaxwell: I'm not saying it should be impossible ofc
 58 2016-07-26 08:03:32	0|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.
 59 2016-07-26 08:04:06	0|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.
 60 2016-07-26 08:04:07	0|wumpus|wallet.dat encryption helps against exploit that allow grabbing a named file from the file system, but not more
 61 2016-07-26 08:04:58	0|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.
 62 2016-07-26 08:05:20	0|wumpus|it's not exactly a panacea, but encryption never is, it only helps if it's used in the right way
 63 2016-07-26 08:05:24	0|gmaxwell|but for that sort of thing a passphrase such as "goat" is perfectly fine. :P
 64 2016-07-26 08:05:48	0|wumpus|in any case I don't think arguing about this makes sense - we're not considering removing wallet encryption I hope?
 65 2016-07-26 08:05:55	0|sipa|i'm sure more funds have been lost from forgotten passphrases than from theft
 66 2016-07-26 08:06:09	0|sipa|wumpus: hell no
 67 2016-07-26 08:06:14	0|gmaxwell|wumpus: yea, not going to remove it. (I say with some regret.)
 68 2016-07-26 08:06:39	0|gmaxwell|(because as sipa says, I'm pretty confident that more funds have been lost to lost passphrases, than saved from theft by it)
 69 2016-07-26 08:06:50	0|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.
 70 2016-07-26 08:07:05	0|gmaxwell|wumpus: same malware also has keylogging hooks.
 71 2016-07-26 08:07:18	0|wumpus|gmaxwell: that's not an argument against theft happening
 72 2016-07-26 08:07:27	0|wumpus|gmaxwell: just that the current security may not be good enough
 73 2016-07-26 08:07:59	0|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.
 74 2016-07-26 08:08:09	0|gmaxwell|forgotten vs protected from theft by encryption.
 75 2016-07-26 08:08:24	0|wumpus|hw wallets would be preferable, and I think we need to support those in the future
 76 2016-07-26 08:08:29	0|gmaxwell|I do know of cases protected from theft by encryption, but few.
 77 2016-07-26 08:08:39	0|gmaxwell|wumpus: yes.
 78 2016-07-26 08:08:57	0|wumpus|but repeating this discussion for/against wallet encrption every few months is not going to help :)
 79 2016-07-26 08:09:39	0|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.
 80 2016-07-26 08:10:26	0|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
 81 2016-07-26 08:11:06	0|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.
 82 2016-07-26 08:11:17	0|gmaxwell|can't spell tonight.
 83 2016-07-26 08:12:28	0|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.
 84 2016-07-26 08:14:04	0|wumpus|gmaxwell: yes, we agree there, I started this off with stating that I don't like forcing the user to set a passphrase
 85 2016-07-26 08:14:26	0|wumpus|and I don't think a goal should be to encourage people to use the encryption
 86 2016-07-26 08:14:34	0|wumpus|but if they want to use it, they should be able to
 87 2016-07-26 08:14:47	0|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.
 88 2016-07-26 08:14:55	0|wumpus|and then it should also be as secure *as possible given the constraints of local usage tc*
 89 2016-07-26 08:15:37	0|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.
 90 2016-07-26 08:17:17	0|wumpus|indeed, an unencrypted backup makes sense combined with physical security
 91 2016-07-26 08:17:31	0|sipa|then again we don't even have a user-friendly way to recover from a backup...
 92 2016-07-26 08:17:34	0|wumpus|if only they don't put it in the cloud :(
 93 2016-07-26 08:18:14	0|gmaxwell|wumpus: electrum works hard to make you actually write it down... it does all it can to prevent your backup from being electronic.
 94 2016-07-26 08:18:47	0|wumpus|gmaxwell: yes that is good
 95 2016-07-26 08:19:29	0|wumpus|sipa: yes, which wouldnthere the ugly problem of lack of people actually interested in working on it rears its head again
 96 2016-07-26 08:19:36	0|wumpus|which wouldn't be rocket science*
 97 2016-07-26 08:20:47	0|wumpus|I mean there is a 'backup wallet' menu option, could add an 'import wallet' option too
 98 2016-07-26 08:20:55	0|wumpus|although it would work better with multi-wallet support I guess
 99 2016-07-26 08:20:57	0|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.
100 2016-07-26 08:21:22	0|gmaxwell|Restore is mostly a disaster until something is done about rescan.
101 2016-07-26 08:21:31	0|btcdrak|greenaddress has encrypted seeds so you put in a passohrase and it gives you an encrypted seed
102 2016-07-26 08:21:38	0|wumpus|why? it doesn't matter if restore takes a while, it will be an infrequent operation
103 2016-07-26 08:21:47	0|btcdrak|that is part of the initialisation process.
104 2016-07-26 08:22:07	0|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
105 2016-07-26 08:22:13	0|gmaxwell|wumpus: there is "a while" and then there is ">8 hours" which is what a rescan takes on my laptop.
106 2016-07-26 08:22:33	0|wumpus|gmaxwell: that long? oh last time I did it it was much faster
107 2016-07-26 08:22:39	0|wumpus|yes, >8 hours is bad
108 2016-07-26 08:22:46	0|btcdrak|rescan? ouch
109 2016-07-26 08:23:00	0|gmaxwell|I think on a fast machine its about 5 hours now, down from about 12 prior to 0.12.0.
110 2016-07-26 08:23:01	0|btcdrak|good case for keeping an addrindex
111 2016-07-26 08:23:01	0|wumpus|that's longer than a reindex takes in good circumstances
112 2016-07-26 08:23:41	0|wumpus|why is a rescan so slow? it's a fairly simple scan over data right?
113 2016-07-26 08:23:52	0|gmaxwell|deseralizes every block and every transaction.
114 2016-07-26 08:24:17	0|wumpus|so deserialization-bound? ok
115 2016-07-26 08:24:20	0|gmaxwell|and then is constantly opening and closing the wallet database.
116 2016-07-26 08:24:40	0|gmaxwell|I believe that one of phantomcircuit's wallet fixes (maybe in the pipeline) fixed the latter part.
117 2016-07-26 08:24:44	0|wumpus|I guess there's room for optimization there, it wouldn't need to deserialize everything
118 2016-07-26 08:25:25	0|wumpus|many operations could be done in-place on the data
119 2016-07-26 08:25:50	0|gmaxwell|or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
120 2016-07-26 08:26:33	0|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.
121 2016-07-26 08:26:35	0|wumpus|anyhow: why would importing a wallet.at require a rescan?
122 2016-07-26 08:26:52	0|wumpus|it's no different from replacing your wallet.dat with a different one and restarting the client
123 2016-07-26 08:27:09	0|gmaxwell|it always requires _some_ rescanning; assuming it was offline more than one blocktime :P
124 2016-07-26 08:27:16	0|gmaxwell|but presumably a backup is old.
125 2016-07-26 08:27:21	0|wumpus|the transaction should already be in there. Sure, it may need to catch up a bit, but no full rescan should be needed
126 2016-07-26 08:27:44	0|gmaxwell|well the first 300k blocks rescan in pretty much no time. :P
127 2016-07-26 08:27:50	0|wumpus|partial rescans are pretty fast at least in my experience
128 2016-07-26 08:28:12	0|wumpus|I just don't think this is a blocker issue for implementing wallet import, if someone really wanted to implement it
129 2016-07-26 08:28:23	0|wumpus|optimizing rescan would be awesome still
130 2016-07-26 08:28:52	0|gmaxwell|I have data on the partial rescan.
131 2016-07-26 08:29:11	0|sipa|the wallet should be able to tell the node code that some range of blocks is to be downloaded agaim
132 2016-07-26 08:30:05	0|gmaxwell|2016-07-25 06:57:24 Rescanning last 5556 blocks (from block 416625)...
133 2016-07-26 08:30:09	0|gmaxwell|2016-07-25 07:02:23  rescan               298400ms
134 2016-07-26 08:30:12	0|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
135 2016-07-26 08:30:23	0|gmaxwell|that was a backup restore I did a day ago.
136 2016-07-26 08:30:38	0|sipa|gmaxwell: many matching transactiond in that range?
137 2016-07-26 08:30:50	0|wumpus|a lot things never get done because too many other things are dragged into it, the old scope creep again
138 2016-07-26 08:30:53	0|gmaxwell|sipa: none.
139 2016-07-26 08:31:01	0|sipa|gmaxwell: ugh
140 2016-07-26 08:31:28	0|sipa|well, 1 second per week
141 2016-07-26 08:31:35	0|wumpus|oh so you want to implement wallet importing? we first need to improve rescan performance. Oh never mind then...
142 2016-07-26 08:32:11	0|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.
143 2016-07-26 08:32:22	0|wumpus|gmaxwell: yes, that's a very bad data point.
144 2016-07-26 08:33:39	0|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.
145 2016-07-26 08:34:23	0|wumpus|talking about rescanning, did anyone ever notice this issue: https://github.com/bitcoin/bitcoin/issues/8116
146 2016-07-26 08:34:35	0|wumpus|the rescan suddenly started over
147 2016-07-26 08:34:48	0|wumpus|I'm sure it can be really slow if it's done multiple times :p
148 2016-07-26 08:37:07	0|gmaxwell|freaky, I don't think I've seen it do that before.
149 2016-07-26 08:37:36	0|gmaxwell|oh I see you imported while it was already rescanning, and so it started over?
150 2016-07-26 08:37:58	0|gmaxwell|oh no your import is what triggered the rescan and the new block restarted it.
151 2016-07-26 08:38:00	0|wumpus|no, that's not even possible
152 2016-07-26 08:38:06	0|wumpus|if it's rescanning everything is blocked
153 2016-07-26 08:38:16	0|wumpus|yes, that seems to be the case
154 2016-07-26 08:38:43	0|gmaxwell|weird. pretty sure I've seen it connect blocks while rescannign and not start over.
155 2016-07-26 08:41:48	0|wumpus|maybe it was just a fluke. But it could explain some very slow rescans
156 2016-07-26 08:42:29	0|gmaxwell|not the ones I've been expirencing at least.
157 2016-07-26 08:42:35	0|wumpus|the end result was correct so I didn't make a big issue out of it
158 2016-07-26 08:42:38	0|gmaxwell|but some of the complaints for sure.
159 2016-07-26 08:43:35	0|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.
160 2016-07-26 08:46:26	0|gmaxwell|da2ce7_mobile: what you're asking there could describe several different actual usecases which have different supporting development requirements.
161 2016-07-26 08:47:08	0|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.
162 2016-07-26 08:47:53	0|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)
163 2016-07-26 08:48:53	0|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.
164 2016-07-26 08:49:08	0|da2ce7_mobile|You could import these seeds into your Bitcoin Core to act as hot-wallets.
165 2016-07-26 08:50:04	0|gmaxwell|you mean extended public keys there.
166 2016-07-26 08:50:15	0|gmaxwell|IIRC trezor has absolutely no private key export.
167 2016-07-26 08:50:54	0|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.
168 2016-07-26 08:50:58	0|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.
169 2016-07-26 08:51:29	0|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.
170 2016-07-26 08:51:46	0|da2ce7_mobile|yeah. It would be great if BIP44 had a 'hardened only' option.
171 2016-07-26 08:52:07	0|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.
172 2016-07-26 08:53:05	0|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.
173 2016-07-26 08:53:09	0|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.
174 2016-07-26 08:55:46	0|da2ce7_mobile|I really don't like public derivation.  I don't see any point of it if you have a hardware wallet.
175 2016-07-26 08:56:15	0|da2ce7_mobile|it is userfull for 'watch only'
176 2016-07-26 08:56:29	0|da2ce7_mobile|but most people don't use watch only accounts.
177 2016-07-26 08:57:21	0|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.
178 2016-07-26 08:57:50	0|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.
179 2016-07-26 08:57:57	0|jonasschnelli|da2ce7_mobile: indeed
180 2016-07-26 08:58:13	0|gmaxwell|da2ce7_mobile: indeed. Public derrivation causes a lot of trouble for a very narrow improvement.
181 2016-07-26 08:58:33	0|gmaxwell|it's useful, but the utility is often overhyped.
182 2016-07-26 08:58:52	0|sipa|... says the man who invented iy
183 2016-07-26 08:58:56	0|sipa|:)
184 2016-07-26 08:59:00	0|sipa|*iy
185 2016-07-26 08:59:03	0|sipa|**it
186 2016-07-26 08:59:21	0|jonasschnelli|hehe
187 2016-07-26 08:59:43	0|jonasschnelli|I think there are serval usecases for pubkd... but not for the novice wallet user
188 2016-07-26 08:59:58	0|gmaxwell|sipa: yup.
189 2016-07-26 09:00:21	0|jonasschnelli|So... I'm kinda no longer sure if we even want to allow flexible keypath... with or without pubckd
190 2016-07-26 09:00:55	0|jonasschnelli|We should probably work more towards supporting cold storages with something like "importmulti"
191 2016-07-26 09:01:42	0|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
192 2016-07-26 09:01:48	0|gmaxwell|on addresses is also undesirable. :P
193 2016-07-26 09:02:22	0|gmaxwell|I think supporting offline wallets, HW wallets, and multisig with these things should be a higher priority than anything about derrivation paths.
194 2016-07-26 09:02:38	0|gmaxwell|Some things like multisig might imply things about derrivation paths, and thats fine.
195 2016-07-26 09:03:42	0|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)
196 2016-07-26 09:03:42	0|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.
197 2016-07-26 09:04:08	0|jonasschnelli|rawtx is possible because fundrawtx has a custom change address in 0.13.
198 2016-07-26 09:04:42	0|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"
199 2016-07-26 09:04:43	0|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.
200 2016-07-26 09:05:16	0|jonasschnelli|gmaxwell: I though it would be most simple if it would be TCP/HTTP
201 2016-07-26 09:05:33	0|jonasschnelli|A json call goes out to a configurable URL, a response might come back.
202 2016-07-26 09:05:58	0|jonasschnelli|Would also possible allow to sign on a cold storage attached to a different computer in your LAN
203 2016-07-26 09:06:00	0|gmaxwell|Then you get CSRF from js running on the users machine...
204 2016-07-26 09:06:13	0|jonasschnelli|You can avoid that...
205 2016-07-26 09:06:16	0|gmaxwell|different computer; now the communication needs to be cryptographically protected.
206 2016-07-26 09:06:27	0|gmaxwell|Sure you can but you just said, most simple.
207 2016-07-26 09:06:40	0|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.
208 2016-07-26 09:06:43	0|gmaxwell|Having to avoid CSRF and provide link layer encryption is not simple.
209 2016-07-26 09:06:51	0|jonasschnelli|Launching a process... yes. Why not...
210 2016-07-26 09:06:59	0|jonasschnelli|It would also eliminate the need for a background daemon
211 2016-07-26 09:07:22	0|jonasschnelli|Can you check if a certain process (application at path) is already running?
212 2016-07-26 09:07:33	0|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.
213 2016-07-26 09:07:37	0|jonasschnelli|Or how would you prevent from spinning off to many processes?
214 2016-07-26 09:08:51	0|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.
215 2016-07-26 09:10:52	0|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...
216 2016-07-26 09:11:10	0|gmaxwell|By blocking I just meant bitcoin core wouldn't open multiple processes.
217 2016-07-26 09:11:15	0|jonasschnelli|But right, you could track on the bitcoincore side if there is already a signing in process and refuse anotherone.
218 2016-07-26 09:11:26	0|gmaxwell|Not the actual mechenism for talking to the file descriptors.
219 2016-07-26 09:12:36	0|jonasschnelli|You could also retrive pubkeys over that process by sending different commands over stdio
220 2016-07-26 09:12:46	0|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.
221 2016-07-26 09:27:57	0|GitHub176|13bitcoin/06master 14ab942c1 15Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
222 2016-07-26 09:27:57	0|GitHub176|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/517eee3e8f8b...618c9dd8c651
223 2016-07-26 09:27:58	0|GitHub176|13bitcoin/06master 14618c9dd 15Wladimir J. van der Laan: Merge #8365: Treat high-sigop transactions as larger rather than rejecting them...
224 2016-07-26 09:28:10	0|GitHub182|[13bitcoin] 15laanwj closed pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (06master...06unifysigopcost) 02https://github.com/bitcoin/bitcoin/pull/8365
225 2016-07-26 09:36:54	0|sipa|anyone have any intuition about what hashrate you could get out of a raspberry pie?
226 2016-07-26 09:37:26	0|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...
227 2016-07-26 09:37:49	0|sipa|but that requires its hashrate to be at most 1.2 Mhash/s
228 2016-07-26 09:42:53	0|jonasschnelli|install CGMiner...
229 2016-07-26 09:45:07	0|gmaxwell|jonasschnelli: has no cpu mining.
230 2016-07-26 09:45:27	0|gmaxwell|sipa: openssl has a nice benchmark.
231 2016-07-26 09:45:48	0|jonasschnelli|Oh. I'm not familiar with mining, maybe install cpuminer..
232 2016-07-26 09:45:54	0|kinlo|sipa: raspberry pi will not get 1.2 Mhash/s
233 2016-07-26 09:46:01	0|kinlo|it's not that powerfull
234 2016-07-26 09:46:30	0|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).
235 2016-07-26 09:49:52	0|gmaxwell|https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#ARM
236 2016-07-26 09:50:30	0|sipa|ok, http://qr.ae/1x0nad
237 2016-07-26 09:50:33	0|gmaxwell|funny how much slower original rpi is compared to sensible arm computers.
238 2016-07-26 09:50:48	0|gmaxwell|in any case those numbers are going to be too slow by about 10% or so because they don't implement asicboost.
239 2016-07-26 09:51:38	0|gmaxwell|"more energy than a whole country" is ... laughable
240 2016-07-26 09:53:14	0|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?
241 2016-07-26 09:54:34	0|gmaxwell|sipa: nice answer. :P
242 2016-07-26 12:07:24	0|GitHub15|[13bitcoin] 15jonasschnelli opened pull request #8407: [Qt] Add dbcache migration path (06master...062016/07/qt_dbcache) 02https://github.com/bitcoin/bitcoin/pull/8407
243 2016-07-26 12:24:39	0|GitHub29|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/618c9dd8c651...4b1a4d8810f9
244 2016-07-26 12:24:40	0|GitHub29|13bitcoin/06master 141ffaff2 15Johnson Lau: Make witness v0 outputs non-standard before segwit activation
245 2016-07-26 12:24:40	0|GitHub29|13bitcoin/06master 14c59c434 15Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs
246 2016-07-26 12:24:41	0|GitHub29|13bitcoin/06master 144b1a4d8 15Wladimir J. van der Laan: Merge #8381: Make witness v0 outputs non-standard...
247 2016-07-26 12:24:54	0|GitHub118|[13bitcoin] 15laanwj closed pull request #8381: Make witness v0 outputs non-standard (06master...06patch-15) 02https://github.com/bitcoin/bitcoin/pull/8381
248 2016-07-26 12:26:14	0|GitHub164|13bitcoin/060.13 14f84ee3d 15Johnson Lau: Make witness v0 outputs non-standard before segwit activation...
249 2016-07-26 12:26:14	0|GitHub164|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/86edc20a178c...4f7f531af6e1
250 2016-07-26 12:26:15	0|GitHub164|13bitcoin/060.13 144f7f531 15Suhas Daftuar: qa: Add test for standardness of segwit v0 outputs...
251 2016-07-26 12:28:40	0|GitHub160|[13bitcoin] 15laanwj closed pull request #8364: Fix counting of sigops cost in mempool check (06master...06fix-mempool-sigops) 02https://github.com/bitcoin/bitcoin/pull/8364
252 2016-07-26 12:40:43	0|GitHub30|13bitcoin/06master 14faa5931 15MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)
253 2016-07-26 12:40:43	0|GitHub30|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4b1a4d8810f9...beadffae6d65
254 2016-07-26 12:40:44	0|GitHub30|13bitcoin/06master 14beadffa 15Wladimir J. van der Laan: Merge #8358: [doc] gbuild: Set memory explicitly (default is too low)...
255 2016-07-26 12:40:58	0|GitHub38|[13bitcoin] 15laanwj closed pull request #8358: [doc] gbuild: Set memory explicitly (default is too low) (06master...06Mf1607-docBuild) 02https://github.com/bitcoin/bitcoin/pull/8358
256 2016-07-26 12:41:33	0|GitHub192|13bitcoin/060.13 14cfd1280 15MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)...
257 2016-07-26 12:41:33	0|GitHub192|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/cfd1280f23bf687a38d3d00355ac94a3646cb59f
258 2016-07-26 12:46:59	0|GitHub199|[13bitcoin] 15NicolasDorier closed pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (06master...06wallet-min-output) 02https://github.com/bitcoin/bitcoin/pull/8356
259 2016-07-26 12:54:32	0|sdaftuar|sipa: BlueMatt: i'm not sure i followed your discussion of the sendcmpct semantics
260 2016-07-26 12:55:17	0|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?
261 2016-07-26 12:56:07	0|sdaftuar|also, how do you know what version the compactblock announcements that you receive are generated with?
262 2016-07-26 13:02:00	0|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
263 2016-07-26 13:02:30	0|sdaftuar|sipa: ah okay, so we are looking at responses then. that makes sense to me.
264 2016-07-26 13:05:17	0|sipa|for unsollicited cmpctblocks, you can say that the last received sendcmpct takes effect (as that is the one with the announce bit set)
265 2016-07-26 13:05:42	0|sipa|but it's probably easier to just say that the last understood sendcmpct is what countd?
266 2016-07-26 13:06:15	0|sdaftuar|last one with an understood version number?  yes, i think that.
267 2016-07-26 13:07:25	0|sdaftuar|i guess changing version numbers should only really happen during initial handshake, otherwise we get race conditions
268 2016-07-26 13:07:26	0|sipa|so that means you'd send v1 and then v2 initially, without announce bit
269 2016-07-26 13:09:38	0|sipa|if the peer never sends you a v2, you never ask for announce and never ask for cmpctblock
270 2016-07-26 13:10:00	0|sipa|i don't think there is any race
271 2016-07-26 13:10:19	0|sdaftuar|i mean, you shoulnd'
272 2016-07-26 13:10:24	0|sdaftuar|you shouldn't later try to negotiate up to v2
273 2016-07-26 13:11:13	0|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
274 2016-07-26 13:11:19	0|sdaftuar|then it would be unclear how the announcement is encoded
275 2016-07-26 13:11:39	0|sdaftuar|as i wouldn't know whether my message to you was received before that point, or not.
276 2016-07-26 13:12:01	0|sdaftuar|(if we previously negotiated to v1)
277 2016-07-26 13:13:13	0|sipa|right, there is a possible race
278 2016-07-26 13:55:05	0|AaronvanW|https://twitter.com/spair/status/757908557949984769
279 2016-07-26 13:55:25	0|AaronvanW|"the #bitcoin core developers deserve a lot of credit for sticking to their guns on the block size issue" <- Stephen Pair on Twitter
280 2016-07-26 13:55:31	0|jonasschnelli|AaronvanW. :)
281 2016-07-26 13:56:26	0|jonasschnelli|"[...] sticking to their guns [...]" I think this is the US version for "being loyal"?
282 2016-07-26 13:58:59	0|AaronvanW|more like, not being intimidated or persuaded to do the wrong thing. doing what you believe is right.
283 2016-07-26 13:59:05	0|AaronvanW|(though I'm also no US native)
284 2016-07-26 14:19:03	0|kanzure|AaronvanW: wrong channel i think
285 2016-07-26 14:29:34	0|AaronvanW|o
286 2016-07-26 14:29:35	0|AaronvanW|k
287 2016-07-26 17:01:48	0|jtimon|ping #8348 #8346 and #8391
288 2016-07-26 18:52:51	0|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
289 2016-07-26 18:53:05	0|luke-jr|for 22 minutes now
290 2016-07-26 18:53:14	0|luke-jr|sorry, 1 hour 22 minutes..
291 2016-07-26 18:53:42	0|luke-jr|getpeerinfo shows no blocks inflight from anyone
292 2016-07-26 18:53:52	0|luke-jr|two peers are 0.12.1
293 2016-07-26 18:53:58	0|luke-jr|sipa: ^ any ideas?
294 2016-07-26 19:02:53	0|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
295 2016-07-26 19:03:20	0|luke-jr|sdaftuar: are not 0.12.1 all NODE_WITNESS? O.o
296 2016-07-26 19:03:34	0|sdaftuar|uh, no released code is NODE_WITNESS
297 2016-07-26 19:03:35	0|luke-jr|got something I can addnode?
298 2016-07-26 19:04:03	0|luke-jr|right, I'm confusing segwit with csv now. :|
299 2016-07-26 19:04:25	0|instagibbs|there are reports that syncing on testnet is near impossible with master/0.13
300 2016-07-26 19:04:40	0|sdaftuar|this might work: x9.testnet-seed.bitcoin.jonasschnelli.ch
301 2016-07-26 19:05:02	0|sdaftuar|or you could restart with -forcednsseed maybe
302 2016-07-26 19:08:22	0|luke-jr|-forcednsseed seems to have worked, although I restarted in the process :x
303 2016-07-26 19:10:37	0|sdaftuar|my guess is we should more proactively use the dns seeds if the addrman is light on NODE_WITNESS nodes
304 2016-07-26 19:11:00	0|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
305 2016-07-26 19:11:16	0|sdaftuar|which, i think, improved the bookkeeping on peer services
306 2016-07-26 20:46:17	0|luke-jr|is testnet really at 3.125 BTC subsidy? O.o
307 2016-07-26 20:59:54	0|Lightsword|yep
308 2016-07-26 21:10:23	0|luke-jr|anyone who can easily send a bunch of segwit txs on testnet? :x
309 2016-07-26 21:21:47	0|GitHub66|[13bitcoin] 15sdaftuar opened pull request #8408: Prevent fingerprinting, disk-DoS with compact blocks (06master...06cb-misbehaving) 02https://github.com/bitcoin/bitcoin/pull/8408
310 2016-07-26 21:25:05	0|arubi|luke-jr, I made a few,  I don't have many funds
311 2016-07-26 21:25:48	0|luke-jr|arubi: hm, seems to have not relayed to me; can you pastebin them raw?
312 2016-07-26 21:26:41	0|arubi|hmm let's see.  might have easier time if I set it to output raw hex this time
313 2016-07-26 21:27:30	0|arubi|oh oops it was set to segnet :)  moment
314 2016-07-26 21:27:36	0|luke-jr|XD
315 2016-07-26 21:28:25	0|arubi|making some more txes
316 2016-07-26 21:30:30	0|luke-jr|arubi: if you have a limited #, hold off a bit, I have a crash to debug XD
317 2016-07-26 21:31:13	0|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/
318 2016-07-26 21:33:19	0|arubi|and txs themselves http://paste.debian.net/hidden/283a36ab/
319 2016-07-26 21:33:38	0|arubi|heh, should've uniq, but you get what it means :)
320 2016-07-26 22:10:03	0|luke-jr|crap, someone mined the witness stuff
321 2016-07-26 22:10:39	0|luke-jr|anyone else? XD
322 2016-07-26 22:24:14	0|luke-jr|yay for invalidateblock <.<
323 2016-07-26 22:37:37	0|luke-jr|someone screwing with me by sending bitcoins to random mining addresses? <.<
324 2016-07-26 22:37:47	0|luke-jr|[testnet]
325 2016-07-26 22:50:06	0|luke-jr|Lightsword: can you mine a testnet block on top of mine? :p
326 2016-07-26 22:50:17	0|luke-jr|000000000296ba9a3ef21c0978962203ee8b75a2e0b0a5a8ec57517ebb6b8e07
327 2016-07-26 22:50:24	0|luke-jr|(should be current best block)
328 2016-07-26 22:50:47	0|luke-jr|(anyone else is fine too, but preferably not using libblkmaker code)
329 2016-07-26 23:10:10	0|luke-jr|thanks