1 2014-04-08 00:00:13 <justanot1eruser> s/small fee transactions/child-pays-for-parent transactions
2 2014-04-08 00:02:59 <airbreather> justanot1eruser, what are you trying to accomplish with that idea exactly?
3 2014-04-08 00:12:30 <SoftwareMechanic> I'm not having any success in having the testnet faucets sending to a p2sh address
4 2014-04-08 00:12:34 <SoftwareMechanic> multisig address
5 2014-04-08 00:12:42 <SoftwareMechanic> (not sure about terminology)
6 2014-04-08 00:12:55 <GAit> SoftwareMechanic: have you tried https://tpfaucet.appspot.com/ ?
7 2014-04-08 00:13:12 <SoftwareMechanic> ya, used that one
8 2014-04-08 00:13:14 <GAit> I test it with GreenAddress.it which is P2SH
9 2014-04-08 00:13:14 <SoftwareMechanic> http://blockexplorer.com/testnet/tx/4df4d2707abbcf44027ab54529972db0380de06bd38bdf1d02b4198abf22e275
10 2014-04-08 00:13:27 <SoftwareMechanic> Get a "strange transaction" showing up in block explorer.
11 2014-04-08 00:13:35 <SoftwareMechanic> haven't tried Green
12 2014-04-08 00:13:51 <sipa> why do you assume block explorer even supports p2sh?
13 2014-04-08 00:14:17 <GAit> sipa: good point
14 2014-04-08 00:14:18 <SoftwareMechanic> Doesn't look like it does
15 2014-04-08 00:14:56 <sipa> block explorer is ancient
16 2014-04-08 00:15:12 <SoftwareMechanic> what one do you recommend?
17 2014-04-08 00:15:21 <SoftwareMechanic> It's just what turned up on google.
18 2014-04-08 00:15:22 <sipa> use a wallet that supports p2sh, send to it, see if the funds arrive
19 2014-04-08 00:16:29 <SoftwareMechanic> I'm creating raw transactions through bitcoind command line
20 2014-04-08 00:17:01 <SoftwareMechanic> was going verify my script is correct by seeing if online blockchain browers liked it
21 2014-04-08 00:17:18 <sipa> the first rule of bitcoin is: do not trust online blockchain explorer
22 2014-04-08 00:17:25 <SoftwareMechanic> good to know
23 2014-04-08 00:19:39 <gmaxwell> sipa: interesting: the flush&reload attack on the openssl scalar multiply for some characteristic 2 implementation leaked the key with only a _single_ signing operation. (OpenSSL's fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4b7a4ba29cafa432fc4266fe6e59e60bc1c96332 )
24 2014-04-08 00:21:06 <sipa> gmaxwell: interesting
25 2014-04-08 00:21:21 <sipa> gmaxwell: the nist p256 code also uses tricks like that
26 2014-04-08 00:23:45 <SoftwareMechanic> Does bitcoin-qt support p2sh?
27 2014-04-08 00:24:17 <sipa> yes
28 2014-04-08 00:24:43 <sipa> (but to receive to a p2sh key, you need all keys of it)
29 2014-04-08 00:25:32 <SoftwareMechanic> yes, that's what I'm experimenting with. I have bitcoind signing one of the inputs, and some other code adding the other tx_input
30 2014-04-08 00:26:19 <justanot1eruser> airbreather: doublespend
31 2014-04-08 00:31:20 <airbreather> justanot1eruser, to answer the original question, yes I think that's the idea. still not sure what you're specifically trying to accomplish with it though
32 2014-04-08 00:41:19 <airbreather> off-the-top, anyone have a list of really cool things that exist in the testnet3 chain that I should make sure my super-WIP alternative client handles?
33 2014-04-08 00:41:48 <airbreather> (just to make sure it's not reporting false successes)
34 2014-04-08 00:43:49 <justanot1eruser> airbreather: make tx spending to address X with 0 fees, make tx spending to address Y with regular fees, make tx X_child with 2x regular fees, and win the doublespend every time Eligius mines a block
35 2014-04-08 03:22:27 <todam00n> you guys read about that openssl bug?
36 2014-04-08 03:22:53 <aynstein> can you be more specific (a link perhaps?)
37 2014-04-08 03:23:34 <todam00n> tldr: https://news.ycombinator.com/item?id=7549943 long text: http://heartbleed.com/
38 2014-04-08 03:24:02 <todam00n> I assume it's a newbie mistake
39 2014-04-08 03:24:16 <Luke-Jr> newbie mistake?
40 2014-04-08 03:24:22 <todam00n> but if it slipped pass openssl, it's a bit worrying
41 2014-04-08 03:24:47 <todam00n> beginner's mistake
42 2014-04-08 03:25:16 <todam00n> trusted user input on a memcopy if I understand correctly
43 2014-04-08 03:25:28 <aynstein> we know what a newbie mistake is, but how do you mean?
44 2014-04-08 03:26:47 <aynstein> lexa minda a quick pm about your cloak?
45 2014-04-08 03:30:34 <Lexa> aynstein: sure :)
46 2014-04-08 04:23:45 <dgenr8> anything to be careful of when adding data to an rpc output JSON format?
47 2014-04-08 04:24:38 <dgenr8> should I add after siblings?
48 2014-04-08 04:28:19 <dgenr8> or amidst siblings where it makes sense?
49 2014-04-08 04:40:55 <todam00n> dgenr8: you are modifying bitcoind's rpc output?
50 2014-04-08 04:42:26 <todam00n> dgenr8: you could possibly put your data under a key that is likely unique {.... "dgenr8": { your data } }
51 2014-04-08 04:42:33 <todam00n> the order of keys does not matter in JSON
52 2014-04-08 04:53:58 <warren> anyone use bitcore?
53 2014-04-08 04:54:17 <vetch> warren: depends what you're asking.
54 2014-04-08 04:54:25 <warren> in general
55 2014-04-08 04:54:31 <vetch> yes.
56 2014-04-08 04:56:10 <todam00n> warren: yes
57 2014-04-08 04:56:26 <todam00n> writing an app with it at the moment
58 2014-04-08 04:57:08 <warren> I'm implementing regtest mode
59 2014-04-08 04:57:14 <warren> for bitcore and insight
60 2014-04-08 04:57:38 <todam00n> good
61 2014-04-08 04:58:02 <todam00n> I'm trying to figure out how to do the initial blocks download using p2p
62 2014-04-08 04:58:13 <todam00n> instead of RPC/block files
63 2014-04-08 04:58:45 <justanot1eruser> Does Bitcoin run using local javascript?
64 2014-04-08 04:58:58 <justanot1eruser> *Bitcore
65 2014-04-08 04:59:03 <todam00n> justanot1eruser: yes, with node.js
66 2014-04-08 04:59:16 <todam00n> justanot1eruser: there is also a browser build
67 2014-04-08 04:59:28 <justanot1eruser> Is there an alternative that doesn't use node.js?
68 2014-04-08 04:59:46 <Luke-Jr> is there any reason a P2SH can't be a null script?
69 2014-04-08 05:00:37 <justanot1eruser> Luke-Jr: Since Eligius takes child-pays-for-parent transactions, can I give it a no-fee transaction that will only be payed for when it's child pays for it?
70 2014-04-08 05:00:49 <justanot1eruser> Or will the no-fee tx be discarded
71 2014-04-08 05:01:19 <Luke-Jr> justanot1eruser: undefined
72 2014-04-08 05:01:48 <todam00n> justanot1eruser: what do you mean? a javascript alternative that doesn't use node.js / browser? I doubt there is
73 2014-04-08 05:02:15 <justanot1eruser> todam00n: preferrably not js at all
74 2014-04-08 05:02:24 <justanot1eruser> but definately not using node.js
75 2014-04-08 05:02:37 <warren> uint256("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943")); from Bitcoin Core for Testnet
76 2014-04-08 05:02:49 <warren> genesisBlock: {
77 2014-04-08 05:02:50 <todam00n> justanot1eruser: ah sure.. there is bitcoinj in java and btcd in go.. and a few others
78 2014-04-08 05:02:50 <warren> hash: hex('43497FD7F826957108F4A30FD9CEC3AEBA79972084E90EAD01EA330900000000'),
79 2014-04-08 05:03:01 <justanot1eruser> s/easy/convenient
80 2014-04-08 05:03:01 <justanot1eruser> until then, I will use python or c++ with the json rpc, but that isn't as easy as bitcore
81 2014-04-08 05:03:04 <todam00n> justanot1eruser: there is also an haskell implemtentation IIRC
82 2014-04-08 05:03:06 <warren> what the easiest way to convert that number to this other format?
83 2014-04-08 05:03:20 <warren> oh, duh, it's just backwards
84 2014-04-08 05:04:19 <todam00n> warren: maybe bitcore.util.formatHashFull(bitcore.networks.genesisBlock.hash) ?
85 2014-04-08 05:04:27 <justanot1eruser> todam00n: do they have their own implementation, or do they use the json rpc?
86 2014-04-08 05:04:43 <todam00n> justanot1eruser: own implementation
87 2014-04-08 05:05:05 <todam00n> justanot1eruser: it's probably safer to only connect to a trusted bitcoind peer though as they haven't been tested as much as bitcoind
88 2014-04-08 05:06:04 <todam00n> justanot1eruser: and bitcoind will only relay valid blocks
89 2014-04-08 05:08:03 <todam00n> how does bitcoind "know" that it should stop sending getblocks message during the initial sync?
90 2014-04-08 05:10:08 <vetch> todam00n: knowing if you are up to sync is hard. I'm guessing it queries it's peers for their height.
91 2014-04-08 05:10:10 <Luke-Jr> can someone check my work? I expect 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy to be an anyone-can-spend P2SH..
92 2014-04-08 05:11:00 <todam00n> vetch: right
93 2014-04-08 05:11:24 <vetch> Luke-Jr: why the hell would you want that? even if you are the first unannounced spend an orphaned block can screw you over.
94 2014-04-08 05:13:12 <vetch> todam00n: if every peer connected is lying then you have no hope. the peer selection is designed to avoid connecting to close IPs to prevent that situation.
95 2014-04-08 05:14:41 <Luke-Jr> vetch: wiki example address
96 2014-04-08 05:14:49 <todam00n> Luke-Jr: pay to anyone? what is the original script? just empty or OP_TRUE?
97 2014-04-08 05:14:56 <Luke-Jr> todam00n: just empty
98 2014-04-08 05:15:23 <Luke-Jr> fashoned after https://en.bitcoin.it/wiki/Script#Anyone-Can-Spend_Outputs
99 2014-04-08 05:17:40 <Luke-Jr> vetch: the idea is: 1) have the wiki example address be P2SH so that people implementing stuff should be aware addresses don't all begin with 1; 2) if someone does pay to it, the bitcoins aren't lost forever
100 2014-04-08 05:17:52 <Luke-Jr> (nor go to any specific entity)
101 2014-04-08 05:31:47 <todam00n> Luke-Jr: ok, getting 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
102 2014-04-08 05:32:06 <todam00n> with bitcore https://gist.github.com/10094350
103 2014-04-08 05:32:48 <Luke-Jr> is fromHumanReadable right?
104 2014-04-08 05:33:12 <todam00n> yeah actually var hash = bitcoreUtil.sha256ripe160(''); outputs the same thing
105 2014-04-08 06:07:02 <Luke-Jr> ACTION pokes lechuga_
106 2014-04-08 06:19:52 <Luke-Jr> wumpus: ping
107 2014-04-08 06:24:21 <wumpus> pong
108 2014-04-08 06:43:14 <wumpus> gitian descriptors for if you want to build with openssl 1.0.1g: https://github.com/bitcoin/bitcoin/pull/4023
109 2014-04-08 07:01:28 <warren> hmm, how do I find the merkle_root of the regtest genesis block?
110 2014-04-08 07:01:40 <wumpus> chainparams.cpp?
111 2014-04-08 07:02:12 <warren> hash only the block hash
112 2014-04-08 07:02:14 <warren> has*
113 2014-04-08 07:02:19 <wumpus> bleh
114 2014-04-08 07:03:00 <warren> for some reason bitcore wants it for its own chainparams. I'm trying to add regtest to it.
115 2014-04-08 07:03:08 <Luke-Jr> wumpus: am I missing something? OpenSSL bug shouldn't affect us..
116 2014-04-08 07:03:32 <Luke-Jr> ACTION checks email first
117 2014-04-08 07:03:47 <warren> Luke-Jr: should affect at least rpcssl
118 2014-04-08 07:03:53 <Luke-Jr> ah
119 2014-04-08 07:03:57 <Luke-Jr> forgot we had that XD
120 2014-04-08 07:04:01 <warren> yeah
121 2014-04-08 07:04:01 <wumpus> Luke-Jr: dunno, some people are quite paranoid about it, doesn't hurt to update it just in case
122 2014-04-08 07:04:24 <wumpus> indeed, rpc ssl could be mitmed or something?
123 2014-04-08 07:04:27 <Luke-Jr> wumpus: meh, I wouldn't make it a special release though
124 2014-04-08 07:04:27 <warren> so uh... genesis block ...
125 2014-04-08 07:04:38 <wumpus> Luke-Jr: well I want to do a 0.9.1 anyway
126 2014-04-08 07:04:40 <Luke-Jr> we already tell people never to use RPC over the internet
127 2014-04-08 07:04:42 <Luke-Jr> sure
128 2014-04-08 07:04:51 <Luke-Jr> just saying.. doesn't make sense to do it just for this one minor thing
129 2014-04-08 07:04:58 <wumpus> so it would have that + pretty much all GUI changes since 0.9 + some other fixes
130 2014-04-08 07:05:00 <wumpus> right
131 2014-04-08 07:05:01 <SomeoneWeird> well, the rest of the internet is panicing
132 2014-04-08 07:05:09 <SomeoneWeird> so maybe it should be an exception?
133 2014-04-08 07:05:12 <SomeoneWeird> iunno
134 2014-04-08 07:05:24 <Luke-Jr> if anything, releasing for it is like saying "yes, bitcoin was vulnerable"
135 2014-04-08 07:05:25 <Luke-Jr> <.<
136 2014-04-08 07:05:50 <wumpus> but if we can't say for sure it's better to err on the safe side Luke-Jr
137 2014-04-08 07:06:31 <wumpus> well at least from a technical perspective
138 2014-04-08 07:06:36 <Luke-Jr> wumpus: well, considering the extremely narrow scope of the fix.. I think we can say for sure, minus the RPC thing
139 2014-04-08 07:06:37 <wumpus> as for PR, mehh
140 2014-04-08 07:07:34 <wumpus> another reason to get 0.9! :o
141 2014-04-08 07:07:45 <warren> any recommendation for a tool that reads the raw genesis block from blk00000.dat and can print out the merkle root?
142 2014-04-08 07:08:12 <wumpus> warren: easiest would probably be to patch bitcoind to log it on startup or so
143 2014-04-08 07:08:23 <warren> ah
144 2014-04-08 07:08:58 <wumpus> you could of course write a specific tool, which is educative but that will likely cost more time
145 2014-04-08 07:09:17 <warren> I'm sure tools already exist that read blocks.
146 2014-04-08 07:09:25 <vetch> isn't the genesis block only in the code, not in the blocks?
147 2014-04-08 07:09:31 <wumpus> oh of course
148 2014-04-08 07:09:36 <wumpus> vetch: yep!
149 2014-04-08 07:10:04 <vetch> warren: you literally can't read the genesis block from disk.
150 2014-04-08 07:10:24 <wumpus> you could request the block data through RPC
151 2014-04-08 07:10:37 <wumpus> ... I think
152 2014-04-08 07:10:51 <vetch> I seem to remember that you can't
153 2014-04-08 07:10:51 <wumpus> (would be strange if that ignored the genesis too)
154 2014-04-08 07:10:55 <wumpus> LOL okay
155 2014-04-08 07:11:47 <vetch> I think for all intents it's completely invalid. its transaction isn't in the unspent pool, I know that.
156 2014-04-08 07:12:18 <Luke-Jr> eh, pretty sure we write the genesis block to disk
157 2014-04-08 07:12:28 <warren> yes, it's in that file
158 2014-04-08 07:12:34 <Luke-Jr> I remember at one point it was appending to the blk*.dat file every time you ran test_bitcoin <.<
159 2014-04-08 07:13:14 <vetch> hm. must be documented somewhere that it isn't, otherwise I wouldn't have thought it.
160 2014-04-08 07:13:16 <warren> I see the string "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in blk00000.dat
161 2014-04-08 07:13:35 <warren> wumpus: nope, doesn't work for genesis
162 2014-04-08 07:13:52 <wumpus> it doesn't? I'm trying:
163 2014-04-08 07:14:03 <warren> trying on 0.9.0 with -regtest
164 2014-04-08 07:14:04 <wumpus> getblockhash 0 -> 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
165 2014-04-08 07:14:12 <jcorgan> the genesis block is on disk, but if you ask for the transaction, it will fail
166 2014-04-08 07:14:20 <wumpus> getblock 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 -> does show output
167 2014-04-08 07:14:24 <warren> oh weird
168 2014-04-08 07:14:28 <warren> gave me an error last time
169 2014-04-08 07:14:29 <wumpus> "merkleroot" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
170 2014-04-08 07:14:31 <wumpus> there you are
171 2014-04-08 07:14:38 <warren> ok thanks
172 2014-04-08 07:14:43 <wumpus> lesson learned: please try things instead of guessing whether they work
173 2014-04-08 07:14:45 <wumpus> :P
174 2014-04-08 07:14:54 <warren> I might have fat fingered it
175 2014-04-08 07:16:04 <vetch> alright, so the spend isn't in the pool, but the block is on disk and does return data (could have sworn it didn't at some point).
176 2014-04-08 07:16:49 <warren> merkle_root is the same as testnet
177 2014-04-08 07:16:55 <wumpus> vetch: I also remembered that it wasn't on disk
178 2014-04-08 07:17:08 <warren> ... which I should have guessed from the spec
179 2014-04-08 07:17:51 <Luke-Jr> my office. so hot.
180 2014-04-08 07:17:53 <Luke-Jr> :x
181 2014-04-08 07:18:11 <vetch> predictably, getting information on the genesis block transaction fails.
182 2014-04-08 07:18:19 <Luke-Jr> and I don't even have miners running here
183 2014-04-08 07:18:27 <Luke-Jr> vetch: there is no such transaction :P
184 2014-04-08 07:18:35 <vetch> Luke-Jr: exactly
185 2014-04-08 07:18:46 <warren> maybe Satoshi will fix the unspendable genesis bug in a mandatory hardfork one day
186 2014-04-08 07:18:55 <Luke-Jr> and we'll all NACK it
187 2014-04-08 07:19:11 <xeroc> lol
188 2014-04-08 07:21:25 <vetch> warren: weird that its not on the hardfork wishlist actually.
189 2014-04-08 07:22:49 <warren> maybe the mysterious creator of Litecoin will want it spend it too one day
190 2014-04-08 07:24:11 <Luke-Jr> vetch: why would we wish it?
191 2014-04-08 07:24:20 <vetch> sounds like its time for me to make SpendableGenesisBlockCoin and shake the altcoin world to pieces.
192 2014-04-08 07:25:15 <vetch> Luke-Jr: sarcastic really. probably more risk to fix it and introduce more unknowns. only really hurts altcoins who forked off back in 0.6 anyway.
193 2014-04-08 07:25:19 <warren> vetch: wouldn't work, the alt coins have mandatory hardforks all the time to fix their last mistake
194 2014-04-08 07:25:20 <wumpus> vetch: because it doesn't have enough advantages to even start a serious discussion about it :p
195 2014-04-08 07:25:43 <warren> (none of which fix their first mistake, creating it)
196 2014-04-08 07:26:38 <vetch> I concede, SpendableGenesisBlockCoin is dead before I even cloned the repo.
197 2014-04-08 07:26:49 <wumpus> if you could do one wish, would you wish that the poor Satoshi had 50 more coins?
198 2014-04-08 07:27:39 <wumpus> though I suppose you could sell the genesis block coins for much more than that, for novelty value
199 2014-04-08 07:29:04 <warren> that would ruin its novelty value
200 2014-04-08 07:30:23 <vetch> birthday messages signed by the genesis block address. 0.5BTC each. don't need the hardfork patch and you'd make bank.
201 2014-04-08 07:37:20 <venzen> wumpus: i see you've announced gitian updates to fix the OpenSSL vulnerability. The oonly place the Core uses openssl is if users create a cert for use with -rpcssl, right? Or is TLS used elsewhere?
202 2014-04-08 07:37:48 <vetch> venzen: that's it.
203 2014-04-08 07:38:04 <wumpus> SSL (https) can also be used to fetch payment requests, but yes that's basically it
204 2014-04-08 07:38:32 <wumpus> the bitcoin protocol itself isn't affected by it
205 2014-04-08 07:38:53 <warren> wumpus: what else would we include in this release, the static build?
206 2014-04-08 07:39:04 <venzen> wumpus: thank you, and i liked this: https://bitcoinfoundation.org/blog/?p=677
207 2014-04-08 07:39:05 <warren> wumpus: cfields said he's very close to finishing the filter symbols
208 2014-04-08 07:40:03 <kuzetsa> venzen: openssl 1.0.1g also fixes CVE-2014-0076 which affects a sidechannel attack used for ECDSA keys (and explicitly affects bitcoin)
209 2014-04-08 07:40:16 <warren> wumpus: oh, congrats!
210 2014-04-08 07:40:37 <wumpus> warren: yes, and gui/documentation updates, and some fixes
211 2014-04-08 07:41:07 <wumpus> a lot of stuff merged into master post-0.9 could go perfectly safely into a 0.9.1
212 2014-04-08 07:41:13 <warren> yup
213 2014-04-08 07:41:17 <venzen> kuzetsa: oh-hoo... that sounds dangerous: "sidechannel" attack
214 2014-04-08 07:41:36 <warren> wumpus: how much time for QA do you want to have given that the vulnerability isn't that bad for bitcoin?
215 2014-04-08 07:41:56 <wumpus> I'll also cherry-pick theuni's preparation stuff for macosx gitian build (which happens outside the tree, but a few changes to upstream are needed)
216 2014-04-08 07:42:02 <warren> wumpus: is anything post-0.9 really bad enough to not just fork from master again?
217 2014-04-08 07:42:23 <wumpus> warren: just the normal rc cycle, I suppose
218 2014-04-08 07:42:52 <warren> I mean the things that are too risky are probably the minority (just revert it)
219 2014-04-08 07:43:00 <wumpus> warren: I don't completely trust the latest change to networking yet
220 2014-04-08 07:43:10 <wumpus> warren: so no, I won't fork 0.9.1 from master
221 2014-04-08 07:43:11 <warren> or pick a point in master to fork
222 2014-04-08 07:43:18 <warren> if not HEAD
223 2014-04-08 07:43:23 <wumpus> I'm going to cherry-pick, as linus intended
224 2014-04-08 07:43:28 <warren> ok
225 2014-04-08 07:43:29 <wumpus> :P
226 2014-04-08 07:43:44 <warren> just saying because doing so might allow translations to be used immediately
227 2014-04-08 07:43:53 <wumpus> I will do a transifex pull
228 2014-04-08 07:44:04 <warren> when's the last time tx source was synced?
229 2014-04-08 07:44:09 <wumpus> a long time ago
230 2014-04-08 07:44:18 <warren> 3 weeks prior to 0.9 right?
231 2014-04-08 07:44:24 <wumpus> long enough ago to be usable as-is for 0.9
232 2014-04-08 07:44:29 <warren> oh
233 2014-04-08 07:48:14 <wumpus> oh, and I'm going to pull (almost) all GUI changes anyway, so the messages should be pretty much in sync with master after 0.9.1
234 2014-04-08 07:48:29 <warren> wumpus: given that none of the 3rd party tools seem to support regtest yet, would folks be against changing its address version?
235 2014-04-08 07:48:44 <wumpus> warren: I have no opinion on that
236 2014-04-08 07:48:51 <warren> wumpus: err, won't that break the 0.9.0 translations?
237 2014-04-08 07:49:00 <warren> that's been transifex source for a long time
238 2014-04-08 07:49:17 <wumpus> huh, transifex source is no longer master?
239 2014-04-08 07:49:35 <kuzetsa> venzen: well considering a whitepaper was published explicitly explaining how this sidechannel vulnerability could be exploited to steal bitcoin keys... yes, it's dangerous ---> http://eprint.iacr.org/2014/161.pdf
240 2014-04-08 07:49:38 <warren> checking
241 2014-04-08 07:49:40 <wumpus> why do people never tell me anything?
242 2014-04-08 07:49:55 <warren> oh, transifex source last sync was March 21st
243 2014-04-08 07:50:04 <wumpus> how can I do my job as maintainer if I have to learn everything in a sideways IRC discussion?
244 2014-04-08 07:50:06 <warren> although it isn't clear with what
245 2014-04-08 07:50:11 <wumpus> ok, so it does pick it from master
246 2014-04-08 07:50:24 <warren> that's the opposite of what you said earlier
247 2014-04-08 07:50:41 <wumpus> no, it's not?
248 2014-04-08 07:50:45 <kuzetsa> like I said, openssl 1.0.1g also fixes CVE-2014-0076 (as described in that whitepaper)
249 2014-04-08 07:51:51 <warren> you said the transifex sources were not updated for a long time
250 2014-04-08 07:52:02 <wumpus> 3 weeks is a long time
251 2014-04-08 07:52:29 <warren> would it be bad to have it auto-sync?
252 2014-04-08 07:52:40 <warren> you can set a URL for it to grab once a day
253 2014-04-08 07:52:51 <wumpus> (and yes, in my thoughts it was longer than that, but so much happens from day-to-day that 3 weeks is a long time...)
254 2014-04-08 07:53:07 <wumpus> it auto-syncs from master
255 2014-04-08 07:53:16 <warren> oh, hasn't changed since then
256 2014-04-08 07:53:20 <wumpus> right
257 2014-04-08 07:53:28 <warren> and it would later auto-sync from <script that merges branches>
258 2014-04-08 07:53:36 <wumpus> yes
259 2014-04-08 07:53:40 <warren> sounds great
260 2014-04-08 07:56:03 <wumpus> so our official starting point for that plan will be 0.9.1, not 0.9.0
261 2014-04-08 07:56:42 <wumpus> (or, in general, the latest 0.9.x release)
262 2014-04-08 07:58:23 <wumpus> messages that exist in the latest stable release should never be dropped from transifex
263 2014-04-08 07:58:48 <warren> excellent
264 2014-04-08 07:58:49 <wumpus> ...unless there is a new stable release
265 2014-04-08 07:59:33 <warren> if the merging script is smart enough, strings from master (already translated) can have the same id in the merged new stable, so it won't need re-translation
266 2014-04-08 07:59:46 <venzen> kuzetsa: thanks for that - i will definitely read and inform myself. However, I am writing a news announcement about the Heartbeat bug (CVE-2014-0160) and will omit any reference to CVE-2014-0076 (affecting ECDSA) because it will just cause hysteria in the community and Bitcoiners running around like headless chickens all over IRC :D
267 2014-04-08 08:01:56 <Luke-Jr> warren: I have a small collection of scripts I've used for previous stable releases
268 2014-04-08 08:03:43 <warren> wumpus: the reason I ask about a different address version for regtest, bitcore checks the address version (and other versions) of things like addresses to guess what network it is. currently testnet and regtest are identical in this regard so it can't differentiate them.
269 2014-04-08 08:03:44 <wumpus> warren: there aren't really ids; messages in qt are matched by contents, and an optional context (which is usually the class name)
270 2014-04-08 08:04:05 <warren> oooh
271 2014-04-08 08:04:07 <Luke-Jr> http://codepad.org/z2WXkZho tsproc.xsl=http://codepad.org/UsQUdPPm tsmerge.py=http://codepad.org/TEv2kMPo
272 2014-04-08 08:04:09 <wumpus> I suppose transifex uses the same matching, so it shouldn't give any troubhle
273 2014-04-08 08:05:15 <wumpus> warren: but I doubt in howsofar that's an issue, regtest isn't really meant for general use, usually it can be considered 'just a local testnet' like the testnet-in-a-box befoer
274 2014-04-08 08:05:28 <wumpus> there is no use in speaking of 'the regtest network'
275 2014-04-08 08:05:57 <warren> wumpus: it matters to things that want to test synthetic reorg behavior for 3rd party apps that use bitcore to interface bitcoind
276 2014-04-08 08:06:02 <wumpus> addreses hence only make sense in the context of an instance of the regtest network, even within one regression test
277 2014-04-08 08:06:32 <warren> not disagreeing, just the way they wrote the code is making it non-trivial to add regtest because of this "guess"
278 2014-04-08 08:07:17 <wumpus> (ideally there'd be an 'instance id' in addresses that uniquely identifies a chain, and each new regtest instance gets a new chain id... but bitcoin addresses have only one version byte, and this is for testing so it's not worth designing a new standard for)
279 2014-04-08 08:07:20 <Luke-Jr> tsmerge.py basically looks for close-matches of strings
280 2014-04-08 08:07:50 <warren> If all of the genesis of regtest were identical with testnet this would be less of an issue.
281 2014-04-08 08:07:53 <warren> It isn't.
282 2014-04-08 08:08:29 <wumpus> btw, bitcoin-qt has one of those guesses as well, when providing a bitcoin URI on the command line
283 2014-04-08 08:08:56 <Luke-Jr> wumpus: can 0.9.1 please fix testnet-in-a-box btw? :P
284 2014-04-08 08:09:00 <wumpus> so yes it would be marginally better to be able to identify it from the address
285 2014-04-08 08:09:04 <wumpus> Luke-Jr: no
286 2014-04-08 08:09:06 <Luke-Jr> â¦
287 2014-04-08 08:09:10 <warren> Luke-Jr: regtest is a lot better than testnet-in-a-bo
288 2014-04-08 08:09:18 <Luke-Jr> warren: not if you're trying to test mining
289 2014-04-08 08:09:19 <wumpus> Luke-Jr: I only merge things into 0.9.1 that are already in master
290 2014-04-08 08:09:35 <Luke-Jr> wumpus: yeah, obviously someone needs to implement a fix too <.<
291 2014-04-08 08:09:37 <wumpus> Luke-Jr: there is no fix for testnet-in-a-box in master, so I must answer no
292 2014-04-08 08:09:49 <warren> annoyingly, electrum lacks testnet support and a request to add it was turned down with "I don't see why this is needed."
293 2014-04-08 08:10:12 <wumpus> warren: I'd say... make a (short) proposal for new address bytes for regtest and post it to the mailing list
294 2014-04-08 08:10:28 <warren> wumpus: so the regtest URL would begin with regtest: I guess.
295 2014-04-08 08:10:29 <Luke-Jr> ACTION suggests 42 and 0x42
296 2014-04-08 08:10:47 <warren> Luke-Jr: what would the first symbol be?
297 2014-04-08 08:10:48 <wumpus> warren: note that you need not one but several, also for the different kinds of addresses (P2SH)
298 2014-04-08 08:10:55 <Luke-Jr> warren: shrug
299 2014-04-08 08:10:57 <warren> i know
300 2014-04-08 08:10:59 <wumpus> warren: no, all bitcoin uris start with bitcoin:
301 2014-04-08 08:11:06 <warren> ok
302 2014-04-08 08:11:06 <warren> ooooh
303 2014-04-08 08:11:35 <wumpus> warren: the distinction is based on the address version (did you read my above "btw, bitcoin-qt has one of those guesses as well, when providing a bitcoin URI on the command line")
304 2014-04-08 08:11:45 <Luke-Jr> 42 = H or J
305 2014-04-08 08:11:59 <Luke-Jr> 0x42 = T
306 2014-04-08 08:12:11 <warren> is there a symbol that is only R?
307 2014-04-08 08:12:15 <warren> that would make a lot of sense ...
308 2014-04-08 08:12:31 <Luke-Jr> 60 and 61
309 2014-04-08 08:12:50 <Luke-Jr> 122 and 123 for lowercase
310 2014-04-08 08:12:58 <Luke-Jr> https://en.bitcoin.it/wiki/List_of_address_prefixes
311 2014-04-08 08:13:01 <warren> Do we want R or r?
312 2014-04-08 08:13:15 <Luke-Jr> warren: well, we need one for pkh and one for sh
313 2014-04-08 08:13:15 <warren> what color would you like the bikeshed?
314 2014-04-08 08:13:43 <Luke-Jr> personally, I'd prefer regtest to use the same as testnet since it's not a global scope
315 2014-04-08 08:13:46 <wumpus> that page doesn't even mention P2SH?
316 2014-04-08 08:13:47 <Luke-Jr> but I don't care to argue
317 2014-04-08 08:14:04 <Luke-Jr> 5
318 2014-04-08 08:14:21 <warren> Luke-Jr: it's a pain for code that guesses the network from the address
319 2014-04-08 08:14:27 <wumpus> oh, right
320 2014-04-08 08:14:55 <Luke-Jr> warren: indeed. but regtest isn't a network.
321 2014-04-08 08:15:07 <wumpus> Luke-Jr: read above, I explained that to him too
322 2014-04-08 08:15:20 <warren> bitcore sets the network params from the guesses sometimes
323 2014-04-08 08:15:40 <warren> the code could be rewritten to not do that
324 2014-04-08 08:16:00 <wumpus> why does it guess based on an address?
325 2014-04-08 08:17:45 <warren> looking
326 2014-04-08 08:19:36 <wumpus> in any case, you could still make the proposal and see if people agree, it's not like we are running out of address versions any time soon
327 2014-04-08 08:20:18 <wumpus> (not for bitcoin, at least, and altcoins are stupid if they don't take the oppertunity to design a new and better address scheme)
328 2014-04-08 08:20:52 <warren> it contains various utility functions that returns various things identifying the network based upon an arbitrary input, much of which doesn't seem to be used within bitcore itself, probably by other apps that use bitcore
329 2014-04-08 08:21:06 <warren> so changing this in bitcore to support regtest would mean editing arbitrary other apps too
330 2014-04-08 08:22:51 <warren> Luke-Jr: how do you set pkh and sh separately?
331 2014-04-08 08:23:41 <warren> mm
332 2014-04-08 08:31:00 <warren> I'll ask jgarzik before making any proposal.
333 2014-04-08 08:35:00 <Luke-Jr> wumpus: I take back my former disinterest in 0.9.1-ASAP if the vuln does affect the client side.. that would mean we could leak ECDSA privkey data :x
334 2014-04-08 08:35:30 <Luke-Jr> in fact, if that's the case, I'd suggest sending an alert out to not use the payment protocol
335 2014-04-08 08:35:37 <Luke-Jr> wumpus: do you have the alert key?
336 2014-04-08 08:35:47 <warren> Luke-Jr: oh crap, forgot about client side
337 2014-04-08 08:35:47 <wumpus> I'm not sure I understand you
338 2014-04-08 08:35:50 <warren> ...
339 2014-04-08 08:35:52 <warren> wumpus: he's right
340 2014-04-08 08:35:53 <wumpus> how would you concretely exploit this?
341 2014-04-08 08:36:02 <warren> wumpus: you would need a hostile server
342 2014-04-08 08:37:25 <wumpus> so are we sure that it can also be exploited client side?
343 2014-04-08 08:38:15 <Luke-Jr> wumpus: that's how I interpreted what you said
344 2014-04-08 08:38:18 <wumpus> I really want gavin and the rest involved before sending around an alert
345 2014-04-08 08:38:42 <Luke-Jr> we need to be sure if it does or doesn't affect client side. if it does, an alert is prudent.
346 2014-04-08 08:39:40 <wumpus> well don't take *my* word on that, I haven't studied the vulnerability at all, have been working on upgrading gitian and going through the commit list after waking up with panicked mails in my mailbox
347 2014-04-08 08:40:17 <wumpus> note that I word it carefully: it *may* affect this and this, I don't express certainty
348 2014-04-08 08:41:20 <Luke-Jr> ACTION wishes we had some kind of isolation between wallet and everything else
349 2014-04-08 08:41:31 <wumpus> we're working on that
350 2014-04-08 08:41:49 <wumpus> headers-first needs to go in, after that I can make a bitcoin-qt-spv
351 2014-04-08 08:43:08 <wumpus> not that that would help much, people would still want to use SSL to talk to the wallet ...
352 2014-04-08 08:44:45 <wumpus> a better idea would be to have the *private keys and signing* in a seperate isolated process, not so much the entire wallet
353 2014-04-08 08:45:29 <wumpus> it could then run on a seperate chip/trusted computing domain/whatever
354 2014-04-08 08:45:49 <warren> awesome
355 2014-04-08 08:46:04 <Luke-Jr> wumpus: SPV is not isolation from GUI.
356 2014-04-08 08:46:07 <wumpus> not that any cross-OS API exists for such things, mind you
357 2014-04-08 08:46:19 <Luke-Jr> private keys and signing = wallet :P
358 2014-04-08 08:46:22 <wumpus> Luke-Jr: you didn't say isolation from GUI, but isolation from wallet
359 2014-04-08 08:46:35 <Luke-Jr> wallet isolated from *everything else* :P
360 2014-04-08 08:46:38 <wumpus> Luke-Jr: no, the wallet is the entire part that listens for transactions as well
361 2014-04-08 08:47:00 <wumpus> you wouldn't need to run the essentially watchonly part of the wallet in the trusted domain
362 2014-04-08 08:47:25 <Luke-Jr> http://www.reddit.com/r/programming/comments/22ghj1/the_heartbleed_bug/cgmzakx
363 2014-04-08 08:47:26 <Luke-Jr> crap
364 2014-04-08 08:50:14 <Luke-Jr> wumpus: these logs are public. can we get ahold of Gavin and whoever else in the next few hours?
365 2014-04-08 08:51:07 <gjs278> yeah I was just going to say, any exploit is going to get noticed
366 2014-04-08 08:51:24 <warren> Luke-Jr: so 0.8.7 without payment protocol (and rpcssl disabled by default) has any attack surface?
367 2014-04-08 08:51:30 <warren> I can't think of any.
368 2014-04-08 08:51:43 <Luke-Jr> warren: shouldn't
369 2014-04-08 08:51:44 <wumpus> warren: why not just upgrade openssl?
370 2014-04-08 08:51:53 <wumpus> speaking of that, can anyone help testing and ACK https://github.com/bitcoin/bitcoin/pull/4023 ?
371 2014-04-08 08:52:16 <warren> wumpus: I had an issue earlier trying to verify the GPG key of that
372 2014-04-08 08:52:34 <warren> wumpus: the GPG key of that source tarball wasn't on key servers earlier today =(
373 2014-04-08 08:52:37 <warren> it seems to be now
374 2014-04-08 08:52:43 <wumpus> warren: good news: 0.8 doesn't have payment protocol yet
375 2014-04-08 08:53:12 <wumpus> so it's just a matter of disabling rpcssl
376 2014-04-08 08:59:18 <wumpus> 0.9.1 branch created with the gitian updates https://github.com/bitcoin/bitcoin/tree/0.9.1
377 2014-04-08 09:00:24 <wumpus> so mikehearn claims it affects only servers?
378 2014-04-08 09:00:28 <wumpus> is there anyone that knows for sure?
379 2014-04-08 09:00:41 <Luke-Jr> there should be, but I don't know how to reach them
380 2014-04-08 09:03:12 <wumpus> openssl.org is unreachable, probably stampeded
381 2014-04-08 09:05:03 <fanquake> noticed that :/
382 2014-04-08 09:05:18 <fanquake> ERROR: The certificate of `www.openssl.org' is not trusted.
383 2014-04-08 09:05:19 <fanquake> ERROR: The certificate of `www.openssl.org' hasn't got a known issuer.
384 2014-04-08 09:10:37 <Luke-Jr> sigh, is mikehearn using some non-standard definition of "client"? -.-
385 2014-04-08 09:12:15 <vetch> gmaxwell was talking (correcting me) about it before in #bitcoin.
386 2014-04-08 09:13:27 <Luke-Jr> vetch: ?
387 2014-04-08 09:14:23 <vetch> er that was a reply to wumpus, who asked if anybody knew the scope of the heartbleed bug for certain. I was saying that gmaxwell seems to have a good handle on it.
388 2014-04-08 09:14:54 <Luke-Jr> bleh, was hoping you were implying something else
389 2014-04-08 09:15:18 <Luke-Jr> I suppose if connecting to a TLS server doesn't automatically make you a "TLS client", then we might be okay..
390 2014-04-08 09:15:21 <Luke-Jr> but that would be very confusing
391 2014-04-08 09:17:09 <Luke-Jr> Payment protocol *does* connect to TLS servers, right? :x
392 2014-04-08 09:18:14 <wumpus> yes
393 2014-04-08 09:46:11 <michagogo> cloud|wumpus: is there a chain of servers between us?
394 2014-04-08 09:46:24 <Luke-Jr> woops, wumpus beat me to it
395 2014-04-08 09:46:39 <michagogo> cloud|wumpus: So I know the deps will need to be rebuilt
396 2014-04-08 09:46:59 <wumpus> huh, a chain of servers, how do you mean?
397 2014-04-08 09:47:08 <michagogo> cloud|But will qt-win also need to be rebuilt? (since I know it uses OpenSSL, and so requires the deps zip)
398 2014-04-08 09:47:23 <wumpus> michagogo|cloud: oh shit
399 2014-04-08 09:47:23 <wumpus> yes
400 2014-04-08 09:47:25 <michagogo> cloud|If so, should probably bump the version, no?
401 2014-04-08 09:47:48 <wumpus> why didn't anyone note this before?
402 2014-04-08 09:48:27 <woofpluf> Maybe bitcoin should be stopped for a week while this is checked out
403 2014-04-08 09:49:15 <wumpus> 'stop bitcoin' lol, as if it was that easy it wouldn't be a very robust network
404 2014-04-08 09:54:36 <olalonde> how often does bitcoind issue getBlocks messages when syncing?
405 2014-04-08 09:54:37 <michagogo> cloud|heh, I guess it did go through :P
406 2014-04-08 09:54:49 <michagogo> cloud|wumpus: I mean, an IRC route between the two of us
407 2014-04-08 09:55:18 <olalonde> every 500 blocks?
408 2014-04-08 09:55:30 <michagogo> cloud|(IRCCloud doesn't handle huge netsplits, etc very well)
409 2014-04-08 09:55:40 <shesek> is it considered unsafe to do ECDH with keys that are also used as Bitcoin keys (and receive payments)?
410 2014-04-08 09:55:57 <michagogo> cloud|So when I typed that, the split seemed to still be going on
411 2014-04-08 09:56:16 <wumpus> yep, qt dependency bump has been done, thanks for noting
412 2014-04-08 09:56:38 <michagogo> cloud|people quitting, etc, so even though you seemed to still be in here, I couldn't know if you were or if I just hadn't seen you dc yet
413 2014-04-08 09:56:56 <Luke-Jr> shesek: it's probably not a good idea
414 2014-04-08 09:57:50 <shesek> Luke-Jr, for what reason?
415 2014-04-08 09:58:16 <Luke-Jr> shesek: confusing to end users, who shouldn't be aware of keys?
416 2014-04-08 09:58:43 <Luke-Jr> and presumbly you'd need to publish the public key
417 2014-04-08 10:01:59 <woofpluf> The public key only gets published when an address actually sends funds outwards, correct?
418 2014-04-08 10:03:58 <michagogo> cloud|wumpus: what's the third commit for?
419 2014-04-08 10:04:45 <michagogo> cloud|...and the fourth? o_O
420 2014-04-08 10:05:41 <Luke-Jr> woofpluf: addresses don't send funds, the wallet does using a key.
421 2014-04-08 10:05:49 <Luke-Jr> woofpluf: by that time, the address is no longer related to it.
422 2014-04-08 10:08:28 <dexX7> is an update recommended due to the ssl vuln?
423 2014-04-08 10:08:46 <michagogo> cloud|dexX7: there isn't a release with the ssl vuln fixed yet
424 2014-04-08 10:09:06 <dexX7> rephrased: should i rebuild now?
425 2014-04-08 10:09:07 <michagogo> cloud|If you build your own binary, then yes
426 2014-04-08 10:09:19 <michagogo> cloud|No need to upgrade the code, just update openssl and qt
427 2014-04-08 10:09:29 <Luke-Jr> dexX7: if you compile yourself, you don't need to rebuild, just update openssl
428 2014-04-08 10:09:34 <michagogo> cloud|Oh, right
429 2014-04-08 10:09:36 <michagogo> cloud|Of course
430 2014-04-08 10:09:37 <dexX7> ah okay, ty
431 2014-04-08 10:09:51 <michagogo> cloud|Forgot about dynamic linking
432 2014-04-08 10:10:27 <michagogo> cloud|dexX7: (btw, in the meantime, don't use rpcssl or the payment protocol)
433 2014-04-08 10:11:14 <shesek> Luke-Jr, its part of something that I'm writing, it'll be handled in the background without the users being aware of it
434 2014-04-08 10:11:48 <shesek> so it shouldn't really confuse anyone
435 2014-04-08 10:12:04 <Luke-Jr> shesek: care to elaborate? I can't imagine how this could be useful :x