Bitcoin Forum
December 06, 2016, 10:11:23 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
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 »
  Print  
Author Topic: [announce] Namecoin - a distributed naming system based on Bitcoin  (Read 318915 times)
khal
Hero Member
*****
Offline Offline

Activity: 538


NamecoinID: id/khal


View Profile WWW
May 30, 2013, 02:19:14 PM
 #661

I read the post with all the tx testing.. i can't say i fully understand it.. but did you check the changes to the latest bitcoin? (obviously may not fit in with namecoin)
It is a simulation of fees with new rules on current namecoind.

The new bitcoin release use this to BLOCK really small dust (on client side and relay side if i'm right) :
Code:
bool CTxOut::IsDust() const
{   
    // "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
    // which has units satoshis-per-kilobyte.
    // If you'd pay more than 1/3 in fees
    // to spend something, then we consider it dust.
    // A typical txout is 33 bytes big, and will
    // need a CTxIn of at least 148 bytes to spend,
    // so dust is a txout less than 54 uBTC
    // (5430 satoshis) with default nMinRelayTxFee
    return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < CTransaction::nMinRelayTxFee);

We could also integrate this into namecoin ?

NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9 | NamecoinID: id/khal | Register .bit domain
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T | My bitcoin Identity: send messages to bitcoin users
Free bitcoins: Surf4Bitcoin.com | Charity Ad: Make a good deed without paying a cent
1481019083
Hero Member
*
Offline Offline

Posts: 1481019083

View Profile Personal Message (Offline)

Ignore
1481019083
Reply with quote  #2

1481019083
Report to moderator
1481019083
Hero Member
*
Offline Offline

Posts: 1481019083

View Profile Personal Message (Offline)

Ignore
1481019083
Reply with quote  #2

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

Posts: 1481019083

View Profile Personal Message (Offline)

Ignore
1481019083
Reply with quote  #2

1481019083
Report to moderator
snailbrain
Legendary
*
Offline Offline

Activity: 1134



View Profile
May 30, 2013, 04:50:46 PM
 #662

I read the post with all the tx testing.. i can't say i fully understand it.. but did you check the changes to the latest bitcoin? (obviously may not fit in with namecoin)
It is a simulation of fees with new rules on current namecoind.

The new bitcoin release use this to BLOCK really small dust (on client side and relay side if i'm right) :
Code:
bool CTxOut::IsDust() const
{   
    // "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
    // which has units satoshis-per-kilobyte.
    // If you'd pay more than 1/3 in fees
    // to spend something, then we consider it dust.
    // A typical txout is 33 bytes big, and will
    // need a CTxIn of at least 148 bytes to spend,
    // so dust is a txout less than 54 uBTC
    // (5430 satoshis) with default nMinRelayTxFee
    return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < CTransaction::nMinRelayTxFee);

We could also integrate this into namecoin ?

will this effect your own proposals? (or this is just for really realy small dust?)


Updated Icon with White N
Included Namecoin Splash screen on startup

https://github.com/namecoin-qt/namecoin-qt
http://www.mediafire.com/folder/3aa8ukj7v6m5d/Namecoin-qt

nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
May 30, 2013, 05:44:53 PM
 #663


I compiled it in linux (the Makefile has the boost suffix for mingw unconditionally but other than that it compiled fine). I only had time to do a simple newaddress, tx to it, dumpprivkey, new wallet, importprivkey and this last step succeeds but doesn't import the key, at least not the right one.

I couldn't debug it further but if I had to guess I'd say it probably imports using the wrong address version.
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
May 30, 2013, 08:13:13 PM
 #664


I compiled it in linux (the Makefile has the boost suffix for mingw unconditionally but other than that it compiled fine). I only had time to do a simple newaddress, tx to it, dumpprivkey, new wallet, importprivkey and this last step succeeds but doesn't import the key, at least not the right one.

I couldn't debug it further but if I had to guess I'd say it probably imports using the wrong address version.

I have no idea why github decided that it shouldn't show me namecoin-qt remote as an option for a pull request, so here's the fix for the above problem:

https://github.com/nelisky/bitcoin/commit/95ca4f8dc800a203f65613afe5c9c79894d6c6a7
lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 30, 2013, 08:24:57 PM
 #665

 Probably a little bit of a dumb question, .. But I was wondering why the domain names have to expire 12,000 blocks?
One of the biggest areas of future development and use case scenarios, seems to be that of the open transaction style issuance of stock, bond or for that matter any form of digital unique certificate and tracking of their ownership. At first glance this seems ideally suited to Namecoin, but obviously this breaks down if the certificate expires after a ~ 1year rather than being transferred indefinitely.
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
May 30, 2013, 09:35:26 PM
 #666

Probably a little bit of a dumb question, .. But I was wondering why the domain names have to expire 12,000 blocks?
One of the biggest areas of future development and use case scenarios, seems to be that of the open transaction style issuance of stock, bond or for that matter any form of digital unique certificate and tracking of their ownership. At first glance this seems ideally suited to Namecoin, but obviously this breaks down if the certificate expires after a ~ 1year rather than being transferred indefinitely.
To keep Namecoin lean and mean.

It would be comfortable to be able to do a name_update for a name you don't have the privkeys for. I would expect that to be not realistic for the next release or any time soon, though.  Undecided

blockchained.com ■ bitcointalk top posts
cassini
Member
**
Offline Offline

Activity: 83



View Profile
May 30, 2013, 09:54:19 PM
 #667

Probably a little bit of a dumb question, .. But I was wondering why the domain names have to expire 12,000 blocks?
One of the biggest areas of future development and use case scenarios, seems to be that of the open transaction style issuance of stock, bond or for that matter any form of digital unique certificate and tracking of their ownership. At first glance this seems ideally suited to Namecoin, but obviously this breaks down if the certificate expires after a ~ 1year rather than being transferred indefinitely.
To keep Namecoin lean and mean.
And there is no need for changing this system, atm.

The only technical things that happen after 36,000 blocks are:
(btw, meanwhile it's 36,000 blocks, not 12,000)
a) The "expiry" date turns negative.
b) Someone else now can issue a name_new on this name, but the old data is still visible to everyone. Try name_history.
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.

So it is just a matter of a concensus on the meaning of "expired". For domain names it seems quite reasonable that the owner has to renew it after a certain period of time.
For other types of namecoin uses it might be sensible to just ignore the expiration date. You may set up your own bonds exchange, for instance, and the rule is "The blockchain's expiration date of our bonds is irrelevant. Only the first one who registered bond no. bo/ff1d80824444a0b792ca82 is the unique owner."
(where "ff1d80824444a0b792ca82" is the name)
snailbrain
Legendary
*
Offline Offline

Activity: 1134



View Profile
May 30, 2013, 09:55:01 PM
 #668


I compiled it in linux (the Makefile has the boost suffix for mingw unconditionally but other than that it compiled fine). I only had time to do a simple newaddress, tx to it, dumpprivkey, new wallet, importprivkey and this last step succeeds but doesn't import the key, at least not the right one.

I couldn't debug it further but if I had to guess I'd say it probably imports using the wrong address version.

will get it looked at.. thanks

bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
May 30, 2013, 09:57:20 PM
 #669

The thing is permanent domain squatting would be possible with no chance of recovery. Also what if you lose a private key. If it expires you can get it back with a new key.

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 30, 2013, 10:40:57 PM
 #670

Probably a little bit of a dumb question, .. But I was wondering why the domain names have to expire 12,000 blocks?
One of the biggest areas of future development and use case scenarios, seems to be that of the open transaction style issuance of stock, bond or for that matter any form of digital unique certificate and tracking of their ownership. At first glance this seems ideally suited to Namecoin, but obviously this breaks down if the certificate expires after a ~ 1year rather than being transferred indefinitely.

Another thing is that the namecoin blockchain could be used for coloured coin type applications just by using the regular TX features that are identical to bitcoin's, disregarding any of the namespace operations.

Also, automated renewal is not difficult for any serious application that is using the namecoin namespaces.

Dacm4n
Sr. Member
****
Offline Offline

Activity: 359



View Profile
May 30, 2013, 10:57:03 PM
 #671

Shouldn't this thread be in the alt-coin forum? Just wondering.

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 30, 2013, 11:02:09 PM
 #672

Shouldn't this thread be in the alt-coin forum? Just wondering.

No. Namecoin is special. Read the whole thread, you are like the 10th person to ask this ... probably you own some other competing alt-coin right?

phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
May 31, 2013, 07:40:34 AM
 #673

The client should come with reasonable default fees as you suggest. Would it be possible to change these via the config file or only via compilation?
Currently, only by compiling it. But it can be added as command line options like in bitcoin.
Compiling to go below a minimum seems better to me.

Does the dust filter have an influence on relaying?
Yes, it is applied after that the free mechanism reduces fees to 0. However, not all miners may use it (old version of namecoind).
Fees on size are applied before the free mechanism, and it hinders me a bit.
If we agree that what is expensive for the network is data storage/signature checks, then, the fees applied on size/txOut should be after applied the free mechanism, like the dust one.
Current steps :
1. fees = size x baseFee
2. fees = 0 if (priority & size < 1k / block < 9k)
3. fees = + dust

I would like something like :
1. fess = baseFee
2. fees = 0 if (priority & size < 1k / block < 9k)
3. fees = size x baseFee
4. fees = + dust
5. fees = + split
Hmm, what is the point of 1. and 2. if they get overwritten in 3. ?   IMHO 3. to 5. would be enough.

Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).

