|
Terracoin (TRC) is undergoing a re-vamp & are considering integrating merge mining. One of the older coins, I think it would benefit greatly from this - please drop by their thread where they have a poll for merge mining implementation & show your support.
Thanks.
|
|
|
|
|
I've now been running 24 hours with the latest git version & all seems good. The error message seems to have stopped & efficiency is back to normal again.
Good stuff.
|
|
|
|
Is this functional but just not actively maintained? Don't want to put effort in to getting up and running if it won't connect anywhere.
It's working fine. |
|
|
|
I wish we could know more about what SP-Tech actually intends on doing moving forward from them instead of the usual forum bullshit speculation.
That would be nice eh?  |
|
|
|
I will set up a poll about merge mining!
I was under the impression that merge mining was already decided. Changing this due to one or two persons not understanding how merge mining works does not set a good president, plus people are not likely to vote for something they do not understand. I have mined TRC for a long time now, but it has remained stagnant due to a lack of bringing anything new to the crypto table - it just doesn't have anything to entice miners to it. Enabling merge mining will change this. Personally, I want this coin to grow, but if it stays the same - that's OK too, but it will remain stagnant in it's current form unless merge mining is enabled. |
|
|
|
Announcement: We will withdraw support from February 21’s roundtable consensus, unless Adam Back gives us a reasonable explanation why he quietly changed his title from Blockstream President to Individual at the very last moment — without anybody noticed. We feel we’ve been cheated. I don’t know how we can trust Blockstream anymore in the future.
Feel free to start your own coin then - enjoy your own empty blocks. Bye. |
|
|
|
I don't understand why you want merge mining. If we can improve the difficulty adjust algorithm, security will be better. All the other independent coins don't have merge mining.
I'm not sure what merge mining has to do with independence. All coins are independent weather they are merge mined or not, you don't have to merge mine it, it's just another option that will bring in more miners & thus help secure the network & attract a wider user base, which is important if a coin is to become successful. One question: If merge-mining is enabled, everyone will do merge-mining or not? Otherwise he will lose money? If so, once TRC merge-mined with BTC, huge mining power will be thrown on TRC. In this case, personal mining will be obsolete. P2Pool could also be obsolete if there's no one works on the merge-mining option of p2pool server. We should allow user to use their low hash machine (e.g. < 1T) to mine TRC otherwise it will not gain interest from ordinary people or newbies. I will not against it if it's most people's decision, and you all know the downside of merge-mining. If merge-mining is enabled, everyone will do merge-mining or not?
No. There are other merge mined coins out there with low hash rates - the coin still has to appeal to miners in the first place. Otherwise he will lose money?
No. How? If so, once TRC merge-mined with BTC, huge mining power will be thrown on TRC.
See above. In this case, personal mining will be obsolete.
That depends on your costs. For many, personal mining has been obsolete for a while. P2Pool could also be obsolete if there's no one works on the merge-mining option of p2pool server.
Merge mining is not just for p2pool, but p2pool is the easiest option for the home (independant?) miner to set-up merge mining, which is what you seem so concerned about. P2pool does not use a server, the nodes are the "servers" as you call them - it is completely decentralised, which adds to the security of the network. Also, TRC is already listed in the p2pool coins networks (although this might need to be updated depending on what changes are made to TRC, if any) We should allow user to use their low hash machine (e.g. < 1T) to mine TRC otherwise it will not gain interest from ordinary people or newbies.
Anyone can mine it with any amount of hash at any time, weather it is merge mined or not. The fact is, the more miners that mine it (or any other crypto), the higher the diff will go - that is a fact of mining. If you want a coin that has permanently low diff, you will have to create a coin that nobody knows about & mine it yourself - it will of course be worthless, because nobody knows about it or mines it. ...and you all know the downside of merge-mining.
Please explain it to "us all". As I have already pointed out, not one single coin has failed due to merge mining, they have all benefited. How many coins have failed that aren't merge mined? Hundreds, with more following suit every week. |
|
|
|
I don't understand why you want merge mining. If we can improve the difficulty adjust algorithm, security will be better. All the other independent coins don't have merge mining.
I'm not sure what merge mining has to do with independence. All coins are independent weather they are merge mined or not, you don't have to merge mine it, it's just another option that will bring in more miners & thus help secure the network & attract a wider user base, which is important if a coin is to become successful. |
|
|
|
Regarding this: There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low. https://github.com/p2pool/p2pool/issues/274I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out. |
|
|
|
Sorry, but IMHO forrest was referring to tampering with the p2pool settings, namely
Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though. |
|
|
|
Fixing this issue will likely require a hard fork of the p2pool share chain.
It looks like that's what will be needed then, as it seems that most (80%) of the hash rate has finally come to an agreement with Core to increase the blocksize: http://www.coindesk.com/bitcoin-miners-back-proposed-timeline-for-2017-network-hard-fork/So I'd recommend v0.12 (classic or core, up to your taste) to every p2pool node out there. I use in the bitcoin.conf on my node and don't have any problems with orphan rate or tx errors. According to forrestv on github: I wouldn't recommend for you to change that value. Depending on where the problem is, it could either work or split you off from the P2Pool network.
...which I think is what happened to me & I had to re-download a new sharechain. If it works for you, that's great, but I'll take forrestv's advice & keep it at the default setting of 750000 until/if the problem has been fixed. |
|
|
|
We need more Pools for DubaiCoin-DBIC, if interested please contact us!
You will need to provide the source code. |
|
|
|
blockmaxsize=1000000
I don't get it - if p2pool can only handle blockmaxsize of 750000, how can setting it to 1000000 in bitcoin.conf be beneficial? Wont that cause problems? Thanks. |
|
|
|
There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low. https://github.com/p2pool/p2pool/issues/274As Bitcoin Classic sets the default block size limit to the largest allowed by the consensus rules, this can result in Bitcoin Classic nodes failing to produce valid shares. Consequently, if you run Bitcoin Classic with p2pool, you should use blockmaxsize=750000 or lower in your ~/.bitcoin/bitcoin.conf. Hmm... not much good using a fork designed to increase the max blocksize limit if you can't... increase the max blocksize. I see the issue was brought to forrestv's attention over 5 months ago on github - it would be nice if he followed it up or privided some additional info/update..... |
|
|
|
Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.
Did you use the binary or compile from the 0.12 branch? (which is what I did btw)
I complied core rc3 and the classic 12 branch, both run fine with significantly lower getblocktemplate latency... Edit: see jtoomim's comment above, I run at 750000 on my test node so did not test larger Is it the same problem with Core as well? |
|
|
|
|
Think I'll wait until the official release & try again, I hate re-downloading the sharechain....lol It's running nice again now, so I'll let it ride.
Did you use the binary or compile from the 0.12 branch? (which is what I did btw)
|
|
|
|
Running Core v0.12 I got loads or these errors: 2016-02-19 17:55:11.831105 > Error while processing Event callbacks:
2016-02-19 17:55:11.831211 > Traceback (most recent call last):
2016-02-19 17:55:11.831237 > File "/home/rig/p2pool/p2pool/util/variable.py", line 74, in set
2016-02-19 17:55:11.831263 > self.changed.happened(value)
2016-02-19 17:55:11.831287 > File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.831311 > func(*event)
2016-02-19 17:55:11.831335 > File "/home/rig/p2pool/p2pool/node.py", line 243, in _
2016-02-19 17:55:11.831360 > self.mining_txs_var.set(new_mining_txs)
2016-02-19 17:55:11.831383 > File "/home/rig/p2pool/p2pool/util/variable.py", line 75, in set
2016-02-19 17:55:11.831410 > self.transitioned.happened(oldvalue, value)
2016-02-19 17:55:11.831434 > --- <exception caught here> ---
2016-02-19 17:55:11.831457 > File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.831481 > func(*event)
2016-02-19 17:55:11.831505 > File "/home/rig/p2pool/p2pool/p2p.py", line 211, in update_remote_view_of_my_mining_txs
2016-02-19 17:55:11.831541 > assert self.remote_remembered_txs_size <= self.max_remembered_txs_size
2016-02-19 17:55:11.831565 > exceptions.AssertionError:
2016-02-19 17:55:11.833002 > Error while processing Event callbacks:
2016-02-19 17:55:11.833105 > Traceback (most recent call last):
2016-02-19 17:55:11.833132 > File "/home/rig/p2pool/p2pool/util/variable.py", line 74, in set
2016-02-19 17:55:11.833157 > self.changed.happened(value)
2016-02-19 17:55:11.833182 > File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.833206 > func(*event)
2016-02-19 17:55:11.833230 > File "/home/rig/p2pool/p2pool/node.py", line 243, in _
2016-02-19 17:55:11.833257 > self.mining_txs_var.set(new_mining_txs)
2016-02-19 17:55:11.833280 > File "/home/rig/p2pool/p2pool/util/variable.py", line 75, in set
2016-02-19 17:55:11.833304 > self.transitioned.happened(oldvalue, value)
2016-02-19 17:55:11.833327 > --- <exception caught here> ---
2016-02-19 17:55:11.833351 > File "/home/rig/p2pool/p2pool/util/variable.py", line 42, in happened
2016-02-19 17:55:11.833374 > func(*event)
2016-02-19 17:55:11.833398 > File "/home/rig/p2pool/p2pool/p2p.py", line 211, in update_remote_view_of_my_mining_txs
2016-02-19 17:55:11.833421 > assert self.remote_remembered_txs_size <= self.max_remembered_txs_size
2016-02-19 17:55:11.833445 > exceptions.AssertionError: ...& my DOA/Orphan rate was quite high - anyone else experience this? Since going back to the previous master branch the errors have gone & my DOA/Orphan rate is fine again. |
|
|
|
What coin were you guys thinking about? BTC? If say, we decided to merge mine with a coin and it failed would we have to hard fork again to switch to another merge mined coin?
When a coin is merge minable, the user can choose almost any SHA256 coin to mine it with, not just BTC. So no, if any coin fails it makes no difference to TRC. Hi can you point to some good guide on merge mining? There are 2 guides on this forum, but they are quite outdated so should not be taken literally, but as guides they are OK: https://bitcointalk.org/index.php?topic=651819.0;topicseenhttps://bitcointalk.org/index.php?topic=62842.0If you are familiar with p2pool you should be OK. |
|
|
|
|
No buyers on Cryptopia?........
|
|
|
|
|
Show Posts
