Bitcoin Forum
September 19, 2019, 09:48:03 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 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 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1267370 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
zbx
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
March 24, 2014, 01:06:31 AM
 #6041

Hey, there are a lot of threads over on the Bitcoin Subreddit talking/lamenting about recent and ongoing failures of centralized exchanges... Would people here help me watch the Subreddit and mention Counterparty where it's appropriate? Just to point people in the right direction. I'm sure that a lot of the readers there don't know about Counterparty and they'd be interested to learn that there's another real option to MtGox, Vircurex, and so on. We're obviously really close to the release of Counterwallet on Mainnet, and when that happens, Counterparty's distributed exchange will be really easy to use. Anyone will be able to trade BTC, XCP, USD vouchers, etc. without any risk of the trading platform suddenly going under, freezing withdrawals, running away with their money, or whatever.
1568929683
Hero Member
*
Offline Offline

Posts: 1568929683

View Profile Personal Message (Offline)

Ignore
1568929683
Reply with quote  #2

1568929683
Report to moderator
1568929683
Hero Member
*
Offline Offline

Posts: 1568929683

View Profile Personal Message (Offline)

Ignore
1568929683
Reply with quote  #2

1568929683
Report to moderator
1568929683
Hero Member
*
Offline Offline

Posts: 1568929683

View Profile Personal Message (Offline)

Ignore
1568929683
Reply with quote  #2

1568929683
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Matt Y
Hero Member
*****
Offline Offline

Activity: 647
Merit: 500


Counterpartying


View Profile WWW
March 24, 2014, 01:12:35 AM
 #6042

^^ I've found a couple threads and commented where appropriate. More technically savvy people will have more luck, though.

This is the most relevant: http://www.reddit.com/r/Bitcoin/comments/216d8e/coin_secrets_op_return_metadata_in_the_bitcoin/

And here: http://www.reddit.com/r/Bitcoin/comments/216ajq/this_is_fucking_ridiculous/

buaichiyuwh
Newbie
*
Offline Offline

Activity: 41
Merit: 0


View Profile
March 24, 2014, 01:14:42 AM
 #6043

maybe we can just use pos
nakaone
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
March 24, 2014, 01:27:12 AM
 #6044

a solution within the bitcoin protocol would be much better, the charme of xcp and msc is the network security and that you do not need to move your bitcoins on any exchange to get them
Matt Y
Hero Member
*****
Offline Offline

Activity: 647
Merit: 500


Counterpartying


View Profile WWW
March 24, 2014, 01:39:37 AM
 #6045

Why Counterparty used proof-of-burn to initially distribute XCP

https://www.counterparty.co/why-proof-of-burn/

There seems to be a lot of confusion about this outside of the Counterparty community. This blog post should help clear up any confusion by providing us with an easy place to direct people who have questions related to proof-of-burn.

jgarzik
Legendary
*
Offline Offline

Activity: 1582
Merit: 1005


View Profile
March 24, 2014, 01:40:47 AM
 #6046

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,
  • I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
  • I'm well versed in in-chain data projects -- I wrote some myself
  • Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
  • This feature may be going away anyway, for other reasons
  • Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
qtgwith
Hero Member
*****
Offline Offline

Activity: 602
Merit: 500


View Profile
March 24, 2014, 01:56:55 AM
Last edit: March 24, 2014, 04:25:16 AM by qtgwith
 #6047

I'm soliciting feedback on a forthcoming paper wallet design for Counterparty. Functionality will be identical to my Bitcoin paper wallet design of course: BIP38, provide your own random data (roll dice, etc.) plus ability to scan QR codes with your wallet and such.


You can print out this draft design here:


https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html?design=counterparty

https://forums.counterparty.co/index.php?topic=199.msg1559;topicseen#msg1559

I call this a draft because until the more or less "official" Counterparty logo/branding is announced, I need to keep the logos / colors flexible. However at this point I'm very interested to hear what anyone thinks about how a Counterparty paper wallet should be *different* from a Bitcoin paper wallet. For example, maybe the reverse side instructions should be significantly different. Maybe the reverse side "register" shouldn't just list amount/date, but also "asset" and "description"?


Or I wonder if it makes more sense to leave the look and feel of a Counterparty wallet essentially identical to a Bitcoin paper wallet, only adding a "XCP" logo or something to indicate that XCP are stored in this wallet as well?













Very good!Cool!

Cooperation please between BTC and XCP!

PhantomPhreak
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250

Counterparty Chief Scientist and Co-Founder


View Profile
March 24, 2014, 02:03:04 AM
 #6048

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,
  • I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
  • I'm well versed in in-chain data projects -- I wrote some myself
  • Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
  • This feature may be going away anyway, for other reasons
  • Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.


Thank you for making this post. I agree with everything in it.

What do you suggest that we do going forward? Unfortunately, I don't think that using a side-chain (with hashes of Counterparty messages in Bitcoin), or a chain with merged mining, is really an option for us, because of the security issues and the implementation-complexity involved. I also don't think that approaching miners individually is a viable option. It's too important to this project that it be built upon standard, default settings of Bitcoind. We can't let the relaying of Counterparty transactions depend on promises that particular mining pools will apply a certain patch to their copies of Bitcoind regularly. None of those options is at all worth the risk.

