Bitcoin Forum
October 18, 2018, 03:09:48 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 [56] 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 238 »
1101  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 23, 2015, 03:40:58 PM
The risk of having a centralized core team for bitcoin against
This is a false dichotomy.  Bitcoin Core is free / open source software. It isn't owned by anyone. Anyone is free to make their own modifications, run arbitrary versions of their own choosing from arbitrary sources, and people do. Even within one project the participants don't report to any authority except themselves.  Your argument actually cuts the other way when more diversity spreads thinner the review resources required to ensure that any implementation does what its users (or even its authors) thinks it does.

I think Hhanh00 comment about burden is weird; I am stuck reviewing redundant code in several language which I am not qualified to review in, and dealing with unfamiliar codebases because I have to cope with the mitigating interoperability risk created by other implementations. Node diversity is an significant cost to anyone working on the Bitcoin system who is not punting on dealing with the risk of the whole thing faulting. I am probably losing about 20% of my review time due to alternative implementations already, we have protocol enhancements hung up on concern that they'll just simply be rejected by other implementations (some of which are not very actively maintained relative to Bitcoin Core), etc.: It's a big enough task that people struggle to get things working, keeping up and working with the community is seemingly too much to ask for some. This isn't a cost we complain about-- it's a necessary consequence of an open system that people can (and inevitably will) do some of this--, but it very much is one. (This also holds for wallets and other tools, not just full nodes: I am not a developer of Bitcoin Core. I am a developer for the Bitcoin system as a whole, Bitcoin core just-- in my view-- is one of the most leveraged places to do work to benefit the Bitcoin system today.  That said, I have found and reported critical security vulnerabilities and design flaws in many wallets, services, and underlying infrastructure, sometimes fixing them by changes to the Bitcoin system when doing so appeared to be the best approach. These things are true for many of the other people who work on Bitcoin Core: We generally tend to take our share of the responsibility for the system as a whole, not exclusively the parts of it we work on most directly; as I've pointed out before: your own software being correct but not agreeing with other people is no great success in this space. Increasing ecosystem software diversity does not reduce the burden, beyond the point that it's best if no one program is asked to accommodate all possible needs.)
1102  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core soft-fork proposal for strict DER enforcing on: January 23, 2015, 02:40:13 PM
Am I just too paranoid?
Yes. Due to malleability invalid scriptSig are re-encodable as valid for any plausible signature type. This was explicitly considered and it's why BIP62 didn't impose changes on pubkey encoding requirements (e.g. requiring pubkeys be valid, or compressed), since whatever scriptPubKeys there are are set in stone. Height restricting strictder would completely undermine the motivation of the change, since consensus could be broken by anything spending an old coin.

One case that isn't covered is if you authored a chain of private-key-destroyed timelocked transactions using invalid encodings. You can fix-up the signature in the first transaction, but doing so changes its txid and thus invalidates its dependents.  Of course, if you did this you were already likely to get burned even absent any further change: anyone in the network could mutate your transaction (and with the invalid encoding, all the network would already ignore it and take the mutant instead) and invalidate the child equally well. There already appear to be some parties that mutate any invalid encodings they observe to valid ones.

In general, I think long term timelocks like this are suicidally ill advised... but indeed, I do consider it important to not soft-fork out the ability to spend old coins, even those of people who've done generally ill-advised things. Though changes have been made in the past which invalidated previously spendable scriptPubKeys, e.g. OP_RETURN being made invalid closed off some perfectly reasonable scriptPubKeys.

Provided that an agreement was already reached on BIP 62, I see no problem doing the required soft fork at the same time (except for the additional coding and testing involved).  Support for non-malleable transactions in clients can be added later when the network supports them.
Several of people who've been working on BIP 62 feel that its not mature enough yet for rapid deployment, as it is somewhat complicated and we've still found ourselves somewhat recently uncovering more interactions that were somewhat surprising. The strictder part of it is mature and hasn't been yielding any surprises and with that in place we can simplify BIP62 some, which will help get BIP62 deployed. It's still in progress and isn't being abandoned in the slightest.

