Pages:
Author

Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 17. (Read 13217 times)

member
Activity: 70
Merit: 10
I noticed that my miner wasn't showing up in the block distribution history at times. Here's an example where it's registering fine up to block 575, disappears during blocks 576 and 577, then returns at block 578.

Code:
3d99591e-5790-4b7a-b219-ab22d2eef382	jc12345		578	19994.0000	1668.9717	8/9/2017 2:42:30 PM	23283.17	0.0716814584926104	8/9/2017 2:42:30 PM	jc12345.1: 32152 (23283)
bcbefc8a-c366-48ce-b7d5-47a3380536ed seriestoo 578 19994.0000 9074.4408 8/9/2017 2:42:30 PM 126593.98 0.0716814584926104 8/9/2017 2:42:30 PM intel7700k: 150311 (126594)
seriestoo: 61240 (126594)
2cba286c-0e95-443b-b1af-878621dcda79 testbible 578 19994.0000 891.2757 8/9/2017 2:42:30 PM 12433.84 0.0716814584926104 8/9/2017 2:42:30 PM testbible: 17715 (12434)
eba0fbab-978f-4a75-8c25-8b2033d8538f jumpinbunny 578 19994.0000 5615.1193 8/9/2017 2:42:30 PM 78334.33 0.0716814584926104 8/9/2017 2:42:30 PM Jesus777: 113712 (78334)
0879d8c7-7e38-47d0-8cc2-7d974354def8 tiras 578 19994.0000 2042.6564 8/9/2017 2:42:30 PM 28496.3 0.0716814584926104 8/9/2017 2:42:30 PM tirasworks: 45371 (28496)
0f649be8-eddc-402c-ae62-1f2152327349 happy_merchant 578 19994.0000 701.5361 8/9/2017 2:42:30 PM 9786.86 0.0716814584926104 8/9/2017 2:42:30 PM happy_merchant00: 13033 (9787)

6f4dc4a8-549d-4e13-b688-07a9b00ac03c jc12345 577 19995.0000 1453.3782 8/9/2017 2:39:26 PM 23963.58 0.0606494680929861 8/9/2017 2:39:26 PM jc12345.1: 32154 (23964)
ff81fe6d-0d05-4986-9eff-a594c3cefd39 bible_pay 577 19995.0000 3954.7030 8/9/2017 2:39:26 PM 65205.9 0.0606494680929861 8/9/2017 2:39:26 PM r15: 87462 (65206)
f3798682-34b9-493b-9750-d2ef2041e71c seriestoo 577 19995.0000 8053.6146 8/9/2017 2:39:26 PM 132789.53 0.0606494680929861 8/9/2017 2:39:26 PM intel7700k: 145944 (132790)
seriestoo: 61148 (132790)
89cfbc27-b5a8-47c6-ba6c-8498af2f9a90 jumpinbunny 577 19995.0000 4805.0187 8/9/2017 2:39:26 PM 79226.07 0.0606494680929861 8/9/2017 2:39:26 PM Jesus777: 113412 (79226)
4ba7e54d-ec4e-4a6f-8003-79fc5cad2487 tiras 577 19995.0000 1728.2855 8/9/2017 2:39:26 PM 28496.3 0.0606494680929861 8/9/2017 2:39:26 PM tirasworks: 45371 (28496)

6619ecfd-a25f-4393-b90c-196de1cb7f75 jc12345 576 19995.0000 2326.7319 8/9/2017 2:12:48 PM 19874.89 0.117068924354683 8/9/2017 2:12:48 PM jc12345.1: 32167 (19875)
4fe90646-5b5f-49bf-9c64-f8a913b973e4 bible_pay 576 19995.0000 7585.3988 8/9/2017 2:12:48 PM 64794.3 0.117068924354683 8/9/2017 2:12:48 PM r15: 88098 (64794)
b289e23d-1d97-4149-ba45-6677ba962b8f jumpinbunny 576 19995.0000 6335.1291 8/9/2017 2:12:48 PM 54114.52 0.117068924354683 8/9/2017 2:12:48 PM Jesus777: 55290 (54115)
900716bb-62ca-4cae-b143-89d104cd2d88 tiras 576 19995.0000 3747.7403 8/9/2017 2:12:48 PM 32013.11 0.117068924354683 8/9/2017 2:12:48 PM tirasworks: 47576 (32013)

