1 2014-08-23 04:12:27 <kdomanski> sipa: do you have a windows build box? I'm trying to get rid of boost thread and I already reimplemented mutexes and locks in POSIX, but I have no means of building the windows code
2 2014-08-23 04:14:35 <gmaxwell> kdomanski: you cross compile for windows using mingw see the gitian scripts.
3 2014-08-23 04:14:53 <gmaxwell> (and you can test the result under wine, at least for basic testing)
4 2014-08-23 04:22:59 <kdomanski> gmaxwell: ah, thanks
5 2014-08-23 05:24:33 <wumpus> cfields: I had no problems
6 2014-08-23 05:25:00 <cfields> wumpus: he got it worked out, it was his base vm
7 2014-08-23 05:26:51 <wumpus> cfields: did the version string ever reflect rc status?
8 2014-08-23 05:27:43 <cfields> wumpus: not sure, planning to look into it this weekend/mon
9 2014-08-23 05:27:47 <wumpus> afaik not, at least when I look at the recent logs we don't do version bumps between rcs
10 2014-08-23 05:28:52 <wumpus> the only thing I could think of to get an 'rc' into the displayed version is to set the suffix to somethig else than -beta, but we never did that
11 2014-08-23 05:28:57 <wumpus> yeah no hurry
12 2014-08-23 05:29:47 <wumpus> we can still identify versions using the git hash, so it's not high priority in any case
13 2014-08-23 05:46:59 <theymos> ill not be able to change your ad once I accept it. Anyone interested?
14 2014-08-23 05:46:59 <theymos> There is an ad slot available on bitcointalk.org because someone in the auction didn't pay. These slots last for at least 7 days (but usually more) and nowadays always get more than 1 million impressions. They typically sell for 2.5-3.5 BTC, but you can have this slot for 0.75 BTC. However, I will need your ad text (which can include limited HTML, but no images) within the next 30 minutes, and you w
15 2014-08-23 05:47:45 <theymos> See here for more info: https://bitcointalk.org/index.php?topic=715267.0 . Note that I am logged in, and I will PGP-sign something if you are worried about my identity. (Phishing forum advertisers is unfortunately very common.)
16 2014-08-23 05:49:31 <theymos> Whoops, wrong channel. I meant to post that to bitcoin-otc. Sorry.
17 2014-08-23 09:01:15 <BlueMatt> gmaxwell/forrestv: does p2pool fast-relay blocks that it didnt generated (ie is it worth while to make sure there is a run_p2pool running without miners on something connected to the relay network?)
18 2014-08-23 09:05:10 <gmaxwell> BlueMatt: it does not, IIRC.
19 2014-08-23 09:30:49 <sipa> kdomanski: heh, we switched the synchronization code from pthread/windows to boost thread a long time ago in order not to need to maintain twonstacks...
20 2014-08-23 09:41:02 <wumpus> we're definitely not going to get rid of boost threads
21 2014-08-23 09:41:39 <wumpus> well, that is, until c++ provides its own threading functionality, as it does with c++11
22 2014-08-23 09:41:56 <wumpus> but there will be no roll-your-own threading code in bitcoin core
23 2014-08-23 09:42:48 <wumpus> we spent ages getting rid of all satoshi's poorly-implemented wrappers, resist the NIH syndrome please
24 2014-08-23 09:44:39 <gmaxwell> what kdomanski was doing before was in service of facilitating an eventual shift from boost to C++ things, so I assumed this was just somehow more of that. :)
25 2014-08-23 09:47:08 <wumpus> the major reason we use boost is because c++ doesn't provide the functionality itself
26 2014-08-23 09:47:16 <wumpus> if it did, we wouldn't be using boost
27 2014-08-23 09:48:08 <gmaxwell> Right, but C++11 changes most of that, and â eventually, I presume, we'll move to that.
28 2014-08-23 09:48:32 <wumpus> agreed fully, but that doesn't mean we should be wasting time maintaining our own platform compatibility wrappers in the mean time
29 2014-08-23 09:50:41 <gmaxwell> Right. I dunno what kdomanski was doing there perhaps it was just a trial "boost free version" not meant for merging, but just identifying the issues.
30 2014-08-23 09:55:55 <sipa> what kdomanski is doing is trying to get rid of the boost dependency in libbitcoinscript
31 2014-08-23 09:56:47 <sipa> which seems reasonable, but imho it should just be done by making the locking-depending parts optional or not in the modules needed for scripting
32 2014-08-23 09:57:06 <sipa> as there should be need for it to access any threading or locking for that
33 2014-08-23 09:57:59 <wumpus> right - it would be preferable to write the scripting code so that it doesn't depend on the os at all
34 2014-08-23 09:58:15 <wumpus> no threading either through boost or the os directly
35 2014-08-23 09:58:24 <sipa> exactly
36 2014-08-23 10:00:52 <gmaxwell> it should only now do to funny hiddden side effects, AFAIR
37 2014-08-23 10:06:52 <sipa> it may mean that for something like signature caching we need dynamic binding; have an interface that just exposes a cache, and use a dummy in libbitcoinscript and the fully-featured synchronization-aware one inside the full validation code
38 2014-08-23 10:09:11 <wumpus> right, could have the client pass in an interface handle
39 2014-08-23 10:11:09 <wumpus> and libbitcoinscript would pass in a dummy, and the full validation code would pass in an a real implementation
40 2014-08-23 10:11:27 <sipa> exactly
41 2014-08-23 10:12:13 <wumpus> so it's at least possible to do everything in a stateless and side-effect-less way, at the expense of performance
42 2014-08-23 10:20:36 <kdomanski> wumpus: huh, I've been thinking of a dual stack drop-in replacement interface-compatible with C++11 facilities - easy enough for pthread, buf if you say no then no
43 2014-08-23 10:20:59 <wumpus> kdomanski: I don't see the point, isn't that exactly what boost is doing already?
44 2014-08-23 10:21:56 <wumpus> I must admit I've never looked at the details, but from what I've heard boost::thread is pretty much a drop-in replacement for c++11's threading facilities
45 2014-08-23 10:23:05 <kdomanski> wumpus: I was convinced not using boost is in this case better than using boost
46 2014-08-23 10:23:18 <wumpus> I'm not convinced of that
47 2014-08-23 10:23:42 <sipa> i think that having less dependencies is better than having more, all other things aside
48 2014-08-23 10:23:57 <wumpus> but not at the expense of importing all those dependencies in our code
49 2014-08-23 10:24:02 <wumpus> please...
50 2014-08-23 10:24:15 <sipa> and if we can restructure things so that libbitcoinscript has a dependency less, that's great
51 2014-08-23 10:24:28 <sipa> but not by duplicating things - just by not depending on what we don't need
52 2014-08-23 10:24:40 <wumpus> right, doing duplicate work is a waste of time
53 2014-08-23 10:24:53 <sipa> libbitcoinscript shouldn't be doing any threading or locking at all - so let's make sure it compiles without needing those
54 2014-08-23 10:25:04 <sipa> in theory that must be possible
55 2014-08-23 10:26:25 <wumpus> boost is used by a lot of different projects so it should be well-tested code, in general.. .sure, some of their things suck, but that doesn't necessarily mean that we need to re-do them
56 2014-08-23 10:27:32 <kdomanski> understood
57 2014-08-23 10:32:55 <wumpus> ideally I'd like to minimize the amount of OS-specific code in bitcoin core
58 2014-08-23 10:33:18 <kdomanski> wumpus: one thing that won't work out with C++11 threads - they don't have builtin interruption mechanism like boost::this_thread::interruption_point()
59 2014-08-23 10:33:42 <wumpus> almost all the os-specific code that exists right now has to do with networking
60 2014-08-23 10:33:50 <wumpus> kdomanski: thanks for researching that, seems like a real issue
61 2014-08-23 10:34:27 <kdomanski> wumpus: I discovered it that time when I've been rewriting everything to c++11
62 2014-08-23 10:35:16 <wumpus> kdomanski: I've always wondered how their interruption mechanism is implemented, sure, it's just a flag, but what if an interruption point is hit? it raises an exception I suppose to clean up, which is catched by the thread spawner?
63 2014-08-23 10:35:38 <wumpus> at least that's how python's similar mechanism works
64 2014-08-23 10:35:59 <wumpus> brb
65 2014-08-23 10:36:48 <sipa> wumpus: interruption_point raises an exception indeed
66 2014-08-23 10:37:58 <gmaxwell> yuck
67 2014-08-23 10:38:17 <kdomanski> wumpus: maybe I'll start maintaining a C++11 branch permanently in sync with master
68 2014-08-23 12:32:56 <wumpus> kdomanski: that's fine; I think we can aim to switch to c++11 after 0.10 is released
69 2014-08-23 12:33:39 <wumpus> not sure though, breaking compatibility with compiling on older systems is going to get a lot of pushback
70 2014-08-23 13:22:49 <Luke-Jr> yeah⦠people should always be able to easily build BCCore themselves on the latest Fedora/Debianâ¦
71 2014-08-23 13:23:12 <Luke-Jr> sadly, I think that means C++11 is a few years off
72 2014-08-23 13:54:12 <wumpus> right, certainly if we insist on complete c++11 support then it will take quite a long time before it leaks into stable distributions...
73 2014-08-23 14:32:47 <kdomanski> Luke-Jr: which one latest distribution won't compile with C++11 stdlib ?
74 2014-08-23 14:41:44 <Luke-Jr> kdomanski: Debian is at GCC 4.7.2 and libc 2.13; RH is at GCC 4.4.7 and libc 2.12; Gentoo is at GCC 4.7.3 and libc 2.19
75 2014-08-23 14:44:46 <Luke-Jr> kdomanski: and bleeding edge GCC isn't C++11 complete yet even today
76 2014-08-23 14:55:22 <PRab> I hear that the getinfo RPC is going to be depreciated, so in that case, which RPC would be the best to add a human readable version string?
77 2014-08-23 14:56:53 <PRab> right now, getinfo.version returns "90201", but I want something like "bitcoind v0.9.2.1"
78 2014-08-23 14:58:11 <PRab> My main problem is there is no way to tell bitcoind from btcd via the RPC (That I know of)
79 2014-08-23 15:11:02 <jgarzik> huh
80 2014-08-23 15:11:18 <jgarzik> my public node's bitcoind is suddenly averaging 600MB RSS rather than 800MB
81 2014-08-23 15:11:55 <jgarzik> same average number of connections, 30-40
82 2014-08-23 15:30:01 <wumpus> PRab: getversioninfo?
83 2014-08-23 15:32:36 <wumpus> jgarzik: interesting; could be due to #4675
84 2014-08-23 15:40:37 <kdomanski> kdomanski: and bleeding edge GCC isn't C++11 complete yet even today << yeah, garbage collection is missing
85 2014-08-23 15:46:13 <kdomanski> Luke-Jr: so Gentoo has all we need
86 2014-08-23 15:46:24 <kdomanski> Luke-Jr: and you're not looking at the latest RH
87 2014-08-23 15:46:37 <kdomanski> Luke-Jr: there's just the matter of Debian
88 2014-08-23 15:49:14 <wumpus> but we don't need "c++11 complete" so let's not let that distract us
89 2014-08-23 15:50:06 <kdomanski> wumpus: my thoughts exactly
90 2014-08-23 15:50:07 <wumpus> we just need to determine a realistic set of c++11 features that can be used
91 2014-08-23 15:51:05 <Adlai> ACTION has to deal with C++11 compatibility issues at work, is there a way to be helpful here?
92 2014-08-23 15:51:15 <Adlai> (totally unfamiliar with the bitcoind codebase though)
93 2014-08-23 15:51:53 <kdomanski> wumpus: C++11 facilities are introduced in glibc 2.16
94 2014-08-23 15:52:14 <kdomanski> wumpus: range-based for in gcc 4.6
95 2014-08-23 15:52:28 <kdomanski> wumpus: move semantics in gcc 4.3
96 2014-08-23 15:52:35 <wumpus> gcc 4.6 is also sort-of the minimum that we support
97 2014-08-23 15:52:55 <kdomanski> wumpus: I don't see an immediate necessity for anything more
98 2014-08-23 15:53:27 <kdomanski> so Debian is the only obstacle in the way
99 2014-08-23 15:53:52 <wumpus> ah, no, we support 4.4.3 on linux
100 2014-08-23 15:54:06 <wumpus> 'GCC': (4,4,0), 'CXXABI': (1,3,3), 'GLIBCXX': (3,4,13), 'GLIBC': (2,11) for the releases
101 2014-08-23 15:54:44 <wumpus> then again that's not fixed forever, just for now
102 2014-08-23 16:04:44 <kdomanski> wumpus: whoa, this means we can have move semantics and initializer lists right now
103 2014-08-23 16:05:53 <kdomanski> wumpus: and deletion of copy constructors and strongly typed enums
104 2014-08-23 16:12:34 <PRab> wumpus: Would that be a new RPC? Right now that returns "error: {"code":-32601,"message":"Method not found"}"
105 2014-08-23 16:14:40 <Luke-Jr> kdomanski: RHEL 6 is the latest RH
106 2014-08-23 16:15:05 <Luke-Jr> kdomanski: and I'm not clear on what you mean there at all - Gentoo is only one bugfix release up from Debianâ¦
107 2014-08-23 16:15:46 <kdomanski> Luke-Jr: uhm, no, it isn't
108 2014-08-23 16:16:02 <Luke-Jr> no? *double checks*
109 2014-08-23 16:16:25 <Luke-Jr> oh, RHEL 7 is out already :o
110 2014-08-23 16:16:32 <Luke-Jr> 4.8.2 there I guess
111 2014-08-23 16:17:37 <kdomanski> Luke-Jr: we do not need complete C++11 featureset, first and foremost we need C++11 facilities in stdlib, which were introduced in glibc 2.16
112 2014-08-23 16:19:31 <kdomanski> unless you feel like you don't want to replace boost::mutex with std::mutex unless you also have bidirectional memory fences and alignment support
113 2014-08-23 16:20:35 <Luke-Jr> meh, as long as it builds on stable distros
114 2014-08-23 16:58:40 <jgarzik> michagogo, ping. Do you have sha1/sha256 for latest bootstrap.dat @ 313000?
115 2014-08-23 17:07:09 <joedoe-> I am trying to cross-compile bitcoin-qt.exe using linux without gitian. googled and found same issues however without a solution. here's someone else paste with same error: http://pastebin.com/Z5RZXZEW
116 2014-08-23 17:07:23 <joedoe-> (DB cross-compilation issue)
117 2014-08-23 17:07:56 <joedoe-> (I base on gitian yamls)
118 2014-08-23 17:11:55 <joedoe-> well I removed second declaration and it goes fine...
119 2014-08-23 17:20:16 <joedoe-> and now threads mess, anyone was dealing with cross-compilation last time? :)
120 2014-08-23 17:58:17 <joedoe-> where can I download boost-mingw-gas-cross-compile-2013-03-03.patch from?
121 2014-08-23 18:04:05 <joedoe-> nevermind, google did not help, reading yaml carefuly did
122 2014-08-23 19:39:34 <TheRelic> hello, is there anyone here who knows python/django and has worked with the bitcoinrpc?
123 2014-08-23 20:07:33 <jgarzik> Pre-seeding blockchain torrent (22.5 GB) at http://gtf.org/garzik/bitcoin/bootstrap.dat.torrent
124 2014-08-23 20:08:40 <fuzion24> can you dynamically add files to a tracker?
125 2014-08-23 20:11:38 <jgarzik> fuzion24, tracker yes, torrent no
126 2014-08-23 20:34:43 <BlueMatt> gmaxwell: thats a shame :(
127 2014-08-23 20:35:20 <BlueMatt> GM0127: change your nick, you're hurting my gm->tab autocomplete-fu :(
128 2014-08-23 20:35:49 <BlueMatt> gmaxwell: is it worth running a run_p2pool instance on a relay node (or close to one) in any case?
129 2014-08-23 20:40:06 <gmaxwell> BlueMatt: yes, I think you should, and advertise that you do so that people running p2pool can manually peer with it.
130 2014-08-23 20:42:11 <BlueMatt> gmaxwell: whats the memory requirements for a run_p2pool w/o mining on it?
131 2014-08-23 20:43:33 <gmaxwell> well, with mining on it, looks like about 380mbytes.
132 2014-08-23 20:46:36 <BlueMatt> ugh
133 2014-08-23 20:46:48 <BlueMatt> gmaxwell: any idea about peak?
134 2014-08-23 20:46:50 <BlueMatt> is that current
135 2014-08-23 20:48:25 <gmaxwell> Thats what I'm using currently, it's also fairly similar to the peak. IIRC.
136 2014-08-23 20:53:33 <BlueMatt> forrestv: ^
137 2014-08-23 20:57:39 <gmaxwell> ::sigh:: at the insanity of the bitcoin world. Random people histerical about zomg centeralization because matt has a relay network you can connect to; meanwhile people on bitcoin developement who've never even compiled the code are very concerned that we might try to be a little less dependant on github.
138 2014-08-23 20:58:16 <gmaxwell> Incidentally, is anyone mirroring the issues and pull text from github? Past expirence is that you cannot get that data when their legal department goes brain-damaged and shuts off access to your repos.
139 2014-08-23 20:59:42 <PRab> gmaxwell: I'm not worried about being less dependent on github. I just want it to remain an up-to-date option.
140 2014-08-23 21:00:58 <gmaxwell> PRab: There is no problem with that, though the authentication is pretty bad, but I suppose that doesn't matter if you're just reading things.
141 2014-08-23 21:01:36 <PRab> gmaxwell: My concern is that if it wasn't as easy for me to look at pull request and the commit log, that would be 1 less set of eyes reviewing the code.
142 2014-08-23 21:02:05 <PRab> Granted, not a through review, but anyone can catch something.
143 2014-08-23 21:02:52 <gmaxwell> PRab: in theory we could make it a lot easier, as far as review goes github is very poor compared to gerrit in basically everyone's opinion whos used both... But sure there is no problem mirroring data.
144 2014-08-23 21:03:19 <gmaxwell> Github has basically non-existant security and nearly mandates bad security practices... though we've worked around some of it with the github-merge script.
145 2014-08-23 21:03:49 <PRab> I've never used gerrit and would be willing to take a look.
146 2014-08-23 21:05:05 <PRab> I haven't been able to locally reproduce an equivalent of Github's network graph.
147 2014-08-23 21:05:07 <hearn> well, github at least has two factor authentication on the web side.
148 2014-08-23 21:05:17 <hearn> git itself doesn't really "do" 2FA but that's not githubs fault
149 2014-08-23 21:06:21 <PRab> For bitcoin, it is broken, but for other related projects (Armory, btcd, bitcoind-ncurses), I find it extremely useful.
150 2014-08-23 21:08:50 <gmaxwell> PRab: github's "network graph" is a simulation of that gitk does.
151 2014-08-23 21:09:19 <BlueMatt> gitlab has something similar
152 2014-08-23 21:09:24 <gmaxwell> (and IIRC github's network graph doesn't work at all on bitcoinâ but gitk works fine)
153 2014-08-23 21:09:35 <PRab> gmaxwell: gitk doesn't automatically know about everyone else's repo until you add all the remotes.
154 2014-08-23 21:10:30 <gmaxwell> PRab: but github's can't support external repos at all, and won't work with large projects, etc.
155 2014-08-23 21:10:35 <gmaxwell> ('large')
156 2014-08-23 21:11:19 <gmaxwell> Here is what you get for bitcoin https://github.com/bitcoin/bitcoin/network
157 2014-08-23 21:11:31 <PRab> agreed, both could use some improvements.
158 2014-08-23 21:12:19 <gmaxwell> (git itself, without gitk, can also show the tree view on the commandline too, with git log --graph but it only shows a single repo)
159 2014-08-23 21:12:57 <gmaxwell> For bitcoin I've mostly not found this stuff useful, virtually none of the forks on github have any interest in contributing to bitcoin.
160 2014-08-23 21:13:16 <gmaxwell> (well 'virtually none' was relatively speaking)
161 2014-08-23 21:15:35 <PRab> FYI, locally I use a combo of the command line and SourceTree.
162 2014-08-23 21:16:00 <PRab> I find SourceTree a bit easier to use that gitk.
163 2014-08-23 21:17:43 <Luke-Jr> what is gitk part of?
164 2014-08-23 21:17:54 <Luke-Jr> or how do you get it?
165 2014-08-23 21:18:31 <PRab> Luke-Jr: On Windows it was included with the Github's Git for Windows install.
166 2014-08-23 21:18:41 <Luke-Jr> hrm, not part of my git install
167 2014-08-23 21:19:16 <PRab> It doesn't make a shortcut for it, but it can be launched from the "Git Shell" shortcut.
168 2014-08-23 22:55:42 <andytoshi> can i send a tx out without maintaining a mempool? it seems like i have to do `inv` then `getdata`
169 2014-08-23 22:55:52 <andytoshi> then respond to a `getdata` indeterminately later*
170 2014-08-23 23:16:58 <sipa> andytoshi: they're not relayed from the mempool but from the relay pool
171 2014-08-23 23:17:21 <sipa> before BIP35, the mempool wasn't queryable through getdata
172 2014-08-23 23:24:07 <stacksmash> Where should I announce an open-source exchange for testing? Is GPL the right license for such a project?
173 2014-08-23 23:27:38 <hearn> andytoshi: you can just send it
174 2014-08-23 23:27:46 <hearn> andytoshi: there is no need to go through the inv/getdata dance if you don't want to
175 2014-08-23 23:28:06 <sipa> you do if you're relaying
176 2014-08-23 23:28:15 <sipa> (rather than being the original sender)
177 2014-08-23 23:29:36 <andytoshi> sipa: hearn: thx, i wasn't sure if a bare `tx` would be antisocial or ignored
178 2014-08-23 23:30:22 <andytoshi> s/bare/unsolicited/
179 2014-08-23 23:37:58 <gmaxwell> andytoshi: the btcd authors are pretty unhappy that they're accepted in the protocol.
180 2014-08-23 23:39:01 <andytoshi> yeah, it seems like an abuse-enabler....but if it's there, i'll use it
181 2014-08-23 23:39:38 <sipa> unless there is a way to know the hash of data before receiving it, it makes no difference
182 2014-08-23 23:40:22 <sipa> (which is in theory the case for blocks, as you can process the header before processing/receiving the transaction data)
183 2014-08-23 23:41:05 <BlueMatt> gmaxwell: why?
184 2014-08-23 23:41:14 <BlueMatt> aside from using downstream bw, but...
185 2014-08-23 23:43:21 <gmaxwell> presumably because its a potential waste of bandwidth, complexifies the state machine because you need to be able to accept things you didn't ask for. It's also abused by some nodes (e.g. bc.i) to constantly, over and overagain, spam a zillion transactions that you already have.
186 2014-08-23 23:43:55 <BlueMatt> I thought the point of the p2p protocol was that it was stateless...I hope you dont have a state machine there
187 2014-08-23 23:43:59 <gmaxwell> there are some nodes that every block vomit their complete mempool at you.
188 2014-08-23 23:44:09 <BlueMatt> but, yea, its a waste of bw, but its not a dos risk or anything
189 2014-08-23 23:46:10 <andytoshi> :D https://testing.wpsoftware.net/coinjoin/session.php?id=2fc8f72192076383
190 2014-08-23 23:46:14 <andytoshi> thx for all your help guys
191 2014-08-23 23:46:58 <gmaxwell> well, it's potentially a DOS riskâ or rather makes some approaches to avoiding DOS somewhat harderâ, in that your peers can cause you to use memory what you weren't expecting. at least temporarily holding a transaction to recieve it and decide if you want to keep it or not. E.g. perhaps you would have held off pulling more transactions until you'd worked through your queues. If the protocol didn't allow it you could ban peers that ...
192 2014-08-23 23:47:02 <andytoshi> (this is what the new joiner looks like ... it does not do "safe" fee/donation handling yet, but i think it's otherwise ready)
193 2014-08-23 23:47:04 <gmaxwell> ... were spamming you with stuff you didn't request.
194 2014-08-23 23:48:14 <BlueMatt> gmaxwell: you can manage your incoming data queue however you want, keep your kernel incoming queue small and only pull data from kernel when you're ready to process it
195 2014-08-23 23:48:45 <gmaxwell> BlueMatt: It's not like the kernel has magical free memory. :P
196 2014-08-23 23:48:54 <BlueMatt> gmaxwell: no, but you can keep its queue small
197 2014-08-23 23:49:33 <gmaxwell> Fair enough, it still leaves you with the insane spammy nodes.
198 2014-08-23 23:49:47 <BlueMatt> so if the node is dumb and spamming you, just ban it
199 2014-08-23 23:50:11 <BlueMatt> if you only ever get transactions from it that you've already seen and thats all its providing, ban it
200 2014-08-23 23:50:13 <gmaxwell> I think we could do this, but it would be effectively a change in the protocol.
201 2014-08-23 23:50:33 <BlueMatt> (just like you should ban any node which is taking a non-proprtional amoutn of your resources)
202 2014-08-23 23:50:39 <BlueMatt> but I dont think its a transaction-only thing
203 2014-08-23 23:50:42 <gmaxwell> eeeehhh.
204 2014-08-23 23:51:28 <gmaxwell> thats very riskyâ the non-proportional thing. An attacker just needs to find a way to trigger the non-proportionality behavior remotely without it being triggered on them and they can carve the network up.
205 2014-08-23 23:51:42 <BlueMatt> if any given node is constantly spamming you with messages and you cant keep up....
206 2014-08-23 23:51:50 <BlueMatt> yea, sure, proportionality is probably a bad measure
207 2014-08-23 23:52:02 <BlueMatt> its more about keeping up and checking wheterh messages were useful
208 2014-08-23 23:52:18 <gmaxwell> We've been careful to avoid banning on valid behavior even if its abusive due to that risk.
209 2014-08-23 23:52:50 <BlueMatt> it depends on how abusive
210 2014-08-23 23:53:02 <BlueMatt> if its an old version sending spammy transactions with fees, its probably fair to ban
211 2014-08-23 23:53:03 <jgarzik> http://www.reddit.com/r/Bitcoin/comments/2eekr8/ann_bitcoin_blockchain_data_torrent_updated_to/
212 2014-08-23 23:53:45 <gmaxwell> So you get a bunch of quiet sybil peers to a target victim node, and spam the honest network a bunch... and now the victim is partitioned. I really think that we should probably never ban on behavior that a well constructed peer might possibly consider 'surprising'.
213 2014-08-23 23:55:51 <BlueMatt> gmaxwell: I didnt say surprising
214 2014-08-23 23:56:14 <BlueMatt> relaying transactions with obviously dumb fees, double-spends avoiding fees, etc
215 2014-08-23 23:56:26 <sipa> any other acks on 4683?
216 2014-08-23 23:57:16 <BlueMatt> sipa: I'll queue it and hopefully get to it today