I mean "winning" hard-fork of course. The majority does not need dead hard-forks.
You may misunderstand Bitcoin. If you are mining in violation of the network rules (e.g. on a hard fork) you are no longer mining as far as the nodes that disagree with you are concerned. 100% of the hashpower visible to a network is always in agreement with the hard fork rules.

Can't really claim to understand this fully so might be off the mark entirely.
Does this mean SSL is here to stay? I thought there where plans to move away from it and maybe even implement an alternative. Being unable to move away from SSL would be my only concern, otherwise sounds like a good move imho, +0.000001 Smiley
SSL is used nowhere in the Bitcoin protocol. We do use the OpenSSL library to get access to some cryptographic functions and would eventually like to not do so, this change is a necessary step to make along that path. (e.g. if anything, the opposite of your fear).

DER should be removed it makes no sense for Bitcoin since Bitcoin has already defined the lengths and encodings of everything in its protocol.
Once you realize what DER actually is and what it does in the block its ridiculous.
Can't be removed without totally breaking incompatibility, making people's coins unspendable, etc. It's also more or less harmless at least once most of the possible complexity is removed by enforcing strict encoding, it just adds a couple bytes of overhead. Any future CHECKSIG alternatives obviously wouldn't use it; but there are still all the already existing coins left to deal with.
1103  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core soft-fork proposal for strict DER enforcing on: January 21, 2015, 08:32:59 PM
Is there any cons worth discussing ? I only see the pros.
I believe all the cons we could uncover were hashed out in pre-proposal adjustments; so whats left is any unknowns people discover and just the general cost of doing something at all (which has to be weighed against the rather considerable and clear known costs/risks of doing nothing).
1104  Bitcoin / Development & Technical Discussion / Bitcoin Core soft-fork proposal for strict DER enforcing on: January 21, 2015, 06:17:56 PM

Greetings, as suggested in the post about the recent OpenSSL incompatibility there is a proposal for strictly enforcing DER encoding for signatures as a block validity rule:

Bitcoin Core has enforced this restriction for relay/mempool/mining since 0.8 in preparation for eventually making a change like this.

I know its kind of a boring change and boring changes tend to not gather a lot of comments; but it's still important so I'd greatly appreciate it if people would review and comment even if the comment is just "I read this, makes sense, no further comments.".  Ideally you'd comment on bitcoin-development directly, but if you comment here instead I can relay views (you take my editorial judgements at your own risk: best to comment directly).
1105  Bitcoin / Development & Technical Discussion / Re: ECDSA 2 of 2 signing on: January 20, 2015, 01:47:55 AM
my 0.01 BTC
Might want to consider putting those views on sale, because that price is a little high.

If you take a moment to search you'll see that sort of thing has been discussed before. Not only does it need a trusted setup, but it needs a single trusted point while signing.  It's not completely worthless to split up a key only while stored, but does defeat most of the point, since it basically removes all immunity to malicious hardware or malicious participants.

As far as secret sharing schemes: If constructed right (e.g. using truly random inputs) the scheme has trivially provable information theoretic security (basically if you have threshold - 1 shares, any possible key output can be reached by some possible missing share input). So there is no realistic possibility of "any not know vulnerability"; but a particular implementation could easily be defective in some way-- so you should cite correctly implemented not the sharing itself;  ... really, the greater risk there is thinking that it does something useful for you at all, since due to the aforementioned issues: it likely doesn't.
1106  Bitcoin / Development & Technical Discussion / Re: ECDSA Signatures allow recovery of the public key on: January 19, 2015, 03:05:31 PM
Please don't bump old threads, especially not to propose something new. You can always link to the old thread in a new post.

