1 2017-04-18 00:24:54 <achow101> tomatopeel: yes. It's bytes that should have absolutely zero meaning in human readable ascii. In fact, the only places where you will actually see human readable text when converting bytes in Bitcoin related ata to ascii is in p2p message headers, the coinbase, and some OP_RETURN outputs
 2 2017-04-18 05:08:42 <suryab> when I'm creating a p2wkh output in a transaction, does the transaction necessarily have to have a witness associated with it? none of the other inputs/outputs are segwit
 3 2017-04-18 05:09:16 <suryab> i guess i should say, I created an output that is [OP_0, Hash160(pubkey)] and I want to spend that output in another transaction
 4 2017-04-18 05:09:44 <suryab> is that simple script all that needs to be there for me to spend it or does there need to be other information in the output for it?
 5 2017-04-18 05:10:54 <achow101> to create the output, you just put the script in the output. to spend from it, you need to spend from it as specified in the BIPs, by adding stuff to the txwitness field
 6 2017-04-18 05:11:06 <achow101> you do not need a txwitness in the transaction that makes the output
 7 2017-04-18 05:11:21 <suryab> okay cool, thanks
 8 2017-04-18 05:11:31 <suryab> achow101 to the rescue again
 9 2017-04-18 05:16:32 <suryab> so the scriptSig is what is created with spending an output. in the case of p2wkh outputs is the redeemScript just the scripPubKey of the output (i.e. the same OP_0 script?). the bitcoin core segwit dev guide says that the redeeming scriptSig should push only the redeemScript
