Bitcoin Forum
May 25, 2024, 07:21:03 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 [348] 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 »
6941  Bitcoin / Project Development / Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) on: December 10, 2011, 07:10:38 PM
Namecoin might be able to handle ownership of shares pretty easily without modification.

It is a pity that namecoin addresses are forced to look different from bitcoin address though, as that means you cannot simply use the same address as a bitcoin address to send dividends or whatever to. You'd have to eat up space in the namecoin chain to specify a bitcoin address if you wanted to use bitcoin along with it. On the other hand though, you could simply pay all dividends and such in namecoin and let people trade them on exchanges for any other kind of coin they would prefer to have.

-MarkM-
6942  Bitcoin / Wallet software / Re: Open-Transactions new version: MARKET screen now functional. on: December 10, 2011, 06:13:10 PM
Maybe with smart contracts / scripts you could script up something for the kind of roundabout trades you have in mind.

I suppose in meantime you could offer directly the deal you have in mind, who knows someone might take it, or might do the multi part deal in order to be able to take up your deal. I guess it would help to make your deal a little better, basically add in whatever you think the risk cost is of getting stuck partway through the multi-step deal.

By the way, so far I have been implementing all my currency contracts for my server as whole coins.

Do you think that is a bit problem?

I am hoping it will help avoid cluttering up the system with tons of tiny transactions.

For example if you want to sell BTC at 2.99 MtGoxUSD each, you could offer 100 BTC for 299 MtGoxUSD on the units-of-100-BTC market...

I kind of hope to move away from pathetic "I want to but 0.01 BTC" type orders. Real Forex exchanges tend to operate in 1000's at a time, don't they?

-MarkM-
6943  Bitcoin / Wallet software / Re: Open-Transactions new version: MARKET screen now functional. on: December 10, 2011, 04:26:51 PM
Transfer from one server to another would require collusion between the operators of the servers.

Possibly most of it would be done by selling off the stuff to be transfered to get a sum of some easily moveable money such as bitcoins, then buying at the other end once those bitcoins arrive.

I am brainstorming now how using a greater level of abstraction might help some situations, such as having different tokens I issue representign coins I have on different servers, but commonly using a generic token that doesn't really care which server's tokens will ultimately end up backing them.

That way maybe you could trade a generic "back by a bitcoin somewhere but not specific as to where" token that I could end up redeeming in the form of a bitcoin at MtGox or a bitcoin at TradeHill or a bitcoin sent to some address you want it sent to or whatever.

With some of the alternate blockchain currencies I am also concerned about double spend / 51% attacks. I am thinking it might be nice if it were possible to operate something like e-gold, where really one does not actually expect anyone to ever demand delivery of the underlying gold.

If I didn't have to worry that everyone would keep wanting the represented coins actually sent out to them over the blockchain, I could use only coins that are old enough to have had hard-coded checkpoints coded in the clients sicne the block the coins are in, and thus back my tokens with highly secure against double-spending coins.

That will fall apart if people keep demanding I send them the coins, as any new coins that come in will be too recent to be secured yet by hardcoded checkpoints.

Basically the idea would be to use market-makers, who buy my tokens and also sell them, and are maybe the only people I actually take real backing-assets from to issue more tokens.

It is still a problem though as I would have to sit on the coins they send me until the next hard-coded checkpoint before issuing tokens based on them.

-MarkM-
6944  Bitcoin / Wallet software / Re: Open-Transactions new version: MARKET screen now functional. on: December 10, 2011, 03:37:58 PM
The cash is per server, and you have to check with the server to make sure someone didn't already redeem it, since obviously someone could make umpteen copies of any particular cash-certificate. The server keeps track of which have been turned in so it does not honour them a second time.

-MarkM-
6945  Bitcoin / Project Development / Re: On a decentralized bitcoin-based stock market... on: December 10, 2011, 01:28:38 PM
If merged mining can work with arbitrary numbers of blockchains, maybe shares could be issued simply by starting a new chain that issues that many units in its genesis block? The issuing ocmpany would own those, and ownership can spread from there by normal operatinos of changing ownership on blockchains.

There are already supposedly methods one can use to lock in change of ownership on one chain so a change of ownership of something on another chain has to happen too.

Basically each type of share would be another alt currency, like the GMC (General Mining Corp) and GRF (General Retirement Funds) chains.

-MarkM-


I thought about this, but could this be susceptible to the 51% attack?

