Bitcoin Forum
June 29, 2016, 03:50:23 AM *
News: Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 226 »
481  Bitcoin / Development & Technical Discussion / Re: Bitcoin GPLed because of GMP? on: June 14, 2015, 05:43:52 PM
I'm trying to build that great secp25k1 library (https://github.com/bitcoin/secp256k1) but it needs USE_NUM_GMP defined, and it has to link to GNU Multiprecision Library which is GPLv2? What's going on here?
secp256k1 is self contained. GMP is optional. Releases of Bitcoin Core do not currently use GMP.

Libsecp256k1 is still unreleased experimental software. Our use of it in Bitcoin core is intentionally very narrow (only for signing, always checked against OpenSSL). I would not advise using it in a production consensus system currently. If you're interested in using it-- you could help support its maturation to full release by supporting review of the software.
482  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 14, 2015, 01:15:34 AM
as far as I understand both sidechains and blocksize increase will need a hardfork.  There might be some grand compromise where both sides agree to let the other sides project in.  
Thats a complete misunderstanding, and I have no clue where you could have gotten it from-- can you specify so I can go hunt down that location and get them to fix it?  PM please-- this is offtopic for this thread.
483  Bitcoin / Development & Technical Discussion / MOVED: What does "taint analyis" on blockchain.info really mean? on: June 14, 2015, 01:13:48 AM
This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=1088997.0
484  Economy / Service Discussion / Re: What does "taint analyis" on blockchain.info really mean? on: June 14, 2015, 01:13:25 AM
The computation on BC.i is darn near a random number generator. The main thing it accomplishes is making people think they're more (or, infrequently, less) private than they are.
485  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 04:02:34 AM
guys, i think it's pretty clear that Greg isn't even going to consider Jeff's proposal as viable, unless you'd like to say otherwise Greg.  your non-response to my query says so not to mention your rhetoric.
I did respond to your query! Jeff's proposal is a bit underdefined right now, but to the extent that it isn't it's a good step forward. (Have you read it? It makes many of the points I've been making that you so vigorously have disagreed with...)
486  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 03:41:17 AM
If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.  The limitation to 1MB was intentional, not a bug.  Nor was the additional temporary soft limits below 1MB.   No one in the technical community is arguing that it should by 1MB forever, other than a panic end run around the process, breaking up consensus, and a huge leap thats completely out of proportion with safe operation or current demand just doesn't make sense.

Every single one explicitly predicts features that require more transactions than can fit in 1MB.  The promise was NEVER "someday, you'll never use bitcoins but your bank will".
Good thing then that there is no one in the technical sphere saying that.

Quote
You have a problem with 20MB, fine.  So propose 8, 4 or something that is not just "wait and see".  However, I never saw a post from you guys about how you tried it with 20MB and it didn't work. But I saw a careful analysis by Gavin showing how it DID work.
Many things have been proposed, moreover, when we tried it and it didn't work we went about _fixing_ the problems in the system. (Heck, good luck getting an older version of Bitcoin core synced with the chain with the _current_ sizes!). Do you read Bitcoin Development? do you read the commit and pull request feed? Do you read the bitcoin-dev channel logs? If not why would you have expected to see these things?  The only reason to take technical work out of the ordinary open to everyone technical channels is political gamesmanship. I for one prefer to avoid making it look like Bitcoin is blowing up (in spite of whatever concerns I will gladly bring to people's attention in the appropriate forums).

The constant attacks on sidechains/blockstream are because you think you can manipulate people with pat answers-- but the claims are bogus and easily established as such; the opposition to the 2000% jump in the Bitcoin development community universal it's Gavin thats the odd man out, yes indeed, that includes all the tech people at my company too-- but it's easy to show our views on the subject existed long before the company.  Worse, it's illogical, huge blocks and the ability to willy nilly change Bitcoin would make sidechains a lot easier to deploy.  In terms of interests, I'd be all for it, if I were not concerned about it being an existential threat to Bitcoin as a practical, decentralized system.

Quote
And scalability is harming the network RIGHT NOW, because developers aren't going to base all their work on something that won't work (or won't work without who-knows-how-high fees).
I like your euphemistic "developers" where are these mystery people? What are the project's you're talking about? As far as not knowing what the fees will be in the future-- thats fundamental, less than a half dozen miners could decide tonight that all future txn will need 1 BTC fees.

meanwhile:
Yea, well, got a chart of Bitcoin since Monday?  Ahem.
487  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 02:07:12 AM
so it sounds to me that you aren't willing to even talk to Gavin on this issue, is that right?
In public, sure and I have.

It's just that I think there is unlikely to be an agreement there. As far as I can tell Gavin and Mike have a vision of a future where Bitcoin is "decenterlized" in the way the existing central banking system is-- rather than being secured by a decenteralized proof of work consensus (or similar) where the rules dominate the system instead of politics; or at a lest that its okay to become that way now and then maybe worry about it later if we don't like it.  It's not a view I share, and with such different objectives its difficult to agree on the the foundations needed for agreement when a true trade-off must be made.  Mike thinks that transactions should be completely free forever and that the system has failed if they're not.. well you can see the perspective differences outlined here, probably better than I am going to explain it right now: https://medium.com/@allenpiscitello/what-is-bitcoin-s-value-proposition-b7309be442e3

Quote
Greg, would you want to be lead core dev?
No, among other reasons, it would be foolish as a US person..., and incidentally, I think the lead on Bitcoin Core-- Wladimir--  has done and continues to do an absolutely tremendous job. Though I suspect you read too much into lead-- it doesn't mean leader except in a person who helps people organize efforts sense. In Bitcoin another term for the world "leader" in the traditional top down governance sense, is "single point of failure"-- the part you compromise to undermine the whole thing. By Bitcoin's design and nature it can't have one of those, for better or worse.

the important part of their conclusion is that they acknowledge that organic growth of tx volume doesn't necessarily immediately ramp to the block limit; it is in fact controlled by market forces and adoption by users.  even if tx volume did ramp to the max i actually wouldn't be afraid of a scenario like this.  that's b/c i'd bet dollars to donuts that exchange price would ramp with it thus allowing me personally to have some extra fun running a "supernode".
As Jeff pointed out in his writeup, blocks have long been '100% full' relative to to whatever limit is being applied. If there is excess space, there is someone somewhere who will try to use it to store their data... be it some outlawed pornography they want to try to make censorship resistant or just 0 BTC  payments to advertise to people. A single while loop is an effectively infinite capacity demand, and a price of zero thats what we would have.  There have been a half dozen attempted companies trying to do "data archival in the blockchain", yadda yadda-- turns out globally replicated storage that other people pay for is pretty attractive!.   Though the traditional hard limit isn't necessary to block out crap like the unsolicited commercial advertising, but I'm personally very uncomfortable with putting ourselves in the position where the health of the network depends on miners censoring transactions-- I much prefer the politically neutral economics of competing for the available resources with fees.
488  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 01:54:27 AM
at this pt, you'd have to propose a concrete commitment plan and present it to Gavin to prove yourself.  no more talk.
LOL. Present it to Gavin?  You realize that Gavin hasn't actually tendered a specific proposal-- it's all talk and political maneuvering with the general public, right?  No BIP draft, no pull request, no development thread (except for the one created days after by opponents of his move in shock by the approach). As far as I can tell the whole situation was specifically constructed to be a big show and justify a "governance" crisis and land-grab (a belief also supported by the emails Mike was sending the gmx account a year ago). That noise about the XT hardfork?  No commits on the repository for months, and except for two patches even the months old stuff is just copying Bitcoin Core-- the work of all these other people who are so easily disrespected now. Sound and fury, signifying nothing. Meanwhile, beyond making proposals, creating simulations, oh yea and developing bunch of highly useful new free software for Bitcoin, the rest of the people who actually do the work continuing to truck on.  In any case-- these things have been proposed in the usual forums. Gavin seems unwilling to consider anything other than a massive uncontrolled jump in blocksize as far as I can tell, fortunately Jeff isn't interested in the same kind of purely political end run.

And here again we find that you say something untrue (that I hadn't made proposals related to block size), it's corrected (no, in fact I've tried several specific proposals), then the bar moves.
489  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 01:16:31 AM
it's certainly a lot simpler than anything you've proposed; oh wait, maybe not, that'd be nothing. Grin
Yes, you cannot be simpler than changing a constant-- but as I pointed out, changing a constant is no measure of safety, correctness, or ethics. There are plenty of one character changes that would utterly destroy the system if adopted.

And contrary to your claim, I've proposed many things--- even going back some time. For example, adjusting the limit to respect the impact on UTXO so that the costs better match the actual costs; adjusting blocks based on the 33rd percentile of miner preferences (similar to Jeff's proposal of 25th percentile), and allowing miners to mine blocks over the limit quadratically with increased effective-difficulty-- so if the network is actually backlogged with fees miners can catch up without being completely unhinged.

And then there is all the separate fundamental scaling work which I originally proposed, like the whole notion of UTXOs as a separately tracked and commutable resource, fraud proofs, etc.

apparently the initial software is very buggy; not unexpected. 
Huh?  Dunno what you're talking about there!  The network has been running flawlessly.  While we're sure there are, no doubt, lots of issues-- as we optimized for adding interesting features instead of QA-- and you really really really shouldn't go create an altcoin out of it (because it will crash and burn and we will laugh)... it works quite well, and I'm not aware of any complaints to the contrary.    Are you unable to exit FUD-everything-gmaxwell-touches mode for even a moment?

There really should be more interest in Confidential Values. That's a great technique.
Thanks. There are a couple of other angles that I think more people will be excited about once they 'click' for them.

Tying the subjects together-- for a given state of technology and amount of extra capacity (be it bandwidth, cpu, etc.) that capacity can be spent in various ways, by taking on increased load, by improving fungibility or privacy, by increasing decentralization. I happen to think we need all of these things. But a simplified understanding that only looks at one dimension isn't going to come up with a good engineering conclusion.  And sure, more X sound great if you consider it in isolation, but perhaps not when you realize it means less Y and never gaining any Z.  One of the reasons I think it's important to be cautious here is so that we can have CT (or a superior successor technology) in the Bitcoin network and not just in a sidechain.

490  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 13, 2015, 12:45:40 AM
I hate the fact that politics must be played.  But after this debacle, sidechains had better be more awesome than the second coming of Satoshi if they want to make mods that are so much more complicated than changing a constant that there is simply no comparative basis.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise.  But this is turning into a huge mistake.  They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin.  This reputation is going to badly affect their ability to get consensus in the future.

The opposition to Gavin's 2000% jump proposal comes unanimously from every active technical contributor to Bitcoin Core who has spoken up. This should suggest to you that your understanding of the comparative basis likely miscalibrated.  Though there is no comparative basis, 2WP sidechains are something that just requires non-broken smart contracts, it's not something that needs a hard-fork (and the centralized fedpeg sidechain stuff is indistinguishable, uncensorable, and unblockable: you can't prevent people from using it no matter how much you think you should be able to tell them that they can manage their funds).

Considering how often cypherdoc brags about his thread here being filled with economic wisdom, it's surprising to see views like "changing a constant simple and safe", after all 21 million bitcoins is merely a constant (and, pedantically, one the system didn't originally enforce....).  Try another strawman. Smiley
 
491  Bitcoin / Pools / Re: Notice: _ALL POOLS AND SOLO MINERS MUST UPDATE FOR BIP-66_ on: June 12, 2015, 10:52:51 PM
Isn't it only required to be on 0.10.1 on any system but windows?
Indeed, PeterTodd's description on the list is precise.  (I didn't want to give people a long list as a recommendation).
492  Bitcoin / Pools / Notice: _ALL POOLS AND SOLO MINERS MUST UPDATE FOR BIP-66_ on: June 12, 2015, 08:32:39 PM
Please see this post on bitcoin-development by Peter Todd: http://sourceforge.net/p/bitcoin/mailman/message/34199290/

We are currently at >75% hash-power with version 3 blocks, meaning BIP66 is enforced in those blocks.  If the 1001 block window reaches 95% all block with version<3 will be rejected and become orphaned.

I _strongly_ recommend upgrading to Bitcoin Core 0.10.2 immediately if you have not yet done so. If you have technical issues with the upgrade people will be glad to help, e.g. join #bitcoin-dev on freenode IRC.
493  Bitcoin / Bitcoin Discussion / Re: The overlooked existential threat of centralization on: June 12, 2015, 06:59:32 AM
I think anyone with significant amount of bitcoin holding (10K+ USD) will surely setup a dedicated node on high speed residential networks, the cost of such a server is very low comparing with the safety of his investment

Mining farms on the other hand will have a trend to further centralize, that is the danger, has nothing to do with block size
Why do you say that when many people clearly do not do so today?

As others have said, the increased block size shouldn't be a concern for nodes.
Then why is startup and sync time the number one complaint about Bitcoin Core since 2013? Why have so many people and organizations told me they stopped running it because of that?
494  Bitcoin / Development & Technical Discussion / Re: Great Orphan Block Hunt on: June 11, 2015, 03:47:45 AM
Anyone can trivially forge old orphan blocks (and have in the past...) sooo...
495  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 11, 2015, 02:40:14 AM
Don't be so sure. I think there is at least even odds that the recent drama will ultimately make it easier to deploy improved privacy in the system.
496  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 11, 2015, 02:04:02 AM
Since the vast majority of transactions will be <42.94967295 BTC, almost all transactions will have exponent zero. So, transactions with exponent >0 will stand out and be much less anonymous. And the inputs and outputs to coinjoins will need to have the same exponent.
Nothing against it, the space saved is worth the loss of anonymity for very large transactions. But it is probably best to warn people about it so that no one uses confidential transactions incorrectly.
Also, if I have several inputs with different exponents (let's say 0,1 and 2) and I want join them into a single ouput, will the protocol force me to have two outputs (with exp 0 and 2) or will it round down the amount?

Inputs do not have an exponent.  The exponent is a property of the range proof, not of the values themselves. They work by scaling the basis the proof operates over.

Right now elements alpha wallet only lets the exponent be changed by a config file setting.   

Edit2: Speaking of which, is this going to make it to Bitcoin core or is this expected to remain on a sidechain?
This exactly?  No-- but some optimized, mature, and superior version... sometime in the future? I certainly plan to work towards that end. There are other people who work on software in this space which wouldn't support it, however.

Aside, as TierNolan pointed out-- this composes perfectly with coinjoin and coinswap, and the interface is setup to facilitate coinjoin already; in coinjoin the participants need not learn each others values.  And in the case of coinswaps the swap transactions can be made indistinguishable from ordinary payments to a single key due to the switch to schnorr signatures.
497  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 10, 2015, 03:38:49 PM
It seems the public/blinding key operates on a per-wallet basis.  Doesn't that basically kill privacy?
No, because it doesn't show up on the network; though sure it's not ideal-- it was just an implementation expedient: that has no impact on the consensus behavior, and it can be fixed to have one blinding key per scriptpubkey.

Is the exponent also encrypted? And if so, could you give some more detail on how you deal with amounts with different exponents?
No-- it could be, but the overhead of that is quite considerable.  The exponent is public (note how it's shown on the getrawtransaction view), and just a property of the range proof, not the value itself-- so there is no complication in combining. It's set to whatever value the user wants, using it doesn't restrict the values you can send, though if your exponent is >0 your least significant digits are non-private.

498  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 10, 2015, 03:51:01 AM
Interesting ~ this probably sounds anti-privacy a bit for me to ask perhaps at this stage :-) but do you have a screencap of what it looks like (GUI) when this process (confidential transactions as described thus far in your post) is being done?  
(Note:  I haven't dug into Elements... yet. :-) )
There is nothing much to see.

You just have an address. You send coins to it.  The fact that the world can't see the values is basically invisible to the user.  Looks just like testnet. From the CLI you can see more.

Here is an example where I send 0.25 testnet to myself.


$ ./alpha-cli getnewaddress
22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy
$ ./alpha-cli sendtoaddress 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy 0.25
ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9
$ ./alpha-cli listtransactions "*" 2
[
    {
        "account" : "",
        "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",
        "category" : "receive",
        "amount" : 0.25000000,
        "vout" : 0,
        "confirmations" : 0,
        "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
        "walletconflicts" : [
        ],
        "time" : 1433908060,
        "timereceived" : 1433908060
    },
    {
        "account" : "",
        "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",
        "category" : "send",
        "amount" : -0.25000000,
        "vout" : 0,
        "fee" : -0.00005479,
        "confirmations" : 0,
        "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
        "walletconflicts" : [
        ],
        "time" : 1433908060,
        "timereceived" : 1433908060
    }
]
#then we can see how the world sees it.
$ ./alpha-cli getrawtransaction ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9 1
{
    "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00005479,
    "vin" : [
        {
            "txid" : "76c4b906eaebdfc7685d1870aa3c4d57c8dce2fe7b924a7147c410ebffa8bee2",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "0c0315abc52bced031a61ef1d8987470794540e46890b25b1f0f2b73b39d85ca37056e60fbf9a33 70c11ef7229575d937fd2935c9024ed2b1bc4a6fd473d3a9e01 0359134c3055c290a7a0499f0dfb78742ce964c1c4c8e17407898d5d05956c894e",
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value-minimum" : 0.00000000,
            "value-maximum" : 42.94967295,
            "ct-exponent" : 0,
            "ct-bits" : 32,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 fd23ecdd4fb918bd88a319294b1f0ede5f701165 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "n4bSHiZXaApHquce1KEB8tfCZH7ZpDnUYe"
                ]
            }
        },
        {
            "value-minimum" : 0.00000000,
            "value-maximum" : 42.94967295,
            "ct-exponent" : 0,
            "ct-bits" : 32,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 fd5eff1963631488f624513719e866d92eae83e5 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914fd5eff1963631488f624513719e866d92eae83e588ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "n4cf44LWhzi5KtbTaA1YHFBLWtgn89TF4K"
                ]
            }
        }
    ]
}

