1 2017-05-26 01:36:00 <dstadulis> amount of funds between the last, exhausting commitment and the second from the exhausting commitment? or is channel exhaustion a risk for another reason
 2 2017-05-26 01:36:00 <dstadulis> in this lecture (at this time stamp https://www.youtube.com/watch?v=-lgYYz3y_hY&t=336 ), tdryja mentions that channel exhaustion, in adversarial conditions, is a risk to the receiving party. Is that because the exhausting party has not yet revoked the exhausting payment (by divulging their commitment revocation key)?  i.e. the best the receiving party could do is broadcast Commitment_transaction(-1) and they risk losing the
 3 2017-05-26 05:31:40 <Agro> when we generate an address from a public key, do we take the hash160 of the uncompressed key, including the 0x04 prefix or excluding it?
 4 2017-05-26 05:34:37 <Agro> been reading some docs, if i'm not mistaken, the 0x04 prefix is included
 5 2017-05-26 06:08:35 <arubi> Agro, you take the 0x02, 0x03 or 0x04 as well yes
 6 2017-05-26 06:08:44 <arubi> (if you wouldn't 0x02 and 0x03 would be the same)
 7 2017-05-26 06:09:14 <Agro> ahh got it, thanks! are there any situations where you'd hash the compressed point? haven't seen any yet
 8 2017-05-26 06:09:34 <arubi> almost all software uses compressed keys now
 9 2017-05-26 06:09:41 <arubi> there's not reason not to use compressed keys
10 2017-05-26 06:10:10 <Agro> ah, but the address is still generated from the uncompressed public key, right?
11 2017-05-26 06:10:15 <Agro> p2pkh address
12 2017-05-26 06:10:36 <arubi> nope, because again these would become the same address
13 2017-05-26 06:11:03 <arubi> a compressed pubkey and uncompressed one have different addresses because their hashes are different
14 2017-05-26 06:12:17 <Agro> right, the compressed one is 33 bytes (including the prefix), and the uncompressed one is 65 bytes including the prefix. the docs i've been reading derives the p2pkh address from the uncompressed point
15 2017-05-26 06:12:24 <Agro> https://stackoverflow.com/questions/17672696/generating-bitcoin-address-from-ecdsa-public-key http://enetium.com/resources/Bitcoin.pdf
16 2017-05-26 06:12:43 <arubi> these are just examples
17 2017-05-26 06:13:02 <arubi> in reality, nobody uses uncompressed pubkeys for addresses or scripts
18 2017-05-26 06:13:40 <Agro> oh hmm
19 2017-05-26 06:20:28 <Agro> ok i think i got it now, can generate the address from the compressed or uncompressed point. as long as you specify the correct pubkey in the scriptPubkey, it should be fine, yeah? does OP_CHECKSIG expect a compressed/uncompressed key though?
20 2017-05-26 06:20:47 <arubi> it expects a valid public key
21 2017-05-26 06:21:03 <arubi> (and a signature)
22 2017-05-26 06:23:33 <arubi> Agro, really just look at any p2pkh transaction in flight right now.  they all use compressed keys
23 2017-05-26 06:23:52 <Agro> will do
24 2017-05-26 06:26:46 <sictransitgloria> hey all, anyone around? my friend is having an issue w/ 14.1 and I haven't seen this before
25 2017-05-26 06:27:04 <sictransitgloria> basically ran into some rpcworkqueue errors and then he rebooted the node and it's chugging really slowly, last line in debug.log is: Waiting for data... (interrupt to abort)
26 2017-05-26 06:27:21 <sictransitgloria> plenty of space/blocks on drive and CPU/RAM
27 2017-05-26 06:27:57 <sictransitgloria> not sure if it's hardware-layer issue but wondering if anyone else has seen this
28 2017-05-26 06:28:23 <sictransitgloria> sorry, last line is: 2017-05-26 06:24:22 init message: Loading addresses...
29 2017-05-26 06:30:22 <arubi> maybe move the peers.dat file somewhere and try again?
30 2017-05-26 06:37:43 <Agro> arubi, yeah, just went through a transaction, uses a compressed key. if i were to use an uncompressed one, would be paying for an additional 32 bytes in fees huh
31 2017-05-26 06:37:53 <arubi> yep
32 2017-05-26 06:39:36 <Agro> thanks for the help, wouldn't have realized that
33 2017-05-26 06:39:45 <arubi> cheers Agro
34 2017-05-26 06:40:30 <Agro> have a good night!
35 2017-05-26 06:40:32 <sictransitgloria> does anyone know offhand what position sendmany puts the change address in?
36 2017-05-26 06:40:35 <arubi> night :)
37 2017-05-26 12:29:38 <afk11> anyone know of a public litecoin insight instance?
38 2017-05-26 16:58:45 <Chris_Stewart_5> Anyone know travis ci well? Having trouble getting bitcoind installed on travis https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/jobs/236438192#L186
39 2017-05-26 17:02:32 <arubi> Chris_Stewart_5, maybe call bitcoind with the full path?
40 2017-05-26 17:22:46 <Chris_Stewart_5> Hmm, looks like they aren't installing the binary for some reason: https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/builds/236451398#L205
41 2017-05-26 17:23:22 <Chris_Stewart_5> I have had isues in the past with travis and bitcoind, but I thought they had whitelisted it.. They claim it is mining software that can be used to abuse their infrastructure
42 2017-05-26 17:23:46 <arubi> well it could in theory
43 2017-05-26 17:24:28 <arubi> but so could any other binary :)
44 2017-05-26 17:24:36 <Chris_Stewart_5> If you look at the request history here you'll see it use to outright reject any pull with a bitcoind dependency
45 2017-05-26 17:24:39 <Chris_Stewart_5> https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/requests
46 2017-05-26 17:24:55 <arubi> :(
47 2017-05-26 17:25:19 <Chris_Stewart_5> but it is actually creating the build now (which it didn't use to before I emailed them). Some progress I guess...
48 2017-05-26 17:25:29 <arubi> maybe you could download the .deb and extract it?
49 2017-05-26 17:25:43 <Chris_Stewart_5> Yeah, i'll try that next.
50 2017-05-26 18:28:19 <fpgaminer> Is there a reason TxOut.value is listed as an int64_t in the documentation (https://bitcoin.org/en/developer-reference#txout)?  Shouldn't it be uint64_t?
51 2017-05-26 18:42:10 <Chris_Stewart_5> fpgaminer: It is an int64_t in the codebase https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L12
52 2017-05-26 19:05:19 <fpgaminer> Chris_Stewart_5: Weird.  I assume a negative value is never valid, so I wonder why it's int64 in the code?
53 2017-05-26 19:14:09 <Chris_Stewart_5> Good question, there are some test cases that use -1 satoshis
54 2017-05-26 19:20:14 <Chris_Stewart_5> For building crediting transactions for the script_tests.json files
55 2017-05-26 19:22:46 <fpgaminer> hmmm, okay.  I guess it makes sense if parts of the code end up using negative values.  Thanks for the info Chris_Stewart_5!
56 2017-05-26 19:23:11 <Chris_Stewart_5> fpgaminer: I'm not sure if I am convinced -- couldn't it be changed to a uint32_t without a hard fork?
57 2017-05-26 19:24:05 <Chris_Stewart_5> I would imagine there is some consensus rule in validation.cpp that states all outputs must have value > 0
58 2017-05-26 19:46:22 <fpgaminer> Chris_Stewart_5: Well, it at least needs to be 64-bit
59 2017-05-26 19:49:49 <Chris_Stewart_5> fpgaminer: You wouldn't need the full 64 bits as half of int64_t is negative numbers
60 2017-05-26 19:52:20 <jonasschnelli> coin values in general can be minus and I think it's just consistency (maybe historical) to use int64_t in TxOut/value
61 2017-05-26 19:52:30 <jonasschnelli> can be *negative
62 2017-05-26 19:53:53 <jonasschnelli> And int64_t is sufficient for ~21M-e8
63 2017-05-26 21:20:24 <fpgaminer> jonasschnelli: Yeah, int64_t is definitely more "convenient" and has many orders of magnitude more space than needed to accommodate.  I guess I was just wondering if there was a more technically interesting reason for int64_t versus uint64_t :P