I would strongly recommend against it. If Bitcoin were to deploy a new signature system we'd likely prefer schnorr signatures to pick up efficient multisignature; there are other approaches which much more size reduction (E.g. BLS pairing signatures are half the size); and there are other considerations.
1107  Bitcoin / Development & Technical Discussion / Re: Is provoking a fork on purpose a good thing ? on: January 17, 2015, 11:07:45 PM
Potential forking conditions need to be handled in a coordinated manner in order to avoid opening people to loss.  In the past we've found forking conditions and managed them in a coordinated manner through e.g. fixes that prevent the discrepancy from ever showing up in the blockchain.  Any trigger of a fork _immediately_ allows it to be opportunistically used by thieves, who don't need to understand why the network has forked in order to find parties on other sides of it and rob them; and don't need to have done anything special before the fork showed up. Doing so is exactly the opposite of protective. Not specific to now, but as a general bit of advice, it may well be that anything you think you've found is not actually a real issue or is already known and already in the process of a coordinated resolution which such an attack would disrupt.

By intentionally triggering an inconsistency in network state you would be exposing yourself to civil litigation by any party harmed by the foreseeable outcomes of your attack the network/it's participating systems.  I would strongly recommend against it.

Instead I would recommend that you responsibly report any discoveries to the security contact on or the specific authors/maintainers of the Bitcoin application you believe to be most proximately at fault.
1108  Bitcoin / Development & Technical Discussion / Re: secp256k1 as a library on Windows on: January 16, 2015, 02:56:42 PM
You should probably not be using the library right now, especially not if you're having problems using what is a very basic C library.  It is preproduction experimental software, as it says so quite explicitly on the website.

I probably will never stop being horrified at people's capacity for rushing head long into using software that even its authors tell them not to use. It makes it much harder to work in the open, because you now have to worry about what harm inadequately tested software is causing people (and their users) who ignore warnings.
1109  Bitcoin / Development & Technical Discussion / Re: script on: January 15, 2015, 04:12:23 AM
That checkmultisig reads an extra element could be used in the future to make batch validation faster (as it needs some additional side information), or for other extensions.  It's commonly assumed to be a bug that it reads an extra item but might have just as well been another forward compatibility mechanism, or a left over behavior from an earlier approach.
1110  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 15, 2015, 02:03:51 AM
We can't just cherry pick what to apply our arguments to.  The entire argument here is entirely based around the probability
I'd like to invite you to point out any place where I argued anything about probability, except to rebut your reliance on that argument. Bitcoin is an experimental system, and in some regards it is pushing the envelope about the kinds of systems we know how to engineer and is doing so under considerable resource restrictions.
1111  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 15, 2015, 01:18:49 AM
To me, what it really comes down to is probabilities.  The popular assumption is that Bitcoin Core has an extremely low probability that it will fork against itself.  So, let's go with that premise and say that the probability of Bitcoin Core forking against itself is something like 1 in a 100 trillion (1e14).
Probabilities are not an effective model to reason about bugs in an adversarial environment. (Even in conventional reliability engineering-- without invoking an adversary-- you must first separate systematic failure from random failure in order to reason about failure distributions.)

"If you have a website with a billion pixels and due to a bug clicking one gives the reader one of your bitcoins, and you have one visitor an hour and a normal visitor clicks on 100 pixels, how long until you've lost 100 bitcoins?"  .... This doesn't make sense, and thinking about consensus bugs in this manner doesn't make sense. Existing consensus bugs we've seen triggered against implementation were 10^-100 scale events if your model is random monkies pounding on keyboards to produce transactions.

Virtually all the errors we care about are not random failures, and to the extent that there is an element of randomness an attacker can behave adaptively to bring out the otherwise 'rare' behavior that is harmful to your interests.

the consensus tests need to be improved
Thats always true, the tests are woefully inadequate and would continue to be even if they were terrabytes in size. That said, improving them has high value. I'm looking forward to contributions on that front. Probably one of the really important things an alternative implementation can do for the ecosystem is produce new tests as a side effect of their own independent efforts to obtain agreement. (Though, sadly, there seems to have been at least some level of people keeping at least implementation errors private in order to use them for marketing purposes... with all the different ways to monetize a security flaw other than reporting it, we cannot really count on reports.)

