Bytecoin needs more pools and a good dedicated exchange.
You are focusing your energy on the wrong target.
Bytecoin is perfect as it is. Just keep mining and STFU!
Maria.
Topic: ByteCoin Poll (PLZ Sticky) - page 5. (Read 28791 times)
wow! i've spoken to doublec and he agreed to add it after the fork. I have a repository with a forked bytecoin aith the patch applied however it's not currently accepting any merged mined blocks upon testing so i have some more debugging to do on testnet
wait bitparking is in the TH?
i thought it was in the GH 
well then i dont plan on adding a static diff then. since th will get us to the next retarget in no time
7.8 TH now i thought it was in the GH well then i dont plan on adding a static diff then. since th will get us to the next retarget in no time
did you speak to doublec about adding BTE to the pool?
do you have a github repository with a merged mining patch?
wait bitparking is in the TH? i thought it was in the GH
well then i dont plan on adding a static diff then. since th will get us to the next retarget in no time
i thought it was in the GH well then i dont plan on adding a static diff then. since th will get us to the next retarget in no time
it would come faster but would it come fast enough? i personally dont think so but give me an hour or so and ill do some calc's
if it goes to bitparking that's 5 TH added.Even if people start merge-mining on p2pool it would be tens of gigahashes.
it would come faster but would it come fast enough? i personally dont think so but give me an hour or so and ill do some calc's
i see what you're saying however i think theres a possability there may be a misunderstanding. I wont be changing the diff algorithm or anything like that.i was thinking of doing it so that at the time of the fork the difficulty will be reduced on that one occasion and the diff adjustments will continue like normal
With merged mining the current diff won't be a problem, at least next retarged will come much faster.
i see what you're saying however i think theres a possability there may be a misunderstanding. I wont be changing the diff algorithm or anything like that.i was thinking of doing it so that at the time of the fork the difficulty will be reduced on that one occasion and the diff adjustments will continue like normal
the merged mining would give it a more consistent hashrate. Think of the current hashrate + mmpool hashrate = new hashrate after the fork. What i was thinking of doing was setting the hashrate at the hard fork to something slightly lower in order to increase the block times. However i am in 2 minds about that
Firstly, I appreciate your efforts.
Now. Since you've confirmed my suspicion that your merge mining patch will lead to a higher hashrate after the fork, why would you not wait to see the effects on the block times? Tinkering the code to improve the block times should be a last resort in my opinion. If after a certain amount of time, the merge mining doesn't lead to a nice increase in network hashrate then we could look to improve the block time situation with a coding change.
I would be willing to assist in an effort to market the merge mining capability to the wider Bitcoin crowd.
Yes for merged mining
No for retargeting changes.
No for retargeting changes.
i can agree but the diff is something that needs to be looked at, im thinking of setting the diff to be a static value at the hard fork so we can bring it down to a normal level
I'm strongly of the opinion that tinkering with Bytecoin's difficulty or retargeting will destroy it's USP (unique selling point). We already have hundreds of coins similar to Bitcoin but 'a little different'.
+1 - The "tinkering" that is being considered includes forking the blockchain, which should be rejected out-of-hand, as it destroys Bytecoin's uniqueness as a pure BTC clone. These "forkers" want to profit at others expense just to make it easy for themselves to merge-mine multiple alt coins. Motive is pure profit and damn the blockchain integrity.
the merged mining would give it a more consistent hashrate. Think of the current hashrate + mmpool hashrate = new hashrate after the fork. What i was thinking of doing was setting the hashrate at the hard fork to something slightly lower in order to increase the block times. However i am in 2 minds about that
i can agree but the diff is something that needs to be looked at, im thinking of setting the diff to be a static value at the hard fork so we can bring it down to a normal level
I'm confused. My understanding was that you are working on a merge mining patch. Would that not vastly improve the situation once implemented due to the significant increase in network hashrate?
I'm strongly of the opinion that tinkering with Bytecoin's difficulty or retargeting will destroy it's USP (unique selling point). We already have hundreds of coins similar to Bitcoin but 'a little different'.
i already have a pure SHA pool for bytecoin i just need to clean up the frontend. Im planning on making it PPS too to increase the users
Just want to point out... If not for the max 4x difficulty decrease, even if the remaining blocks till 20160 were all found now, the difficulty would drop by a factor of 9, to 3.8K.
Right now it's going at 93 blocks found in the past 288 hours (1 block every 3.1 hours), suggesting a hashrate of 13.79GH/s. At this rate the next diff adjustment will be in 169 days and 7 hours. Perhaps we could get people who mine just for fun (i.e. not expecting much profit) to put their hashpower onto this coin? 336MH/s here, 336MH/s there and pretty soon you'd have a whole lot of gigahashes per second.
I hope to set up a pure-SHA pool soon, and when (if ever) I get it I will include Bytecoin as one of the choices.
Right now it's going at 93 blocks found in the past 288 hours (1 block every 3.1 hours), suggesting a hashrate of 13.79GH/s. At this rate the next diff adjustment will be in 169 days and 7 hours. Perhaps we could get people who mine just for fun (i.e. not expecting much profit) to put their hashpower onto this coin? 336MH/s here, 336MH/s there and pretty soon you'd have a whole lot of gigahashes per second.
I hope to set up a pure-SHA pool soon, and when (if ever) I get it I will include Bytecoin as one of the choices.
possible and true. However until the last pool it was technically considered dead. Even now its blocks every 12 hours. So something has to be done to fix it
The whole point of Bytecoin is that it's a pure copy of Bitcoin. Making it different turns Bytecoin into one of the million other alt coins around here. Plus if merge mining is successful then the difficulty retarget will become a smaller issue than at present.
Agreed. The future potential of BTE is it's 1:1 relationship to BTC. Messing with the blockchain and hard-forking just benefit those who want quick profits right away. It benefits only miners who are currently promoting the changes. I believe those who are able to conventional-mine BTE with modest hashing should continue to do so. This will give the difficulty time to come down slowly by the end of the year hopefully making block generation quicker.
It's a possibility that the increasing difficulty and hashrate BTC is currently experiencing will put many off mining Bitcoin. Also remember it's only three years to the next BTC payout halving and the coin may not be as desirable at 12.5 per block unless the price has risen quite a bit. This may make Bytecoin, with it's 1:1 copy a popular alternative to investors. What do you say, $50-$100 per BTE in three years? Better to moderately mine now than screw up the blockchain to suit a few greedy opportunists.
Just my 0.02 BTE.
i can agree but the diff is something that needs to be looked at, im thinking of setting the diff to be a static value at the hard fork so we can bring it down to a normal level
The whole point of Bytecoin is that it's a pure copy of Bitcoin. Making it different turns Bytecoin into one of the million other alt coins around here. Plus if merge mining is successful then the difficulty retarget will become a smaller issue than at present.
is there anything u guys think i should add in?
Jump to: