1 2016-01-25 00:26:01 <kenrestivo> are there any good guides, or opensource implementations, to doing micropayments with off-chain txs?
  2 2016-01-25 00:31:02 <instagibbs> kenrestivo, try #bitcoin
  3 2016-01-25 01:18:28 <cluelessperson> What are the valid parameters for a bitcoin private key?
  4 2016-01-25 01:28:16 <kefkius> cluelessperson: An ECDSA private key i.e. 32 bytes of random data
  5 2016-01-25 01:32:33 <cluelessperson> Do private keys have checksums?
  6 2016-01-25 01:35:46 <maaku> the key itself no
  7 2016-01-25 01:35:55 <maaku> the format of the dumpprivkey serialization, yes
  8 2016-01-25 01:56:35 <Luke-Jr> eh, these days "bitcoin private key" would usually be a HD wallet seed ;)
  9 2016-01-25 02:55:10 <RainMan28> I'm running a bitcoin node on a 80GB SSD, 8GB RAM, 4 CPU VPS and server load average shoots up to 2.5 to 3.5 and slows the server down to a halt. Is there anything I can do to lighten the effect bitcoind has on the system?
 10 2016-01-25 02:55:51 <RainMan28> I'm running version 110200
 11 2016-01-25 03:08:11 <RainMan28> I'm only using the VPS for bitcoind, but when it slows down, I can't even query the wallet balance.
 12 2016-01-25 03:18:23 <owowo> RainMan28: is that node synced? Or did you newly install it and it is downloading the blockchain/syncing ?
 13 2016-01-25 03:18:41 <RainMan28> been active for about 6 months owowo, fully synced
 14 2016-01-25 06:32:02 <phantomcircuit> RainMan28, bitcoin-cli getpeerinfo | grep subver | sort | uniq -c
 15 2016-01-25 06:32:08 <phantomcircuit> how many of the clients are bitcoinj?
 16 2016-01-25 06:32:30 <phantomcircuit> and how long does it stay at high load?
 17 2016-01-25 06:32:42 <RainMan28> phantomcircuit: checking now
 18 2016-01-25 06:34:12 <RainMan28> phantomcircuit: it stays at high load for about 30-45 mins or so it seems. I have 3 BitCoinJ clients connected. Load right now is 0.23
 19 2016-01-25 06:34:36 <bitcoin350> If I write a thin client rely on servers for information like available balances and transaction history. Standard code (like that available in bitcoinj -android) for maintaining wallet and sending bitcoins to others, is that will be  a good method ?
 20 2016-01-25 06:36:21 <Luke-Jr> bitcoin350: I don't know what you're asking.. it is generally not a good idea to simply trust third-parties for information.
 21 2016-01-25 06:38:26 <bitcoin350> msg/ Luke-Jr But otherwise how it is possible to create an android application, since it is not possible store entire blockchain.
 22 2016-01-25 06:39:24 <Luke-Jr> bitcoin350: do not use /msg for this. the answer is that you do not need to store the entire blockchain to run Bitcoin Core
 23 2016-01-25 06:41:32 <RainMan28> phantomcircuit: one time when the load was very high I think I did bitcoin-cli getinfo and it gave an error message about how it processed more blocks than it was expecting in the last 24 hours
 24 2016-01-25 06:42:49 <bitcoin350> But how the restore operation works in HD wallet,  we don't know which block has a transaction to our wallet address.
 25 2016-01-25 06:45:20 <phantomcircuit> RainMan28, 30-45 minutes? uh what operating system are you running?
 26 2016-01-25 06:46:46 <phantomcircuit> RainMan28, that error is caused by a certain person getting the math very wrong
 27 2016-01-25 06:48:18 <RainMan28> phantomcircuit: Running Ubuntu 14.04
 28 2016-01-25 06:52:41 <RainMan28> phantomcircuit: does it just slow down drastically when there are a lot of blocks found in quick succession? It isn't slow all the time
 29 2016-01-25 06:52:51 <RainMan28> but sometimes I can't even query the wallet's balance
 30 2016-01-25 07:00:18 <bitcoin350> The thin clients uses SPV for varification, but still it is not enough for restoring an HD wallet , am I correct
 31 2016-01-25 07:12:47 <RainMan28> hi mrkent
 32 2016-01-25 09:02:50 <cluelessperson> sup all
 33 2016-01-25 12:29:31 <Lauda> Warning: This version is obsolete..
 34 2016-01-25 12:29:34 <Lauda> since when was this issued?
 35 2016-01-25 12:30:47 <Lauda> Core 0.11.1 here
 36 2016-01-25 12:44:50 <phantomcircuit> Lauda, wat
 37 2016-01-25 12:45:27 <aj> phantomcircuit: pre CLTV capable version soft-fork warning
 38 2016-01-25 12:45:49 <phantomcircuit> oh CLTV right
 39 2016-01-25 12:47:24 <Lauda> So aj my 'node' does not fully validate blocks now or?
 40 2016-01-25 12:49:07 <aj> Lauda: it won't relay spends of CLTV timelocked funds, and it for blocks that include spends of CLTV timelocked funds, it won't check all the rules that need to be checked
 41 2016-01-25 12:49:41 <Lauda> Thanks. I'll wait for 0.12 to update.
 42 2016-01-25 12:50:05 <aj> (you "should" run 0.11.2 in the meantime)
 43 2016-01-25 12:52:26 <Lauda> Why is that?
 44 2016-01-25 12:52:37 <Lauda> I only occasionally turn this on to sync
 45 2016-01-25 12:52:58 <aj> because it validates the new rules and is the current version of the software?
 46 2016-01-25 12:53:23 <Lauda> What possible negative effects are there (user wise)?
 47 2016-01-25 12:53:37 <Lauda> I might and might not even send a single transaction from this in the meantime.
 48 2016-01-25 12:53:40 <aj> none either way really afaik
 49 2016-01-25 12:55:56 <xabbix> If my bitcoin-core node rejected a tx for any reason, and it gets included in the just arrived block, will I be able to getrawtransaction it after it ingested the new block? I should be able to do so since the new block is relayed with all the txs in it, right?
 50 2016-01-25 14:10:14 <jouke> xabbix: only if it's in your wallet or if you are running a full index node.
 51 2016-01-25 14:21:28 <xabbix> jouke: Yes I'm running with txindex=1
 52 2016-01-25 15:02:36 <denisx> where can I get 0.12rc2?
 53 2016-01-25 15:17:09 <wumpus> it's 0.12.0rc2, see the announcement here http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012275.html
 54 2016-01-25 15:30:33 <denisx> wumpus: thanks
 55 2016-01-25 15:42:39 <Chris_Stewart_5> I'm looking at this test case from bitcoin core, its related to OP_PUSHDATA2
 56 2016-01-25 15:42:41 <Chris_Stewart_5> ["0x4d 0x0100 0x08","8 EQUAL", "P2SH,STRICTENC", "0x4d is OP_PUSHDATA2"],
 57 2016-01-25 15:43:26 <Chris_Stewart_5> does 0x0100 mean that the next 16 bytes need to be pushed on to the stack, or does it mean that the next 256 bytes need to be pushed onto the stack?
 58 2016-01-25 15:43:45 <Chris_Stewart_5> 0x4d is the op code for OP_PUSHDATA2
 59 2016-01-25 15:46:47 <arubi> Chris_Stewart_5, if I understand correctly, it means "the next 0x0001 bytes will be pushed", but 0x0001 = 0x01, pushdata2 is too big for a one byte push
 60 2016-01-25 15:48:53 <arubi> Chris_Stewart_5, and then you get "Data push larger than necessary" when trying to broadcast
 61 2016-01-25 15:49:59 <arubi> but, pretty sure it can still be mined if a miner chooses to.  not sure if this makes it invalid or not
 62 2016-01-25 15:53:02 <arubi> oh sorry, not 01, 0x10
 63 2016-01-25 15:53:26 <arubi> so, sorry I guess I'm wrong about that there
 64 2016-01-25 15:54:37 <arubi> grr, I'm too tired, 0x0100 -> 0x0001 .  it is 0x01.
 65 2016-01-25 16:34:07 <what_now> How is this possible http://btc.blockr.io/tx/info/6733553af91c4518bd15fb8448dee07fd37c85c56b2274322f59a721476e50bd
 66 2016-01-25 16:34:25 <what_now> Where are the rest of the btc "gone"?
 67 2016-01-25 16:36:25 <what_now> For the lazy 1.089 sum of incoming 1.089 sum of outgoing but only 0.97806685 made it to the address and fee was 0.0001 so bitcoins can magically vanish?
 68 2016-01-25 16:37:46 <IanT_> 0.11083315
 69 2016-01-25 16:37:46 <IanT_> 1KhMNZcM1BjZPMNwH6uXHmC2dfBMK6MLYU ->
 70 2016-01-25 16:37:59 <what_now> Ah nvm my bad looks like there was change sent back sorry, it didnt show in trade view just raw view
 71 2016-01-25 17:25:36 <Chris_Stewart_5> arubi: Thanks for helping me out with that.
 72 2016-01-25 17:25:50 <Chris_Stewart_5> Sorry for the delay in replying, I had to step out
 73 2016-01-25 17:26:32 <arubi> sure
 74 2016-01-25 17:26:54 <Chris_Stewart_5> Little things like that can cause one to question their sanity :-)
 75 2016-01-25 17:27:05 <Chris_Stewart_5> So simple, yet so easy to make complicated
 76 2016-01-25 17:27:19 <Chris_Stewart_5> if you overthink it
 77 2016-01-25 17:28:11 <arubi> hehe, endianess always does that to me :)
 78 2016-01-25 18:08:07 <wallet42> what are the restrictions for p2sh scripts?
 79 2016-01-25 18:08:26 <wallet42> in therms of "standardness"?
 80 2016-01-25 18:09:41 <Luke-Jr> wallet42: standards are defined by BIPs; relay policy is decided by individual nodes; default relay policy for Core is to not restrict P2SH except for sigop limits
 81 2016-01-25 18:10:05 <Luke-Jr> decisions for new standards should ignore the current network node policies
 82 2016-01-25 18:10:37 <kefkius> But for spending, the actual script has to be standard in the way a p2pkh script must be standard, right?
 83 2016-01-25 18:18:40 <Chris_Stewart_5> How is this a script that evaluates to true?
 84 2016-01-25 18:18:42 <Chris_Stewart_5> ["0x4c 0x00","0 EQUAL", "P2SH,STRICTENC"],
 85 2016-01-25 18:18:53 <Chris_Stewart_5> which decodes to OP_PUSHDATA1 0x00 0 EQUAL
 86 2016-01-25 18:19:33 <Chris_Stewart_5> does this end up have the stack = OP_0 when OP_EQUAL is called? Which should be a problem since OP_EQUAL requires two inputs?
 87 2016-01-25 18:19:58 <kefkius> 0x00 and 0 are equal Chris_Stewart_5
 88 2016-01-25 18:20:21 <kefkius> So, 0x00 and 0 are consumed and 1 is placed on the stack --> evaluates to true
 89 2016-01-25 18:20:52 <Luke-Jr> eh, isn't 0x00 the length in this case? so an empty vector.. and the number zero is likewise an empty vector
 90 2016-01-25 18:23:01 <Chris_Stewart_5> however, isn't 0x00 not pushed onto the stack? Isn't that discarded as an input to OP_PUSHDATA1?
 91 2016-01-25 18:23:27 <Luke-Jr> Chris_Stewart_5: the empty vector is pushed to the stack
 92 2016-01-25 18:23:56 <Chris_Stewart_5> by OP_PUSHDATA1?
 93 2016-01-25 18:24:02 <Luke-Jr> yes
 94 2016-01-25 18:24:23 <Chris_Stewart_5> so basically an OP_0 is pushed onto the stack?
 95 2016-01-25 18:24:33 <Luke-Jr> yes
 96 2016-01-25 18:24:43 <Chris_Stewart_5> hmm ok. Thanks Luke-Jr & kefkius
 97 2016-01-25 18:24:47 <Luke-Jr> it's checking that both methods of pushing an empty vector get the same result
 98 2016-01-25 18:44:24 <Chris_Stewart_5> the result of arithmetic operations are pushed onto the stack top right?
 99 2016-01-25 18:44:34 <Chris_Stewart_5> i.e. OP_ADD 3 4 would push 7 onto the stack?