But thinking that passing a prefab test suite that someone else wrote alone is sufficient-- which is certainly the impression given there-- sounds like magical thinking. It's not sufficient, merely necessary, and one shouldn't rely on it alone. (If this wasn't the message you were intending to convey, it wasn't clear to me.)  Anyone can grind at some tests until they pass but doing, sadly, reduces the predictive power of the tests for errors not present in the tests. (This is partially why I prefer the block tests in Bitcoin runs in CI rather than being used locally by developers; we get a concrete measurement of detectable consensus bugs which are introduced by a change.)  Yes, by some definition the tests are inadequate if there is a failure in spite of passing; but they're always going to be inadequate because they cannot be sound, at least not by themselves. (A test coupled with a formal analysis that showed it met some definition of completeness would be interesting.)

There should be a formal specification,
Philosophically there should be, but in terms of benefit to the world the value is quite possibly negative. A non-executable or not widely used specification is a dead letter. The behavior of the participants defines the system.  You can point blame all day this way that when some reading of the specification disagrees with some other reading; but its little comfort when all the funds are gone.  As a pedagogical artifact a good specification may be highly useful; but it can also cause harm by feeding deep misunderstandings like having software which you believe-does (instead of actually-does) what you believe the specification says (rather than what everyone else actually-does, regardless of what they believe the specification says) is an acceptable situation to be in. "But I followed the spec!" "Too bad, all your coins have been double spent away because you ended up on a different chain from the other participants."  Compared to other efforts to improve system integrity I think specification work beyond what exists now has fairly low returns.  (Doubly so because existing alternative implementers have frequently made mistakes in parts of the system that are clearly specified and have tests in the normal tests suites.).   In Bitcoin the behavior of the system is all there is. You have no other recourse, no higher authority.   Being surprised or unhappy with at the Bitcoin network for disagreeing with a ream of paper is, in some ways, like being mad at the universe for not being completely defined by Einsteins' description of general relativity.  Like the universe, the Bitcoin network doesn't give a darn about political gamesmanship. It does what it does, not what you think it should do. To the extent that people want to work on specification work, especially if it was specification work that clearly enough defined to permit formal reasoning, it's work I would support-- in spite of my reservations about potential net-negative value from it.
1112  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 14, 2015, 11:10:26 PM
Is there somewhere I can read about the kinds of corner cases that were discovered and how they were dealt with?
They're sort of scattered in various places, for example:

Also, what would it take to produce a formally verifiable implementation of bitcoin? Is such a thing even possible? Can we expect a PhD thesis to deliver the matter in the next decade?
One question with formal verification is what are you formally verifying?  If the question is the most important question in consensus "is this function equivalent to that function for all inputs" there is one very easy to have a strong guarantee that the answer is true: make them be exactly the same function.  Formally proving two functions written in different languages compute the same thing is much harder, and likely not practically possible if the languages are very different or the algorithms used internally substantially different.

To formally verify other properties we first need to extract the part that needs to be verified into it's smallest self contained realization. You can look at whats been done with SEL4 to see whats currently possible (and how much work it takes for a rather small program) at the state of the art.

In Bitcoin core we're working on the isolation which is an important first step on both with the "use the exact same code for the consensus critical parts" approach as well as the "formally show some code achieves certain properties". I suspect that on the latter we won't make much progress in the near term outside of some parts in the underling cryptographic code unless some researchers pick it up as an area of study, but we should hopefully be well positioned to take advantage of formal analysis tools as that space matures.
1113  Bitcoin / Development & Technical Discussion / Re: bitcoinqt doesn't add transaction fee even if it is set in Settings? on: January 14, 2015, 09:15:07 PM
Not enough info provided. I don't believe that there is any way for it to create a transaction with a fee per KB less than you've specified.
1114  Bitcoin / Mining speculation / Re: Jan 12th to Approx Jan 27th diff thread (3.5%) on: January 14, 2015, 06:18:39 PM
FWIW, for the record I removed a wall of offtopic posts by seriouscoin which were some of the more vile posts I've run across on the mining subforums.
1115  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.9.3 drops incoming connections only - Windows on: January 14, 2015, 06:00:28 PM
AFAIK this has been discussed on github and no one is working on a solution.
Not so.

