1 2014-09-30 00:47:34 <jtimon> petertodd I proposed verifying backards verification earlier, not sure if I was the first one though https://bitcointalk.org/index.php?topic=204283.msg2155915#msg2155915
 2 2014-09-30 00:48:26 <jgarzik> http://www.coindesk.com/early-bitcoin-adopter-calls-multi-sig-solutions-750-btc-theft/
 3 2014-09-30 00:48:29 <jgarzik> How???
 4 2014-09-30 00:48:36 <jgarzik> Did he not encrypt his wallet?
 5 2014-09-30 00:56:29 <jtimon> at the very least we need to move to cpp v11 before being able to away from boost, no?
 6 2014-09-30 00:57:01 <sipa> at the very least, yes
 7 2014-09-30 00:57:04 <moa> hacker was only able to remotely get read access to my home directory  (which had numerous unencrypted backups) or whether there’s a customised  root kit avoiding detection and logging my every keystroke
 8 2014-09-30 00:57:05 <moa> MacOSX
 9 2014-09-30 00:57:45 <jgarzik> No clue why people are suddenly saying "750 BTC stolen due to shellshock"
10 2014-09-30 00:57:52 <jgarzik> I don't see it
11 2014-09-30 00:58:12 <moa> mmm, might be convenient "boating accident" story for all we know
12 2014-09-30 00:58:39 <sipa> jtimon: i think gmaxwell has been proposing backward verifications for... years?
13 2014-09-30 01:01:37 <jtimon> that tends to happen with many proposals that's why I never took credit for that since that seemed kind of obvious to me
14 2014-09-30 01:02:12 <sipa> jtimon: https://en.bitcoin.it/w/index.php?title=User:Gmaxwell/Reverse_header-fetching_sync&oldid=23445
15 2014-09-30 01:05:15 <gmaxwell> it was even old when I posted that; but it needs a protocol change
16 2014-09-30 01:11:59 <Gnosis> does Bitcoin use RAND_bytes in a thread-safe manner on all platforms?
17 2014-09-30 01:12:28 <sipa> yes
18 2014-09-30 01:12:40 <sipa> openssl does its own locking
19 2014-09-30 01:12:59 <sipa> or rather, you tell openssl how to acquire locks, with help from the application
20 2014-09-30 01:14:15 <Gnosis> ah, I see. Where in the code does it tell openssl about this? I found no occurrences of CRYPTO_THREADID_set_callback
21 2014-09-30 01:14:45 <sipa> CRYPTO_set_locking_callback in util.cpp
22 2014-09-30 01:15:11 <Gnosis> ahh, thanks!
23 2014-09-30 04:41:36 <petertodd> jtimon: cool, though you're idea is a bit different than mine: I'm proposing to build up the UTXO set starting from nothing in reverse order, you're proposing to validate a untrusted UTXO set
24 2014-09-30 04:41:49 <petertodd> jtimon: but yeah, all varients of similar ideas
25 2014-09-30 04:42:59 <petertodd> jtimon: I am at least fairly confident the "catchy" name "partial UTXO set mode" or "partial mode" for short is original :P
26 2014-09-30 04:51:55 <jtimon> well, I'm saying that in the context of a committed utxo, so it's not really completely untrusted
27 2014-09-30 04:52:38 <sipa> right, seems everyone is talking about pretty different things
28 2014-09-30 04:52:48 <sipa> just shows there is a lot of potential there :)
29 2014-09-30 04:55:37 <jtimon> right, I think it would be really useful to define more "levels of validation" than full node and spv
30 2014-09-30 05:49:22 <BlueMatt> coryfields: why do we not run tests outside of x86_64?
31 2014-09-30 06:22:19 <brisque> jgarzik: the "750BTC stolen by shellshock" thing is going to need some serious FUD repellant. I spoke to the user in #bitcoin (check the log for details) at some length and to me it didn't appear to be anything like that. it's blamed without reason.
32 2014-09-30 06:24:16 <brisque> jgarzik: they were using a very old (keys were uncompressed point type, so the wallet.dat was extremely old and had never been encrypted. as far as I can find there's no suggestion that a default OSX setup has anything openly vulnerable to shellshock either.
33 2014-09-30 06:25:09 <brisque> er that sentence doesn't make sense, sorry. you get the gist though. old wallet that might have been backed up in god knows what insecure places.
34 2014-09-30 06:26:11 <benrcole> where has the loss been attributed to shellshock?
35 2014-09-30 06:26:38 <brisque> http://www.coindesk.com/early-bitcoin-adopter-calls-multi-sig-solutions-750-btc-theft/
36 2014-09-30 06:26:50 <benrcole> Doesnt thay say 'after reading about it , I checked my bitcoin' ?
37 2014-09-30 06:27:04 <benrcole> not ' because of shellshock - I lost my bitcoin?'
38 2014-09-30 06:27:38 <benrcole> granted ther'll be FUD anyway but I didnt connect the two directly…
39 2014-09-30 06:28:17 <brisque> in the lastlog it was suggested that the connection was made, but I don't know where.
40 2014-09-30 06:28:25 <benrcole> ah ok
41 2014-09-30 08:40:54 <chichov> how come that if I define in some header "extern CBasicKeyStore Store" and in the source "CBasicKeyStore Store" then it throws me a forward declaration error of class CScript?
42 2014-09-30 08:55:06 <chichov> when using simply CBasicKeyStore without the "extern" keyword everything works fine. But if I do use it, which I must, then it starts complaining when I define it
43 2014-09-30 10:15:09 <chichov> is there any difference when serializing a transaction between SER_DISK and SER_NETWORK?
44 2014-09-30 10:15:26 <phantomcircuit> sipa, ^
45 2014-09-30 10:15:36 <phantomcircuit> chichov, i dont think so.... but there's probably a reason for those
46 2014-09-30 10:20:00 <chichov> phantomcircuit: alright, thanks
47 2014-09-30 13:41:07 <maraoz> I need ~50 testnet coins to fix a bug that only happens for tx outputs > 100 btc. can anyone spare some test coins? ms53WnNZohQzXs16AssNLxFvLcKNunnEyQ (thanks)
48 2014-09-30 13:42:08 <hearn> that sounds like a job for regtest mode
49 2014-09-30 13:49:31 <maraoz> thanks to whoever sent me the coins :)
50 2014-09-30 13:49:46 <maraoz> and hearn: I'll check that, thanks!!
51 2014-09-30 16:50:00 <wumpus> chichov: no, there is no difference for transactions/blocks for SER_DISK and SER_NETWORK. Only CAddress is different between both...
52 2014-09-30 17:21:32 <gmaxwell> from the rust mailing list,
53 2014-09-30 17:21:34 <gmaxwell> "I've been told by LLVM folks that getting LLVM to do constant time code generation is essentially hopeless, and it should just be written in asm. One could start by compiling with LLVM, then hand-inspecting the output."
54 2014-09-30 17:24:38 <sipa> :(
55 2014-09-30 18:48:09 <maraoz> I'm trying to run the bitcoin.org site locally and all pages except the home page are throwing 404's. Any idea what I could be doing wrong?
56 2014-09-30 18:49:03 <maraoz> btw is it OK if I submit a PR to add Copay to https://bitcoin.org/en/choose-your-wallet or is someone in charge of doing that?
57 2014-09-30 18:58:16 <hearn> maraoz: is copay a wallet people can actually use?
58 2014-09-30 18:58:28 <hearn> maraoz: my understanding was it's basically a web app that requires a full block explorer
59 2014-09-30 18:58:39 <hearn> maraoz: if there's a hosted version then maybe. otherwise it's more a tool for sysadmins and developers
60 2014-09-30 18:59:42 <maraoz> there's a hosted demo instance: https://copay.io/
61 2014-09-30 19:09:18 <Happzz> i have my testnet wallet synced up fully, and it cant find txid N
62 2014-09-30 19:09:26 <Happzz> while test-insight.bitpay.com can see it
63 2014-09-30 19:09:37 <Happzz> my wallet can see newer txs than N, too
64 2014-09-30 19:10:16 <Happzz> error: {"code":-5,"message":"No information available about transaction"}
65 2014-09-30 19:12:45 <Happzz>     "blocks" : 282091,
66 2014-09-30 19:12:45 <Happzz> my bitcoind has     "chain" : "test",
67 2014-09-30 19:13:12 <Happzz> the tx it cant find was included in block 204292
68 2014-09-30 20:19:13 <Happzz> anyone?
69 2014-09-30 20:22:04 <sipa> Happzz: you need to run with -txindex if you want getrawtransaction to find arbitrary transactions
70 2014-09-30 20:22:12 <sipa> by default, bitcoind only keeps track of unspent transactions
71 2014-09-30 20:22:49 <sipa> and gettransaction only works for your own wallet
72 2014-09-30 20:24:44 <Happzz> k
73 2014-09-30 22:25:35 <minethisplease> 0100000004aaa93201507db60aa0fe5c4bf8136517ce9deb069c4b05aaeb145ac68df35f411c0000006b483045022100f8e75f87d5a873e84df4a13cc696f7497d5abbbef2af4422f5acb4f3abca92ae022069d5e80938805b1f94b0b9079a1154832ce1b338d5cf8b14305061071906a9a3822103a49217141374d9054471550e1027eb52acfa22bbb9d7de849483e44905b78ed6ffffffff3c59f47baa2d0525c7a0ff080543458714226a6a59169ed520217189746d01b51c0000006b483045022100e5600b54a780614dfc
74 2014-09-30 22:25:35 <minethisplease> 822103a49217141374d9054471550e1027eb52acfa22bbb9d7de849483e44905b78ed6ffffffffd770ef8ba10ba008486e135603c818ad64d0dd16f0cd5b2329d0a4f71021c8e0240000006a473044022071e97c70fc8fcf85f0970ac5feb499de2c7886524e0831a8a661b06a17e53477022018c9ad531e27ddd60c658b8726d6c77f97405188c6a85a234f7bd66e162ce7de822103a49217141374d9054471550e1027eb52acfa22bbb9d7de849483e44905b78ed6ffffffff010000000000000000016a00000000
75 2014-09-30 22:25:35 <minethisplease> b5529a0c7cca26fa0460fabb8162bd1e87d1264abf05f602203029d4995d35db78d27db87d10b81c24ad5ead7448f91281c568481fa1c2817d822103a49217141374d9054471550e1027eb52acfa22bbb9d7de849483e44905b78ed6ffffffff8914731baead7a5749245df2bce536d79319302bf449fe93a0ef7699ba3baac61f0000006b483045022100c036ad39b265adb6b9395ebc5ed356db61bada27dfd18533ba2a784bddff23ab02200738464bf831fa437932bec5fad997e26d806d30a141c5811f74011eced9c2a5
76 2014-09-30 22:37:17 <firelegend> Let me grab a pen and paper to solve those.
77 2014-09-30 23:52:05 <lechuga_> lol@new pulltester comments
78 2014-09-30 23:52:17 <lechuga_> https://github.com/TheBlueMatt/test-scripts/blob/45af728179bfc38ccd8321ab2dacfced415f829a/FullBlockTestGenerator.java#L33-L34
79 2014-09-30 23:52:25 <lechuga_> debugging those tests really isnt all that difficult
80 2014-09-30 23:53:25 <BlueMatt> lechuga_: debugging them if you break something obvious isnt, but they rarely break in an obvious way
81 2014-09-30 23:55:20 <lechuga_> i like the idea of making the consensus rules a shared library but i wonder how practical that is
82 2014-09-30 23:55:30 <BlueMatt> very practical
83 2014-09-30 23:55:35 <lechuga_> lots of things outside of acceptblock can affect consensus
84 2014-09-30 23:55:36 <BlueMatt> doing it with script only is trivial
85 2014-09-30 23:55:51 <BlueMatt> and 90% of consensus failures are script-based
86 2014-09-30 23:55:56 <lechuga_> true
87 2014-09-30 23:56:06 <BlueMatt> other things are not terribly hard to test, but even those wouldnt be /too/ hard to library-ize
88 2014-09-30 23:56:08 <lechuga_> r u still working on your shared script runner library?
89 2014-09-30 23:56:11 <BlueMatt> (even with pluggable backend)
90 2014-09-30 23:56:27 <lechuga_> would managing proper reorg behavior be out of scope?
91 2014-09-30 23:56:34 <BlueMatt> I walked away from it for a bit, mostly because jtimon is working on other refactors that make it easier
92 2014-09-30 23:56:36 <lechuga_> (for shared consensus lib)
93 2014-09-30 23:56:52 <BlueMatt> no, thats ofc consensus lib
94 2014-09-30 23:57:15 <BlueMatt> but that one is harder to do, you're right
95 2014-09-30 23:57:27 <BlueMatt> still, I think it would be doable, but would require lots more refactoring
96 2014-09-30 23:58:28 <lechuga_> anyway the comments rule :)
97 2014-09-30 23:58:45 <firelegend> lechuga_:With an iron fist!