Bitcoin Forum
April 30, 2024, 12:18:03 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 ... 288 »
2841  Bitcoin / Development & Technical Discussion / Re: Dual SNARK: How to make ZKP with trusted initilization trustless in some cases. on: March 16, 2014, 08:25:45 PM
Why do you say "because it's zero-knowledge miners couldn't come along and replace the outputs like in a plain hash-locked transaction" ? If I understand this paragraph (and your last comment in this post) correctly, the payer has to specify a specific payee that can redeem the coins (rather than allowing anyone who knows a solution to the Sudoku puzzle to redeem the coins) ? If so, this can be done outside the snark, as we normally do in Bitcoin by requiring the ScriptSig input-script to provide a signature for a specified address/pubkey of the payee, in order to prevent miners from replacing the output. Is there any beneficial reason to enforce the payee's identity inside the snark, as you seem to imply here?
Perhaps not. I probably picked a poor example— and perhaps there isnt one— to describe a motivation for doing this.  Really when the payee is designated I think you can almost always completely remove the proving process from the cryptocurrency.

Quote
Also, if I understand correctly then the protocol here isn't non-interactive, i.e. the payee sends to the payer via a private channel an encrypted solution s0 encrypted under symmetric key k0, and then the payer broadcasts the snark transaction that should reveal (in the clear) k0, so that only the payer will know the solution?
It's inherently interactive but it could potentially be asynchronous. 

Let me expand the idea further so that the application is more clear.   Say we make our SNARK circuit a universal circuit (like vntinyram) which takes a hash of the program as a public input (and the program itself as a private input).   Lets also assume that you and I are members of a trading club which frequently trades puzzle solutions for coins amongst its members.

Every member of the trading club compiles and the tinyram circuit and produces a ECDSA private key. They publish the verifier key and public keys to all the members of the club and (via some sibyl resistant process) the club produces a hash-tree over these verifier keys and the public keys which everyone in the club agrees is correct.

Now I can form a transaction which offers a coin to someone who can produce either dual SNARK proofs (or SNARK+sig), such one snark is mine, and the other is any which is not mine in the list (by providing the verification key and proving membership in the set committed in the transaction).