So far, yes. That is why GMC and GRF chains have been kept private, and now actually might even get abstracted away completely in favour of simply trading in Open Transactions some tokens representing such coins. The actual chain with the actual coins is starting to look like it can simply go away as not really being needed. Though if at some time such a chain does seem useful it can be created from scratch and the tokens in the Open Transactions system can be used to determine how many initial "coins" to issue initially to who.

Similarly with a number of other private blockchains; it is starting to look as if the actual chains can be ignored in favour of working directly with the Open Transactions tokens representing the values that would/could be represented in such chains.

If/when actual chains can be deployed without worry about 51% attacks, fine, that can be done. Meanwhile trading can proceed without waiting for the actual deployment of such a chain and such chains might even end up never actually being needed.

-MarkM-
6946  Bitcoin / Project Development / Re: On a decentralized bitcoin-based stock market... on: December 10, 2011, 12:59:58 PM
Open Transactions uses cryptography to sign everything, maybe just publishing transactions can suffice?

Anyone interested could keep histories, even though Open Transactions uses triple-signed receipts to avoid actually needing to keep transaction histories. (The receipt, signed by the two parties to the transaction and the server that executed it, serves as "proof" both parties and the notary server all agreed as to the balance, making the history of how that balance was arrived at moot/irrelevant.)

Since we depend on the issuer anyway - the company of which shares are issued - they could simply run a server themselves. They need not though, as any other server can allow them to do an issue. Either way there is their signed contract describing the issue, and triple-signed transactions whenever any units of the issue change ownership.

Ultimately we probably don't really care much how many people or entities who can do nothing in the way of actually grabbing for us some portion of the real assets of a company we have shares in think we have such shares. It is those who can actually give us something real when the company dies that need to know how much of the assets should be shipped to us or sold for something that is shipped/transferred to us.

But if all the transactions get published, so that the issuer and anyone else can see a server never issued any more than the actual issuer of the contract ordered them to, does it really matter what kind of storage or database various observers choose to use to store that info?

If a company's only assets are to be p2p assets though, such as holdings of various alt coins for example, then possibly it might make sense to try to run the whole company as a p2p application. As soon as you want it to hold non p2p assets though, there is centralisation, in that the value of each such asset is probably centralised at the location of that asset and/or the legal/de-facto ownership/control of that asset.

("Smart assets" can help with that though so maybe we should work on developing those while at it.)

-MarkM-
6947  Bitcoin / Project Development / Re: On a decentralized bitcoin-based stock market... on: December 10, 2011, 12:24:07 PM
If merged mining can work with arbitrary numbers of blockchains, maybe shares could be issued simply by starting a new chain that issues that many units in its genesis block? The issuing ocmpany would own those, and ownership can spread from there by normal operations of changing ownership on blockchains.

There are already supposedly methods one can use to lock in change of ownership on one chain so a change of ownership of something on another chain has to happen too.

Basically each type of share would be another alt currency, like the GMC (General Mining Corp) and GRF (General Retirement Funds) chains.

-MarkM-
6948  Bitcoin / Project Development / Re: Dark Exchange: a 100% decentralized p2p exchange on: December 09, 2011, 02:59:40 PM
whats the status of this project?
Last time I tried to get it to run it showed errors, which I posted, but I never heard back. So as far as I know it does not work.

-MarkM-
6949  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 02:15:32 PM
Yeah but unless the client can actually go look at the parent chain, anyone could just pretend they have a chain someplace that they used as parent, and make up stuff about some fictional block on that fictional chain they supposedly did the merged mining with.

Unless you can actually go look at that parent to make sure it really does have your chain's merkle hash thing in it at the place described and at the difficulty described, what does having a parent chain accomplish?

EDIT: maybe we don't care if the purported other chain(s) exist so long as the hash is difficult enough? It'd be just as much work to make the entry for the rainbow table of fake merged mining proofs one per merkle our chain might have that it wants to see in the proof as it would be to do the real proof? (But having done the real one, what stops you saving it as an entry for rainbow table in case a collision ever occurs so that you get to present the same proof again? Just the sheer unlikeliness of collisions?)

-MarkM-
6950  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 01:19:05 PM
It looks as if the child chain client has to know in advance exactly which chain(s) are to be acceptable as parent chains, and how to get hold of specific blocks of those parent chains. So basically it is not a miner's decision hey I think I will mine with chain Y using chain X as parent; it is hard-coded into the clients of chain Y exactly which chain(s) can be used as parent and exactly how to tell which of those chains, if more than one possible parent is coded in, a particular merged-mined block did chose as its parent.

