1 2017-11-28 12:52:30 <tomdickharry> hi, i'm trying to find a wallet file on a computer, the file has no extension. im running windows and can't find a hex editor that can search a disk....anyone got any ideas? thanks
  2 2017-11-28 14:52:24 <rgenito> heyyyyy
  3 2017-11-28 14:52:51 <rgenito> how do you use SIGHASH_FORKID in the signature?
  4 2017-11-28 14:53:09 <rgenito> whilst broadcasting for Bitcoin Cash, I'm getting "16: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID). Code:-26"
  5 2017-11-28 14:53:22 <rgenito> been googling around. any tips will be great! I'm doing all of this straight from the command line
  6 2017-11-28 14:59:22 <wumpus> what did you use to sign?
  7 2017-11-28 15:00:13 <wumpus> there are hacks floating around to patch bitcoin core to sign transactions for bch, for example: https://github.com/laanwj/bitcoin/commit/98f79a7243bbc5eccee2649ef19178c1908dc555   then use signrawtransaction with "ALL|ABC"
  8 2017-11-28 15:14:31 <rgenito> wumpus: i used the bitcoin cash version of bitcoin unlimited
  9 2017-11-28 15:15:06 <rgenito> wumpus: https://www.bitcoinunlimited.info/download
 10 2017-11-28 15:15:10 <rgenito> and thank you for the response! :)
 11 2017-11-28 15:19:36 <wumpus> ok can't help you with that
 12 2017-11-28 15:20:36 <wumpus> apparently your client signed the transaction for bitcoin instead of bcash
 13 2017-11-28 15:21:45 <rgenito> wumpus: ah ok, ya.... i'll agree.
 14 2017-11-28 15:22:00 <rgenito> wumpus: what bitcoin cash node do you recommend then for manual transactions? apparently bitcoin unlimited isn't the answer
 15 2017-11-28 15:30:56 <rgenito> wumpus: ok i got bitcoinabc :)
 16 2017-11-28 15:31:10 <rgenito> *sigh*, signing a transaction is now "missing Amount"
 17 2017-11-28 17:04:15 <cluelessperson> Can someone help me understand SegWit from the ground up?
 18 2017-11-28 17:31:54 <mlz> cluelessperson, start with this video:  https://www.youtube.com/watch?v=zchzn7aPQjI&feature=youtu.be&t=101
 19 2017-11-28 17:34:52 <cluelessperson> mlz: thanks
 20 2017-11-28 17:35:17 <cluelessperson> mlz: I've observed that SegWit moves signature information "witness data" into a "SegWit field" in the block
 21 2017-11-28 17:35:33 <cluelessperson> also, I'm confused by something
 22 2017-11-28 17:35:46 <cluelessperson> Are blocks effectively a larger size in bytes as a result of segwit?
 23 2017-11-28 17:36:01 <cluelessperson> segwit has an "effective weight" of 4 million weight units
 24 2017-11-28 17:38:35 <arubi> it's not true that segwit moves script and signature data to a different place in a block.  it does move it to a different place within a transaction, and also commits to all the witness data as an output in the generation transaction
 25 2017-11-28 17:39:14 <arubi> yes for the second question.  it's valid now to have a block that's almost 4 megabytes and made up of almost 4 million witness bytes
 26 2017-11-28 17:39:30 <arubi> it's "almost" because the non witness data would just be the generation transaction itself
 27 2017-11-28 17:48:05 <cluelessperson> arubi: yeah, that's what I meant, sorry.
 28 2017-11-28 17:48:16 <cluelessperson> arubi: What's a generation transaction?
 29 2017-11-28 17:48:32 <arubi> what's usually called coinbase transaction
 30 2017-11-28 17:48:42 <cluelessperson> ah, got it
 31 2017-11-28 17:48:54 <arubi> it's not a good name because "coinbase" is a term in itself
 32 2017-11-28 17:49:09 <arubi> same ambiguity with the term "scriptsig" :(
 33 2017-11-28 17:49:29 <cluelessperson> arubi: I'm confused because some people have almost demanded a blocksize increase, and I believe I saw it reasoned that even 2MB is so much, I don't understand why SegWit enables 4 megabytes
 34 2017-11-28 17:49:34 <cluelessperson> isn't that still too much?
 35 2017-11-28 17:50:44 <arubi> it's a lot yea, I agree
 36 2017-11-28 17:51:29 <cluelessperson> arubi: I feel I've been misled or that I'm still confused.
 37 2017-11-28 17:51:37 <arubi> how so?
 38 2017-11-28 17:54:54 <mlz> arubi, miners can mine their block rewards to a Segwit address, correct?
 39 2017-11-28 17:55:01 <arubi> sure
 40 2017-11-28 18:57:56 <cluelessperson> arubi: Because, we've specifically fought against a block size increase.
 41 2017-11-28 19:01:06 <arubi> well, segwit fixes a lot of issues with just a blunt increase.  this increase is done in a safe way
 42 2017-11-28 19:02:22 <cluelessperson> arubi: What does that mean?  I'm all for fixing transaction malleuability, but I'm concerned with the current transaction system still in place.
 43 2017-11-28 19:02:33 <cluelessperson> people aren't using segwit yet
 44 2017-11-28 19:03:12 <arubi> a block can't have more than 1 megabyte of non witness bytes
 45 2017-11-28 19:03:37 <arubi> it's not the size itself that's the issue, it's validation
 46 2017-11-28 19:03:44 <arubi> and segwit
 47 2017-11-28 19:03:59 <arubi> and segwit's bip143 fixes a lot of validation slowdowns
 48 2017-11-28 19:06:56 <arubi> transaction malleability is fixed just by moving the signature data to the witness area in a transaction.  segwit the software made specific scripts' executed checksig operation to behave in a safer manner when hashing the transaction data
 49 2017-11-28 19:08:01 <cluelessperson> arubi: I don't understand.
 50 2017-11-28 19:10:20 <arubi> it's a lot less resource intensive to validate checksigs in segwit scripts than it is in pre-segwit scripts like p2pkh.  basically pre-segwit checksigs are hashing the transaction in a way where each checksig hashes entirely different data
 51 2017-11-28 19:11:03 <arubi> you have to set up the "sighash" from scratch for each input where a checksig is made, so many inputs and many outputs in a single transaction can get to a very large amount of hashed data
 52 2017-11-28 19:12:39 <arubi> with segwit, you set up the data to be signed in such a way that the vast majority can be re-used by other checksigs (or verifies)
 53 2017-11-28 19:15:26 <arubi> the difference is, say you have an unsigned transaction with 10 inputs, and its size is 1kb, then a verifier would be hashing 10kb of data to check it. 1kb for each checksig in each input
 54 2017-11-28 19:16:08 <arubi> so if the consensus maximum is 20,000 checksigs in a block, and a block size (pre-segwit) is 1 megabyte, then you can guess what the worst case is :)
 55 2017-11-28 19:16:46 <arubi> well, it's a bit less than 1mb*20000, but not by a lot hehe
 56 2017-11-28 19:21:31 <alt0id> hey
 57 2017-11-28 19:21:35 <alt0id> any dev's here?
 58 2017-11-28 19:21:41 <alt0id> devs*
 59 2017-11-28 19:22:08 <alt0id> why does my btc client sometimes stop downloading data when syncing?
 60 2017-11-28 19:24:18 <eck> I have a question about the p2p protocol... for 'addr' messages, am I supposed to use the current timestamp, or the timestamp I last talked to the node I'm advertising?
 61 2017-11-28 19:26:08 <Chris_Stewart_5> alt0id: I'm guessing, but it might be to verify that the blocks you received are correct
 62 2017-11-28 19:26:43 <Chris_Stewart_5> alt0id: I think you could attack a node by sending a BUNCH of data at once, and then let them verify it after the fact
 63 2017-11-28 19:27:12 <Chris_Stewart_5> if you sync x blocks, verify those x blocks, sync x block again, verify x blocks again
 64 2017-11-28 19:27:26 <Chris_Stewart_5> you don't have to worry about that attack vector. Again i am guessing though
 65 2017-11-28 19:28:14 <Chris_Stewart_5> eck: https://bitcoin.org/en/developer-reference#addr
 66 2017-11-28 19:28:27 <Chris_Stewart_5> "Nodes advertising IP addresses they’ve connected to set this to the last time they connected to that node"
 67 2017-11-28 19:28:39 <eck> thanks
 68 2017-11-28 19:28:51 <eck> I was looking at the wiki protocol docs, I should use this instead
 69 2017-11-28 19:28:57 <Chris_Stewart_5> np
 70 2017-11-28 19:58:20 <alt0id> Chris_Stewart_5: so closing/re-connecting is a bad idea?
 71 2017-11-28 20:23:01 <cluelessperson> alt0id: who knows, reorgnization, compression, etc?
 72 2017-11-28 21:13:15 <cluelessperson> Can someone help me understand how to communicate with nodes via python?
 73 2017-11-28 21:13:35 <eck> for the p2p protocol?
 74 2017-11-28 21:13:57 <eck> or the json rpc protocol?
 75 2017-11-28 21:14:37 <eck> this is the de facto standard for python https://github.com/jgarzik/python-bitcoinrpc
 76 2017-11-28 21:14:44 <cluelessperson> eck: the p2p
 77 2017-11-28 21:15:12 <eck> https://github.com/petertodd/python-bitcoinlib
 78 2017-11-28 21:15:21 <cluelessperson> eck: Aren't those both for the rpc?
 79 2017-11-28 21:15:37 <eck> bitcoinlib can parse the p2p network messages
 80 2017-11-28 21:16:06 <cluelessperson> eck: I want to learn how to parse them myself.
 81 2017-11-28 21:16:08 <eck> i am writing a p2p client in c++ right now, the protocol is pretty simple if you want to try to write your own
 82 2017-11-28 21:16:39 <cluelessperson> eck: Yes, that's whta I'm looking for
 83 2017-11-28 21:18:09 <eck> this is what i have so far for the encoding/decoding logic https://github.com/eklitzke/spv/blob/master/src/message.cc
 84 2017-11-28 21:18:27 <eck> https://bitcoin.org/en/developer-reference describes all the messages
 85 2017-11-28 21:19:10 <eck> it would be a lot less code in python due to how much easier reflection is in python
 86 2017-11-28 21:20:15 <cluelessperson> eck: I don't know  ++ :/
 87 2017-11-28 21:21:02 <eck> tl;dr is you do some dns lookups to some seeds, use those to bootstrap your peer list
 88 2017-11-28 21:21:16 <eck> and then it's a pretty simple framed protocol as described in the bitcoin.org docs
 89 2017-11-28 21:21:23 <cluelessperson> eck: how do I connect to and query a node though?
 90 2017-11-28 21:21:31 <cluelessperson> say I hopen a socket
 91 2017-11-28 21:21:55 <eck> you bootstrap the list using dns, then later you get peer announcements from your peers. the peers all listen on a well known port.
 92 2017-11-28 21:22:12 <cluelessperson> eck: I'm having trouble with the communication part
 93 2017-11-28 21:22:16 <cluelessperson> like, how do they wrap messages?
 94 2017-11-28 21:22:24 <eck> it's a framed protocol over tcp
 95 2017-11-28 21:22:35 <cluelessperson> what protocol?
 96 2017-11-28 21:22:41 <eck> the message frame has a magic constant, the message type, the payload length, and a checksum
 97 2017-11-28 21:22:47 <cluelessperson> ah
 98 2017-11-28 21:22:50 <cluelessperson> that's all?
 99 2017-11-28 21:22:52 <eck> custom framed protocol on top of tcp
100 2017-11-28 21:22:57 <eck> well after that there's a payload
101 2017-11-28 21:23:00 <eck> which you need to decode as well
102 2017-11-28 21:23:14 <cluelessperson> decode? you mean deserialize?
103 2017-11-28 21:23:17 <eck> you can skip the message types you don't understand though, since the message header has the payload size
104 2017-11-28 21:26:12 <eck> the protocol is kind of stateful, so if you want to try to write your own client i recommend using an event loop (e.g. tornado for python) to handle timers and whatnot
105 2017-11-28 21:33:08 <cluelessperson> eck: I'm not at all familmiar with tornado
106 2017-11-28 21:33:13 <cluelessperson> eck: what do you mean stateful?
107 2017-11-28 21:56:45 <eck> some of the message types are request/response where you need to remember your request to validate the response, and some things are supposed to be expired from memory after different amounts of time