1 2015-05-20 00:10:12 <kadoban> Luke-Jr: Ahh, throw --squash on the end? I'm not entirely clear on why that makes it "work", but it seems to. I don't usually --squash, heh. Check to make sure it makes sense of course, I don't understand the code really at all.
  2 2015-05-20 00:11:24 <Luke-Jr> kadoban: hm, this does better, but still conflicts :/
  3 2015-05-20 00:14:01 <kadoban> :/ on master and master it went through without
  4 2015-05-20 00:14:45 <Luke-Jr> hmm
  5 2015-05-20 00:15:01 <Luke-Jr> ok, I see why I think
  6 2015-05-20 00:16:24 <Luke-Jr> thx
  7 2015-05-20 00:16:31 <kadoban> 'welcome
  8 2015-05-20 01:44:26 <jubbub> not much action going on this channel eh?
  9 2015-05-20 03:51:20 <Luke-Jr> hum, looks like MAX_MONEY is actually relevant (to prevent overflows)
 10 2015-05-20 06:41:42 <petertodd> Luke-Jr: heh, you following up on jgarzik's comment? I think you could get around that by sendingthe inputs mostly to fees, and creating a block that throws away some of those fees
 11 2015-05-20 06:42:01 <petertodd> Luke-Jr: but I haven't looked at the v0.old codebase in awhile
 12 2015-05-20 06:42:48 <Luke-Jr> petertodd: no, just a casual observation I made writing code :P
 13 2015-05-20 06:44:51 <petertodd> Luke-Jr: heh
 14 2015-05-20 07:09:38 <jonasschnelli> warren: <cool, will your code have public derivation, allowing watch-only wallets to getnewaddress without any privkeys?> : yes. This is my goal. Currently i'm working on different HD schemes. While creating a new wallet you can add a chainpath argument like "m/44'/0'/0'/", this will define where/how your keys get generated. I also like to add something for pubkey only wallets (watchonly-receiveonly-multisig-wallets).
 15 2015-05-20 07:09:42 <jonasschnelli> warren: https://github.com/jonasschnelli/bitcoin/blob/2015/05/corewallet/src/corewallet/corewallet_wallet.cpp#L58
 16 2015-05-20 07:09:58 <jonasschnelli> (implementation is heavily incomplete for now)
 17 2015-05-20 07:10:38 <gmaxwell> jonasschnelli: it is undesirable to use public derrivation as a default except for particular cases where you really want it (e.g. warren's application is a merchant billing thing)
 18 2015-05-20 07:10:49 <Luke-Jr> … why do we have 3 different places in the code (CreateNewBlock, CTxMemPoolEntry::GetPriority, and CCoinsViewCache::GetPriority) all trying to do the same math? :/
 19 2015-05-20 07:11:41 <gmaxwell> The fact that normal wallets are pushing people onto public derrivation where its properties aren't needed or even used is very concerning to me, there is a material reduction in security which has already caused some funds loss. It makes me somewhat regret having invented the whole scheme to begin with. :(
 20 2015-05-20 07:11:46 <jonasschnelli> gmaxwell: i think a use case could be a 2of2 or 2of3 multisig wallet. You could generate multisig addresses without having pivkeys on your system.
 21 2015-05-20 07:12:01 <jonasschnelli> gmaxwell: of course for merchants receiving-only it could be usefull
 22 2015-05-20 07:12:14 <gmaxwell> yea, sure there absolutely are use cases! merchants recieve only was the motivation for inventing it.
 23 2015-05-20 07:13:11 <stonecoldpat> what do you guys mean by merchant receive only? do you mean one per customer, or the merchants public key is static for everybody? (im probably over-thinking this)
 24 2015-05-20 07:13:23 <gmaxwell> In early 2011 the FSF asked me if there was a way to have their webserver generate fresh random donation addresses for each user, without having private keys on the webserver that could get lost or fail to get backed up...
 25 2015-05-20 07:13:38 <jonasschnelli> gmaxwell: currently i'm not sure if i should implement bip39 or if i should just give the user a chance to write down the master seed in hex (or print over Qt).
 26 2015-05-20 07:13:53 <gmaxwell> stonecoldpat: being able to do one per customer without having private key generation on the server.
 27 2015-05-20 07:14:24 <stonecoldpat> gmaxwell: ah okay, thank you :)
 28 2015-05-20 07:14:34 <jonasschnelli> gmaxwell: i agree that HD pubkey derivation is cool for merchants. But the main attack vector is probably someone who attacks your pubkey(hash)-generation code.
 29 2015-05-20 07:14:41 <gmaxwell> BIP39 was created over my protest (and pieter's and thomasv's-- who was originally an author and requested his name be removed.) Please do not implement that.
 30 2015-05-20 07:15:44 <jonasschnelli> gmaxwell: but manually writing down the hex of a master seed has a high chance of writing down a wrong char. If there would be some redundancy and failure tollerance...
 31 2015-05-20 07:15:48 <gmaxwell> jonasschnelli: yea, it doesn't prevent someone from redirecting future payments, it mostly just avoids past payments being exposed and issues with backing up the webserver. Not _that_ big of an improvement, especially since there is an alternative to generate a zillion keys in advance.
 32 2015-05-20 07:17:20 <gmaxwell> the scheme used in BIP39 doesn't functionally have a check, so if thats your concern... if you want a w/ check scheme thats what base58check is for. (and if you want to make it better we could define a version that adds an extra DAMM-code check digit so that all substutions and transpositions will always be detected)
 33 2015-05-20 07:19:49 <jonasschnelli> gmaxwell: DAMM / integrity is not my main concern. The user probably won't check his written down master seed until he needs a backup. :) I'm looking for a way so that the user can reimport his written down seed even if he missed/misswrote some of the characters.
 34 2015-05-20 07:20:05 <jonasschnelli> *he needs to restore a backup
 35 2015-05-20 07:20:46 <jonasschnelli> Bip39 has a minimal failure tolerance because it uses know words.
 36 2015-05-20 07:21:39 <gmaxwell> jonasschnelli: it doesn't actually, in that the words aren't enforced. It's basically a brainwallet scheme with a suggested front end word thing.
 37 2015-05-20 07:22:06 <gmaxwell> jonasschnelli: any scheme with a check can be searched to reduce errors (some more efficiently than others)
 38 2015-05-20 07:22:15 <Luke-Jr> gmaxwell: ThomasV has some other mnemonic stuff in Electrum I believe, maybe worth pushing him to BIPify
 39 2015-05-20 07:22:47 <gmaxwell> Luke-Jr: I think he had a bad expirence before, with the BIP39 thing being turned into a crappy brainwallet scheme during drafting. :(
 40 2015-05-20 07:22:55 <ThomasV> Electrum currently uses the same wordlist as BIP39 (at least for English).
 41 2015-05-20 07:23:03 <Luke-Jr> gmaxwell: how did he lose control of it? :/
 42 2015-05-20 07:23:10 <Luke-Jr> ThomasV: but not the same algo, right?
 43 2015-05-20 07:23:18 <ThomasV> not the same algo, right
 44 2015-05-20 07:23:28 <ThomasV> bip39 is not consistent
 45 2015-05-20 07:23:35 <Luke-Jr> ThomasV: thoughts on a sane BIP for this? ;)
 46 2015-05-20 07:24:50 <ThomasV> well, first you would need to decide if you want a two-way mapping between mnemonic and seed, or not. BIP39 is somewhat in the middle
 47 2015-05-20 07:25:17 <ThomasV> that's one thing I don't like about it
 48 2015-05-20 07:25:26 <ThomasV> the other is that it does not include a version number
 49 2015-05-20 07:25:29 <gmaxwell> jonasschnelli: have you seen maaku's base-32 encoding? https://gist.github.com/maaku/8996338
 50 2015-05-20 07:25:29 <Luke-Jr> ThomasV: I mean, just taking BIP39, changing it to match what Electrum presently uses, and publishing that as a new BIP
 51 2015-05-20 07:26:00 <ThomasV> Luke-Jr: I guess that would not please the trezor guys
 52 2015-05-20 07:26:26 <Luke-Jr> ThomasV: probably not. does that matter?
 53 2015-05-20 07:26:32 <ThomasV> not to me
 54 2015-05-20 07:26:50 <ThomasV> they put my name on bip39 and I had to ask it to be removed
 55 2015-05-20 07:27:01 <jonasschnelli> gmaxwell: thanks. This is exactly what i was looking for!
 56 2015-05-20 07:28:00 <ThomasV> Luke-Jr: but I'm not sure if what Electrum currently uses would make consensus. some people would argue for a two way mapping
 57 2015-05-20 07:28:24 <gmaxwell> jonasschnelli: for something like that I'd probably also add a DAMM check digit... at the time maaku was writing that I wasn't aware of quasigroup error detection schemes.
 58 2015-05-20 07:28:59 <jonasschnelli> gmaxwell: Yes. This would make sense.
 59 2015-05-20 07:29:06 <Luke-Jr> gmaxwell: thoughts re two way mapping ThomasV mentioned? (I don't really know what that means in this context)
 60 2015-05-20 07:29:30 <ThomasV> Luke-Jr: it means allowing shamir secret sharing
 61 2015-05-20 07:29:38 <gmaxwell> it means you can go from an arbritary private key to the string. There certantly are cases where this is useful and important to have.
 62 2015-05-20 07:30:30 <ThomasV> Electrum hashes the utf8 string, so it's one way
 63 2015-05-20 07:30:39 <ThomasV> (so does bip39)
 64 2015-05-20 07:31:27 <Luke-Jr> oh
 65 2015-05-20 07:31:34 <gmaxwell> that being one of them.  There is the riplin work, which is currently dormant in part due to feature bloat https://bitcointalk.org/index.php?topic=258678.0
 66 2015-05-20 07:32:07 <gmaxwell> I was planning on picking up working on that (or getting someone to) after the PHC completes, and having it use whatever the resulting trendy KDF function is for the encryption.
 67 2015-05-20 07:34:27 <gmaxwell> (feature bloat was that people showed up and wanted both 'denyability' and secret sharing.  The former is not really that compatible with error detection. And the secret sharing is just mildly complicated to implement)
 68 2015-05-20 07:35:01 <ThomasV> I guess multisig replaces secret sharing
 69 2015-05-20 07:35:33 <ThomasV> without multisig it would be much more important to have it
 70 2015-05-20 07:36:06 <gmaxwell> Thats largely my view. Strangly secret sharing seems to be a weird obsession with bitcoin companies, everyone I've talked to that has some private key management story at all go on about it.
 71 2015-05-20 07:36:19 <ThomasV> heh
 72 2015-05-20 07:37:21 <gmaxwell> In terms of storing your own private keys, there is some advantage-- passwords aren't great and if you set them to be anything but the simplest possible you take a serious risk of forgetting.  But if you've put your key in a safe deposit box with a weak password ... well banks are known to prettly liberally confiscate and auction off the boxes in some places.
 73 2015-05-20 07:37:55 <gmaxwell> so sharing lets you have security by treasure hunt, which might actually be safer for many people than picking good passwords, especially absent some kind of recovery mechenism.
 74 2015-05-20 07:40:27 <ThomasV> in practice, if you want 2 way mapping, you must freeze your wordlist, which is not so good imo
 75 2015-05-20 07:40:44 <ThomasV> well, that's what I did in electrum v1
 76 2015-05-20 07:44:05 <gmaxwell> technically it's possible to do two way without that, I think. but not both that and indempotence.   E.g. hash the word to find out what digit it maps to.
 77 2015-05-20 07:44:43 <ThomasV> hmm, right
 78 2015-05-20 07:44:58 <gmaxwell> it's not clear to me if wordets are faster to write / more durable than base32 though.
 79 2015-05-20 07:45:34 <ThomasV> how do you mean? manually?
 80 2015-05-20 07:45:57 <Luke-Jr> gmaxwell: I would expect them to be since you don't need to think about how to spell the words
 81 2015-05-20 07:46:41 <Luke-Jr> manually copying down base32, I would probably have to waste more time tracking my position, and be uncertain enough I'd want to verify I copied it correctly 2 or 3 times
 82 2015-05-20 07:47:23 <gmaxwell> I looked before and couldn't find information if anyone has studied this much. I don't really know.   I mean what qualities do we look for in an encoding scheme: fast to write down, and reliably to recover. 256 bits takes 24 words using a reasonable dictionary size, compared to 52 base-32 digits... so number of keystrokes the base32 is less than half the size.
 83 2015-05-20 07:47:48 <gmaxwell> some of that size difference can be used for forward error correction to make it much more durable against common errors.
 84 2015-05-20 07:48:55 <ThomasV> gmaxwell: nothing beats natural language words in terms of user friendliness
 85 2015-05-20 07:49:15 <ThomasV> they will do much more mistakes typing base32
 86 2015-05-20 07:50:02 <gmaxwell> Yes? but so?  you could still have it be 1/3rd less typing but correct up to a dozen incorrect characters or transpositions and/or several slips (dropped or gained characters).
 87 2015-05-20 07:50:43 <gmaxwell> It might be the case, it's not clear to me-- I looked and couldn't find any studies or error rates for nonsense phrases.  There is a lot of studies of alphanumeric codes (including tables of what kinds of mistakes are most common)
 88 2015-05-20 07:51:07 <gmaxwell> (by not clear meaning I don't know one way or another)
 89 2015-05-20 07:52:05 <ThomasV> heh, maybe.. actually we could have base32 seeds in Electrum now, and see if users like it. since we use a one way hash, we can include any kind of encoding
 90 2015-05-20 07:52:08 <gmaxwell> intutively words seem friendlier, but it might be that algebraic error correction is better than words.
 91 2015-05-20 07:54:41 <ThomasV> gmaxwell: as you say, words *seem* friendlier. but that is actually a good reason to use them: they don't scare users off for that reason
 92 2015-05-20 07:54:54 <ThomasV> users are not rational
 93 2015-05-20 07:55:11 <gmaxwell> sure thats what I said it would be interesting to study more than just hypothize about.
 94 2015-05-20 07:55:37 <gmaxwell> shorter things also seem friendlier. Also the user preference could be handled by a user choice, this or that.
 95 2015-05-20 07:55:39 <ThomasV> heh, then you should fund a cognitive psychology study
 96 2015-05-20 07:55:52 <gmaxwell> OK. Suggestion on who might be good to do it?
 97 2015-05-20 07:55:53 <gmaxwell> :)
 98 2015-05-20 07:56:08 <ThomasV> well, I did my PhD in such a lab
 99 2015-05-20 07:56:14 <gmaxwell> I tried for a bit back to find a wordlist selected so that the initial or final letters of the words were unique in the list, so you could enter just those for faster entry. ... but I never was super happy with my results.
100 2015-05-20 07:56:28 <ThomasV> (of course that does not make me an expert)
101 2015-05-20 07:56:37 <stonecoldpat> they may also find it more "secure" using alphabraic than words as well
102 2015-05-20 07:57:12 <gmaxwell> As an aside the DAMM quasigroup stuff mentioned earlier works for any base, so you could e.g. add a single word to your menmonic and be able to detect all transposition errors and substution errors.
103 2015-05-20 07:57:33 <gmaxwell> yea, indeed. Or treat their secrets with more respect and care. Dunno!
104 2015-05-20 07:58:08 <ThomasV> gmaxwell: see https://bitcointalk.org/index.php?topic=153990.msg5046887#msg5046887
105 2015-05-20 07:58:28 <jonasschnelli> I would also expect some users prefer base32 over bip39 words. Bip39 just don't look secure (in a psychological meaning).
106 2015-05-20 07:59:10 <ThomasV> gmaxwell: tldr: short words are not good
107 2015-05-20 07:59:20 <ThomasV> for memorisation
108 2015-05-20 07:59:41 <gmaxwell> ThomasV: yea, I wasn't trying for short words. I was trying for long words with unique suffixes (or prefixe).
109 2015-05-20 08:00:14 <gmaxwell> sort of like "short words inside long words"  short for typing into the computer, long for memory (if you're crazy enough to try that!)
110 2015-05-20 08:00:42 <ThomasV> correct horse battery staple
111 2015-05-20 08:00:53 <ThomasV> everyone remembers that ^
112 2015-05-20 08:01:03 <gmaxwell> I often remember it out of order FWIW.
113 2015-05-20 08:02:20 <ThomasV> well, maybe I am not a good example; I had to train my memory a lot at school; our teacher gave us one poetry to learn per week, and we could be questioned about anyone of them since the beginning of the year
114 2015-05-20 08:02:53 <gmaxwell> and apparently so do many other people: $ grep -i 'staple battery' \#bitcoin* | wc -l
115 2015-05-20 08:02:56 <gmaxwell> 5
116 2015-05-20 08:03:10 <ThomasV> lol
117 2015-05-20 08:04:07 <ThomasV> gmaxwell: anyway, my tae is that there is no easy/optimal way to choose a wordlist, so it would be a mistake to freeze it
118 2015-05-20 08:04:24 <ThomasV> that's why I went for a hash of the utf8 phrase
119 2015-05-20 08:04:32 <ThomasV> s/tae/take
120 2015-05-20 08:05:26 <ThomasV> it also makes it easier to have localized versions
121 2015-05-20 08:06:08 <gmaxwell> the resulting limits on error detection/recovery are pretty concerning though... but it depends on the application I suppose. I dunno about your argument, your choice of bad wordlists is not necessarily an improvement over a single bad one. :) Localized is a better argument. Though hashing the words to find out what digits they map to still allows that.
122 2015-05-20 08:06:56 <ThomasV> my point is that if the wordlist is bad, we can change it without breaking existing seeds
123 2015-05-20 08:06:59 <gmaxwell> (though it may mean you need a longer candidate list to cover the whole space. OTOH, if the encoding has adequate forward error correction it could actually handle some digits being missing.
124 2015-05-20 08:07:12 <Diablo-D3> gmaxwell: hijack time, whats your thoughts on logjam
125 2015-05-20 08:07:24 <Diablo-D3> gmaxwell: because it scares the fuck out of me no one generates their own dhparam
126 2015-05-20 08:12:50 <arhuaco> I am having issues creating a script to redeem a 2/3 multisig tx. Could I get help? I could send money with Paypal if we agree something. Thanks.
127 2015-05-20 08:13:29 <ThomasV> arhuaco: maybe you forgot the OP_0 ?
128 2015-05-20 08:14:07 <warren> gmaxwell: RPC getsomewhatunsafepublicderivedaddress
129 2015-05-20 08:16:12 <jonasschnelli> arhuaco: do you implement you own software for that or do you use bitcoind for that? Maybe better #bitcoin
130 2015-05-20 08:17:39 <arhuaco> ThomasV, jonasschnelli. I need to do offline signing. I am trying with Pybitcointools and with python-bitcoinlinb. Pybitcointools does this: serialize_script([None]+sigs+[script]) , so the OP_0 seems to be there.
131 2015-05-20 08:17:53 <arhuaco> ThomasV, jonasschnelli. Signing with Bitcoind worked for me. But I need to do it offline...
132 2015-05-20 08:18:16 <warren> jonasschnelli: more seriously, I wonder if it shouldn't use getnewaddress at all because people won't know it can be very unsafe if misused.
133 2015-05-20 08:18:17 <jonasschnelli> arhuaco: you can use bitcoind for offline signing.
134 2015-05-20 08:18:40 <warren> jonasschnelli: something like derivenextpublicaddress ... where people have to know what they're doing to use it
135 2015-05-20 08:19:04 <jonasschnelli> warren: good point.
136 2015-05-20 08:19:24 <arhuaco> jonasschnelli: I didn't know. I'll try with bitcoin-cli then. It already worked for me.
137 2015-05-20 08:19:49 <jonasschnelli> warren: currently i'm not sure if it would make sense to allow one to select/define the chainpath while calling "getnewaddress" (or new command)
138 2015-05-20 08:19:58 <warren> it also might not be a "new address" in the sense of the previous meaning
139 2015-05-20 08:20:08 <jonasschnelli> also the option if the key should be hardened.
140 2015-05-20 08:20:25 <warren> perhaps a chain path should be chosen with a different command?
141 2015-05-20 08:20:29 <gmaxwell> warren: the model I'd expected was something like a "create public wallet"
142 2015-05-20 08:21:00 <warren> gmaxwell: don't allow mixing?  suppose it could work, I can't think of a use case where you want both I guess.
143 2015-05-20 08:21:13 <warren> err, private keys in the same wallet
144 2015-05-20 08:21:17 <jonasschnelli> "addwallet" should be the place where you could add a new pubkey wallet while providing some arguments like "parent-pubkey" and "chainpath".
145 2015-05-20 08:21:50 <jonasschnelli> warren: mixing can lead to very complex user interactions.
146 2015-05-20 08:21:51 <warren> jonasschnelli: let's design the RPC and use case workflow before going ahead with code?  I'll help.
147 2015-05-20 08:22:35 <jonasschnelli> warren: yes. Help is always good. I also don't care to throw away implementation i just did. It all has it's purpose. :)
148 2015-05-20 08:22:59 <warren> First we need to identify the different use cases.
149 2015-05-20 08:23:20 <jonasschnelli> warren: i'm working more or less full time on this so time is still an issue but not the main point.
150 2015-05-20 08:24:09 <wumpus> cfields: re: ~TestingSetup() never being called, that indeed sounds like a bug, so the teardown stuff was never being tested
151 2015-05-20 08:24:23 <warren> Is the intent for the future default wallet to use hardened key private derivation?
152 2015-05-20 08:24:32 <jmcn> Ok, I give up, I need to ask.... should "verificationprogress" (in rpc getblockchaininfo) ever decrease?
153 2015-05-20 08:25:31 <jmcn> (I'm upgrading bitcoind from 0.89 to 0.10.1 on an old server)
154 2015-05-20 08:25:35 <wumpus> jmcn: yes, if you wait long enough or are stuck, the chain keeps growing so relatively you can go backwards
155 2015-05-20 08:25:50 <Luke-Jr> warren: how is key derivation unsafe?
156 2015-05-20 08:25:53 <wumpus> the block number should not be decreasing of course
157 2015-05-20 08:25:56 <jonasschnelli> warren: i think so. I don't have the full understanding of this right now but i think every key for receiving and change should be hardened. I don't see why change keys should be non-hardened.
158 2015-05-20 08:26:37 <jmcn> wumpus: hmm, block numbers are not increasing, they're constant at 330386 (the node got stuck at a fork there ages back)
159 2015-05-20 08:26:48 <wumpus> in that case you may have to reindex
160 2015-05-20 08:27:12 <warren> Luke-Jr: if you reveal the privkey of any unhardened key, you have revealed the privkey for the entire chain, I think
161 2015-05-20 08:27:23 <Luke-Jr> warren: well sure, but that's a risk to revealing private keys..
162 2015-05-20 08:27:26 <jmcn> ah, I did a rescan, not re-index. thanks
163 2015-05-20 08:27:28 <Luke-Jr> not to key derivation
164 2015-05-20 08:27:44 <jonasschnelli> warren: imo bitcoin-core should be easy to use by default, standard hd scheme like m/44/0/0, but if you provide some rpc arguments you should be able to do more complex things like pubkey-wallets, multisig-cosign-wallet, etc.
165 2015-05-20 08:27:50 <wumpus> jmcn: (possibly a combination of invalidateblock/reconsiderblock may also work)
166 2015-05-20 08:28:00 <wumpus> jmcn: rescan only affects the wallet, not the sync process
167 2015-05-20 08:28:36 <Luke-Jr> jonasschnelli: multisig really should be easy too ideally
168 2015-05-20 08:29:14 <warren> jonasschnelli: pubkey-wallet refers to my watch-only receiving use case?
169 2015-05-20 08:29:17 <jonasschnelli> Luke-Jr: Agreed. Over RPC it could be hard. But over the UI it could be easy by passing around transactions with QR codes or so.
170 2015-05-20 08:30:37 <jonasschnelli> warren: pubkey-wallet could be used for "receiving only" wallets (with generation of new receiving keys). As well they can be used to create 2of2 multistig addresses.
171 2015-05-20 08:32:17 <Luke-Jr> jonasschnelli: eh, RPC isn't for end users in any case
172 2015-05-20 08:32:29 <jonasschnelli> warren: maybe the main focus for a HD implementation should be a easy way of supporting cosigning-wallets (multisig).
173 2015-05-20 08:32:56 <warren> Luke-Jr: the previous meaning of getnewaddress was different, with different guarantees
174 2015-05-20 08:33:01 <jonasschnelli> Luke-Jr: depends on how you define endusers. But agreed. UI level is more for "endusers".
175 2015-05-20 08:33:01 <Luke-Jr> jonasschnelli: Electrum supports multisig with hardware wallets or public services coordinating FWIW
176 2015-05-20 08:33:24 <Luke-Jr> warren: no, it has always been "if any private key is revealed, consider the whole wallet compromised"
177 2015-05-20 08:34:31 <jonasschnelli> Luke-Jr: I think hardware wallets are cool. But nowadays everyone has laying around a old unused smartphone (old generation). A offline phone supporting a 2of2 multisig wallet as cosigning would be a easy an secure ways of handling higher value funds.
178 2015-05-20 08:35:01 <Luke-Jr> I don't.. but they're cheap anyway. :P
179 2015-05-20 08:35:07 <Luke-Jr> don't all old smartphones have USB? ;)
180 2015-05-20 08:35:13 <warren> old unused smartphone with forever unpatched security holes
181 2015-05-20 08:35:32 <Luke-Jr> warren: less relevant if you have an entire firmware dedicated to making it a hardware wallet
182 2015-05-20 08:35:55 <ThomasV> Luke-Jr: Electrum currently supports both multisig and hw wallets, but not multisig hw wallets :-P
183 2015-05-20 08:35:57 <Luke-Jr> although otoh, I'd rather my hardware wallets not have wireless capabilities
184 2015-05-20 08:36:03 <jonasschnelli> USB/NFC/Bluetooth all produce problems in user friendliness (drivers, activations, etc.). For cosigning i would just prefer to go over cams/qr codes.
185 2015-05-20 08:36:04 <Luke-Jr> ThomasV: oh O.o
186 2015-05-20 08:36:20 <ThomasV> Luke-Jr: it should be added soon, though
187 2015-05-20 08:36:25 <Luke-Jr> jonasschnelli: how does that work for getting data into my PC? ;)
188 2015-05-20 08:37:30 <jonasschnelli> This is a good point. Because you wan't to have your cosining wallet (smartphone) offline, it might should come back to your PC. If you don't have a webcam at your PC (to scan a QR code) you might need a different channel like TCP oder mDNS, Bluetooth or something like this.
189 2015-05-20 08:37:58 <jonasschnelli> *it might come back to your PC -> (the transaction)
190 2015-05-20 08:37:59 <Luke-Jr> USB is easy on Linux, at least. just plug in the device and it works.
191 2015-05-20 08:38:07 <warren> jonasschnelli: let's start a bitcoin-dev list discussion about the different use cases people expect and what kind of RPC interface would be best to support the different uses.
192 2015-05-20 08:38:08 <jonasschnelli> USB is a nogo for iOS
193 2015-05-20 08:38:27 <Luke-Jr> jonasschnelli: iOS might as well be perpetually compromised anyway
194 2015-05-20 08:38:55 <Luke-Jr> otoh, I guess that's what the multisig is supposed to solve
195 2015-05-20 08:39:02 <jonasschnelli> right!
196 2015-05-20 08:39:21 <ThomasV> jonasschnelli: electrum allows you to send/receive transactions via qr codes. however, you cannot send all the previous transactions that way (useful if you want to verify the amounts of the inputs)
197 2015-05-20 08:39:25 <jonasschnelli> Why investing in a save hardware (like Trezor) when you can use your old phone with a 2of2 ms?
198 2015-05-20 08:39:53 <jonasschnelli> ThomasV: right. QR code has it's limits.
199 2015-05-20 08:40:19 <ThomasV> you can also use the audio modem/microphone
200 2015-05-20 08:40:45 <Luke-Jr> jonasschnelli: 1) Trezor doesn't have wireless comms that can be exploited; 2) sales help firmware dev; 3) Ledger hw wallet is safe against sidechannels; 4) USB is workable
201 2015-05-20 08:41:53 <jonasschnelli> Luke-Jr: if you have concerns about exploiting/compromising. Use a 3of3ms and add another smartphone (1: your PC, 2: your old iPhone, 3: your old Android phone).
202 2015-05-20 08:42:22 <jonasschnelli> IMO the cool thing about multisig is that it doen't matter that much if one device is compromised.
203 2015-05-20 08:42:52 <Luke-Jr> well, if all 3 devices (like the ones you listed) are vulnerable, it matters
204 2015-05-20 08:42:55 <warren> I'd be worried about the old phone failing randomly one day.
205 2015-05-20 08:43:21 <Luke-Jr> if your PC runs Apple, you have 2 companies with backdoors into all your keys
206 2015-05-20 08:43:40 <Luke-Jr> and all 3 of those devices are vulnerable to sidechannels
207 2015-05-20 08:43:41 <warren> my old Nexus S's kernel reported escalating quantities of bad flash
208 2015-05-20 08:43:47 <wumpus> warren: trazors fail too, using an external device does not free you from the burden of making a backup
209 2015-05-20 08:44:01 <Luke-Jr> wumpus: Trezors can clone each other I think
210 2015-05-20 08:44:11 <Luke-Jr> guess that's beside the point
211 2015-05-20 08:44:14 <wumpus> oh, sure, it may be more *convenient* with a trezor
212 2015-05-20 08:44:26 <wumpus> that's why they sell specific hardware :)
213 2015-05-20 08:44:28 <jonasschnelli> right. Of course you should paper-backup your three wallets
214 2015-05-20 08:44:39 <ThomasV> lol
215 2015-05-20 08:44:41 <jonasschnelli> :)
216 2015-05-20 08:45:02 <wumpus> it has drifted quite far from normal bitcoin-dev territory (though not so far to be off topic)
217 2015-05-20 08:45:03 <jonasschnelli> well, we where trying to specify a possible new wallet RPC interface. :)
218 2015-05-20 08:45:13 <warren> I like cheese.
219 2015-05-20 08:46:33 <Luke-Jr> anyhow, the risk of exposing private keys has always been to compromise the entire wallet; HD wallets makes that more a practical reality, but it doesn't change the guarantees or expected results
220 2015-05-20 09:02:29 <arhuaco> jonasschnelli: I noticed people do two things. 1) Run bitcoind and don't connec to any peer. 2) ./bitcoin-tx. Trying to sign with bitcoin-tx, figuring out how to pass the priavate keys, not much info out there.
221 2015-05-20 09:03:15 <warren> jonasschnelli: so I'm not here, sleeping ... but maybe 'getnewaddress' really meant "new address" in the past, as in unused.  There's no guarantee of that with derivation.  So maybe that' s a reason not to overload the previous RPC command.
222 2015-05-20 09:04:47 <jonasschnelli> arhuaco: you can also run bitcoind on a offline machine and use the rawtransaction (oder multisig) RPC calls.
223 2015-05-20 09:05:33 <jonasschnelli> arhuaco: you can use signrawtransaction by providing a privatekey as argument or by having a private key in your bitcoind's wallet
224 2015-05-20 09:05:44 <jonasschnelli> but anyhow, this is #bitcoin stuff
225 2015-05-20 10:13:05 <rubensayshi> bleh testnet diff reset to 1.0 is really anoying if you want to test some stuff with unconfirmed TXs :/
226 2015-05-20 10:25:45 <btcdrak> rubensayshi use regtest, then you have control over the process
227 2015-05-20 10:44:47 <wumpus> without the reset to 1.0 it was also annoying - though with different reasons, like days without block if someone pointed an ASIC farm at it for a while
228 2015-05-20 11:20:18 <jonasschnelli> wumpus: i think https://github.com/bitcoin/bitcoin/pull/6160 would also be good to have in 0.11 (because it's a consistency fix for https://github.com/bitcoin/bitcoin/pull/6110)
229 2015-05-20 11:20:28 <wumpus> yes
230 2015-05-20 11:20:31 <wumpus> just testing it
231 2015-05-20 11:20:38 <jonasschnelli> cool. Thanks.
232 2015-05-20 11:20:52 <wumpus> seems to work. cool
233 2015-05-20 11:21:26 <jonasschnelli> But i have to admit i'm not happy with the SigneColorIcons. On ubuntu it looks good. But on Fedora the blueish looks,... ugly.
234 2015-05-20 11:21:51 <wumpus> well it's just a matter of finding the right way to determine the color
235 2015-05-20 11:22:30 <jonasschnelli> Right. I think we should have some fixed colors (maybe 3-4) and choose one of the given color depending on the detected palette.
236 2015-05-20 11:22:37 <wumpus> it should be picked from the theme somehow, but the current way is not necessarily the best way  (but having it the same as the text color may be too boring?)
237 2015-05-20 11:23:01 <jonasschnelli> i'll try a fix/improvement soon
238 2015-05-20 11:23:02 <wumpus> I don't like hardcoding colors at al
239 2015-05-20 11:23:35 <jonasschnelli> coder don't like hardcoded colors, designers do. :)
240 2015-05-20 11:23:37 <wumpus> in my case it picks an acceptable color from the theme, and in the default ubuntu case it does too
241 2015-05-20 11:24:06 <wumpus> people that use custom themes generally don't
242 2015-05-20 11:26:17 <jonasschnelli> fedora: http://i.imgur.com/sK41XCY.png
243 2015-05-20 11:26:23 <jonasschnelli> It's acceptable.
244 2015-05-20 11:26:51 <wumpus> I like it
245 2015-05-20 11:27:36 <jonasschnelli> but i don't get why it's blue. There is no blue color on the rest of my fedora stuff.
246 2015-05-20 11:28:00 <wumpus> I think that's the default plastique theme
247 2015-05-20 11:28:24 <wumpus> on ubuntu qt uses the gtk theming, these days, but some reason it doesn't on fedora, so it falls back to its default theme
248 2015-05-20 11:28:25 <jonasschnelli> ah. there is blue. For selected items, etc.
249 2015-05-20 11:29:01 <wumpus> yes, it's the highlight color, also see the progress bar
250 2015-05-20 11:29:48 <jonasschnelli> Agreed. It's okay....
251 2015-05-20 11:32:11 <wumpus> so if you don't like the blue you could configure another qt/kde theme with a different highlight color, it should automatically pick that. I think that's neat.
252 2015-05-20 11:33:23 <jonasschnelli> Yes. This makes sense. I kinda start to like the SingleColor thing (on linux at least).
253 2015-05-20 11:47:18 <bsm117532> What kind of horrors would befall us if blocks contained only the Merkle tree, but not the transactions themselves, instead depending on the p2p network to distribute them?
254 2015-05-20 11:50:11 <wumpus> isn't that just redefining the block to be the block header?
255 2015-05-20 11:50:42 <wumpus> the P2P network already distributes the transactions, along with the block header, for easy verification. Sure, other P2P schemes could be used (see iBLT)
256 2015-05-20 11:51:25 <bsm117532> The CBlockHeader has only the Merkle root, not the entire tree.
257 2015-05-20 11:52:23 <wumpus> but the idea behind merkle trees is that it commits the entire tree, so you could send along the tree if you wanted
258 2015-05-20 11:52:31 <bsm117532> Correct me if I'm wrong, but when we transmit blocks, the only thing that nodes receive that don't already have (or could get) is the Merkle tree.
259 2015-05-20 11:53:32 <wumpus> it's indeed one of the options for faster block propagation, as many of the transactions will have already been gossiped over the network. But the whole merkle tree is stil quite big, and it would involve a few roundtrips to request them, so it's likely not the optimal solution
260 2015-05-20 11:54:21 <wumpus> (I'd refer to previous discussion about speeding up block propagation on e.g. the mailing list)
261 2015-05-20 11:54:22 <bsm117532> I'm not sure what you want with "optimal".  The only further improvement would be to break the Merkle tree into smaller chunks (faster block time)
262 2015-05-20 11:55:46 <wumpus> here: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
263 2015-05-20 11:56:47 <bsm117532> Ah yes I've read that one
264 2015-05-20 12:04:46 <bsm117532> Gavin's idea is slightly better than mine, if he can make it work.  He wants to find a way to transmit *only* the block header, and have the Merkle tree constructable by nodes using a deterministic algorithm.  I'm saying just to transmit the Merkle tree.
265 2015-05-20 12:05:06 <bsm117532> In either case, we don't need to transmit tx's.  Why do we still double-send tx's in the block?
266 2015-05-20 12:14:12 <wumpus> you wouldn't ever have to send the enitire merkle tree, just sending the hashes at the bottom level would be enough to construct the whole of it
267 2015-05-20 12:15:33 <wumpus> bluematt's relay network also does a few optimizations for block propagation, I'm not sure which ones though
268 2015-05-20 12:16:45 <bsm117532> does Gavin have an implementation of this?
269 2015-05-20 12:17:54 <wumpus> there's some more discussion about it here, including code; https://rustyrussell.github.io/pettycoin/2014/11/05/Playing-with-invertible-bloom-lookup-tables-and-bitcoin-transactions.html
270 2015-05-20 12:20:56 <fanquake> ;;blocks
271 2015-05-20 12:20:57 <gribble> 357252
272 2015-05-20 12:33:20 <bsm117532> For some other applications I'm leaning toward Cuckoo Filters.  It's a lot easier to understand how much they can hold.  One should be able to create an Invertible Cuckoo Lookup Table instead...
273 2015-05-20 12:47:52 <wumpus> yes that could be an interesting comparison
274 2015-05-20 12:49:08 <bsm117532> I'm not finding that anyone has created an ICLT yet.
275 2015-05-20 12:52:57 <bsm117532> A IBLT has a failure case when all of its buckets contain 2 or more entries (or zero).  Then it's non-empty but can no longer list its contents.
276 2015-05-20 12:53:40 <bsm117532> In which case you need a secondary mechanism to request the Merkle tree or txs in a block.  :-/
277 2015-05-20 13:51:03 <wallet42> does linearize.py still works, now that the blocks my be in disorder?
278 2015-05-20 14:04:55 <wumpus> wallet42: linearize.py has been adapted for that, yes
279 2015-05-20 14:43:39 <michagogo> wumpus: adapted? Did the 2-step thing get made without the out-of-order support?
280 2015-05-20 14:44:31 <michagogo> Actually, wait, linearize.py is only the name of the one that asks bitcoind for all the blocks via RPC
281 2015-05-20 16:44:46 <wumpus> michagogo: linearize (which indeed consists of two scripts, of which only the second phase is relevant here) was changed at around the same time to support out-of-order block storage as bitcoind itself
282 2015-05-20 16:52:17 <kanzure> which flag should i use to make regtest bitcoind relay zero fee transactions? -sendfreetransactions ? -minrelaytxfee=0 ?
283 2015-05-20 17:18:23 <morcos> -relaypriority=0 I think
284 2015-05-20 17:19:56 <morcos> kanzure: you can't set minrelaytxfee to 0, and i think sendfreetransactions is only used by the wallet code
285 2015-05-20 17:21:53 <morcos> you can also increase -limitfreerelay if you don't want the rate limiter to kick in for free transactions, but thats prob not necessary unless you're going crazy
286 2015-05-20 17:23:28 <kanzure> morcos: i'm trying to send just one zero fee transaction.
287 2015-05-20 17:23:31 <kanzure> ah, relaypriority.
288 2015-05-20 17:23:37 <kanzure> thank you
289 2015-05-20 17:29:22 <morcos> wumpus: do you have a list of PR's that still need testing for 0.11
290 2015-05-20 17:32:38 <wumpus> morcos: #5927 #5943 #5976 #5985 #5989 #6030 #6153
291 2015-05-20 17:34:17 <morcos> ok, thx, i'll see if i can take a look at some
292 2015-05-20 17:35:45 <morcos> wumpus: would you consider adding #5875 if you pull #5927, I think I would feel better about not opening up any new DOS attacks, even if it's not clear how practical it would be
293 2015-05-20 17:48:03 <wumpus> yes #5875 is also on the list (don't know why I missed it)
294 2015-05-20 18:12:51 <jonasschnelli> would it make sense to add the 0.11 milestone for #5875 #5927 #5943 #5976 #5985 #5989 #6030 #6153?
295 2015-05-20 19:09:03 <btcdrak> wumpus is #6124 on the list for 0.11?
296 2015-05-20 22:41:11 <denisx> BlueMatt: the eu server seems not to work right now
297 2015-05-20 23:55:12 <TD-Linux> gmaxwell, yeah I'll fix travis, I have real work to do though too :^)
298 2015-05-20 23:55:52 <gmaxwell> TD-Linux: no rush.
299 2015-05-20 23:56:11 <TD-Linux> I actually thought I fixed it yesterday but I forgot a noinst_HEADERS
300 2015-05-20 23:56:38 <TD-Linux> I actually highly doubt anyone will ever use this with autotools, but it's handy for testing
301 2015-05-20 23:59:30 <gmaxwell> I dunno, I anticpate making the static signing tables a default, ... unless I come up with another blinding technique thats incompatible with them. :)