Bitcoin Forum
October 22, 2018, 11:15:09 AM *
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  
Pages: [1] 2 »  All
  Print  
Author Topic: What are the steps to take to publish the solution for blockchain scaling?  (Read 210 times)
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 10:04:41 AM
 #1

Hey everyone,

I have fixed the blockchain scaling issue. I am creating a network with the necessary fixes in place. I am also writing a paper so everyone can understand the fix. Please advise what are the further steps to take from here.

My vision is to build a Value Network so that everyone can have access to micropayments and to create a society where people are motivated to add value by means of scientific inventions.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1540206909
Hero Member
*
Offline Offline

Posts: 1540206909

View Profile Personal Message (Offline)

Ignore
1540206909
Reply with quote  #2

1540206909
Report to moderator
1540206909
Hero Member
*
Offline Offline

Posts: 1540206909

View Profile Personal Message (Offline)

Ignore
1540206909
Reply with quote  #2

1540206909
Report to moderator
1540206909
Hero Member
*
Offline Offline

Posts: 1540206909

View Profile Personal Message (Offline)

Ignore
1540206909
Reply with quote  #2

1540206909
Report to moderator
aleksej996
Sr. Member
****
Offline Offline

Activity: 420
Merit: 311


Do not trust the government


View Profile WWW
September 09, 2018, 10:55:01 AM
 #2

There was never an issue with figuring out the way to scale a blockchain, there was just a debate on which solution we will implement.
That debate resulted in a fork as people couldn't agree.

I am glad that you have another solution, but this is a 'problem' that even Satoshi gave a simple solution for.
It is a kinda of a virtual problem, not a natural one. The block limit was purposely implemented for spam protection.
So it is very simple if you just want to solve it simplest and quickest way possible, but off-chain solution ended up being followed by most.

░░░░░░░▄▄▄▄▄▄
░░░░▄██████████▄
░░░██████████████
░░██████▐▌██████
█████░░░░░░░▀█████
██████▄▄░░▄▄░░██████
████████░░▀▀▄██████
████████░░▄▄▄░░█████
██████▀▀░░▀▀▀░░█████
█████░░░░░░░░█████
░░██████▐▌██████
░░░██████████████
░░░░▀██████████▀
░░░░░░░▀▀▀▀▀▀
░░░

                   BitCloak Bitcoin Mixer  
  BTC & BCH | API| MULTIADDRESS| PGP PROOF|  FAST MIX |  ESCROW|  MORE !

░░░░░░░▄▄▄▄▄▄
░░░░▄██████████▄
░░░██████████████
░░██████▐▌██████
█████░░░░░░░▀█████
██████▄▄░░▄▄░░██████
████████░░▀▀▄██████
████████░░▄▄▄░░█████
██████▀▀░░▀▀▀░░█████
█████░░░░░░░░█████
░░██████▐▌██████
░░░██████████████
░░░░▀██████████▀
░░░░░░░▀▀▀▀▀▀
░░░

vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 12:20:31 PM
 #3

Hello aleksej996,

Glad to see you post here. I appreciate you sharing your points.

 I am talking about scaling payments and data to millions of transactions per second without any "Central validator hub". I am not aware of any present solution that does the same. The lightning network works only in theory because it still needs everyone to be in a payment channel with someone. Just writing those "LOCKED" payment channels requires a lot of on-chain space.

I have a solution which I have been working on for quite some time which solves the scalability trilemma.
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 12:32:40 PM
 #4

I am glad that you have another solution, but this is a 'problem' that even Satoshi gave a simple solution for.
It is a kinda of a virtual problem, not a natural one. The block limit was purposely implemented for spam protection.
So it is very simple if you just want to solve it simplest and quickest way possible, but off-chain solution ended up being followed by most.

Here's my view for your statement. If 10 billion people in the world used blockchain for payments. That's at least a million transactions a second. Currently, the Blocksize is 1 MB. If the minimum BTC transaction size is 250 bytes.  ~4,000 transactions per block. That's 6.66 Transactions per second.