If this is what it appears to be, that Bitcoin never learns the new IP after it changes:
It's more or less solved, or at least more or less as much as it's ever likely to be, by the new discovery procedure in 0.10.

Of course, if your IP is changing you're somewhat less useful to the network because it takes time for other nodes to discover your IP before they can reach you.

If UPNP is in use somewhat more could be done, but the result still would take a while to get back many connections.
1116  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 14, 2015, 07:59:03 AM
including Bitcoin Core.
There has at least not been a new version so far which introduce an incompatibility, that we know of (frequently repeated _incorrect_ claims otherwise aside.). It wouldn't be the most shocking thing; but enormous effort goes into preventing it.

So I was thinking about looking at another guy who faced the same problem to see where the road ends and whether it's worth going the extra few miles.
BlueMatt wrote a pretty extensive agreement testing framework and discovered several corner cases that were not previously known. He's generally of the opinion that achieving a correct reimplementation is more or less intractable. His approach made progress, especially in unearthing weird behaviours, but doesn't result in great confidence of soundness; and doesn't show an implementation free of its own buts not related to non-obvious behavior in Bitcoin Core.  Our strategy in Bitcoin Core as of late has been toward compartmentalizing and simplifying in order to make code reuse more reasonable; and also get things structured to be more agreeable to approaches that would possibly make formal analysis more realistic, but thats a long term effort.
1117  Bitcoin / Development & Technical Discussion / Re: Is there any full node implementation 100% compatible with the core client? on: January 13, 2015, 09:54:23 PM
I would bet any amount of money that none of the complete reimplementation that I am aware of are consensus consistent.

If you're doing something for educational purposes, then obviously the stakes are less severe. If the prospect of inventing novel ways to assure consistency excites you, then you should do so enlighten the world... but if it doesn't, why are you implementing a Bitcoin full node?  Effectively, achieving consistency _is_ the tasks, if you don't enjoy that tasks you'd probably be better of finding a project to work on that where you do enjoy the work of it.
1118  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: January 13, 2015, 12:10:56 AM
I am completely shocked that you of all people are making this claim gmaxwell. Reusing a K value is against the DSA signing algorithm's specifications. Reusing a K value is an incompetent implementation by definition. There have been multiple instances where BTC were lost because bitcoin client software reused the same K value for different signatures on the same address. If you do so you're guaranteed to find that address emptied fairly quickly, based on past instances it seems there there network monitors actively watching for this exact situation.
Maybe when you find yourself shocked you should take that as a signal that perhaps you misunderstood and should read again.

"is an incompetent implementation by definition" Exactly. And if you are using an incompetent implementation you are in extreme peril no matter how many layers of cargo-cult buzzword security theatre it's author has dressed it up in.

Insecure nonce generation isn't something that happens by chance-- not for the size of the numbers involved here, it is not some random fault, not some cosmic ray event. (Okay, sure, anything can happen, but that isn't whats has actually happened).  The faults you're talking about are real but they are exclusively the result of dangerously incompetent software which would not (and in some cases did not) pass even the most straight forward review, if it were ever reviewed at all.  In most (though not quite all) cases _same_ software would still be insecure, even using derandomized DSA, because it also use the same faulty procedures to generate the private keys; which have just as strong of a requirement for randomness but have no way around it.

AFAIK, I was the first or at least one of the first persons to suggest that implementations in this space probably ought to be using derandomization, e.g. (and many times previously on IRC and directly to implementers). I went and nagged several of the early hardware wallet vendors to go change their approach, etc.

because bitcoin client software
What you should say is dangerous, incompetent software, which likely would have (or actually did) lost the users funds in several different other ways as well.

The question I was responding to, if you can find the context in this huge thread, was on the relative priority of sidechannel resistance and derandomization in Bitcoin Core. The person I was responding to thought sidechannel attack resistance was unimportant and that randomization was important (or at least more important). I responded that relatively speaking I consider sidechannel resistance more important there: the signature randomness story isn't not a disaster in Bitcoin core, and if it were the private key generation would be just as broken or worse. This isn't the same for all applications, in some applications it matters more than others. And derandomization is prudent just out of principle, so we use it for Bitcoin Core... but comparatively speaking, given the above considerations of the two I don't consider it the more important one.
1119  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: January 12, 2015, 09:42:49 PM
I think deterministic signatures are much more important than constant-time signatures (there's been a non-trivial amount of funds lost due to the repeat k-value problem but I doubt a single satoshi has ever been lost due to a genuine side-channel attack).  Someone like gmaxwell could comment better on the practical risks here…
There never has been a single 1e-8 btc lost due to reused/bad K ... in a competent implementation. The places we've seen lossage have been implementations which were horrific in other ways as well (like only having 32..48 bits of randomness total)... ultimately, if you can't generate strong random numbers you're going to be utterly screwed in any case, because your private keys themselves will be predictable. It's more important for embedded/hardware implementations which are more likely to suffer from randomness problems and are easier targets for attack. (e.g. tampering with the supply chain for all server hardware in order to backdoor Bitcoin Core is probably much less attractive than going after the supply chain for a hardware wallet). So while derandomized signing is a good practise because it aids auditability and _maybe_ reduces the space for incompetent implementations to screw up a bit, in someplace like Bitcoin Core I don't generally consider it very important (though, we did it in any case; in part to set a good example).  I had proposed the ecosystem switch to it, back around when BIP 32 was announced, but we hadn't switched to it in Bitcoin Core yet because derandomized signing basically requires replacing what OpenSSL does. (OpenSSL does have a non-standard quasi 6979 implementation in its source repository-- for a long time I'd hoped to pick that up-- but its never made it into production for some reason.)

With respect to the side-channel attacks. It seems to be impossible to convince people of the non-wisdom of running critical cryptographic software on commodity shared-hardware virtual machines; just like it's hard to convince them to stop reusing addresses. Especially when coupled with the fact that the parties doing this are usually handling third party funds, it seems like disaster waiting to happen in a number of respects. With flush+reload boosted side-channel attacks being successfully performed against OpenSSL for our curve with a surprisingly small number of queries, I did consider that fairly concerning.

The distinction is that getting the signing nonces right is a process that can be secured one time for all users by auditing the software; but making sure users don't deploy in a side-channel vulnerable way is something that must be done for each and every user and doesn't really scale. The possitiblity of side-channel attacks is very surprising to people so they don't tend to do much to secure against them. Better to just close the sidechannel.

(also, wtf is with this thread? it seems like five threads merged together. It's impossible to read; I never would have found this post except by pure chance.)
1120  Bitcoin / Bitcoin Discussion / Re: Users of Bitcoin Core on Linux must not upgrade to the latest version of OpenSSL on: January 12, 2015, 04:55:37 PM
The binaries from are not effected, not on any operating system.

Virtually all users on Windows and OSX are not impacted, because virtually all of them use provided binaries. The only way you are possibly effected on those platforms is if you built the software for yourself and if you update OpenSSL.

Unless LibreSSL is guaranteeing bug-for-bug compatibility with old OpenSSL, it cannot safely be used with Bitcoin.
I looked at that a while back and their massive house-keeping makes the _changes_ more or less impossible to review. (Of course, OpenSSL is more or less impossible to review to begin with; so for their purposes I cannot blame them.)

Keep in mind the Bitcoin protocol doesn't use SSL. That we're using a SSL library here is an accident of history, and a bad call in general. As this update demonstrates, our needs are at odds with the needs of a SSL library.
Pages: « 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 [56] 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 238 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!