1 2016-08-19 01:07:50	0|jcorgan|wumpus: is there a plan for #7753?
  2 2016-08-19 01:29:24	0|jl2012|gmaxwell, luke-jr: I think we could require an extra command in debug windows to "unlock" those sensitive commands
  3 2016-08-19 01:32:06	0|CodeShark|jl2012: good idea
  4 2016-08-19 01:33:08	0|jl2012|which will return a page of warning, describing the risk of each unlocked command
  5 2016-08-19 01:35:50	0|luke-jr|jl2012: hmm, that might work
  6 2016-08-19 04:48:10	0|GitHub144|[13bitcoin] 15petertodd opened pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (06master...062016-08-anyonecanpay-if-spendzeroconfchange-disabled) 02https://github.com/bitcoin/bitcoin/pull/8543
  7 2016-08-19 06:29:22	0|GitHub95|[13bitcoin] 15jonasschnelli closed pull request #8541: Trivial: Fix typos in various files (06master...06various-typos) 02https://github.com/bitcoin/bitcoin/pull/8541
  8 2016-08-19 06:34:55	0|jonasschnelli|sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig.  ecdsa(sha256(sha256(<filecontent>)), P)
  9 2016-08-19 06:35:41	0|jonasschnelli|sipa, gmaxwell: then we could have a file with [{"<devname>":"34byte pubkey"},]
 10 2016-08-19 06:35:49	0|jonasschnelli|(a cpp header IMO)
 11 2016-08-19 06:38:18	0|jonasschnelli|For the downloading the asset file signatures, we could use the github API (GET /repos/:owner/:repo/contents/:path)
 12 2016-08-19 06:38:47	0|jonasschnelli|Using the maybe existing local git binary seems fragile
 13 2016-08-19 06:40:31	0|luke-jr|Seems unlikely Mac/Windows (where this will generally get used) will have a local git binary anyway
 14 2016-08-19 06:46:49	0|jonasschnelli|luke-jr: Yes. depending on git is probably a nogo on Win/OSX
 15 2016-08-19 07:39:41	0|da2ce7|jonasschnelli a ecdsa binary verify client would be very useful for other projects.  It would be great to create something that could get support of a wider community.
 16 2016-08-19 07:40:21	0|jonasschnelli|Yes. Maybe it could be coupled with gitian
 17 2016-08-19 07:44:29	0|da2ce7|I would have something like a 'project definition' file.  that defines the fields: serial, project name, version naming rules, public keys, n of m requirements, revoked keys, revoked releases
 18 2016-08-19 07:45:26	0|da2ce7|and a 'witness file', that has a list of sha256 hashes, and signatures.
 19 2016-08-19 07:46:29	0|jonasschnelli|You need to make sure the "project definition" (devs pubkey) must be covered by a sha256 during previous builds...
 20 2016-08-19 07:47:05	0|jonasschnelli|This why it might be best if compiled into a binary or if its covered in the gitian assets file
 21 2016-08-19 07:48:16	0|da2ce7|the project definition file should come with a self-witness, except that the self-witness is signed by all of the public keys defined in the definition.
 22 2016-08-19 07:48:36	0|da2ce7|(ignores the n-of-m requirement).
 23 2016-08-19 07:48:38	0|catsAREnotSECURE|Is there public disclosure of  bitcoin holdings / wallets associated with specific developers?
 24 2016-08-19 07:48:56	0|da2ce7|catsAREnotSECURE no, and off topic.
 25 2016-08-19 07:49:29	0|catsAREnotSECURE|This question was intended for midnightmagic. The conversation began in #bitcoin, but for transparency reasons, I sought to move it to this channel.
 26 2016-08-19 07:51:40	0|da2ce7|catsAREnotSECURE, well, I'm sorry for your mistake, please move it back to #bitcoin, or elsewhere.
 27 2016-08-19 07:51:52	0|catsAREnotSECURE|One more comment and then that will be it.
 28 2016-08-19 07:52:08	0|catsAREnotSECURE|midnightmagic, During the last meeting, there was discussion regarding the proposed implementation a system similar to that which Gitian is using, which features signatures of multiple developers, within the official binary / source distribution on certain operating systems. One proposal included distributing the GPG library and another used an alternate method for signature / checksum verification which would not require additional
 29 2016-08-19 07:52:09	0|catsAREnotSECURE|libraries. The alternate proposal, determined by Wladimir van der Laan to be unworkable, intended to mitigate the requirement of an additional library by imbedding checksums within the blockchain. The alternate proposal was not included in the official meeting and was dismissed over stated concerns about existing nodes rejecting the transactions. It was acknowledged that either implementation would significantly increase client
 30 2016-08-19 07:52:09	0|catsAREnotSECURE|security during the release cycle, affecting the majority of users, and it is speculated by my clients that either implementation would result in less (downward) price fluctuation. Right now, the security of the releases are highly dependant on admittedly vulnerable CA/TLS certificates and a single GPG signing key held by Wladimir van der Laan, with a lack of transparency regarding the level of security measures taken to secure this
 31 2016-08-19 07:52:14	0|catsAREnotSECURE|signing key. During this "unofficial" meeting in #bitcoin, there were a minimum of 123 lines of comment from Wladimir van der Laan, all of which are not included in the "official" meeting log. Given the recent advisory on the website, regarding "state actors", there is speculation amoung my clients that conflict of interest disclosure and transparency may be insufficient amoung the Bitcoin Core developers.
 32 2016-08-19 07:54:16	0|sipa|catsAREnotSECURE: take it elsewhere
 33 2016-08-19 07:54:17	0|luke-jr|then your clients should hire people of their own to work as Bitcoin Core developers; off-topic anyway, #bitcoin
 34 2016-08-19 07:55:19	0|jonasschnelli|sigh
 35 2016-08-19 07:59:44	0|da2ce7|jonasschnelli we need a constant 'Project CN', so that somebody doesn't release 'bitcotn-core' and project will ignore all the signing policies.  -  The verify app should also spit out warnings:  "bitcotn-core" is very similar to "bitcoin-core".
 36 2016-08-19 08:00:29	0|da2ce7|maybe a simple 'release' file will suffice.  a release file has: project CN, sha256 of latest 'project definition' file, release name and version, list of sha256 of past release files, list of sha256 of binaries included in release
 37 2016-08-19 08:33:57	0|wumpus|gmaxwell: god damnit, can it get any more scammy
 38 2016-08-19 08:34:10	0|MarcoFalke|?
 39 2016-08-19 08:34:24	0|wumpus|<gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey.  :(
 40 2016-08-19 08:35:01	0|LeMiner|ugh...
 41 2016-08-19 08:35:14	0|sipa|:(
 42 2016-08-19 08:36:11	0|wumpus|fuckers
 43 2016-08-19 08:36:19	0|sipa|do we need to put a warning in the qt console when using certain RPCs?
 44 2016-08-19 08:36:22	0|LeMiner|could include a warning message on dumbprivkey that the outputs are private and anyone with the key can steal your coins?
 45 2016-08-19 08:36:24	0|LeMiner|exactly
 46 2016-08-19 08:36:40	0|wumpus|does anyone have info on that guy?
 47 2016-08-19 08:36:57	0|sipa|of course, then people may get users to run bitcoin-qt with -server...
 48 2016-08-19 08:37:00	0|midnightmagic|wumpus: Yes. A tenuous link.
 49 2016-08-19 08:37:07	0|LeMiner|Not a bad idea
 50 2016-08-19 08:37:16	0|luke-jr|sipa: jl2012 suggested an extra step to enable dangerous RPCs
 51 2016-08-19 08:37:41	0|luke-jr|(which would warn)
 52 2016-08-19 08:37:53	0|wumpus|luke-jr: +1
 53 2016-08-19 08:38:32	0|wumpus|I think any private key leaking functions should be disabled by default
 54 2016-08-19 08:38:34	0|LeMiner|And perhaps a topic message in #bitcoin that states to be cautious when people try to "help" you through pm's
 55 2016-08-19 08:38:35	0|wumpus|both for the UI and RPC
 56 2016-08-19 08:38:54	0|wumpus|maybe a command line option to enable them
 57 2016-08-19 08:38:56	0|sipa|LeMiner: nobody reada the topic message, but it can't hurt
 58 2016-08-19 08:45:14	0|wumpus|jcorgan: not really, I try to get back to that at some point
 59 2016-08-19 08:45:21	0|wumpus|jcorgan: lots of things got in between, as usual :(
 60 2016-08-19 08:46:00	0|wumpus|aim is still 0.14 I guess
 61 2016-08-19 08:54:18	0|wumpus|https://github.com/bitcoin/bitcoin/issues/8544
 62 2016-08-19 09:00:25	0|jouke|wumpus: :(
 63 2016-08-19 09:00:53	0|wumpus|jouke: yes thsi makes me really grumpy
 64 2016-08-19 09:08:46	0|jouke|But, literally at the same time we were helping a customer on the phone to do a dumpprivkey :x. (Someone bought bitcoins to pay for cryptolocker, but didn't realise that it would take a while for Core to be able to send bitcoins).
 65 2016-08-19 09:13:14	0|wumpus|"Someone bought bitcoins to pay for cryptolocker" :(
 66 2016-08-19 09:13:24	0|wumpus|I'm going to take off today, sorry
 67 2016-08-19 09:13:33	0|jouke|heh
 68 2016-08-19 09:13:58	0|wumpus|stupid fuckers, sometimes I'm about to believe the story that bitcoin is just making it easy for people to be scammed out of their money
 69 2016-08-19 09:14:37	0|jonasschnelli|Private-key-management will occupy us during the next years...
 70 2016-08-19 09:14:53	0|jonasschnelli|But people also need to wake up...
 71 2016-08-19 09:15:18	0|wumpus|yes, people need to take responsibility, or not use it at all
 72 2016-08-19 09:15:23	0|jonasschnelli|Would you give someone (just met on the street), you wallet containing 10k USD to "fix an issue" with the opening zipper?
 73 2016-08-19 09:15:31	0|wumpus|but things like cryptolocker ... bah puke
 74 2016-08-19 09:16:25	0|jonasschnelli|Cryptolockers are evil, ... indeed.
 75 2016-08-19 09:16:43	0|wumpus|jonasschnelli: not a random someone, but what if someone pretends to be e.g. a cop, people would be inclined to trust them
 76 2016-08-19 09:17:30	0|jonasschnelli|maybe in Europe. :) But right,... people pretending to help on technical issues but then scam off one, thats just so bad.
 77 2016-08-19 09:17:32	0|wumpus|but yes the threshold for trust should be even lower on the internet, you can almost never assume peopel are who them pretend they are
 78 2016-08-19 09:18:28	0|wumpus|that's a much bigger problem than just bitcoin
 79 2016-08-19 09:18:48	0|jouke|A lot of people are really trustful by nature.
 80 2016-08-19 09:19:42	0|jonasschnelli|which is good IMO
 81 2016-08-19 09:20:20	0|jouke|They should wake up indeed. But I lost a bit of confidence in "people" to be able to do so since I started with Bitcoin. On the other hand, a police officer once told me: "These people are allowed to vote".
 82 2016-08-19 09:20:22	0|jonasschnelli|But I agree with wumpus, we should add some private key protections
 83 2016-08-19 09:20:50	0|jonasschnelli|But the questions is then, if an attacker can manage to enable the protected features by setting a config value, etc.
 84 2016-08-19 09:20:58	0|jonasschnelli|(if they already manage to execute dumpprivkey)
 85 2016-08-19 09:21:05	0|jonasschnelli|Maybe warning are the better approach
 86 2016-08-19 09:21:14	0|jonasschnelli|you need to call dumpprivkey twice...
 87 2016-08-19 09:21:25	0|jonasschnelli|first time, it will response with a warning
 88 2016-08-19 09:21:42	0|wumpus|a big red warning on top of the debug console
 89 2016-08-19 09:22:07	0|jouke|Only to come to realise that people don't read :P
 90 2016-08-19 09:22:16	0|jonasschnelli|or we could entirely disable dumpprivkey in the GUI
 91 2016-08-19 09:22:24	0|jonasschnelli|(and dumpwallet)
 92 2016-08-19 09:22:43	0|jonasschnelli|like most hardware wallets, there is no way to export private keys.
 93 2016-08-19 09:22:59	0|jonasschnelli|(for core, except your using -server/d with bitcoin-cli
 94 2016-08-19 09:24:25	0|wumpus|yes, ideally wallets wouldn't allow exporting private keys
 95 2016-08-19 09:25:38	0|wumpus|jouke: what was the point of having the user do dumpprivkey? I hope he didn't have to give the private key over the phone?
 96 2016-08-19 09:26:24	0|jouke|wumpus: no, we are very strict on not wanting to know the privkey (although it's quite tempting to just ask for the wallet).
 97 2016-08-19 09:26:55	0|jouke|wumpus: to transfer it to an other "light weight" wallet.
 98 2016-08-19 09:27:09	0|jonasschnelli|transfering keys is bad...
 99 2016-08-19 09:27:18	0|jonasschnelli|transfering coins over on-chain transactions probably much better
100 2016-08-19 09:27:29	0|jonasschnelli|the fee should be worth the additional security
101 2016-08-19 09:28:08	0|jouke|Very often the payees of cryptolockers are businesses that are unable to work so they don't want to way for the wallet to fully synchronize.
102 2016-08-19 09:28:15	0|jouke|*wait
103 2016-08-19 09:28:59	0|jouke|Normally we tell people to just wait.
104 2016-08-19 09:29:09	0|wumpus|core should also warn better that it's unable to process transactions until it is synced, there's already a pull for that though
105 2016-08-19 09:29:42	0|wumpus|https://github.com/bitcoin/bitcoin/pull/8371
106 2016-08-19 09:29:51	0|jonasschnelli|Yes. Needs testing.
107 2016-08-19 09:29:57	0|wumpus|so that people don't get the idea that they can just make a receiving address and receive coins
108 2016-08-19 09:30:09	0|jonasschnelli|But what we really need is a SPV hybrid mode
109 2016-08-19 09:30:14	0|jonasschnelli|This would solve so much hassle.
110 2016-08-19 09:30:17	0|jouke|wumpus: *and send coins
111 2016-08-19 09:30:34	0|wumpus|jouke: well they can receive coins, but they won't see them until synced
112 2016-08-19 09:30:41	0|wumpus|jouke: and can't send them through either
113 2016-08-19 09:30:49	0|wumpus|jonasschnelli: sure, but tha's further away
114 2016-08-19 09:30:56	0|jonasschnelli|yes. agreed
115 2016-08-19 09:31:00	0|wumpus|just warning people and telling people what they're up to would already go a*long* way
116 2016-08-19 09:31:05	0|wumpus|we haven't been doing enough of that
117 2016-08-19 09:31:13	0|wumpus|always far-away technical solutions
118 2016-08-19 09:32:09	0|jouke|I like that pull request :)
119 2016-08-19 09:33:29	0|jonasschnelli|Needs testing.. will probably be in 0.14
120 2016-08-19 09:33:41	0|wumpus|at least it's much easier to merge than a SPV mode jonasschnelli:)
121 2016-08-19 09:33:48	0|GitHub82|13bitcoin/06master 14b4a9aa5 15Wladimir J. van der Laan: qt: Fix random segfault when closing "Choose data directory" dialog...
122 2016-08-19 09:33:48	0|GitHub82|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8250de13587e...36404aeec8c1
123 2016-08-19 09:33:49	0|GitHub82|13bitcoin/06master 1436404ae 15Wladimir J. van der Laan: Merge #8540: qt: Fix random segfault when closing "Choose data directory" dialog...
124 2016-08-19 09:33:49	0|jonasschnelli|heh... indeed
125 2016-08-19 09:34:02	0|GitHub158|[13bitcoin] 15laanwj closed pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (06master...062016_08_qt_choosedatadir_crash) 02https://github.com/bitcoin/bitcoin/pull/8540
126 2016-08-19 09:38:54	0|wumpus|jonasschnelli: but yes we should really start merging some GUI changes for 0.14
127 2016-08-19 09:38:59	0|wumpus|jonasschnelli: so much open
128 2016-08-19 09:39:41	0|jonasschnelli|Yes. But mosts things are not ready
129 2016-08-19 09:39:58	0|jonasschnelli|But will have a look next week
130 2016-08-19 09:39:59	0|wumpus|0.14 is still far away, so merging something not-entirely-perfect-yet that can be improved later is actually ok
131 2016-08-19 09:40:10	0|jonasschnelli|Yes
132 2016-08-19 09:40:13	0|wumpus|incremental development tends to work better for GUI
133 2016-08-19 09:41:27	0|wumpus|ooh https://github.com/bitcoin/bitcoin/pull/8517 is cool
134 2016-08-19 09:41:30	0|wumpus|I completely missed that one
135 2016-08-19 09:41:34	0|jonasschnelli|I'm finishing my QT Mempool stats PR, then I'll focus on getting things in
136 2016-08-19 09:41:47	0|jonasschnelli|8517 is mostly ready IMO
137 2016-08-19 09:41:58	0|jonasschnelli|Needs some Win/Linux testing I guess
138 2016-08-19 09:42:14	0|jonasschnelli|And I think I need to run optimizepngs
139 2016-08-19 09:43:15	0|wumpus|going to test it
140 2016-08-19 09:57:53	0|GitHub3|[13bitcoin] 15MarcoFalke opened pull request #8545: [doc] Update git-subtree-check.sh README (06master...06Mf1608-doc) 02https://github.com/bitcoin/bitcoin/pull/8545
141 2016-08-19 10:19:01	0|GitHub39|13bitcoin/06master 1465f4532 15Jameson Lopp: document return value of networkhashps for getmininginfo RPC endpoint
142 2016-08-19 10:19:01	0|GitHub39|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/36404aeec8c1...f4e777819c54
143 2016-08-19 10:19:02	0|GitHub39|13bitcoin/06master 14f4e7778 15Wladimir J. van der Laan: Merge #8461: document return value of networkhashps for getmininginfo RPC endpoint...
144 2016-08-19 10:19:11	0|GitHub3|[13bitcoin] 15laanwj closed pull request #8461: document return value of networkhashps for getmininginfo RPC endpoint (06master...06rpcMiningHelp) 02https://github.com/bitcoin/bitcoin/pull/8461
145 2016-08-19 10:34:18	0|GitHub140|[13bitcoin] 15mcccs opened pull request #8546: Remove IP transaction check [CLEAN] (06master...06abc123) 02https://github.com/bitcoin/bitcoin/pull/8546
146 2016-08-19 10:34:38	0|GitHub142|[13bitcoin] 15mcccs closed pull request #8538: Remove IP transaction check (06master...06Ip-check) 02https://github.com/bitcoin/bitcoin/pull/8538
147 2016-08-19 15:13:17	0|jonasschnelli|gmaxwell, sipa: what do you think about the following approach: https://bitcoin.jonasschnelli.ch/ecdsa_sig.txt
148 2016-08-19 15:21:37	0|gmaxwell|Requiring QT is problematic, since many (esp high security) users are headless cli users.  This sounds like it is not (many) fewer steps then verifying with gpg? it sounds like you're thinking the user will seperately download the software, but then verify it with this which will also make outbound connections?
149 2016-08-19 15:23:15	0|gmaxwell|My suggestion is that we make it so there is a single download which contains all the verification information. Just one file.  And have it so the tool can either take this one file provided by the user and verify it and if it passes, unpack and install it, or it can fetch it + verify it (then unpack and install it).
150 2016-08-19 15:25:02	0|gmaxwell|it's important that its also easy to use the tool without it making network connections, so that it can be used on offline hosts, and also not "phone home" every time bitcoin is installed, which would make it easy to track who is using it. (both who is using bitcoin and who is using it with/without verifying-- we want a network attacker to not be able to tell users who verify from users who don'
151 2016-08-19 15:25:08	0|gmaxwell|t)
152 2016-08-19 15:26:33	0|jonasschnelli|gmaxwell: Good point.. make sense.
153 2016-08-19 15:28:03	0|jonasschnelli|gmaxwell: regarding "single download", Isn't grabbing the sources from a GPG signed github repository more secure?
154 2016-08-19 15:28:21	0|jonasschnelli|Hmm... no... not really
155 2016-08-19 15:28:41	0|jonasschnelli|Agree, we could provide a single witness file along with the binaries
156 2016-08-19 15:29:02	0|jonasschnelli|If additional signature follow after the release, we could update the witness file.
157 2016-08-19 15:29:24	0|gmaxwell|then thats two files, which would be unfortunate (bad for usability)
158 2016-08-19 15:29:44	0|jonasschnelli|What would speak against replacing the witness file...
159 2016-08-19 15:29:46	0|jonasschnelli|?
160 2016-08-19 15:30:30	0|jonasschnelli|gmaxwell: Or do you mean a "single download" would be the verifing tool including the witness data?
161 2016-08-19 15:30:34	0|gmaxwell|By two files I mean "bitcoin" and "the witness"  if there are two files someone watching the network can tell which users check and which don't,  and someone checking on an offline computer has two files to download and copy across, so they won't.
162 2016-08-19 15:31:29	0|gmaxwell|I mean the bitcoin core update and the signatures for it should be a single file.  The download/verifying tool can both be included in it, and available seperately (for the first time user).
163 2016-08-19 15:31:42	0|jonasschnelli|ah...
164 2016-08-19 15:31:44	0|jonasschnelli|yes..
165 2016-08-19 15:32:11	0|jonasschnelli|Though, there would be a file-package (including sigs) per platform I guess
166 2016-08-19 15:33:09	0|gmaxwell|Right, I guess I'd suggest we include in the tar a dummy file the size of the witness. And the signing tool would fill that in, and the verify tool would mask out the dummy file. Or something like that.
167 2016-08-19 15:33:45	0|gmaxwell|it's a little unfortunate to have to uncompress an unverified file, but I see no way around that.
168 2016-08-19 15:33:47	0|jonasschnelli|or just <whitnessfile>&<tar.file>
169 2016-08-19 15:34:10	0|gmaxwell|do you mean concatinate them?
170 2016-08-19 15:34:12	0|jonasschnelli|It would be a "new file format"... but I guess that doesn't matter
171 2016-08-19 15:34:16	0|jonasschnelli|yes
172 2016-08-19 15:34:35	0|jonasschnelli|also it prevents from users extracting the tar without verifing.
173 2016-08-19 15:34:45	0|jonasschnelli|Once it was verified, it'll copy out the "pure" tag
174 2016-08-19 15:34:46	0|jonasschnelli|tar
175 2016-08-19 15:34:53	0|gmaxwell|well that would be simpler, unfortunately it would mean a network observer could tell who was downloading those files vs the plain tar files, unless we stopped distributing plain tar files.
176 2016-08-19 15:35:34	0|gmaxwell|I do like that that is much easier to implement. :)
177 2016-08-19 15:35:41	0|jonasschnelli|stopping the plain tar files would probably good, but people will complain. :)
178 2016-08-19 15:35:55	0|jonasschnelli|*be good
179 2016-08-19 15:36:29	0|jonasschnelli|I think forcing user to verify the binaries would be good security pratice.
180 2016-08-19 15:37:11	0|gmaxwell|Yes, but using a web wallet because bitcoin core install required an extra, foreign, step would not be. :)
181 2016-08-19 15:37:33	0|jonasschnelli|indeed...
182 2016-08-19 15:38:06	0|gmaxwell|my expectation is that users would use a traditional, insecure method to do their first install. You really can't do better than that, since even the verify tool itself would need to be installed.
183 2016-08-19 15:38:07	0|jonasschnelli|Assume the signatures file is in the tar,.. I guess you can just extract a single file
184 2016-08-19 15:38:44	0|gmaxwell|jonasschnelli: yes, the trickyness is with verifying you need to verify everything except that file. Which means masking it out.
185 2016-08-19 15:38:47	0|jonasschnelli|Yes. First install of the verify tool should be verified through gitian-verify
186 2016-08-19 15:38:56	0|sipa|do we need a tar parser then...?
187 2016-08-19 15:39:11	0|jonasschnelli|Hmm.. tar dependency would be bad I guess
188 2016-08-19 15:39:38	0|jonasschnelli|Can we not just append the signatures files to the tar so that the tar can still be deflated properly?
189 2016-08-19 15:39:50	0|jonasschnelli|hidden-append...
190 2016-08-19 15:39:55	0|gmaxwell|https://github.com/Gottox/sltar  200 lines of code?
191 2016-08-19 15:40:09	0|jonasschnelli|does that include the gzip?
192 2016-08-19 15:40:45	0|gmaxwell|we could start distibuing the software as shell archives, much easier to extract data from them. :P
193 2016-08-19 15:41:43	0|jonasschnelli|A tar.gz that includes the binary as a tar.gz and the signatures?
194 2016-08-19 15:42:24	0|jonasschnelli|we provide signatures only for the "inner" binary tar.gz
195 2016-08-19 15:43:00	0|jonasschnelli|and would also work with the OSX .dmg and window .exe
196 2016-08-19 15:44:20	0|kanzure|user can open a port on their machine, provide a login to the ripple foundation, and then the ethereum team can deliver the payload in one step
197 2016-08-19 15:45:11	0|kanzure|sltar looks cool. this might even be human-memorizable.
198 2016-08-19 15:46:05	0|wumpus|why would the signature files need to be in a tar?
199 2016-08-19 15:46:16	0|wumpus|just go old school, concatenate binary ecdsa signatures
200 2016-08-19 15:46:31	0|jonasschnelli|to avoid network observers to detect who download the signatures and who not as gmaxwell mentioned
201 2016-08-19 15:46:50	0|wumpus|yes, well, it doesn't matter in what format it is then right?
202 2016-08-19 15:46:55	0|jonasschnelli|wumpus: but that would require to split of the signatures if you just want to install it without verifing
203 2016-08-19 15:47:03	0|wumpus|the user has to download the file with signatures anyhow
204 2016-08-19 15:47:26	0|kanzure|i thought the concern was re: have a single download
205 2016-08-19 15:47:35	0|jonasschnelli|wumpus: not if we make the verification optional
206 2016-08-19 15:47:55	0|wumpus|attaching signatures to the download itself isn't really an option; this would invalidate the sha256 hashes
207 2016-08-19 15:47:58	0|jonasschnelli|and would you also add the signatures to the .exe NSI installer? :)
208 2016-08-19 15:48:09	0|wumpus|no
209 2016-08-19 15:48:45	0|jonasschnelli|Just provide a "meta"-tar that includes the exe/dmg/tar.gz (where we provide hashes/sigs)
210 2016-08-19 15:48:48	0|wumpus|just a replacement/addition to sha256sums.txt, that contains ecdsa signatures connected from by all gitian builders
211 2016-08-19 15:48:58	0|wumpus|coLLected
212 2016-08-19 15:49:02	0|jonasschnelli|Also fine for me.
213 2016-08-19 15:49:13	0|jonasschnelli|gmaxwell said we should use just a single download
214 2016-08-19 15:49:29	0|wumpus|that would be one additional file in addition to the one you want
215 2016-08-19 15:49:38	0|jonasschnelli|to avoid network observers to detect who did download the sigs and who not
216 2016-08-19 15:49:49	0|wumpus|sigh
217 2016-08-19 15:49:54	0|jonasschnelli|hehe.. :)
218 2016-08-19 15:49:55	0|wumpus|I can just smell the scope creep
219 2016-08-19 15:50:10	0|wumpus|don't let gmaxwell get involved in this except for security review :)
220 2016-08-19 15:50:30	0|jonasschnelli|We could start with an additional signatures file (per release including all platforms/binaries)
221 2016-08-19 15:50:37	0|kanzure|re: "one additional file" -- i thought that was the point of tar? :)
222 2016-08-19 15:50:42	0|wumpus|otherwise we'll never have an actually deployable product, just a lot of nice theory
223 2016-08-19 15:50:43	0|wumpus|:P
224 2016-08-19 15:50:55	0|jonasschnelli|though, that signature file may be changed after a release if we get additional signatures
225 2016-08-19 15:51:05	0|wumpus|yes, additional signatures could be added to that file
226 2016-08-19 15:51:18	0|jonasschnelli|But its a manual process I guess... which sucks
227 2016-08-19 15:51:21	0|wumpus|it's just a concatentation of people's signatures of the same thing
228 2016-08-19 15:51:28	0|jonasschnelli|The gitian.sig repo would probably be simpler
229 2016-08-19 15:51:30	0|wumpus|could be fully automated
230 2016-08-19 15:51:36	0|wumpus|python scirpt that pulls stuff from git
231 2016-08-19 15:51:40	0|wumpus|concatenates it
232 2016-08-19 15:51:42	0|jonasschnelli|Yes. Why not
233 2016-08-19 15:51:43	0|wumpus|drops it on the site
234 2016-08-19 15:51:46	0|wumpus|voila
235 2016-08-19 15:52:05	0|jonasschnelli|But not sure if the site is protected with some non-automatable 2FA technique or so.
236 2016-08-19 15:52:06	0|wumpus|could run in a crontab such
237 2016-08-19 15:52:15	0|wumpus|it could be any site
238 2016-08-19 15:52:20	0|jonasschnelli|crontab means the credentials must be available on that machine
239 2016-08-19 15:52:24	0|wumpus|where to drop the signatures? that's a good question
240 2016-08-19 15:52:28	0|jonasschnelli|yes. Could be a different site
241 2016-08-19 15:52:33	0|wumpus|heck, it could be a githib statically hosted site
242 2016-08-19 15:52:38	0|jonasschnelli|indeed
243 2016-08-19 15:52:40	0|wumpus|laanwj.github.com/bla
244 2016-08-19 15:52:54	0|jonasschnelli|Even simpler... it could be in gitian.sigs
245 2016-08-19 15:53:13	0|jonasschnelli|or yes... on a static site
246 2016-08-19 15:53:19	0|wumpus|could be, but rememer it needs to be a static http site
247 2016-08-19 15:53:24	0|wumpus|putting it on github has the https probem again
248 2016-08-19 15:53:37	0|wumpus|well, I mean as a git-based on github
249 2016-08-19 15:53:43	0|wumpus|github static sites are http
250 2016-08-19 15:53:45	0|jonasschnelli|We could add libcurl to our dependencies... *duck*
251 2016-08-19 15:53:51	0|wumpus|:-(
252 2016-08-19 15:53:58	0|jonasschnelli|But wait!
253 2016-08-19 15:54:02	0|jonasschnelli|We could use Qt headless
254 2016-08-19 15:54:10	0|jonasschnelli|no need to build windows.
255 2016-08-19 15:54:12	0|wumpus|the point would be to make the user download it themselves I think
256 2016-08-19 15:54:26	0|wumpus|if it needs to work without network conenction
257 2016-08-19 15:54:47	0|jonasschnelli|both could be possible...
258 2016-08-19 15:54:50	0|wumpus|or just use libevent's http client?
259 2016-08-19 15:54:56	0|wumpus|we already have that
260 2016-08-19 15:55:02	0|jonasschnelli|Yes. Why not...
261 2016-08-19 15:55:13	0|wumpus|it's super-simple, but good enough to fetch a simple small binary or text file, if you really want
262 2016-08-19 15:55:24	0|wumpus|(over http though, forget https)
263 2016-08-19 15:56:31	0|wumpus|we have secp256k1 for signature verification, we have sha256 hashing, and we can fetch files over http through evhttp. I think all the components are there
264 2016-08-19 15:56:51	0|jonasschnelli|Yes
265 2016-08-19 15:57:06	0|wumpus|(that doesn't mean the implementation is trivial! but let's not talk about adding dependencies :-)
266 2016-08-19 15:57:59	0|jonasschnelli|On OSX and Windows, the verify tool should probably have a GUI
267 2016-08-19 15:58:01	0|wumpus|it also doesn't need to rely on qt, although for end-users a qt user interface for it would be nice
268 2016-08-19 15:58:21	0|wumpus|ye
269 2016-08-19 15:58:30	0|jonasschnelli|We could detect the platform (or maybe if a WM is attached on Linux) and create a UI in that case
270 2016-08-19 15:58:41	0|jonasschnelli|Or..
271 2016-08-19 15:58:58	0|jonasschnelli|we provide the verification-feature in Bitcoin-Qt and in the new cli only verify tool
272 2016-08-19 15:58:59	0|wumpus|yea, or have separate verification-cli and verification-gui executables
273 2016-08-19 15:59:19	0|jonasschnelli|or that. yes
274 2016-08-19 15:59:20	0|wumpus|right, that is possible too
275 2016-08-19 15:59:49	0|jonasschnelli|But another GUI tool would require some tweaks in the EXE/DMG deployment
276 2016-08-19 15:59:52	0|wumpus|it has the advantage of not having to package qt twice, as long as we still statically lnk
277 2016-08-19 15:59:58	0|wumpus|right, and that
278 2016-08-19 16:00:12	0|jonasschnelli|Ah. Yes
279 2016-08-19 16:00:12	0|wumpus|so having only one GUI executable which has it as extra menu option would be better probably
280 2016-08-19 16:00:21	0|jonasschnelli|Indeed
281 2016-08-19 16:00:56	0|jonasschnelli|Okay... will try to work out something...
282 2016-08-19 16:00:56	0|wumpus|then have a seprrate cli verification executable
283 2016-08-19 16:01:02	0|wumpus|thanks!
284 2016-08-19 16:01:38	0|jonasschnelli|For creating the signatures, I guess it can be a third party tool.. don't need to be part of Bitcoin-Core
285 2016-08-19 16:02:01	0|wumpus|certainly not
286 2016-08-19 16:02:16	0|wumpus|I'll just roll some script for that, don't worry about that side :)
287 2016-08-19 16:05:28	0|wumpus|I'll have a try at the gitian builder side
288 2016-08-19 16:06:35	0|wumpus|(I wasn't serious about gmaxwell, to be clear)
289 2016-08-19 16:07:00	0|gmaxwell|Why would we create a shitty NIH version of the openbsd signify tool?
290 2016-08-19 16:07:13	0|gmaxwell|There is no security advantage from just changing the underlying cryptosystem.
291 2016-08-19 16:07:34	0|wumpus|it's just easier to integrate in our software than using gpg
292 2016-08-19 16:09:08	0|wumpus|if we could integrate a gpg lib and fetch the signatures from gitian.sigs repository and verify directly (like gitian-downloader) it'd be much more straightforward, but we need something that can be integrated into our software release right?
293 2016-08-19 16:09:26	0|jonasschnelli|Yes
294 2016-08-19 16:10:33	0|GitHub20|[13bitcoin] 15btcdrak opened pull request #8547: Update btcdrak key with new expiry dates (06master...06btcdrak-key) 02https://github.com/bitcoin/bitcoin/pull/8547
295 2016-08-19 16:32:29	0|GitHub196|[13bitcoin] 15MarcoFalke opened pull request #8548: [wallet]  Use __func__ to get function name for output printing (06master...06Mf1608-walletFunc) 02https://github.com/bitcoin/bitcoin/pull/8548
296 2016-08-19 16:39:49	0|GitHub187|13bitcoin/06master 147e5d94d 15Jonas Schnelli: [Wallet] Trivial cleanup of HD wallet changes
297 2016-08-19 16:39:49	0|GitHub187|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f4e777819c54...56ac0469609a
298 2016-08-19 16:39:50	0|GitHub187|13bitcoin/06master 1456ac046 15Jonas Schnelli: Merge #8443: [Wallet] Trivial cleanup of HD wallet changes...
299 2016-08-19 16:39:59	0|GitHub184|[13bitcoin] 15jonasschnelli closed pull request #8443: [Wallet] Trivial cleanup of HD wallet changes (06master...062016/08/hd_fixes) 02https://github.com/bitcoin/bitcoin/pull/8443
300 2016-08-19 16:48:07	0|GitHub136|13bitcoin/06master 14914154f 15Jonas Schnelli: [Qt] add HD enabled/disabled icon to the status bar
301 2016-08-19 16:48:07	0|GitHub136|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/56ac0469609a...2468292a0353
302 2016-08-19 16:48:08	0|GitHub136|13bitcoin/06master 142468292 15Jonas Schnelli: Merge #8517: [Qt] show wallet HD state in statusbar...
303 2016-08-19 16:48:17	0|GitHub179|[13bitcoin] 15jonasschnelli closed pull request #8517: [Qt] show wallet HD state in statusbar (06master...062016/08/hd_gui) 02https://github.com/bitcoin/bitcoin/pull/8517
304 2016-08-19 17:08:08	0|GitHub42|[13bitcoin] 15jmcorgan opened pull request #8549: zmq: mempool notifications (06master...06zmq_mempool) 02https://github.com/bitcoin/bitcoin/pull/8549
305 2016-08-19 19:31:07	0|GitHub95|[13bitcoin] 15jonasschnelli opened pull request #8550: [Qt] Add interactive mempool graph (06master...062016/08/stats_qt) 02https://github.com/bitcoin/bitcoin/pull/8550
306 2016-08-19 20:45:40	0|GitHub4|[13bitcoin] 15MarcoFalke opened pull request #8551: [qa] Remove unused code (06master...06Mf1608-qaUnused) 02https://github.com/bitcoin/bitcoin/pull/8551