(If you don't-dual snark, and replace the hashtree with a ring signature of all the club members except me (or turn the hashtree approach into a ring signature by running selection and blinding in zero knowledge), then the identity of the redeeming party can be private and unknown even to me.)

In any case in this example there was interaction, but it was all in a setup phase, and the redemption can be asynchronous and one-shot.

Quote
If my understanding above wasn't way off, then isn't it enough here to require the payee to provide his digital signature (in additional to the proof that passes the snark verification), and because the payer cannot produce a signature for the corresponding pubkey of the payee, he cannot double-spend by providing a false proof (that he can produce because he knows the snark initialization), at least until some nlocktime expired where he'd spend the output via a transaction that the payee already signed for him.
Maybe, though this has weakness when you want an 'nlocktime' rule which is more complex than nlocktime.  E.g. transaction pays you if you present a receipt from your bank that the payment went through, it refunds to me if I can present proof from my bank that the transaction was reversed... then only after some very long timeout does the nlocktime come into play.

It seems to me that for non-interactive proofs (as in CoinWitness), the need to avoid a trusted initialization cannot be overcome. And on the other hand, trusted initialization isn't really an issue in interactive ZK proof scenarios? But please elaborate on any observations that I could be missing here...
I agree. Though I'm not sure if non-interactive is the quite the right criteria it fails, I think it fails publicly verifiable (yes, the CRS schemes are 'publicly verifiable', but only with trust that is not really acceptable). The interactive schemes are often easy in part because there is a designated verifier.

I don't seek to say that trusted init can replace non-trusted, it really cannot for many things. I'm just exploring the space that tools with trusted initialization can be applied.
2842  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 16, 2014, 12:13:49 PM
Oh brother, could you possibly be more maudlin and self-pitying?   Roll Eyes
A 105% refund is not "nothing" no matter how much you prefer a 600% windfall.
No court is going to ignore the fact you refused a refund in legal tender.
Have you read a Federal Reserve Note lately?  It does what it says on the label (settle all debts, public and private).
You did not offer me a refund, you offered me a settlement— as was plainly stated. The settlement was for a fraction of what you owe me according to our established agreement and had burdensome additional terms which I have never and will never agree to. (If we're to be pedantic: You also did not offer me federal reserve notes, fwiw.)

No court is going to ignore that you ignored a mountain of letters from me and my months long good faith effort to sort this out in a mutually agreeable manner, no court is going to ignore that you've never offered me a _refund_ just an additional contract "settlement" for a fraction of our agreed on terms. No court is going to ignore that you you're now publicly claiming that you're not going to pay me anything at all.

As I pointed out in prior (I believe now deleted) messages: I would happily take alternative compensation for your default and would even prefer alternative compensation if it was mutually beneficial. What I wouldn't accept is a tiny fraction of a refund plus a "disparagement agreement" while you walk away with a huge windfall and leave dozens of other customers screwed over here— while the "disparagement agreement" left me less able to help them.

But speaking of court— you're saying you're so confident about the outcome, OKAY— where is my release from the forced arbitration so we can actually take it to court without a months long dispute over the proper venue?
2843  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s [Non Self Moderated] on: March 16, 2014, 11:43:03 AM
FWIW, it looks to me like they're selectively locking the other thread when they're not at the computer and can't be vigilantly deleting messages. Kinda crazy.
2844  Bitcoin / Development & Technical Discussion / Re: I don't think 'Pi' is a valid public key... on: March 16, 2014, 11:34:45 AM
It's an output, and it's unspent. Bitcoin blockchain rules do absolutely nothing with the content of scriptpubkey until its spent.
2845  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 16, 2014, 11:20:18 AM
You have time to complain to the forum, bother the State of Californa, and hire a lawyer.
I have a standing relationship with an attorney for a multitude of reasons.  I don't know why you keep talking about "bother the state of california", I believe I've not yet ever communicated with the state of California on any matter what-so-ever, and certainly not you or your company. You need to discontinue your lying here.

Quote
More like, you know your quest for a ~600% gain for doing nothing is doomed to fail if it ever reached a proper venue.
Okay, release me from the forced arbitration clause so that there isn't ton of time wasted arguing about the venue— since you're so confident that you'll prevail— and I'll go head with lawsuit now that you've _finally_ admitted that you're planning on actually returning nothing at all— and not leaving me thinking that you just have not been getting my letters.

By taking my funds and giving absolutely nothing, no refund no product you are a thief. And perhaps really what I should be doing is perusing criminal charges. Your theft is not just a civil matter at this point: No theory of law enables you to take peoples funds and give them nothing and then argue that they've somehow forfeit your obligation because you've successfully ignored all their attempts to communicate or negotiate and they wouldn't take a tiny fractional one-sided 'settlement' with onerous additional terms.
2846  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: March 16, 2014, 08:10:08 AM
why not define an specific database for bitcoin to decrease the blockchain?
I believe BerkeleyDB save a lot of metadata for it's own work/features that maybe we dont need them at all.
BDB is _only_ used for the wallet. The blockchain itself is stored as raw blocks.
2847  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 16, 2014, 06:26:49 AM
i think you got a chance there.
Sadly, I don't because I simple don't have the time— or emotional tolerance— to see these guys through to court. Fortunately other people are already in the process of suing them, so some amount of justice may still be served.

I started the heavy prodding in public when I saw they were soliciting more rubes to screw over, with only a mild hope that I'd ever see a dollar or a Bitcoin out of them— that maybe if they saw they they were going to be able to get away with the highly profitable task of pulling in more victims without complaint they might try to rescue things with their past customers.  I think that at least the recent noise has been successful at increasing a lot of awareness, and maybe saved some people a $6k loss, so thats all good.

If there is anything someone thinks I can easily do to help them recover please let me know.
2848  Economy / Service Discussion / Re: CampBX [btc] missing on: March 16, 2014, 01:26:38 AM
FWIW, Campbx seems to have lost my deposit of testnet BTC.  Glad they have a testnet site so that I could see that their service is having problems without using real coins! Smiley
2849  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 15, 2014, 09:35:40 PM
So there is a gap in lawmaking and HF is using this gap to commit fraud.
I don't really agree there. This is what contracts exist for. The law doesn't have to forsee in advance every possible business contingency.  There is no basis in law that says that you can just ignore a contract when it suits you.
2850  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 15, 2014, 09:31:37 PM
Just out of curiosity, you stated in the other thread that your deadline was the 31 of January. Batch 1 deadline was the 31 of December, so you are batch 2, right?
Gah no. I started to type January 1st and then realized the actual date was Dec 31st and didn't fix the month. My purchases were August 14th and September 1st, both Batch 1. (thanks for pointing that out, I fixed it)

They sent the revised terms to me on 08/21. I just personally consider them binding both due to the second purchase and because I talked to them after, considered immediately demanding a refund but didn't— because frankly the revised terms seemed more realistic to me... I was worried that they'd be a day late and get slammed with refunds and that didn't strike me as fair or wise. So if anything the contract revision increased my confidence... how foolish I was.
2851  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 15, 2014, 09:25:33 PM
The bottom line is that money is power.
Well, hey, some of us still have money here, and their 90%-100% losses on HF so far haven't left them broke.  Is there some slot where I can insert money and receive justice? I too am unhappy with them getting away with the fraud— even more so than my financial loss. I'm willing to double down on my losses if I was reasonably confident that the result would be them not getting away with it, because I'm very concerned with the long term effects on the mining ecosystem if its possible for hardware vendors to freely get away with fraud. What I don't have an abundance of is time.

I was thinking of perhaps funding some bounties for things like most effective community action to prevent others from getting defrauded by hashfast, but I'm not sure I have time to administer it— and esp. in terms of figuring how how to convince people that I'm being serious when I say that I really don't want anything illegal done.
2852  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 15, 2014, 09:23:27 PM
Pete Morici for example is suing them in court, instead of going with AAA/JAMS. That's a breach of the contract.
It really depends on the strategy you are following. (Morici states that the contract was sent to him one week after his purchase; by email).
Posted from Bitcointa.lk - #PrO8XVnUfBUyTgW7
It was also sent to me in email after my first purchase too, after a couple days delay. If they sent it to him at the same time they sent it to him it would have been a long time after his purchase. But I accepted the agreement and later— after HF had continued to say they were on-time for a few more weeks— made another purchase.  I could probably also make Morici's argument— that October 20th was the only relevant date— for my first purchase... but I'm really trying to give hashfast every bit of slack: Business is hard. But being screwed over even after giving them the benefit of doubt on ambiguity about which terms were actually in effect stinks.

Sadly, if HF is run as incompetently as they appear to be there likely will be nothing to recover. Getting a larger fraction of what they owe me at the expense of causing a complete loss for people making purchases now (under newer, even crapper terms) doesn't really strike me as the right thing to do, at least personally. I don't fault other people for forcing hashfash to comply with the agreement though. The fault rests exclusively on hashfast if they drafted a contract of adhesion that they couldn't live up to themselves.
2853  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 15, 2014, 08:52:03 PM
You voluntarily chose to spend your 98 BTC and now regret it because of post-purchase appreciation.  
It has absolutely nothing to do with the appreciation of Bitcoin. Your company advertised an October 20th delivery, and claimed to be "on time" until just before you missed that target— now it seems like you were just committing fraud at that point considering you didn't even have the chips until months later. I paid you roughly 5x per GH/s what your competition was charging specifically because you assured me that by doing business with you I wouldn't end up with substantially fewer coins than I started with as a result of delays or failure on your part. You assured this in several layered ways, including a promise of a full refund in the case that you had massively failed to deliver— which turned out to be the case. That promise required holding or hedging and was worth a premium. Because of these assurances I took a risk in doing business with you, and even if you do ultimately make good on your contract I will still be at a significant loss in terms of time, stress, exposure to fraud risk from you, and loss of use of those funds for seven months.

I'm perfectly happy with the actual purchase I made— with the ink on the paper and the terms of the agreement. My only regret is that paper is nearly worthless when the counterpart is a con-artist. To emphasize this further, I'd also be happy to receive the hardware plus the Bitcoin it would have mined had you delivered it on your advertised date. That I haven't been demanding that instead is because it's somewhat more than the full refund which was my "only recourse" according to our agreement, unlike you I'm willing to stick to the actual agreement even when it's a loss to me. Hell, I was prepared to accept— according to our agreement— the hardware plus full MPP and what it would have mined starting on your massively late deadline date of December 31st, though that would be a loss to me. In my first certified letter I proposed an alternative negotiation which would have allowed you to refund me in additional hardware (with a formula for the amount based on when you sent it), specifically because if you did something massive stupid and didn't hold/hedge I didn't want to put you out of business— for the same reason that you're getting forum posts from me and not a process server banging on your door. I'm willing to negotiate and even consider alternatives that leave me somewhat worse off than our agreed terms, because I think business should result in mutually beneficial results. Sadly, you've ignored my letters. What I will not accept is taking a complete bath while _you_ take a windfall, in violation of our contract, nor will I accept a "settlement" that leaves me defrauded while prohibiting me from telling others.
2854  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 15, 2014, 08:25:04 PM
Query: If BTC went to $1,000,000 would you still expect HashFast to pay out millions of dollars in windfall refunds?
Sure. Everyone expected you to comply with your promises and to have held or hedged the Bitcoins you collected in order to do so, the talk about investors certainly created that impression, and the very reason we asked about the refunds was specifically because of that case and the reason that we still purchased your hardware at 4-5x the cost per GH of your competition at the time was because of assurances like that.

It's a very easy scam that others are believed to have performed in the past: Collect a bunch of pre-order money. If BTC goes up a lot 'refund' a bunch of people USD. If it goes down, either go ahead and ship a product to everyone or try to refund in BTC.

The fact that you also forcefully "refunded" fractional amounts in USD denominated terms in violation of the contract to many early customers without them ever asking for a refund makes a lot of people believe you are engaging in this fraudulently behavior and that perhaps you company intended to do so all along.

There is no windfall here. I started with X Bitcoin. You sold me a machine to mine Bitcoin for those X Bitcoin scheduled for late october whos value you would almost certainly rapidly decrease and would have been rather close to only breaking even— mining back just X Bitcoin— if you shipped on time and would become worthless if you were late. Your contract allowed you to be up to two months late with no recourse, which would have made my purchase into a substantial loss. To prevent a total loss your contract guaranteed a cancellation and full refund if you were later than that. You were— shipping to apparently a fraction of customers three months after your advertised date and almost one month after your own self-set deadline.

Few sane would spend X bitcoins to purchase hardware which would only ever mine 0.1*X bitcoins, they certainly wouldn't do so at 5x the cost of the competition. Your company was abundantly clear on this and because of it some of us purchased, because while we saw how other companies exploited ambiguity we didn't expect to get ripped off by someone overtly violating their agreement.

Part of how you managed to gain sales originally was by convincing people your company understood the business of mining. It's ironic now how you insist on not understanding it— arguing that people should be happy to pay X bitcoin to buy hardware that earns a tiny fraction back when doing so is essential for your mindblowing claim that everyone's understanding all along was that you planned on refunding the full amount paid regardless of (and specifically due to) BTC price changes in the face of the fact that your founders and support staff clarified this point in the clearest possible terms several times in public and in private. Do you expect that people will want to buy your new mining boards from a company that now insists that it doesn't understand mining?
2855  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 15, 2014, 08:16:33 PM
Let me be completely clear: HashFast sent you a 105% refund, which you admit to returning because you feel entitled to a ~600% windfall based on nothing more than post-purchase appreciation of your chosen payment medium.
You sent me a check which was clearly labeled as a _settlement_ for about 10% of the value you owed me and contained a long list of burdensome conditions, such as that I couldn't tell other people how much you screwed me over. I don't believe I could ethical accept terms like that, nor should I especially for such an enormous loss.  You sold me a machine to mine bitcoin and then you failed to deliver. As a result I lost most of my purchase price— and at the moment all of my purchase price because you refuse to refund and instead  

Quote
You know this is true, which explains your failure to get a lawyer. Good job wasting taxpayer money by going the legal route via a complaint to the state of California.   Wink
You again prove that you're not actually reading the certified letters arriving, I have an attorney. I also have not complained to the state of California, though I suppose I probably should do that as well— especially now that you've made it clear with your consistent direct lying as you're doing here that you aren't operating your business in good faith.

Quote
I see you used your moderator powers to unlock the thread and have the last word.  Very nice; did you also use your mod powers to ask cedivad to stop spamming us with re-posts?  Your own rules say edit-warring moderated threads is not acceptable...
I didn't unlock the thread. Your locking of it, however generated a number of moderator reports, so I presume someone did it.  SOP around here is that we do unlock threads when scamming vendors try to use locking to suppress people from discussing their fraud.

And please, you think I'm about to lift a finger to help you after you've fucked me over like this and behaved in such an unprofessional manner? The fact that I'm disinclined to apply the full power available to me against you should in no way be interpreted as suggesting that I think I owe you anything. I already gave you every kindness by attempting to resolve your default for three months in private before blasting you in public— attempts seem to have been completely ignored.  You always have the option of going away or convincing some other moderator who you haven't defrauded and deprived of 98 BTC. I've asked people to not repost the same stuff and to keep their posts related to their concerns that your new product (such as concerns that it will not be delivered or perform to specification based on your past and continuing dishonest and unethical business conduct), but beyond that as far as I'm concerned you can pound sand...
2856  Bitcoin / Development & Technical Discussion / Re: Why allow blocks in the past? on: March 15, 2014, 07:57:39 PM
So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud.
It was explained to you that it prevents shenanigans where the time is pushed against the rail and a trouble making minority makes the network unreliable. This is doubly true when you start to consider nlocktime.  Perhaps you don't care— people often don't care when it comes to other people's security— but at the same time it doesn't actually buy you anything either: If you want a monotonized timestamp just filter the existing one with max(current,last_filtered_value).
2857  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 15, 2014, 03:33:43 PM
So, just to be completely clear— You are, in fact, refusing to refund my payment?

I want to be complete clear on this because you have ignored every certified letter I (and apparently other people have sent you) and you seem to also be saying that you already have— which is entirely untrue. You have not refunded me in any way shape or form, the only response I've received from you at all has been the taunting, insults, and deletion notices here— plus some crazy settlement for a fraction of what I'm out due to your incompetent or deceptive business practices: I am beginning to lean towards deceptive considering your apparent complete lack of interest in seeking a mutually agreeable resolution.

You continue to have an obligation according to our contract to refund my payment after your failure to deliver by the very lenient deadline which you specified. You have ignored all my private efforts to resolve the matter and not responded to any of my communication except here in public. Obviously very few people are going to do business with you with you screwing over people like this. You've claimed that your new pre-orders were flying off the virtual shelves— and maybe there really are enough suckers out there— but I'd guess if you actually were selling product you'd actually be able to make more deliveries and refund some of the people you've screwed over and left completely in the lurch.
2858  Bitcoin / Development & Technical Discussion / Dual SNARK: How to make ZKP with trusted initilization trustless in some cases. on: March 15, 2014, 12:01:02 PM
Some of the most efficient constructions available now for proving arbitrary programs in zero-knowledge are only secure in the CRS model— in English: They require a trusted initialization step where someone has to generate some magical numbers and if they cheat (e.g. by keeping the initial randomness) they can produce false proofs.

Systems with these properties are found in some of the papers at http://www.scipr-lab.org/ and in http://research.microsoft.com/apps/pubs/default.aspx?id=180286, both of which are currently using systems based on the GGPR'12 cryptosystem. They have really awesome performance, though— fast enough to actually be feasible to use on the prover, and almost as verification in a couple milliseconds with a few hundred bytes for the proof regardless of the size of the program being proven or how long it takes to run. But the requirement of a trusted initialization is unacceptable for some applications.  Ultimately we'll want systems which do not depend on the trusted initialization but they're less far along in development and may never be quite as efficient.

Some things we'd like to use these proofs systems for is a more powerful and efficient replacement for Bitcoin script. Instead of every node verifying your fancy script, instead the party creating the transaction runs the script themselves and provides the network with an efficient proof that you ran it faithfully and that it accepted. This avoids network load as being a disincentive to using fancy scripts and also has privacy advantages.

For example, say I want to pay you conditional on you publishing a solution to a— say— Sudoku puzzle. A script running under an efficient proof of knowledge system could verify an encrypted solution, and because it's zero-knowledge miners couldn't come along and replace the outputs like in a plain hash-locked transaction. You could use a CRS snark here where the payer computes the trusted initialization and then the payee cannot cheat— but the fact that the payer initialized it means the payer could double-spend race the redemption and get both the solution and their coin back.

There are a couple of ways of solving this, but I wanted to mention another one which is especially general:

In a two-party trade, just have both parties compute their own trusted initiations, then require the script provide proofs under each of them. Then so long as one side isn't cheating the transaction will behave faithfully.

This can be further optimized by instead requiring Person_A_snark&&Person_B_ECDSA_sig || Person_B_snark&&Person_A_ECDSA_sig... Cross signing using ECDSA is more efficient since the snark proofs are larger (and much slower to compute) than ECDSA signature, and this equally achieves the goal of not allowing either party to take advantage of a trapdoor.  (in particular, if you use hash compression to avoid ever even bothering to publish the verifier public keys for the untaken branches).

The same approach can be extended to more than two parties though the efficiency becomes less impressive (e.g. the prover must run the proof N-1 times to handle any party possibly conspiring with them, or N/2 if you only want a honest majority security) and sadly, it doesn't really work for broadcast payment sorts of application.
2859  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: up to 800GH/s on: March 15, 2014, 07:03:57 AM
HashFast already offered and paid out 105% refunds.
Offered and paid out?  What are you talking about? You have absolutely not refunded me. I wish it were so, I certainly do not enjoy the current state of affairs.
2860  Bitcoin / Project Development / Re: [ANN] LAUNCHED Wallet Cloak v1.0 - Encrypt And Cloak Your Wallets on: March 15, 2014, 05:35:41 AM
The "Virus total" results mean less than nothing: They never report custom wallet stealers and couldn't be expected to do so. The fact that you keep pointing to them when you should know better yourself is very suspicious.

You should never run non open-source Bitcoin software, you should never run binaries of Bitcoin software that you or someone yourself can't verify matches the publicly audited source.

There is no particular need to use a wallet specific tool, there are many open steganography applications: http://freecode.com/search?q=steganography&submit=Search

There isn't a chance in hell that I'd run this.

Pages: « 1 ... 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 ... 288 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!