Transcript for #bitcoin-dev 2017/08/29

01:06 ginseng any good guides out there for using segwit addresses?
01:37 meshcollider Not sure what level of technicality you're after but this is a good guide I guess: https://bitcoincore.org/en/segwit_wallet_dev/
02:35 ginseng this is good, thank you
02:36 ginseng one more q: i am unable to replicate the 9-step procedure for creating a public address from public key found here https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
02:38 ginseng sha256 of the given public key (in step 1) results in 32511E82D56DCEA68EB774094E25BAB0F8BDD9BC1ECA1CEEDA38C7A43ACEDDCE whether i use sha256sum bash command or an online 256sum calculator
02:38 ginseng any ideas?
03:01 esotericnonsense ginseng: you're probably doing the sha256sum on the text rather than on the binary data
03:02 esotericnonsense yes, that is what you're doing
03:03 esotericnonsense ginseng: see https://0bin.net/paste/fj0EhXCYF1Rd4lCq#qhdncCzuSecrKS0amuL3SO+M9FHpENCjdhBln515sGh
03:03 esotericnonsense second value being what you actually want to get
03:14 ginseng esotericnonsense: interesting. i didn't realize hashing was dependent on the encoding of the original data. thanks!
03:15 esotericnonsense ginseng: it must be, otherwise there would be trivial collisions! :)
03:15 esotericnonsense 1234abcd != 1234Abcd
03:16 esotericnonsense to be strictly accurate though it's not 'dependent on the encoding' as such, sha256 always operates on blobs, if you hash 'abcde' it is likely just hashing the ascii representation of it
03:17 esotericnonsense bad example as that could be hex, say 'efghij' :P
03:38 esotericnonsense sa98we
03:38 esotericnonsense oops
03:49 ddustin Why is the test network's block height so much bigger than the main network?
04:00 esotericnonsense ddustin: it has a rule that resets the diff to a very low value if some time has passed since the last block
04:00 ddustin Ah makes sense
04:01 esotericnonsense ddustin: it also has at least one timewarp attack in it
04:30 wallet42 question about median time past
04:30 wallet42 does it has to be strictly increasing for blocks to be valid?
04:31 wallet42 or can it also be equal for a period?
04:31 wallet42 eg. mtp(block0) <= mtp(block1) <=.... or mtp(block0) < mtp(block1)
06:54 luke-jr wallet42: MTP can be equal for up to (IIRC) 5 or 6 blocks in a row
22:10 derek_c Does anyone have insights into why Ethereum uses a structured overlay (Kademlia) for broadcasting, while Bitcoin doesn't?
22:15 ginseng i've been reading about OP_RETURN. i seem to remember a couple of altcoins back in the day (ie. mastercoin) that wanted to store data on the blockchain. is this why this OP_RETURN "compromise" was made by Core and if so are there still any altcoins trying to use the blockchain for this reason?
22:16 esotericnonsense my understanding is that op_return was created because it's not possible to stop people trying to encode data in silly ways (e.g. in unspendable addresses) and it's preferable that the utxo set isn't bloated
22:18 esotericnonsense you might find http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html interesting
22:19 esotericnonsense txid 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 contains bitcoin.pdf in a 200kb tx
22:20 esotericnonsense so that's a fair few kb sitting in the utxo set forever
22:20 ginseng thanks for the link
22:21 ginseng yeah when this discussion was first taking place it seemed to me like it was a wrong use for the blockchain
22:21 ginseng seems to be some strong opinions here as well
22:21 ginseng https://github.com/bitcoin/bitcoin/pull/3737
22:22 ginseng i havent heard much discussion of arbitrary data spam lately, but it looks like it is still used pretty often
22:22 ginseng http://coinsecrets.org/
22:22 esotericnonsense i think timestamping is useful but a suggestion i remember hearing a while back is that if this is going to be a thing, then many hashes should be combined using a merkle tree so that it's only one wasted op_return
22:23 esotericnonsense in general though yes, the less non-transactional data the better