I have a solution (proof of concept in GoLang) which scales up to 1M transactions per second with a smaller block size without compromising on decentralization / security / future scalability.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1470
Merit: 1208


Use SegWit and enjoy lower fees


View Profile WWW
September 09, 2018, 01:03:19 PM
 #5

Please advise what are the further steps to take from here.

Release your whitepaper and make sure someone do peer review on your paper. Release it on it's own testnet or release the source code also helps.

There was never an issue with figuring out the way to scale a blockchain, there was just a debate on which solution we will implement.
That debate resulted in a fork as people couldn't agree.

I disagree since there's few lazy scaling solution such as only increase maximum block size limit while others try to decrease TX size, move it to off-chain/2nd layer or make nodes not verify all transaction.

The lightning network works only in theory because it still needs everyone to be in a payment channel with someone. Just writing those "LOCKED" payment channels requires a lot of on-chain space.

You mention LN's disadvantage, not why it only works on theory since LN already used on both testnet and mainnet.

I am glad that you have another solution, but this is a 'problem' that even Satoshi gave a simple solution for.
It is a kinda of a virtual problem, not a natural one. The block limit was purposely implemented for spam protection.
So it is very simple if you just want to solve it simplest and quickest way possible, but off-chain solution ended up being followed by most.

Here's my view for your statement. If 10 billion people in the world used blockchain for payments. That's at least a million transactions a second. Currently, the Blocksize is 1 MB. If the minimum BTC transaction size is 250 bytes.  ~4,000 transactions per block. That's 6.66 Transactions per second.

I have a solution (proof of concept in GoLang) which scales up to 1M transactions per second with a smaller block size without compromising on decentralization / security / future scalability.