b7b2a89d-67e1-408b-8a58-5d713a621301 jc12345 575 19998.0000 3293.6308 8/9/2017 2:02:33 PM 25604.32 0.128635734486599 8/9/2017 2:02:33 PM jc12345.1: 32126 (25604)
9e8e72a9-c884-40f6-bef9-c6ce61d7cba2 bible_pay 575 19998.0000 8441.5605 8/9/2017 2:02:33 PM 65623.76 0.128635734486599 8/9/2017 2:02:33 PM r15: 88472 (65624)
31f15a64-61c3-41b2-b380-225442389aa3 testbible 575 19998.0000 2051.2566 8/9/2017 2:02:33 PM 15946.24 0.128635734486599 8/9/2017 2:02:33 PM testbible: 17689 (15946)
7c9d586e-d28c-4309-a320-5c668a441a7d tiras 575 19998.0000 5023.1974 8/9/2017 2:02:33 PM 39049.78 0.128635734486599 8/9/2017 2:02:33 PM tirasworks: 47415 (39050)
8cd55983-1c1f-4be7-b98c-ef836ade429f happy_merchant 575 19998.0000 1188.3547 8/9/2017 2:02:33 PM 9238.14 0.128635734486599 8/9/2017 2:02:33 PM happy_merchant00: 13011 (9238)

The debug log at the time shows nothing abnormal:

Code:
2017-08-09 19:01:39 UpdateTip: new best=000013b3e09a5ace4c8d87dcadbd6f1a97d61004ea5b3d7cb46dce501c68871a  height=575  log2_work=26.339499  tx=2067  date=2017-08-09 19:01:36 progress=0.002851  cache=0.4MiB(1915tx)
2017-08-09 19:01:39 ProcessNewBlock : ACCEPTED
2017-08-09 19:11:51 UpdateTip: new best=000001d53cbb572419d76001b3742a27bcee8f8c0030e3bef9bcb4239b8ba630  height=576  log2_work=26.350153  tx=2068  date=2017-08-09 19:11:49 progress=0.002852  cache=0.4MiB(1916tx)
2017-08-09 19:11:51 ProcessNewBlock : ACCEPTED
2017-08-09 19:38:31 UpdateTip: new best=0000076b78a8fc0bb351b2ca2854b55bde5430d9397c3c2fc45173630de023ee  height=577  log2_work=26.362141  tx=2069  date=2017-08-09 19:38:28 progress=0.002854  cache=0.4MiB(1917tx)
2017-08-09 19:38:31 ProcessNewBlock : ACCEPTED
2017-08-09 19:41:36 UpdateTip: new best=00001de0c00c110c5893479e1036ee5dcdf14ab2c8f04b7e66977a849bb9dea7  height=578  log2_work=26.367812  tx=2070  date=2017-08-09 19:41:35 progress=0.002855  cache=0.4MiB(1918tx)
2017-08-09 19:41:36 ProcessNewBlock : ACCEPTED

Also happened at block 582, but this time there was an error:

Code:
2017-08-09 19:46:40 UpdateTip: new best=00000ff5d8a60182a69ac948a8cfec4c6b028950f59d3ee970d3ad95b1644ff7  height=581  log2_work=26.392701  tx=2073  date=2017-08-09 19:46:32 progress=0.002859  cache=0.4MiB(1921tx)
2017-08-09 19:46:40 ProcessNewBlock : ACCEPTED
2017-08-09 20:08:59 UpdateTip: new best=000012a13b09357a7d8f6f67ea01af0e7b44ffee11a2c5434e2e129f85018007  height=582  log2_work=26.407361  tx=2074  date=2017-08-09 20:08:58 progress=0.002860  cache=0.4MiB(1922tx)
2017-08-09 20:08:59 ProcessNewBlock : ACCEPTED
2017-08-09 20:09:21 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED

And finally blocks 584 and 585, with a different error occuring at block 584:

Code:
2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED
2017-08-09 20:27:54 UpdateTip: new best=000027558d313d80cad64a45db74624beec59967ba6868793eec6046eb01c6f3  height=584  log2_work=26.423361  tx=2076  date=2017-08-09 20:27:36 progress=0.002863  cache=0.4MiB(1924tx)
2017-08-09 20:27:57 

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-09 20:27:58

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 20:27:58 ProcessNewBlock : ACCEPTED
2017-08-09 20:29:51 UpdateTip: new best=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81  height=585  log2_work=26.429534  tx=2077  date=2017-08-09 20:29:47 progress=0.002864  cache=0.4MiB(1925tx)
2017-08-09 20:29:51 ProcessNewBlock : ACCEPTED
2017-08-09 20:41:46 CBlock(hash=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4, ver=536870912, hashPrevBlock=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81, hashMerkleRoot=7f41015fd0af276794ee02c2fd083a1b87965d628dfb34c3c263b61111b5892d, nTime=1502311305, nBits=1e19f652, nNonce=17734, vtx=1)
  CTransaction(hash=7f41015fd0, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 024a02022e01)
    CTxOut(nValue=19997.00000000, scriptPubKey=76a9149cff090c148949e19f4ed915)


