1 2014-11-29 00:02:00 <gmaxwell> op_null: I'd be willing to entertain a patch that punts node-network peers that never relay anything.
2 2014-11-29 00:02:31 <gmaxwell> esp outbound ones, maybe two thresholds, one for inbound one for outbound.
3 2014-11-29 00:02:45 <gmaxwell> (or maybe for outbound the result should be banning)
4 2014-11-29 00:04:11 <op_null> peers don't relay transactions when they are doing the intial sync though. couldn't you just pretend to be always doing the initial sync?
5 2014-11-29 00:06:20 <op_null> I'm hesitant to write any code that will ban peers conditionally. would be a disaster if we have the null vin bug from 0.8.x on a wider scale.
6 2014-11-29 00:08:41 <op_null> (I know that wasn't a bug in the DoS scoring system but in the wallet, but the impact regardless was quite high peer churn, my nodes don't DoS ban on it to try and reduce churn as much as I can)
7 2014-11-29 00:09:12 <Zarutian> op_null: what things are involved in banning?
8 2014-11-29 00:10:03 <Zarutian> op_null: that is, what is the result of banning a peer? refusing to communicate with it?
9 2014-11-29 00:10:23 <op_null> you drop their connections for a day. if they connect, you drop them again.
10 2014-11-29 00:10:48 <Luke-Jr> also SPV nodes never relay
11 2014-11-29 00:13:53 <op_null> actually me not banning for the vin empty DoS has an odd effect, 0.8.X nodes will bounce their connections around until the only nodes left they can connect to are mine. wonder if that happens or not.
12 2014-11-29 00:14:52 <Luke-Jr> op_null: 0.8.x nodes usually don't trigger that, you know..
13 2014-11-29 00:15:20 <op_null> is it only one version, or have I got it totally wrong?
14 2014-11-29 00:15:38 <Luke-Jr> op_null: IIRC it's only triggered with a corrupt wallet file of some form
15 2014-11-29 00:15:43 <gmaxwell> Luke-Jr: thats why I said node-network.
16 2014-11-29 00:15:53 <gmaxwell> Also we should never be outbound to a spv node... :)
17 2014-11-29 00:15:58 <Luke-Jr> gmaxwell: ah, didn't understand that term
18 2014-11-29 00:16:42 <op_null> Luke-Jr: must be a lot of people with corrupt wallets then, I was seeing a couple getting banned every hour at least
19 2014-11-29 00:16:52 <sipa> still??
20 2014-11-29 00:17:05 <sipa> i thought we fixed that bug ages ago
21 2014-11-29 00:17:12 <sipa> though i can't remember the details of what caused it
22 2014-11-29 00:17:16 <Luke-Jr> sipa: yes, we're talking about older nodes
23 2014-11-29 00:17:43 <op_null> sipa: yes, and not so much now, I think most of my peers are 0.9 today
24 2014-11-29 00:17:50 <sipa> ok
25 2014-11-29 00:20:21 <op_null> 6 of 71 for this node are 0.8, not all that many left.
26 2014-11-29 00:22:02 <Luke-Jr> 63.96% are updated: http://luke.dashjr.org/programs/bitcoin/files/charts/security.html
27 2014-11-29 00:22:03 <gmaxwell> one of my tor hs nodes gives 24 vs 8 for 0.9.x vs 0.8.x
28 2014-11-29 00:22:53 <Luke-Jr> 81% are 0.9.x: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
29 2014-11-29 00:23:22 <gmaxwell> some of those numbers may be a bit funky due to the only sampling listening nodes.
30 2014-11-29 00:23:32 <Luke-Jr> /caesure:20141014/ <-- O.o wat?
31 2014-11-29 00:24:06 <sipa> https://github.com/samrushing/caesure
32 2014-11-29 00:24:14 <Luke-Jr> interesting
33 2014-11-29 00:41:08 <op_null> "Start up a node with 100 outgoing connections and 100 incoming"
34 2014-11-29 00:41:10 <op_null> :<
35 2014-11-29 00:41:26 <gmaxwell> :(
36 2014-11-29 10:47:25 <damethos> got a question regarding v0.10 and the out of order blocks situation. Is this out-of-order only while bitcoind is syncing with the network and after that there is a logical order of the blocks?
37 2014-11-29 10:49:46 <sipa> in general, yes
38 2014-11-29 10:50:09 <sipa> but there is no real difference between the two... it just switches to a different means of fetching when it thinks it's caught up
39 2014-11-29 10:50:13 <sipa> don't rely on it
40 2014-11-29 10:50:30 <damethos> yeah i agree, i just wanted to know
41 2014-11-29 10:50:56 <damethos> i have already done the fixes i was supposed to do, i am about to start testing
42 2014-11-29 10:51:48 <damethos> i see in your PR#4468 notes the following
43 2014-11-29 10:51:50 <damethos> "No more orphan blocks. At all. We only ever request a block for which we have verified the headers, and store it to disk immediately. This means that a disk-fill attack would require PoW."
44 2014-11-29 10:52:16 <damethos> are these the blocks which i mentioned the other day that i was parsing them but they just stayed there, as a "side chain" and never got in a reorg?
45 2014-11-29 10:52:17 <sipa> "orphan blocks" means something else (in the bitcoin source code) than what the rest of the world calls orphan blocks
46 2014-11-29 10:52:25 <sipa> it means blocks that don't have a parent
47 2014-11-29 10:52:39 <damethos> ah ok , the ones i was seeing had a parent
48 2014-11-29 10:53:05 <sipa> blocks without known parent were just kept in ram in bitcoind, they were never written to disk
49 2014-11-29 10:53:17 <sipa> one of the reasons why 0.9.x had pretty high memory usage during sync
50 2014-11-29 10:53:34 <sipa> in 0.10 they don't exist anymore at all, but this is not relevant for you
51 2014-11-29 10:53:41 <damethos> hm but the ones i was seeing in my parsing where from reading the disk files
52 2014-11-29 10:53:57 <damethos> and when i queried the rpc interface with getblock, it returned confirmations: -1
53 2014-11-29 10:54:14 <sipa> which means they're not part of the currently active chain
54 2014-11-29 10:54:24 <damethos> but they had a parent though
55 2014-11-29 10:54:27 <sipa> grrrr
56 2014-11-29 10:54:31 <sipa> read what i say
57 2014-11-29 10:54:37 <damethos> ACTION re-reads
58 2014-11-29 10:55:01 <damethos> ok so these are not called "orphan blocks"
59 2014-11-29 10:55:05 <sipa> no
60 2014-11-29 10:55:08 <sipa> they're forks
61 2014-11-29 10:55:19 <op_null> or stale blocks. stale is a nicer term.
62 2014-11-29 10:55:30 <op_null> people get scared when you call them forks (I know)
63 2014-11-29 10:56:10 <sipa> (people started calling them orphan blocks, because they gave rise to orphan transactions in mining payouts... but as 'orphan' means 'without parent' that name is totally wrong; hard to change a term that stuck though)
64 2014-11-29 10:56:50 <damethos> i think is stale is more appropriate for what i noticed because they are blocks with a parent but they just stayed like that, never got into a reorg
65 2014-11-29 10:56:56 <damethos> -is
66 2014-11-29 10:57:39 <damethos> i will upgrade my bitcoind and resync with network to see if the situation will clear
67 2014-11-29 10:58:00 <sipa> i'm not sure what you expect to see
68 2014-11-29 10:58:13 <sipa> you'll still have stale blocks in your blk*.dat files
69 2014-11-29 10:58:19 <sipa> in 0.10, they'll also be out of order
70 2014-11-29 10:58:54 <damethos> i dont mind seeing them, i even parse them and keep them around but should i consider them as a fork?
71 2014-11-29 10:58:58 <damethos> or are they something else?
72 2014-11-29 10:59:11 <sipa> what do mean by 'they' ?
73 2014-11-29 10:59:33 <op_null> just a stale chain. forgotten and ignored. like the funny lollies you get in a mix bag that nobody wants.
74 2014-11-29 10:59:54 <damethos> lol
75 2014-11-29 10:59:58 <sipa> by just parsing the blk*.dat files you can *not* know what the active chain is, as that depends on which blocks are valid
76 2014-11-29 11:00:03 <damethos> they i meant those "stale" blocks
77 2014-11-29 11:00:13 <sipa> all you can discover is the entire block tree
78 2014-11-29 11:00:25 <sipa> which most likely has one very long chain, and a few very short branches off it
79 2014-11-29 11:00:33 <sipa> but you can't rely on that
80 2014-11-29 11:01:26 <sipa> if you need to know which chain is actually considered valid, ask bitcoind
81 2014-11-29 11:01:41 <sipa> any chain that isn't, is a fork/branch/stale/whatever
82 2014-11-29 11:01:48 <sipa> and may be valid or invalid
83 2014-11-29 11:02:44 <damethos> yeah got it
84 2014-11-29 11:05:40 <damethos> op_null, i am still laughing with the funny lolies thing :p everybody hates that heh
85 2014-11-29 11:06:00 <op_null> the little cube ones with the layers that all taste like dirt.
86 2014-11-29 13:19:42 <op_null> seeing a lot of transactions being rejected for weird stuff at the moment. flood of peers tried to relay a 22kb transaction, all non standard for non-mandatory-script-verify-flag. blockchain.info seems to be showing them and relaying them though.
87 2014-11-29 13:23:15 <op_null> sample if anybody was curious http://178.62.133.216:8000/paste/TvOI9lww#4MNGVE0CRAIC-6Tc1qLyGg0yIx6OtYumkXGbCmLctGM
88 2014-11-29 14:09:29 <sipa> op_null: do you know for which 'offense' ?
89 2014-11-29 14:21:31 <op_null> sipa: no, just the reject message I posted.
90 2014-11-29 14:22:51 <sipa> op_null: i'll write a patch for bitcoind to show the script evaluation error
91 2014-11-29 14:23:27 <op_null> sipa: sweet. ping me if you want me to test it :)
92 2014-11-29 14:39:44 <sipa> op_null: what exactly do you see in debug.log?
93 2014-11-29 14:41:21 <op_null> ERROR: CScriptCheck() : be9a733b63628aeabd1afe314c4ec7692f63b2191e517593687d378358869ccd:0 VerifySignature failed
94 2014-11-29 14:41:25 <op_null> ERROR: AcceptToMemoryPool: : ConnectInputs failed be9a733b63628aeabd1afe314c4ec7692f63b2191e517593687d378358869ccd
95 2014-11-29 15:02:46 <sipa> op_null: #5394
96 2014-11-29 15:03:48 <sipa> op_null: looks like they're passing 0 as a pubkey
97 2014-11-29 15:03:58 <sipa> iirc that has been non-standard since 0.8
98 2014-11-29 15:04:16 <op_null> heh well, we know what node software blockchain.info is running then
99 2014-11-29 15:04:58 <op_null> thanks for putting that together, just building it no
100 2014-11-29 15:35:43 <andytoshi> sipa: does the sha2 -> {sha256, sha512} stuff in #5227 change any code?
101 2014-11-29 15:35:49 <andytoshi> or just split the files
102 2014-11-29 15:36:13 <sipa> andytoshi: there's a small change (changes two += operations to + operations)
103 2014-11-29 15:36:16 <sipa> otherwise, no
104 2014-11-29 15:37:59 <andytoshi> ok, i'm going to trust that that's correct (since MD hashes are pretty hard to fuck up in subtle ways, and there are unit tests)
105 2014-11-29 15:38:11 <andytoshi> but it looks weird
106 2014-11-29 15:39:12 <sipa> what looks weird?
107 2014-11-29 15:39:35 <andytoshi> that you have two + lines after a ton of += lines
108 2014-11-29 15:39:50 <sipa> you can use git diff commitid1:filename1 commitid2:filename2 to verify move-onlyness
109 2014-11-29 15:40:02 <andytoshi> oh, thx
110 2014-11-29 15:40:28 <andytoshi> why are those two rounds different from every other one? if this changes the output why wasn't it noticeably wrong before?
111 2014-11-29 15:41:06 <andytoshi> oh, i see, it doesn't, you're just avoiding a dead assignment
112 2014-11-29 15:41:21 <andytoshi> ok i'm happy
113 2014-11-29 15:41:24 <sipa> yup
114 2014-11-29 15:52:26 <andytoshi> thx for the `git diff` command, i verified that you changed those two lines in sha512 (but not sha256!) and nothing else
115 2014-11-29 15:53:18 <sipa> in sha256 that optimization had been done already
116 2014-11-29 15:54:01 <andytoshi> cool
117 2014-11-29 15:54:11 <andytoshi> almost done #5227, just need to check the Sign function and the test cases
118 2014-11-29 16:02:00 <andytoshi> Sign is ok, good catch storing the return val of the libsecp256k1 call so you zero out the nonce regardless of early return (the old code used the CKey destructor which calls openssl_cleanse)
119 2014-11-29 16:02:19 <andytoshi> i suspect i would've missed that if you hadn't done it :/
120 2014-11-29 16:08:57 <andytoshi> sipa: utACK for #5227, i'm running make check now and will post on github
121 2014-11-29 16:33:07 <sipa> andytoshi: thanks!
122 2014-11-29 22:39:19 <kefkius> Is there an example of bitcoin-tx usage for setting a register? Or barring that, how should JSON-STRING look in bash for this command: "set=NAME:JSON-STRING"?
123 2014-11-29 22:40:10 <sipa> for what register?
124 2014-11-29 22:46:14 <sipa> kefkius: it depends on what data you're setting
125 2014-11-29 22:46:18 <sipa> name is the name
126 2014-11-29 22:46:27 <sipa> and JSON-STRING is a JSON encoded piece of data
127 2014-11-29 22:52:46 <kefkius> sipa: I mean that I've been trying to get it working but getting json parsing errors. I've errored all the way up to this level of complexity: bitcoin-tx -testnet -json $TX set=privatekeys:"{"'$KEY_WIF'"}"
128 2014-11-29 22:54:00 <sipa> 'set=privatekeys:{"KEY1","KEY2"}'
129 2014-11-29 23:57:07 <tErik> Hi, what's the link to IETF protocol proposal RFC for bitcoin protocol ?
130 2014-11-29 23:58:56 <tErik> where is the bitcoin PROTOCOL specified & explained ?