Assuming current block size is 1MB (which isn't because we use block weight limit with 4 kWu limit) or AFAIK 1.000.000 bytes in reality, then that means 1 transaction only have size about 1 byte and i can't see how would you fit transaction (input, output and signature). But i've no idea about GoLang.

███           ▄▄▄                          ███
███           ███    ▄█                    ███
███ ▄▄▄▄▄▄          ▄██▄▄▄▄      ▄▄▄▄▄     ███        ▄██▄    ▄▄▄         ▄▄▄
███████████▄  ███ ▐████████  ██▄███████▄   ███       ██████    ███       ███▀
███▀    ▀███▌ ███   ███      ███▀    ▀███  ███      ████████    ███     ███▀
███      ▐██▌ ███   ███      ███      ███  ███     ██▀    ▀██    ███   ███▀
███      ▐██▌ ███   ███      ███      ███  ███    ███      ███    ███ ███▀
███▄    ▄███▌ ███   ███▄     ███▄    ▄███  ███   ████▄    ▄████    █████▀
███████████▀  ███   ▀██████  ███████████▀  ███  ████████████████    ███▀
▀▀▀ ▀▀▀▀▀▀    ▀▀▀     ▀▀▀▀▀  ███ ▀▀▀▀▀▀    ▀▀▀   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀    ███▀
                             ███       ▄▄▄ ▄   ▄  ▄ ▄▄▄          ▄███▀
                             ███      █    █   █  █ █▄▄▀      █████▀
                             ▀▀▀      ▀▄▄▄ █▄▄ ▀▄▄▀ █▄▄█      ▀▀▀















❱❱
❰❰

vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 01:33:26 PM
 #6

Hey ETFbitcoin,

Thank you for taking the time to post.


Release your whitepaper and make sure someone do peer review on your paper. Release it on it's own testnet or release the source code also helps.

I am going to do exactly that. I have the proof of concept stress tested.  Will be publishing the white paper within a month and releasing the test network within 2 months and main network within 3 months.

It would be great if you can do a peer review too and point to the issues I have so that I can improve upon thigs. Of course this system also comes with a Turing complete VM and I am planning to run the entire project as a smart contract with tokens issued in a DAO style to anyone who adds value. Will share the business plan and other stuff at a later stage after the white paper is ready.

You mention LN's disadvantage, not why it only works on theory since LN already used on both testnet and mainnet.

Yes, thanks for correcting me. What I meant was that it works only in theory for "unlimited scaling".

Assuming current block size is 1MB (which isn't because we use block weight limit with 4 kWu limit) or AFAIK 1.000.000 bytes in reality, then that means 1 transaction only have size about 1 byte and i can't see how would you fit transaction (input, output and signature). But i've no idea about GoLang.

ETFbitcoin, It has nothing to do with GoLang. Data is data everywhere. My solution algorithm reaches sharding consensus with infinitesimally low failure rate and extremely high fault tolerance.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2534
Merit: 1550



View Profile
September 09, 2018, 02:33:49 PM
 #7

The block limit was purposely implemented for spam protection
This claim has is just one of the pieces of unsupported nonsense pumped out by paid shills, it's so sad that so many people have just accepted it because of the number of sock accounts that have constantly repeated it. Sad

As far as the thread goes, many people have made similar claims before. Their proposals have inevitably turned out to banal rehashings of more or less obvious ideas that the Bitcoin community considered and rejected as far back as 2010 because they don't respect some critical element of what makes Bitcoin Bitcoin that the proposer themselves wasn't aware of as a result of so much bitcoin promotional material giving an incomplete view of the system. The most common things I've seen such proposals do is introduce unfounded third party trust (usually in miners, sometimes in other random node operators) and in doing so eliminate the system's trustlessness.

Regardless, instead of saying that you have an idea that achieves some grand effect, you should simply publish the idea.  Crowing about it just burns your and everyone elses time without making the world a better place or having an opportunity to improve your understanding.


Bitcoin will not be compromised
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 02:46:08 PM
 #8


As far as the thread goes, many people have made similar claims before. Their proposals have inevitably turned out to banal rehashings of more or less obvious ideas that the Bitcoin community considered and rejected as far back as 2010 because they don't respect some critical element of what makes Bitcoin Bitcoin that the proposer themselves wasn't aware of as a result of so much bitcoin promotional material giving an incomplete view of the system. The most common things I've seen such proposals do is introduce unfounded third-party trust (usually in miners, sometimes in other random node operators) and in doing so eliminate the system's trustlessness.

Regardless, instead of saying that you have an idea that achieves some grand effect, you should simply publish the idea.  Crowing about it just burns your and everyone else's time without making the world a better place or having an opportunity to improve your understanding.


Agreed. I will be publishing my paper very shortly in this same thread.

Gmaxwell, since you seem to be an old hand. Let me convince you super quick as to how the solution works.

Important statement #1 :

Ask yourself from a 40,000 feet view.

What is a currency?

A currency is something that is pegged to a base value Like Gold. All the scaling issues of blockchains start at the coin base. Since PoW is NOT reusable, one simply has to issue a coin base equal to the amount of work that they have performed.

For eg. Let's assume the base target is 100. If someone finds a nonce to create a hash that has a target below 100, he's issued let's say 1 coin. If someone spends double the amount of hash power, they have to be issued 2 coins. i.e. the coin base shouldn't be fixed. What this means is that all chains following this consensus have an equal store of value hence facilitating inter-chain transfers at face value.
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 02:54:29 PM
 #9

Here's some more info that I have quickly typed in for you to look at :

The fix is simple.

Bitcoin has solved most of the puzzle with blockchain.

We simply propose a few fixes :

1) The coin value should be directly pegged to the issuance of the coins. Which means the coin base transaction should be equal to the difficulty factor of the target that's met.

For eg. If the target should be less than 100,000 - then one coin shall be issued.

If the target is less than 50,000 - then two coins shall be issued in the coin base.

This way multiple chains are equal. Given this. People can move accounts and transfer money between different chains.

Any chain with a proof of work chain is valid and it's easy to estimate the amount of value in them.

How do we prevent double spend?

Remember, the proof of Work is actually a timestamp and a sure way to measure time. To achieve decentralized consensus, we simply accept the chain as valid which holds in a section of its headers - the full sequence of the mother chains' timestamps (block hashes). I have a specific algorithm which measures the trustability of a chain. Will be releasing it along with the reference client.
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 03:02:16 PM
 #10


Regardless, instead of saying that you have an idea that achieves some grand effect, you should simply publish the idea.  Crowing about it just burns your and everyone elses time without making the world a better place or having an opportunity to improve your understanding.


I am going to try and publish the paper in the coming week along with a proof of concept test network. Will publish the source code for that so that maybe you can then provide me detailed feedback.
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 09, 2018, 03:26:34 PM
 #11

A quick example image that I made with draw.io to explain my views.

https://pasteboard.co/HD6ALBV.png
Anonymous Kid
Member
**
Offline Offline

Activity: 170
Merit: 18


View Profile
September 11, 2018, 06:59:57 PM
 #12

A quick example image that I made with draw.io to explain my views.


Does this not mean that the main chain or "monster chain" as you called it would get insanely big? How does that scale?
vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 12, 2018, 07:28:05 AM
 #13

It doesn't become big. There's more details involved which will I will publish in my paper. I just gave a quick overview. If you are a developer, you are welcome to join me in coding the reference client if you will be interested and I can provide you more information.
aleksej996
Sr. Member
****
Offline Offline

Activity: 420
Merit: 311


Do not trust the government


View Profile WWW
September 12, 2018, 10:06:53 AM
 #14

This claim has is just one of the pieces of unsupported nonsense pumped out by paid shills, it's so sad that so many people have just accepted it because of the number of sock accounts that have constantly repeated it. Sad

Well this is very surprising to me.
If it wasn't for stopping the blockchain of getting too big, why was it implemented then?

░░░░░░░▄▄▄▄▄▄
░░░░▄██████████▄
░░░██████████████
░░██████▐▌██████
█████░░░░░░░▀█████
██████▄▄░░▄▄░░██████
████████░░▀▀▄██████
████████░░▄▄▄░░█████
██████▀▀░░▀▀▀░░█████
█████░░░░░░░░█████
░░██████▐▌██████
░░░██████████████
░░░░▀██████████▀
░░░░░░░▀▀▀▀▀▀
░░░

                   BitCloak Bitcoin Mixer  
  BTC & BCH | API| MULTIADDRESS| PGP PROOF|  FAST MIX |  ESCROW|  MORE !

░░░░░░░▄▄▄▄▄▄
░░░░▄██████████▄
░░░██████████████
░░██████▐▌██████
█████░░░░░░░▀█████
██████▄▄░░▄▄░░██████
████████░░▀▀▄██████
████████░░▄▄▄░░█████
██████▀▀░░▀▀▀░░█████
█████░░░░░░░░█████
░░██████▐▌██████
░░░██████████████
░░░░▀██████████▀
░░░░░░░▀▀▀▀▀▀
░░░

vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 12, 2018, 11:25:42 AM
 #15

This claim has is just one of the pieces of unsupported nonsense pumped out by paid shills, it's so sad that so many people have just accepted it because of the number of sock accounts that have constantly repeated it. Sad

Well this is very surprising to me.
If it wasn't for stopping the blockchain of getting too big, why was it implemented then?

I am not completely sure of the motivation behind that decision.

If I were to guess, Satoshi probably implemented that block size limit so that it allows for guaranteed full propagation to all the nodes regardless of their geographic location and latency before the 10 minute interval kicks in, so the nodes have enough time to at least easily verify a block and hence be ready to validate the next one.
Piggy
Hero Member
*****
Online Online

Activity: 518
Merit: 921



View Profile WWW
September 14, 2018, 04:39:37 AM
 #16

vinodjax, could you please tell what is your background, what do you do? Is this work your are doing is something related with your job, a side project or something else?

In any case i'm waiting to see what you came up with.  Smiley

vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 14, 2018, 09:20:10 AM
 #17

vinodjax, could you please tell what is your background, what do you do? Is this work your are doing is something related with your job, a side project or something else?

In any case i'm waiting to see what you came up with.  Smiley

I am a software enthusiast / IT security enthusiast turned into an entrepreneur (gaming/casino industry). I am the founder of a multi-million dollar gaming brand. (at least valued at $10m using a 3x revenue valuation formula.

Our casino brands for the Indian market are :

www.khelo365.com
www.deccanrummy.com

Like I said, I have not worked for anyone. Fixing the blockchain scaling problem is what I have been working on for the last 4 months.

Sure, Once I publish the paper, you will understand my concept.

Our vision is to build a payment processor that scales for millions of transactions per second using blockchain technology where we issue a currency underwritten by CPU Power.
aliashraf
Sr. Member
****
Online Online

Activity: 602
Merit: 372


View Profile
September 14, 2018, 09:48:05 AM
 #18


1) The coin value should be directly pegged to the issuance of the coins. Which means the coin base transaction should be equal to the difficulty factor of the target that's met.

For eg. If the target should be less than 100,000 - then one coin shall be issued.

If the target is less than 50,000 - then two coins shall be issued in the coin base.

This way multiple chains are equal. Given this. People can move accounts and transfer money between different chains.

Any chain with a proof of work chain is valid and it's easy to estimate the amount of value in them.
It seems to me a kinda chaotic version of my own proposal PoCW. I say chaotic because it is more deconstructional and we should deal with a whole new data structure which is more complex than what is used in legacy blockchain. This is definitively a disadvantage: More sophisticated the model less predictable and more error prone it is.

As of the basic idea, rewarding miners proportional to their blocks' difficulty which is relatively similar to what I  suggested in PoCW, obviously I admire it.

Few questions by the way:
1- How is it possible to keep track of difficulty and total coin supply?

2- Full nodes should validate all chains for inter-chain transactions. How this is handled?

3- Immutability of a confirmed transaction on the blockchain is not guaranteed only by the work done on the containing block it is achieved by total work of all of the next blocks in the chain. Dividing work between sub-chains escalates re-write attacks on weak chains. What's your mitigation?

vinodjax
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
September 14, 2018, 11:17:44 AM
 #19


1) The coin value should be directly pegged to the issuance of the coins. Which means the coin base transaction should be equal to the difficulty factor of the target that's met.

