Bitcoin Forum
November 19, 2017, 01:06:50 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   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 ... 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 [1518] 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2009265 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 01:41:01 PM
 #30341

still rising:

1511096810
Hero Member
*
Offline Offline

Posts: 1511096810

View Profile Personal Message (Offline)

Ignore
1511096810
Reply with quote  #2

1511096810
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511096810
Hero Member
*
Offline Offline

Posts: 1511096810

View Profile Personal Message (Offline)

Ignore
1511096810
Reply with quote  #2

1511096810
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 01:55:04 PM
 #30342

this pretty much sums up Luke-Jr:

[–]bitvote 1 point 16 minutes ago

^ This is a useful comment because it shows the prejudice of u/Luke-jr perspective.

I work for a bitcoin company, get paid in bitcoin, buy many, many things with bitcoin, give bitcoin to friends and family, hodl bitcoin as a speculative investment.

But for u/luke-jr, none of this makes me a bitcoin user.

Which is, on the face of it, absurd. and offensive.

I admit there is value in running a node/mining, but certainly a community that claims to favor freedom should have the ability (and courage) to welcome a diverse range of users, even if they don't meet some arbitrary standard set by an elitist insider.

This comment, more than any other in the blocksize debate so far, reveals the flaw in perspective of the Evolution Deniers. But this is getting ridiculous:

    Redefining what an alt-coin is
    Censoring a main communication platform
    And redefining "bitcoin user" so that less than 1% of bitcoin holders are anointed as 'Real Users'

Enough already. It smells like tyranny, it looks like tyranny - it IS tyranny. And Bitcoin, more than any other community, should overthrow this flawed attempt at governance.

Remember, bitcoin works through Consensus by code. Not consensus by CODERS.

The last two sentences in the white paper: "They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism"

    permalink
    save
    parent
    report
    give gold
    reply


https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn/cu1krds
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 02:05:15 PM
 #30343


but back to this, you and i can't be outliers as much as LukeJr and gmax want everyone to think in terms of bandwidth speed.  we can easily handle a significant block size increase, no problem.



furthermore:

http://arstechnica.co.uk/gadgets/2015/08/samsung-unveils-2-5-inch-16tb-ssd-the-worlds-largest-hard-drive/

i really see no technical reasons why we can't have bigger blocks.  now.
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
August 13, 2015, 02:09:22 PM
 #30344

looks to me like this post by Mike has been taken down off the main page by mods:

https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn/

Perfect. As I said earlier, I don't understand the "hardness" of this fork (bigblocks). Mike Hearn said it better,


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 02:41:04 PM
 #30345

Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
August 13, 2015, 03:02:26 PM
 #30346


but back to this, you and i can't be outliers as much as LukeJr and gmax want everyone to think in terms of bandwidth speed.  we can easily handle a significant block size increase, no problem.



furthermore:

http://arstechnica.co.uk/gadgets/2015/08/samsung-unveils-2-5-inch-16tb-ssd-the-worlds-largest-hard-drive/

i really see no technical reasons why we can't have bigger blocks.  now.

Yeah I think we're past that point in the debate. It's now clear that the concern of those who make the technical claims regarding bandwidth is about ensuring that Bitcoin node-running is an all-inclusive activity. They insist that no one can be left out, or else it's not a "consensus." Well we're being left out right now, aren't we. By their logic we should be able to halt Bitcoin entirely during this debate because they don't have our consensus. There is no internal consistency in the whole "consensus" line of reasoning. It's just a feel-good buzzword except in the very narrow sense that of course a given version of Bitcoin will only operate among those who are currently in consensus. The lack of any mention of market cap or other economic factor during such invocations of consensus should be a red flag.

There are aspects of the debate where intelligent people may disagree, but this part is pure reactionary stalwartism at this point. It doesn't even jive with the fundamental nature of open source software, which makes consensus a fluid concept. At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
August 13, 2015, 03:17:41 PM
 #30347


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

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

Activity: 1764



View Profile
August 13, 2015, 03:34:02 PM
 #30348


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

that's just a re-write of what i've been advocating; lift the limit entirely.

but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu.  i like it.

don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 03:36:30 PM
 #30349


but back to this, you and i can't be outliers as much as LukeJr and gmax want everyone to think in terms of bandwidth speed.  we can easily handle a significant block size increase, no problem.



furthermore:

http://arstechnica.co.uk/gadgets/2015/08/samsung-unveils-2-5-inch-16tb-ssd-the-worlds-largest-hard-drive/

i really see no technical reasons why we can't have bigger blocks.  now.

