1 2015-08-17 00:30:00 <c4pt> the blockchain is getting massive around 80gb ?
  2 2015-08-17 00:30:54 <c4pt> ?
  3 2015-08-17 00:33:44 <c4pt> is there a lightweight version of bitcoin-qt that use blockchain.info as a backend to load the blockchain ? or can the blockchain be truncated safely for a lightweight version of bitcoin-qt / bitcoind ?
  4 2015-08-17 00:34:54 <Luke-Jr> c4pt: Electrum?
  5 2015-08-17 00:35:21 <c4pt> Luke-Jr, bitcoin-qt / bitcoind does it better electrum is nice but bitcoin-qt / bitcoind is the original
  6 2015-08-17 00:36:03 <Luke-Jr> c4pt: well, not supported at this time
  7 2015-08-17 00:36:43 <c4pt> it would be decent to have split versions something thats use a lightweight amount of data and something does will fetch the entire blockchain
  8 2015-08-17 00:37:42 <Luke-Jr> 0.11 supports pruning as it downloads, but this isn't very useful yet
  9 2015-08-17 00:37:43 <alpalp> Can't you use the -prune option?
 10 2015-08-17 00:37:50 <alpalp> arg my pony too slow
 11 2015-08-17 00:38:03 <Luke-Jr> :p
 12 2015-08-17 00:38:44 <alpalp> luke-jr: why is it not useful yet?
 13 2015-08-17 00:38:53 <c4pt> wheres the trust there could be a version that queries blockchain.info transaction data
 14 2015-08-17 00:38:53 <Luke-Jr> alpalp: it only works for mining
 15 2015-08-17 00:39:18 <alpalp> ah, found the text
 16 2015-08-17 00:39:22 <alpalp> wallet incompatible with it
 17 2015-08-17 00:39:29 <Luke-Jr> c4pt: blockchain.info is merely misinformation; using it will almost certainly never be supported
 18 2015-08-17 00:40:20 <c4pt> Luke-Jr, i dont really agree thats its misinformation its confirms every transaction i have sent or received
 19 2015-08-17 00:41:24 <alpalp> c4pt: Except it's not accurate, it will tell you that someone spent Satoshi's coins for example
 20 2015-08-17 00:41:28 <c4pt> maybe a split version one version that will download the entire blockchain data and another version the pulls the data from http to make it lightweight
 21 2015-08-17 00:41:37 <midnightmagic> c4pt: This isn't really the place for that sort of discussion. Please take it to #bitcoin.
 22 2015-08-17 00:41:42 <c4pt> ok
 23 2015-08-17 03:14:45 <dcousens> Will the HK meet at http://scalingbitcoin.org/ be as worth while as the montreal?
 24 2015-08-17 03:16:21 <dcousens> Never mind,  its not a repeat, but two distinct phases. Ignore
 25 2015-08-17 05:56:22 <dcousens> Is there any way to do   multisig using PUBKEYHASH's alone?
 26 2015-08-17 05:56:45 <dcousens> I assume now,  but,  fundamentally it could be possible with a new OP code to support it?
 27 2015-08-17 05:56:53 <dcousens> s/now/not*
 28 2015-08-17 05:57:35 <CodeShark> there's no way to check a signature without having the full public key
 29 2015-08-17 05:57:52 <CodeShark> so it needs to be somewhere
 30 2015-08-17 05:58:03 <dcousens> CodeShark: no doubt
 31 2015-08-17 05:58:17 <CodeShark> so I'm not sure what you're asking
 32 2015-08-17 05:59:54 <CodeShark> you mean instead of using p2sh using the pubkey hashes themselves as a kind of "address"?
 33 2015-08-17 05:59:57 <dcousens> It was more of a speculation, an idea, then it was a question, sorry.   I meant,  it would be interesting if you could do:   `OP_2 HASH160 HASH160 HASH160 OP_3 OP_CHECKMULTISIGHASH`.
 34 2015-08-17 06:00:41 <dcousens> And I was just curious if anyone had thought about something similar
 35 2015-08-17 06:01:29 <dcousens> And say, it only gets verified with compact signatures (or maybe the pubkey is inlined,  like a P2PKH script sig)
 36 2015-08-17 06:02:47 <CodeShark> are you talking about putting the pubkey hashes in the transaction output rather than the input?
 37 2015-08-17 06:03:01 <CodeShark> still confused
 38 2015-08-17 06:03:13 <CodeShark> I don't understand what it is you're trying to accomplish
 39 2015-08-17 06:04:00 <dcousens> CodeShark: I'm curious if you can do traditional multisignature without exposing the full public keys to each other
 40 2015-08-17 06:04:30 <dcousens> until a spend occurs
 41 2015-08-17 06:04:45 <CodeShark> that's how p2sh multisig currently works
 42 2015-08-17 06:04:56 <CodeShark> or hmm
 43 2015-08-17 06:05:14 <CodeShark> you're talking about two different parties being able to, say, construct a 2-of-2 p2sh without knowing each other's public keys?
 44 2015-08-17 06:05:48 <dcousens> correct
 45 2015-08-17 06:07:37 <CodeShark> I think you can
 46 2015-08-17 06:08:20 <CodeShark> push the full pubkeys before the redeemscript, in the redeemscript first check the hashes using OP_EQUALVERIFY and then check the signatures
 47 2015-08-17 06:10:04 <dcousens> True
 48 2015-08-17 06:18:26 <dcousens> CodeShark: hmmm
 49 2015-08-17 06:21:31 <dcousens> It would just be 3 PKH scripts concatenated?
 50 2015-08-17 06:21:48 <dcousens> Doesn't really help with the nOfm part
 51 2015-08-17 06:23:25 <CodeShark> for a 2-of-2 redeemscript I think you could do something like [ OP_DUP OP_HASH160 <hash 1> OP_EQUALVERIFY OP_DROP OP_TOALTSTACK ] [ OP_DUP OP_HASH160 <hash 2> OP_EQUALVERIFY OP_DROP ] OP_FROMALTSTACK OP_2 OP_CHECKMULTISIG
 52 2015-08-17 06:24:07 <dcousens> scriptPubKey: OP_HASH160 <pubKeyHash1> OP_EQUALVERIFY OP_HASH160 <pubKeyHash2> OP_EQUALVERIFY  OP_HASH160 <pubKeyHash3> OP_EQUALVERIFY  m [pubKeys ...] n OP_CHECKMULTISIG
 53 2015-08-17 06:24:07 <dcousens> scriptSig: OP_0 signature1 signature3 pubKey1 pubKey3 pubKey1 pubKey2 pubKey3
 54 2015-08-17 06:24:07 <dcousens> unless you just did extra data:
 55 2015-08-17 06:24:41 <CodeShark> then the full signed input would be OP_0 <sig 1> <sig 2> OP_2 <pubkey 1> <pubkey 2>
 56 2015-08-17 06:24:43 <dcousens> heh, OP_TOALTSTACK, TIL,  sec,  need to read what htat is
 57 2015-08-17 06:24:50 <CodeShark> then the full signed input would be OP_0 <sig 1> <sig 2> OP_2 <pubkey 1> <pubkey 2> { redeemscript }
 58 2015-08-17 06:25:15 <CodeShark> I got the hashes backwards, but I think that's basically the gist
 59 2015-08-17 06:26:32 <dcousens> what is OP_DROP dropping in the above?
 60 2015-08-17 06:26:46 <CodeShark> the result of OP_EQUAL, which places a value of true or false at the top of the stack
 61 2015-08-17 06:27:03 <dcousens> right, does that not drop with OP_VERIFY?
 62 2015-08-17 06:27:05 <CodeShark> to generalize to m-of-n you'll need some OP_IF
 63 2015-08-17 06:27:25 <phantomcircuit> dcousens, yes you simply exchange hashes and have the script validate the hashes
 64 2015-08-17 06:28:07 <phantomcircuit> iirc this is limited the the max size of the transactions
 65 2015-08-17 06:28:59 <CodeShark> transactions have max sig ops...but isn't the transaction's actual size only limited by block size?
 66 2015-08-17 06:29:29 <dcousens> P2SH redeem scripts are limited iirc
 67 2015-08-17 06:33:18 <dcousens> and these would all be non-standard?
 68 2015-08-17 06:33:21 <dcousens> in any case?
 69 2015-08-17 06:33:27 <phantomcircuit> CodeShark, P2SH redeem scripts are limited by the maximum OP_PUSH which is like 520 bytes or something
 70 2015-08-17 06:33:45 <phantomcircuit> dcousens, yes
 71 2015-08-17 06:34:12 <CodeShark> the term non-standard is annoying :p
 72 2015-08-17 06:34:41 <dcousens> more like,  not-yet-relayed-by-most-nodes,  but minable
 73 2015-08-17 06:34:56 <CodeShark> right
 74 2015-08-17 06:35:34 <dcousens> what was the original intention behind limiting op codes?
 75 2015-08-17 06:35:46 <CodeShark> DoS prevention
 76 2015-08-17 06:35:49 <dcousens> Just a attack surface issue?
 77 2015-08-17 06:36:10 <CodeShark> or are you talking about OP codes that are currently disabled?
 78 2015-08-17 06:36:26 <CodeShark> you're talking about op counts?
 79 2015-08-17 06:36:45 <dcousens> I meant,  only allowing some transactions to be 'standard'
 80 2015-08-17 06:37:05 <CodeShark> legacy
 81 2015-08-17 06:37:55 <dcousens> Is there any reason to not allow non-standard transactions be prevalent now?
 82 2015-08-17 06:41:28 <CodeShark> I never quite understood the reasoning behind the script roll-out process
 83 2015-08-17 06:42:11 <CodeShark> why would a transaction be minable but not relayable?
 84 2015-08-17 06:43:01 <CodeShark> anyone here know the answer?
 85 2015-08-17 06:44:46 <CodeShark> I mean, it's clear that spamming a bunch of transactions to be relayed is cheaper than mining them...but it seems like a very tenuous anti-DoS measure at best
 86 2015-08-17 06:47:57 <dcousens> CodeShark: probably one of those things where because all nodes aren't miners,  the incentives of propagating/verifying more complex transactions doesn't line up,  since nodes don't have any incentive to relay them?
 87 2015-08-17 06:48:18 <CodeShark> that doesn't really make sense, though
 88 2015-08-17 06:48:50 <CodeShark> then the relay policy should be solely based on evaluation cost, not whether it's "standard" or not
 89 2015-08-17 06:49:00 <CodeShark> i.e. sig op counts
 90 2015-08-17 06:49:28 <dcousens> wumpus: ?
 91 2015-08-17 06:49:33 <dcousens> Any ideas
 92 2015-08-17 06:52:01 <CodeShark> I can understand for a turing-complete language you might have script templates with known execution cost bounds
 93 2015-08-17 06:52:41 <CodeShark> but in this case it's not that hard in most instances to compute this upper execution cost bound without actually doing the execution
 94 2015-08-17 06:53:36 <dcousens> in most instances?  isn't the point of using the stack based DSL so that way it was possible to count easily?
 95 2015-08-17 06:55:04 <CodeShark> as opposed to a register machine?
 96 2015-08-17 06:56:19 <CodeShark> I would think conditional branching is what most complicates cost evaluation
 97 2015-08-17 08:39:03 <mjerr> Is there something similar to the HD technique of bip32 to usual hashes? like having a master pubkey that you can calculate all the hashes for, and a master privkey, that can calculate the preimages+
 98 2015-08-17 08:39:57 <mjerr> My understanding is that this would be very difficult, since bip32 builds upon the fact, that private->public is just a simple mathematic operation
 99 2015-08-17 08:40:06 <mjerr> while preimage->hash is much more complicated
