1 2015-01-02 00:00:33 <sipa> yes
2 2015-01-02 00:00:35 <op_mul> xabbix: if you have txindex, you can gettransaction any TXID at the cost of gigabytes of indexes.
3 2015-01-02 00:00:46 <sipa> no
4 2015-01-02 00:00:51 <op_mul> er, getrawtransaction.
5 2015-01-02 00:00:59 <sipa> gettransaction queries the wallet
6 2015-01-02 00:01:12 <sipa> getrawtransaction queries mempool and txindex
7 2015-01-02 00:01:32 <op_mul> yep, sorry, mixed them up in my head.
8 2015-01-02 00:01:50 <xabbix> ah, never noticed getrawtransaction, thanks
9 2015-01-02 00:31:22 <xabbix> Is there a reason why I cannot getrawtransaction the tx in the genesis block? (4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b), getting an error: "error: {"code":-5,"message":"No information available about transaction"}"
10 2015-01-02 00:32:17 <xabbix> my client is partially synced (a few weeks left for full sync)
11 2015-01-02 00:32:34 <op_mul> that's normal.
12 2015-01-02 00:33:15 <xabbix> Why can't I get that info from bitcoin-core?
13 2015-01-02 00:34:14 <op_mul> it's just not an indexed transaction, it's always been that way. it's output is not spendable either.
14 2015-01-02 00:35:57 <sipa> http://bitcoin.stackexchange.com/questions/10009/why-can-t-the-genesis-block-coinbase-be-spent
15 2015-01-02 00:39:06 <xabbix> Interesting, thank you
16 2015-01-02 00:41:27 <Luke-Jr> xabbix: the genesis block basically doesn't have a transaction
17 2015-01-02 00:42:58 <kkode> Any speculation as to why the genesis block doesn't have a transaction?
18 2015-01-02 00:44:13 <op_mul> kkode: I wouldn't burn my 3 questions with Satoshi on that one.
19 2015-01-02 00:44:39 <kkode> I guess it doesn't really matter, though interesting. Do altcoin genesis blocks have this quirk as well?
20 2015-01-02 00:45:04 <op_mul> yes. they are all just worthless clones of old bitcoin clients, they never fix bugs or backport things.
21 2015-01-02 00:47:48 <op_mul> you can't sell "we fixed OP_CHECKMULTISIG!", hence it remains the same.
22 2015-01-02 01:31:33 <fanquake> Itâs always so interesting reading through a pull request from thuni. Just a big brain dump of interesting notes and information.
23 2015-01-02 02:05:20 <s1w> op_mul: what would your questions be then?
24 2015-01-02 02:09:44 <op_mul> s1w: I'm not sure, I'd probably let gmax or someone have a rub of the lamp instead. most of the things I'm curious about really aren't interesting things for most people to find out.
25 2015-01-02 06:13:08 <midnightmagic> Diablo-D3: sorry for mocking you yesterday I misunterpreted what you said to me. I'd forgotten you're a squishie deep down.
26 2015-01-02 06:13:43 <midnightmagic> sipa: got a return: time ./bench_verify -> min 52673.949us / avg 52677.212us / max 52705.408us : real 2h 55m 40s
27 2015-01-02 06:13:50 <midnightmagic> I'll start one of the others.
28 2015-01-02 06:25:58 <gmaxwell> lol
29 2015-01-02 06:26:35 <gmaxwell> It takes less time to ping across the country than for that chip to verify a ECDSA signature??!
30 2015-01-02 06:26:43 <gmaxwell> midnightmagic: can you link to the specs on that chip?
31 2015-01-02 08:08:03 <midnightmagic> gmaxwell: sure. Right here: http://www.atmel.com/devices/AT32AP7000.aspx
32 2015-01-02 08:09:24 <gmaxwell> what OS do you have on it?
33 2015-01-02 08:10:48 <midnightmagic> Linux right now, the last published buildroot as the base, from atmel. the entire line of them has been EOL'd, no new ones (according to a self-described ex-employee ot atmel) will be produced in the avr32 line.
34 2015-01-02 08:13:35 <midnightmagic> the objdump disassembly is gibberish, I can't make sense of what it's doing.
35 2015-01-02 08:15:26 <midnightmagic> oh, no, that was because I was examining the math portions of the secp routines. the actual code routines all look normal, it doesn't look like the stuff I can grok is wasteful
36 2015-01-02 08:16:33 <gmaxwell> I assume it's memory bandwidth killing it.
37 2015-01-02 08:29:07 <midnightmagic> huh. there's a secure state mode where you can run signed code alongside unsigned code.
38 2015-01-02 08:29:26 <midnightmagic> time ./bench_inv -> min 8421.018us / avg 8425.499us / max 8464.311us : real 28m 5.11s
39 2015-01-02 08:29:52 <midnightmagic> time ./bench_sign -> min 24778.139us / avg 24780.495us / max 24800.040us : real 1h 22m 36s
40 2015-01-02 08:44:04 <wumpus> you made it more than two times faster by toggling a secure state bit?
41 2015-01-02 08:50:47 <midnightmagic> wumpus: no, it was just something I noticed while reading the datasheet. I believe I'm running different benchmarks..? or are they all doing the same thing?
42 2015-01-02 08:56:57 <wumpus> I misread
43 2015-01-02 09:17:03 <gdm85> cfields: but I think locale was fixed with that PR of mine. indeed wouldn't hurt another test
44 2015-01-02 09:41:29 <fanquake> wumpus have you deceided to pull out the copyright dates entirely? I think I had a branch sitting around.
45 2015-01-02 10:04:40 <wumpus> fanquake: just preparing for it for now, I think there was someone that wanted to ask a lawyer
46 2015-01-02 12:24:13 <Diablo-D3> [01:13:44] <midnightmagic> Diablo-D3: sorry for mocking you yesterday I misunterpreted what you said to me. I'd forgotten you're a squishie deep down.
47 2015-01-02 12:24:16 <Diablo-D3> you did what yesterday?
48 2015-01-02 12:24:18 <Diablo-D3> and Im a what?
49 2015-01-02 12:25:17 <Diablo-D3> I dont even remember sayng anything in here yesterday
50 2015-01-02 12:26:05 <op_mul> Diablo-D3: you're a british pie. tough and grumpy on the outside, horse meat on the inside.
51 2015-01-02 12:26:32 <Diablo-D3> Bitch please, I'm a half Irish half German pie, tough and grumpy on the outside, but a flask for booze on the inside.
52 2015-01-02 12:26:59 <wumpus> #bitcoin please
53 2015-01-02 12:59:21 <paveljanik> What is the status of leveldb in our sources?
54 2015-01-02 12:59:42 <paveljanik> it looks like it is a mix of upstream and win32 port...
55 2015-01-02 13:00:12 <fanquake> https://github.com/bitcoin/leveldb
56 2015-01-02 13:00:28 <fanquake> 1.18 was the last upstream merge
57 2015-01-02 13:00:47 <paveljanik> yes, this is ok.
58 2015-01-02 13:00:59 <paveljanik> Are there plans to report fixes to upstream?
59 2015-01-02 13:01:05 <paveljanik> work on win32 port integration etc?
60 2015-01-02 13:02:27 <fanquake> Do you have particular issues in mind? If I remember correctly when we were having serious osx corruption issues, some fixes got pushed upstream.
61 2015-01-02 13:03:45 <paveljanik> the win32 part:
62 2015-01-02 13:03:46 <paveljanik> build_detect_platform: PLATFORM_SOURCES="util/env_win.cc"
63 2015-01-02 13:03:58 <paveljanik> This sis the only line in git grep PLATFORM_SOURCES
64 2015-01-02 13:04:26 <paveljanik> the file is then built on all systems and emits warning because it is empty (on linking) on them.
65 2015-01-02 13:05:28 <paveljanik> I can add "PRUNE" part to build_detect_platform, but first I'd like to know the status of this part of the code.
66 2015-01-02 13:05:51 <paveljanik> so upstream -> bitcoin/leveldb -> bitcoin/bitcoin/src/leveldb
67 2015-01-02 13:05:53 <paveljanik> ok?
68 2015-01-02 13:06:06 <fanquake> correct
69 2015-01-02 13:06:09 <paveljanik> ok
70 2015-01-02 13:06:11 <paveljanik> Thank you.
71 2015-01-02 13:06:44 <paveljanik> PLATFORM_SOURCES seems like bitcoin/leveldb invention.
72 2015-01-02 13:06:52 <fanquake> Although, if you look through the change history, some changes have been by us
73 2015-01-02 13:07:14 <fanquake> i.e https://github.com/bitcoin/leveldb/commit/907f3084998fa4ce96b7abc6d9b12c7aa7b81c8c
74 2015-01-02 13:07:48 <paveljanik> yup, I already was there. win32 port...
75 2015-01-02 13:10:36 <fanquake> If your are poking around in the leveldb code you might want to take alook at something like this https://github.com/bitcoin/leveldb/issues/7
76 2015-01-02 13:11:31 <gdm85> I wonder if it has been tried/explored behavior on leveldb on a samba share
77 2015-01-02 13:11:38 <gdm85> ideally one would prevent this use-case at all
78 2015-01-02 13:11:57 <gdm85> s/on/of/
79 2015-01-02 13:17:11 <fanquake> paveljanik Maybe you should try and get some patches merged upstream. Looking though leveldb issues, people are suggesting just that https://github.com/google/leveldb/issues/248
80 2015-01-02 13:18:40 <paveljanik> I do not use Windows at all...
81 2015-01-02 13:19:02 <paveljanik> but yes, it would be great, if they merge our changes in.
82 2015-01-02 13:21:40 <gdm85> before, a subnet like 192.168.178.* was working for rpcallow. now it's no more. is there a comprehensive list of changes in a changelog or release notes already? or it gets created only at release time?
83 2015-01-02 13:22:17 <fanquake> gdm85 https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md
84 2015-01-02 13:22:28 <gdm85> fanquake: missed that. thanks
85 2015-01-02 13:24:46 <Luke-Jr> gdm85: basically you need to use normal subnet syntax now âº
86 2015-01-02 13:25:28 <gdm85> Luke-Jr: which is better :) I remember having to work around the wildcard syntax before, but nonetheless was a breaking change for my integration test
87 2015-01-02 13:33:31 <paveljanik> my chnage is PR now: https://github.com/bitcoin/leveldb/pull/8
88 2015-01-02 13:33:55 <paveljanik> contributing to leveldb upstream is not that easy - copyright assignement needed etc.
89 2015-01-02 13:34:42 <Luke-Jr> wtf? C++11 breaks ABI between GCC versions?
90 2015-01-02 13:40:41 <s1w> Luke-Jr: lolol
91 2015-01-02 13:42:11 <gdm85> "Error: There is no RPC client functionality in bitcoind anymore. Use the bitcoin-cli utility instead." <-- this is another breaking change. maybe we could have a paragraph with a summary of them?
92 2015-01-02 13:42:23 <gdm85> unless they're too many/too difficult to track..
93 2015-01-02 13:43:08 <sipa> gdm85: if that was not yet in 0.9.x, yes!
94 2015-01-02 13:43:16 <gdm85> sipa: not in 0.9.3
95 2015-01-02 13:43:38 <sipa> that deserves a section in the release notes then, imho
96 2015-01-02 13:44:00 <gdm85> yes, would be nice to have for people building on top of bitcoin core
97 2015-01-02 13:44:06 <gdm85> helps at upgrading
98 2015-01-02 13:44:37 <op_mul> if anybody is building services on bitcoin core using bitcoin-cli.. they've got other problems.
99 2015-01-02 13:45:15 <gdm85> op_mul: it's part of an integration test where I check if a peer is online. it's the correct way to do it, AFAIK
100 2015-01-02 13:46:09 <op_mul> bitcoin-cli is just a handy CLI tool, if you want to be interacting with the node you use the RPC interface as intended.
101 2015-01-02 13:46:16 <sipa> gdm85: the "suggested" way is use a json-rpc library in some other language directly
102 2015-01-02 13:46:32 <sipa> but if bitcoin-cli suffices, so much the better
103 2015-01-02 13:46:49 <gdm85> op_mul, sipa in deployment scripts (dreadful *bash*), that is still the most effective way
104 2015-01-02 13:47:11 <op_mul> sipa: seeing as the last use of it I saw passed user input straight to a root shell with bitcoin-cli and no escaping, doesn't fill me with warm fuzzies.
105 2015-01-02 13:48:37 <gdm85> op_mul: first mistake, running it as root
106 2015-01-02 13:48:43 <op_mul> in some ways having bitcoind refuse to run as root might be nice.
107 2015-01-02 13:54:19 <gdm85> https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/examples/bitcoin.conf#L84 <-- this ought be changed too
108 2015-01-02 13:54:32 <gdm85> maybe I'll wrap up a PR for these minor things
109 2015-01-02 15:17:23 <wumpus> cfields: travis is behaving strangely, the comparisontool gets killed without any message see eg https://travis-ci.org/bitcoin/bitcoin/jobs/45680679
110 2015-01-02 15:17:47 <wumpus> that's a change to a documentation file, so I think it occurs intermittently
111 2015-01-02 15:18:15 <Luke-Jr> wumpus: OOM killer?
112 2015-01-02 15:18:33 <Luke-Jr> I think BlueMatt mentioned some memory limitations recently added to Travis
113 2015-01-02 15:29:21 <wumpus> Luke-Jr: likely
114 2015-01-02 15:33:12 <wumpus> Luke-Jr: though I wonder how it manages to compile bitcoin and qt (with parallelism!) but runs out of memory during that test
115 2015-01-02 15:33:29 <sipa> Answer: Java
116 2015-01-02 15:33:31 <sipa> ACTION hides
117 2015-01-02 15:33:38 <Luke-Jr> probably :p
118 2015-01-02 15:33:42 <wumpus> lol
119 2015-01-02 15:35:13 <gdm85> just had to troubleshoot OOM PermGen errors (VM memory), not nice.. :\
120 2015-01-02 15:36:02 <Luke-Jr> wumpus: also note OOM killer does not imply out of memory
121 2015-01-02 15:36:03 <hearn> java doesn't have a permgen anymore
122 2015-01-02 15:36:13 <hearn> however i don't know if travis is using an old version for tests
123 2015-01-02 15:36:22 <Luke-Jr> if you have no swap configured, it will gladly start killing stuff when you're down to "only" a few GB free
124 2015-01-02 15:37:13 <Luke-Jr> (that was an interesting and rather confusing experience :P)
125 2015-01-02 15:37:48 <gdm85> this might be relevant: http://blogs.linbit.com/p/28/kernel-min_free_kbytes/ (I discovered it recently)
126 2015-01-02 15:39:04 <Luke-Jr> gdm85: nah, it's just bad logic in the OOM killer
127 2015-01-02 15:39:40 <gdm85> Luke-Jr: kernel's OOM killer?
128 2015-01-02 15:40:04 <Luke-Jr> yes
129 2015-01-02 15:40:18 <gdm85> I remember some code comments there talking about "child sacrifice", was a funny read and biblical reference
130 2015-01-02 15:40:26 <gdm85> (kernel code comments)
131 2015-01-02 15:42:53 <wumpus> Luke-Jr: I also noticed that, I had swap disabled for a while as I thought it was the reason for performance problems, but I was reasoning the wrong way around, it was *increasing* the swappiness parameter that made things more bearable
132 2015-01-02 16:11:26 <wumpus> michagogo: re: build date, because of determinism we take that from the git date, not the actual current date/time
133 2015-01-02 16:52:32 <gdm85> wumpus: although in tar it uses a fixed date (in 2006 IIRC)?
134 2015-01-02 16:54:13 <wumpus> gdm85: sure, I'm talking about the build date showed in 'about' and --version
135 2015-01-02 16:54:20 <gdm85> yes, clear
136 2015-01-02 16:54:46 <gdm85> honestly I was expecting any magic date to be the genesis block date :P
137 2015-01-02 16:55:19 <wumpus> hah
138 2015-01-02 16:55:58 <sipa> but shouldn't we use tag date rather than commit date?
139 2015-01-02 16:56:08 <wumpus> you can also build non-tag commits
140 2015-01-02 16:56:32 <sipa> right, sure
141 2015-01-02 16:56:39 <wumpus> of course it could check if there is a tag on the current commit, and if there is, use the tag date instead, but that sounds a bit pointless
142 2015-01-02 16:56:48 <sipa> probably not worth the complexity
143 2015-01-02 16:57:03 <wumpus> also it may be possible with git to import the commits themselves and not the tags, resulting in non-determinism
144 2015-01-02 17:55:54 <firelegend> Considering transaction hashes are well, hashes is it better to just use the first 3 or 4 bytes of the tx's hash for a hash table?
145 2015-01-02 17:57:32 <gmaxwell> for what?
146 2015-01-02 17:58:11 <gmaxwell> Someone can happily produce transactions that have a very biased distribution, and clobber your hashtable into linear performance... which might be a dos attack. So the answer depends on your application.
147 2015-01-02 18:23:38 <Genitrust> i'm looking for a light-weight way to automatically build transactions using a script (without having access to the private key). any suggestions out there on where i can get started?
148 2015-01-02 18:25:00 <kanzure> Genitrust: createrawtransaction, fundrawtransaction, petertodd/python-bitcoinlib, richardiss/pycoin, pick your poison
149 2015-01-02 18:25:20 <Genitrust> ooooo python-bitcoinlib....
150 2015-01-02 18:25:49 <Genitrust> kanzure: i was looking at electrum , but importing existing addresses (just the public key) is such a pain
151 2015-01-02 18:25:56 <Genitrust> thank you :)
152 2015-01-02 18:28:47 <kanzure> generally anything with a gui is not appropriate for the task you just described
153 2015-01-02 18:29:25 <kanzure> although electrum may have correctly separated their gui from the rest of their code, i've never read their source code
154 2015-01-02 18:30:40 <Genitrust> kanzure: well this "primer" seemed to help: https://electrum.org/offline_wallets.html
155 2015-01-02 18:30:52 <Genitrust> correct me if i'm wrong, but it appears i need more than just the public key
156 2015-01-02 18:31:12 <Genitrust> i need the 'script public key', which is the script for the public key's coin to spend or something
157 2015-01-02 18:32:03 <Genitrust> what would be awesome: createtx(input([just_the_bitcoin_address]), output([{bitcoinaddress1: 'amount'}, {bitcoinaddress2: 'amount'}, etc...]))
158 2015-01-02 18:32:11 <Genitrust> that'd be awesome @.@ so eh, i should create it then hehe
159 2015-01-02 18:32:31 <kanzure> i highly encourage you to use the existing implementations of that
160 2015-01-02 18:34:50 <Genitrust> kanzure: of pycoin?
161 2015-01-02 18:34:55 <Genitrust> oh yes, i understand now
162 2015-01-02 18:38:40 <Genitrust> kanzure: thank you so much @.@
163 2015-01-02 19:35:31 <Genitrust> does anyone here use pycoin?
164 2015-01-02 19:35:38 <Genitrust> trying to find where to get additional pycoin help
165 2015-01-02 19:35:45 <Genitrust> (so far, it seems very straight-forward)
166 2015-01-02 19:44:43 <cfields> robbak: around?
167 2015-01-02 19:50:51 <cfields> robbak: here's a test-case that's enough to demonstrate the problem: http://pastebin.com/raw.php?i=KAVmgd8u
168 2015-01-02 19:51:33 <cfields> robbak: build it with: clang++ -emit-llvm -c -S test.cpp -o test.S
169 2015-01-02 19:53:16 <cfields> robbak: then view test.S. If the type for out_of_range contains unnamed_addr, compiler is busted
170 2015-01-02 19:55:26 <cfields> robbak: also, just a regular clang build of that as an app should crash and burn: clang++ test.cpp -o test && ./test
171 2015-01-02 20:16:18 <Genitrust> anyone here use pycoin?