I agree the relay base fee should be increased. Not sure about the change of the base tx fee - all in all is that a decrease in fees compared to what we run now?
Splitting is more expensive, dust less (due to reduced threshold) & more (due to 10x the fees), size less (due to reduced fees); standard tx less (due to reduced fees).
Im' not sure about reducing fees too, but we must plan things as if 1NMC = 10 x current value => 10$. Is the current fee value of 0.005 still adapted to this ?
ok  Smiley

[Edit: I didn't add fees for txIn on my previous post, maybe we could do it too for each txIn above 2, which would increase fees for those tx]
? I thought txIns would decrease the fee?

Free txs
There is no way to force miners to include these, so I would prefer all MY txs to include fees by default. Also I don't see what the problem is to pay a tiny fee once every year.

Tx priority can be helpful should someone try to flood the network with txs so I would keep priority for miners that want to use it but have all txs pay normal fees by default. Hopefully this can simplify things, too.

The easier the fee system the better this works so it would sure be nice if there was a single base fee as khal suggests that can be adjusted.
Ok, so no change in priority/free mechanism for miners, but fees for everybody on the client side ? Keeping this part as it is already is the most simple choice :p
But as I propose to remove free tx for miners if size > 1k... I would like to let the choice for miners to include free tx, but only if txSize < 1k, and apply fees for size in other cases (even if the blockSize is mall).
Miners change this to maximize profit anyway...

Name op fees
IMHO it would be best if there were length staggered name op fees that would be network enforced and go to the miners (now or later does not matter). I guess it would be quite an effort, though.
If it is going to miners now, it may be more simple for users (nothing to do). In the other case, that would require to check for each name_tx if the name is expired and if the coins can be selected + force it to go to fees. Or add a name_refund/release rpc command.
Both choices (miner fees or locked funds until expirations) will need some effort.
Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of  selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.

Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.

This is an issue with high fees in general, also with the XYZ fees. The moral of the story being that miners have the last word.

Output size >! tx fee ?
Enforcing this would help making txs spendable thus reduce chainsize. It would also make name_ops a little more expensive. What is the point of all these dust tx?
What is currently considered as dust are txOut below 0.01NMC, which seems to be quite frequent in the chain (but still > 0.001NMC). Mining ? Gambling ?
Quote
// If you'd pay more than 1/3 in fees
// to spend something, then we consider it dust.
+1   Whatever goes against dust.

Sidenote: why does Bitcoin code have to be so... weird...

I'm for a stacked fee system : each characteristic of a tx can require a small amount of fees that are added to each other => less way to cheat the system as a "bad" tx will fall in at least one case, while allowing standard tx to remain cheap.
Sounds good  Smiley

[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.

@snailbrain: Awesome, will try to find the time to compile on win and test on the weekend.

blockchained.com ■ bitcointalk top posts
snailbrain
Legendary
*
Offline Offline

Activity: 1134



View Profile
May 31, 2013, 01:36:17 PM
 #674

Added 'importaddress' RPC command (based on CodeShark's pull request).

https://github.com/namecoin-qt/namecoin-qt/commits/master

https://github.com/namecoin-qt/namecoin-qt

working on rawtransaction rpcs

please test new commands (no guarantee, but all seem to be working atm)

khal
Hero Member
*****
Offline Offline

Activity: 538


NamecoinID: id/khal


View Profile WWW
May 31, 2013, 08:55:07 PM
 #675

Hmm, what is the point of 1. and 2. if they get overwritten in 3. ?   IMHO 3. to 5. would be enough.
I forgot a '+' in 3.


Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).
There is an additional rule at the end of the fee function to require more and more fees is block has reached 50% of its size. So, more fees, more chances to be in the next block in case of flood.


? I thought txIns would decrease the fee?
I first proposed that but there are 3 problems :
- each txIn is where the signature will be verified, and it costs CPU
- if you have 50 txIn and 50 txOut, you'll pay 0 (50-50) additional fee on this part
- you can send 1000 tx to yourself for "free" (1000 small tx) and then consolidate to yourself (1000 txIn 1 txOut) for "free"

So, here is what can be done for txOut/txIn :
fee += (nb txOut - 2) * baseFee + (nb txIn - 2 * baseFee / 2)


Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of  selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.

Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.
So, we need to enforce the 0.01NMC (or wathever value we chose) of name_new. And forget the fees based on the size of the name...


[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
Not if the name is expired (he may not spoke about that case). Not sure it would be a good idea.

NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9 | NamecoinID: id/khal | Register .bit domain
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T | My bitcoin Identity: send messages to bitcoin users
Free bitcoins: Surf4Bitcoin.com | Charity Ad: Make a good deed without paying a cent
bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
June 01, 2013, 01:14:42 PM
 #676

Namecoin could have done well if stupid Opendns cared about the community like they used to and resolved .bit
But the dipshits dont care about opendns or dnsomatic any more and only trying to make cash from "Umbrella"

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
June 01, 2013, 01:59:54 PM
 #677

Hmm, what is the point of 1. and 2. if they get overwritten in 3. ?   IMHO 3. to 5. would be enough.
I forgot a '+' in 3.
Smiley

Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).
There is an additional rule at the end of the fee function to require more and more fees is block has reached 50% of its size. So, more fees, more chances to be in the next block in case of flood.
Interesting... I guess Bitcoin has that, too. So it is even cheaper to bully normal txs out of a block.
(https://bitcointalk.org/index.php?topic=148211.0)

? I thought txIns would decrease the fee?
I first proposed that but there are 3 problems :
- each txIn is where the signature will be verified, and it costs CPU
- if you have 50 txIn and 50 txOut, you'll pay 0 (50-50) additional fee on this part
- you can send 1000 tx to yourself for "free" (1000 small tx) and then consolidate to yourself (1000 txIn 1 txOut) for "free"

So, here is what can be done for txOut/txIn :
fee += (nb txOut - 2) * baseFee + (nb txIn - 2 * baseFee / 2)
Sounds good.

Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of  selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.

Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.
So, we need to enforce the 0.01NMC (or wathever value we chose) of name_new. And forget the fees based on the size of the name...
I would not mind  Roll Eyes

[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
Not if the name is expired (he may not spoke about that case). Not sure it would be a good idea.
Hmm, it makes reregistering cheaper which is bad. Other problems?


Block size limit
It should be checked that the block size limit of the new version is the same as in the old version. Pre fork height that is.
https://bitcointalk.org/index.php?topic=152030.0   



blockchained.com ■ bitcointalk top posts
cassini
Member
**
Offline Offline

Activity: 83



View Profile
June 02, 2013, 01:52:53 PM
 #678


[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
You are right, phelix. A name_update of an expired name doesn't work even though I am the owner of the expired name. However, the name_list command still displays my out-of-date names as expected.

What worries me a little is that a name_update is completely free of charge. This leaves the door wide open for massive spamming.
The results of a few fee tests (after doing a settxfee 0.00):
name_new: 0.01 + 0.0005
name_firstupdate: 0.0005
name_update: 0.0000

virtualmaster
Hero Member
*****
Offline Offline

Activity: 504



View Profile
June 02, 2013, 02:08:34 PM
 #679


[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
You are right, phelix. A name_update of an expired name doesn't work even though I am the owner of the expired name. However, the name_list command still displays my out-of-date names as expected.

What worries me a little is that a name_update is completely free of charge. This leaves the door wide open for massive spamming.
The results of a few fee tests (after doing a settxfee 0.00):
name_new: 0.01 + 0.0005
name_firstupdate: 0.0005
name_update: 0.0000


This is correct. I agree.
Registration/renewal prices are to low even for long names.
They should be at least 0.1 NMC = 0.1 USD.

Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
Namecoinia.org  -  take the planet in your hands
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba   |  NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
snailbrain
Legendary
*
Offline Offline

Activity: 1134



View Profile
June 02, 2013, 05:01:53 PM
 #680


[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
You are right, phelix. A name_update of an expired name doesn't work even though I am the owner of the expired name. However, the name_list command still displays my out-of-date names as expected.

What worries me a little is that a name_update is completely free of charge. This leaves the door wide open for massive spamming.
The results of a few fee tests (after doing a settxfee 0.00):
name_new: 0.01 + 0.0005
name_firstupdate: 0.0005
name_update: 0.0000


This is correct. I agree.
Registration/renewal prices are to low even for long names.
They should be at least 0.1 NMC = 0.1 USD.

the registration needs to be less imo... maybe name_update should cost (i think it does if you update before a certain time period?), although maybe settxfee overrides it??

if names cost 0.1nmc.. this is only a total of a possible 210million names to cover domains, names, logins, usernames or whatever other things we use it for in the future (this is not including names already bought, some for 50 etc etc)...
need some way of releasing the locked fee names.. or the names have to be very low cost so billions of names can be created..
ultimately new names should be free or almost free.. but then it really could be spammed.. I think it should keep going down in price as intended.

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 »
  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!