100 2015-08-17 08:40:13 <mjerr> but just in case I'm missing something
101 2015-08-17 08:40:19 <olalonde> CodeShark: I think the original idea was political
102 2015-08-17 08:53:38 <CodeShark> olalonde: political?
103 2015-08-17 08:53:41 <CodeShark> how so?
104 2015-08-17 09:12:30 <olalonde> I just recall there were heated debates about what the blockchain should be used for
105 2015-08-17 09:12:55 <olalonde> Probably the main reason was for security though as most op codes hadn't been extensively used/tested
106 2015-08-17 09:16:41 <gmaxwell> CodeShark: uh. the purpose of IsStandard has changed over time. Right now the purpose it serves is preserving forward compatiblity features to enable safe soft forks.
107 2015-08-17 09:17:10 <gmaxwell> (because if you try to softfork in something in a space where miners will include transactions much more turbulance results.
108 2015-08-17 09:17:48 <gmaxwell> at least if you use P2SH the only opcode stuff blocked by standness checks should be the forward-compatibility features.
109 2015-08-17 09:18:16 <dcousens> "preserving forward compatibility features", could you elaborate?
110 2015-08-17 09:18:22 <gmaxwell> olalonde: and no, it was never political there was just an issue with actual software flaws and broken code.
111 2015-08-17 09:18:44 <gmaxwell> (and resource consumption attacks and such, most of script had no tests previously)
112 2015-08-17 09:24:51 <CodeShark> what a mess :p
113 2015-08-17 09:33:08 <hdbuck> dam you gavin
114 2015-08-17 09:35:30 <mjerr> gmaxwell, can you think of a way to have a similar technique like bip32 for hashes?  http://i.imgur.com/WDdD9lK.png
115 2015-08-17 09:35:48 <CohibAA> random question... from bitcoin-cli getnetworkinfo, how is "score" calculated?  help just says "relative score" :/
116 2015-08-17 13:18:07 <wumpus> CohibAA: very simple: every incoming connection that mentions the local address is counted as 1
117 2015-08-17 14:35:08 <lolcat> Will the block size increase?
118 2015-08-17 14:41:12 <Lightsword> lolcat, the XT fork is unlikely to gain miner support
119 2015-08-17 14:42:36 <hdbuck> screw you USGavin & Googlhearn
120 2015-08-17 14:51:15 <lolcat> Lightsword: will we get the lightning crap?
121 2015-08-17 14:51:32 <afk11> lolcat: not soon.
122 2015-08-17 14:52:02 <lolcat> What if I want to send 15k transactions per day?
123 2015-08-17 14:52:05 <Lightsword> lolcat, hard to say, I’m not saying there won’t be a block size increase I’m saying the XT fork and xt exponentialy increasing block sizes are very unlikely to be accepted by miners
124 2015-08-17 14:54:35 <Aquentin> miners would risk becoming employees of hubs though if they don't go with an increase of the blocksize
125 2015-08-17 14:55:21 <Aquentin> and they all support 8mb - no one has yet commented on 8mb plus % increase
126 2015-08-17 14:55:21 <Lightsword> Aquentin, miners aren’t neccesarially against a block size increase they are against XT blocks however
127 2015-08-17 14:57:38 <Lightsword> Aquentin, we will have to see what sort of compromise we can get in regards to a block size increase since the XT hard fork is very unlikely to be succesful
128 2015-08-17 14:58:35 <Aquentin> the compromise you'll get is 2mb in 20 years
129 2015-08-17 14:58:57 <Aquentin> not sure why anyone would want to fork for that
130 2015-08-17 14:59:44 <Lightsword> Aquentin, the XT fork will just not happen, if you think it will you aren’t being realistic, there will likely be some compromise eventually, maybe BIP100
131 2015-08-17 15:00:15 <Aquentin> BIP 100 guarantees another fork which no one wants
132 2015-08-17 15:00:57 <chmod755> the original BIP 100 was good
133 2015-08-17 15:01:17 <Lightsword> Aquentin, so what realistic proposals do you see that may get miner support?
134 2015-08-17 15:01:33 <Aquentin> well, if this was negotiation and it is
135 2015-08-17 15:02:05 <Lightsword> Aquentin, this isn’t a negotiation where all sides have equal say, only the miners can vote
136 2015-08-17 15:02:36 <Aquentin> we opened with 20, they should have moved to 2, we then went down to 8 because thats what the miners asked, so meeting in the middle is 4mb to start with
137 2015-08-17 15:02:43 <Aquentin> then maybe 20% yearly increase
138 2015-08-17 15:02:55 <chmod755> 4 is too low
139 2015-08-17 15:03:03 <Lightsword> Aquentin, the yearly increase is unlikely to be acepted by miners if it goes too high
140 2015-08-17 15:03:10 <Aquentin> yeh and they say its too high
141 2015-08-17 15:03:13 <Aquentin> that's compromise
142 2015-08-17 15:03:33 <Aquentin> Lightsword how else do you avoid another fork?
143 2015-08-17 15:03:33 <Lightsword> Aquentin, so what would you say a reasonable compromise is? static 8MB blocks without increase?
144 2015-08-17 15:03:39 <Aquentin> no
145 2015-08-17 15:03:45 <Aquentin> 4mb with 20% yearly increase
146 2015-08-17 15:03:55 <Lightsword> Aquentin, and when is that 4mb capped?
147 2015-08-17 15:03:56 <Aquentin> and I wouldnt compromise any further on that tbh
148 2015-08-17 15:04:17 <Lightsword> the miners will reject uncapped exponential increases
149 2015-08-17 15:04:31 <Aquentin> erm maybe 1gb -dunno about the cap
150 2015-08-17 15:04:38 <Lightsword> thats way too high
151 2015-08-17 15:04:44 <Aquentin> in 20 years?
152 2015-08-17 15:04:55 <Lightsword> miners won’t agree to anything they already can’t handle
153 2015-08-17 15:05:01 <Aquentin> it's no way too high, 1gb will be what 1mb is now by then
154 2015-08-17 15:05:07 <Lightsword> or aren’t quite sure they can handle
155 2015-08-17 15:05:34 <Aquentin> maybe these miners should put forward some proposals?
156 2015-08-17 15:05:36 <Aquentin> officially
157 2015-08-17 15:05:37 <Lightsword> Aquentin, miners will be conservative, they will not rely on those types of predictions
158 2015-08-17 15:05:41 <Lightsword> Aquentin, they did
159 2015-08-17 15:05:44 <Lightsword> 8MB static blocks
160 2015-08-17 15:05:52 <Lightsword> is what the chinese pools proposed
161 2015-08-17 15:05:58 <Aquentin> well it wasn't accepted by gmaxwell and pieter I'm afraid
162 2015-08-17 15:06:17 <Lightsword> well, XT wasn’t accepted by the miners so we maybe need to find something else like BIP100
163 2015-08-17 15:06:31 <Aquentin> they haven't said so yet
164 2015-08-17 15:06:43 <Aquentin> and if they do they should make their reasons known and put forward an offer
165 2015-08-17 15:06:58 <Aquentin> xt could be changed I should think, but core seems to have no hope of changing
166 2015-08-17 15:07:24 <Lightsword> Aquentin they publicly rejected the XT fork
167 2015-08-17 15:07:26 <helo> #bitcoin, please
168 2015-08-17 15:07:44 <Aquentin> helo Lightsword claims to be a pool admin
169 2015-08-17 15:08:06 <Aquentin> and since this blocksize debate it is hugley important I should think it is relevant to bitcoin development specifically
170 2015-08-17 15:08:21 <helo> doesn't matter who is offtopic, blocksize debates don't belong in here for now
171 2015-08-17 15:08:40 <Lightsword> Aquentin, this probably isn’t the right channel to discuss this
172 2015-08-17 15:08:59 <Aquentin> I said what I wanted I think
173 2015-08-17 15:09:06 <chmod755> #bitcoin-blocksize
174 2015-08-17 15:09:33 <Aquentin> as for miners rejecting xt that was some article by coin telegraph
175 2015-08-17 15:09:34 <helo> that's probably even better
176 2015-08-17 15:09:42 <Aquentin> they were talking about contentious forks not block sizes
177 2015-08-17 15:09:55 <Aquentin> if 75% of miners move - prob everyone else will - so no contention
178 2015-08-17 15:10:24 <Aquentin> then blockstream can keep working on sidechain which is what they are paid to do anyway
179 2015-08-17 15:30:34 <helo> Aquentin: 75% is not "no contention"
180 2015-08-17 15:30:49 <helo> 75% doesn't mean landslide to 100%
181 2015-08-17 15:31:10 <helo> if it did, why not make the threshold 100%?
182 2015-08-17 15:31:39 <helo> bah, wrong channel -.-
183 2015-08-17 19:10:40 <bedeho> When a signature appears in a scriptSig, a sighash_type flag is appended to it, correct? Is it also the case that the sighash itself has the sighash_type flag appended to it before the signature is generated?
184 2015-08-17 19:11:45 <bedeho> that is, is it DER signature = compute_signature(hash(tx.serialized() || sighash_type))
185 2015-08-17 19:12:00 <bedeho> or is it DER signature = compute_signature(hash(tx.serialized()))
186 2015-08-17 19:19:53 <drazisil> if I wanted to export the tx blockchain, is there a more efficient way then parsing each block for it's tx, or is that how core's index does it?
187 2015-08-17 19:23:23 <warren> drazisil: that's necessary
188 2015-08-17 19:24:52 <drazisil> warren: thank you. I would need a rational database to do an address balance lookup, right? or could I do it somehow with key/value?
189 2015-08-17 19:26:32 <warren> drazisil: you may want to avoid reinventing the wheel, people have wrote code to do this many times already
190 2015-08-17 19:30:19 <drazisil> mm, yah, I'm probably overthinking this.
191 2015-08-17 19:32:07 <kanzure> btcdrak: why reject CSV failing transactions from the mempool? whynot keep until it passes?
192 2015-08-17 19:32:24 <warren> drazisil: there's a patch to bitcoin core that adds an address index that a bunch of people are using apparently successfully.  other people use bitcore + insight.  there are probably 5 other solutions out there.
193 2015-08-17 19:33:54 <btcdrak> warren: drazisil: it's available at https://github.com/btcdrak/bitcoin/tree/addrindex-0.11 (additionally the addrindex branch is based on 0.10)
194 2015-08-17 19:34:04 <drazisil> I'm looking for json output to feed to my site. bitcore might work, have to see if that's an option since I'm already running insight. I'll look into the patch as well.
195 2015-08-17 19:36:53 <warren> drazisil: insight itself uses bitcore to interface with bitcoin core.  Bitcore used to be necessary as a JSON RPC -> REST converter, but now Bitcoin Core itself does REST directly.
196 2015-08-17 19:37:19 <warren> bitcore has other functions that are useful though
197 2015-08-17 19:37:37 <warren> I haven't used bitcore + insight since mid-2014, it was very unstable back then, probably better now.
198 2015-08-17 19:37:40 <drazisil> warren: yes, but unless I missed a doc, core's rest only has like 3 calls?
199 2015-08-17 19:38:25 <drazisil> btcdrak: I'm liking the idea of this patch, what does it add exactly?
200 2015-08-17 19:39:05 <btcdrak> drazisil: searchrawtransactions <address> and will return the history of the address.
201 2015-08-17 19:39:30 <drazisil> nice. does it need wallet enabled?
202 2015-08-17 19:41:15 <btcdrak> drazisil: no
203 2015-08-17 19:42:08 <btcdrak> kanzure: From the PR text maaku says it's to make testing easier, but maybe there is another reason I am unaware of.
204 2015-08-17 19:42:32 <drazisil> btcdrak: sounds perfect then. thank you, and warren too for bringing it up.
205 2015-08-17 19:46:27 <kanzure> btcdrak: hmm sounds like i should post that as a comment then
206 2015-08-17 19:52:58 <drazisil> btcdrak: will I have to reindex?
207 2015-08-17 19:53:21 <btcdrak> yes, you need to add txindex=1 and addrindex=1 and then reindex.
208 2015-08-17 19:56:42 <kanzure> btcdrak: BIP-CSV typo: "block heiht"
209 2015-08-17 20:01:07 <btcdrak> kanzure: thanks and fixed. though it might be better to comment in the PR so I dont miss anything if I cant address it immediately.
210 2015-08-17 20:22:45 <nwilcox> bedeho: I don't know the answer to your question, but I'd love to find out.
211 2015-08-17 20:23:09 <nwilcox> This is where I would start: https://github.com/bitcoin/bitcoin/blob/0.11/src/script/interpreter.cpp#L1036
212 2015-08-17 20:23:46 <bedeho> nwilcox, wondering myself... not brave enough to look inside core, it just looks insane to me
213 2015-08-17 20:26:40 <nwilcox> It uses this utility class: https://github.com/bitcoin/bitcoin/blob/0.11/src/script/interpreter.cpp#L943
214 2015-08-17 20:28:04 <nwilcox> I notice immediately that the nHashTypeIn isn't directly stored in the class instance, so that makes me suspicious that the behavior is close to your compute_signature(hash(tx.serialized()))
215 2015-08-17 20:28:05 <bedeho> ok, so it seems like its sighash = hash(tx.serialize() || sighash_type)
216 2015-08-17 20:28:22 <bedeho> lines 1056-1058 show it
217 2015-08-17 20:28:54 <bedeho> nHashType is an arg, and I think this is not a class member
218 2015-08-17 20:28:56 <nwilcox> Ah, good find.
219 2015-08-17 20:29:23 <bedeho> well thanks for the pointer! first time Ive gained any information from core! perhaps its not as hard as Ive thought
220 2015-08-17 20:31:31 <nwilcox> Hrm. My understanding of this serialization framework is pretty tenuous, so I'm not sure what the << call site on line 1057 translates to in the CTransactionSignatureSerializer implementation yet.
221 2015-08-17 20:34:28 <bedeho> nwilcox, I would assume the CTransactionSignatureSerializer just does what it says, however the ChashWriter is responsible for the << operator implementation, so I guess it just reads the serializedtxTmp.
222 2015-08-17 20:34:51 <bedeho> then the hash type flag is appended, and then the whole thing is hashed, which answers our question
223 2015-08-17 20:35:35 <bedeho> I wonder why nHashType is part of the sighash itself, when nHashType also appears explicitly in scriptSig.
224 2015-08-17 21:42:12 <bedeho> is the previous block hash in block headers little or big endian?
225 2015-08-17 23:56:01 <dessugrue> Im not saying it is feasable or even desirable, but has concurrent block processing ever been brought up?
226 2015-08-17 23:57:04 <dcousens> @dessugrue like in the ethereum protocol (of which I know very little about,  but I remember something about it doing something different in regards to dealing with orphans)
227 2015-08-17 23:57:08 <dcousens> ?*
228 2015-08-17 23:57:42 <dessugrue> exactly
229 2015-08-17 23:58:25 <dessugrue> orphaned blocks drop transactions that are already verified, yes?