We have the merged mining ready - we are testing now. Will be online soon.
Let me know if you need a tester for p2pool  |
|
|
|
I'd have a little more confidence in this bitstellar situation if they had spelled "cloud" properly. All we need is another "Could Mining Solution" - where yet another ponzi "could" have physical equipment that "could" be mining. Sorry, I couldn't resist! You mean you cloudn't resist........  |
|
|
|
Expect the same problem soon with the AntS5
Kano, are you working your magic on a new S5 update similar to the excellent S3 one? If so, you sir are a legend..... |
|
|
|
Sold out... my ass!
Absolutely this. So now you know where all the first gen hardware really went, straight to their partners/sister company to launch yet another cloud mining ponzi scam. Seems Sfards have decided to follow in the footsteps of Bitmain & others after all, right down to their non-communication & zero updates. Unfortunate, but not surprising  |
|
|
|
Always nice to get one of those "surprise" blocks Seems to be a lot of miners panicking on other pools due to bad luck recently, which makes it even sweeter |
|
|
|
Relax guys, this is how it is when you're mining, always has been & always will be. If you're looking for a continuous, steady income - you're in the wrong game Good days & bad days, lucky & unlucky streaks, it's normal |
|
|
|
|
So, the infamous anti Bitcoin bank that closes customer accounts that use Bitcoin now say they are pro Bitcoin? Nah.
Barclays are evil & not to be trusted, like all UKofA banks.
|
|
|
|
Proposed Myriadcoin changes
posted 3 hours ago author 8bitcoderMyriad - stickied post
Over the last few months various proposals for changes to Myriadcoin were made here, on bct and on irc. After discussion with Myriad members and developers, the following changes to Myriadcoin are proposed:
1 - Implement auxpow and enable for SHA and Scrypt.
This will allow SHA and Scrypt to be merge minable. It increases the security of the block chain by having high difficulties on the ASIC algo's.
2 - Increase block time from 30s to 60s
This will decrease block chain bloat, give transactions more time to propagate in the networks without too much of an increase in confirmation times.
3 - Modify the chain work calculation to use a geometric mean instead of an arithmetic mean across algos.
There are security advantages to using this method, as previously proposed by MentalCollatz.
4 - Reduce block reward
Cut reward from 500 MYR to 50 MYR per block, with the reward increasing by 1 MYR every two years.
This will reduce the current high inflation in Myriad. https://www.reddit.com/r/myriadcoin/comments/3d0ml7/proposed_myriadcoin_changes/I like this, good idea. Is there a time frame for when merge mining will be implemented? |
|
|
|
Maybe isnt only one user (i didnt say that 20ph is one person)
There are so many newcomer in bitcoin mining in every countries.
They always search pool that give high payout and less fee.
Or maybe bitmain moved 20 ph somwhere else to keep decentralization propaganda allive  Or maybe miners are starting to realize that this & a few other large pools that are churning out empty blocks are harming the Bitcoin network, & are making an ethical decision to mine at a pool that is beneficial to Bitcoin........maybe...... https://bitcointalk.org/index.php?topic=1085800.0 |
|
|
|
LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network.
You & me both! I couldn't understand why it was happening, then I realized that the other merge mined coins were also connecting on port 127.0.0.1 & it hit me when I read about the default rpc being set at 4 - what a plonker I am!  Still, if nothing else - I've just learned something more & you've tuned the relaynetworkclient even more in your search for a solution....... Thanks Matt, & sorry to have wasted your valuable time  Edit: I'm still confused as to why it has only recently started causing problems though, it ran fine since the beginning........ |
|
|
|
aha ok cool cheers No problem. Suggest you change the default address to the one you are mining with on a separate wallet if possible. Then you will see the correct payment due in the default payment stats to the wallet address you specify |
|
|
|
No. The default address is your bitcoind that p2pool is connected to & that p2pool generates when first connected. It's always safer to not have any coins in that wallet anyway. As long as one/all of those bitcoin addresses listed on your node stats page is yours then you're good to go. Everything is fine, really Edit: If you want the default payment address to be a different wallet (safer) you can change it by adding: ..to the p2pool startup command. |
|
|
|
ben mininig for 1.6 days now and still Payout if a block were found NOW: 0 BTC what does this meen ? do i need more THS?
here is the link to the node : 85.165.223.226:9332
I think it means you are not mining to the default address. You currently have 2 miners mining on your node, both using wallet addresses. If these are your only miners then it's all good. Your latency & efficiency are all good also. Only the 1% fee your node charges miners will be paid to the default address. |
|
|
|
I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
I suspect this has more to do with transaction flooding on the network and new versions of the relay network client than new versions of bitcoin. PM'd you ping & trace results from my router. Edit: latest release compiled without issue & running. Still getting disconnects, but far less frequent: Sent transaction of size 427 to relay server
Received transaction of size 427 from relay server
Sent transaction of size 427 to relay server
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Connected to relay node with protocol version sponsor printer
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road Edit2: I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using: ...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed I'll keep an eye on it, but hopefully this info will prove useful to other merge miners. |
|
|
|
I'm still getting disconnects I'm afraid, but not constant as before:
Strange, the server logs just shows you disconnecting. Can you run Wireshark? It looks like your outbound bandwidth may be saturated by the uploading of transactions (its quite small), though I would expect your client to print errors about the buffer blowing up. I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously. |
|
|
|
I'll take up that bounty.
EDIT: I'll throw in an upgrade to btc 0.10? free of charge
Ahmed
Any news? |
|
|
|
I'll take up that bounty.
EDIT: I'll throw in an upgrade to btc 0.10? free of charge
Ahmed
Any news? Did the dev get back to you? |
|
|
|
Got it up and running whit the code you provided. it works on windows you just have to cmd to the folder where p2pool is then use the code along whit it . Thanks guys for the help node up and running =)
Well done! Welcome to the decentralized "in crowd" |
|
|
|
Good man JB Is this the only wallet you've had to do this with? |
|
|
|
It might be the version of glibc I'm using... I'm looking into this avenue.
Ah yeah, I remember you installed a funky version of that while trying to get the relaynetworkclient running - I never installed it, so there's a good chance that's the cause of the problem...... |
|
|
|
|
Show Posts
