1 2017-04-19 04:36:59 <suryab> NODE_WITNESS = (1 << 3) means that the witness service bit is the 4 bit in the service field?
 2 2017-04-19 04:37:16 <suryab> or does that mean (32-4)th bit in big endian
 3 2017-04-19 04:44:37 <goatpig> where do you get that 3 bit shift?
 4 2017-04-19 04:45:14 <goatpig> nevermind, it's 3
 5 2017-04-19 04:45:28 <goatpig> that;s the service bit thing
 6 2017-04-19 04:45:39 <goatpig> this is a left shift
 7 2017-04-19 04:46:19 <goatpig> so 0x08
 8 2017-04-19 04:47:20 <goatpig> either way you
 9 2017-04-19 04:47:34 <goatpig> you are better off letting the binary comparison do the job for you
10 2017-04-19 04:47:36 <goatpig> than trying to image it
11 2017-04-19 04:47:41 <goatpig> i always get confused with that stuff too
12 2017-04-19 04:48:05 <goatpig> peer_sw = service_bit & (1 << 3)
13 2017-04-19 14:13:57 <Matt_von_Mises> I'm using the regtest in v0.14.0 to test some code and the getblock RPC command with verbose=false is giving weird block data. It seems all OK up until the first transaction but then it gives a transaction version of 2 followed by the additional (hex) bytes of "0001". Does this sound familiar to anyone?
14 2017-04-19 14:43:40 <earlz> In BIP-141 there is a note "the increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore". This is in reference to the birthday problem and RIPEMD-160, correct?
15 2017-04-19 14:46:31 <instagibbs> earlz, yes
16 2017-04-19 14:47:10 <instagibbs> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012204.html
17 2017-04-19 14:52:43 <earlz> interesting, thanks
18 2017-04-19 14:53:08 <earlz> I wonder how that compares to Ethereum's method of making 160bit addresses (SHA3 with the top 12 bytes chopped off)
19 2017-04-19 14:53:43 <Matt_von_Mises> The problem with the random "0001" occurring where the transaction input count should be, is showing in the blk00000.dat. It doesn't appear in every block but when it starts appearing it doesn't seem to stop. So it doesn't appear to be a problem with the RPC command itself, but the block data is being corrupted somehow.
20 2017-04-19 14:54:33 <instagibbs> earlz, you just have to grind a matching pair of 160 bit strings, so likely the same
21 2017-04-19 14:54:56 <instagibbs> eth doesn't have "multisig" addresses per se, so I'm unsure how all that interacts
22 2017-04-19 14:58:57 <earlz> yea, it uses contracts and such for multisig. But the addresses used on the blockchain are 160bit, it's just sha3(pubkey) with the top 12 bytes cut off.. so I guess to really get any monetary gain you'd have to find a pubkey that matches a collision, which I imagine is still a bit beyond what's possible
23 2017-04-19 15:03:55 <Matt_von_Mises> This is the result of getrawtransaction: https://pastebin.com/raw/GNCXsu6b
24 2017-04-19 15:05:14 <instagibbs> earlz, attacking a particular p2pkh/keyhash means you have to grind out all the work(2^(n-1) ?), not just 2^(n/2)
25 2017-04-19 15:05:40 <earlz> oh right, that is true
26 2017-04-19 15:06:17 <instagibbs> in the p2sh case you before you have given your victim your pubkey you can grind out a colliding pair where it just pays you.
27 2017-04-19 15:06:25 <instagibbs> (IIRC)
28 2017-04-19 15:07:07 <instagibbs> ie pick a pubkey that creates an address that collides with a "pay me" p2sh address
29 2017-04-19 15:07:18 <earlz> yea, but other than that you can't just steal funds off of some unknown output ont he blockchain
30 2017-04-19 15:08:23 <Matt_von_Mises> I'm guessing the new SegWit changes have changed the format of the block data returned by getblocks and stored in blk00000.dat?
31 2017-04-19 15:10:51 <instagibbs> earlz, correct, it's an active attack, but serious enough that we should just pay for the space hit
32 2017-04-19 15:21:30 <Matt_von_Mises> I can confirm that the problem with blocks occurs when segwit activates on regtest and not before. Segwit may break software that uses the getblock RPC command for raw blocks. Developers should have been warned about this particular problem. I did not see any mention of it.
33 2017-04-19 15:23:19 <bsm117532> I'd say that should be patently obvious.
34 2017-04-19 15:30:32 <Matt_von_Mises> The changes to getblocktemplate are mentioned but not getblock: https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/ It's not obvious unless one has looked at segwit into detail. And even then one might assume getblock to continue to return the old format unless otherwise told.
35 2017-04-19 15:30:53 <bsm117532> You get a "raw" block, that's on you to interpret...
36 2017-04-19 15:33:06 <Matt_von_Mises> Well it's nice to know when it changes, to avoid headaches when updating the version.
37 2017-04-19 15:34:31 <bsm117532> Definitely should be mentioned in docs...
38 2017-04-19 15:36:30 <instagibbs> Matt_von_Mises, recent releases have an option to return legacy raw blocks
39 2017-04-19 15:37:57 <instagibbs> https://github.com/bitcoin/bitcoin/pull/9194
40 2017-04-19 15:38:07 <instagibbs> "-rpcserialversion=0"
41 2017-04-19 15:40:50 <Matt_von_Mises> instagibbs: OK thanks. I didn't know about that. I'll use that for now and add in segwit support when I can.
42 2017-04-19 15:41:32 <instagibbs> Exactly why it was added. Good luck
43 2017-04-19 15:42:05 <bsm117532> Matt_von_Mises: many back-end tools already support it.  bcoin does, and I've added support for python-bitcoinlib: https://github.com/petertodd/python-bitcoinlib/pull/112
44 2017-04-19 15:50:38 <Matt_von_Mises> bsm117532: OK thanks, I may take a look.
45 2017-04-19 17:42:33 <suryab> does a node always repond to a version message with a version message even after the connection is established and handshake is done
46 2017-04-19 17:42:34 <suryab> ?
47 2017-04-19 21:16:00 <goatpig> not you only get a the verack the first time around
48 2017-04-19 21:52:50 <ProfMac> When I install the source and work on it, where in the filesystem should I install it?  ~/gitstuff/bitcoin  /usr/local/opt/bitcoin
49 2017-04-19 21:54:20 <suryab> in bitcoin core it says nodes realy op_return transactions up to 80 bytes. Does that mean for every output whose scriptPubKey has an OP_RETURN in it, the data coming after it can be at most 80 bytes or is there some other meaning to this?
50 2017-04-19 22:22:56 <abpa> suryab you can only have 1 output like that right?
51 2017-04-19 22:23:49 <suryab> i didn't know that actually
52 2017-04-19 22:23:50 <suryab> okay
53 2017-04-19 22:24:08 <suryab> hmmm, only 1 op_return output per transaction
54 2017-04-19 22:24:33 <abpa> Storing lots of data in the blockchain is discouraged
55 2017-04-19 22:26:17 <suryab> i've wondered how things like blockstack work then
56 2017-04-19 22:26:27 <suryab> do they just spend substantially more money to store data?
57 2017-04-19 22:26:53 <suryab> because they do a naming service that is authenticated but they store their information on the chain
58 2017-04-19 22:27:20 <suryab> maybe there's some way i can condense the signature + hash into 8- bytes
59 2017-04-19 22:27:23 <suryab> 80-bytes
60 2017-04-19 22:27:32 <abpa> There's no good reason to store lots of data on the blockchain
61 2017-04-19 22:27:56 <suryab> well yeah, i don't plan on using it as the main data backend of what I'm doing
62 2017-04-19 22:28:01 <abpa> If you have lots of data just use a merkle tree
63 2017-04-19 22:28:08 <suryab> yeah
64 2017-04-19 22:28:24 <suryab> basically i want to publish signatures and hashes for verification purposes
65 2017-04-19 22:28:49 <suryab> but yeah, merkle tree meets that rec