Bitcoin Forum
October 18, 2017, 12:32:06 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 ... 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1995179 times)
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
August 11, 2015, 03:10:18 PM
 #30101

my pt was that the construction of the relay network might have been a knee jerk reaction to the same "large miner large block attack" FUD that has been spread around by the Cripplecoiners.  it's author is a BS employee after all. it's only been around since Sept 2014.  i'm not saying that the relay network has been bad for Bitcoin; it may even have been good.  except that it is encouraging this non-verification scheme for tx's which as you say, may be gamed and has contributed to quite a perversion in analyzing this particular attack and was never visualized in Satoshi's original ideas.  perhaps it is not necessary to exist.  that is not to deny that it does exist and we need to adapt to it's presence.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009944.html

Maybe inform yourself before pulling things out your ass.


"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
1508286726
Hero Member
*
Offline Offline

Posts: 1508286726

View Profile Personal Message (Offline)

Ignore
1508286726
Reply with quote  #2

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

Posts: 1508286726

View Profile Personal Message (Offline)

Ignore
1508286726
Reply with quote  #2

1508286726
Report to moderator
1508286726
Hero Member
*
Offline Offline

Posts: 1508286726

View Profile Personal Message (Offline)

Ignore
1508286726
Reply with quote  #2

1508286726
Report to moderator
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 11, 2015, 03:13:02 PM
 #30102

it may even have been good.  except that it is encouraging this non-verification scheme for tx's which as you say, may be gamed and has contributed to quite a perversion in analyzing this particular attack and was never visualized in Satoshi's original ideas.
That isn't the problem.

The problem is that there is no way to tell an SPV client that the chain they are following because it has the most proof of work is actually invalid and should be rejected.

If that capability existed, then nobody would have to care whether or not miners choose to burn their own electricity mining invalid blocks or not.

This seems to happen frequently in Bitcoin where bad behaviour by party A can negatively effect party B, and so everybody focuses exclusively on preventing party A's bad behaviour instead of making the system more robust by removing party A's ability to negatively impact party B to solve all current and future problems.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 11, 2015, 03:17:23 PM
 #30103

Quote
i'm not saying that the relay network has been bad for Bitcoin; it may even have been good.  except that it is encouraging this non-verification scheme
I'm not sure to understand your logic here.
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
August 11, 2015, 03:18:12 PM
 #30104

Beware cypherdoc, you might find yourself agreeing with a Popescu follower for once:

http://www.contravex.com/2015/08/05/pity-the-lil-goldbuggers/

"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
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 11, 2015, 03:19:27 PM
 #30105

...
And the miner’s profit is the distance of the revenue curve above the cost curve.

Yes, nice work.  In my paper I was looking at the Miner's Surplus, which is not in general equal to the Miner's Profit as your graphs illustrate (but they both are maximized at the same value of Q*).  Your graphs show the miner's profit explicitly.  

Quote
The nice thing about plotting it this way is that we can also consider what would happen if transaction fees become a significant source of revenue and the block reward is not sufficient to profitably mine empty blocks:



We can see that in this case, it would only make sense for the miners to include enough transactions to be in the region of the graph where revenue exceeds cost.

This chart brings up a very good point.  Like you point out, in such a scenario, the miner can only earn a profit if he can include a sufficient number of fee-paying TXs in his block.  But what happens if the miner before him cleaned out the mempool?  It seems the rational miner will stop hashing1 entirely until enough new transactions have built up to push his block into the "profitable" zone in your graph (the zone where the supply curve is below the demand curve).  

Quote
This would also work in the extreme case where R=0.

I'm not sure.  I think the model suggests that the supply curve turns into a horizontal line at M=0 in such a case.  We still need to get around the problem that Eq. (11) suggests the cost to write to the Blockchain falls to zero:



Smooth has brought this up a few times now (and I've been ignoring him because I think this can of worms is best left closed).  Anyways, to really understand what happens when R->0 I think we need to make a new model that takes into account what we just learned from your chart above (that miners won't necessarily be hashing all the time).  

1Assuming the cost to turn the hardware on and off is small.

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

Activity: 1050



View Profile
August 11, 2015, 03:30:31 PM
 #30106

[...]
So to answer your question, my view is that IBLT would not affect the health of the fee market (but it would reduce fees overall).
[...]

I think this unclear and could be misconstrued. This is the fee per transaction you are talking about, correct? As no one really knows about the total amount of fees without assumptions about the demand curve.

You're correct; I am talking about the average fee per transaction.  I suspect that total fees per block would continue to increase with block size, as they have done historically.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 11, 2015, 03:40:31 PM
 #30107

Quote
Anyways, to really understand what happens when R->0 I think we need to make a new model that takes into account what we just learned from your chart above (that miners won't necessarily be hashing all the time).

That seems to be an interesting point illustrating how the best interest of users and miners incentives could diverge.
For users, an empty block is always better than no block because it adds work to the chain and increases the security of the previous transactions.
nby
Newbie
*
Offline Offline

Activity: 27


View Profile
August 11, 2015, 03:43:16 PM
 #30108


This chart brings up a very good point.  Like you point out, in such a scenario, the miner can only earn a profit if he can include a sufficient number of fee-paying TXs in his block.  But what happens if the miner before him cleaned out the mempool?  It seems the rational miner will stop hashing1 entirely until enough new transactions have built up to push his block into the "profitable" zone in your graph (the zone where the supply curve is below the demand curve).  


Maybe I'm missing something, please correct me if I'm wrong.

In the event of an empty mempool (and with a 0 btc subsidy), for a miner to obtain a profit would be necesary to wait until enough new fee paying transactions enter into the mempool, otherwise keep mining at a loss.

Isn't this the same as saying

"In order for a transaction to be added to the blockchain, a sufficient fee must be provided"


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 11, 2015, 03:51:51 PM
 #30109

my pt was that the construction of the relay network might have been a knee jerk reaction to the same "large miner large block attack" FUD that has been spread around by the Cripplecoiners.  it's author is a BS employee after all. it's only been around since Sept 2014.  i'm not saying that the relay network has been bad for Bitcoin; it may even have been good.  except that it is encouraging this non-verification scheme for tx's which as you say, may be gamed and has contributed to quite a perversion in analyzing this particular attack and was never visualized in Satoshi's original ideas.  perhaps it is not necessary to exist.  that is not to deny that it does exist and we need to adapt to it's presence.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009944.html

Maybe inform yourself before pulling things out your ass.



note how all the arguments have flipped 180 from what they originally FUD'd about large block attacks here:

https://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/cr138we?context=3

gmax (italics).  non-italics mine:
>
I'm also mystified by a lot of the large block discussion, much of it
is completely divorced from the technology as deployed; much less what
we-- in industry-- know to be possible. I don't blame you or anyone in
particular on this; it's a new area and we don't yet know what we need
to know to know what we need to know; or to the extent that we do it
hasn't had time to get effectively communicated.

The technical/security implications of larger blocks are related to
other things than propagation time, if you assume people are using the
available efficient relay protocol (or better).

SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
What these parties are actually doing is blinding mining on top of
other pools' stratum work. You can think of it as sub-pooling with
hopping onto whatever pool has the highest block (I'll call it VFSSP
in this post-- validation free stratum subpooling).  It's very easy to
implement, and there are other considerations.

It was initially deployed at a time when a single pool in Europe has
amassed more than half of the hashrate. This pool had propagation
problems and a very high orphan rate, it may have (perhaps
unintentionally) been performing a selfish mining attack; mining off
their stratum work was an easy fix which massively cut down the orphan
rates for anyone who did it.  This was before the relay network
protocol existed (the fact that all the hashpower was consolidating on
a single pool was a major motivation for creating it).


note how the relay network was an apparent reactionary construct to ghash which had been spv mining to compensate for it's own high orphan rates.  never mind that it self imploded as hashers abandoned the pool for aggregious behavior.  the relay network is less than 1y old.  also note how miners CAN defend themselves quite well to a large block attack and high orphan rates; by spv mining at it's most extreme.  this is a major pt i have been making as to why a block cap is not needed.


>VFSSP also cuts through a number of practical issues miners have had:
Miners that run their own bitcoin nodes in far away colocation
(>100ms) due to local bandwidth or connectivity issues (censored
internet); relay network hubs not being anywhere near by due to
strange internet routing (e.g. japan to china going via the US for ...
reasons...); the CreateNewBlock() function being very slow and
unoptimized, etc.   There are many other things like this-- and VFSSP
avoids them causing delays even when you don't understand them or know
about them. So even when they're easily fixed the VFSSP is a more
general workaround.


see?  i have been saying EXACTLY THIS since the beginning of the debate calling them "defensive blocks".

>Mining operations are also usually operated in a largely fire and
forget manner. There is a long history in (esp pooled) mining where
someone sets up an operation and then hardly maintains it after the
fact... so some of the use of VFSSP appears to just be inertia-- we
have better solutions now, but they they work to deploy and changing
things involves risk (which is heightened by a lack of good
monitoring-- participants learn they are too latent by observing
orphaned blocks at a cost of 25 BTC each).


remember when gmax was "surprised" when he was told by f2pool that they needed to utilize spv blocks as a defense to full blocks as a result the spamming attacks?  i never called him out on this as up to that pt they had been continually using the "large miner large block attack" as a reason to not lift the limit.  in contrast, i had for some time prior to this pointed out that this was obvious based on what Chun had said in his bitcoin-dev post.

>One of the frustrating things about incentives in this space is that
bad outcomes are possible even when they're not necessary. E.g. if a
miner can lower their orphan rate by deploying a new protocol (or
simply fixing some faulty hardware in their infrastructure, like
Bitcoin nodes running on cheap VPSes with remote storage)  OR they can
lower their orphan rate by pointing their hashpower at a free
centeralized pool, they're likely to do the latter because it takes
less effort.



yet another non-technical assessment from gmax based on a misunderstanding of miner incentives.  no, i don't think miners will just take the easy route in pointing their hashrate at a centralized pool.  miners instead have an incentive to keep mining honest by keeping the hashrate decentralized and the system honest as a whole in order not to destroy value:

https://www.youtube.com/watch?v=or65M4Ht4Kk
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 11, 2015, 03:51:58 PM
 #30110

Quote
One could argue that the Shannon Entropy in a new block will not in general be proportional to the size of the block, but that doesn't make any sense to me
I fear there's a misunderstanding here. The key point is the relation between the number of transactions and the size of the block (or the associated Shannon Entropy). With mechanisms like IBLT, the quantity of information transmitted on the wire (Shannon Entropy) is constant, whatever the number of transactions in the block.

I think there's enough contention on this topic that it deserves continued research.  To me it seems fairly obvious (I could be wrong) that no scheme exists where simultaneously (a) miner's are free to build blocks according to their own volition, and (b) the quantity of information transmitted on the wire (during block solution propagation) is constant for all values of the block size Q.  However, no one has proven this one way or the other so it's an open research question.  

Quote
EDIT: Do you plan to participate in this event ?

This looks great!  I would love to go and present my paper.

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

Activity: 1050



View Profile
August 11, 2015, 04:00:43 PM
 #30111

Maybe I'm missing something, please correct me if I'm wrong.

In the event of an empty mempool (and with a 0 btc subsidy), for a miner to obtain a profit would be necesary to wait until enough new fee paying transactions enter into the mempool, otherwise keep mining at a loss.

Isn't this the same as saying

"In order for a transaction to be added to the blockchain, a sufficient fee must be provided"

It's a matter of whether we're talking about the fee per transactions, or the total fees that a miner can claim when he builds a block.  In the case where R->0, you could post a TX with a generous fee1 but it still won't make sense for a miner to attempt to mine a block just for you.  You'd need to wait until others have broadcast similarly fee paying transactions, in order to push the block size into the "profitable" zone in Mengerian's graph:



1There would be some fee that you could pay to get your TX mined, but it would be vastly more costly than waiting for other fee-paying transactions to begin re-filling the miners' mempools.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
August 11, 2015, 04:13:27 PM
 #30112

Using logic, I can see two possible reason for being a block minimalist developer.

1)  Since "Uh oh, here it is we who decide the size of the blocks", because having power is good. Since there is no consensus within the self appointed dominator group, we have to wait until the royals can come to agreement.

