I think someone missed the launch.
I think someone needs an update on current time, a year is no longer 2012. but 2014.
good one
Topic: Bitmark - page 150. (Read 622228 times)
I think someone needs an update on current time, a year is no longer 2012. but 2014.
good one
I think someone missed the launch.
I think someone needs an update on current time, a year is no longer 2012. but 2014.
I think someone missed the launch.
Project Status / Request for Funding
We have now achieved the amount needed to launch the project, 0.6 BTC.
We have now achieved the amount needed to launch the project, 0.6 BTC.
True that, crap clone coin costs around that much at Coingen or some similar coin-creation service.
So when can we expect to see this one on an exchange?
Why add this crapcoin to exchange? It seems most here fell for thousands of lines of nicely written yet slightly retarded stories but this coin is Coingen-made scrypt clone.
There is absolutely nothing special about it and all signs of bullshit are present. Instamining was massive, to start a new scrypt coin with difficulty 1 this days equalls either
complete lack of mining hardware and cryptocoin scene awareness or deliberate scam - it was later case, just in case you are still wondering. Using blockchain explorer it is
easy to realise how it all went:
http://cryptexplorer.com/chain/Bitmark?hi=770&count=100
Scroll down to block 720 and observe block times while difficulty was 1.0 and after it changed to 4.0 there is very little difference, blocks were mined just few seconds apart.
Situation went slightly better after next retarget from 4.0 to 16.0 (maximum possible upward change which means hashrate for blocks 720 to 1440 was at least 4 times higher
than desirable) but at that time 28,800 coins were already instamined, out of 45,100 coins in existence (based on latest data from blockchain explorer at time of this post).
As for other things, if you belive this crap clone has a future you are truly retarded.
Happy mining, investing or whatever other shit you are after for here.
So when can we expect to see this one on an exchange?
Hi ethought. Is your luck statistic broken? It just seems to throw up random numbers. 2 blocks can be solved with roughly the same amount of shares at the same diff and one will say 45% and the other 200% ??
Also please note:
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
God work. I have a question. Where is the option for manual payouts?
There is no manual payout option as a security measure.
Auto payouts occur every 5 minutes usually so you just need to enter your threshold and address.
Also please note:
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
God work. I have a question. Where is the option for manual payouts?
Also please note:
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
Total Earnings (Last 24H)
Is not showing the correct value at the moment. The correct value for earnings in last 24 hours (as pool is less than 24 hours old) can be found on the Dashboard under Total Credits + Pending.
This is because I made one mistake in the fix and entered credits (https://www.miningpool.co/account/payment/history/53/1) without a time..
Total Earnings (Last 24H) will show correct value 24 hours from now.
Figured out what the problem was.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
Well done! Wasn't panicking, honest...
Still think your pool has been one of the best, in the long run
Yes, it's looking much better now. Great work, thank you!
Figured out what the problem was.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
Good work, thanks. It seems to be displaying a number now in my balance that looks to be around what I expected it to be.
Figured out what the problem was.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
Basically every time the main system queried the stratum client wallets it would look through the last 400 transactions and update the confirmations.
Because up to now no coins on the pool had had greater confirmations required than 120, the last 400 transactions would always catch the needed blocks and update the confirmations.
Because bitmark requires 740 confirmations to mature a block the pool began to miss updating confirmations which then meant blocks were not getting paid out.
The problem was compounded by the fact that because there are two stratum servers the one with less hash on it was updating confirmations correctly as it was not finding nearly as many blocks as the other. The system would then only look back as far as the last solved and confirmed block paid out to process and pay new blocks.
Luckily all shares are recorded and logged on the system so all I had to do was write a quick script that replayed through the unconfirmed / unpaid blocks.
I have also updated the transaction query from the main system to look at the last 4000 transactions instead of the last 400, so this should never happen again.
Apologies for any inconvenience / stress etc caused by this.
I noticed that Execoin just released a forked and modified electrum with a 'stealth' option.
Not sure on any of the technical details yet on how their stealth option actually works. But since we we've been discussing forking Electrum at some point anyway, perhaps it's worth looking in to their implementation for Bitmark at some point in the future if it's well done.
https://github.com/fukukami/electrum-exe-stealth/
http://www.electrum-exe.org/stealth/
I can imagine that we'll be examining lots of different features similar to this as time goes on. Although I guess this would fall under the 3rd party category since I don't think this has anything to do with the core protocol, no?
Not sure on any of the technical details yet on how their stealth option actually works. But since we we've been discussing forking Electrum at some point anyway, perhaps it's worth looking in to their implementation for Bitmark at some point in the future if it's well done.
https://github.com/fukukami/electrum-exe-stealth/
http://www.electrum-exe.org/stealth/
I can imagine that we'll be examining lots of different features similar to this as time goes on. Although I guess this would fall under the 3rd party category since I don't think this has anything to do with the core protocol, no?
Woah, yeah. I just woke up and I have less total earnings(24) then I had when I went to sleep. 
And even before then I remember by total earnings going down by about a third. I wasn't sure if I was reading the fields wrong or what. It seemed like when I had coins confirmed I was losing more than I was getting from the 24 hour total.
edit: And total earnings went down by about ~25% again.
And even before then I remember by total earnings going down by about a third. I wasn't sure if I was reading the fields wrong or what. It seemed like when I had coins confirmed I was losing more than I was getting from the 24 hour total.
edit: And total earnings went down by about ~25% again.
I am looking into the issues now.
I have pm'd him also, my own "pending" and "total" balance has changed many times. I do not know how they are calculated, but it does not say estimate.
Since it his business I am sure ethought will confirm, and hopefully correct any errors if errors are present.
24 hour earnings are estimated, and depend on the other miners hashing power, and the pools success at finding blocks on the network. It will change often and means little when a coin is young.
For network health, we should look at some more pools.
I would like to avoid multipools and pools which auto convert to other currencies.
Perhaps we should research and approach some mining pools.
We should also create the IPM pool soon, it is a 5% donation but that goes to the foundation for the future of the coin and strengthens the value of any coins earned.
Since it his business I am sure ethought will confirm, and hopefully correct any errors if errors are present.
24 hour earnings are estimated, and depend on the other miners hashing power, and the pools success at finding blocks on the network. It will change often and means little when a coin is young.
For network health, we should look at some more pools.
I would like to avoid multipools and pools which auto convert to other currencies.
Perhaps we should research and approach some mining pools.
We should also create the IPM pool soon, it is a 5% donation but that goes to the foundation for the future of the coin and strengthens the value of any coins earned.
I'm not talking about estimated earnings. I'm talking about: Total Earnings (Last 24H). This shouldn't be swinging by 100's of coins, and shouldn't be dropping by about 20 each time 1 is confirmed to my balance available for withdraw.
thanks, I am learning. I am surprised though that apparently it had some 'success' - as you can see on the screenshot
It found a sha256d hash with the right amount of zero bits. It thought it was valid because it checks sha256.
Valid means the number of zero bits matched the difficulty target.
The pool and coin would reject it immediately as it was done with the wrong proof of work. It was an invalid hash with the right amount of zero bits.
You can conclude that cgminer worked with your sha256 asic, and if it had been a sha256 coin it would have worked.
You will nee a cpu (slow), or a gpu (medium), or a scrypt-asic (fast) for this scrypt coin.
If that's a block erupter it wont work for this. You need a scrypt asic or a gpu to mine this coin.
thanks, I am learning. I am surprised though that apparently it had some 'success' - as you can see on the screenshot
Pentamon
I have pm'd him also, my own "pending" and "total" balance has changed many times. I do not know how they are calculated, but it does not say estimate.
Since it his business I am sure ethought will confirm, and hopefully correct any errors if errors are present.
24 hour earnings are estimated, and depend on the other miners hashing power, and the pools success at finding blocks on the network. It will change often and means little when a coin is young.
For network health, we should look at some more pools.
I would like to avoid multipools and pools which auto convert to other currencies.
Perhaps we should research and approach some mining pools.
We should also create the IPM pool soon, it is a 5% donation but that goes to the foundation for the future of the coin and strengthens the value of any coins earned.
Since it his business I am sure ethought will confirm, and hopefully correct any errors if errors are present.
24 hour earnings are estimated, and depend on the other miners hashing power, and the pools success at finding blocks on the network. It will change often and means little when a coin is young.
For network health, we should look at some more pools.
I would like to avoid multipools and pools which auto convert to other currencies.
Perhaps we should research and approach some mining pools.
We should also create the IPM pool soon, it is a 5% donation but that goes to the foundation for the future of the coin and strengthens the value of any coins earned.
Jump to: