Transcript for #bitcoin-dev 2017/04/19

04:36 suryab NODE_WITNESS = (1 << 3) means that the witness service bit is the 4 bit in the service field?
04:37 suryab or does that mean (32-4)th bit in big endian
04:44 goatpig where do you get that 3 bit shift?
04:45 goatpig nevermind, it's 3
04:45 goatpig that;s the service bit thing
04:45 goatpig this is a left shift
04:46 goatpig so 0x08
04:47 goatpig either way you
04:47 goatpig you are better off letting the binary comparison do the job for you
04:47 goatpig than trying to image it
04:47 goatpig i always get confused with that stuff too
04:48 goatpig peer_sw = service_bit & (1 << 3)
14:13 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:43 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?
14:46 instagibbs earlz, yes
14:47 instagibbs
14:52 earlz interesting, thanks
14:53 earlz I wonder how that compares to Ethereum's method of making 160bit addresses (SHA3 with the top 12 bytes chopped off)
14:53 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.
14:54 instagibbs earlz, you just have to grind a matching pair of 160 bit strings, so likely the same
14:54 instagibbs eth doesn't have "multisig" addresses per se, so I'm unsure how all that interacts
14:58 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
15:03 Matt_von_Mises This is the result of getrawtransaction:
15:05 instagibbs earlz, attacking a particular p2pkh/keyhash means you have to grind out all the work(2^(n-1) ?), not just 2^(n/2)
15:05 earlz oh right, that is true
15:06 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.
15:06 instagibbs (IIRC)
15:07 instagibbs ie pick a pubkey that creates an address that collides with a "pay me" p2sh address
15:07 earlz yea, but other than that you can't just steal funds off of some unknown output ont he blockchain
15:08 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?
15:10 instagibbs earlz, correct, it's an active attack, but serious enough that we should just pay for the space hit
15:21 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.
15:23 bsm117532 I'd say that should be patently obvious.
15:30 Matt_von_Mises The changes to getblocktemplate are mentioned but not getblock: 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.
15:30 bsm117532 You get a "raw" block, that's on you to interpret...
15:33 Matt_von_Mises Well it's nice to know when it changes, to avoid headaches when updating the version.
15:34 bsm117532 Definitely should be mentioned in docs...
15:36 instagibbs Matt_von_Mises, recent releases have an option to return legacy raw blocks
15:37 instagibbs
15:38 instagibbs "-rpcserialversion=0"
15:40 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.
15:41 instagibbs Exactly why it was added. Good luck
15:42 bsm117532 Matt_von_Mises: many back-end tools already support it. bcoin does, and I've added support for python-bitcoinlib:
15:50 Matt_von_Mises bsm117532: OK thanks, I may take a look.
17:42 suryab does a node always repond to a version message with a version message even after the connection is established and handshake is done
17:42 suryab ?
21:16 goatpig not you only get a the verack the first time around
21:52 ProfMac When I install the source and work on it, where in the filesystem should I install it? ~/gitstuff/bitcoin /usr/local/opt/bitcoin
21:54 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?
22:22 abpa suryab you can only have 1 output like that right?
22:23 suryab i didn't know that actually
22:23 suryab okay
22:24 suryab hmmm, only 1 op_return output per transaction
22:24 abpa Storing lots of data in the blockchain is discouraged
22:26 suryab i've wondered how things like blockstack work then
22:26 suryab do they just spend substantially more money to store data?
22:26 suryab because they do a naming service that is authenticated but they store their information on the chain
22:27 suryab maybe there's some way i can condense the signature + hash into 8- bytes
22:27 suryab 80-bytes
22:27 abpa There's no good reason to store lots of data on the blockchain
22:27 suryab well yeah, i don't plan on using it as the main data backend of what I'm doing
22:28 abpa If you have lots of data just use a merkle tree
22:28 suryab yeah
22:28 suryab basically i want to publish signatures and hashes for verification purposes
22:28 suryab but yeah, merkle tree meets that rec