Bitcoin Forum
September 23, 2017, 07:46:33 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 [982] 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1979921 times)
tvbcof
Legendary
*
Offline Offline

Activity: 2268


View Profile
January 04, 2015, 11:14:12 PM
 #19621

 It doesn't matter how the back-end of a sidechain happens to work, and there are a vast number of possibilities (that's one of the main points of sidechains!)  

if that's how you view SC's then we don't need them.

Looks like you've been reduced to utter babble as best I can tell.  You must have had a peek at my question and it fused your couple dozen neurons together.


Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
January 04, 2015, 11:33:48 PM
 #19622

I gather that there are at least three kinds of interactions that are being discussed:
1. Bitcoins may be somehow be "moved"  from the BTC blockchain to the BDS, who would handle them in some way, and eventually "return" them to the BTC blockchain.  
I'm sorry but these are not sidechains. In this scenario there exist only one blockchain, Bitcoin's, where the units are stored/assigned to wallets and not a secondary blockchain.
Exchanges for example have multiple wallets storing their clients' fund and an internal ledger of ownership that determines how much bitcoins every clients are storing.

Sorry, I was not clear.  The three items I listed are not alternative views of "sidechains", but three independent interaction mechanisms that would together comprise the "sidechains proposal".  (Or perhaps only 1+2, or 1+3 if 2 is superfluous once one has 3).

My understanding is that interactions of type 1 and 2 do not require a change in protocol or in the mining software, and in fact the bitcoin network cannot prevent them.  I suppose that interactions of type 3 (merged mining) would require restructuring of the BCN but no change in the BCP, and each miner would be free to choose which "sidechains" it wants to merge-mine.

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 04, 2015, 11:40:48 PM
 #19623

I said what on the thread that you trimmed Smiley  security...
I though you meant one particular method of doing 100k tps was insecure, not the mere fact of achieving that rate.

Can you explain what about higher transaction rates inherently makes the blockchain less secure?

You probably didnt read what I said about pettycoin, nor the 1hr video where Rusty Russel explains it at a conference.

It is the particular approach to sharding that makes it less secure, to reduce bandwidth.  He proposes to shard it 100 ways and have each node only validate two shards, but mine all 100 via (the other 98 blind assuming the other miners are not cheating, they have a way to prove fraud, so long as no one succeeds to jam them)

Not directly less secure, but indirectly Bitcoin security also relies on decentralisation and that'd be a 15 GB block, and not many people have enough bandwidth to do that.  (And sharding it is also less secure).

Snarks could do something but we cant rely on this yet IMO and I am not sure if they're fast enough to keep up computationally.

Quote from: JustusRanvier
Seems he does not understand what is "100k TPS".

100,000 transactions * 260 bytes * 60 seconds * 60 minutes * 24 hours = 2 246 400 000 000 bytes per day  =  2.25 TB / day
Yes, I can do math.

What's your point?

That if your home computer had to do 2.25TB/day down to be a full node you might not be able to do it, which is a centralising factor.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 04, 2015, 11:53:05 PM
 #19624

Quote from: adam3us
With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes there too, so they release the funds to the address the return peg tells them to.

Ok, this is new info to all of here who assumed federated server implementations of SC's were just that, server based only,  without blockchains. This sounds more like a Ripple type system with gateways and a blockchain.  

Yeah  you know now you point it out, that is not super clear in the appendix A (that the thing being protocol adapted is a full side-chain), it justs says

"The key observation is that any enhancement to Bitcoin Script can be implemented externally by
having a trusted federation of mutually distrusting functionaries13 evaluate the script and accept by
signing for an ordinary multisignature script. That is, the functionaries act as a protocol adaptor by
evaluating the same rules we would have wanted Bitcoin to evaluate, but cannot for lack of script
enhancements. Using this we can achieve a federated peg."

I did say earlier protocol adaptor but I see in hindsight "insufficient information"!

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 05, 2015, 12:09:28 AM
 #19625

There are many brilliant people working on crypto technologies, but they are so in love with the technology and with their own ideas, they neglect to consider how their academic, theoretical work may apply to the world of finance. After all, bitcoin directly relates to finance.

I agree, and have had that discussion with a number of people on this, with me doing the pointing out.  We have some advisors/investors who know a thing or two about finance & economics.  We plan hire an economist and/or finance wizard (who can be trusted!) in due course.

Quote from: MarketNeutral
At this point, I think it's very important for people working on Bitcoin, sidechains, and all blockchain-related technologies, whatever they may be, to clearly state in lay terms WHY their work is important and necessary, which is to say, what problems their proposed solutions solve. Satoshi was very good at this.

