1 2014-12-14 00:15:14 <krafty> bitcoind listtransactions returns an empty set, any ideas why? I've tried "" and "*" and i still just get [] back
 2 2014-12-14 00:16:04 <sipa> well do you have any transactions in your wallet?
 3 2014-12-14 00:16:29 <krafty> no, im trying to get all recent transactions received
 4 2014-12-14 00:16:36 <krafty> i assumed if i didnt specify a wallet i would get that
 5 2014-12-14 00:16:53 <sipa> listtransactions lists your wallet's transactions
 6 2014-12-14 00:17:00 <krafty> gah ok
 7 2014-12-14 00:17:14 <sipa> there is no way to query all transactions ever (there's nearly 54 million!)
 8 2014-12-14 00:17:28 <krafty> i just want the most recent that its received
 9 2014-12-14 00:17:51 <krafty> do i just poll getrawmempool and check for new ones?
10 2014-12-14 00:17:54 <sipa> yes
11 2014-12-14 00:18:10 <krafty> thanks :)
12 2014-12-14 00:20:57 <krafty> is there a way to see where i received the new transaction notification from?
13 2014-12-14 00:23:30 <sipa> there is no such thing
14 2014-12-14 00:23:51 <sipa> or do you mean which peer?
15 2014-12-14 00:23:54 <sipa> no, that isn't tracked
16 2014-12-14 00:24:13 <krafty> ok thanks
17 2014-12-14 00:45:14 <phantomcircuit> krafty, whatcha doin' that you need that?
18 2014-12-14 00:45:33 <krafty> just playing really
19 2014-12-14 00:45:46 <krafty> getting my head round the whole system
20 2014-12-14 00:45:51 <phantomcircuit> ok
21 2014-12-14 00:46:13 <krafty> i thought it would be interesting to set up a few noes and map where i hear about transactions from
22 2014-12-14 00:46:30 <krafty> nodes*
23 2014-12-14 14:18:24 <warptangent> when bitcoind creates the blockchain file using the bootstrap process, is proof of work for each block checked, or just checkpoints?
24 2014-12-14 14:30:28 <harding> warptangent: each block is processed from the bootstrap as if it were received from the network.  That includes verifying the proof of work as well as verifying each transaction in the block.  If you have follow-up questions, I suggest asking in #bitcoin.
25 2014-12-14 14:31:38 <warptangent> thanks
26 2014-12-14 14:33:13 <warptangent> i'm curious about the reason it's verified. if the bootstrap.dat file is trusted (e.g. file checksum), why is verification for everything it contains, as if the blocks were downloaded individually over the P2P network?
27 2014-12-14 14:35:19 <harding> warptangent: That question is better asked in #bitcoin.  If you re-ask there, I'll be happy to help answer.
28 2014-12-14 14:35:50 <warptangent> ok
29 2014-12-14 15:00:57 <discreteunit> Any appetite for OS identification in the version message or an extension of it?
30 2014-12-14 15:05:58 <discreteunit> ... along the lines of "User-Agent" browser headers, in oder to facilitate platform-dependent decision making for Bitcoin Core development.
31 2014-12-14 15:07:04 <discreteunit> These could in turn be consumed by services such are getaddr.bitnodes.io etc...
32 2014-12-14 16:34:36 <syskall> hola
33 2014-12-14 16:36:26 <syskall> anyone around?
34 2014-12-14 16:36:33 <sipa> nope, sorry
35 2014-12-14 16:41:51 <syskall> :(
36 2014-12-14 18:19:49 <proserpine-> 7:17 PM <proserpine-> trying to add a custom rpc method to bitcoind, getting error: {"code":-1,"message":"value is type str, expected int"}
37 2014-12-14 18:19:50 <proserpine-> 7:18 PM <proserpine-> even though i added it to rpcclient.cpp
38 2014-12-14 18:19:50 <proserpine-> 7:19 PM <proserpine-> it works when calling with curl, but bitcoin-cli does not work, the first parameter is always parsed as STRING instead of INT
39 2014-12-14 18:22:43 <sipa> rpcclient needs to know that it has to interpret the argument
40 2014-12-14 18:24:18 <proserpine-> 7:23 PM <proserpine-> i added to CRPCConvertParam table to make sure its parsed as int, didn't work :(
41 2014-12-14 18:30:51 <proserpine-> pulled and built from latest git commit, added custom method to src/rpcblockchain.cpp; added method to the convertparam table in src/rpcclient.cpp; added method to rpccommands table in src/rpcserver.cpp; added declaration in src/rpcserver.h - missing anything?
42 2014-12-14 18:39:13 <paveljanik> proserpine-: show us the code...
43 2014-12-14 18:50:08 <proserpine-> paveljanik: its alright i dont need bitcoin-cli
44 2014-12-14 18:57:08 <tibnoic> Is 2 hours forgiven time necessary for blocks? Surely everyones clocks can't be off by that much. Wouldn't 10 minutes be fine?
45 2014-12-14 18:58:26 <sipa> tibnoic: maybe, but why bother changing it?
46 2014-12-14 18:59:05 <tibnoic> sipa: No reason to change it. Just wondering the rationale
47 2014-12-14 18:59:34 <sipa> the rationale was 'satoshi thought it would need to be at least enough not to hurt people with incorrect timezone configured'
48 2014-12-14 19:00:00 <tibnoic> Though would changing it even be a softfork? I assume 51% of miners already display the time correctly
49 2014-12-14 19:00:28 <sipa> no, it would just be a risky period with potentially increased forking
50 2014-12-14 19:00:46 <sipa> and no, it would require changes, because miners do play with the timestamp value
51 2014-12-14 19:01:34 <tibnoic> by play with them do you mean minimize the difficulty if they find the last block in a difficulty period?
52 2014-12-14 19:02:33 <sipa> no, using the timestamp as an extra nonce basically, within some limits
53 2014-12-14 19:02:39 <sipa> not sure how that is currently actually done
54 2014-12-14 19:02:42 <sipa> *how much
55 2014-12-14 19:03:15 <tibnoic> oh yeah, that's actually pretty smart. Do all modern ASICs do that?
56 2014-12-14 19:03:26 <sipa> no clue
57 2014-12-14 19:04:20 <tibnoic> That actually leads me to a different question.
58 2014-12-14 19:04:41 <tibnoic> It seems dangerous to have 32 bit nonces
59 2014-12-14 19:05:00 <sipa> in what way?
60 2014-12-14 19:05:43 <tibnoic> actually nevermind
61 2014-12-14 19:07:49 <tibnoic> I'm not sure why I thought that. My reasoning was that calculating the entire set of 2^32 nonces would be trivial so mining rigs would calculate the extranonce as part of their task. Less transactions means less hashes to calculate each time, but they are just hashes, they should be able to make a cheap component that can calculate the merkle tree in at least 1/2^20 times the speed
62 2014-12-14 19:08:16 <tibnoic> Basically processing a transaction will make their PoW harder, but only by 0.000000000000000000001%
63 2014-12-14 19:08:24 <tibnoic> s/a transaction/more transaction/
64 2014-12-14 19:09:01 <tibnoic> It does add a touch of complexity to ASICs, but not enough to hardfork I think
65 2014-12-14 19:09:22 <sipa> there have been proposals to repurpose part of the version number as extra nonce
66 2014-12-14 19:09:25 <sipa> which is just a soft fork
67 2014-12-14 19:10:24 <tibnoic> theres that too. To my understanding the version number doesn't add much.
68 2014-12-14 19:10:56 <tibnoic> I don't see why it couldn't be in the coinbase
69 2014-12-14 19:28:56 <gmaxwell> tibnoic: I've exaplained this to you before. Requiring very high accuracy would require all particpants to have their clocks set by centeralized update systems. Even accepting a centeralized source of time, no secure time service is widely deployed on the internet.  So it would be adding a point of failure to the network for no benefit.
70 2014-12-14 19:29:56 <gmaxwell> two hours is so wide that virtually any system will keep that much time after being set once, and if it fails you can just reset it periodically.
71 2014-12-14 19:30:22 <gmaxwell> (even just using a sundial if you know tha date...)
72 2014-12-14 19:30:35 <gmaxwell> (and your location :P)
73 2014-12-14 19:31:09 <tibnoic> gmaxwell: I'm not implying it has to be super accurate. I was just asking if the time window had to be so big. In #bitcoin I asked the same, but included my assumption that no central time servers were used just to be clear that I was assuming decentralized time setting.
74 2014-12-14 19:31:42 <gmaxwell> Why would you assume something which is completely non-existant and unclear how to make possible?  :P
75 2014-12-14 19:32:58 <tibnoic> gmaxwell: I'm not sure what you mean when you say it's nonexistent. I set my wristwatch when I was at my parents house and I can use that to verify my computers time.
76 2014-12-14 19:33:50 <tibnoic> Their microwave was probably set by looking at some time set by a central server though
77 2014-12-14 19:34:37 <gmaxwell> tibnoic: your computer time if set once may not keep 10 minutes precision acceptably long. Though accurate oscillators are fairly cheap, people often don't care about correct time and it's not hard to find server hardware that drifts several seconds a day.  And, as you note, wtf the microwave.
78 2014-12-14 19:36:39 <tibnoic> "wtf the microwave"?
79 2014-12-14 19:38:15 <gmaxwell> tibnoic: as far as the nonce. Doing root updates on the asics is a poor idea, though some have done it on microcontrollers (also a poor idea), ... in that it means that any fixes or changes to the network may make your hardware worthless. Better if it's more isolated. 2^32 is an awful big number... 4 billion. Usually a concern with updates isn't computation, but bandwidth since miner hardware likes t
80 2014-12-14 19:38:21 <gmaxwell> o attach large amounts of miners to a slow bus. Actually doing the nonce updates in hardware can make it worse since it needs to send the tree fragment (thus microcontrollers doing it).
81 2014-12-14 19:38:47 <gmaxwell> tibnoic: sorry sent too early there;  "And, as you note with respect to the microwave... even in that model you're taking some centeralized source of time ultimately."
82 2014-12-14 19:39:08 <tibnoic> gmaxwell: what time doesn't root from some centralized source?
83 2014-12-14 19:41:10 <gmaxwell> As I said, you can go read a sundial ... (perhaps the relative motion of the earth and the sun are 'centeralized' but they're not human influencable); and thats fine so long as you don't need a ton of precision.  Or setting it once to whatever the network is doing and forgetting it, but thats only viable if not much precision is required.
84 2014-12-14 19:41:47 <tibnoic> I guess 2 hours is good for sundial precision
85 2014-12-14 19:42:54 <gmaxwell> it's not just that, it's good because it doesn't matter if the system's clock is stable or has a very accurate rate. Regardless of how you set it, its decenteralized going forward if you can set it once and forget it.
86 2014-12-14 19:46:11 <tibnoic> So is it correct to say that 2 hours was chosen because it was optimizing between both allowing a very large inaccuracy in time and a very small ability to manipulate difficulty?
87 2014-12-14 19:46:48 <gmaxwell> It certantly has that effect.
88 2014-12-14 19:48:15 <tibnoic> pretty impressive how satoshi covered all these corner cases
89 2014-12-14 20:06:11 <deego> Re johoe's sweeping of blockchain's https://bitcointalk.org/index.php?topic=581411.0 What was the bottom line cause of the problem? Why do they re-use R? Is the main source of the problem a use of a weak RNG? And, I guess satoshi uses a far better RNG?
90 2014-12-14 20:06:26 <deego> satoshi client*
91 2014-12-14 20:07:22 <wumpus> why is tibnoic always here talking about the precision of the block timestamps
92 2014-12-14 20:09:03 <gmaxwell> deego: they replaced the rng on the site with a broken one which IIRC only had at best one byte of entropy; in an update which was presumably trying to fix some other issue. The rng it uses is very ill advised and concerning, in general.
93 2014-12-14 20:09:48 <deego> gmaxwell: mwahahaha.  lol. thanks.
94 2014-12-14 20:12:10 <deego> So, so thankful for all the brave souls that try out these crazy, fly-by-night clients, risk their life savings, and be the guinea pigs for the rest of us.
95 2014-12-14 23:52:58 <tdlfbx> Following this suggestion: http://www.verters.com/blockcheck I checked bitcoin's nonces.  Can anyone explain this distribution? http://pbrd.co/1wxc1wN