2) They want to suffocate bitcoin, permanently if possible, to get a head start on their endevour into competing systems.

I'm leaning more and more towards 2, judging by the percentage of Blockstream supremacists and monero pimps between block minimalists.

I don't follow your logic.
Larger blocks would help Blockstream be effective.
I doubt there are many people (if any) in either Blockstream or Monero that are seeking for Bitcoin to not succeed.

It is disingenuous to assume a wicked motive in this debate just because you disagree on the risk assessment.
Those that disagree with you could do the same and say that you want big blocks ahead of other developments because you want Bitcoin to fail and it would also not make any sense or be useful to getting the right answer.

I used "logic" to sound arrogant, it is a bad habit. Anyway, there is absolutely no higher risk with 1.1 MB than 1.0 MB. I don't want to repeat all the other arguments either way.

There is also absolutely no point to move from 1.0 MB to 1.1 MB.


I think it would be a good move. Revitalise trust from those with only toes in, then moon...


Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
August 11, 2015, 04:15:06 PM
 #30113

Using logic, I can see two possible reason for being a block minimalist developer.

1)  Since "Uh oh, here it is we who decide the size of the blocks", because having power is good. Since there is no consensus within the self appointed dominator group, we have to wait until the royals can come to agreement.

2) They want to suffocate bitcoin, permanently if possible, to get a head start on their endevour into competing systems.