My confusion arose from seeing all kinds of posts all over the place that made it sound like a miner just decides one day hey it would be fun to use this one as parent for that one today...

Do the child chain clients contact the parent chain network as well as their own network, and keep their own copy of the parent chain blockchain on hand to check against? If not, how do they go about getting the referenced block of the parent chain to check a merge mined block against? Some hard coded block explorer URL they consult or what?

-MarkM-
6951  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 12:05:54 PM
So how do they check the hash is correct? It is a hash of some other chain's block isn't it, not the hash you get by hashing the block of the child chain you are actually the client for?

-MarkM-
6952  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 11:41:55 AM
The -qt was unable to mine because the threads it used were not compatible with something, maybe with the going out to get the receiver files or something like that.

If those threads are now in use in the latest bitcoin, we might find that we cannot mine using the new version.

That would require finding some alternate means of getting the receiver files that is thread-safe with the newfangled threads.

-MarkM-
6953  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 11:25:38 AM
If you have identified the original bitcoin that devcoin was made from, presumably with a context diff you can get the complete set of changes that constitute devcoin's difference from bitcoin.


Then maybe we can work through them trying to apply them all correctly to the latest stable release of bitcoin and maybe from there be poised to pull any more fixes that bitcoin comes up with?

If I have this right, that would involve forking from https://github.com/bitcoin/bitcoin and renaming my fork devcoin then start applying the patches.

As for adding merged mining, I do not understand how clients confirm the validity of blocks that claim to have their proof of work on some other chain that a given person running a client might not even have installed, and even if they do have it installed its blockchain is hopefully under some other username so that the various daemons cannot mess with each other's wallets.

What is actually involved at the client to check that a block is valid when it has been merged-mined, especially if the chain used as parent is some new one we never even heard of before? What info about how to find that chain, how to get info from it about proofs of work and so on does the client need, and where/how does it get it?

-MarkM-

6954  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 10:26:46 AM
Maybe that is not the block 18851 you are being sent?
Is there a block explorer for devcoin?

I saw a couple announced along the way, but any I actually tried to look at just kind of hung, either website too slow or back end too slow or site offline or something, not sure what, but I never actually got as far as actually seeing a page of output from any of them.

The checkpoint at 18851 was a very recent block, maybe it did turn out later to be an orphan. I am going back a bunch of blocks now to find a checkpoint to add, more recent, and remove that 18851 checkpoint. Maybe that will fix it.

I uploaded a new -qt to https://sourceforge.net/projects/galacticmilieu/files/ and will put a new devcoind there too shortly.

(SourceForge's web-based upload always craps out on devcoind, I have to go look up how to do it via sftp each time.)

-MarkM-
6955  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 09:09:56 AM
Maybe block 18851 doesn't have the expected checkpointed hash,

 (nHeight == 18851 && hash != uint256("0x00000000005775d287176111b9d6fb1e1618ca13151b1f97f830b3d0fea4197d")))

or that hash is actually for the previous or next block.

I thought it was block 18851 because in the debug.log it said:

BitcoinMiner:
proof-of-work found
  hash: 00000000005775d287176111b9d6fb1e1618ca13151b1f97f830b3d0fea4197d
