1 2017-03-07 00:20:04 <ruid> what is the proper way to only remake a certain binary in bitcoin?
 2 2017-03-07 00:20:52 <praxeology> ruid? you mean when compiling w/ make?
 3 2017-03-07 00:22:11 <ruid> praxeology, yes, is the default to do a clobber, or an incremental?
 4 2017-03-07 00:23:55 <praxeology> um, when you run make, it only compiles for the architecture target you are doing AFAIK, and then it also only re-compiles the files you change or the files that depend on those changes
 5 2017-03-07 00:25:34 <praxeology> So right now when I change the file I am working on, it recompiles the .o for that file, then like 6 executables and a .a
 6 2017-03-07 00:25:48 <ruid> ok.  That is not always the case.  Make can imply clean > all depending on how the target is defined
 7 2017-03-07 00:26:28 <ruid> thank you
 8 2017-03-07 00:32:45 <praxeology> Where is the segwit witness data stored?  Given that it is not part of a block...  If I load a segwit block from disk, and I iterate and read through all of the transactions, does it give me the witness data too?
 9 2017-03-07 00:33:34 <praxeology> If I make a new "CCoins" with a segwit tx, does the witness data get stored in the "CCoins"?
10 2017-03-07 00:37:04 <praxeology> or wait... the witness data is proof that the spending of an output is permitted...  never mind I think I just answered my question
11 2017-03-07 00:37:31 <praxeology> CCoins doesn't store witness data, never did, and won't after segwit either
12 2017-03-07 00:39:20 <praxeology> I still wonder where/how the witness data is stored though.  Guess I can look another day unless somebody knows off the top of their head
13 2017-03-07 04:55:35 <rusty> OK, dumb q.  In regtest mode, I want to test a zero-fee tx.  Is there a way to avoid "insufficient priority" ?
14 2017-03-07 04:57:11 <achow101> try setting minrelaytxfee to 0 in your bitcoin.conf
15 2017-03-07 04:58:44 <rusty> achow101: Error: Invalid amount for -minrelaytxfee=<amount>: '0'
16 2017-03-07 05:01:16 <achow101> huh. didn't know that that wasn't allowed
17 2017-03-07 05:01:52 <rusty> Yeah, me neither.  That's why I wondered if I was missing something...
18 2017-03-07 05:02:42 <praxeology> zero fee tx are pretty much blocked now to prevent spam
19 2017-03-07 05:02:57 <achow101> but regtest...
20 2017-03-07 05:07:24 <rusty> OK, I'll file a bug.
21 2017-03-07 05:13:03 <rusty> Let me first upgrade from version v0.13.99.0-9346f84 :)
22 2017-03-07 05:14:33 <achow101> just remove the check for 0 https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L1010 and don't forget to put it back when you go to mainnet :)
23 2017-03-07 05:15:23 <rusty> achow101: well, this is to test the lightning test vectors, so would be nice if everyone could run it without hacking bitcoind :(
24 2017-03-07 10:33:12 <bit7> can some kind soul please help me with a small section of C# Bitcoin Nbitcoin code ? :)
25 2017-03-07 18:47:12 <RainMan28> Attempting to send bitcoin using bitcoin core 0.13.2 to a valid (and previously used) address. Getting the error message that it is an invalid address.
26 2017-03-07 19:43:22 <coin_trader> question on coin-UTXO selection .... example: i send bitcoins to wallet in these sizes: 1, 1, 1, 2, 2, 2, 10 -- if i then go to send 7, i should get a transaction that is just one or two inputs and 2 outputs. but i am instead seeing behavior where it wants to group together many of the smaller chunks which makes an inefficient & large byte size transaction.... i am seeing
27 2017-03-07 19:43:23 <coin_trader> behavior where it will group 5-6 inputs when the node has viable and ready-to-spend outputs larger that would make same transaction with 1 input and 2 outputs or 2 inputs and 2 outputs...
28 2017-03-07 19:43:43 <coin_trader> this did not happen in previous versions of core - i'm running 13.2 and have been noticing this type of behavior more and more...
29 2017-03-07 21:05:24 <praxeology> Detailed description of my proposed Balances Commitment Data Structure: "http://pastebin.com/fRFaJ1Q4".  Feedback welcomed!
30 2017-03-07 21:06:33 <praxeology> Balances <-> UTXO set
31 2017-03-07 21:11:35 <luke-jr> * [new tag]         v0.14.0.knots20170307 -> v0.14.0.knots20170307