1 2015-04-08 00:14:33 <fanquake> ;;blocks
 2 2015-04-08 00:14:34 <gribble> 351185
 3 2015-04-08 00:33:00 <phantomcircuit> is GetRand inclusive or exclusive of the top value?
 4 2015-04-08 00:35:33 <phantomcircuit> exclusive
 5 2015-04-08 01:12:10 <StephenM347> When the nHashType that contains the sighash flags is serialized into a scriptSig, it is cast to an unsigned char: https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L31
 6 2015-04-08 01:12:21 <StephenM347> Even though it is used as an integer throughout the code
 7 2015-04-08 01:12:32 <StephenM347> Any reason for this?
 8 2015-04-08 01:13:15 <StephenM347> And if a signature has 0001 appended, older clients will reject them, yes?
 9 2015-04-08 01:13:28 <StephenM347> (instead of 01 for sighash all)
10 2015-04-08 01:14:22 <gmaxwell> ~'older clients' ?
11 2015-04-08 01:15:11 <StephenM347> I guess any clients, really
12 2015-04-08 01:15:40 <StephenM347> Will standard bitcoind nodes reject a sighash value of 0001 instead of 01?
13 2015-04-08 01:18:14 <gmaxwell> StephenM347: it's a single byte, so what you're asking has nothing to do with sighash flags, you're asking if it'll accept a DER signature with an extra null at the end.  This is non-standard but I think it will be decoded and verify. Why?
14 2015-04-08 01:18:30 <gmaxwell> (I just asked pieter and this was also his belief)
15 2015-04-08 01:19:12 <gmaxwell> (BIP66 will eliminate this.
16 2015-04-08 01:19:13 <gmaxwell> )
17 2015-04-08 01:21:47 <sipa> StephenM347: in any case, doing so is non-standard since 0.8
18 2015-04-08 01:22:20 <sipa> but afaik, even using FFFFFFF...01 as hashtype would work
19 2015-04-08 01:23:01 <sipa> as long as you stay under 128 bytes or so
20 2015-04-08 01:23:19 <StephenM347> Interesting, thanks gmaxwell and sipa. Isn't the sighash not part of the DER encoding, though?
21 2015-04-08 01:23:25 <StephenM347> Like this http://pastebin.com/MU0XpCu3
22 2015-04-08 01:25:16 <StephenM347> Well, no {end}, I guess. I guess I'm just trying to figure out how sighash value is affected by DER encoding, because I thought it wasn't even included directly into the DER part of the signature
23 2015-04-08 01:26:54 <StephenM347> In any case, I think I figured out why it's used as an integer throughout the code even though it's just a single byte when serialized: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1057
24 2015-04-08 01:30:07 <sipa> StephenM347: because integers are more efficient on a cpu
25 2015-04-08 01:30:25 <gmaxwell> 
ACTION sends sipa a look of disapproval

26 2015-04-08 01:30:33 <sipa> ok ok
27 2015-04-08 01:30:50 <gmaxwell> more like "because thats the normal thing you do, unless you have a reason to do otherwise; sometimes it has performance impacts, but not here"
28 2015-04-08 01:30:55 <sipa> i guess you will have to go ask satosi
29 2015-04-08 01:31:27 <gmaxwell> but when you seralize something you will often use a more space efficient type.
30 2015-04-08 01:31:31 <sipa> StephenM347: the serialization and processing are really separate
31 2015-04-08 01:32:10 <sipa> the fact that an int is used internally does not change the fact that it will serialize and deserialize as a single char
32 2015-04-08 01:32:42 <StephenM347> sipa: But when it's serialized for SignatureHash it appends the full 4 bytes
33 2015-04-08 01:32:50 <sipa> and the reason that introducing an extra zero before ghe sighash byte would still work pre-0.8 is even unrelated to that
34 2015-04-08 01:32:55 <sipa> StephenM347: yes, so?
35 2015-04-08 01:33:15 <sipa> different purpose, different serialization
36 2015-04-08 01:33:35 <sipa> it's confusing to humans perhaps :)
37 2015-04-08 01:33:41 <StephenM347> Yeah, I know. Just seemed peculiar to me, I think I understand now
38 2015-04-08 01:33:45 <sipa> but it's perfectly well defined
39 2015-04-08 01:34:57 <sipa> as to why the serialization is different betwern sighash and tx serialization: ask satoshi
40 2015-04-08 01:35:22 <StephenM347> sipa: Gotcha ;)
41 2015-04-08 01:46:04 <phantomcircuit> is there a guarantee that wallet transactions will make it into the mempool?
42 2015-04-08 01:57:03 <leakypat> http://www.reddit.com/r/Bitcoin/comments/31spb7/help_with_bitcoin_core_wallet/.compact
43 2015-04-08 02:27:23 <phantomcircuit> gmaxwell, just to make sure im clear on this
44 2015-04-08 02:27:45 <phantomcircuit> the goal of the address trickling is to prevent a node connected to all the nodes from mapping the network, right?
45 2015-04-08 02:28:35 <gmaxwell> phantomcircuit: and preventing the same data from being sent both directions on many links.
46 2015-04-08 02:29:48 <phantomcircuit> alright
47 2015-04-08 02:54:30 <phantomcircuit> gmaxwell, disguising the local address clearly needs to be a larger interval then the cross flight prevention
48 2015-04-08 04:21:27 <gmaxwell> phantomcircuit: right, cross in flight prevention probably wants the delay to be exponentially distributed with a mean of some multiple of the latency between nodes.
49 2015-04-08 04:21:44 <gmaxwell> the privacy should be considerably larger than that.
50 2015-04-08 04:24:51 <phantomcircuit> gmaxwell, another thing to consider, maybe we can stop broadcasting our own address if a peer sends it to us?
51 2015-04-08 04:25:14 <phantomcircuit> or at least increase the delay
52 2015-04-08 04:27:08 <gmaxwell> phantomcircuit: we'll only broadcast it once per 24h hours, unless I remember incorrectly.
53 2015-04-08 04:29:46 <phantomcircuit> gmaxwell, 24 hours... and on outbound connect
54 2015-04-08 04:33:17 <gmaxwell> ah, right. outbound, ... well the only reservation I have with backing that off is that its our only real way to respond to address changes.
55 2015-04-08 04:39:34 <phantomcircuit> gmaxwell, hmm
56 2015-04-08 04:40:45 <gmaxwell> in theory we could suppress the more frequent outbound ones if we have only one idea of what our address is, and we've heard it via other peers.  but those relays to peers don't tend to go far in the network.
57 2015-04-08 04:41:16 <gmaxwell> One thing to think about is we don't want honest nodes to be so polite that agressive ones can get comparative overrepresentation.
58 2015-04-08 04:45:25 <phantomcircuit> gmaxwell, i guess that mostly depends on the CAddrMan logic
59 2015-04-08 04:49:22 <gmaxwell> yea, it doesn't really let more announcements influence it much... but if you're so passive that you're never heard from at all then obvious you won't be found.
60 2015-04-08 05:06:58 <phantomcircuit> gmaxwell, oh and there's weirdness there around whether you want to broadcast to all your nodes every $interval
61 2015-04-08 05:07:00 <phantomcircuit> or just one
62 2015-04-08 05:07:08 <phantomcircuit> since the outbound nodes could obviously change
63 2015-04-08 05:43:03 <rnvk> Anybody mining Testnet right now?