For eg. If the target should be less than 100,000 - then one coin shall be issued.

If the target is less than 50,000 - then two coins shall be issued in the coin base.

This way multiple chains are equal. Given this. People can move accounts and transfer money between different chains.

Any chain with a proof of work chain is valid and it's easy to estimate the amount of value in them.
It seems to me a kinda chaotic version of my own proposal PoCW. I say chaotic because it is more deconstructional and we should deal with a whole new data structure which is more complex than what is used in legacy blockchain. This is definitively a disadvantage: More sophisticated the model less predictable and more error prone it is.

As of the basic idea, rewarding miners proportional to their blocks' difficulty which is relatively similar to what I  suggested in PoCW, obviously I admire it.

Few questions by the way:
1- How is it possible to keep track of difficulty and total coin supply?

2- Full nodes should validate all chains for inter-chain transactions. How this is handled?

3- Immutability of a confirmed transaction on the blockchain is not guaranteed only by the work done on the containing block it is achieved by total work of all of the next blocks in the chain. Dividing work between sub-chains escalates re-write attacks on weak chains. What's your mitigation?




As of the basic idea, rewarding miners proportional to their blocks' difficulty which is relatively similar to what I  suggested in PoCW, obviously I admire it.

The purpose of technology is to help mankind and not the other way around. So, if it has to come down to redoing the entire data structure or coming up with a fresh perspective, as long as it solves the problem of scaling transactions in an immutable and decentralized way, it should be fine. Nothing is Chaotic.


