1 2014-07-11 01:08:42 <tjr-> Hi all.  I've been trying to search for info about BIP62 (Transaction MAlleability). Seems to be 'Draft' status.  Is it (partially?) implemented anywhere, or is it purely a 'maybe this will happen someday' BIP? Are there any plans to deploy it?
 2 2014-07-11 02:24:15 <copumpkin> I wish I could only keep the most recent X chunk of the blockchain
 3 2014-07-11 02:31:17 <wumpus> copumpkin: try https://github.com/bitcoin/bitcoin/pull/4481
 4 2014-07-11 02:57:55 <dhill> Luke-Jr: do you run the dashjr.org seed?
 5 2014-07-11 02:59:12 <Luke-Jr> dhill: yes
 6 2014-07-11 02:59:23 <Luke-Jr> well, depending on what "run" means <.<
 7 2014-07-11 02:59:51 <dhill> $ host dnsseed.bitcoin.dashjr.org
 8 2014-07-11 02:59:52 <dhill> ;; connection timed out; no servers could be reached
 9 2014-07-11 02:59:52 <gribble> Error: "connection" is not a valid command.
10 2014-07-11 03:00:01 <Luke-Jr> dhill: yes, it's not *running* right now
11 2014-07-11 03:00:08 <dhill> ok
12 2014-07-11 03:00:56 <Luke-Jr> dhill: XO.net likes to DoS my server when I run it, and their support is crap (= slow)
13 2014-07-11 03:02:48 <wumpus> Luke-Jr: I'll fix it in my pull
14 2014-07-11 03:03:20 <Luke-Jr> wumpus: k
15 2014-07-11 03:05:51 <phantomcircuit> Luke-Jr, what's the approximate cost of an ioctl SPI_IOC_MESSAGE call on an arm processor?
16 2014-07-11 03:06:44 <Luke-Jr> phantomcircuit: I would imagine it depends on the specific processor
17 2014-07-11 03:08:06 <phantomcircuit> Luke-Jr, lets say it's an RPI because im sure you know what one :P
18 2014-07-11 03:08:16 <phantomcircuit> (closer to a bbb)
19 2014-07-11 03:08:53 <Luke-Jr> phantomcircuit: RPI and BBB are very different :p
20 2014-07-11 03:09:03 <phantomcircuit> Luke-Jr, ok
21 2014-07-11 03:09:05 <phantomcircuit> bbb
22 2014-07-11 03:09:08 <Luke-Jr> phantomcircuit: regardless of what chipset, I don't know the answer ;)
23 2014-07-11 03:09:11 <phantomcircuit> (and yes i know)
24 2014-07-11 03:12:26 <phantomcircuit> Luke-Jr, you're no fun :P
25 2014-07-11 03:13:03 <Luke-Jr> <.<
26 2014-07-11 03:13:20 <Luke-Jr> phantomcircuit: let's say it's never been so low that I've had to worry about it
27 2014-07-11 03:13:27 <wumpus> phantomcircuit: 100 satoshis
28 2014-07-11 03:13:33 <Luke-Jr> OTOH, I *am* combining as much traffic into a single syscall as possible already :/
29 2014-07-11 03:13:54 <phantomcircuit> wumpus, heh
30 2014-07-11 03:14:03 <phantomcircuit> Luke-Jr, yeah that seems like it's necessary
31 2014-07-11 06:57:29 <ttll> how difficult would it be to add a "execscript" rpc call to bitcoin-qt (for research purposes only)
32 2014-07-11 06:58:14 <ttll> basically just taking a scriptSig and scriptPubKey in hex format
33 2014-07-11 06:59:14 <ttll> or is there an existing rpc call that lets me test arbitrary scripts
34 2014-07-11 07:57:32 <houska> hi, don't know if this is the right channel, but could someone please help me with this question? http://bitcoin.stackexchange.com/questions/29416/how-do-pool-servers-handle-multiple-workers-sharing-one-connection-with-stratum
35 2014-07-11 08:52:26 <jaromil> jtimon: re timestamping ACK reading now
36 2014-07-11 08:52:53 <jaromil> i'm into a codesprint for some other proj this weekend but will have time to thinker (too interesting to look over it)
37 2014-07-11 11:13:34 <sipa> phantomcircuit: it has the offset and always has. it uses bruteforce ffor finding particular transactions in a given block if needed (for the getrawtransaction rpc)
38 2014-07-11 11:14:33 <sipa> tjr-: probably it will happen someday
39 2014-07-11 11:41:52 <gribble> Error: "middag" is not a valid command.
40 2014-07-11 11:41:52 <tjopper1> !middag
41 2014-07-11 11:41:59 <tjopper1> !koffiemet
42 2014-07-11 11:42:00 <gribble> Error: "koffiemet" is not a valid command.
43 2014-07-11 12:26:13 <wumpus> Luke-Jr: a new transaction entering the mempool is also supposed to break the long poll, or not?
44 2014-07-11 12:32:02 <wumpus> oh it waits at least a minute
45 2014-07-11 12:32:14 <wumpus> (before looking for a mempool change)
46 2014-07-11 12:37:26 <wumpus> we should have the option to modify these timeouts, but as you say that can be done in a later pull...
47 2014-07-11 13:01:08 <wumpus> anyhow, added tests, and they pass
48 2014-07-11 13:30:30 <cronus> if im building a web service that will handle bitcoin payments and I want to get notifications when receive addresses get a transaction is it bad practice to run a full node with bitcoind on the same machine my web server is running on?
49 2014-07-11 13:43:11 <kiddouk> cronus: I think it's actually ok to do so. Running the node locally on another server will have no differences. You still have to connect RPC to the node to get some info.
50 2014-07-11 13:43:13 <wumpus> cronus: you could use the new watchonly functionality in master
51 2014-07-11 13:44:09 <wumpus> running a node isn't a problem, but running a live wallet with private keys on the same server (or in connection to) the web server is a bad idea
52 2014-07-11 13:44:17 <gmaxwell> Anyone know what the nTargetSize + 1 in wallet.cpp is for?  A result of it is that you can't set the keypool target lower than the current keypool size and keep it from generating any new keys.
53 2014-07-11 13:45:53 <wumpus> gmaxwell: why not? you just have  to pass one lower than what you want
54 2014-07-11 13:46:03 <wumpus> gmaxwell: the only thing you cannot do is generate a keypool of one
55 2014-07-11 13:46:38 <wumpus> it's either 0, which means the current default keypoolsize, or 1, which means 2
56 2014-07-11 13:47:58 <sipa> i expect it was once there for dealing with the default key
57 2014-07-11 13:49:03 <sipa> if anyone feels like converting this to a wiki article: http://bitcoin.stackexchange.com/a/29418/208, be my guest :)
58 2014-07-11 13:49:56 <wumpus> maybe at some point, although the default key has not been part of the keypool for as long as I can remember, it's a normal address with empty label
59 2014-07-11 13:50:35 <gmaxwell> wumpus: hm right. there is some point where it always generates a new key even when the keypool is full when getinfo is called... I thought for a moment that the cause was there, but you're right.
60 2014-07-11 13:51:07 <gmaxwell> (e.g. it reserves a key then releases it)
61 2014-07-11 13:52:54 <wumpus> gmaxwell: anyhow, ack on removing that +1 if it doesn't cause problems, I doubt anyone is relying on that behavior (it's not documented anywhere either)
62 2014-07-11 13:53:24 <cronus> yeah wouldn’t be storing a wallet on it, just the node with watch addresses for incoming transactions
63 2014-07-11 13:53:36 <wumpus> cronus: that's fine
64 2014-07-11 13:55:31 <cronus> any docs on new watchonly functionality?
65 2014-07-11 13:55:34 <wumpus> sipa: nice, block database documentation, I wouldn't encourage people to regard it as a stable interface, but it's useful for developer documentation
66 2014-07-11 13:55:38 <wumpus> cronus: nope
67 2014-07-11 13:55:44 <cronus> heh cool
68 2014-07-11 13:55:56 <wumpus> cronus: except the RPC help documentation of course
69 2014-07-11 13:56:06 <wumpus> cronus: see importaddress
70 2014-07-11 13:56:58 <cronus> ok thanks ill check it out
71 2014-07-11 14:14:51 <wumpus> and if you have any questions just ask
72 2014-07-11 14:19:03 <wumpus> wut https://github.com/bitcoin/bitcoin/issues/4509
73 2014-07-11 14:20:34 <wumpus> that should never happen, getnewaddress will not return a default address if the keypool is empty (unlike getrawchangeaddress did)
74 2014-07-11 14:21:39 <gmaxwell> wumpus: yea, I don't believe thats possible... I can't sort out that users response.
75 2014-07-11 14:38:40 <cronus> is it okay to run a node from master? importaddress isn’t in a release yet, right?
76 2014-07-11 14:40:57 <wumpus> cronus: it's ok, just be aware that you're using something that is not as well-tested as a release
77 2014-07-11 14:41:33 <cronus> yeah
78 2014-07-11 14:45:18 <wumpus> and on the other hand if no one tests master, problems only come to light in releases, which is also not good