target: 000000000079d483000000000000000000000000000000000000000000000000
CBlock(hash=00000000005775d28717, ver=1, hashPrevBlock=00000000001afbb1ac53, hashMerkleRoot=9929a03757, nTime=1321878699, nBits=1b79d483, $
  CTransaction(hash=9929a03757, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 0483d4791b0130)
    CTxOut(nValue=5000.00000000, scriptPubKey=049c73dbd9a3389072f874670a677b)
    CTxOut(nValue=45000.00000000, scriptPubKey=OP_DUP OP_HASH160 2639637eb4cc)
  vMerkleTree: 9929a03757
11/21/11 12:31 generated 5000.00
keypool keep 7244
  nActualTimespan = 98958  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 86400    nActualTimespan = 98958
Before: 1b78714c  000000000078714c000000000000000000000000000000000000000000000000
After:  1b79d483  000000000079d483c52bdd36d815119b92bdd36d815119b92bdd36d815119b92
AddToWallet 9929a03757  new
SetBestChain: new best=00000000005775d28717  height=18851  work=3040468427823054
ProcessBlock: ACCEPTED

which I was still able to find in the debug.log

Seems to me that in the past that height= number was the number matching the preceding hash number.

Maybe that is not the block 18851 you are being sent?

-MarkM-
6956  Bitcoin / Bitcoin Discussion / Re: Bitcoin the enabler - Truly Autonomous Software Agents roaming the net on: December 09, 2011, 12:24:49 AM
SInce bitcoin provides it a way of receiving payment without having to reveal a website or host for anti spam activists to shut down when it spams people trying to get theym to send money, it might be able to do quite well as a spammer. Prepare a new place to be hosted, set itself up there safely, then spam the heck out of the old location until it is shut down. The new child collects the proceeds from the blockchain, sets up another new bolthole, and proceeds to spam again...

...Heck it could even try actually sending people whatever they thought sending the coins was goign to buy them. Who knows, maybe if it signs its spam it could build up a rep to customers that might make it a more lucrative spammer that way than if it simply took them money without providing anything in return.

-MarkM-
6957  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 09, 2011, 12:11:05 AM
What port does devcoin use, so I can make sure it's open?  I searched this thread and couldn't find it.

It is set in net.h:

inline unsigned short GetDefaultPort() { return fTestNet ? 62333 : 52333; }

So 62333 for testnet (which the d and the -qt disagree currently as to correct hash for), 52333 for real net.

-MarkM-
6958  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 08, 2011, 11:57:09 PM
Thanks.

The different genesis hash is just the testnet one.

The different height thing is something to do with trying not to bother with old inventory until you have the blockchain, both versions numbers seem just inherited from bitcoin, probably should be a constant one can set someplace convenient, something like how big was blockchain last time we coded this.

The message about failing checkpoint though looks like it should have fired every time, as that line appears twice in the -qt, once as clause of if, but then immediately thereafter, from clumsy delete old and paste new obviously. The second occurrence should just unconditionally fire.

But that would make it do the return error thing, which I would have expected to cause the program to die. So it is still somewhat mysterious.

I am deleting the extra copy of that duplicated line and seeing if that fixes it.

EDIT: Yep, that was the culprit. Tarring up to put to sourceforge now...

EDIT2: Ok, done. devcoin-qt-8-Dec-2011.tgz (at https://sourceforge.net/projects/galacticmilieu/files/ as usual).

-MarkM-
6959  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 08, 2011, 10:34:08 PM
I vaguely recall people had trouble in past getting initial blockchain with the -qt, and just ran the daemon instead.

However, after looking at that diff, I am not confident that the -qt will actually work even once the blockchain *is* downloaded, as it seems to have a different idea of at which block some fix or other is to kick in. (That is visible in the diff before the part where we see two different genesis block hashes.)

-MarkM-
6960  Alternate cryptocurrencies / Altcoin Discussion / Re: [800,000 DVC remaining bounty] for Devcoin preliminary testing on: December 08, 2011, 10:05:04 PM
Last change was just to default fees, to defend against dust spam.

So it must have broken further back than that and we jsut don't have enough new people starting from scratch with the GUI to notice when it breaks.

Hopefully it is something in main.cpp, so I did a diff:

Code:
[root@megabox bitcoin]# diff devcoin/src/main.cpp devcoin-qt/src/main.cpp
20d19
<
650d648
<
737d734
<
797d793
<
993,994d988
<
<
1359a1354
>             return error("AcceptBlock() : rejected by checkpoint lockin at %d", nHeight);
1375c1370
<                 if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 134444))
---
>                 if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 118000))
1494c1489
<         ThreadSafeMessageBox(strMessage, "Bitcoin", wxOK | wxICON_EXCLAMATION);
---
>         ThreadSafeMessageBox(strMessage, "Devcoin", wxOK | wxICON_EXCLAMATION);
1546c1541
<         hashGenesisBlock = uint256("0x0000000062558fec003bcbf29e915cddfc34fa257dc87573f28e4520d1c7c11e");
---
>         hashGenesisBlock = uint256("0x0000000087a230b3a9d612d73dba267cb70135b76a923cae2c74852c2e5d7639");
1605,1607c1600,1603
<         printf("%s\n", block.GetHash().ToString().c_str());
<         printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
---
>         printf("hashMerkleRoot  : %s\n", block.hashMerkleRoot.ToString().c_str());
>         printf("hashGenesisBlock: %s\n", hashGenesisBlock.ToString().c_str());
>         printf("Actual blockhash: %s\n", block.GetHash().ToString().c_str());
>
1610,1621c1606
<            // This will figure out a valid hash and Nonce if you're
<            // creating a different genesis block:
<            uint256 hashTarget = CBigNum().SetCompact(block.nBits).getuint256();
<            while (block.GetHash() > hashTarget)
<            {
<                ++block.nNonce;
<                if (block.nNonce == 0)
<                {
<                    printf("NONCE WRAPPED, incrementing time\n");
<                    ++block.nTime;
<                }
<            }
---
>            printf("You need to put correct hashMerkleRoot in these asserts to get past these asserts.\n");
1623,1630d1607
<
<         //// debug print
<         printf("block.nTime = %u \n", block.nTime);
<         printf("block.nBits = %u \n", block.nBits);
<         printf("block.nNonce = %u \n", block.nNonce);
<         printf("%s\n", block.GetHash().ToString().c_str());
<         printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
1648,1649c1625,1626
< }
< //// debug print
---
>         }
>         //// debug print
1653,1655c1630,1632
<         printf("%s\n", block.GetHash().ToString().c_str());
<         printf("%s\n", hashGenesisBlock.ToString().c_str());
<         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
---
>         printf("hashMerkleRoot  : %s\n", block.hashMerkleRoot.ToString().c_str());
>         printf("hashGenesisBlock: %s\n", hashGenesisBlock.ToString().c_str());
>         printf("Actual blockhash: %s\n", block.GetHash().ToString().c_str());
2154d2130
<         unsigned int nBytes = 0;
2160c2136
<                 printf("  getblocks stopping at %d %s (%u bytes)\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str(), nBytes);
---
>                 printf("  getblocks stopping at %d %s\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str());
2164,2167c2140
<             CBlock block;
<             block.ReadFromDisk(pindex, true);
<             nBytes += block.GetSerializeSize(SER_NETWORK);
<             if (--nLimit <= 0 || nBytes >= SendBufferSize()/2)
---
>             if (--nLimit <= 0)
2171c2144
<                 printf("  getblocks stopping at limit %d %s (%u bytes)\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str(), nBytes);
---
>                 printf("  getblocks stopping at limit %d %s\n", pindex->nHeight, pindex->GetBlockHash().ToString().substr(0,20).c_str());
2836,2838d2808
<     // Add our coinbase tx as first transaction
<     pblock->vtx.push_back(txNew);
<
2841d2810
<     //int64 nFees = 0;
3038c3007
<     printf("BitcoinMiner:\n");
---
>     printf("DevcoinMiner:\n");
3048c3017
<             return error("BitcoinMiner : generated block is stale");
---
>             return error("DevcoinMiner : generated block is stale");
3059c3028
<             return error("BitcoinMiner : ProcessBlock, block not accepted");
---
>             return error("DevcoinMiner : ProcessBlock, block not accepted");
3070c3039
<     printf("BitcoinMiner started\n");
---
>     printf("DevcoinMiner started\n");
3105c3074
<         printf("Running BitcoinMiner with %d transactions in block\n", pblock->vtx.size());
---
>         printf("Running DevcoinMiner with %d transactions in block\n", pblock->vtx.size());
3252c3221
<         printf("Starting %d BitcoinMiner threads\n", nAddThreads);
---
>         printf("Starting %d DevcoinMiner threads\n", nAddThreads);
[root@megabox bitcoin]#

Maybe someone can see something in there that explains why devcoind gets new blockchain seemingly okay but the -qt thinks everything after the genesis block is an orphan?

Hmm, like WTF is that totally different genesis block hash part about? I hmmm WFT happened / is happening...

-MarkM-

EDIT: the -qt is obsolete anyway, since the base/mainline bitcoin now uses qt instead of wxwidgets. SO we should just forget about the qt and update the devcoin aka devcoind release to the latest bitcoin, thus no longer needing two separate releases as the GUI will use the exact same actual engine code as the daemon, no more trying to make same fixes to two different packages.

It seems quite possible that I *did* regenerate the genesis block after a restart so as to not have long gap in time between date of genesis block and date of next block, but didn't put the new hash into the -qt and that never got noticed as it only checks that when getting new blockchain.

I do not understand though why the -qt didn't simply claim the genesis hash was wrong and die, instead asking for more blocks and listing them as orphans.

If someone can discover a way to tell github to make a fork under a new name, I would like to make a fork of the latest bitcoin but name it devcoin, so we can start trying to turn current bitcoin into an up to date devcoin...
Pages: « 1 ... 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 [348] 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!