1 2017-06-22 00:07:19 <achow101> anyone got some testnet coins that they could send to me?
 2 2017-06-22 00:28:56 <galileopy> is the code for segwit2x going to be merged on the main bitcoin repo or segwit2x will be a fork of bitcoin?
 3 2017-06-22 00:37:05 <achow101> galileopy: bitcoin core will almost certainly not accept segwit2x
 4 2017-06-22 00:37:16 <achow101> (bitcoin core is the "main" bitcoin repo)
 5 2017-06-22 00:38:39 <galileopy> I know, so all this segwit2x propaganda, that there will not be a split is a lie, if miners HF segwit2x, we have a new coin?
 6 2017-06-22 00:39:10 <galileopy> http://www.coindesk.com/first-look-bitcoin-scaling-proposal-segwit2x-gets-alpha-release/
 7 2017-06-22 00:39:21 <galileopy> I'm talking about that
 8 2017-06-22 02:04:54 <Chicago> galileopy, I read that article this evening too.  achow101 you're saying coindesk's article omitted the fact Bitcoin Core won't be including 2x at all?
 9 2017-06-22 02:05:30 <Chicago> (the way I read it, probably by not comprehending carefully is that Core *would* be going forward with the compromise there)
10 2017-06-22 02:05:34 <Chicago> I guess I should re-read.
11 2017-06-22 02:06:14 <Chicago> and I wasn't certain what they were referring to when they spoke about the bitmain private chain happening hours after the July 31st thing.
12 2017-06-22 02:23:38 <kallewoof> "Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which helped organize the SegWit2x proposal and has an ownership stake in both BitGo and BitPay.
13 2017-06-22 02:42:43 <augurphan> ahoyhoy
14 2017-06-22 02:44:12 <cncr04s> is there any way to edit the number of threads that serve the RPC interface?
15 2017-06-22 02:45:11 <arubi> there is -rpcthreads=<n>
16 2017-06-22 02:46:15 <cncr04s> sweet
17 2017-06-22 06:31:53 <arubi> runeks, a bit more on topic here, yes I can't verify the signature
18 2017-06-22 06:32:20 <arubi> also not sure why you have two signatures on stack.  you're redeeming with the non-timelocked pubkey
19 2017-06-22 06:32:29 <arubi> no need to also sign with the locked one
20 2017-06-22 06:40:26 <runeks> arubi: ok. Thanks. I'll look into the signatures then.
21 2017-06-22 06:41:42 <runeks> arubi: as far as I understand, it's a 2-of-2 multisig. After expiration only one pubkey is needed, but before then both are needed.
22 2017-06-22 06:43:25 <arubi> hm lemme re-read the script
23 2017-06-22 06:43:38 <arubi> OP_IF 0388c5f0c79fe4bc23603a3268b4e71e24de8a704b3393bed0ba37375bde4783bc OP_CHECKSIGVERIFY OP_ELSE 1506442667 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_ENDIF 03e66447fbc5f3a4b461070ede729acaa293d7181db98e2d3e9db111716580a5c8 OP_CHECKSIG
24 2017-06-22 06:43:53 <arubi> dosn't look like multisig.  one is needed before the lock, the other after
25 2017-06-22 06:44:13 <arubi> you decide which by setting true or false to IF
26 2017-06-22 06:46:07 <arubi> also locktime isn't set, so the sig by the locked key can't verify even if that was the one that was used and not the first
27 2017-06-22 06:49:43 <runeks> A script starting with true should enter the if clause, checking the first pubkey, and continue after the if clause (after endif) with checking the second pubkey.
28 2017-06-22 06:50:21 <runeks> A script starting with false should skip the if clause, enter the else clause to check locktime, and then check the second pubkey.
29 2017-06-22 06:51:04 <arubi> you're right, I imagined an else
30 2017-06-22 12:45:00 <waxwing> is the ordering of the output of `listunspent` deterministic?
31 2017-06-22 14:20:18 <arubi> waxwing, lexicographically by txid, but by the reveres bytes :)
32 2017-06-22 14:20:43 <arubi> s/reverse/
33 2017-06-22 14:30:22 <waxwing> oh by txid. thanks. i wonder why they didn't do it by confirmations.
34 2017-06-22 14:31:32 <arubi> same mystery as for why the wallet address dump is ordered by the hash160 and not date added  I guess :)
35 2017-06-22 14:32:04 <arubi> "addresses in wallet dump" rather
36 2017-06-22 14:32:51 <arubi> I wonder if it's just a bdb thing
37 2017-06-22 14:39:30 <augurphan> hey there
38 2017-06-22 14:52:36 <wumpus> arubi: strange - dumpwallet output should be sorted by key birthdate, it doesn't dump directly from bdb
39 2017-06-22 14:52:46 <wumpus> waxwing: no, you cannot make assumptions about that
40 2017-06-22 14:53:22 <wumpus> it might be true for one version, but the order of the output is not part of the interface
41 2017-06-22 14:53:26 <arubi> was that recently changed wumpus?  keys do not appear in their bip32 order last time I did dumpwallet
42 2017-06-22 14:59:01 <arubi> right so on some 139900 I have for regtest it dumps addresses by hash160, and for a 149900 testnet it dumps by bip32 order
43 2017-06-22 15:00:43 <waxwing> wumpus: thanks
44 2017-06-22 15:01:07 <wumpus> waxwing: e.g. in the future we want to add an index for the utxo in the wallet, I'm not sure that will preserve currnet order
45 2017-06-22 22:30:58 <CryptAxe> Hey guys.. I'm working on a fork of bitcoin and I'm trying to fix this error which some of the travis builds throw during compilation:
46 2017-06-22 22:31:19 <CryptAxe> "undefined reference to `boost::system::generic_category()'"
47 2017-06-22 22:32:03 <CryptAxe> I've tried pretty hard not to make any of the code use any boost stuff, and looking through all of the includes in the file that throws this error I don't see where the boost dependency is
48 2017-06-22 22:32:30 <CryptAxe> Includes:   p, li { white-space: pre-wrap; }  #include <map> #include <queue> #include <vector>
49 2017-06-22 22:32:31 <CryptAxe> #include "uint256.h"
50 2017-06-22 22:32:44 <CryptAxe> #include <map>
51 2017-06-22 22:32:45 <CryptAxe> #include <queue>
52 2017-06-22 22:32:45 <CryptAxe> #include "uint256.h"
53 2017-06-22 22:32:45 <CryptAxe> #include <vector>
54 2017-06-22 22:35:41 <abpa> Hello CryptAxe this channel is for discussion of Bitcoin
55 2017-06-22 22:36:08 <CryptAxe> Yes I'm working on code for bitcoin...
56 2017-06-22 22:36:42 <abpa> You said you were working on a fork
57 2017-06-22 22:36:50 <CryptAxe> I'll leave lol
58 2017-06-22 22:36:52 <CryptAxe> bye