1 2015-08-05 00:22:22 <Rozal> anyone here an iOS dev? or has a dev account?
 2 2015-08-05 00:23:51 <Luke-Jr> Rozal: not here please
 3 2015-08-05 00:24:10 <Rozal> Luke-Jr: you're a bully
 4 2015-08-05 00:39:35 <billotronic> anyone in here NOT a ban heavy cunt?
 5 2015-08-05 02:11:32 <blackmatrix_NY> Hi everyone. A bit confused here. Why does my bitcoin daemon doest start a process to listen on the port it is assigned when I enable both the connect field and port field ? Am I missing something
 6 2015-08-05 02:12:03 <blackmatrix_NY> If I disable/comment out the connect field, it starts listening
 7 2015-08-05 02:14:12 <phantomcircuit> blackmatrix_NY, the default is to listen
 8 2015-08-05 02:14:24 <phantomcircuit> specifying connect changes the default for listen to 0
 9 2015-08-05 02:14:32 <phantomcircuit> you can specify both connect and listen to get both
10 2015-08-05 02:19:13 <blackmatrix_NY> phantomcircuit: thanks, how do I go about adding another local bitcoin daemon I want to connect to ?
11 2015-08-05 02:19:44 <phantomcircuit> with -connect=ipaddress
12 2015-08-05 02:20:41 <blackmatrix_NY> cool, thanks...let me try that
13 2015-08-05 02:30:11 <blackmatrix_NY> phantomcircuit: when I add the -connect field to start the daemon it stops listening on the port
14 2015-08-05 02:32:28 <blackmatrix_NY> http://pastebin.com/Z7KvF0ue This is my bitcoin.conf...maybe I'm doing something wrong here
15 2015-08-05 02:35:52 <PRab> blackmatrix_NY: Add "listen=1" (without the quotes)
16 2015-08-05 02:36:03 <PRab> (More of a question for #bitcoin)
17 2015-08-05 02:40:04 <blackmatrix_NY> PRab: wow, that fixed it boss. both my nodes are connected now. Thank you very much!!!
18 2015-08-05 02:40:26 <PRab> No problem.
19 2015-08-05 02:41:30 <PRab> If you use connect=, the assumption is that you want to only use that node. Using both connect= and listen= at the same time is a bit strange.
20 2015-08-05 02:44:25 <blackmatrix_NY> PRab: Sure. Thanks again.
21 2015-08-05 04:04:28 <Lightsword> is there a way to make bitcoin core to not seed to users who are far from being caught up?
22 2015-08-05 04:06:19 <harding> Lightsword: please ask in #bitcoin
23 2015-08-05 04:06:46 <Lightsword> AFAIK there isn’t and I’m thinking it may be a good option to have for running mining pools.....
24 2015-08-05 07:37:42 <sipi> I am wondering how to get ExtPubKey from Copay Wallet in order to give other systems opportunity to generate public keys that would be only controlled by the Copay wallet. Is it possible to get xpubkey from just a Bitcoin address?
25 2015-08-05 07:49:01 <wumpus> sipi: no - an address consists of a pubkey or script *hash*
26 2015-08-05 08:14:52 <sipi> wumpus: alright, thanks. I have found out that just Mycellium exports the xpubkey. Thanks alot.
27 2015-08-05 08:21:39 <wumpus> great
28 2015-08-05 09:35:18 <jonasschnelli> sipi: the ExtPubKey is stored locally (browser local storage). You can copy/n/paste  export it from there?
29 2015-08-05 09:36:59 <jonasschnelli> there is a local key/value pair called "profile" containing a json object containing a "xPubKey".
30 2015-08-05 09:38:53 <sipi> jonasschnelli: I am in the scenario where merchant would provide from his xpubkey from his wallet, to other merchant systems. I thought that copay wallet does support that by default e.g. in export, etc.
31 2015-08-05 09:41:24 <jonasschnelli> why would a merchant give out a xpubkey? What is the usecase?  IIRC by default you can't export the XPubKey over the Copay UI... so you need to go down to the browser level local storage.
32 2015-08-05 09:43:05 <phantomcircuit> jonasschnelli, to make it as difficult as possible to correlate payments with invoices of course
33 2015-08-05 09:44:40 <jonasschnelli> So the "other merchant" could generate receiving addresses from the "merchant"?
34 2015-08-05 09:56:11 <sipi> jonasschelli here you go: http://bitcoin.stackexchange.com/questions/38959/pos-receipt-payment-identification
35 2015-08-05 09:56:48 <sipi> jonasschnelli so the "pos software" could generate unique address without having the control of their private keys.
36 2015-08-05 09:59:05 <sipi> phantomcircuit, what is the better option to uniquelly map payment with receipt?
37 2015-08-05 10:00:16 <jonasschnelli> sipi: Okay. I see your use-case. But i think you don't want the xPubKey of m ,... you probably want the xpubkey of the external chain (copay: m/45'/0/0, bip44: m/44'/0'/0'/0)
38 2015-08-05 10:02:07 <sipi> Thanks. Will have a look into that. I am currently in research phase.
39 2015-08-05 10:49:37 <sipi> jonasschnelli: yes. that perfectly fits. Do you think there is any other option ?
40 2015-08-05 10:55:20 <jonasschnelli> sipi: You mean an other option for the export or for you POS usecase?
41 2015-08-05 10:57:06 <sipi> jonasschnelli: the POS usecase, sorry.
42 2015-08-05 10:59:53 <jonasschnelli> I think i didn't fully understand your POS use case,.. but if you just wan't to allow a customer to send bitcoins to a POS system, it would make sense to store the extended pubkey of the external chain on the POS so the POS can generate a new address for receiving the funds.
43 2015-08-05 11:00:47 <jonasschnelli> IMO important is the fact, that the xpubkey is useless to spend funds, but could be attacked and replaced to transmit new incoming funds to a hackers account.
44 2015-08-05 13:50:10 <jonasschnelli> can i compile bitcoin-core with a already installed libsecp256k1? Or does it always compile a specific git hash?
45 2015-08-05 13:53:21 <Luke-Jr> jonasschnelli: check out my syslibs branches; but even then, you need a specific git hash
46 2015-08-05 13:53:56 <jonasschnelli> Luke-Jr: Yeah. The current libsecp256k1 master is incompatible with bitcoin-cores master...
47 2015-08-05 13:54:24 <jonasschnelli> I just try to find a way to easy reuse core-classes of bitcoin-core (like CKey, uint256, Hash160, etc.)
48 2015-08-05 13:54:49 <jonasschnelli> libbitcoin_common_a seems to be a good candidate for a such use case.
49 2015-08-05 13:55:37 <jonasschnelli> but compile time is bad... would be nice if there would be a boost free c++11 core library
50 2015-08-05 13:56:31 <Luke-Jr> like libbitcoinconsensus..
51 2015-08-05 14:04:16 <jonasschnelli> bitcoin/src/libbitcoin_common.a  -> 13MB!
52 2015-08-05 14:04:40 <jonasschnelli> (and this does not include boost)
53 2015-08-05 15:00:03 <wumpus> why does the size of the .a file matter? the linker will only use the objects in it that it needs
54 2015-08-05 15:15:30 <jonasschnelli> wumpus: Right. That's a good point.
55 2015-08-05 15:36:15 <Luke-Jr> :P
56 2015-08-05 15:36:15 <Luke-Jr> -rwxr-xr-x 1 luke-jr luke-jr 94M Jul 23 17:00 src/qt/bitcoin-qt
57 2015-08-05 15:43:20 <canth> lazy question - is upnp enabled by default in bitcoin core?
58 2015-08-05 15:44:19 <Luke-Jr> canth: only for GUI
59 2015-08-05 15:45:18 <wumpus> canth: depends on the configure setting --enable-upnp-default, for the releases it is
60 2015-08-05 15:45:34 <wumpus> GUI or not does not make a difference
61 2015-08-05 15:47:10 <canth> rgr that. given the number of upnp / igd enabled devices, its still a bit of a wonder at how few full nodes there are.
62 2015-08-05 15:47:57 <canth> some of it might stem from an above average level of security / paranoia from those who run full nodes and knowledge of upnp security weaknesses.
63 2015-08-05 15:48:40 <Luke-Jr> wumpus: oh? we changed the bitcoind default?
64 2015-08-05 15:49:36 <wumpus> a long time ago
65 2015-08-05 15:50:03 <wumpus> ( when the build system was switched to autoconf)
66 2015-08-05 16:49:56 <jdvs> i have started bitcoind, and i'm guessing it's syncing, but i don't know. how can i check this?
67 2015-08-05 16:55:14 <johnny_> _|jdvs: #bitcoin
68 2015-08-05 17:05:44 <hearn> cfields: heya, around?
69 2015-08-05 17:06:34 <cfields> hi
70 2015-08-05 17:07:58 <hearn> cfields: i have a gitian question :)
71 2015-08-05 17:08:16 <hearn> cfields: the osx-signer descriptor has a mysterious dir: "signature" line in the remotes section
72 2015-08-05 17:08:27 <hearn> what sort of directory does this refer to? i see no "signature" directory in the repository
73 2015-08-05 17:08:33 <hearn> (the detached-sigs repo i mean)
74 2015-08-05 17:09:06 <cfields> hearn: that param is the name of the dir that the remote is cloned into
75 2015-08-05 17:11:03 <wumpus> cfields: can you please take a look at https://github.com/bitcoin/bitcoin/issues/6515
76 2015-08-05 17:11:54 <cfields> wumpus: sure, i'll have a look when i finish up what i'm working on
77 2015-08-05 17:12:03 <wumpus> ok
78 2015-08-05 17:12:36 <BTC046> can I sign a raw transaction using signrawtransaction using a private key that is not imported into the wallet?
79 2015-08-05 17:12:38 <hearn> hm ok
80 2015-08-05 17:14:04 <wumpus> BTC046: yes
81 2015-08-05 17:14:49 <BTC046> i tried this syntax but it didn't work: signrawtransactoin (raw tx hex) [] [(priv key in wif format)]
82 2015-08-05 17:15:15 <hearn> cfields: i don't fully get how this works. gitian clones the bitcoin-detached-sigs repo into a directory called "signature". so far so good.
83 2015-08-05 17:15:24 <hearn> cfields: then the detached-sig-apply.sh script is invoked with a path of signature/osx
84 2015-08-05 17:15:38 <hearn> cfields: however, the repository doesn't have an "osx" directory in it. it has version directories and *then* the osx directory
85 2015-08-05 17:15:45 <hearn> cfields: where is this magic handled?
86 2015-08-05 17:16:49 <cfields> hearn: the master layout is just for viewing convenience. See the branches/tags.
87 2015-08-05 17:16:58 <hearn> ahhh
88 2015-08-05 17:17:57 <hearn> that explains it then,thanks