The thread is kind of long, but it was explained at some point that the problem is it is hard to change code with $ billions of irrescindable ecash sitting on it so core changes have focussed on maintenance, cleanup refactoring, security as well as the odd new feature.  There are many features people would like to have, even including basic needed features, that can not realistically be included into bitcoin-main, or not any time soon, some examples being zerocash, snark-contracts, high volume micropayments, native issued assets at least without some environment to gain an understanding of their behavior.  Similarly its difficult to do hard-forks (major upgrade) because there is no live-beta mechanism.  The sidechain was proposed to solve this set of problems.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 05, 2015, 12:30:44 AM
 #19626


And confirmed by Odalv, your partner in crime.

You are so confused. :-)

actually i think you are incredibly confused since you're trying to secure all these supposed federated server SC's you claim are running with minimal MM'ing.  you should let me know where these are located so i can go perform a 51% and destroy them  Grin

You do not understand tech. :-)
 - 1 timestamp is equal to 100% MM
 - SC can use POS or login to central server ... I really do not need to share my blockchain with 7B unknown people. (I work together with only few people, and do shopping in less than 100 local shops )

i think you do not understand SC's OR Bitcoin. :-)

there is no reason for a private coalition of central servers to adopt a blockchain to secure its data.  it's a waste and insecure.  let's say you have 10 centralized server businesses (federated servers) in your local area securing your blockchain and with whom you do business.  one of them, unbeknownst to you, is the head of Discus Fish.  once your local blockchain acquires enough scBTC, one day you'll wake up and they will be all gone.
Odalv
Legendary
*
Offline Offline

Activity: 1204



View Profile
January 05, 2015, 12:48:30 AM
 #19627


And confirmed by Odalv, your partner in crime.

You are so confused. :-)

actually i think you are incredibly confused since you're trying to secure all these supposed federated server SC's you claim are running with minimal MM'ing.  you should let me know where these are located so i can go perform a 51% and destroy them  Grin

You do not understand tech. :-)
 - 1 timestamp is equal to 100% MM
 - SC can use POS or login to central server ... I really do not need to share my blockchain with 7B unknown people. (I work together with only few people, and do shopping in less than 100 local shops )

i think you do not understand SC's OR Bitcoin. :-)

there is no reason for a private coalition of central servers to adopt a blockchain to secure its data.  it's a waste and insecure.  let's say you have 10 centralized server businesses (federated servers) in your local area securing your blockchain and with whom you do business.  one of them, unbeknownst to you, is the head of Discus Fish.  once your local blockchain acquires enough scBTC, one day you'll wake up and they will be all gone.

It is not possible because I'll hire you as my personal SC advisor.

Edit:
And we will siphon all bitcoin from Discus Fish into my SC. :-)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 05, 2015, 01:01:42 AM
 #19628


And confirmed by Odalv, your partner in crime.

You are so confused. :-)

actually i think you are incredibly confused since you're trying to secure all these supposed federated server SC's you claim are running with minimal MM'ing.  you should let me know where these are located so i can go perform a 51% and destroy them  Grin

You do not understand tech. :-)
 - 1 timestamp is equal to 100% MM
 - SC can use POS or login to central server ... I really do not need to share my blockchain with 7B unknown people. (I work together with only few people, and do shopping in less than 100 local shops )

i think you do not understand SC's OR Bitcoin. :-)

there is no reason for a private coalition of central servers to adopt a blockchain to secure its data.  it's a waste and insecure.  let's say you have 10 centralized server businesses (federated servers) in your local area securing your blockchain and with whom you do business.  one of them, unbeknownst to you, is the head of Discus Fish.  once your local blockchain acquires enough scBTC, one day you'll wake up and they will be all gone.

It is not possible because I'll hire you as my personal SC advisor.

Edit:
And we will siphon all bitcoin from Discus Fish into my SC. :-)

no offense, but it is difficult talking to you about this with all the sarcasm. 

Adam, is there a problem with my logic?
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
January 05, 2015, 01:43:20 AM
 #19629

There are many brilliant people working on crypto technologies, but they are so in love with the technology and with their own ideas, they neglect to consider how their academic, theoretical work may apply to the world of finance. After all, bitcoin directly relates to finance.

I agree, and have had that discussion with a number of people on this, with me doing the pointing out.  We have some advisors/investors who know a thing or two about finance & economics.  We plan hire an economist and/or finance wizard (who can be trusted!) in due course.

Quote from: MarketNeutral
At this point, I think it's very important for people working on Bitcoin, sidechains, and all blockchain-related technologies, whatever they may be, to clearly state in lay terms WHY their work is important and necessary, which is to say, what problems their proposed solutions solve. Satoshi was very good at this.

The thread is kind of long, but it was explained at some point that the problem is it is hard to change code with $ billions of irrescindable ecash sitting on it so core changes have focussed on maintenance, cleanup refactoring, security as well as the odd new feature.  There are many features people would like to have, even including basic needed features, that can not realistically be included into bitcoin-main, or not any time soon, some examples being zerocash, snark-contracts, high volume micropayments, native issued assets at least without some environment to gain an understanding of their behavior.  Similarly its difficult to do hard-forks (major upgrade) because there is no live-beta mechanism.  The sidechain was proposed to solve this set of problems.

Adam


Keep up the great work, Adam.
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
January 05, 2015, 04:56:12 AM
 #19630


That if your home computer had to do 2.25TB/day down to be a full node you might not be able to do it, which is a centralising factor.

Adam

Lets put problems in perspective, when I'm faced with the problem of managing 2.2TB/day in Bitcoin tx's the value stored in my 10 BTC that I've held onto all this time will take my hobby to a whole new level.

Building that data storage system would be a labour of love many will do it just to make sure there 10 BTC are secure.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
January 05, 2015, 05:12:52 AM
 #19631


That if your home computer had to do 2.25TB/day down to be a full node you might not be able to do it, which is a centralising factor.

Adam

Lets put problems in perspective, when I'm faced with the problem of managing 2.2TB/day in Bitcoin tx's the value stored in my 10 BTC that I've held onto all this time will take my hobby to a whole new level.

Building that data storage system would be a labour of love many will do it just to make sure there 10 BTC are secure.

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
January 05, 2015, 05:28:05 AM
 #19632


That if your home computer had to do 2.25TB/day down to be a full node you might not be able to do it, which is a centralising factor.

Adam

Lets put problems in perspective, when I'm faced with the problem of managing 2.2TB/day in Bitcoin tx's the value stored in my 10 BTC that I've held onto all this time will take my hobby to a whole new level.

Building that data storage system would be a labour of love many will do it just to make sure there 10 BTC are secure.

Exactly.
And, the demand to support 100k TPS will not happen anytime soon, maybe two or three decades from now. I remember, about 1990, buying 30MB hard disk drives and thinking they held a lot of data. 2TB is common today, and by the 2030s high density optical data storage could be standard:

Quote
In this paper, we present a review of the recent advancements in nanophotonics-enabled optical storage techniques. Particularly, we offer our perspective of using them as optical storage arrays for next-generation exabyte data centers.
http://www.nature.com/lsa/journal/v3/n5/full/lsa201458a.html

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

STT
Legendary
*
Online Online

Activity: 1484


¯\_(ツ)_/¯


View Profile WWW
January 05, 2015, 05:32:02 AM
 #19633

Two terabytes of data has a cost of transportation to it, there has to be some feedback into the coin at some point.    It would not be worth propagating that data without a decent set worth like bitcoin has, alot of the side chain coins arent really worth much so how could they be mixed in at some cost like this

smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
January 05, 2015, 05:36:50 AM
 #19634

2TB is common today

Make that 4 TB while you weren't paying attention.

http://www.newegg.com/Product/Product.aspx?Item=N82E16822178338

6 and 8 TB are also available, but more expensive. 12 TB coming in a few weeks.
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
January 05, 2015, 05:47:29 AM
 #19635

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half. 

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool.  The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
January 05, 2015, 06:10:13 AM
 #19636

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half.  

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool.  The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block.  

Yes, but "simply" is an understatement. Real-time tx cross the network uniformly, with enormous capacity already available, perhaps 1000 TPS. It is block propagation which is time critical where milliseconds count. When a block is solved the rest of the mining network is then hashing uselessly until the block is fully propagated. Incentives are perverse, against large blocks which are ultimately needed to fund the network via fees rather than rewards. Removing the bottleneck for block propagation is a huge win for scaling Bitcoin.

Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
January 05, 2015, 06:11:30 AM
 #19637

Please let me try again to spread my ignorance about sidechains.  Grin

Perhaps the sidechains project could be renamed "ways in which the bitcoin network (BCN) can interact with other internet services, and how the bitcoin protocol (BCP) would have to be modified to allow them".  These "other services" being the "sidechains".

