1 2016-02-08 01:18:30 <rusty> kanzure: I'm wading through the 2MB thread now.  It's become a sewer AFAICT.    Hmm, wait, just hit a great jtoomim post which redeemed it.
 2 2016-02-08 01:20:23 <maaku> worth reading? (i'm unsubscribed)
 3 2016-02-08 01:24:44 <rusty> maaku: well, he actually provided the numbers on the profitability around the last halving.  It was refreshing to see real data :)
 4 2016-02-08 01:25:11 <maaku> real data is always good
 5 2016-02-08 01:27:01 <rusty> maaku: it was a bit off topic, but it logically followed.  I'm going to ask the other moderators if we should just kill that thread.
 6 2016-02-08 01:27:33 <gmaxwell> It was about 2:1 profitablity for me through most of the end of 2012-- though difficulty had been dropping for months to maintain that. I always thought it was odd that hashrate was falling with profitability so high, but chalked it up to hardware attrition (stuff fails and it makes no sense to replace it) and people paying more for power.
 7 2016-02-08 01:27:33 <jtoomim> awww, thanks rusty
 8 2016-02-08 01:28:04 <jtoomim> i was debating about whether i should answer backchannel or not. i'm not sure if i made the right call.
 9 2016-02-08 01:28:40 <jtoomim> gmaxwell how much were you paying for power?
10 2016-02-08 01:29:43 <gmaxwell> jtoomim: about 6 cents per kwh.
11 2016-02-08 01:30:38 <jtoomim> i knew a few people in california who were trying to mine off of $0.15/kWh and had to power off, and there were probably some europeans who did the same
12 2016-02-08 01:31:09 <jtoomim> they probably sold their rigs on the used market, at which point they were moved to a cheaper locale and powered back on
13 2016-02-08 01:32:59 <gmaxwell> we also saw difficulty drops in the not too distant past.  I suspect that emotional effects at small scale and realestate costs at large scales likely make the break even point closer to 2:1 on a coins to power basis; at least as an informal impression based on when diffculty goes up and down.
14 2016-02-08 01:33:40 <gmaxwell> I'm not sure if you ever ran a large scale operation with gpus, but their reliablity was very poor. Even just running two or three dozen gpus was a significant time investment cycling out bad hardware, dealing with fan failures, etc.
15 2016-02-08 01:35:54 <gmaxwell> Most of the asic miners are much better; though still pretty obnoxious at times.  as a random aside, a bunch of avalon batch 1 hardware just showed up in an electronics scrap store local to me. interestingly, some of it appears to be clone hardware not mfgured by avalon... and all of it appears to have an interesting wiremod (I'd guess a voltage mod to get more hashrate out.. you could get a lot more
16 2016-02-08 01:36:00 <gmaxwell> out of most of the avalon boards...)
17 2016-02-08 02:16:39 <pindarhk> Kung Hei Fat Choy (Happy New Year)! Please help determine whether a Scaling Bitcoin is held in 2016 by completing this 8 minute survey http://goo.gl/forms/6nbuvoGxWL
18 2016-02-08 04:24:05 <instagibbs> gong xi fa cai pindarhk :)
19 2016-02-08 05:49:03 <c4pt> how much does the blockchain grow every month in terms of hard drive space?
20 2016-02-08 05:52:13 <moli> c4pt: ask in #bitcoin
21 2016-02-08 08:25:06 <wumpus> given that up to 1 MB is added, on average, every 10 minutes, the worst case is easy to compute. The actual growth is a bit smaller as not all blocks are full.
22 2016-02-08 12:24:47 <xabbix> What's the 'reqSigs' field for? I can see it in txs but cannot find any explanation online about it.
23 2016-02-08 12:42:35 <wumpus> the number of signatures that are required
24 2016-02-08 13:10:38 <xabbix> wumpus: as in multi sig signatures? I'll have a number > 1 for a multisig tx?
25 2016-02-08 13:13:28 <wumpus> yes, though it won't work for P2SH multisig
26 2016-02-08 13:13:47 <wumpus> (as it can't see from the output how many signatures are required)
27 2016-02-08 13:42:42 <buZz> does anyone have an easy way to build raw transactions? like a bash script or something
28 2016-02-08 13:44:23 <buZz> without depending on bitcoind, that is :/
29 2016-02-08 13:44:27 <wumpus> the bitcoin-tx command line tool
30 2016-02-08 13:44:37 <buZz> hmmf, guess this will need a lot of external help
31 2016-02-08 13:45:09 <wumpus> or from python, python-bitcoinlib
32 2016-02-08 13:45:28 <buZz> i want to build something around picocoin to make it usable for users that dont want to type transactions in hex :P
33 2016-02-08 13:45:30 <jouke> buZz: what do you want to do?
34 2016-02-08 13:45:59 <buZz> lower system requirements to run a wallet
35 2016-02-08 13:46:13 <jouke> Does it need to run a bitcoin node itself?
36 2016-02-08 13:46:15 <buZz> picocoin seems to able to function in just 32MB ram, more so than bitc
37 2016-02-08 13:47:10 <buZz> my target system doesnt have capabilities to run a full node
38 2016-02-08 13:47:18 <buZz> but i want it to hold the keys
39 2016-02-08 13:47:21 <buZz> and 'be the wallet'
40 2016-02-08 13:48:11 <buZz> so i think using https://github.com/jgarzik/picocoin as 'engine' with some wrappers around it , could work
41 2016-02-08 13:49:15 <jouke> What do you mean with 'engine'?
42 2016-02-08 13:49:32 <buZz> its a SPV wallet system
43 2016-02-08 13:49:48 <buZz> but has no user friendly method to do transactions, or even see balance
44 2016-02-08 13:49:48 <buZz> etc
45 2016-02-08 13:56:06 <buZz> i guess python-bitcoinlib gets quite far :)
46 2016-02-08 14:12:22 <wumpus> it does
47 2016-02-08 14:35:37 <Chris_Stewart_5> when evaluating an OP_CHECKLOCKTIMEVERIFY is the tx invalid if ANY of the inputs sequence numbers are set to 0xffffffff
48 2016-02-08 14:44:40 <instagibbs> yes
49 2016-02-08 14:44:59 <instagibbs> wait
50 2016-02-08 14:45:37 <instagibbs> no, just that particular one
51 2016-02-08 15:29:50 <maaku> Chris_Stewart_5: just the one
52 2016-02-08 15:58:30 <Chris_Stewart_5> thanks maaku
53 2016-02-08 19:18:14 <midnightmagic> attempting to gitian 0.12.0rc1, I see the following error in build.log for the windows port (Linux gitian works and verifies fine): /home/ubuntu/build/bitcoin/depends/x86_64-w64-mingw32/lib/libdb_cxx-4.8.a(cxx_env.o):cxx_env.cpp:(.data$_ZTISt9exception[_ZTISt9exception]+0x0): multiple definition of `typeinfo for std::exception'
54 2016-02-08 19:18:21 <midnightmagic> is there something magic to solve this?
55 2016-02-08 22:25:13 <Lauda> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html
56 2016-02-08 22:25:26 <Lauda> What's the chance of this happening?
57 2016-02-08 22:31:01 <warren> Lauda: (not a core dev, just guessing)  I think the position of some exchanges is they fear doing engineering work so they might not like a HF of this type.  A HF of this type would require everyone to switch at the same time as opposed to segwit SF which allows for gradual opt-in when wallets and service operators are ready.
58 2016-02-08 22:32:50 <Luke-Jr> wumpus: https://github.com/bitcoin/bips/pull/322
59 2016-02-08 22:35:08 <Lauda> warren Why is everyone so afraid of a HF?
60 2016-02-08 22:35:26 <midnightmagic> this isn't really the place for that discussion.
61 2016-02-08 22:35:42 <warren> right, this is off-topic here, sorry for responding.
62 2016-02-08 22:36:14 <Lauda> I guess..
63 2016-02-08 22:36:14 <midnightmagic> #bitcoin or ##bitcoin would work as long as Lauda doesn't devolve it into trolling
64 2016-02-08 22:52:08 <mohammad> hi
65 2016-02-08 22:52:29 <Guest58548> hi
66 2016-02-08 22:55:36 <Guest58548> hi
67 2016-02-08 23:59:56 <midnightmagic> has anyone had any problems building 0.12.0rc* in gitian that look like this: multiple definition of `typeinfo for std::exception' when doing the Windows builds?