2017-08-09 20:41:46 generated 19997.00
2017-08-09 20:41:46 UpdateTip: new best=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4  height=586  log2_work=26.439813  tx=2078  date=2017-08-09 20:41:45 progress=0.002866  cache=0.4MiB(1926tx)
2017-08-09 20:41:46 ProcessNewBlock : ACCEPTED
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.



test coins have no value .  right ?
None at all.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Not really related to the test pool, but this is an issue I see a lot even on the main blockchain:

Code:
Block  Timestamp
548    8/9/2017 9:45:08 AM
549    8/9/2017 10:44:51 AM
550    8/9/2017 10:44:51 AM
551    8/9/2017 10:44:51 AM

It'll go about an hour with no blocks, then that fail-safe difficulty reduction kicks in and you often see it followed by 2-3 blocks that are mined instantly. Do you think this is something that will work itself out when the network hashrate starts going up? I don't really know enough about blockchains to speculate on any security issues that might arise from the low difficulty blocks, but at the very least the inconsistency in block time might have an affect on widespread adoption of Biblepay since it directly affects the speed of transactions.
I have observed this also on all the chains.  I believe the issue is (the chain) eventually selects a difficulty for the next block that is slightly too hard for the miners, probably due to either them getting lucky on the last block, or, maybe some extra miners piling in the wallet.

Anyway, I doubt more hash rate will solve the problem, it might make it less frequent.
I think what we need to do is when we have another mandatory, add in two features in it:
- Retarget difficulty once per block instead of once per 4 blocks
- Lower the threshold for the stuck blocks from one hour to say 35 minutes.  It has to be well over 15 minutes, because the timedrift function for getting the network adjusted time is 15 minutes, and that enforced block drift for disallowing future mining (IE clocks could be off, per se, up to say 7 minutes or so) is used, but we could probably go with 35 minutes for stuck blocks, and that would keep our chain running smoother, and not have people hanging around waiting for confirms.


full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Go ahead and try to spam the pool now.

Got to jump out for a little while; spam prevention should be enabled on miner actions, ips, and withdraws.
full member
Activity: 221
Merit: 100
can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.



test coins have no value .  right ?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.
full member
Activity: 221
Merit: 100
can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?
member
Activity: 70
Merit: 10
Not really related to the test pool, but this is an issue I see a lot even on the main blockchain:

Code:
Block  Timestamp
548    8/9/2017 9:45:08 AM
549    8/9/2017 10:44:51 AM
550    8/9/2017 10:44:51 AM
551    8/9/2017 10:44:51 AM

It'll go about an hour with no blocks, then that fail-safe difficulty reduction kicks in and you often see it followed by 2-3 blocks that are mined instantly. Do you think this is something that will work itself out when the network hashrate starts going up? I don't really know enough about blockchains to speculate on any security issues that might arise from the low difficulty blocks, but at the very least the inconsistency in block time might have an affect on widespread adoption of Biblepay since it directly affects the speed of transactions.
full member
Activity: 221
Merit: 100
Hmm, I think I might've killed the pool website. I tried spamming withdrawals to see if it handled it okay. Seemed to be fine while I was spamming it manually, then I set up an autoclicker to hit send about a hundred times a second and now the web server seems to be busy or dead.


looks like ....

Server Error in '/' Application.
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: Invalid column name 'threads'.
Invalid column name 'BoxHPS'.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
member
Activity: 70
Merit: 10
Hmm, I think I might've killed the pool website. I tried spamming withdrawals to see if it handled it okay. Seemed to be fine while I was spamming it manually, then I set up an autoclicker to hit send about a hundred times a second and now the web server seems to be busy or dead.

--edit--
Site seems to be loading again, but was unresponsive for about 10 minutes.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Some feedback:

1. When you click on switch to testnet it toggles to switch to mainnet. When you click on another like like home, the link switch to mainnet defaults back to switch to testnet which is not correct.
2. There is no page to see stats on the blocks found, who found them, when found, the block's status etc.
3. No anonymous mining option.
4. Pool hash indicator is very close to client side hash
Hi JC,

Thanks for the detailed info.
I agree, #1 is a nuisance, however, the reason it made it so far is the affinity to main_chain, so Im not sure if that will stay that way or not.  The thing is in my experience, once we finish testing we will really for all intents and purposes always be in the main chain.   (To fix this I need to move the setting for your selected chain to Account to a drop down, and then put the indicator (of the active chain) somewhere else- Ill see what I can do).