Yeah I think we're past that point in the debate. It's now clear that the concern of those who make the technical claims regarding bandwidth is about ensuring that Bitcoin node-running is an all-inclusive activity. They insist that no one can be left out, or else it's not a "consensus." Well we're being left out right now, aren't we. By their logic we should be able to halt Bitcoin entirely during this debate because they don't have our consensus. There is no internal consistency in the whole "consensus" line of reasoning. It's just a feel-good buzzword except in the very narrow sense that of course the code will only run among those who are currently in consensus. The lack of any mention of market cap or other economic factor during such invocations of consensus should be a red flag.

There are aspects of the debate where intelligent people may disagree, but this part is pure reactionary stalwartism at this point. It doesn't even jive with the fundamental nature of open source software, which makes consensus a fluid concept. At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

i've flipped the question around to the Cripplecoiner's a few times, as in, what happens if Gavin is the sole dissenter when the need to slip in the spvp for SC's comes around in a year or so?  will they gracefully and quietly back off since they won't have consensus?  the angry answer i get back always sounds like they'll ram it thru anyways.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 03:39:41 PM
 #30350

StarMaged and others vs. theymos, BashCo, etc.?



you may be on to something:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1nlya
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
August 13, 2015, 03:41:31 PM
 #30351


There is no such thing as a store of value.


There is no such thing as a thing.

Separateness is an illusion.  All that exists is the Unified Field and the Void (sort of).

Oh sorry, I thought I was in a late night dorm room session discussing our Epistomology 101 homework, not a thread for adults focused on the practical implications of Gold vs Bitcoin.

Yo dawg, pass that sick glass you got at Pipes Plus over here...   Cheesy

Here's a store of value.



Wow.  That's like totally intense, man!


awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
August 13, 2015, 03:53:42 PM
 #30352


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

YES! See also here: https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/

Instead of a pull down menu, I would favor a free form text field without any default. (For policy neutrality)

Pushes the responsibility and the power to set this limit back to the user - where it belongs.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
August 13, 2015, 03:56:30 PM
 #30353


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

that's just a re-write of what i've been advocating; lift the limit entirely.

but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu.  i like it.

don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.

Yes, you have been essentially advocating the same thing.  

We could take this idea further: in addition to the drop-down menu where node operators and miners select the max block size they'll accept, we could add two new features to improve communication of their decisions:

  1.  The max block size selected by a node would be written into the header of any blocks the node mines.

  2.  The P2P protocol would be extended so that nodes could poll other nodes to find out their block size limit.

This would be a highly decentralized way of coming to consensus in a very flexible and dynamic manner.  

It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:

you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.

The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.

So…is this a good idea?  If there are no obvious "gotchas" then perhaps we should write up a BIP.

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

Activity: 1036


View Profile
August 13, 2015, 03:58:26 PM
 #30354

This is a fundamental disagreement on the value of Bitcoin then which IMO is first SOV then payment network.
There is no such thing as a store of value.

You've described the religious approach to understanding money.

I'd say the term "store of value" has meaning in the context our current world of fiat money, where you need a hedge against inflation. In the case of Bitcoin while it is still not yet mainstream I think a special definition is useful: an asset that retains or grows its purchasing power over the years (particularly in contrast with fiat money), with growth of course being considered even better as a store of value than simply staying level. Also the difficulty in confiscating it should be part of its store-of-value merits.

In world where we were already using gold universally, for example, the concept of "store of value" would probably be unnecessary.

However, reading between the lines, I assume your larger point here is that these "store of value" properties rely on Bitcoin being a payment network, too, so there is no clean line where we can say, "For now Bitcoin is only an SoV, so the number of transactions people could use it for doesn't matter." Since the SoV (especially the growth aspect) in the present day owes largely to the investment premise that Bitcoin *will become* a major payment network for the world in the future, the transaction capacity going forward is a key determiner of current price upside and therefore a pivotal element of its SoV properties.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
August 13, 2015, 04:00:27 PM
 #30355

YES! See also here: https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/

Instead of a pull down menu, I would favor a free form text field without any default. (For policy neutrality)

Pushes the responsibility and the power to set this limit back to the user - where it belongs.

Thanks for the link!  Sounds like this is already a thing!  We should bring more attention to this idea and iron out the details.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
August 13, 2015, 04:03:51 PM
 #30356

[...]
So…is this a good idea?  If there are no obvious "gotchas" then perhaps we should write up a BIP.


I'd be willing to help! But I'd also suggest to just make it about the configurable setting and leave the rest to the user. I think signalling about blocksize has to happen out-of-band for the time being. Because it is potentially a lot of code complexity. And simple IMO beats complex here.

