1 2015-12-05 02:46:51 <Genitrust> so let me get this straight... when you bitcoin-cli sendrawtransaction 'hex' ... you don't get a json response? :(
 2 2015-12-05 02:48:49 <harding> Genitrust: could you please ask in #bitcoin ?
 3 2015-12-05 03:02:07 <sipa> Genitrust: yes you do, it's just a JSON response that only includes one hex string :)
 4 2015-12-05 03:02:28 <sipa> Genitrust: eh, one that includes nothing
 5 2015-12-05 04:21:01 <Genitrust> sipa well, the response is not "JSON": "Javascript Object Notation" ... it's not an object in javascript notation form :|
 6 2015-12-05 04:26:30 <gijensen> I think bitcoin-cli returns in a human readable form. Just do an RPC call to get JSON.
 7 2015-12-05 04:27:27 <gijensen> Genitrust: ^
 8 2015-12-05 04:32:24 <sipa> Genitrust: what gijensen says
 9 2015-12-05 15:36:51 <btcdrak> AntPool produced a v4 block, w00t
10 2015-12-05 15:37:02 <btcdrak> this means we get enforcement in 5-6 days
11 2015-12-05 15:37:03 <btcdrak> this means we get enforcement in 5-6 days
12 2015-12-05 15:37:22 <morcos> With most people in HK, this is probably the wrong time to ask these arcane questions, but here we go:
13 2015-12-05 15:37:55 <morcos> Currently LockTime = 0 is special cased to mean no locktime, #6312 changes this to make LockTime = 0 mean LockTime = 0
14 2015-12-05 15:38:29 <morcos> In addition my suggested changes to #6312 also change Sequence = MAX from special case of no locktime to LockTime=0
15 2015-12-05 15:39:05 <morcos> I think this means the genesis block coinbase wouldn't be considered final by my code (but would be by #6312) but that's never checked.
16 2015-12-05 15:41:01 <morcos> How hard should we try to stick to the intial consensus rules?  I could change my code to have Sequence = MAX mean LockTime = -1, which would bring it back to #6312 and the genesis coinbase would be considered final again.
17 2015-12-05 15:41:52 <morcos> Is that worht fixing?  Is it worth fixing the Locktime = 0 special case in #6312 which has no effect unless some alternate chain has a genesis coinbase with non-maxed sequence?
18 2015-12-05 15:44:07 <morcos> oh, hmm nevermind, since the failure it returns is 0, then it's actually still passing.  (both in #6312 and my proposed changes)  so i guess it's fine, just a little less clear than the original code
19 2015-12-05 15:44:55 <morcos> sorry for the ramble
20 2015-12-05 15:44:57 <btcdrak> morcos: regarding the genesis block, isn't that why we have lines like "block.GetAncestor(std::max(block.nHeight-1, 0))->GetMedianTimePast()"
21 2015-12-05 15:45:42 <morcos> btcdrak: yeah good point, the code is built so it should pass it, but i don't think we do since we skip most of ConnectBlock for the genesis block
22 2015-12-05 15:46:19 <morcos> i mean i don't think we ever evaluate it, but now i do think it would pass if we did
23 2015-12-05 16:04:52 <tulip> morcos: be aware that some miners roll the coin base sequence number to create a new nonce space to search rather than tweaking the extranonce. they have effectively random values in that field.
24 2015-12-05 16:05:36 <tulip> just as a "be aware of this" with making consensus rules in that department.
25 2015-12-05 16:22:17 <phantomcircuit> tulip, of course they do :/
26 2015-12-05 16:31:28 <justanotheruser> Is this not in the hardware by now?
27 2015-12-05 16:34:30 <tulip> justanotheruser: as far as I know nobody has ever put the coinbase generation completely in hardware.
28 2015-12-05 16:35:34 <justanotheruser> So you're just giving the hardware batches of hundreds of merkle roots per second and calculating it on hardware? Seems excessive
29 2015-12-05 16:36:07 <tulip> there's little point to doing so, you risk having your hardware made obsolete for no real improvement. an antminer s7 needs new midstates at 1.2kHz which is pretty slow.
30 2015-12-05 16:38:57 <tulip> some use a FPGA but I'm not sure if it is actually making work or just distributing it between ASICs. the one I have in mind is the Avalon 1 which only needs midstates at 20hz.
31 2015-12-05 16:43:41 <phantomcircuit> tulip, the avalon machines convert stratum work to chip work on the fpga
32 2015-12-05 16:43:48 <phantomcircuit> afaik that's unusual
33 2015-12-05 19:38:13 <morcos> tulip: thanks, to be clear i'm only talking about the coinbase in the genesis block.  anyway turns out i was worried mistakenly.
34 2015-12-05 21:42:32 <gmaxwell> 288 block window shows CLTV as >75%, activation pending soon.
35 2015-12-05 21:52:00 <ahmed_> anyone know why bitcoind would throw this error?
36 2015-12-05 21:52:25 <ahmed_> DB_ENV->log_stat interface requires an environment configured for the logging subsystem
37 2015-12-05 21:52:25 <ahmed_> illegal flag combination specified to DB_ENV->open
38 2015-12-05 22:19:31 <tulip> phantomcircuit: that seems worthlessly expensive, wonder why they did it. I expected it to just be an io expander.
39 2015-12-05 22:21:44 <gmaxwell> Underpowered microcontroller, and super unoptimized old versions of cgminer made work generation look like more of a problem than it was.
40 2015-12-05 22:22:07 <gmaxwell> If you already have the fpga for IO reasons, and already have expirence building FPGA hashing devices...
41 2015-12-05 22:24:42 <tulip> good enough reason for me.
42 2015-12-05 22:49:39 <gijensen> I backported pr #6589 (log bytes send/recv per command) to 0.11 if anyone's interested (wasn't sure where to mention it) https://github.com/GIJensen/bitcoin/commit/605a12c6b20ac6f4fef193051175935fade00fd2