12016-07-10T00:00:31  <petertodd> I could make use of a breakdown by age fwiw
  22016-07-10T00:01:36  <sipa> yeah, i'll create such a graph too
  32016-07-10T00:01:44  <sipa> should be easier as it doesn't require reindexing
  42016-07-10T00:01:52  <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).
  52016-07-10T00:02:21  <petertodd> sipa: thanks!
  62016-07-10T00:03:34  <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...
  72016-07-10T00:03:49  <petertodd> gmaxwell: potentially still useful for local optimisation though
  82016-07-10T00:08:41  <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. :)
  92016-07-10T00:10:22  <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
 102016-07-10T00:10:49  <petertodd> gmaxwell: keeping higher value UTXO's in cache longer probably does make sense
 112016-07-10T00:11:44  <gmaxwell> yea sure.. the full answer isn't probably that useful as a consensus rule
 122016-07-10T00:11:48  *** johhnyfive has joined #bitcoin-core-dev
 132016-07-10T00:11:55  <gmaxwell> The part of the answer that tells you some value breakpoint(s) may be.
 142016-07-10T00:12:38  <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.
 152016-07-10T00:13:35  <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.
 162016-07-10T00:14:52  <petertodd> yup
 172016-07-10T00:15:05  <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. :)
 182016-07-10T00:15:49  <petertodd> gmaxwell: speaking of, what approaches are good for writing polynomials in consensus critical code? (I wonder if someone has a writeup on that)
 192016-07-10T00:17:03  *** spudowiar has joined #bitcoin-core-dev
 202016-07-10T00:20:56  *** Chris_Stewart_5 has quit IRC
 212016-07-10T00:25:55  <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.
 222016-07-10T00:27:01  <gmaxwell> this is where you write is as a c0 + x * (c1 + x * (c2 + x *....
 232016-07-10T00:28:37  <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.
 242016-07-10T00:31:30  <petertodd> gmaxwell: cool, thanks. re: exhaustively, I assume that's 16bit ints at most?
 252016-07-10T00:31:53  <gmaxwell> no, 32 bits.
 262016-07-10T00:32:19  <petertodd> gmaxwell: huh, how does that work?
 272016-07-10T00:32:20  <gmaxwell> for some function thats just doing some multiplies and adds, trying all 32 bit inputs isn't a big deal.
 282016-07-10T00:32:31  <petertodd> gmaxwell: wait, as in 2^64?
 292016-07-10T00:33:00  <sipa> i assume it's a function with 1 input :)
 302016-07-10T00:33:05  <kanzure> https://github.com/xiph/opus/blob/58dbcf23f3aecfb9c06abaef590d01bb3dba7a5a/celt/cwrs.c#L164
 312016-07-10T00:33:35  <gmaxwell> no, as in computing f(x) where x is some 32 bit value and x is a single variable polynomial in x.  :)
 322016-07-10T00:34:13  <petertodd> gmaxwell: yeah, that makes a lot more sense :)
 332016-07-10T00:34:50  <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
 342016-07-10T00:34:58  <gmaxwell> yes, indeed that is a bit normative polynomial, though I think the current CWRS code there mostly uses tables.
 352016-07-10T00:36:18  <gmaxwell> petertodd: thats something you could argue, though it would have to be weighed against footgun and bloat risks.
 362016-07-10T00:36:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 372016-07-10T00:36:47  <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)
 382016-07-10T00:37:22  <gmaxwell> over and underflow can be defined as script failure.
 392016-07-10T00:37:23  <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
 402016-07-10T00:38:04  <petertodd> gmaxwell: yes, I'm planning on under/overflow to be a failure condition (probably with wrapping and/or overflow variants)
 412016-07-10T00:38:08  <gmaxwell> petertodd: also a commonly interesting case is things like where one input has small range, and that doesn't really impede exaustive testing.
 422016-07-10T00:38:50  <gmaxwell> e.g. U32 * U8.  It's really common in software to take arbritary numbers and multiply or divide them by small constants.
 432016-07-10T00:38:52  <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
 442016-07-10T00:39:09  <gmaxwell> like computing 2/3 of a coin value.
 452016-07-10T00:39:31  <petertodd> gmaxwell: though, consensus critical economic use-cases just need summation, not multiplication/division (usually)
 462016-07-10T00:40:07  <sipa> petertodd: but but demurrage
 472016-07-10T00:40:17  <gmaxwell> for example, you may want to compute input * 2/3, and input - input * 2/3.
 482016-07-10T00:40:29  <gmaxwell> for value splits in a contract.
 492016-07-10T00:40:33  <gmaxwell> and input is 64 bits.
 502016-07-10T00:41:47  <petertodd> sipa: ok, austrian economics... :P
 512016-07-10T00:41:56  *** jtimon has joined #bitcoin-core-dev
 522016-07-10T00:42:37  <petertodd> gmaxwell: well, once you talk about contracts more genreally, you get interest calculations, which gets very complex...
 532016-07-10T00:43:03  <gmaxwell> polynomial approximations of interest calculations generally work fine over limited ranges.
 542016-07-10T00:43:04  <petertodd> gmaxwell: but I'm assuming sane contracts would generally only need a few calculations along those lines, so slower approaches should be ok
 552016-07-10T00:43:50  <petertodd> yeah, polynomial approx being one approach
 562016-07-10T00:44:49  <petertodd> in any case, it's looking like having reasonable type checking is a way harder and more complex problem :)
 572016-07-10T00:45:17  <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.
 582016-07-10T00:45:29  <petertodd> gmaxwell: CLZ?
 592016-07-10T00:45:34  <sipa> count leading zeroes
 602016-07-10T00:45:38  <petertodd> sipa: ah!
 612016-07-10T00:45:38  <sipa> __builtin_clz
 622016-07-10T00:49:03  <gmaxwell> er actually its the log you want the clz for, for exp you just need to use the leading bits of the number.
 632016-07-10T00:49:49  <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)
 642016-07-10T00:50:24  *** belcher has quit IRC
 652016-07-10T00:50:37  <petertodd> gmaxwell: a neat article to write would be numerical methods for consensus critical code :)
 662016-07-10T00:51:10  <sipa> "Bounded memory, bounded CPU usage... and bounded errors"
 672016-07-10T00:51:25  <gmaxwell> I think they mostly end up like numerical methods for fixed point realtime dsp.
 682016-07-10T00:51:32  <petertodd> sipa: lol, did chris send you a copy of my spec? :P
 692016-07-10T00:51:38  <sipa> no
 702016-07-10T00:51:46  <sipa> well, maybe he did, but i did not look at it
 712016-07-10T00:51:55  <petertodd> sipa: I mean, I have basically the exact same sentence in it - though no surprise, same problem :)
 722016-07-10T00:52:05  <petertodd> gmaxwell: yeah, probably true
 732016-07-10T00:52:12  <gmaxwell> with perhaps some additional considerations for exhaustive testing and/or formal verification.
 742016-07-10T00:53:42  <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
 752016-07-10T00:54:30  <petertodd> bbl, need a bigger battery...
 762016-07-10T00:55:41  <midnightmagic> i wonder how heavy that special 9-cell thinkpad thing is
 772016-07-10T01:09:01  <petertodd> midnightmagic: doesn't help that mine is a few years old - batteries wearing out
 782016-07-10T01:09:56  <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
 792016-07-10T01:10:18  <petertodd> sipa: good advice - though I've never actualy bought a laptop new
 802016-07-10T01:10:24  * midnightmagic has no user-replaceable battery in his mbp. :(
 812016-07-10T01:10:31  <midnightmagic> petertodd: why not?
 822016-07-10T01:10:51  <petertodd> midnightmagic: because I act like I'm a poor student :P
 832016-07-10T01:12:17  <petertodd> midnightmagic: I have a t520 right now, which I think is about four years old
 842016-07-10T01:18:24  <midnightmagic> Humility and reasonable resource management are virtues.
 852016-07-10T01:20:02  <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
 862016-07-10T01:21:09  <midnightmagic> i hate travelling :( the world is made for people much, much smaller than I am.
 872016-07-10T01:22:48  <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 :)
 882016-07-10T01:25:02  <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
 892016-07-10T01:25:46  *** Ylbam has quit IRC
 902016-07-10T01:26:21  <petertodd> midnightmagic: yeah, and when I'm home, friends want to like, hang out with me and take up all my time :P
 912016-07-10T01:30:56  <midnightmagic> psh. friends. so annoying.
 922016-07-10T01:56:27  <petertodd> sure
 932016-07-10T01:56:44  <petertodd> er, wrong window - stupid lag
 942016-07-10T02:02:20  <sipa> haha
 952016-07-10T02:12:44  <gmaxwell> sipa: lithion ion batteries of varrious type have a shelf life, sadly.
 962016-07-10T02:12:49  <gmaxwell> The unused one will also fade.
 972016-07-10T02:13:07  <gmaxwell> But fortunately if you buy something like a thinkpad, people make batteries for them forever.
 982016-07-10T02:13:16  <gmaxwell> You can buy batteries for ten year old thinkpads no problem.
 992016-07-10T02:20:40  <gmaxwell> petertodd: go stab the people your blog post has confused: https://www.reddit.com/r/Bitcoin/comments/4s3a9r/segwit_code_review_update/
1002016-07-10T02:41:06  <kanzure> consensus-related non-malleability vs wallet/p2p-level, is my guess.
1012016-07-10T02:42:42  <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
1022016-07-10T02:46:06  *** molz has quit IRC
1032016-07-10T02:46:24  <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
1042016-07-10T02:46:37  <petertodd> equaly, s/invalid/unacceptable due to fee, size, whatever/
1052016-07-10T02:46:54  <sipa> i actually don't think the flaw is referring by txid instead of wtxid
1062016-07-10T02:47:00  <petertodd> sipa: how so?
1072016-07-10T02:47:25  <sipa> but we should have made resource limits part of the base transaction, not the witness
1082016-07-10T02:47:28  <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" :\
1092016-07-10T02:47:45  *** moli has joined #bitcoin-core-dev
1102016-07-10T02:48:00  <petertodd> sipa: what do you mean by that?
1112016-07-10T02:48:02  <sipa> (fees, sigop count, byte sizes) go in scriptSig... or even better, in the inv
1122016-07-10T02:48:23  <sipa> so a node can decide to not process before you know... processing
1132016-07-10T02:48:49  <petertodd> sipa: duplicating that stuff has historically lead to endless problems, basically because you have to check it twice
1142016-07-10T02:49:18  <sipa> how do you mean?
1152016-07-10T02:49:29  <petertodd> sipa: in a decent system, processing even invalid txs is something that happens very quickly, so there's no DoS attack
1162016-07-10T02:49:50  <petertodd> sipa: notice how satoshi screwed up sigops from the beginning...
1172016-07-10T02:50:12  <sipa> unfortunately, fees and sigop counting require fetching the utxos
1182016-07-10T02:50:16  <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
1192016-07-10T02:50:24  <sipa> of course
1202016-07-10T02:50:41  <petertodd> sipa: so? fetching utxos can't be expensive, or we've already lost
1212016-07-10T02:50:45  <sipa> but a mismatch can then actually result in a ban, because it cannot happen accidentally
1222016-07-10T02:51:27  <petertodd> sipa: if we used wtxids, you could still ban based on that
1232016-07-10T02:51:35  <sipa> but our rate limiting is based on feerate, which depends on fee, which we cannot enforce until we've done the effort
1242016-07-10T02:51:46  *** johhnyfive has quit IRC
1252016-07-10T02:52:03  <sipa> if there is no rate limit, even a cheap validation per transaction will be too much
1262016-07-10T02:52:07  *** gribble has quit IRC
1272016-07-10T02:52:32  <petertodd> sipa: huh? someone sends you a DoS tx, just ban them - there's no reason *legit* transactions should take significant cost to accept
1282016-07-10T02:54:02  <sipa> petertodd: so there is a trivial solution... fully validate every transaction you asked for
1292016-07-10T02:54:31  <sipa> so you don't prematurely discard a transaction before finding out it was an attempted attack
1302016-07-10T02:55:16  <sipa> it is too expensive, or invalid, or malleated... you can ban who sent it
1312016-07-10T02:55:38  <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
1322016-07-10T02:56:11  <sipa> yes
1332016-07-10T02:56:13  <sipa> i agree
1342016-07-10T02:57:03  <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
1352016-07-10T02:57:35  <petertodd> sipa: right, but wtxid solves that issue
1362016-07-10T02:58:07  <petertodd> if relayer malleates, we'll still ask for a different version of the same txid if another peer gives us it
1372016-07-10T02:58:10  <sipa> yes, it would... but it adds complications
1382016-07-10T02:58:20  <petertodd> how so?
1392016-07-10T02:58:32  <sipa> you need indexes by both txid and wtxid..
1402016-07-10T02:58:42  *** gribble has joined #bitcoin-core-dev
1412016-07-10T02:58:54  <sipa> and you always risk requesting things twice
1422016-07-10T02:58:55  <petertodd> sipa: in what, the mempool/p2p?
1432016-07-10T02:59:06  <petertodd> but they are different things!
1442016-07-10T02:59:28  <sipa> in my view they are the same thing
1452016-07-10T02:59:35  <sipa> one with an optional part omitted
1462016-07-10T02:59:47  <sipa> except we only find out too late that it was not optional
1472016-07-10T03:00:02  <petertodd> well, I don't agree at all - the optional part has a non-optinal effect on the tx
1482016-07-10T03:00:26  <sipa> for those who care (which a full node does)
1492016-07-10T03:00:48  <sipa> that's a semantic discussion, though
1502016-07-10T03:00:56  <sipa> i can see your point
1512016-07-10T03:00:56  <petertodd> I certainly care: my tx fees depend on the witness
1522016-07-10T03:01:04  *** frankenmint has joined #bitcoin-core-dev
1532016-07-10T03:01:28  <petertodd> I may also have a protocol where I'm publishing something in the witness, e.g. hashlock
1542016-07-10T03:01:45  <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)
1552016-07-10T03:02:06  <sipa> i think the easiest solution is to validate scripts even for things we know we won't accept
1562016-07-10T03:02:15  <gmaxwell> You should probably assume that relaying nodes will perform witness stripping in the future.
1572016-07-10T03:02:22  <sipa> we have spent almost all the work anyway (fetched inputs, and wasted bandwidth)
1582016-07-10T03:02:34  <petertodd> gmaxwell: with currnet tx patterns yes; it's non-trivial to make txs with more complex scripts that have non-malleable witnesses
1592016-07-10T03:03:18  <gmaxwell> (by witness stripping I mean compacting the witness to the minimal data needed to be valid, as best it can determine)
1602016-07-10T03:03:23  <petertodd> sipa: as in, valiate scripts to determine if the witness is wrong?
1612016-07-10T03:03:30  <gmaxwell> Yes.
1622016-07-10T03:03:51  <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.
1632016-07-10T03:03:59  <gmaxwell> (a while = before segwit existed)
1642016-07-10T03:04:17  <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)
1652016-07-10T03:04:20  <gmaxwell> though without an enforced feefilter its a bit less than ideal.
1662016-07-10T03:04:42  <gmaxwell> petertodd: sure any cleaning would always be a best effort attempt.
1672016-07-10T03:05:02  <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)
1682016-07-10T03:05:14  <sipa> this is orthogonal to fetching by wtxid, of course
1692016-07-10T03:05:47  <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..."
1702016-07-10T03:05:53  <gmaxwell> yea, I agree it's orthorgonal, fetching by wtxid has an amplification attack vector that is kind of sad.
1712016-07-10T03:06:11  <petertodd> gmaxwell: what's the vector?
1722016-07-10T03:06:42  <sipa> gmaxwell: presenting multiple versions of the same transaction with different witness?
1732016-07-10T03:06:56  <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.
1742016-07-10T03:07:09  <petertodd> gmaxwell: but you can do that anyway with your own txs
1752016-07-10T03:09:15  <sipa> you could of course create invs with both txids and wtxids
1762016-07-10T03:09:45  <petertodd> sipa: yeah, that'd be fine
1772016-07-10T03:09:55  <petertodd> sipa: and obviously, our peer can tell us it's segwit and wants us to do that
1782016-07-10T03:10:29  <sipa> except that also breaks your try to replace with smaller witness use case
1792016-07-10T03:10:58  <petertodd> sipa: why? once you go down that rabbit hole, you can also advertise length
1802016-07-10T03:11:18  <sipa> petertodd: yes, that was my suggestion in the beginning of the discussion :)
1812016-07-10T03:11:31  <sipa> advertize sigops/size/fees in the inv
1822016-07-10T03:11:51  <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
1832016-07-10T03:11:54  *** kekstone has joined #bitcoin-core-dev
1842016-07-10T03:12:01  <sipa> petertodd: reread my sentence
1852016-07-10T03:12:08  <petertodd> sipa: ah, ok, I have no issues with that
1862016-07-10T03:12:22  <petertodd> sipa: (I've been thinking about this exact kind of issue for my dex specification actually)
1872016-07-10T03:12:26  <sipa> "... or even better, in the inv$
1882016-07-10T03:12:59  <petertodd> sipa: yeah, for mempool I think invs advertising this stuff makes a lot of sense
1892016-07-10T03:13:18  <petertodd> for starters, if we screw that up, it's relatively easy to fix :)
1902016-07-10T03:13:18  <sipa> though i think it's not necessarily an urgent issue
1912016-07-10T03:14:00  <sipa> the worst case is that a bad peer can poison your reject cache, preventing you from getting a legitimate transaction before it confirms
1922016-07-10T03:14:00  <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)
1932016-07-10T03:14:11  <petertodd> sipa: it's a good thing no-one relies on zeroconf anymore :P
1942016-07-10T03:14:23  <sipa> i'm sure there are other ways that you can accomplish that
1952016-07-10T03:14:26  *** gribble has quit IRC
1962016-07-10T03:14:33  <sipa> (like inving and not responding to getdata)
1972016-07-10T03:14:37  <gmaxwell> wrt different kinds of relaying later, mostly I thought those improvements would go into mempool sync.
1982016-07-10T03:15:35  <gmaxwell> and rather than wtxid relay,  wtxid,feerate,txid tuples (probably truncated/quantized) may make more sense.
1992016-07-10T03:16:12  <sipa> yeah, for mempool sync we can redesign things cleanyl
2002016-07-10T03:16:27  <petertodd> gmaxwell: note too how schemes like txo commitments allow - and expect - nodes to do significant modifications to txs
2012016-07-10T03:16:30  <gmaxwell> (or even wtxid, feerate, vin id with lowest hash)
2022016-07-10T03:18:08  <gmaxwell> in any case, optimal sync behavior in the presence of double spends (of any kind) isn't a nut I've cracked yet.
2032016-07-10T03:18:10  <sipa> petertodd: yes, the priority should be to make sure no internal inconsistency or banning of unaware nodes occur
2042016-07-10T03:18:27  <gmaxwell> I think I have constructions for schemes which are close to optimal absent doublespends.
2052016-07-10T03:18:42  *** gribble has joined #bitcoin-core-dev
2062016-07-10T03:18:50  <gmaxwell> we already improved relay efficiency a LOT in 0.13, fwiw.
2072016-07-10T03:19:09  <sipa> petertodd: rejectioncache behaviour can either degenerate into attackers preventing you from receiving transactions on the one hand
2082016-07-10T03:19:50  <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)
2092016-07-10T03:21:34  <gmaxwell> there are already several trivially exploited ways where an attacker can massively delay you getting a transaction.
2102016-07-10T03:21:43  <petertodd> sipa: well, again, an attacker can do that DoS attack without segwit by just sending multiple slightly different versions of the same tx
2112016-07-10T03:22:19  <gmaxwell> (e.g. just inv the damn thing from many sockets and don't respond.
2122016-07-10T03:22:20  <gmaxwell> )
2132016-07-10T03:24:15  <sipa> yeah
2142016-07-10T03:30:00  *** frankenmint has quit IRC
2152016-07-10T03:51:13  *** gribble has quit IRC
2162016-07-10T03:52:30  *** spudowiar has quit IRC
2172016-07-10T03:59:06  *** Alopex has quit IRC
2182016-07-10T04:00:11  *** Alopex has joined #bitcoin-core-dev
2192016-07-10T04:03:21  *** moli has quit IRC
2202016-07-10T04:03:42  *** frankenmint has joined #bitcoin-core-dev
2212016-07-10T04:08:39  *** moli has joined #bitcoin-core-dev
2222016-07-10T04:10:01  *** Alopex has quit IRC
2232016-07-10T04:11:06  *** Alopex has joined #bitcoin-core-dev
2242016-07-10T04:14:05  *** frankenmint has quit IRC
2252016-07-10T04:21:00  *** molz has joined #bitcoin-core-dev
2262016-07-10T04:23:43  *** moli has quit IRC
2272016-07-10T04:26:14  *** gribble has joined #bitcoin-core-dev
2282016-07-10T04:41:52  *** cryptapus_ has joined #bitcoin-core-dev
2292016-07-10T04:41:52  *** cryptapus_ has joined #bitcoin-core-dev
2302016-07-10T04:59:41  *** nanotube has quit IRC
2312016-07-10T04:59:41  *** molz has quit IRC
2322016-07-10T04:59:41  *** achow101 has quit IRC
2332016-07-10T04:59:42  *** Justinus has quit IRC
2342016-07-10T04:59:42  *** crudel has quit IRC
2352016-07-10T04:59:42  *** Michail1 has quit IRC
2362016-07-10T04:59:42  *** owowo has quit IRC
2372016-07-10T04:59:42  *** petertodd has quit IRC
2382016-07-10T04:59:43  *** gabridome has quit IRC
2392016-07-10T04:59:43  *** neha has quit IRC
2402016-07-10T04:59:43  *** cjcj has quit IRC
2412016-07-10T04:59:44  *** BCBot has quit IRC
2422016-07-10T04:59:44  *** shaiguit1r has quit IRC
2432016-07-10T04:59:44  *** Taek has quit IRC
2442016-07-10T04:59:45  *** grubles has quit IRC
2452016-07-10T04:59:45  *** bustd_soket has quit IRC
2462016-07-10T04:59:45  *** eenoch has quit IRC
2472016-07-10T04:59:46  *** trippysalmon has quit IRC
2482016-07-10T04:59:46  *** mr_burdell has quit IRC
2492016-07-10T04:59:47  *** haakonn has quit IRC
2502016-07-10T04:59:47  *** so has quit IRC
2512016-07-10T04:59:47  *** gribble has quit IRC
2522016-07-10T04:59:47  *** PatBoy has quit IRC
2532016-07-10T04:59:47  *** JackH has quit IRC
2542016-07-10T04:59:47  *** afk11 has quit IRC
2552016-07-10T04:59:47  *** challisto has quit IRC
2562016-07-10T04:59:47  *** AaronvanW has quit IRC
2572016-07-10T04:59:47  *** Evel-Knievel has quit IRC
2582016-07-10T04:59:47  *** sanada has quit IRC
2592016-07-10T04:59:48  *** roasbeef has quit IRC
2602016-07-10T04:59:48  *** hybridsole has quit IRC
2612016-07-10T04:59:48  *** d9b4bef9 has quit IRC
2622016-07-10T04:59:48  *** Lauda has quit IRC
2632016-07-10T04:59:48  *** pigeons has quit IRC
2642016-07-10T04:59:49  *** adam3us has quit IRC
2652016-07-10T04:59:49  *** PaulCapestany has quit IRC
2662016-07-10T04:59:49  *** pmienk has quit IRC
2672016-07-10T04:59:49  *** [b__b] has quit IRC
2682016-07-10T04:59:49  *** Amnez777 has quit IRC
2692016-07-10T04:59:50  *** hsmiths has quit IRC
2702016-07-10T04:59:50  *** ybit_ has quit IRC
2712016-07-10T04:59:50  *** ClockCat has quit IRC
2722016-07-10T04:59:51  *** sturles has quit IRC
2732016-07-10T04:59:51  *** morcos has quit IRC
2742016-07-10T04:59:51  *** ryan-c has quit IRC
2752016-07-10T04:59:51  *** arubi has quit IRC
2762016-07-10T04:59:52  *** whphhg has quit IRC
2772016-07-10T04:59:52  *** adamg has quit IRC
2782016-07-10T04:59:52  *** Sosumi has quit IRC
2792016-07-10T04:59:52  *** jl2012 has quit IRC
2802016-07-10T04:59:52  *** musalbas has quit IRC
2812016-07-10T04:59:52  *** michagogo has quit IRC
2822016-07-10T04:59:52  *** btcdrak has quit IRC
2832016-07-10T04:59:53  *** windsok_ has quit IRC
2842016-07-10T04:59:53  *** Arnavion has quit IRC
2852016-07-10T04:59:53  *** NicolasDorier has quit IRC
2862016-07-10T04:59:53  *** mturquette has quit IRC
2872016-07-10T04:59:53  *** nsh has quit IRC
2882016-07-10T04:59:53  *** amiller_ has quit IRC
2892016-07-10T04:59:54  *** cfields has quit IRC
2902016-07-10T04:59:54  *** ghtdak has quit IRC
2912016-07-10T04:59:54  *** Madars has quit IRC
2922016-07-10T04:59:55  *** da2ce7_mobile has quit IRC
2932016-07-10T04:59:55  *** jyap has quit IRC
2942016-07-10T04:59:55  *** helo has quit IRC
2952016-07-10T04:59:56  *** asoltys has quit IRC
2962016-07-10T04:59:56  *** jtimon has quit IRC
2972016-07-10T04:59:56  *** slackircbridge has quit IRC
2982016-07-10T04:59:56  *** dgenr8 has quit IRC
2992016-07-10T04:59:56  *** mkarrer has quit IRC
3002016-07-10T04:59:56  *** aureianimus_ has quit IRC
3012016-07-10T04:59:57  *** Cheeseo has quit IRC
3022016-07-10T04:59:57  *** tucenaber has quit IRC
3032016-07-10T04:59:57  *** isis has quit IRC
3042016-07-10T04:59:57  *** mn3monic has quit IRC
3052016-07-10T04:59:57  *** wumpus has quit IRC
3062016-07-10T04:59:58  *** jeremyrubin has quit IRC
3072016-07-10T04:59:58  *** dirtynewshoes has quit IRC
3082016-07-10T04:59:59  *** cryptapus has quit IRC
3092016-07-10T04:59:59  *** Lysanders has quit IRC
3102016-07-10T04:59:59  *** LeMiner has quit IRC
3112016-07-10T04:59:59  *** CyrusV has quit IRC
3122016-07-10T05:00:00  *** bsm117532 has quit IRC
3132016-07-10T05:00:00  *** davec has quit IRC
3142016-07-10T05:00:00  *** face has quit IRC
3152016-07-10T05:00:00  *** OxADADA has quit IRC
3162016-07-10T05:00:01  *** rcd has quit IRC
3172016-07-10T05:00:01  *** midnightmagic has quit IRC
3182016-07-10T05:00:01  *** lclc has quit IRC
3192016-07-10T05:00:01  *** jron has quit IRC
3202016-07-10T05:00:01  *** BonyM has quit IRC
3212016-07-10T05:00:01  *** Squidicuz has quit IRC
3222016-07-10T05:00:03  *** baldur has quit IRC
3232016-07-10T05:00:03  *** berndj has quit IRC
3242016-07-10T05:00:03  *** Anduck has quit IRC
3252016-07-10T05:00:04  *** AtashiCon has quit IRC
3262016-07-10T05:00:05  *** cryptapus_ has quit IRC
3272016-07-10T05:00:05  *** Alopex has quit IRC
3282016-07-10T05:00:06  *** Lightsword has quit IRC
3292016-07-10T05:00:06  *** goregrind has quit IRC
3302016-07-10T05:00:06  *** jonasschnelli has quit IRC
3312016-07-10T05:00:07  *** tadasv has quit IRC
3322016-07-10T05:00:07  *** Expanse has quit IRC
3332016-07-10T05:00:07  *** kinlo has quit IRC
3342016-07-10T05:00:07  *** crescendo has quit IRC
3352016-07-10T05:00:07  *** Cory has quit IRC
3362016-07-10T05:00:07  *** kanzure has quit IRC
3372016-07-10T05:00:07  *** aj_ has quit IRC
3382016-07-10T05:00:07  *** Bootvis has quit IRC
3392016-07-10T05:00:07  *** zxzzt has quit IRC
3402016-07-10T05:00:08  *** CodeShark has quit IRC
3412016-07-10T05:00:08  *** nickler has quit IRC
3422016-07-10T05:00:08  *** limpkin has quit IRC
3432016-07-10T05:00:08  *** zmanian__ has quit IRC
3442016-07-10T05:00:09  *** Eliel_ has quit IRC
3452016-07-10T05:00:09  *** jouke has quit IRC
3462016-07-10T05:00:09  *** blkdb has quit IRC
3472016-07-10T05:00:10  *** kekstone has quit IRC
3482016-07-10T05:00:10  *** Chris_Stewart_5 has quit IRC
3492016-07-10T05:00:10  *** jgarzik has quit IRC
3502016-07-10T05:00:11  *** warren has quit IRC
3512016-07-10T05:00:11  *** foo1 has quit IRC
3522016-07-10T05:00:12  *** gmaxwell has quit IRC
3532016-07-10T05:00:12  *** Naphex has quit IRC
3542016-07-10T05:00:12  *** binns has quit IRC
3552016-07-10T05:00:12  *** murr4y has quit IRC
3562016-07-10T05:00:12  *** devrandom has quit IRC
3572016-07-10T05:00:13  *** gijensen_ has quit IRC
3582016-07-10T05:00:13  *** da2ce7 has quit IRC
3592016-07-10T07:39:42  *** kadoban has quit IRC
3602016-07-10T08:53:49  *** da2ce7 has joined #bitcoin-core-dev
3612016-07-10T08:53:49  *** gijensen_ has joined #bitcoin-core-dev
3622016-07-10T08:53:49  *** dirtynewshoes has joined #bitcoin-core-dev
3632016-07-10T08:53:49  *** devrandom has joined #bitcoin-core-dev
3642016-07-10T08:53:49  *** murr4y has joined #bitcoin-core-dev
3652016-07-10T08:53:49  *** asoltys has joined #bitcoin-core-dev
3662016-07-10T08:53:49  *** helo has joined #bitcoin-core-dev
3672016-07-10T08:53:49  *** jyap has joined #bitcoin-core-dev
3682016-07-10T08:53:49  *** blkdb has joined #bitcoin-core-dev
3692016-07-10T08:53:49  *** da2ce7_mobile has joined #bitcoin-core-dev
3702016-07-10T08:53:49  *** jeremyrubin has joined #bitcoin-core-dev
3712016-07-10T08:53:49  *** binns has joined #bitcoin-core-dev
3722016-07-10T08:53:49  *** wumpus has joined #bitcoin-core-dev
3732016-07-10T08:53:49  *** Squidicuz has joined #bitcoin-core-dev
3742016-07-10T08:53:49  *** so has joined #bitcoin-core-dev
3752016-07-10T08:53:49  *** haakonn has joined #bitcoin-core-dev
3762016-07-10T08:53:49  *** mr_burdell has joined #bitcoin-core-dev
3772016-07-10T08:53:49  *** adam3us has joined #bitcoin-core-dev
3782016-07-10T08:53:49  *** Naphex has joined #bitcoin-core-dev
3792016-07-10T08:53:49  *** pigeons has joined #bitcoin-core-dev
3802016-07-10T08:53:49  *** mn3monic has joined #bitcoin-core-dev
3812016-07-10T08:53:49  *** BonyM has joined #bitcoin-core-dev
3822016-07-10T08:53:49  *** jouke has joined #bitcoin-core-dev
3832016-07-10T08:53:49  *** Eliel_ has joined #bitcoin-core-dev
3842016-07-10T08:53:49  *** Madars has joined #bitcoin-core-dev
3852016-07-10T08:53:49  *** ghtdak has joined #bitcoin-core-dev
3862016-07-10T08:53:49  *** isis has joined #bitcoin-core-dev
3872016-07-10T08:53:49  *** Lauda has joined #bitcoin-core-dev
3882016-07-10T08:53:49  *** jron has joined #bitcoin-core-dev
3892016-07-10T08:53:49  *** cfields has joined #bitcoin-core-dev
3902016-07-10T08:53:49  *** zmanian__ has joined #bitcoin-core-dev
3912016-07-10T08:53:49  *** limpkin has joined #bitcoin-core-dev
3922016-07-10T08:53:49  *** d9b4bef9 has joined #bitcoin-core-dev
3932016-07-10T08:53:49  *** nickler has joined #bitcoin-core-dev
3942016-07-10T08:53:49  *** CodeShark has joined #bitcoin-core-dev
3952016-07-10T08:53:49  *** gmaxwell has joined #bitcoin-core-dev
3962016-07-10T08:53:49  *** amiller_ has joined #bitcoin-core-dev
3972016-07-10T08:53:49  *** lclc has joined #bitcoin-core-dev
3982016-07-10T08:53:49  *** nsh has joined #bitcoin-core-dev
3992016-07-10T08:53:49  *** mturquette has joined #bitcoin-core-dev
4002016-07-10T08:53:49  *** ryan-c has joined #bitcoin-core-dev
4012016-07-10T08:53:49  *** tucenaber has joined #bitcoin-core-dev
4022016-07-10T08:53:49  *** AtashiCon has joined #bitcoin-core-dev
4032016-07-10T08:53:49  *** NicolasDorier has joined #bitcoin-core-dev
4042016-07-10T08:53:49  *** zxzzt has joined #bitcoin-core-dev
4052016-07-10T08:53:49  *** morcos has joined #bitcoin-core-dev
4062016-07-10T08:53:49  *** morgan.freenode.net sets mode: +o wumpus
4072016-07-10T08:53:49  *** midnightmagic has joined #bitcoin-core-dev
4082016-07-10T08:53:49  *** berndj has joined #bitcoin-core-dev
4092016-07-10T08:53:49  *** hybridsole has joined #bitcoin-core-dev
4102016-07-10T08:53:49  *** roasbeef has joined #bitcoin-core-dev
4112016-07-10T08:53:49  *** aj_ has joined #bitcoin-core-dev
4122016-07-10T08:53:49  *** sturles has joined #bitcoin-core-dev
4132016-07-10T08:53:49  *** Arnavion has joined #bitcoin-core-dev
4142016-07-10T08:53:49  *** Bootvis has joined #bitcoin-core-dev
4152016-07-10T08:53:49  *** kanzure has joined #bitcoin-core-dev
4162016-07-10T08:53:49  *** BCBot has joined #bitcoin-core-dev
4172016-07-10T08:53:49  *** Taek has joined #bitcoin-core-dev
4182016-07-10T08:53:49  *** ClockCat has joined #bitcoin-core-dev
4192016-07-10T08:53:49  *** windsok_ has joined #bitcoin-core-dev
4202016-07-10T08:53:49  *** Cory has joined #bitcoin-core-dev
4212016-07-10T08:53:49  *** crescendo has joined #bitcoin-core-dev
4222016-07-10T08:53:49  *** kinlo has joined #bitcoin-core-dev
4232016-07-10T08:53:49  *** Expanse has joined #bitcoin-core-dev
4242016-07-10T08:53:49  *** ybit_ has joined #bitcoin-core-dev
4252016-07-10T08:53:49  *** OxADADA has joined #bitcoin-core-dev
4262016-07-10T08:53:49  *** trippysalmon has joined #bitcoin-core-dev
4272016-07-10T08:53:49  *** baldur has joined #bitcoin-core-dev
4282016-07-10T08:53:49  *** tadasv has joined #bitcoin-core-dev
4292016-07-10T08:53:49  *** foo1 has joined #bitcoin-core-dev
4302016-07-10T08:53:49  *** btcdrak has joined #bitcoin-core-dev
4312016-07-10T08:53:49  *** michagogo has joined #bitcoin-core-dev
4322016-07-10T08:53:49  *** musalbas has joined #bitcoin-core-dev
4332016-07-10T08:53:49  *** jl2012 has joined #bitcoin-core-dev
4342016-07-10T08:53:49  *** Sosumi has joined #bitcoin-core-dev
4352016-07-10T08:53:49  *** CyrusV has joined #bitcoin-core-dev
4362016-07-10T08:53:49  *** Cheeseo has joined #bitcoin-core-dev
4372016-07-10T08:53:49  *** jonasschnelli has joined #bitcoin-core-dev
4382016-07-10T08:53:49  *** goregrind has joined #bitcoin-core-dev
4392016-07-10T08:53:49  *** hsmiths has joined #bitcoin-core-dev
4402016-07-10T08:53:49  *** warren has joined #bitcoin-core-dev
4412016-07-10T08:53:49  *** Lightsword has joined #bitcoin-core-dev
4422016-07-10T08:53:49  *** LeMiner has joined #bitcoin-core-dev
4432016-07-10T08:53:49  *** Lysanders has joined #bitcoin-core-dev
4442016-07-10T08:53:49  *** shaiguit1r has joined #bitcoin-core-dev
4452016-07-10T08:53:49  *** aureianimus_ has joined #bitcoin-core-dev
4462016-07-10T08:53:49  *** cjcj has joined #bitcoin-core-dev
4472016-07-10T08:53:49  *** mkarrer has joined #bitcoin-core-dev
4482016-07-10T08:53:49  *** rcd has joined #bitcoin-core-dev
4492016-07-10T08:53:49  *** face has joined #bitcoin-core-dev
4502016-07-10T08:53:49  *** sanada has joined #bitcoin-core-dev
4512016-07-10T08:53:49  *** eenoch has joined #bitcoin-core-dev
4522016-07-10T08:53:49  *** bustd_soket has joined #bitcoin-core-dev
4532016-07-10T08:53:49  *** davec has joined #bitcoin-core-dev
4542016-07-10T08:53:49  *** Amnez777 has joined #bitcoin-core-dev
4552016-07-10T08:53:49  *** whphhg has joined #bitcoin-core-dev
4562016-07-10T08:53:49  *** Evel-Knievel has joined #bitcoin-core-dev
4572016-07-10T08:53:49  *** [b__b] has joined #bitcoin-core-dev
4582016-07-10T08:53:49  *** pmienk has joined #bitcoin-core-dev
4592016-07-10T08:53:49  *** grubles has joined #bitcoin-core-dev
4602016-07-10T08:53:49  *** Anduck has joined #bitcoin-core-dev
4612016-07-10T08:53:49  *** cryptapus has joined #bitcoin-core-dev
4622016-07-10T08:53:49  *** AaronvanW has joined #bitcoin-core-dev
4632016-07-10T08:53:49  *** bsm117532 has joined #bitcoin-core-dev
4642016-07-10T08:53:49  *** challisto has joined #bitcoin-core-dev
4652016-07-10T08:53:49  *** PaulCapestany has joined #bitcoin-core-dev
4662016-07-10T08:53:49  *** afk11 has joined #bitcoin-core-dev
4672016-07-10T08:53:49  *** JackH has joined #bitcoin-core-dev
4682016-07-10T08:53:49  *** dgenr8 has joined #bitcoin-core-dev
4692016-07-10T08:53:49  *** PatBoy has joined #bitcoin-core-dev
4702016-07-10T08:53:49  *** jgarzik has joined #bitcoin-core-dev
4712016-07-10T08:53:49  *** slackircbridge has joined #bitcoin-core-dev
4722016-07-10T08:53:49  *** jtimon has joined #bitcoin-core-dev
4732016-07-10T08:53:49  *** kekstone has joined #bitcoin-core-dev
4742016-07-10T08:53:49  *** gribble has joined #bitcoin-core-dev
4752016-07-10T08:53:49  *** Michail1 has joined #bitcoin-core-dev
4762016-07-10T08:53:49  *** adamg has joined #bitcoin-core-dev
4772016-07-10T08:53:49  *** arubi has joined #bitcoin-core-dev
4782016-07-10T08:53:49  *** Alopex has joined #bitcoin-core-dev
4792016-07-10T08:54:13  *** nanotube has joined #bitcoin-core-dev
4802016-07-10T08:54:14  *** molz has joined #bitcoin-core-dev
4812016-07-10T08:54:14  *** achow101 has joined #bitcoin-core-dev
4822016-07-10T08:54:14  *** Justinus has joined #bitcoin-core-dev
4832016-07-10T08:54:14  *** crudel has joined #bitcoin-core-dev
4842016-07-10T08:54:14  *** owowo has joined #bitcoin-core-dev
4852016-07-10T08:54:14  *** petertodd has joined #bitcoin-core-dev
4862016-07-10T08:54:14  *** gabridome has joined #bitcoin-core-dev
4872016-07-10T08:54:14  *** neha has joined #bitcoin-core-dev
4882016-07-10T08:59:31  *** Alopex has quit IRC
4892016-07-10T09:00:37  *** Alopex has joined #bitcoin-core-dev
4902016-07-10T10:00:30  *** MarcoFalke has joined #bitcoin-core-dev
4912016-07-10T10:19:39  *** Ylbam has joined #bitcoin-core-dev
4922016-07-10T11:22:01  *** Guyver2 has joined #bitcoin-core-dev
4932016-07-10T11:30:42  *** YOU-JI has joined #bitcoin-core-dev
4942016-07-10T11:31:58  *** belcher has joined #bitcoin-core-dev
4952016-07-10T12:55:19  *** laurentmt has joined #bitcoin-core-dev
4962016-07-10T12:56:59  *** YOU-JI has quit IRC
4972016-07-10T13:08:34  *** paveljanik has joined #bitcoin-core-dev
4982016-07-10T13:34:47  *** YOU-JI has joined #bitcoin-core-dev
4992016-07-10T13:45:57  *** instagibbs has joined #bitcoin-core-dev
5002016-07-10T13:59:14  *** MarcoFalke has quit IRC
5012016-07-10T14:09:59  *** laurentmt has quit IRC
5022016-07-10T14:23:46  *** Guyver2 has quit IRC
5032016-07-10T14:24:00  *** YOU-JI has quit IRC
5042016-07-10T14:45:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5052016-07-10T14:46:13  *** shesek has joined #bitcoin-core-dev
5062016-07-10T14:47:43  *** arubi has quit IRC
5072016-07-10T15:00:23  *** mkarrer has quit IRC
5082016-07-10T15:24:29  *** musalbas has left #bitcoin-core-dev
5092016-07-10T15:30:26  *** musalbas has joined #bitcoin-core-dev
5102016-07-10T15:45:51  *** arubi has joined #bitcoin-core-dev
5112016-07-10T16:01:42  *** ClockCat has quit IRC
5122016-07-10T16:42:29  *** MarcoFalke has joined #bitcoin-core-dev
5132016-07-10T17:07:02  *** Amnez777 has quit IRC
5142016-07-10T17:17:28  *** spudowiar has joined #bitcoin-core-dev
5152016-07-10T17:18:22  *** Amnez777 has joined #bitcoin-core-dev
5162016-07-10T17:24:32  *** moli has joined #bitcoin-core-dev
5172016-07-10T17:25:11  *** molz has quit IRC
5182016-07-10T17:47:53  *** spudowiar has quit IRC
5192016-07-10T18:00:51  *** moli has quit IRC
5202016-07-10T18:02:00  *** moli has joined #bitcoin-core-dev
5212016-07-10T18:15:28  *** Amnez777 has quit IRC
5222016-07-10T18:23:28  *** molz has joined #bitcoin-core-dev
5232016-07-10T18:23:34  *** moli has quit IRC
5242016-07-10T18:28:06  *** Amnez777 has joined #bitcoin-core-dev
5252016-07-10T19:19:18  *** face has quit IRC
5262016-07-10T19:19:30  *** Guyver2 has joined #bitcoin-core-dev
5272016-07-10T19:56:34  *** moli has joined #bitcoin-core-dev
5282016-07-10T19:58:24  *** molz has quit IRC
5292016-07-10T20:21:57  *** moli has quit IRC
5302016-07-10T20:22:21  *** spudowiar has joined #bitcoin-core-dev
5312016-07-10T20:24:10  *** moli has joined #bitcoin-core-dev
5322016-07-10T20:30:58  *** Chris_Stewart_5 has quit IRC
5332016-07-10T20:34:21  *** oddishh has joined #bitcoin-core-dev
5342016-07-10T20:34:23  <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!
5352016-07-10T20:35:10  *** ChanServ sets mode: +o btcdrak
5362016-07-10T20:35:22  *** btcdrak sets mode: +b *!~oddish@static-71-162-202-13.phlapa.fios.verizon.net
5372016-07-10T20:35:33  *** btcdrak sets mode: -o btcdrak
5382016-07-10T20:42:06  *** kadoban has joined #bitcoin-core-dev
5392016-07-10T20:53:12  *** oddishh has left #bitcoin-core-dev
5402016-07-10T20:55:18  *** Guyver2 has quit IRC
5412016-07-10T21:15:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5422016-07-10T21:18:23  *** harrymm has joined #bitcoin-core-dev
5432016-07-10T21:19:31  *** spudowiar has quit IRC
5442016-07-10T21:19:52  *** spudowiar has joined #bitcoin-core-dev
5452016-07-10T21:25:41  *** molz has joined #bitcoin-core-dev
5462016-07-10T21:27:47  *** moli has quit IRC
5472016-07-10T21:29:03  *** Chris_Stewart_5 has quit IRC
5482016-07-10T21:43:20  *** belcher has quit IRC
5492016-07-10T22:04:15  *** belcher has joined #bitcoin-core-dev
5502016-07-10T22:07:21  *** afk11 has quit IRC
5512016-07-10T22:13:49  *** afk11 has joined #bitcoin-core-dev
5522016-07-10T22:13:49  *** afk11 has quit IRC
5532016-07-10T22:13:49  *** afk11 has joined #bitcoin-core-dev
5542016-07-10T22:27:19  *** spudowiar is now known as noslen
5552016-07-10T22:27:36  *** noslen is now known as spudowiar
5562016-07-10T22:51:11  *** achow101 has quit IRC
5572016-07-10T22:56:25  *** spudowiar is now known as sleepytime
5582016-07-10T22:56:37  *** sleepytime is now known as spudowiat
5592016-07-10T22:56:39  *** spudowiat is now known as spudowiar
5602016-07-10T23:00:09  *** whphhg has quit IRC
5612016-07-10T23:01:06  *** whphhg has joined #bitcoin-core-dev
5622016-07-10T23:03:57  *** achow101 has joined #bitcoin-core-dev
5632016-07-10T23:27:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5642016-07-10T23:37:38  *** jtimon has quit IRC
5652016-07-10T23:41:52  <grubles> 1/3
5662016-07-10T23:41:59  <grubles> oops. sorry.
5672016-07-10T23:42:05  <sipa> 0.33333333
5682016-07-10T23:42:35  <grubles> :)
5692016-07-10T23:48:50  *** spudowiar has quit IRC