On #2, check out block distribution history report.  It should have very good details.

On #3, nice idea.... Hmmm, thinking about it.

#4, cool.

And I have a new bug to add:

I think others might have experienced this also.  I have a few nodes solo mining and they are unaffected by this bug.
At 02:45 am this morning we have 5 miners on testnet pool mining.  Myself and I believe 2 others fell off at the time the tithe block hit. I believe our testnet miners crashed.
I believe the issue is, whatever is sent back to the client (either HTTP error, or possibly since the tithe block was mined, an ERROR type response) was handled in a way that caused an unhandled exception to close the whole client.  I will look into this today, and believe this Only affects pool miners.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.


We check for logged in status- please paste the error so we can debug.


http://pool.biblepay.org/Account.aspx
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.

Thanks a lot dude!  So of course when we go live, we can turn off verbose debug info.  But this helps, as this is basically a spoof URL security item, in a way.  On a side note, this happens when the users session auto-expires and then they try to spoof a URL.  Ill jump on this.

legendary
Activity: 1638
Merit: 1013
Some feedback:

1. When you click on switch to testnet it toggles to switch to mainnet. When you click on another like like home, the link switch to mainnet defaults back to switch to testnet which is not correct.
2. There is no page to see stats on the blocks found, who found them, when found, the block's status etc.
3. No anonymous mining option.
4. Pool hash indicator is very close to client side hash
newbie
Activity: 33
Merit: 0
running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.


We check for logged in status- please paste the error so we can debug.


http://pool.biblepay.org/Account.aspx
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.


We check for logged in status- please paste the error so we can debug.
newbie
Activity: 33
Merit: 0
running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.

Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.

sr. member
Activity: 433
Merit: 250
no info in Leaderboard.Still mine in testnet
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:
ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c flyingfish 411 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788 flyingfish 412 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.

Im glad we are still testing as we need to work out the finer kinks.

So good news is some things behind the scenes partially worked but you did find a bug.
So on block 411 (when you pulled out of the pool) you didnt actually get that block, the pool still got it (if you do a 'run subsidy 411') you see the pools testnet address.  So that explains how flyingfish got the whole block 411, so that park worked correctly.
But by the time 412 hit, here is the pool bug hitting:  It did successfully double check 412, and find it was not paid for it, and avoided putting it in the blocks table, but for some reason, it went ahead and distributed the block and paid it, so I can see a condition where it realized it should not pay it but executed the remaining part of the service; Ill look into that now, but anyway this is very helpful.  Looks like we need to keep testing for a while longer and insure this is killed.

Thanks.



Ok,

I fixed the two outstanding pool issues:  Balance is updated correctly now on the withdrawal form, and I found the condition where we pay when we should not pay, and corrected the logic.  Im going to mine against the testnet pool again and see if we can make this solid now.  We still need a few testers in testnet for a couple days, please join us, having only two of us is not very effective to exploit bugs.

Thanks.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:
ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c flyingfish 411 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788 flyingfish 412 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.

Im glad we are still testing as we need to work out the finer kinks.

So good news is some things behind the scenes partially worked but you did find a bug.
So on block 411 (when you pulled out of the pool) you didnt actually get that block, the pool still got it (if you do a 'run subsidy 411') you see the pools testnet address.  So that explains how flyingfish got the whole block 411, so that park worked correctly.
But by the time 412 hit, here is the pool bug hitting:  It did successfully double check 412, and find it was not paid for it, and avoided putting it in the blocks table, but for some reason, it went ahead and distributed the block and paid it, so I can see a condition where it realized it should not pay it but executed the remaining part of the service; Ill look into that now, but anyway this is very helpful.  Looks like we need to keep testing for a while longer and insure this is killed.

Thanks.
member
Activity: 70
Merit: 10
I disconnected from the pool and solo mined blocks 411 and 412 to see how the pool would respond to an outsider mining a block it was working on. The blocks were definitely solo mined and the block rewards were added to my wallet's immature balance. The block distribution history gives the impression that the pool still paid out to pool miners for those blocks:

Code:
ID					User Name	Height	Block Subsidy	Subsidy		Paid Date		HPS	PaymentPerHash	Updated			Stats
13a88588-0b07-42da-a8a7-256595d1438c flyingfish 411 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)
de9a39f5-fb2a-4605-95ae-4aa1bbcf3788 flyingfish 412 20000.0000 20000.0000 8/8/2017 10:27:59 AM 733.49 27.266777209204 8/8/2017 10:27:59 AM testnet2: 551 (733)

I didn't have a miner connected to the pool at the time so I can't verify whether or not pool miners were actually mistakenly credited for those blocks from my end.
Pages:
Jump to: