1 2017-08-29 01:06:45 <ginseng> any good guides out there for using segwit addresses?
 2 2017-08-29 01:37:52 <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/
 3 2017-08-29 02:35:31 <ginseng> this is good, thank you
 4 2017-08-29 02:36:49 <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
 5 2017-08-29 02:38:34 <ginseng> sha256 of the given public key (in step 1) results in 32511E82D56DCEA68EB774094E25BAB0F8BDD9BC1ECA1CEEDA38C7A43ACEDDCE whether i use sha256sum bash command or an online 256sum calculator
 6 2017-08-29 02:38:37 <ginseng> any ideas?
 7 2017-08-29 03:01:36 <esotericnonsense> ginseng: you're probably doing the sha256sum on the text rather than on the binary data
 8 2017-08-29 03:02:34 <esotericnonsense> yes, that is what you're doing
 9 2017-08-29 03:03:38 <esotericnonsense> ginseng: see https://0bin.net/paste/fj0EhXCYF1Rd4lCq#qhdncCzuSecrKS0amuL3SO+M9FHpENCjdhBln515sGh
10 2017-08-29 03:03:55 <esotericnonsense> second value being what you actually want to get
11 2017-08-29 03:14:11 <ginseng> esotericnonsense: interesting. i didn't realize hashing was dependent on the encoding of the original data. thanks!
12 2017-08-29 03:15:07 <esotericnonsense> ginseng: it must be, otherwise there would be trivial collisions! :)
13 2017-08-29 03:15:23 <esotericnonsense> 1234abcd != 1234Abcd
14 2017-08-29 03:16:42 <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
15 2017-08-29 03:17:16 <esotericnonsense> bad example as that could be hex, say 'efghij' :P
16 2017-08-29 03:38:37 <esotericnonsense> sa98we
17 2017-08-29 03:38:44 <esotericnonsense> oops
18 2017-08-29 03:49:48 <ddustin> Why is the test network's block height so much bigger than the main network?
19 2017-08-29 04:00:20 <esotericnonsense> ddustin: it has a rule that resets the diff to a very low value if some time has passed since the last block
20 2017-08-29 04:00:43 <ddustin> Ah makes sense
21 2017-08-29 04:01:09 <esotericnonsense> ddustin: it also has at least one timewarp attack in it
22 2017-08-29 04:30:29 <wallet42> question about median time past
23 2017-08-29 04:30:51 <wallet42> does it has to be strictly increasing for blocks to be valid?
24 2017-08-29 04:31:13 <wallet42> or can it also be equal for a period?
25 2017-08-29 04:31:45 <wallet42> eg. mtp(block0) <= mtp(block1) <=.... or mtp(block0) < mtp(block1)
26 2017-08-29 06:54:30 <luke-jr> wallet42: MTP can be equal for up to (IIRC) 5 or 6 blocks in a row
27 2017-08-29 22:10:53 <derek_c> Does anyone have insights into why Ethereum uses a structured overlay (Kademlia) for broadcasting, while Bitcoin doesn't?
28 2017-08-29 22:15:25 <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?
29 2017-08-29 22:16:46 <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
30 2017-08-29 22:18:16 <esotericnonsense> you might find http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html interesting
31 2017-08-29 22:19:18 <esotericnonsense> txid 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 contains bitcoin.pdf in a 200kb tx
32 2017-08-29 22:20:02 <esotericnonsense> so that's a fair few kb sitting in the utxo set forever
33 2017-08-29 22:20:48 <ginseng> thanks for the link
34 2017-08-29 22:21:10 <ginseng> yeah when this discussion was first taking place it seemed to me like it was a wrong use for the blockchain
35 2017-08-29 22:21:32 <ginseng> seems to be some strong opinions here as well
36 2017-08-29 22:21:33 <ginseng> https://github.com/bitcoin/bitcoin/pull/3737
37 2017-08-29 22:22:37 <ginseng> i havent heard much discussion of arbitrary data spam lately, but it looks like it is still used pretty often
38 2017-08-29 22:22:39 <ginseng> http://coinsecrets.org/
39 2017-08-29 22:22:57 <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
40 2017-08-29 22:23:16 <esotericnonsense> in general though yes, the less non-transactional data the better