1 2014-09-20 01:14:28 <agorist000> Can anybody explain why we're not supporting nLockTime?
 2 2014-09-20 01:15:17 <sipa> nLockTime works and always has (as a consensus rule)
 3 2014-09-20 01:16:14 <agorist000> then why can't I create time-locked transactions without them being thrown out by bitcoind as "non-canonical" ?
 4 2014-09-20 01:16:28 <phantomcircuit> because it's a DoS vector
 5 2014-09-20 01:16:42 <phantomcircuit> you just keep adjusting the nLockTime value
 6 2014-09-20 01:16:56 <sipa> non-canonical?
 7 2014-09-20 01:17:06 <agorist000> sipa, yes
 8 2014-09-20 01:17:07 <sipa> it shouldn't throw them about because of that reason
 9 2014-09-20 01:17:19 <sipa> sure your transaction isn't just noncanonical for other reasons?
10 2014-09-20 01:17:44 <sipa> note that bitcoind _will_ not accept non-final transactions to its mempool
11 2014-09-20 01:17:47 <agorist000> I suppose its possible
12 2014-09-20 01:18:01 <sipa> but timelocked and final transactions are valid inside blocks
13 2014-09-20 01:18:15 <sipa> consistent with timelock rules
14 2014-09-20 01:18:55 <agorist000> so timelock is supported regardless of being a "DoS vector' ?
15 2014-09-20 01:19:24 <sipa> timelocking is a consensus rule; it cannot be changed without a hardforking change
16 2014-09-20 01:19:39 <sipa> but the only thing that consensus rules govern is whether a transaction is valid in a block or not
17 2014-09-20 01:20:04 <sipa> what is accepted into the mempool is subject to local policy
18 2014-09-20 01:20:16 <phantomcircuit> sipa, he's saying it's being rejected by the mempool
19 2014-09-20 01:20:21 <sipa> and non-final transactions are currently not accepted into the mempool because of DoS rules
20 2014-09-20 01:20:26 <phantomcircuit> which is what happens i believe because they're non final
21 2014-09-20 01:20:29 <sipa> indeed
22 2014-09-20 01:20:40 <sipa> but that is completely independent of whether timelock works or not
23 2014-09-20 01:20:48 <sipa> the rule is that non-final things are not accepted :)
24 2014-09-20 01:21:25 <agorist000> maybe I'm just unsure of what final means exactly
25 2014-09-20 01:23:46 <sipa> final means (no locktime) OR (locktime in the past) OR (all inputs final
26 2014-09-20 01:24:01 <sipa> an input is final when its sequence number is 0xFFFFFFFF
27 2014-09-20 01:24:18 <agorist000> if a tx is final, sequence must be uint max? Which means timelock is ignored...
28 2014-09-20 01:24:33 <agorist000> Am I missgin something?
29 2014-09-20 01:24:37 <sipa> reread my sentence
30 2014-09-20 01:25:08 <sipa> either of those 3 conditions is enough for finality
31 2014-09-20 01:25:24 <agorist000> okay so if timelock is past, it should propagate and be included in blocks?
32 2014-09-20 01:25:29 <sipa> yes
33 2014-09-20 01:25:57 <sipa> but if bitcoind complains that it's noncanonical, you have an unrelated problem in your transaction
34 2014-09-20 01:26:52 <agorist000> so then timelock is fully suppported, but sequencing is not? Because all but last in sequence are not final, which can be used for DoS somehow
35 2014-09-20 01:27:17 <sipa> the DoS potential is in relaying non-final transactions, because they can't be accepted into blocks
36 2014-09-20 01:27:31 <agorist000> Aha, that makes sense.
37 2014-09-20 01:27:33 <sipa> the reason for non-finality is irrelevant
38 2014-09-20 01:27:40 <agorist000> Thank you.
39 2014-09-20 01:27:45 <sipa> yw
40 2014-09-20 01:28:39 <DiabloD3> https://github.com/vladikoff/chromeos-apk/blob/master/README.md
41 2014-09-20 01:28:52 <DiabloD3> tthis might be useful for android client devs
42 2014-09-20 03:52:42 <dabura667> Could anyone give me a ballpark figure on how many bytes that a new address generated by getaddress() would add to an encrypted wallet file?
43 2014-09-20 03:54:51 <dabura667> err sorry, not getaddress() but I mean clicking "Add new" in the receiving address window.
44 2014-09-20 05:30:23 <dcousens> dabura667: are you referring to the standard client with that question?
45 2014-09-20 05:31:17 <dcousens> a private key is 32  bytes (padded), with an optional compression flag... in its more raw form anyway.  If you start encoding more information than that, obviously the size will increase
46 2014-09-20 06:21:50 <sipa> dabura667: around a 100 i guess
47 2014-09-20 06:22:28 <dabura667> Could you please elaborate?
48 2014-09-20 06:23:14 <dabura667> Meaning that creating a new key will increase file size by 100 bytes? How does it affect the key pool?
49 2014-09-20 06:23:30 <sipa> define 'create a new key'
50 2014-09-20 06:25:49 <wumpus> it removes a key from the key pool and puts it into active use, if the wallet is encrypted it will not immediately renew the keypool so there will be a key less in it
51 2014-09-20 06:28:33 <dabura667> wumpus: thanks. So the encrypted file will only increase in size after it runs out of keys in the key pool. When the key pool runs out does it automatically refill with 100 keys or do you have to run the rpc call to refill the pool?
52 2014-09-20 06:29:09 <wumpus> it does automatically so but only on the next 'walletpassphrase'
53 2014-09-20 06:29:12 <sipa> every time a key is used, the keypool is refilled to stay at 100 unused keys
54 2014-09-20 06:29:28 <sipa> for an encrypted wallet, only when the passphrase is available
55 2014-09-20 06:30:51 <wumpus> I'm fairly sure the wallet file will still increase in size though, as meta-information such as a label is added
56 2014-09-20 06:32:08 <wumpus> I wouldn't be concerned about that, generally it's transactions that take up lots of space in a wallet, not keys and related info
57 2014-09-20 11:42:52 <firelegend> I am trying to compile the latest git master, but the configure process is failing on the boost library. I have boost v 1.50 and have compiled bitcoin-qt and the daemon before, but the new build system is giving me error messages, some I manually removed from the configure, but now I "No working boost sleep implementation found."
58 2014-09-20 11:43:34 <firelegend> I am unsure how to debug this problem.
59 2014-09-20 11:52:28 <firelegend> fixed it, thanks to the config.log
60 2014-09-20 11:52:51 <firelegend> seems like when you specify BOOST_LDLAGS, you need to supply the path as -L/path/ rather than just the path
61 2014-09-20 11:59:52 <firelegend> there is also a missing stdlib.h include in utilstrencodings.cpp, as g++ complained that strtol and strtoll were missing
62 2014-09-20 12:00:09 <firelegend> well, stdlib I suppose in C++'s case