Counterparty was designed wholly around 80-byte OP_RETURN, not CheckMultiSig, which we started using only as a temporary measure and which we'd be glad to stop using completely. Would you support raising the size limit on OP_RETURN back to 80 bytes, so that we may do so directly? And would you support allowing an OP_RETURN output of arbitrary size, with an appropriate fee structure? (See this post.) I'm sure that the latter option is best for both Bitcoin and Counterparty in the long run.
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
March 24, 2014, 02:09:17 AM
 #6049

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,
  • I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
  • I'm well versed in in-chain data projects -- I wrote some myself
  • Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
  • This feature may be going away anyway, for other reasons
  • Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.


Thanks a lot for the opinion from another Core Dev of Bitcoin.

To be fair, Counterparty plans to use OP_RETURN from the beginning, and using CheckMultiSig is just a workaround added just before the official release because nobody knew when the core 9.0 would be out and whether OP_RETURN will be added.

Now imagine Counterparty did not add CheckMultiSig and kept waiting for OP_RETURN added in this core and now suddenly find that OP_RETURN has been reduced to 40 bytes at the last minute.

If we calm down and it will not be difficult to understand that the devs of Counterparty don't want to use CheckMultiSig at all. They and all the community are looking forward to removing CheckMultiSig and using OP_RETURN for the good of bitcoin and, to be honest, also reducing the trading fees caused by CheckMultiSig.

Nobody is arguing that Counterparty has to use checkmultisig. Current situation is that, the functionalities are designed for 80 bytes OP_RETURN. With only 40 bytes OP_RETURN, counterparty are forced to keep using checkmultisig against the benefit of both communities.
reader31
Full Member
***
Offline Offline

Activity: 221
Merit: 100


View Profile
March 24, 2014, 03:37:57 AM
 #6050

I'm soliciting feedback on a forthcoming paper wallet design for Counterparty. Functionality will be identical to my Bitcoin paper wallet design of course: BIP38, provide your own random data (roll dice, etc.) plus ability to scan QR codes with your wallet and such.


You can print out this draft design here:


https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html?design=counterparty


I call this a draft because until the more or less "official" Counterparty logo/branding is announced, I need to keep the logos / colors flexible. However at this point I'm very interested to hear what anyone thinks about how a Counterparty paper wallet should be *different* from a Bitcoin paper wallet. For example, maybe the reverse side instructions should be significantly different. Maybe the reverse side "register" shouldn't just list amount/date, but also "asset" and "description"?


Or I wonder if it makes more sense to leave the look and feel of a Counterparty wallet essentially identical to a Bitcoin paper wallet, only adding a "XCP" logo or something to indicate that XCP are stored in this wallet as well?













Very good!Cool!

Cooperation please between BTC and XCP!




Great Job! Love where this is going Smiley

sherlock421
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
March 24, 2014, 07:28:39 AM
 #6051

i suggest burn LTC once again,then XCP team can burn more ltc,you can sell this buring for R & D funding,and if bitcoin have problem,then can use LTC block chain for Reduce risk
freedomfighter
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
March 24, 2014, 07:45:17 AM
 #6052

People are looking at the situation as saying "Bitcoin will always be big because it already won" but what isn't appreciated is that in open source, the competition never ends because there is no lock-in.
That's where our views differ.

I have no doubt Bitcoin will become really massive no matter the attitude of BTC core developpers. Network effect and infrastructure are everything, you can't beat Winklevoss and Silbert ETF, hardware wallet and 40 petahash with just useful new features. And even if that put BTC developper in a very despicable position of power, it's still a good thing because would BTC one day be overcomed by an altcoin, then the whole concept of digital scarity would be fuck up.

Also Open Transaction will enable a lot of stuff that will add Counterparty-like features on top of Bitcoin, that will happen no matter the amount of energy Bitcoin developpers put into screwing Satoshi's vision.

It's sad but I think the truth is Counterparty have a lot more to lose than Bitcoin if there would be a schism between XCP and BTC.

+1 to the above.

+1 to JG's post. no one should be painting the BTC core dev's in a wide brush. I was very sad to see some of JR's posts but am not taking him to represent the entire BTC community from which I and all of you are also part (even if one has 1 10 or 10000 btc's).

I have been around 100 companies and valuations in the VC arena for 20 years, assisting them at various stages from pre-seed to IPOs and 2nd offerings.

Based on my experience: At this juncture it is actually the first mover advantage and its benefits mainly in network security and in being proven through endless attacks that gives BTC the best chance to be the biggest and brightest not only now but in the future (not to say that there won't be more alternatives). Smart money is now building the BTC eco-system and is bringing numerous applications that will drive adaptation and penetration better. Smart money will feel much safer building around the "monster"(in positive sense) of the space and only engage in new project in limited scopes at this juncture. This is meaningful in my humbled opinion.

While it is true that market capitalization @ $7Bilion is a fraction of the potential for the entire space, BTC was and in my opinion will be the arrowhead in years to come and in bringing the space to the TRILLIONS.

NXT and ETH and others have long ways to go and unfortunately many attacks to overcome. I wish them all the best success but they will take time.  

This is why I am a firm believer in 1) CP being on top of the BTC blockchain 2) in it adding a great value to BTC and contributing to its penetration 3) that the core devs from both projects must find the common ground above and behind the wild kid jr's attitude. "