100 2016-01-25 18:48:54 <Lauda> Yes
101 2016-01-25 19:16:48 <gavinandresen> 3 4 OP_ADD leaves a 7 on the stack...
102 2016-01-25 19:17:21 <kefkius> I was gonna say, it depends on what endianness your textual representation of a stack has :P
103 2016-01-25 19:46:57 <wallet42> RPN FTW
104 2016-01-25 21:11:25 <Luke-Jr> huh, interesting.. got a bad-diffbits block reject on testnet
105 2016-01-25 21:11:36 <Luke-Jr> I wonder if it's invalid to use the correct difficulty past the 20 minute mark? O.o
106 2016-01-25 21:50:25 <Chris_Stewart_5> Is an empty byte vector pushed onto the stack if the OP_IF body is empty, but true is on the stack top
107 2016-01-25 21:50:31 <Chris_Stewart_5> i.e. IF ELSE 1 ENDIF
108 2016-01-25 22:04:58 <Luke-Jr> btcdrak: https://bitcoincore.org/en/meetings/2016/01/21/ "Wangchung from f2pool indicated he would not run code that required a C++ compiler." confuses C++11 with C++ and maybe(?) misspells wangchun's nick
109 2016-01-25 22:05:59 <gmaxwell> the misspelling is my fault. :( I'm awful with names.
110 2016-01-25 22:06:38 <gmaxwell> it should all so list the action that we took from that (go talk to him and figure out wtf is up with that)
111 2016-01-25 22:07:36 <Luke-Jr> gmaxwell: I suspect requiring C++11 is still a ways off. 0.12 won't even build with C++11 compilers (this is fixed in master).
112 2016-01-25 22:08:24 <gmaxwell> I thought a decision was made for 0.13 to move to requiring C++11?
113 2016-01-25 22:09:01 <Luke-Jr> gmaxwell: supporting C++11 is step 1. :p
114 2016-01-25 22:09:14 <gmaxwell> sure sure.
115 2016-01-25 22:09:39 <Luke-Jr> IMO we should have at least one release that soft-requires (disablable via configure) C++11 before we irreversibly modify the code to need it
116 2016-01-25 22:10:32 <Luke-Jr> to collect any complaints
117 2016-01-25 22:12:35 <gmaxwell> Luke-Jr: I don't think we're going to _not_ use C++11 regardless of what that turns up, the only question is timing.. and we've already delayed for an awful long time.
118 2016-01-25 22:12:58 <gmaxwell> best argument I can give for that is that once we go C++11-needed in master backports will become harder.
119 2016-01-25 22:18:23 <Luke-Jr> gmaxwell: strong NACK for breaking the ability to compile Core on non-niche latest-stable distro releases - but hopefully that won't be a concern by 0.13
120 2016-01-25 22:55:55 <maaku> gmaxwell Luke-Jr: I presumed the plan would be to depreciate C++03 along the same timeline as releases
121 2016-01-25 22:56:37 <maaku> so it is depreciated in 0.12, but 0.12 and 0.13 still compile C++03, and 0.14 is the earliest C++11-only code can come in
122 2016-01-25 22:58:20 <Lightsword> I know a number of pools use centos 6 which doesn’t seem to have a native c++11 compiler
123 2016-01-25 22:58:33 <Lightsword> and won’t be EOL for a long time
124 2016-01-25 23:00:23 <maaku> Lightsword: compile on another machine and static link
125 2016-01-25 23:00:44 <Lightsword> maaku, you can compile on them, just have to download a c++ compiler manually
126 2016-01-25 23:00:44 <moa> do you know pools that actually build their own binaries?
127 2016-01-25 23:00:46 <Luke-Jr> maaku: sounds good to me, assuming it doesn't conflict with target goals
128 2016-01-25 23:00:54 <gmaxwell> Lightsword: IIRC redhat provides one for it.
129 2016-01-25 23:01:03 <Luke-Jr> Lightsword: IMO it is only the *latest* stable we need to support
130 2016-01-25 23:01:07 <Lightsword> gmaxwell, I think it is unofficial
131 2016-01-25 23:01:07 <maaku> moa: most run custom patch sets
132 2016-01-25 23:01:12 <Luke-Jr> moa: all?
133 2016-01-25 23:01:15 <moa> jk
134 2016-01-25 23:01:24 <Lightsword> maaku, I’d say it’s 50:50 on custom patch sets
135 2016-01-25 23:01:35 <bsm117532> Millions for mining hardware but they can't be bothered to upgrade their server? What is that?
136 2016-01-25 23:01:45 <moa> be good if they actually put something back into FOSS once in a while ...
137 2016-01-25 23:02:02 <gmaxwell> Lightsword: running a compiler not tested by any of us is also dangerous, so I'm not sure that using RH's C++11 compiler would be a bad idea.
138 2016-01-25 23:03:06 <Lightsword> gmaxwell, I think they were manually compiling gcc
139 2016-01-25 23:04:02 <gmaxwell> Lightsword: oh well they don't need to do that, RH does provide a compiler.
140 2016-01-25 23:04:17 <gmaxwell> also ... what were they doing that for? bitcoin core doesn't currently need it.
141 2016-01-25 23:05:07 <Lightsword> gmaxwell, for centos6 they provide a c++11 compiler? they were using it for relay network actually
142 2016-01-25 23:05:22 <Lightsword> since relay does requite c++11
143 2016-01-25 23:06:30 <gmaxwell> wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
144 2016-01-25 23:06:59 <Lightsword> gmaxwell, yeah they used that one, is that official? I thought it was the centos equivalent of a ubuntu ppa
145 2016-01-25 23:07:15 <Lightsword> they also manually compiled as well I think….not sure which one they were using