As of the basic idea, rewarding miners proportional to their blocks' difficulty which is relatively similar to what I  suggested in PoCW, obviously I admire it.

Interesting, I would like to look more deeply into your proposal if you can share with me the links to your concept.

1- How is it possible to keep track of difficulty and total coin supply?

You don't need to. You simply set it as a hardcoded value as part of the consensus protocol. Let's say the base target is 1,000,000 which requires 1 Th/s to compute a hash lower than 1,000,000.

Then, let's say: a hash generation for base target achievement rewards 100 coins.

If someone computes a hash lesser than a target of 500,000, assuming it takes 2 Th/s, then you simply reward them 200 coins.

This way just by looking at the hashes, you can compute the difficulty of the chain and the total coin supply. Also, you can add uncle features like in ethereum so that you can have lesser block times and more ways of calculating the heaviest chain.

To briefly answer your question, you can keep track of difficulty from the adjusted targets. You can keep track of the coin supply simply by figuring out how difficult of a hash was found. If the hash is a multiple of a base target, issue them x number of coins.

2- Full nodes should validate all chains for inter-chain transactions. How this is handled?

It's not needed.

Let's say we both have to transfer funds. As long you are getting paid by a transfer agent on your own chain, you don't really need to be worried about how the transfer agent is managing his risk. As long as the transfer agent has a copy of the mother chain and a copy of the daughter chains ( 1- from where he is transferring payments and 2- from where he's transferring payments to)  (OR) payment channels between the different parties involved - he doesn't need to know any more information about any further chains.

The transfer agent simply accepts the heaviest chain as valid (and the most valuable in case of a tie) in his subnetwork (indicated by a separate network ID on the broadcasted messages).

To briefly answer your question, No one needs to verify all the chains. Every block on the daughter chains simply link to the next blockhash of the mother chain in their headers. Hence, everyone just needs a copy of the mother chain and their respective daughter chain to find out the truth in a decentralized fashion. The heaviest, most valuable chain which is time valid (validated by checking the sequence of motherchain block hashes mentioned in the daughter chain) in a subnetwork is assumed to be the true chain.

3- Immutability of a confirmed transaction on the blockchain is not guaranteed only by the work done on the containing block it is achieved by total work of all of the next blocks in the chain. Dividing work between sub-chains escalates re-write attacks on weak chains. What's your mitigation?

Proof of Work is not reusable.

What is stopping 51% attacks on bitcoin? It's simply because miners find more value in writing new blocks and creating coins for themselves instead of distorting an existing system and hence leading to a value in the currency - Not to mention the madness it will take to waste that kind of resources just to rewrite a few blocks with a not so certain outcome. It's called a free market.

Based on my above statement, the root of trust of bitcoin or anything that has to deal with linking to the checksum of blocks from the past comes down to people acting with honesty for profit.

Simply assume that there are a lot of systems out there like Bitcoin Cash, Bitcoin, Ethereum etc. and imagine if anyone could say just looking at their block-hashes, how many coins each miner and hence the entire system would have. That would effectively make all the coins of equal value because they are underwritten by an exact amount of CPU power (given that we also allow uncle blocks). Now, one could make an argument like yours that longer chains and chains with more hash rate are more trusted and their valuations could be higher than the weaker chains. In a free market this simpy means that it's a high risk payment and the transfer agent may charge higher fees for such a transfer. The main person at risk here is the payment transfer agent and this would amount to business risk in a free-market and the respective entities would resolve this. Maybe, the top miners would choose to act as transfer agents.



Note: Give me until the end of this month. I will have a working proof of concept which you can fork and run and stress test the system for yourself.
aliashraf
Sr. Member
****
Online Online

Activity: 602
Merit: 372


View Profile
September 14, 2018, 03:22:19 PM
 #20

Ok dude. I'm looking forward for your next 'steps'.

Meanwhile:
Be more careful with the whole thing. A decentralized, permissionless consensus system is a hell of a software project. Hostile environment, sophisticated state machine, heavy game theory related issues, multiple socio-politico-economical factors involved, ... just take it more serious than a usual software project.

You should reconcile with literature in the field. Many brilliant people have contributed to crypto ecosystem and you can always find precious ideas reading their works.

As of my PoCW proposal, you can find it here.
Pages: [1] 2 »  All
  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!