Just make it mandatory to start bitcoind with -maxblocksizelimit (or similar) and have an edit box for bitcoin-qt that has to be filled with a value. The amount of code change should be about the same as BIP101.

Start requesting this value at some switchover date in the future - maybe at the beginning of Gavin's increase schedule. Reason for this: Time for user education on building a function Bitcoin network.

What do you think?
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
August 13, 2015, 04:04:25 PM
 #30357

It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:

you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.

The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.

This seems too easy, like why wouldn't this have been thought of before. Is the idea that maybe this is one of those cases where muddled thinking (the consensus/transport layer confusion) has prevented people from seeing the obvious? I ask because I'm not sure I understand the full implications of sickpig's comment.

EDIT: I think I may get it now:

https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/ctddl6h

along with why it hasn't been tried:

https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/ctd812o
kehtolo
Hero Member
*****
Offline Offline

Activity: 706


View Profile
August 13, 2015, 04:08:00 PM
 #30358


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

that's just a re-write of what i've been advocating; lift the limit entirely.

but yeah, your idea is great b/c it would give full node operators a sense of being in charge via a pull down menu.  i like it.

don't forget that mining pools are just huge hashing overlays of full nodes which they operate and could use to do the same type of voting.

Yes, you have been essentially advocating the same thing.  

We could take this idea further: in addition to the drop-down menu where node operators and miners select the max block size they'll accept, we could add two new features to improve communication of their decisions:

  1.  The max block size selected by a node would be written into the header of any blocks the node mines.

  2.  The P2P protocol would be extended so that nodes could poll other nodes to find out their block size limit.

This would be a highly decentralized way of coming to consensus in a very flexible and dynamic manner.  

It would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer, as sickpig suggested:

you know what I can't stop thinking that the max block size is a transport layer constraint that have crept in consensus layer.

The network would dynamically determine the max block size as the network evolves by expressing the size of the blocks they will accept with the drop-down menu on their client.

So…is this a good idea?  If there are no obvious "gotchas" then perhaps we should write up a BIP.


It's a wonderful idea! It scales dynamically by reaching a consensus in a decentralised way. The network decides and evolves organically almost. I love it.

The next 24 hours are critical!
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 13, 2015, 04:17:35 PM
 #30359

I'd say the term "store of value" has meaning in the context our current world of fiat money, where you need a hedge against inflation. In the case of Bitcoin while it is still not yet mainstream I think a special definition is useful: an asset that retains or grows its purchasing power over the years (particularly in contrast with fiat money), with growth of course being considered even better as a store of value than simply staying level. Also the difficulty in confiscating it should be part of its store-of-value merits.
There is certainly a difference between forms of money that work well, and forms of money that don't, that many people have observed throughout history.

The problem is that the explanations for those observations are not correct, because they are tautological. They show up in conversations with goldbugs all the time.

Q: What is a store of value?
A: Anything that has the properties of gold.

Q: Why is gold a store of value?
A: Because it has intrinsic value.

Q: What is value?
A: It's what anything with the properties of gold has.

Q: Can you give reason why I should buy your gold other than that you want to sell it?
A: ...no.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
August 13, 2015, 04:20:31 PM
 #30360

[...]
So…is this a good idea?  If there are no obvious "gotchas" then perhaps we should write up a BIP.


I'd be willing to help! But I'd also suggest to just make it about the configurable setting and leave the rest to the user. I think signalling about blocksize has to happen out-of-band for the time being. Because it is potentially a lot of code complexity. And simple IMO beats complex here.

Just make it mandatory to start bitcoind with -maxblocksizelimit (or similar) and have an edit box for bitcoin-qt that has to be filled with a value. The amount of code change should be about the same as BIP101.

Start requesting this value at some switchover date in the future - maybe at the beginning of Gavin's increase schedule. Reason for this: Time for user education on building a function Bitcoin network.

What do you think?

I think that all makes perfect sense, and I agree that simple is better!  Perhaps the BIP could only advocate for doing what you said to start, and then there could be a follow-up BIP to do the signalling in the block headers and to add the p2p "block size limit request" messages.  The nice thing is that the signalling stuff in the follow-up BIP would have nothing to do with the consensus layer, so it would be much easier to build support for it.  

I'd be willing to contribute to this too.  Realistically, I couldn't do any serious work on this until mid-September, however.  Timing wise, it would be great to have a polished proposal published for the second Scalability Workshop in Hong Kong probably in November or December: https://scalingbitcoin.org/

I'm actually quite excited about this idea.  It has a sort of inevitable feel to it.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Pages: « 1 ... 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 [1518] 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 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!