I'm leaning more and more towards 2, judging by the percentage of Blockstream supremacists and monero pimps between block minimalists.

I don't follow your logic.
Larger blocks would help Blockstream be effective.
I doubt there are many people (if any) in either Blockstream or Monero that are seeking for Bitcoin to not succeed.

It is disingenuous to assume a wicked motive in this debate just because you disagree on the risk assessment.
Those that disagree with you could do the same and say that you want big blocks ahead of other developments because you want Bitcoin to fail and it would also not make any sense or be useful to getting the right answer.

I think what he is saying is that he doesn't think the [2] people want bitcoin to fail, they want to leverage the artificial fee market to push the adoption of their preferred alternative technology.


Right, hold back, not kill entirely, because what they have is only dreams and vaporware.

brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
August 11, 2015, 04:22:21 PM
 #30114

Using logic, I can see two possible reason for being a block minimalist developer.

1)  Since "Uh oh, here it is we who decide the size of the blocks", because having power is good. Since there is no consensus within the self appointed dominator group, we have to wait until the royals can come to agreement.

2) They want to suffocate bitcoin, permanently if possible, to get a head start on their endevour into competing systems.

I'm leaning more and more towards 2, judging by the percentage of Blockstream supremacists and monero pimps between block minimalists.

I don't follow your logic.
Larger blocks would help Blockstream be effective.
I doubt there are many people (if any) in either Blockstream or Monero that are seeking for Bitcoin to not succeed.

It is disingenuous to assume a wicked motive in this debate just because you disagree on the risk assessment.
Those that disagree with you could do the same and say that you want big blocks ahead of other developments because you want Bitcoin to fail and it would also not make any sense or be useful to getting the right answer.

I think what he is saying is that he doesn't think the [2] people want bitcoin to fail, they want to leverage the artificial fee market to push the adoption of their preferred alternative technology.


Right, hold back, not kill entirely, because what they have is only dreams and vaporware.


https://www.reddit.com/r/Bitcoin/comments/3gldfn/alpha_thundernetwork_a_lightning_network/

Vaporware you say?

"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
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
August 11, 2015, 04:23:33 PM
 #30115

Using logic, I can see two possible reason for being a block minimalist developer.

1)  Since "Uh oh, here it is we who decide the size of the blocks", because having power is good. Since there is no consensus within the self appointed dominator group, we have to wait until the royals can come to agreement.

2) They want to suffocate bitcoin, permanently if possible, to get a head start on their endevour into competing systems.

I'm leaning more and more towards 2, judging by the percentage of Blockstream supremacists and monero pimps between block minimalists.

I don't follow your logic.
Larger blocks would help Blockstream be effective.
I doubt there are many people (if any) in either Blockstream or Monero that are seeking for Bitcoin to not succeed.

It is disingenuous to assume a wicked motive in this debate just because you disagree on the risk assessment.
Those that disagree with you could do the same and say that you want big blocks ahead of other developments because you want Bitcoin to fail and it would also not make any sense or be useful to getting the right answer.

