1 2015-11-23 00:27:49 <kenrestivo> is there a make target to build a binary tarball of bitcoind for linux?
 2 2015-11-23 00:28:53 <kenrestivo> make dist builds a source tarball, but i want to run the latest git HEAD on a server that doesn't have a build env, so i'm building it here first
 3 2015-11-23 01:09:35 <kenrestivo> nevermind, i just did make DESTIR
 4 2015-11-23 01:10:18 <kenrestivo> this thing uses up a lot of cpu. not too surprising, but are there compile flags for x86_64 that might tune it a bit?
 5 2015-11-23 01:11:39 <sipa> "this thing" being the compiler, or bitcoind?
 6 2015-11-23 01:12:06 <sipa> bitcoind, during initial sync, will use all CPU it can get to sync as fast as possible
 7 2015-11-23 01:12:20 <sipa> you can use -par=1 if you don't want it to peg multiple cores
 8 2015-11-23 01:12:30 <sipa> and other compile flags won't matter
 9 2015-11-23 03:08:58 <kenrestivo> meanign bitcoind. thanks, will try -par=1
10 2015-11-23 03:09:28 <kenrestivo> now i'm trying to get baron running. anyone here use it? where's a good place to ask?
11 2015-11-23 03:15:38 <kenrestivo> it has an interesting chicken-and-egg problem. upon starting up, it tries to hit its own url. but it hasn't started up yet. so it fails. wtf?
12 2015-11-23 04:00:33 <kenrestivo> hmm... project has been dead since june 2014.  anyway, it was a documentation bug.
13 2015-11-23 04:01:33 <kenrestivo> so right now, for a bitcoin store, your choices are the unmaintained baron, or this straight-server which appears to use blockchain.info instead of running even its own spv node, let alone a full node.
14 2015-11-23 04:02:28 <kenrestivo> or, you use coinbase.com or coinapult or similar.
15 2015-11-23 08:25:07 <windsok> https://bitco.in/forum/threads/will-bitcoin-development-ever-finish.215/
16 2015-11-23 08:26:32 <justanotheruser> windsok: http://250bpm.com/blog:50
17 2015-11-23 08:28:23 <justanotheruser> lots of projects are never finished
18 2015-11-23 08:28:43 <justanotheruser> just because the possibilities  grow as new developments are made
19 2015-11-23 13:03:25 <jonasschnelli> CodeShark: ping
20 2015-11-23 13:05:07 <jonasschnelli> Regarding: Hierarchical Deterministic Script Templates, would it not make sense to also allow a pubkey within a keygroup?
21 2015-11-23 13:05:20 <jonasschnelli> not only bip32 key derivation paths...
22 2015-11-23 13:06:44 <jonasschnelli> Multisig: you might not now the xpub of one of the multisig participants, so you can't re-create the redeem script
23 2015-11-23 16:06:56 <stexro> slap
24 2015-11-23 16:07:28 <stexro> hey
25 2015-11-23 16:09:58 <stexro> hey
26 2015-11-23 16:11:48 <stexro> Hey
27 2015-11-23 16:11:51 <stexro> I am New
28 2015-11-23 19:02:55 <bliljerk101> have there been frequent forks going on?
29 2015-11-23 19:05:21 <gavinandresen> bliljerk101: what do you mean by 'frequent'?  Short chain forks once or twice a day are normal and expected: https://blockchain.info/orphaned-blocks
30 2015-11-23 19:13:05 <bliljerk101> thanks. bitcoin core was throwing alerts. i assumed was related to forks, but it was actually: check your network connection, 0 blocks received in the last 4 hours
31 2015-11-23 20:16:13 <skyzer> A question about bitcoin core. I have about 1 million addresses and 'sendmany' takes too long to process, sometimes over 30 seconds so response to my web server times out. gmaxwell mentioned it's because of rpc keepalive leaking, BUT if i'm trying to run 'sendmany' with bitcoin-cli, sometimes I get the tx id response back within seconds, but sometimes takes takes 20-30 seconds. So the
32 2015-11-23 20:16:13 <skyzer> question is it rpc threads keepalive leaking or bitcoin core reached capacity and I would need now to think of scaling?
33 2015-11-23 20:17:41 <sipa> skyzer: how many transactions in your wallet?
34 2015-11-23 20:25:05 <skyzer> sipa, i think alot, like 500k maybe
35 2015-11-23 20:26:53 <gmaxwell> skyzer: do you have a test enviroment that you could load this wallet on and start doing some testing?  I recently merged some changes to git master that can make some processing for wallets with lots of transactions 2400% faster.
36 2015-11-23 20:27:20 <skyzer> it's a live bitcoin core, i don't know how to move that data into testnet
37 2015-11-23 20:27:26 <gmaxwell> I am guessing the seconds vs 20-30 is just a question of it's adding a new transaction to the wallet the moment you call sendmany, and then the send has to wait for the add being slow.
38 2015-11-23 20:28:26 <gmaxwell> skyzer: sure, but could you bring the wallet up on another mainnet daemon which isn't your production enviroment?   You could bechmark fundrawtransaction which does most of the same things with the wallet as sendmany.
39 2015-11-23 20:28:46 <skyzer> if now the bottleneck in bitcoin core, then i think it's time to separate into 2 bitcoin cores, this one bitcoin core leave as users addresses, and then spin up another bitcoin core that is used as hotwallet to send out bitcoins, so it means in that new bitcoin core is not a big pool of addresses
40 2015-11-23 20:30:03 <skyzer> i was reading about 6 performance boost PR in git that are waiting to be merged
41 2015-11-23 20:30:46 <skyzer> We are getting about 20-30 timeouts a day, where 'sendmany' takes more than 30 seconds
42 2015-11-23 20:31:11 <gmaxwell> skyzer: those other performance boosts are largely unrelated to big wallet performance. Most of the big wallet performance boosts are already in.
43 2015-11-23 20:32:10 <gmaxwell> skyzer: I think what is happening (though this is a guess) is that when you recieve transactions to add to your wallet, this is very slow because its sorting all 500k transactions for each one.  And your send many is just waiting for that to finish.  Git master eliminiates those sorts.
44 2015-11-23 20:32:46 <gmaxwell> In any case, the delays would be related to how many transactions the wallet has, not how many addresses.
45 2015-11-23 20:33:05 <gmaxwell> But this is a theory, you could test it by loading the wallet on a non-production machine and benchmarking fundrawtransaction.
46 2015-11-23 20:33:40 <skyzer> gmaxwell: makes sense, since there are a bunch of incoming transaction always
47 2015-11-23 20:34:08 <skyzer> i'm honestly not sure what would be faster whether to do the benchmarking, or just spin up second bitcoin core that is just used for sending out
48 2015-11-23 20:34:25 <skyzer> not sure what I would get from 'funrawtransaction'
49 2015-11-23 20:37:42 <gmaxwell> skyzer: spinning up another bitcoin core with the same transactions in it will be just as slow.
50 2015-11-23 20:38:45 <gmaxwell> (assuming that my expectation of the cause is correct)
51 2015-11-23 20:38:50 <skyzer> no, there won't be same transactions, a separate bitcoin core where all the incoming user tx-s will be moved and is gonna be used purely for sending out transactions
52 2015-11-23 20:39:11 <skyzer> so existing bitcoin core just for incoming txs and users addresses and second new bitcoin core purely for send outs
53 2015-11-23 20:39:17 <gmaxwell> skyzer: You would get validation that the poor performance you're expirencing is due to the cause I expect and that it has been fixed in master,
54 2015-11-23 20:39:47 <skyzer> any idea whn your change will be merged into release?
55 2015-11-23 20:41:45 <gmaxwell> It's merged, 0.12 will be going into feature freezen in a week, release candidates should be a month or two depending on how testing goes.
56 2015-11-23 20:42:01 <gmaxwell> not my change, luke-jr's change, technically.
57 2015-11-23 20:42:32 <gmaxwell> skyzer: in any case, if you don't care about funds being stuck in that inbound wallet, then you can split like that, and it would probably be reasonable.
58 2015-11-23 20:42:54 <gmaxwell> But it would be really useful if you could perform the test I'm describing; since I'd like to actually fix the behavior you're seeing if it isn't already fixed.
59 2015-11-23 20:43:15 <skyzer> okay, thanks alot, already looking forward to that 0.12 release
60 2015-11-23 20:43:18 <gmaxwell> but I cannot do so if you're unable to test a candidate fix.
61 2015-11-23 20:44:23 <skyzer> okay, shouldn't be a prolem actually to do that testing, will let know later about it
62 2015-11-23 20:45:12 <gmaxwell> skyzer: great, I'm very interested in improving performance with large wallets and have been doing a lot of testing and getting people to fix things that crop up.
63 2015-11-23 20:59:59 <skyzer> gmaxwell: for 'fundrawtransaction' you mean
64 2015-11-23 21:00:03 <skyzer> 'createrawtransaction' right?
65 2015-11-23 21:00:14 <skyzer> as fundraw.. doesnt exist
66 2015-11-23 21:00:30 <skyzer> or 'sendrawtransaction' ?
67 2015-11-23 21:00:45 <gmaxwell> skyzer: fundrawtransaction, not createraw.  Fundraw most certantly does exist, in git master.
68 2015-11-23 21:03:41 <skyzer> I'm lost now with new bitcoin core first I have to actually install the master branch version? Where is doc for that 'funrawtransaction'? https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list not in here
69 2015-11-23 21:04:49 <gmaxwell> that list on the wiki is almost always wrong; the actual documentation is in the software.
70 2015-11-23 21:05:22 <gmaxwell> skyzer: what I was asking you to do was to setup a non-production host with that wallet and test the master branch, to see if its fixed it.
71 2015-11-23 21:06:01 <gmaxwell> skyzer: you can checkout the master branch by typing "git clone https://github.com/bitcoin/bitcoin.git"
72 2015-11-23 21:06:21 <skyzer> okay, all clear now thanks, will let know later about results
73 2015-11-23 21:08:10 <gmaxwell> skyzer: if you need any help, please nag me. Feedback is essential to improving the software.
74 2015-11-23 22:29:01 <CodeShark> jonasschnelli: if you don't know the xpub of one of the participants you can't generate HD m-of-n scripts in the first place, so a script template wouldn't be very helpful
75 2015-11-23 22:30:29 <CodeShark> moreover, it is impractical to watch for all possible p2sh you might be able to sign unless you have the redeemscript
76 2015-11-23 22:31:03 <CodeShark> and even having the redeemscript, it greatly complicates wallet logic to have to parse and interpret it to figure out whether you can sign
77 2015-11-23 22:43:04 <CodeShark> jonasschnelli: I should add that if you want to use an explicit pubkey in a script, you can do so...you don't even need to template that part of the script
78 2015-11-23 22:43:13 <CodeShark> you could still use a template for other parts
79 2015-11-23 22:43:55 <CodeShark> it probably wouldn't make much sense to make it part of a key group and sort it