Different people have different ideas of what sort of services would qualify for "sidechains", but let's not focus on that, focus instead on the interactions.  In order to exclude those variable assumptions, I will use the term "bitcoin-dependent service" (BDS) instead of "sidechain".

I gather that there are at least three kinds of interactions that are being discussed:

1. Bitcoins may be somehow be "moved"  from the BTC blockchain to the BDS, who would handle them in some way, and eventually "return" them to the BTC blockchain.  
...

2. The BDS may exploit the power of the BCN to secure its data structures against tampering or rewind
...
  
3. The BDS could use the full power of the BCN to implement its own PoW mechanisms by merged mining
...

  
Does this make any sense?


As you put

1. Mnt Gox, can run off with one's Bitcoin or a Bank or service could function on fractional reserves untill there is a confidence call and a proverbial run on the bank.

2. Is not necessarily parasitic, if it claims to be a better money sure it's 100% parasitic, there are other ways to achieve the same security one eg. Open Transaction with federated oracles. But any innovative multisig decentralized authoring system could achieve this with no change to the BCP.

3. MM is a good idea, while it limits innovation to just PoW, it can tap into the sea of hashing that goes to waste.

The way BlockStream has proposed to manage what you call BDS is to have in principal the multisig authorizing of Bitcoin transactions in and out of different secured ledgers, this will alow miners to MM BDS's in exchange for a token that is guaranteed to be redeemable in BTC by the BCP.

The perversion is miners could MM a BDS earn additional Bitcoin, without being forced to mine on the BCP or use there hashing power to protect the BCN.

MM = GOOD, but MM for BTC* is an attack at the very incentives that protect the BCN.

*MM alts are subject to market force, so while you can exchange them for BTC, the BCN is unaffected by them, if they gain value it will be a utilitarian value unsupported by the BCN, and thus just grow the ecosystem, otherwise it will shrivel and die as a scam. 

MM a BDS that gives a token that is redeemable for BTC regardless of market rates allows miners to earn BTC equivalent tokens without contributing there hashing power (securing the Bitcoin blockchain) on the BCN, or any work to the greater economy. I.e. it has similar characteristics to our financial system today. What changes is just trust the central bank now becomes just trust the protocol. Making a change to the BCP to alow this is evil at the core.
 
Your conclusion is correct but I'm not sure how deep your understanding is, miners can manipulate (by mining empty blocks in the BDS or the BCN, controlling the flow of BTC and herding markets and controlling money flow, even restricting money supply on demand.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 05, 2015, 06:14:39 AM
 #19638

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half.  

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool.  The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block.  

Yes, but "simply" is an understatement. Real-time tx cross the network uniformly, with enormous capacity already available, perhaps 1000 TPS. It is block propagation which is time critical where milliseconds count. When a block is solved the rest of the mining network is then hashing uselessly until the block is fully propagated. Incentives are perverse, against large blocks which are ultimately needed to fund the network via fees rather than rewards. Removing the bottleneck for block propagation is a huge win for scaling Bitcoin.

how does the IBLT scale with the size of the block UTXO set?  linearly or by some other ratio?

edit:  actually iirc, it scales with the size of the difference btwn UTXO set estimates across the network.  iow, a UTXO set estimated to be 99% similar across the network will allow a miner to send a smaller IBLT when solving a block than a UTXO set estimated to be only 89% similar across the network.  is that right?
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
January 05, 2015, 06:17:45 AM
 #19639

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half.  

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool.  The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block.  

Yes, but "simply" is a massive understatement. Real-time tx cross the network uniformly, with enormous capacity already available, perhaps 1000 TPS. It is block propagation which is time critical where milliseconds count. When a block is solved the rest of the mining network is then hashing uselessly until the block is fully propagated. Incentives are perverse, against large blocks which are ultimately needed to fund the network via fees rather than rewards. Removing the bottleneck for block propagation is a huge win for scaling Bitcoin.

Agreed.  I didn't mean to understate the importance of IBLTs; I just wanted to point out for readers that IBLTs only improve block propagation (still an important problem) … and that each TX still needs to be processed by each node (linear BW scaling with TX/sec).  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
January 05, 2015, 06:23:35 AM
 #19640

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half. 

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool.  The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block. 
Good point, I'd be more open to distributing the network tragic in a manner similar to the way SideChain would manage it when we have to manage that type of bandwidth.

From my perspective as things stand today the proposed SC change to the Bitcoin protocol has more risk than benefit.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Pages: « 1 ... 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 [982] 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 ... 1558 »
  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!