499  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 09, 2015, 04:35:23 PM
Taint tracking is inherently against the fungibility property of money.  
Perhaps you've not caught on that this makes coinjoins and coinswaps tremendously more private and useful; since joining with anyone at any time improves your privacy, with no need to coordinate values. Smiley

You can think of it in these terms:  CoinJoin and CoinSwap are efficient metadata privacy protection systems, but their effectiveness is undermined by the content not being private.  CT is a content privacy system. The two compose very nicely. (And the RPCs in elements should be all setup to integrate with external coinjoin.).

If this materializes, will we see two kinds of Bitcoins traded in exchanges, standard Bitcoins that trade at $x, and tainted Bitcoins that have been in the privacy sidechain trading at $x/2 or so?

OP, would you feel comfortable putting all your BTC through that sidechain?

Uh. Interesting position, (checks posting history), ah. Thanks for taking the time to step away from your ordinary posting in Dash/Darkcoin threads to chime in here.   I reject your premise: A bitcoin system where fungibility had failed enough to produce the situation you described would have already failed as a money. as that outcome would be untenable.  It's also not a theory that is well supported by current practices as there seems to be little such effect for coins moved through a variety of altcoin exchanges which are rumored to be primarily frequented for (inept) money laundering purposes.
500  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 02:25:02 PM
Does the standard client do that?  Could a non-functionary produce the fraud proofs?
It can! And it was mandatory that it did until right before the release, when we realized that syncing a new testnet node took a really substantial majority of the time it took to set it up and try it out.  Under an assumption that many people who would like to play with it don't already have testnet running, we thought that the ability to try it out trumps security for this application and added a switch and defaulted it off.

You can turn it on if you have testnet running;  in your config for alpha, add rpcconnect=127.0.0.1 rpcconnectport=18332 tracksidechain=all txindex=1 blindtrust=true  (assumes the same rpcuser/rpcpassword).



Quote
Does the federation just spend to a change address when done?
Yes, well multisig change.

Quote
So, 10 blocks is to protected against minor re-orgs on testnet and the 144 blocks is to protect against larger re-orgs and give a guaranteed window to broadcast the fraud proof.  There could be an added protection by requiring that 100 testnet blocks happen too.  That could be a federation rule though.
Correct. The ten you can think mostly as dos resistance where someone makes one block forks constantly just to force the network to constantly deal with fraud proofs.

Miners (or in this case the blocksigning functionaries) who happen to be watching both networks could also IsStandard-like enforce the integrity of the initial spends, which would prevent most of the potential fraud from showing up in the first place; but the design is such that the two networks don't generally need to be monitoring each other, or only do so in very very loosely coupled way.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 226 »
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!