I used "logic" to sound arrogant, it is a bad habit. Anyway, there is absolutely no higher risk with 1.1 MB than 1.0 MB. I don't want to repeat all the other arguments either way.

There is also absolutely no point to move from 1.0 MB to 1.1 MB.


I think it would be a good move. Revitalise trust from those with only toes in, then moon...

 Shocked

Hard fork the network and risk catastrophic consensus failure to "revitalise trust" is a good move!?

You are out of your mind.


"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
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
August 11, 2015, 04:27:03 PM
 #30116

Quote
Anyways, to really understand what happens when R->0 I think we need to make a new model that takes into account what we just learned from your chart above (that miners won't necessarily be hashing all the time).

That seems to be an interesting point illustrating how the best interest of users and miners incentives could diverge.
For users, an empty block is always better than no block because it adds work to the chain and increases the security of the previous transactions.

"interest of users and miner's incentives could diverge"... this is a very odd way of describing the situation because these interests are of course divergent.  

The interest of a seller is always to sell at the highest price, and the buyer to buy at the lowest.  It is this tension that makes price discovery work.


This chart brings up a very good point.  Like you point out, in such a scenario, the miner can only earn a profit if he can include a sufficient number of fee-paying TXs in his block.  But what happens if the miner before him cleaned out the mempool?  It seems the rational miner will stop hashing1 entirely until enough new transactions have built up to push his block into the "profitable" zone in your graph (the zone where the supply curve is below the demand curve).  

Do you see this as a problem?  I see this as the network working at its maximum efficiency... note that every miner will have a slightly different cost so hashing power will turn off at different times.  And if running intermittent hashing power causes blocks to come less often than once per 10minutes, the difficulty will be reduced.  The reduction in difficulty will allow blocks to be found with less hash power so your hardware will be more likely to find the block.  This means miners will power up their hardware with fewer transactions in the mempool.

So the system self-adjusts.

The awesome part of it is that there is NO minimum fee.  Difficulty will always adjust to allow the minimum fee to be whatever people are willing to pay (presumably to just below competitive money transmission systems).
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 11, 2015, 04:33:12 PM
 #30117

oh my, Cripplecoiners in Big Trouble:

https://twitter.com/Datavetaren/status/631080568487342080
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 11, 2015, 04:34:20 PM
 #30118

This chart brings up a very good point.  Like you point out, in such a scenario, the miner can only earn a profit if he can include a sufficient number of fee-paying TXs in his block.  But what happens if the miner before him cleaned out the mempool?  It seems the rational miner will stop hashing1 entirely until enough new transactions have built up to push his block into the "profitable" zone in your graph (the zone where the supply curve is below the demand curve).  

Do you see this as a problem?  I see this as the network working at its maximum efficiency... note that every miner will have a slightly different cost so hashing power will turn off at different times.  And if running intermittent hashing power causes blocks to come less often than once per 10minutes, the difficulty will be reduced.  The reduction in difficulty will allow blocks to be found with less hash power so your hardware will be more likely to find the block.  This means miners will power up their hardware with fewer transactions in the mempool.

So the system self-adjusts.

The awesome part of it is that there is NO minimum fee.  Difficulty will always adjust to allow the minimum fee to be whatever people are willing to pay (presumably to just below competitive money transmission systems).

No, I see this as a positive.  I agree with everything you wrote above.  

However, one thing I'd like to reconcile is the fact that Eq. (11)



suggests the cost to spam the blockchain falls to zero as R->0.  I was wondering if my model "breaks" when the block reward becomes small because it is not considering that rational miners would stop and start hashing depending on the fees available from mempool.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Wexlike
Hero Member
*****
Offline Offline

Activity: 975


View Profile
August 11, 2015, 04:38:07 PM
 #30119


Don't forget https://www.reddit.com/r/Bitcoin/comments/3gkp91/blocksize_debate_coinbase_bitpay_chaincom/

Bigger blocks, here we come !
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 11, 2015, 04:38:10 PM
 #30120

hey iCEBLOW.  blow this:

Pages: « 1 ... 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 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 ... 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!