4) Peter todd's wise words in one of the posts above said it the best: "but remember our real competition isn't each other, it's enormously larger field of centralized finance. I strongly believe that we have far more to gain by working with each other and growing the tiny field of decentralized finance in general then we have to gain by pointless in-fighting.

BTW: I have no doubt that creative solutions will be found for reducing the TPS issue with BTC in the future. In fact, I have seen a presentation in one of the conferences proposing a 50% increase in speed (above my head how) by credible PHDs and researchers. It will come.
sherlock421
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
March 24, 2014, 08:01:06 AM
Last edit: March 25, 2014, 01:22:39 AM by sherlock421
 #6053

http://www.zjcad.com.cn/images/post1.jpghow about this ,it was used
IamNotSure
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500


View Profile
March 24, 2014, 08:18:32 AM
 #6054

About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 24, 2014, 08:20:01 AM
 #6055

About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.

Double the transactions fees ? No guarantee they are confirmed at the same time or even the same block ?

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
dexX7
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile WWW
March 24, 2014, 08:34:20 AM
 #6056

Hey guys,

so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:



(http://i.imgur.com/c9mpd8h.png)

I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:

Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.

In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)


Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead. Smiley

Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1013


View Profile
March 24, 2014, 08:55:06 AM
 #6057

Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead. Smiley

Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.

You're transactions will be cheaper overall too. Again, this is another reason why you want to do an arbitrary encoding strategy. I'm rather solidly booked for the next two weeks, but we can talk about implementing that later as an upgrade.

dexX7
Legendary
*
Offline Offline

Activity: 1106
Merit: 1005



View Profile WWW
March 24, 2014, 09:21:29 AM
Last edit: March 24, 2014, 09:32:09 AM by dexX7
 #6058

Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.

Well yes. That's why I don't understand the "utxo bloat" argument - at least not completely. Assuming each multisig recipient is counted as utxo and say for each redeemed XCP/MSC transaction a new one is spawned, then one could say the total amount of utxo is indeed increased due to the one or two additional multisig recipients. But a) is this the case? (I assume yes) and b) is this the case, if pubkeys are created in a way that they do not form a valid ECDSA point? Anything with a length between 33 and 65 byte seems to be accepted as recipient.

Redeeming multisig outputs is fun, by the way! Wink

amincd
Hero Member
*****
Offline Offline

Activity: 772
Merit: 500


View Profile
March 24, 2014, 10:29:56 AM
 #6059

Whitelisting particular upper layer protocols is ridiculous. Bitcoin should be a proper protocol, not a committee run closed network that you need to file an application with to get access to. Bitcoin the protocol should be absolutely neutral, and no group of developers, no matter how important and respected, should be in a position to determine which transaction types are permitted.

The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.

Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.
Fernandez
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000



View Profile
March 24, 2014, 10:49:46 AM
 #6060

Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.

Well yes. That's why I don't understand the "utxo bloat" argument - at least not completely. Assuming each multisig recipient is counted as utxo and say for each redeemed XCP/MSC transaction a new one is spawned, then one could say the total amount of utxo is indeed increased due to the one or two additional multisig recipients. But a) is this the case? (I assume yes) and b) is this the case, if pubkeys are created in a way that they do not form a valid ECDSA point? Anything with a length between 33 and 65 byte seems to be accepted as recipient.

Redeeming multisig outputs is fun, by the way! Wink

If you don't get it completely, like 99% of the people on this thread, just let the big boys discuss about it, and keep it quiet instead of adding your uneducated 2 cents. Anyone else than PP, Xnova discussing with the core devs is just noise and adding more crap to the already existing confusion.

You are very precious, aren't you? Why are you even here? I thought you had dumped all and went to get some Ether.

Having 200 non technical people trying to protect their 2 burnt BTC insulting the BTC devs and adding their irrelevant 2 cents is the way to go, definitely.

Back to reality, no one from the core devs has been consulted, and they can get rid of the 'XCP parasite' in one commit if they want.

It was an interesting project, with talented devs, but the greed and overall retardness of the so called 'community' on top of the terrible lack of communication in general was the last nail in the coffin.

Time to dump until the news spreads, and move to something else. Thanks for the five folds profit. Hopefully Ether or whatever will make things right, control their community, and have a clear communication with all people involved.






██████████████████████████████████████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████████▄▄▄███████████████████████
███████████████████████████████████████████████████████████████████████▀▀▀████████████████████████
██████████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████████





...INTRODUCING WAVES........
...ULTIMATE ASSET/CUSTOM TOKEN BLOCKCHAIN PLATFORM...






Pages: « 1 ... 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 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 ... 661 »
  Print  
 
Jump to:  

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!