10 2017-04-18 05:21:07 <suryab> wait not that's wrong redeemscript is something else
11 2017-04-18 05:36:46 <suryab> when trying to spend a p2wkh output, it says the scriptSig must be empty but the witness programm needs to have: <signature> <20-byte-key-hash>. What is the signature calculated over? Looking at the BIP page on github and the segwit dev guide on bitcoin core seems to either be talking about distinct types of outputs or the information is conflicting somehow
12 2017-04-18 05:37:20 <suryab> should mention this is a version 0 p2wkh
13 2017-04-18 05:42:22 <arubi> suryab, here are examples for the simple cases: https://github.com/fivepiece/witness-sig
14 2017-04-18 05:43:02 <arubi> the scriptsig is supposed to be empty for p2wpkh\p2wsh and the redeeming stuff (redeemscript,signature,pubkey) should be in the witness
15 2017-04-18 05:44:01 <arubi> scriptsig will have the witness programitself (the preimage to a p2sh hash160) if the scritpubkeys for p2wsh\p2wpkh are nested in p2sh
16 2017-04-18 05:44:32 <arubi> other than that, the signature is done over the exact same data
17 2017-04-18 05:45:38 <arubi> (I mean, a signature redeeming p2sh(p2wpkh) is the same for just bare p2wpkh, just add the p2sh redeemscript in scriptsig for p2sh() nests)
18 2017-04-18 05:45:47 <suryab> oh perfect, thanks. i'm not nesting my transactions
19 2017-04-18 05:45:55 <arubi> you don't have to really
20 2017-04-18 05:46:03 <suryab> yeah i didn't think so
21 2017-04-18 05:46:22 <suryab> my main goal in creating these txs is so that I can do my experimenting on testnet and get around the ongoing malleability attack
22 2017-04-18 05:47:05 <suryab> so i'm hoping that I'm satisfying the minimum required to get around that, but i suppose it depends on how many nodes on testnet are actually updated to accept/realy segwit transactions
23 2017-04-18 05:47:15 <suryab> relay*
24 2017-04-18 05:47:34 <arubi> segwit is pretty much supported by testnet nodes
25 2017-04-18 05:48:54 <arubi> well, sometimes there are miners who don't include segwit transactions, but eventually it'll get mined.  you can also use a local regtest.  I'm off to work, cya around!
26 2017-04-18 05:49:37 <suryab> thanks for the help!
27 2017-04-18 06:16:08 <suryab> when creating the witness is the only thing in the witness script <signature hash> <20-byte-key-hash> or is there more to add? more importantly, is the signature hash created in the same way over the entire new transaction with SIGHASH_ALL?
28 2017-04-18 11:44:45 <tomatopeel> hey I'm going through this series http://davidederosa.com/basic-blockchain-programming , I'm on the 2nd and 3rd part re: serialization of fixed length and variable length data, the author gives no examples of use cases for this though so it's a bit hard to conceptualise. So what are some examples for use cases for serialization of fixed length and variable length data?
29 2017-04-18 12:47:50 <Chris_Stewart_5> tomatopeel: I'm not sure why they talk about fixed length data, but for variable length data we have a 'VarInt' data structure in the protocol
30 2017-04-18 12:49:48 <Chris_Stewart_5> IIRC it is called 'CVarInt' in bitcoin core
31 2017-04-18 13:13:49 <tomatopeel> oh ty
32 2017-04-18 13:35:37 <Chris_Stewart_5> tomatopeel: An example of variable length data is script signatures. A multisig script signature requires more bytes than a single signature script signature.
33 2017-04-18 18:21:56 <suryab> when is there anything special that I need to include in inv messages when i am sending transactions that have a witness?
34 2017-04-18 18:22:16 <suryab> well... do i include the txid or the wid in the inv message? or both?
35 2017-04-18 18:31:17 <goatpig> txid afaik
36 2017-04-18 18:31:28 <goatpig> if you inv'ing a witness tx
37 2017-04-18 18:31:41 <goatpig> you need to use the witness tx inv packet
38 2017-04-18 18:33:05 <goatpig> which is 1 | (1 << 30)
39 2017-04-18 18:33:22 <goatpig> basically inv_tx type with the witness bit flag
40 2017-04-18 18:38:35 <suryab> okay i guess my new question is that i get bad-txns-vin-empty rejects from most nodes on the network when I just send them a tx message without inv'ing. Is that because of the type of segwit output I'm using (p2wkh) or would that indicate a lack of segwit adoption?
41 2017-04-18 18:39:48 <suryab> is the most common accepted type nesting p2wkh inside of a p2sh?
42 2017-04-18 18:39:53 <suryab> p2sh-p2wkh
43 2017-04-18 18:42:27 <suryab> some testnet block explorers seem to accept it
44 2017-04-18 18:42:43 <suryab> but most nodes, appro 111 of the nodes gave me that reject message
45 2017-04-18 18:47:01 <arubi> I'm sure the type of nesting isn't related
46 2017-04-18 18:47:25 <goatpig> err
47 2017-04-18 18:47:31 <arubi> and block explorers shouldn't be your measure for anything..  it's coincidence that they sometime display the correct data :)
48 2017-04-18 18:47:49 <goatpig> when you ver a node you get to see if its support SW in its services
49 2017-04-18 18:48:39 <goatpig> regardless you should inv before you push a getdata payload
50 2017-04-18 18:49:13 <goatpig> and in particular, the inv type should be inv_tx_witness so at to make sure non supporting nodes don't request the getdata packet
51 2017-04-18 18:50:00 <goatpig> as for your vin-empty issue
52 2017-04-18 18:50:10 <goatpig> it's possible you didn't serialize your tx as SW
53 2017-04-18 18:50:17 <goatpig> are you missing the flag and marker maybe?
54 2017-04-18 18:50:30 <arubi> well I think that the flag is there
55 2017-04-18 18:50:40 <arubi> it "looks" like 0 vin for non segwit nodes
56 2017-04-18 18:50:53 <goatpig> sure but it's suprising to me
57 2017-04-18 18:51:03 <goatpig> the grand majority of nodes on testnet are SW aware
58 2017-04-18 18:51:23 <arubi> yep, that's where I'm lost too
59 2017-04-18 18:51:36 <goatpig> and providing a SW tx from a inv_tx packet should still work
60 2017-04-18 18:51:47 <goatpig> even though it's not "clean" signaling
61 2017-04-18 18:53:17 <arubi> maybe best to see what the transaction being sent is first, maybe it's just not funded correctly and missing any input
62 2017-04-18 18:54:53 <goatpig> at this rate, bounce the tx between 2 of your nodes
63 2017-04-18 19:23:32 <adiabat> arubi: block explorers are a mess but smartbit does seem to work OK with segwit txs
64 2017-04-18 19:24:02 <adiabat> https://testnet.smartbit.com.au/txs/decodetx can be useful to see if their software can parse it
65 2017-04-18 19:25:12 <arubi> adiabat, yep! smarbit does a very good job I agree
66 2017-04-18 19:36:21 <suryab> https://testnet.smartbit.com.au/tx/aa3c950a01e7f40bd5c55b5b410f2e8ab3f0c43ebfc09cfd1ef4d0769b592907
67 2017-04-18 19:36:27 <suryab> http://n.bitcoin.ninja/checktx
68 2017-04-18 19:36:57 <suryab> this is what i used to see if the outputs are interpretted as segwit outputs first off and the second link i was linked to on this irc channel before as a good place to check
69 2017-04-18 19:37:08 <suryab> check validity of transcations that spend seg wit outputs
70 2017-04-18 19:38:41 <suryab> also i should point out that my local node accepts the transaction when i use the sendtrawtransaction rpc call, i know it does some level of validation before checking it
71 2017-04-18 19:40:19 <suryab> transaction that I actually sent out: 010000000001010729599b76d0f41efd9cc0bf3ec4f0b38a2e0f415b5bc5d50bf4e7010a953caa0100000000ffffffff0154150000000000001600149eea64b8d79d147b884cc0a8ec7de357f5dfc9df024730440220784c3ae3e62b6301968e8ca2f43890306fbf782d15ff2ae8ca844735c21825f8022003fe8747d572ed8c73feb4202b306ee7211becc53a005ab047dd69d67ab84538012103b561b2cfad4e639a689c05e3cad6a7e76f8e703a9d47bcf03b89ac9e3ceb25ae00000000
72 2017-04-18 19:42:03 <suryab> after some tinkering the checktx link finally accepted as valid and when i sent it out my local node didn't complain. if it's worth anything the validation on checktx link and my node seems to be similar as they both responded the same way to every serialized tx i put into both (in terms of reject/accept)
73 2017-04-18 19:42:31 <suryab> arubi: yes I've been using smartbit as a sort of validation to see if my segwit outputs are being interpretted correctly
74 2017-04-18 19:43:53 <suryab> meant to ref adiabat
75 2017-04-18 19:47:08 <suryab> deserialized for readability: CTransaction((CTxIn(COutPoint(lx('aa3c950a01e7f40bd5c55b5b410f2e8ab3f0c43ebfc09cfd1ef4d0769b592907'), 1), CScript([]), 0xffffffff),), (CTxOut(0.0000546*COIN, CScript([0, x('9eea64b8d79d147b884cc0a8ec7de357f5dfc9df')])),), 0, 1, CTxWitness(CTxInWitness(CScriptWitness(x('30440220784c3ae3e62b6301968e8ca2f43890306fbf782d15ff2ae8ca844735c21825f8022003fe8747d572ed8c73feb4202b306ee7211becc53a005ab047dd69d67
76 2017-04-18 20:19:42 <arubi> is this redeeming a testnet input?
77 2017-04-18 20:19:56 <arubi> I mean, is the input to this confirmed at all?
78 2017-04-18 20:20:47 <arubi> I don't have it so I'm wondering what's being redeemed here
79 2017-04-18 20:25:56 <arubi> oh I'm sorry, I missed the link ^, now why is the input txid not found
80 2017-04-18 20:26:04 <arubi> AA3C950A01E7F40BD5C55B5B410F2E8AB3F0C43EBFC09CFD1EF4D0769B592907
81 2017-04-18 20:26:07 <arubi> aa3c950a01e7f40bd5c55b5b410f2e8ab3f0c43ebfc09cfd1ef4d0769b592907
82 2017-04-18 20:28:21 <arubi> oh, my fat fingered locally.  sorry
83 2017-04-18 22:37:11 <suryab> back
84 2017-04-18 22:38:06 <suryab> i should've said I'd be gone i probably missed what was said about my question up until someone suggested smartbit block explorer