1 2016-07-10 00:00:31	0|petertodd|I could make use of a breakdown by age fwiw
  2 2016-07-10 00:01:37	0|sipa|yeah, i'll create such a graph too
  3 2016-07-10 00:01:44	0|sipa|should be easier as it doesn't require reindexing
  4 2016-07-10 00:01:52	0|gmaxwell|I'm thinking it would be interesting to solve the following optimization problem:  given a set of utxo size, birth/death times, value.  Find the coefficients of multinomial a f(value,size,age_in_blocks) such that a fixed cache of size N with retention sorted by f() has the highest hitrate (item still in cache at utxo death).
  5 2016-07-10 00:02:21	0|petertodd|sipa: thanks!
  6 2016-07-10 00:03:35	0|petertodd|gmaxwell: though note that you probably can't bake something like that into a consensus thing like txo commitments w/ utxo cache, as it changes peoples' behavior...
  7 2016-07-10 00:03:50	0|petertodd|gmaxwell: potentially still useful for local optimisation though
  8 2016-07-10 00:08:41	0|gmaxwell|petertodd: well you can to some extent, for example, having a different cache policy at some threshold, like 1BTC... 21 million txo is the absolute maximum number of outputs at 1BTC+ so there is a pretty strong upper bound on whatever impact you could have on encouraging people to make utxo at or over 1 BTC. :)
  9 2016-07-10 00:10:23	0|petertodd|gmaxwell: I mean, if you take the coefficients from prior data, they're likely to be wrong after people change their behavior - if you use coefficients, you need to have a different rational is all I'm saying
 10 2016-07-10 00:10:50	0|petertodd|gmaxwell: keeping higher value UTXO's in cache longer probably does make sense
 11 2016-07-10 00:11:44	0|gmaxwell|yea sure.. the full answer isn't probably that useful as a consensus rule
 12 2016-07-10 00:11:55	0|gmaxwell|The part of the answer that tells you some value breakpoint(s) may be.
 13 2016-07-10 00:12:38	0|gmaxwell|because even if they're slightly wrong due to changing usage which they themselves incentivize, the whole prospect of having value relative retention is reasonable.
 14 2016-07-10 00:13:35	0|gmaxwell|e.g. if age * value is a good scoring function on the past data, it probably is a robust one, which could be prudently used in consensus.
 15 2016-07-10 00:14:52	0|petertodd|yup
 16 2016-07-10 00:15:05	0|gmaxwell|or some polynomial on age * value.  Or really I think any degree multinomial on age and value is probably also okay.  Only size is one that is probably busted. :)
 17 2016-07-10 00:15:50	0|petertodd|gmaxwell: speaking of, what approaches are good for writing polynomials in consensus critical code? (I wonder if someone has a writeup on that)
 18 2016-07-10 00:25:55	0|gmaxwell|So-- if possible, probably best by converting it to a simple segmented linear approximation. But failing that, I would assume fixed point with horner's method (see wikipedia) which is more computationally efficient and has better numerical properties than the naieve way you'd compute it.
 19 2016-07-10 00:27:02	0|gmaxwell|this is where you write is as a c0 + x * (c1 + x * (c2 + x *....
 20 2016-07-10 00:28:38	0|gmaxwell|petertodd: there are all sorts of 'consensus critical' polynomials in opus (ones where a discrepency in the integer value returned causes a total entropy decoding failure)-- they never were a big issue, they're written like that, and we tested them exhaustively. no biggie.
 21 2016-07-10 00:31:30	0|petertodd|gmaxwell: cool, thanks. re: exhaustively, I assume that's 16bit ints at most?
 22 2016-07-10 00:31:53	0|gmaxwell|no, 32 bits.
 23 2016-07-10 00:32:20	0|gmaxwell|for some function thats just doing some multiplies and adds, trying all 32 bit inputs isn't a big deal.
 24 2016-07-10 00:32:20	0|petertodd|gmaxwell: huh, how does that work?
 25 2016-07-10 00:32:32	0|petertodd|gmaxwell: wait, as in 2^64?
 26 2016-07-10 00:33:01	0|sipa|i assume it's a function with 1 input :)
 27 2016-07-10 00:33:06	0|kanzure|https://github.com/xiph/opus/blob/58dbcf23f3aecfb9c06abaef590d01bb3dba7a5a/celt/cwrs.c#L164
 28 2016-07-10 00:33:35	0|gmaxwell|no, as in computing f(x) where x is some 32 bit value and x is a single variable polynomial in x.  :)
 29 2016-07-10 00:34:14	0|petertodd|gmaxwell: yeah, that makes a lot more sense :)
 30 2016-07-10 00:34:50	0|petertodd|gmaxwell: I'm writing a spec for dex, and it's interesting how you can make an argument for only supporting 16-bit ints natively, as you can exhaustively test them
 31 2016-07-10 00:34:58	0|gmaxwell|yes, indeed that is a bit normative polynomial, though I think the current CWRS code there mostly uses tables.
 32 2016-07-10 00:36:19	0|gmaxwell|petertodd: thats something you could argue, though it would have to be weighed against footgun and bloat risks.
 33 2016-07-10 00:36:47	0|gmaxwell|(though I suppose I could make a anti-footgun argument-- the user is much more likely to _know_ the range of the type is limited, when it's so limited they are constantly forced to deal with it)
 34 2016-07-10 00:37:22	0|gmaxwell|over and underflow can be defined as script failure.
 35 2016-07-10 00:37:23	0|petertodd|gmaxwell: yeah, it'd only be practical if you can write reasonably efficient n-bit add/multiply/etc. routines, and make them part of the built-in library
 36 2016-07-10 00:38:05	0|petertodd|gmaxwell: yes, I'm planning on under/overflow to be a failure condition (probably with wrapping and/or overflow variants)
 37 2016-07-10 00:38:09	0|gmaxwell|petertodd: also a commonly interesting case is things like where one input has small range, and that doesn't really impede exaustive testing.
 38 2016-07-10 00:38:50	0|gmaxwell|e.g. U32 * U8.  It's really common in software to take arbritary numbers and multiply or divide them by small constants.
 39 2016-07-10 00:38:53	0|petertodd|gmaxwell: so, what I noted in my draft spec doc, is that interestingly economicly relevant numbers often have quite large ranges: e.g. coin value
 40 2016-07-10 00:39:09	0|gmaxwell|like computing 2/3 of a coin value.
 41 2016-07-10 00:39:31	0|petertodd|gmaxwell: though, consensus critical economic use-cases just need summation, not multiplication/division (usually)
 42 2016-07-10 00:40:07	0|sipa|petertodd: but but demurrage
 43 2016-07-10 00:40:17	0|gmaxwell|for example, you may want to compute input * 2/3, and input - input * 2/3.
 44 2016-07-10 00:40:29	0|gmaxwell|for value splits in a contract.
 45 2016-07-10 00:40:33	0|gmaxwell|and input is 64 bits.
 46 2016-07-10 00:41:47	0|petertodd|sipa: ok, austrian economics... :P
 47 2016-07-10 00:42:37	0|petertodd|gmaxwell: well, once you talk about contracts more genreally, you get interest calculations, which gets very complex...
 48 2016-07-10 00:43:03	0|gmaxwell|polynomial approximations of interest calculations generally work fine over limited ranges.
 49 2016-07-10 00:43:04	0|petertodd|gmaxwell: but I'm assuming sane contracts would generally only need a few calculations along those lines, so slower approaches should be ok
 50 2016-07-10 00:43:50	0|petertodd|yeah, polynomial approx being one approach
 51 2016-07-10 00:44:50	0|petertodd|in any case, it's looking like having reasonable type checking is a way harder and more complex problem :)
 52 2016-07-10 00:45:17	0|gmaxwell|one nice way for exponential functions is to use CLZ to get the integer part of a base 2 log, and then use a polynomial correction.
 53 2016-07-10 00:45:29	0|petertodd|gmaxwell: CLZ?
 54 2016-07-10 00:45:34	0|sipa|count leading zeroes
 55 2016-07-10 00:45:38	0|petertodd|sipa: ah!
 56 2016-07-10 00:45:39	0|sipa|__builtin_clz
 57 2016-07-10 00:49:03	0|gmaxwell|er actually its the log you want the clz for, for exp you just need to use the leading bits of the number.
 58 2016-07-10 00:49:49	0|gmaxwell|https://github.com/xiph/opus/blob/58dbcf23f3aecfb9c06abaef590d01bb3dba7a5a/celt/mathops.h#L184 is such an example. (of course to get to any other base for the exponential is just some scaling)
 59 2016-07-10 00:50:37	0|petertodd|gmaxwell: a neat article to write would be numerical methods for consensus critical code :)
 60 2016-07-10 00:51:10	0|sipa|"Bounded memory, bounded CPU usage... and bounded errors"
 61 2016-07-10 00:51:25	0|gmaxwell|I think they mostly end up like numerical methods for fixed point realtime dsp.
 62 2016-07-10 00:51:33	0|petertodd|sipa: lol, did chris send you a copy of my spec? :P
 63 2016-07-10 00:51:39	0|sipa|no
 64 2016-07-10 00:51:47	0|sipa|well, maybe he did, but i did not look at it
 65 2016-07-10 00:51:55	0|petertodd|sipa: I mean, I have basically the exact same sentence in it - though no surprise, same problem :)
 66 2016-07-10 00:52:05	0|petertodd|gmaxwell: yeah, probably true
 67 2016-07-10 00:52:12	0|gmaxwell|with perhaps some additional considerations for exhaustive testing and/or formal verification.
 68 2016-07-10 00:53:42	0|gmaxwell|but yea, the other reason you exaustively test these approximations is to characterize the worst case error: https://github.com/xiph/opus/blob/58dbcf23f3aecfb9c06abaef590d01bb3dba7a5a/celt/mathops.c#L202
 69 2016-07-10 00:54:31	0|petertodd|bbl, need a bigger battery...
 70 2016-07-10 00:55:41	0|midnightmagic|i wonder how heavy that special 9-cell thinkpad thing is
 71 2016-07-10 01:09:01	0|petertodd|midnightmagic: doesn't help that mine is a few years old - batteries wearing out
 72 2016-07-10 01:09:56	0|sipa|petertodd: protip, when buying a new laptop, buy an extra battery that fits... once your battery wears out they'll be harder to find
 73 2016-07-10 01:10:18	0|petertodd|sipa: good advice - though I've never actualy bought a laptop new
 74 2016-07-10 01:10:32	0|midnightmagic|petertodd: why not?
 75 2016-07-10 01:10:51	0|petertodd|midnightmagic: because I act like I'm a poor student :P
 76 2016-07-10 01:12:17	0|petertodd|midnightmagic: I have a t520 right now, which I think is about four years old
 77 2016-07-10 01:18:24	0|midnightmagic|Humility and reasonable resource management are virtues.
 78 2016-07-10 01:20:02	0|petertodd|midnightmagic: well, I was going through my corporate expenses the other day... and a new laptop would be a drop in the bucket compared to what gets spent on me travelling
 79 2016-07-10 01:21:10	0|midnightmagic|i hate travelling :( the world is made for people much, much smaller than I am.
 80 2016-07-10 01:22:49	0|petertodd|midnightmagic: I actually find I get more work done; I'm no tourist so when I'm in the middle of a foreign country I tend to find somewhere to sit down with my laptop :)
 81 2016-07-10 01:25:02	0|midnightmagic|i do too, all the stuff that is on the to-do list in my home can't be addressed so I can let it go
 82 2016-07-10 01:26:21	0|petertodd|midnightmagic: yeah, and when I'm home, friends want to like, hang out with me and take up all my time :P
 83 2016-07-10 01:30:56	0|midnightmagic|psh. friends. so annoying.
 84 2016-07-10 01:56:28	0|petertodd|sure
 85 2016-07-10 01:56:45	0|petertodd|er, wrong window - stupid lag
 86 2016-07-10 02:02:21	0|sipa|haha
 87 2016-07-10 02:12:44	0|gmaxwell|sipa: lithion ion batteries of varrious type have a shelf life, sadly.
 88 2016-07-10 02:12:50	0|gmaxwell|The unused one will also fade.
 89 2016-07-10 02:13:07	0|gmaxwell|But fortunately if you buy something like a thinkpad, people make batteries for them forever.
 90 2016-07-10 02:13:16	0|gmaxwell|You can buy batteries for ten year old thinkpads no problem.
 91 2016-07-10 02:20:40	0|gmaxwell|petertodd: go stab the people your blog post has confused: https://www.reddit.com/r/Bitcoin/comments/4s3a9r/segwit_code_review_update/
 92 2016-07-10 02:41:07	0|kanzure|consensus-related non-malleability vs wallet/p2p-level, is my guess.
 93 2016-07-10 02:42:42	0|petertodd|kanzure: it's just a flaw in the way the mempool/p2p refers to segwit txs; has little if anything to do with consensus
 94 2016-07-10 02:46:25	0|petertodd|kanzure: tl;dr: is that the p2p asks for txs by txid, which doesn't commit to the witness, and marks invalid txs by txid, without being able to consistently know if a tx was invalid due to a bad witness
 95 2016-07-10 02:46:38	0|petertodd|equaly, s/invalid/unacceptable due to fee, size, whatever/
 96 2016-07-10 02:46:54	0|sipa|i actually don't think the flaw is referring by txid instead of wtxid
 97 2016-07-10 02:47:00	0|petertodd|sipa: how so?
 98 2016-07-10 02:47:25	0|sipa|but we should have made resource limits part of the base transaction, not the witness
 99 2016-07-10 02:47:28	0|kanzure|yes i was wondering about things like "how to actually show a node that a certain tx is valid later, if at first it receives a bad witness" :\
