1 2012-12-08 00:20:36 <btc123> can someone point me in the right direction to generate QR codes (address+BTC amount) that blockchain's iPhone or Andriod app can read ?? thanks
2 2012-12-08 00:21:01 <btc123> i need to know how to encode the BTC amount in the QR (important)
3 2012-12-08 00:21:12 <btc123> thanks!
4 2012-12-08 00:23:41 <maaku> https://en.bitcoin.it/wiki/BIP_0021
5 2012-12-08 00:28:30 <btc123> thanks, i can put that string in any QR code generator and it should work?
6 2012-12-08 00:28:43 <btc123> bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>]
7 2012-12-08 00:29:43 <btc123> sweet
8 2012-12-08 01:37:08 <jgarzik> whew
9 2012-12-08 01:37:20 <jgarzik> all that trouble and debugging, for a double-declared variable
10 2012-12-08 01:38:01 <jgarzik> compiler even complained about it... but pointed to the wrong source file and line number, with a very vague warning
11 2012-12-08 01:38:14 <jgarzik> gotta love C :)
12 2012-12-08 01:38:30 <jgarzik> whole classes of bugs... present!
13 2012-12-08 02:22:34 <D34TH> jgarzik, i should provide libccoin.a
14 2012-12-08 02:22:35 <D34TH> :D
15 2012-12-08 06:18:09 <jgarzik> single thread, valgrind, main chain, with script verification turned on
16 2012-12-08 06:18:14 <jgarzik> let's see how many hours it takes
17 2012-12-08 06:22:28 <andrew12> hours
18 2012-12-08 07:22:19 <sipa> jgarzik: in valgrind? many
19 2012-12-08 14:57:10 <sipa> TD: just been looking at Hal's code a little closer, and I'm quite sure it includes the optimization he claims not to have done...
20 2012-12-08 14:57:28 <TD> odd. ask him, maybe? i think he's still with us
21 2012-12-08 14:59:02 <sipa> i can precalculate a bit more numbers than he did, but i don't expect more than a 1% speedup from that
22 2012-12-08 14:59:29 <sipa> TD: forum PM, or email?
23 2012-12-08 14:59:33 <TD> email
24 2012-12-08 15:00:01 <sipa> ok, will do
25 2012-12-08 15:39:17 <jgarzik> sipa: looks that way :)
26 2012-12-08 15:39:21 <jgarzik> still valgrinding away
27 2012-12-08 15:39:56 <jgarzik> starting at height zero, ~2am EST. It's now noon EST, and valgrind/chain-verf is at height 130000
28 2012-12-08 15:40:04 <jgarzik> looks like this might take a few days :)
29 2012-12-08 15:40:05 <jgarzik> looks like this might take a few days :)
30 2012-12-08 15:40:25 <jgarzik> thankfully the testnet chain is much faster, and already helped me spot and fix a few bugs
31 2012-12-08 15:43:56 <sipa> even valgrinding test_bitcoin takes several minutes :)
32 2012-12-08 15:43:57 <sipa> even valgrinding test_bitcoin takes several minutes :)
33 2012-12-08 15:56:36 <jgarzik> ACTION should probably turn off --leak-check=full
34 2012-12-08 15:56:40 <jgarzik> oh well, too late now
35 2012-12-08 15:56:41 <jgarzik> oh well, too late now
36 2012-12-08 15:56:53 <jgarzik> my computer will be working all weekend, if it doesn't OOM ;p
37 2012-12-08 15:57:13 <jgarzik> 5820 jgarzik 20 0 783m 698m 2484 R 98.6 17.7 593:14.36 memcheck-amd64-
38 2012-12-08 15:57:28 <jgarzik> not too bad, so far. am < height 140000
39 2012-12-08 15:58:05 <D34TH> jgarzik, i should try that on my new dedi
40 2012-12-08 15:58:46 <jgarzik> D34TH: what, valgrind? it won't go any faster because chain verification is single-threaded :)
41 2012-12-08 15:58:51 <D34TH> oh
42 2012-12-08 15:58:53 <D34TH> D:
43 2012-12-08 15:59:00 <sipa> D34TH: how many cores?
44 2012-12-08 15:59:05 <D34TH> 4
45 2012-12-08 15:59:16 <D34TH> i was just going for a basic
46 2012-12-08 15:59:22 <D34TH> i have 16gb of ram though
47 2012-12-08 15:59:41 <jgarzik> valgrind does support multiple threads, but I opted for simplicity. Makes the traces easier to follow, even though the task takes 4x as long
48 2012-12-08 15:59:56 <jgarzik> pretty happy, though.
49 2012-12-08 16:00:06 <jgarzik> libccoin, picocoin and brd all seem pretty valgrind-clean
50 2012-12-08 16:00:11 <jgarzik> and brd is happily downloading blocks
51 2012-12-08 16:00:35 <jgarzik> once reorg is finished, brd should be a full node
52 2012-12-08 16:00:43 <sipa> jgarzik: hmm, i thought valgrind was single threaded
53 2012-12-08 16:01:11 <jgarzik> well, brd will be a full blockchain server at that point. brd will not have a wallet (unlike picocoin, which does have a wallet)
54 2012-12-08 16:01:46 <sipa> it supports multi-threaded programs, but has its own scheduler
55 2012-12-08 16:02:21 <jgarzik> valgrind has two thread checking tools
56 2012-12-08 16:02:27 <D34TH> wow my debug.log from IBD is 2.4GB
57 2012-12-08 16:02:27 <jgarzik> helps spot data races and the like
58 2012-12-08 16:03:03 <sipa> jgarzik: sure, it supports multi-threaded program, but valgrind itself is single threaded
59 2012-12-08 16:03:10 <jgarzik> indeed
60 2012-12-08 16:03:46 <jgarzik> "valgrind does support multiple threads" I was referring to tracing my own multi-threaded program
61 2012-12-08 16:03:53 <sipa> oh ok
62 2012-12-08 16:03:54 <Diablo-D3> bullshit
63 2012-12-08 16:04:01 <Diablo-D3> valgrind and threading is just not compatible
64 2012-12-08 16:04:09 <jgarzik> i.e. making chain-verf verify the chain w/ multiple threads
65 2012-12-08 16:04:17 <jgarzik> parallel script verf
66 2012-12-08 16:05:16 <sipa> i'm building preview binaries from HEAD+halcode+parallel
67 2012-12-08 16:09:42 <sipa> hopefully it 1) doesn't crash on windows 2) gives a speedup
68 2012-12-08 16:16:03 <jgarzik> sipa: I respectfully disagree with gavinandresen... I think we should merge the halcode, after sufficient testing and review
69 2012-12-08 16:17:40 <sipa> i think i can refactor it to make it much more obvious it is ECDSA
70 2012-12-08 16:17:50 <sipa> i understand the code now, i think
71 2012-12-08 16:19:11 <sipa> perhaps some fuzzing-test can help make it trustable: do random bit flips in any of the precomputed constants
72 2012-12-08 16:27:24 <jgarzik> chain-verf: spend block @ 130000
73 2012-12-08 16:27:32 <jgarzik> still > 130000, < 140000
74 2012-12-08 16:27:33 <jgarzik> ;p
75 2012-12-08 16:27:58 <jgarzik> ACTION will provide gripping, breaking news, up-to-the-minute updates on his valgrind run throughout the weekend
76 2012-12-08 16:28:08 <jgarzik> maybe I should tweet every 10,000 blocks
77 2012-12-08 16:28:51 <molecular> I have a problem with "-rescan". It doesn't seem to find the transactions of the wallet I just swapped in. Am I doing it wrong? (I verified there are coins on at least some of the addresses from receiving history)
78 2012-12-08 16:31:01 <jgarzik> hmmm. Today is apparently "pretend to be a time traveler day"
79 2012-12-08 16:31:11 <jgarzik> ok
80 2012-12-08 16:31:42 <jgarzik> I just solo-mined block 420000 on my 100-core ASIC miner!
81 2012-12-08 16:40:34 <Luke-Jr> Only 100 core? O.o
82 2012-12-08 16:41:01 <Luke-Jr> Even BFL's SC MiniRigs are 250 core
83 2012-12-08 16:41:55 <jgarzik> You only need 100 when chips are built on a picometer scale ;p
84 2012-12-08 16:42:09 <sipa> in the future, 'core' is obviously an abbreviation of 'centillion orthogonal rigs executing'
85 2012-12-08 16:43:16 <Luke-Jr> haha
86 2012-12-08 16:45:24 <weex> -rescan is said to scan for missing wallet transactions but is it meant as a tool to make swapping wallet.dat files easy?
87 2012-12-08 16:45:45 <sipa> swapping wallet files should just work
88 2012-12-08 16:45:56 <sipa> -rescan is only for when somethinh goes wrong
89 2012-12-08 16:46:06 <weex> ok
90 2012-12-08 17:00:56 <jgarzik> bah
91 2012-12-08 17:01:14 <jgarzik> I sent some loose change to torservers.net as a donation, to make my balance nice and even
92 2012-12-08 17:01:21 <jgarzik> and I was charged a fee
93 2012-12-08 17:01:23 <jgarzik> defeated!
94 2012-12-08 17:02:10 <jgarzik> now I need to buy something worth 0.9995 bitcoins
95 2012-12-08 17:03:11 <jgarzik> hmmm
96 2012-12-08 17:03:12 <jgarzik> uhoh
97 2012-12-08 17:04:16 <jgarzik> sipa: another ultraprune crash on one of my public nodes: http://pastebin.com/5p0NQQJ4
98 2012-12-08 17:05:02 <jgarzik> sipa: need me to store anything, before restarting with HEAD?
99 2012-12-08 17:05:50 <sipa> i wonder what causes that... i don't think i ever touched code serializing stuff in the message handler
100 2012-12-08 17:06:38 <sipa> hmm, reading block or undo data is deserialization of course
101 2012-12-08 17:08:20 <jgarzik> I audited every deser code site I could find, back in 0.7.1 days
102 2012-12-08 17:31:10 <D34TH> is it possible to have log trunicate automagically after x minutes via bitcoin
103 2012-12-08 17:31:17 <D34TH> or should i just do it manually
104 2012-12-08 17:41:17 <jgarzik> sipa: pastebin doesn't seem to indicate any block/undo activity at the time of the crash. it complains about ThreadMessageHandler
105 2012-12-08 17:41:33 <jgarzik> sipa: anyway, restarting. copied all my data files, in case they are wanted for inspection
106 2012-12-08 17:41:48 <jgarzik> restarting with HEAD (the crash was ~ HEAD - 1 week, or so)
107 2012-12-08 17:42:21 <jgarzik> SetBestChain: new best=0000000000000322376a6b43f3c9ed836f76ae5920c61ac0cb42a361a7836721 height=211376 work=649287579981269053536 tx=9651895 date=12/08/12 10:55:22
108 2012-12-08 17:42:29 <jgarzik> that's the first block received, so that gives an idea of when it crashed
109 2012-12-08 17:42:37 <jgarzik> first block received after restart, that is
110 2012-12-08 17:43:36 <jgarzik> CTxMemPool::accept() : accepted bc9d14f052 (poolsz 30)
111 2012-12-08 17:43:54 <jgarzik> Just received that one. Some people out there probing with bad TX's?
112 2012-12-08 18:36:11 <Pucilowski> Can the change be assigned to one of the transaction inputs?
113 2012-12-08 18:36:34 <sipa> it can be, but the reference client won't do that
114 2012-12-08 18:36:38 <gmaxwell> Pucilowski: in the reference client? No. Certantly software could do that.
115 2012-12-08 18:36:47 <gmaxwell> Though it would be pretty bad for privacy.
116 2012-12-08 18:36:57 <Pucilowski> Yeah, I was just wondering if the design allows it
117 2012-12-08 18:37:02 <Luke-Jr> I can't think of any reason someone would want to do that, unless they have a misconception about inputs
118 2012-12-08 18:37:10 <Pucilowski> figured it'd create some sort of circular dependancy
119 2012-12-08 18:37:14 <gmaxwell> (and not really buy you anything useful, except perhaps making backups more reliable for non-determinstic wallets)
120 2012-12-08 18:37:29 <gmaxwell> Pucilowski: no, that suggests a 'misconception about inputs'
121 2012-12-08 18:37:34 <Luke-Jr> :P
122 2012-12-08 18:37:43 <gmaxwell> Bitcoin is a system of transactions??? coins/inputs??? not balances.
123 2012-12-08 18:37:48 <sipa> Pucilowski: the bitcoin protocol doesn't know or are about addresses or balances
124 2012-12-08 18:38:12 <Luke-Jr> sipa: O.o
125 2012-12-08 18:38:21 <gmaxwell> It just sees a new txn consuming an output from a prior transaction and producing one or more of its own outputs.
126 2012-12-08 18:39:05 <sipa> Luke-Jr: you may argue it knows scripts, and that addresses are shorthands for scripts; but thinking about coins as belonging to addresses leads to misconceptions
127 2012-12-08 18:39:08 <gmaxwell> Luke-Jr: hm? he said the same thing I was typing at the same time.
128 2012-12-08 18:39:21 <Luke-Jr> sipa: no, I think I agree; I just couldn't parse your sentence there :P
129 2012-12-08 18:39:25 <sipa> oh
130 2012-12-08 18:39:27 <sipa> s/are/care/
131 2012-12-08 18:39:28 <sipa> s/are/care/
132 2012-12-08 18:39:35 <Luke-Jr> aha
133 2012-12-08 18:40:14 <Luke-Jr> I would go further and say you can't REALLY assign change to the inputs
134 2012-12-08 18:40:19 <Luke-Jr> since the inputs are just signatures
135 2012-12-08 18:41:07 <Luke-Jr> ;)
136 2012-12-08 18:41:52 <sipa> right, i took the liberty of interpreting his question as "assigning change to the scripts the consumed inputs were assigned to"
137 2012-12-08 19:36:39 <jgarzik> chain-verf: spend block @ 140000
138 2012-12-08 19:36:47 <jgarzik> the valgrind excitement never ends!
139 2012-12-08 19:37:14 <sipa> i never got git HEAD bitcoind running past 140k
140 2012-12-08 19:37:19 <sipa> under valgrind
141 2012-12-08 19:48:56 <D34TH> sipa: is it a ram thing?
142 2012-12-08 19:49:02 <sipa> yes
143 2012-12-08 19:49:03 <sipa> yes
144 2012-12-08 19:49:10 <D34TH> how much do you need?
145 2012-12-08 19:49:19 <sipa> no idea; i have 8 GiB
146 2012-12-08 19:49:33 <D34TH> time to try with my 16gb
147 2012-12-08 19:51:56 <D34TH> how do i run bitcoin with valgrind
148 2012-12-08 19:52:15 <sipa> valgrind ./bitcoind <youropts>
149 2012-12-08 19:55:14 <D34TH> oh my
150 2012-12-08 19:55:15 <D34TH> oh my
151 2012-12-08 19:55:19 <D34TH> i should have ran that in a screen
152 2012-12-08 19:55:20 <D34TH> i should have ran that in a screen
153 2012-12-08 19:55:25 <sipa> yes :D
154 2012-12-08 19:56:30 <D34TH> weird
155 2012-12-08 19:56:34 <D34TH> screen keeps terminating
156 2012-12-08 19:57:27 <D34TH> uhh
157 2012-12-08 19:57:54 <D34TH> i'll just let that do its own thing
158 2012-12-08 19:59:02 <D34TH> i -connected to my other node running on that box
159 2012-12-08 19:59:08 <D34TH> for stupid quick bc download
160 2012-12-08 20:01:12 <D34TH> valgrind is already up to 218MB ram
161 2012-12-08 20:03:08 <D34TH> sipa: it seems even via localhost bitcoind is only downloading blocks at 1.57 kb/s
162 2012-12-08 20:11:40 <jgarzik> 5820 jgarzik 20 0 1050m 969m 2204 R 99.4 24.6 845:39.22 memcheck-amd64-
163 2012-12-08 20:11:55 <jgarzik> so, 1 gig @ 140k blocks
164 2012-12-08 20:15:46 <D34TH> im up to 463M
165 2012-12-08 20:15:57 <D34TH> 95k blocks
166 2012-12-08 20:29:05 <D34TH> 120k and its up to 500 MB
167 2012-12-08 20:47:41 <jgarzik> D34TH: what are you running? bitcoind, chain-verf or other?
168 2012-12-08 20:47:54 <D34TH> bitcoin/bitcoin head
169 2012-12-08 21:00:46 <Luke-Jr> looking for peer review of important mining code: https://bitcointalk.org/?topic=78192.msg1387181#msg1387181
170 2012-12-08 21:00:54 <Luke-Jr> gmaxwell: jgarzik ^
171 2012-12-08 21:01:54 <gmaxwell> Luke-Jr: I'll give it a glance, but you should really just prepare a test with fake work based on the real chain... and make sure it finds all the real blocks.
172 2012-12-08 21:02:15 <Luke-Jr> gmaxwell: I've been solo mining on testnet ???
173 2012-12-08 21:03:04 <gmaxwell> sure sure but that won't show you things like bugs that only crop up for high difficulties. (which sounds silly but miners have had bugs like that)
174 2012-12-08 21:03:09 <Luke-Jr> hm
175 2012-12-08 21:59:52 <sipa> etotheipi_: present?
176 2012-12-08 22:03:31 <etotheipi_> aye
177 2012-12-08 22:03:37 <etotheipi_> you have presents for me?
178 2012-12-08 22:04:40 <etotheipi_> I'm leaving in about 15 minutes, though. but I'll be around all day tomorrow
179 2012-12-08 22:06:59 <sipa> etotheipi_: i see you're contemplating using leveldb instead of an in-memory map
180 2012-12-08 22:07:00 <sipa> etotheipi_: i see you're contemplating using leveldb instead of an in-memory map
181 2012-12-08 22:07:11 <etotheipi_> sipa: yes
182 2012-12-08 22:07:31 <etotheipi_> I've played with leveldb in the past, when you guys brought it up
183 2012-12-08 22:07:44 <sipa> just to let you know, in bitcoind i use something of a hybrid setup, where modified entries are stored in a map, and occasionally flushed to leveldb
184 2012-12-08 22:08:24 <etotheipi_> sipa: at the moment, I'm basically just storing {txHash->blkfileLocation} in leveldb, atm
185 2012-12-08 22:08:26 <sipa> as serializing/deserializing has a cost, and being able to pass pointers to cached elements in memory is nice for performance
186 2012-12-08 22:08:27 <sipa> as serializing/deserializing has a cost, and being able to pass pointers to cached elements in memory is nice for performance
187 2012-12-08 22:08:48 <sipa> oh, then i doubt that is worth it
188 2012-12-08 22:08:50 <etotheipi_> but all tx data relevant to the wallet is in memory
189 2012-12-08 22:08:51 <etotheipi_> but all tx data relevant to the wallet is in memory
190 2012-12-08 22:09:09 <etotheipi_> sipa: the reason I'm doing this is that's how it's currently stored in RAM
191 2012-12-08 22:09:19 <etotheipi_> and I really need to get it out of RAM
192 2012-12-08 22:09:33 <etotheipi_> and it looks like I can make the change fairly transparently
193 2012-12-08 22:09:44 <etotheipi_> if I was starting from scratch, I wouldn't be doing it this way
194 2012-12-08 22:10:54 <etotheipi_> this was my compromise upgrade, compared to reworking Armory to maintain its own blockchain data
195 2012-12-08 22:13:29 <sipa> gavinandresen: if I would rewrite Hal's patch to be an exact copy of OpenSSL's ECDSA verification code, with one EC function call replaced by a secp256k1-specialized version (which means unit tests can try both, and check that the result of that operation is equal in both cases), would that make you trust it more?
196 2012-12-08 22:14:32 <etotheipi_> sipa: back to your recommendation (because I will need it eventually), is it just because it's more efficient to do batch writes with leveldb?
197 2012-12-08 22:14:56 <etotheipi_> I would think, if your data-to-write is scattered, it wouldn't make much difference to performance
198 2012-12-08 22:15:15 <sipa> etotheipi_: it's mostly adding an own layer of cache on top
199 2012-12-08 22:15:16 <sipa> etotheipi_: it's mostly adding an own layer of cache on top
200 2012-12-08 22:15:46 <sipa> since a block is likely to modify UTXO entries created/modified by recent blocks
201 2012-12-08 22:15:47 <sipa> since a block is likely to modify UTXO entries created/modified by recent blocks
202 2012-12-08 22:16:11 <etotheipi_> yeah, but if you add A, modify B and delete C, and all three of those are at completely different locations in the DB, does it matter if you do them separately or together?
203 2012-12-08 22:16:12 <sipa> and there is a rather complex deserialization/serializtion involved when reading/writing from/to leveldb
204 2012-12-08 22:16:13 <sipa> and there is a rather complex deserialization/serializtion involved when reading/writing from/to leveldb
205 2012-12-08 22:16:39 <etotheipi_> I thought it only mattered the keys were sequential
206 2012-12-08 22:16:40 <sipa> well, now a UTXO entry can get modified multiple times before being read and written again
207 2012-12-08 22:16:41 <sipa> well, now a UTXO entry can get modified multiple times before being read and written again
208 2012-12-08 22:16:50 <sipa> *in between
209 2012-12-08 22:16:51 <sipa> *in between
210 2012-12-08 22:18:02 <sipa> and it is per-block needed anyway, as you want to write the changes one block performs atomically to leveldb
211 2012-12-08 22:18:20 <etotheipi_> oh, you're actually avoiding unnecessary writes to the db