Transcript for #bitcoin-dev 2017/05/26

01:36 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
01:36 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
05:31 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?
05:34 Agro been reading some docs, if i'm not mistaken, the 0x04 prefix is included
06:08 arubi Agro, you take the 0x02, 0x03 or 0x04 as well yes
06:08 arubi (if you wouldn't 0x02 and 0x03 would be the same)
06:09 Agro ahh got it, thanks! are there any situations where you'd hash the compressed point? haven't seen any yet
06:09 arubi almost all software uses compressed keys now
06:09 arubi there's not reason not to use compressed keys
06:10 Agro ah, but the address is still generated from the uncompressed public key, right?
06:10 Agro p2pkh address
06:10 arubi nope, because again these would become the same address
06:11 arubi a compressed pubkey and uncompressed one have different addresses because their hashes are different
06:12 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
06:12 Agro https://stackoverflow.com/questions/17672696/generating-bitcoin-address-from-ecdsa-public-key http://enetium.com/resources/Bitcoin.pdf
06:12 arubi these are just examples
06:13 arubi in reality, nobody uses uncompressed pubkeys for addresses or scripts
06:13 Agro oh hmm
06:20 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?
06:20 arubi it expects a valid public key
06:21 arubi (and a signature)
06:23 arubi Agro, really just look at any p2pkh transaction in flight right now. they all use compressed keys
06:23 Agro will do
06:26 sictransitgloria hey all, anyone around? my friend is having an issue w/ 14.1 and I haven't seen this before
06:27 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)
06:27 sictransitgloria plenty of space/blocks on drive and CPU/RAM
06:27 sictransitgloria not sure if it's hardware-layer issue but wondering if anyone else has seen this
06:28 sictransitgloria sorry, last line is: 2017-05-26 06:24:22 init message: Loading addresses...
06:30 arubi maybe move the peers.dat file somewhere and try again?
06:37 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
06:37 arubi yep
06:39 Agro thanks for the help, wouldn't have realized that
06:39 arubi cheers Agro
06:40 Agro have a good night!
06:40 sictransitgloria does anyone know offhand what position sendmany puts the change address in?
06:40 arubi night :)
12:29 afk11 anyone know of a public litecoin insight instance?
16:58 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
17:02 arubi Chris_Stewart_5, maybe call bitcoind with the full path?
17:22 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
17:23 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
17:23 arubi well it could in theory
17:24 arubi but so could any other binary :)
17:24 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
17:24 Chris_Stewart_5 https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/requests
17:24 arubi :(
17:25 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...
17:25 arubi maybe you could download the .deb and extract it?
17:25 Chris_Stewart_5 Yeah, i'll try that next.
18:28 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?
18:42 Chris_Stewart_5 fpgaminer: It is an int64_t in the codebase https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L12
19:05 fpgaminer Chris_Stewart_5: Weird. I assume a negative value is never valid, so I wonder why it's int64 in the code?
19:14 Chris_Stewart_5 Good question, there are some test cases that use -1 satoshis
19:20 Chris_Stewart_5 For building crediting transactions for the script_tests.json files
19:22 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!
19:23 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?
19:24 Chris_Stewart_5 I would imagine there is some consensus rule in validation.cpp that states all outputs must have value > 0
19:46 fpgaminer Chris_Stewart_5: Well, it at least needs to be 64-bit
19:49 Chris_Stewart_5 fpgaminer: You wouldn't need the full 64 bits as half of int64_t is negative numbers
19:52 jonasschnelli coin values in general can be minus and I think it's just consistency (maybe historical) to use int64_t in TxOut/value
19:52 jonasschnelli can be *negative
19:53 jonasschnelli And int64_t is sufficient for ~21M-e8
21:20 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