100 2016-07-10 02:48:01	0|petertodd|sipa: what do you mean by that?
101 2016-07-10 02:48:03	0|sipa|(fees, sigop count, byte sizes) go in scriptSig... or even better, in the inv
102 2016-07-10 02:48:24	0|sipa|so a node can decide to not process before you know... processing
103 2016-07-10 02:48:50	0|petertodd|sipa: duplicating that stuff has historically lead to endless problems, basically because you have to check it twice
104 2016-07-10 02:49:19	0|sipa|how do you mean?
105 2016-07-10 02:49:29	0|petertodd|sipa: in a decent system, processing even invalid txs is something that happens very quickly, so there's no DoS attack
106 2016-07-10 02:49:50	0|petertodd|sipa: notice how satoshi screwed up sigops from the beginning...
107 2016-07-10 02:50:12	0|sipa|unfortunately, fees and sigop counting require fetching the utxos
108 2016-07-10 02:50:17	0|petertodd|sipa: in any of these schemes, you still have to count up sigops as they're actually executed, to check that the sum matches (or is less than) the claimed sum
109 2016-07-10 02:50:24	0|sipa|of course
110 2016-07-10 02:50:42	0|petertodd|sipa: so? fetching utxos can't be expensive, or we've already lost
111 2016-07-10 02:50:45	0|sipa|but a mismatch can then actually result in a ban, because it cannot happen accidentally
112 2016-07-10 02:51:27	0|petertodd|sipa: if we used wtxids, you could still ban based on that
113 2016-07-10 02:51:36	0|sipa|but our rate limiting is based on feerate, which depends on fee, which we cannot enforce until we've done the effort
114 2016-07-10 02:52:03	0|sipa|if there is no rate limit, even a cheap validation per transaction will be too much
115 2016-07-10 02:52:33	0|petertodd|sipa: huh? someone sends you a DoS tx, just ban them - there's no reason *legit* transactions should take significant cost to accept
116 2016-07-10 02:54:02	0|sipa|petertodd: so there is a trivial solution... fully validate every transaction you asked for
117 2016-07-10 02:54:31	0|sipa|so you don't prematurely discard a transaction before finding out it was an attempted attack
118 2016-07-10 02:55:16	0|sipa|it is too expensive, or invalid, or malleated... you can ban who sent it
119 2016-07-10 02:55:39	0|petertodd|sipa: I think you're missing my point: the threshold that we consider it an "attempted attack" should be low enough that there's no DoS issues; txs fundementally should never be expensive to validate, and cases where they are should be non-standard, and eventually, removed entirely from the protocol
120 2016-07-10 02:56:11	0|sipa|yes
121 2016-07-10 02:56:13	0|sipa|i agree
122 2016-07-10 02:57:04	0|sipa|but the issue here is that we fail to detect whether a too expensive transacrion is due to its creator or due to who relayed it
123 2016-07-10 02:57:36	0|petertodd|sipa: right, but wtxid solves that issue
124 2016-07-10 02:58:07	0|petertodd|if relayer malleates, we'll still ask for a different version of the same txid if another peer gives us it
125 2016-07-10 02:58:10	0|sipa|yes, it would... but it adds complications
126 2016-07-10 02:58:21	0|petertodd|how so?
127 2016-07-10 02:58:33	0|sipa|you need indexes by both txid and wtxid..
128 2016-07-10 02:58:54	0|sipa|and you always risk requesting things twice
129 2016-07-10 02:58:56	0|petertodd|sipa: in what, the mempool/p2p?
130 2016-07-10 02:59:06	0|petertodd|but they are different things!
131 2016-07-10 02:59:28	0|sipa|in my view they are the same thing
132 2016-07-10 02:59:36	0|sipa|one with an optional part omitted
133 2016-07-10 02:59:48	0|sipa|except we only find out too late that it was not optional
134 2016-07-10 03:00:03	0|petertodd|well, I don't agree at all - the optional part has a non-optinal effect on the tx
135 2016-07-10 03:00:27	0|sipa|for those who care (which a full node does)
136 2016-07-10 03:00:49	0|sipa|that's a semantic discussion, though
137 2016-07-10 03:00:56	0|petertodd|I certainly care: my tx fees depend on the witness
138 2016-07-10 03:00:56	0|sipa|i can see your point
139 2016-07-10 03:01:28	0|petertodd|I may also have a protocol where I'm publishing something in the witness, e.g. hashlock
140 2016-07-10 03:01:46	0|gmaxwell|Cleanstack means that ordinary transactions cannot have their fees increased without invalidating them. (If not for that I would have already recommended we have some preprocessing to strip transactions as they're relayed)
141 2016-07-10 03:02:07	0|sipa|i think the easiest solution is to validate scripts even for things we know we won't accept
142 2016-07-10 03:02:15	0|gmaxwell|You should probably assume that relaying nodes will perform witness stripping in the future.
143 2016-07-10 03:02:23	0|sipa|we have spent almost all the work anyway (fetched inputs, and wasted bandwidth)
144 2016-07-10 03:02:34	0|petertodd|gmaxwell: with currnet tx patterns yes; it's non-trivial to make txs with more complex scripts that have non-malleable witnesses
145 2016-07-10 03:03:19	0|gmaxwell|(by witness stripping I mean compacting the witness to the minimal data needed to be valid, as best it can determine)
146 2016-07-10 03:03:23	0|petertodd|sipa: as in, valiate scripts to determine if the witness is wrong?
147 2016-07-10 03:03:30	0|gmaxwell|Yes.
148 2016-07-10 03:03:51	0|gmaxwell|This was something I had been advocating for a while because there are some other potential DOS attacks that exist because we don't.
149 2016-07-10 03:03:59	0|gmaxwell|(a while = before segwit existed)
150 2016-07-10 03:04:17	0|petertodd|well, again, that assumes you know how to clean witnesses - there are tx patterns where that's not trivial (and indeed, the user may intentionally have more than one form of witness for the same txid)
151 2016-07-10 03:04:21	0|gmaxwell|though without an enforced feefilter its a bit less than ideal.
152 2016-07-10 03:04:43	0|gmaxwell|petertodd: sure any cleaning would always be a best effort attempt.
153 2016-07-10 03:05:02	0|petertodd|I'm still of the opinion that asking for a wtxid is a way simpler overall conceptual design (obvs implementation level may suck due to historical baggage)
154 2016-07-10 03:05:15	0|sipa|this is orthogonal to fetching by wtxid, of course
155 2016-07-10 03:05:47	0|petertodd|it's not orthogonal at all: if I manage to clean a script significantly, I want my peers to get it, and then say "hey, this is way smaller, lets replace it in our mempool..."
156 2016-07-10 03:05:53	0|gmaxwell|yea, I agree it's orthorgonal, fetching by wtxid has an amplification attack vector that is kind of sad.
157 2016-07-10 03:06:12	0|petertodd|gmaxwell: what's the vector?
158 2016-07-10 03:06:42	0|sipa|gmaxwell: presenting multiple versions of the same transaction with different witness?
159 2016-07-10 03:06:56	0|gmaxwell|The amplification attack vector is that I create grab transactions and relay witness malleations to every node in the network, different version to each node, so when I happen to get txn early every node ends up with a different txid and you get N^2 bandwidth forwarding it around.
160 2016-07-10 03:07:09	0|petertodd|gmaxwell: but you can do that anyway with your own txs
161 2016-07-10 03:09:16	0|sipa|you could of course create invs with both txids and wtxids
162 2016-07-10 03:09:45	0|petertodd|sipa: yeah, that'd be fine
163 2016-07-10 03:09:56	0|petertodd|sipa: and obviously, our peer can tell us it's segwit and wants us to do that
164 2016-07-10 03:10:30	0|sipa|except that also breaks your try to replace with smaller witness use case
165 2016-07-10 03:10:58	0|petertodd|sipa: why? once you go down that rabbit hole, you can also advertise length
166 2016-07-10 03:11:18	0|sipa|petertodd: yes, that was my suggestion in the beginning of the discussion :)
167 2016-07-10 03:11:32	0|sipa|advertize sigops/size/fees in the inv
168 2016-07-10 03:11:51	0|petertodd|sipa: no, you suggested having the tx _commit_ to that info, which is a very different thing; non-consensus critical code advertising length isn't a big deal
169 2016-07-10 03:12:02	0|sipa|petertodd: reread my sentence
170 2016-07-10 03:12:09	0|petertodd|sipa: ah, ok, I have no issues with that
171 2016-07-10 03:12:23	0|petertodd|sipa: (I've been thinking about this exact kind of issue for my dex specification actually)
172 2016-07-10 03:12:27	0|sipa|"... or even better, in the inv$
173 2016-07-10 03:12:59	0|petertodd|sipa: yeah, for mempool I think invs advertising this stuff makes a lot of sense
174 2016-07-10 03:13:18	0|petertodd|for starters, if we screw that up, it's relatively easy to fix :)
175 2016-07-10 03:13:18	0|sipa|though i think it's not necessarily an urgent issue
176 2016-07-10 03:14:01	0|petertodd|so, is a reasonable game plan to releast segwit with the current p2p design, and then add wtixds to invs later? (potentially with sigops/size in the inv)
177 2016-07-10 03:14:01	0|sipa|the worst case is that a bad peer can poison your reject cache, preventing you from getting a legitimate transaction before it confirms
178 2016-07-10 03:14:12	0|petertodd|sipa: it's a good thing no-one relies on zeroconf anymore :P
179 2016-07-10 03:14:24	0|sipa|i'm sure there are other ways that you can accomplish that
180 2016-07-10 03:14:33	0|sipa|(like inving and not responding to getdata)
181 2016-07-10 03:14:37	0|gmaxwell|wrt different kinds of relaying later, mostly I thought those improvements would go into mempool sync.
182 2016-07-10 03:15:35	0|gmaxwell|and rather than wtxid relay,  wtxid,feerate,txid tuples (probably truncated/quantized) may make more sense.
183 2016-07-10 03:16:12	0|sipa|yeah, for mempool sync we can redesign things cleanyl
184 2016-07-10 03:16:27	0|petertodd|gmaxwell: note too how schemes like txo commitments allow - and expect - nodes to do significant modifications to txs
185 2016-07-10 03:16:30	0|gmaxwell|(or even wtxid, feerate, vin id with lowest hash)
186 2016-07-10 03:18:09	0|gmaxwell|in any case, optimal sync behavior in the presence of double spends (of any kind) isn't a nut I've cracked yet.
187 2016-07-10 03:18:10	0|sipa|petertodd: yes, the priority should be to make sure no internal inconsistency or banning of unaware nodes occur
188 2016-07-10 03:18:27	0|gmaxwell|I think I have constructions for schemes which are close to optimal absent doublespends.
189 2016-07-10 03:18:50	0|gmaxwell|we already improved relay efficiency a LOT in 0.13, fwiw.
190 2016-07-10 03:19:09	0|sipa|petertodd: rejectioncache behaviour can either degenerate into attackers preventing you from receiving transactions on the one hand
191 2016-07-10 03:19:50	0|sipa|or to the old pre-rejectioncache bevahiour of requesting failed txn from every peer (which is made much less bad due to feefilter already)
192 2016-07-10 03:21:34	0|gmaxwell|there are already several trivially exploited ways where an attacker can massively delay you getting a transaction.
193 2016-07-10 03:21:44	0|petertodd|sipa: well, again, an attacker can do that DoS attack without segwit by just sending multiple slightly different versions of the same tx
194 2016-07-10 03:22:19	0|gmaxwell|(e.g. just inv the damn thing from many sockets and don't respond.
195 2016-07-10 03:22:21	0|gmaxwell|)
196 2016-07-10 03:24:16	0|sipa|yeah
197 2016-07-10 20:34:23	0|oddishh|WOW! My bitcoin expander is now READY! Put some bitcoin in my wallet and I'll intantly expand it & send you more back. Totally vouched & legit. PM me to begin!
198 2016-07-10 23:41:52	0|grubles|1/3
199 2016-07-10 23:41:59	0|grubles|oops. sorry.
200 2016-07-10 23:42:05	0|sipa|0.33333333
201 2016-07-10 23:42:35	0|grubles|:)