Topic: Stratum protocol discussion - page 2. (Read 9111 times)
I had found this great Stratum wiki here:
http://electrum.orain.org/wiki/Stratum_protocol_specification
Now when I go to that link it redirects me to the pornhub web site I kid you not - what gives? Sabotage?
For all the talk of documentation in posts / anywhere I'm having trouble finding out how this works and the expected syntax for commands.
Can anyone help with this problem for instance:
http://bitcoin.stackexchange.com/questions/40556/how-do-i-get-merkle-branches-using-the-stratum-protocol
http://electrum.orain.org/wiki/Stratum_protocol_specification
Now when I go to that link it redirects me to the pornhub web site I kid you not - what gives? Sabotage?
For all the talk of documentation in posts / anywhere I'm having trouble finding out how this works and the expected syntax for commands.
Can anyone help with this problem for instance:
http://bitcoin.stackexchange.com/questions/40556/how-do-i-get-merkle-branches-using-the-stratum-protocol
Hello
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Not far above your post:Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
https://bitcointalksearch.org/topic/m.6487037
I will also point out there is not much point looking at the link that 'other' forum member supplied.
It contain bias non-objective information and basically he is given free reign of the wiki to post as he pleases.
This thread is the most reliable source of stratum information:
https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866
A certain forum member's protocol envy means taking too much notice of what he says is a waste of time and on occasion leads to misleading information designed to promote ignorance and bias.
Luke,
Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
It's what he was asking for. And quite often, the bad boys do not know their stuff. Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
Luke,
Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
It's what he was asking for. And quite often, the bad boys do not know their stuff. Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
Luke,
Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit and have the resources required you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
Do you realy think that redirecting a miner after first share will "hide or protect" given server?
Do not get me wrong but in 99% of cases when bad boys know their shit and have the resources required you can not do much about it.
Your ISp is the one who shall take care. And depending how hard ddos is it is not an easy task at all....
Hello
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Stratum already supports that.Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Ok I will re read the documentation.
hero member
Activity: 532
Merit: 500
TaaS is a closed-end fund designated to blockchain
Hello
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Stratum already supports that.Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Ok I will re read the documentation.
The only two things which can stop ddos are:
1. Big pipe
if bad boys have 1g connection your ISP should have at least 2gig as an example
2. Expensive machines to filter out ddos sitting in front of the target, taking the fire and capable of doing that - CPU ram and so on
3. Both 1 and 2
Ports and protocols handshakes do not have anything in common especially when it is UDP flood. As long as UDP is stateless bad boys just fill your connection with crap
When bad boys are clever and if they have the appropriate resources available it is very very hard to stop them
The appropriate resources do cost money. so called "fix" happens when:
1. They are out of money and are not able to "rent" big enough resource to attack
2. They are filtered out in the first hop. Works only when they are using ip's which are not random. In most cases the attack is performed from infected PC's al over the world
1. Big pipe
if bad boys have 1g connection your ISP should have at least 2gig as an example2. Expensive machines to filter out ddos sitting in front of the target, taking the fire and capable of doing that - CPU ram and so on
3. Both 1 and 2
Ports and protocols handshakes do not have anything in common especially when it is UDP flood. As long as UDP is stateless bad boys just fill your connection with crap
When bad boys are clever and if they have the appropriate resources available it is very very hard to stop them
The appropriate resources do cost money. so called "fix" happens when:
1. They are out of money and are not able to "rent" big enough resource to attack
2. They are filtered out in the first hop. Works only when they are using ip's which are not random. In most cases the attack is performed from infected PC's al over the world
Hello
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Stratum already supports that. Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
hero member
Activity: 532
Merit: 500
TaaS is a closed-end fund designated to blockchain
Hello
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
Considering the nature of a pool that "mine" Bitcoins I think we will suffer DDOS constantly and every time more aggressive sophisticated and bigger.
In my opinion the Srtatum protocol may help with some improvements to mitigate the DDOS
May be some features like the Apache/HTTP can be implemented like the Redirect or Temporary Redirect where after connecting the node tells the miner to connect to a different IP:PORT. Before that redirect may require to execute some handshake process that needs to be a heavy process at miner side so will be complex for a DDOS complete the handshake without some significant processing power.
Is not nice, but something has to be done.
Regards
Juan
PLEASE PLEASE PLEASE
REALLY
mining.subscribe needs extension with a third parameter being the requested URL.
WHY IS THIS NOT IMPLEMENTED?
REALLY
mining.subscribe needs extension with a third parameter being the requested URL.
WHY IS THIS NOT IMPLEMENTED?
kano/ckolivas,
I'm working with the guys at NiceHash.com to try and resolve a few issues with how they are managing miners with their stratum pool. In debugging this, I've been reading through the code that implements the stratum client - util.c - and trying to better understand the stratum protocol.
What I'm not quite clear on is the loop/state machine that you use in a mining client to "poll" a pool and attempt to connect to get work.
The NiceHash.com pool uses the password parameter in a mining.authorize to pass in a requested "threshold" for mining payouts. (e.g. I might only want to mine if there are contracts for a minimum of 0.07BTC/TH/Day so my password becomes "p=0.07") When the mining.authorize occurs, they will accept or error my auth based on that threshold comparison.
This is working ... mostly.
The problem we are seeing is that at some later point of time, the miner seems to "hang" or believe the pool is alive. I'm running kano's builds on my AntMiners, and periodically during the day I'll find them attached to the pool, but not getting any work. They think the pool is alive ... the pool is saying they sent an error on the auth.
I am debugging to see if this is pool related, miner related, or protocol related. (Or a little of several?)
What I wanted to know is:
Within cgminer, once a pool is determined to be "dead", what is the delay before the pool is tried again, and what operations (Requests) are retried to "test" the pool for aliveness? Where would I find the code that handles that delay and retrying?
I'm writing here, as I tried to locate and study the protocol documentation to determine what the "proper" process ought to be ... but didn't find too much on the subject. :-)
I'm wondering if a miner like cgminer would be doing : mining.subscribe -> mining.authorize -> error/delay/startover-at-subscribe?
If this is the case, is there any reason to believe that after looping like this - getting errors for a half day or so - the miner might hang?
I'm also glad to take this conversation elsewhere if this is not the appropriate thread.
I'm working with the guys at NiceHash.com to try and resolve a few issues with how they are managing miners with their stratum pool. In debugging this, I've been reading through the code that implements the stratum client - util.c - and trying to better understand the stratum protocol.
What I'm not quite clear on is the loop/state machine that you use in a mining client to "poll" a pool and attempt to connect to get work.
The NiceHash.com pool uses the password parameter in a mining.authorize to pass in a requested "threshold" for mining payouts. (e.g. I might only want to mine if there are contracts for a minimum of 0.07BTC/TH/Day so my password becomes "p=0.07") When the mining.authorize occurs, they will accept or error my auth based on that threshold comparison.
This is working ... mostly.
The problem we are seeing is that at some later point of time, the miner seems to "hang" or believe the pool is alive. I'm running kano's builds on my AntMiners, and periodically during the day I'll find them attached to the pool, but not getting any work. They think the pool is alive ... the pool is saying they sent an error on the auth.
I am debugging to see if this is pool related, miner related, or protocol related. (Or a little of several?)
What I wanted to know is:
Within cgminer, once a pool is determined to be "dead", what is the delay before the pool is tried again, and what operations (Requests) are retried to "test" the pool for aliveness? Where would I find the code that handles that delay and retrying?
I'm writing here, as I tried to locate and study the protocol documentation to determine what the "proper" process ought to be ... but didn't find too much on the subject. :-)
I'm wondering if a miner like cgminer would be doing : mining.subscribe -> mining.authorize -> error/delay/startover-at-subscribe?
If this is the case, is there any reason to believe that after looping like this - getting errors for a half day or so - the miner might hang?
I'm also glad to take this conversation elsewhere if this is not the appropriate thread.
Meanwhile, a permanent change that is part of the solution to the client.reconnect problem at the moment should be:
Require the pool domain and the reconnect domain to match.
There is no need for hard coding IP addresses, since anyone on the planet can own a domain for $10 a year
The reconnect has no need to use an IP address either - for the same reason - DNS records require no effort.
... and anyone wishing to use different domains for different located pools, you simply add a DNS record in the domain of the pool doing the reconnect to point to the other IP address.
DNS poisoning problems are not relevant to this since if there is a DNS problem then the miner can already be directed away from the pool when you first connect.
Sounds fine to me. Require the pool domain and the reconnect domain to match.
There is no need for hard coding IP addresses, since anyone on the planet can own a domain for $10 a year
The reconnect has no need to use an IP address either - for the same reason - DNS records require no effort.
... and anyone wishing to use different domains for different located pools, you simply add a DNS record in the domain of the pool doing the reconnect to point to the other IP address.
DNS poisoning problems are not relevant to this since if there is a DNS problem then the miner can already be directed away from the pool when you first connect.
Meanwhile, a permanent change that is part of the solution to the client.reconnect problem at the moment should be:
Require the pool domain and the reconnect domain to match.
There is no need for hard coding IP addresses, since anyone on the planet can own a domain for $10 a year
The reconnect has no need to use an IP address either - for the same reason - DNS records require no effort.
... and anyone wishing to use different domains for different located pools, you simply add a DNS record in the domain of the pool doing the reconnect to point to the other IP address.
DNS poisoning problems are not relevant to this since if there is a DNS problem then the miner can already be directed away from the pool when you first connect.
Require the pool domain and the reconnect domain to match.
There is no need for hard coding IP addresses, since anyone on the planet can own a domain for $10 a year
The reconnect has no need to use an IP address either - for the same reason - DNS records require no effort.
... and anyone wishing to use different domains for different located pools, you simply add a DNS record in the domain of the pool doing the reconnect to point to the other IP address.
DNS poisoning problems are not relevant to this since if there is a DNS problem then the miner can already be directed away from the pool when you first connect.
Is mining.get_transactions mandatory to be implemented on pool side? Is it safe to simply ignore this client request (send back nothing)?
It can be ignored, but should send back an error if not supported.Does your BFGMiner correctly handle variable sizes of extranonce1 and extranonce2? Can extranonce1 be 5 bytes, extranonce2 3 bytes and shares provided valid?
Yes, any reasonable value (bounded by memory size I think) should work fine, but BFGMiner will only actually use at most 40 bits of extranonce2 right now (32 in most cases).Note that the stratum proxy feature requires at least 24-bit extranonce2 (failure to meet this requirement disconnects all clients and rejects new ones).
Is mining.get_transactions mandatory to be implemented on pool side? Is it safe to simply ignore this client request (send back nothing)?
Question for you Luke:
Does your BFGMiner correctly handle variable sizes of extranonce1 and extranonce2? Can extranonce1 be 5 bytes, extranonce2 3 bytes and shares provided valid?
As you may know already, cgminer from certain X up to certain version Y has a bug there, causing all shares to be rejected.
Question for you Luke:
Does your BFGMiner correctly handle variable sizes of extranonce1 and extranonce2? Can extranonce1 be 5 bytes, extranonce2 3 bytes and shares provided valid?
As you may know already, cgminer from certain X up to certain version Y has a bug there, causing all shares to be rejected.
Meanwhile, having a BIP is clearly not as important as has been suggested.
The code for BIP22 for the centralised GBT mining protocol
(yes, saying it is decentralised is also a lie being spread by Luke and gmaxwell)
was modified by Luke before submitting it to bitcoin
He implemented code that is not part of BIP22 and put it into bitcoin - for support of botnet mining.
https://github.com/bitcoin/bitcoin/issues/1985
Anyway, looks like he still can't handle having the stratum pool protocol mentioned first on the Stratum page and likes to list a bunch of meaning less complaints about it:
https://en.bitcoin.it/wiki/Stratum
The "Displacing GBT" complaint has to be the funniest - how dare someone displace GBT with something that is so much better than it.
Pity it also contains outright lies. But that is to be expected of Luke.
The code for BIP22 for the centralised GBT mining protocol
(yes, saying it is decentralised is also a lie being spread by Luke and gmaxwell)
was modified by Luke before submitting it to bitcoin
He implemented code that is not part of BIP22 and put it into bitcoin - for support of botnet mining.
https://github.com/bitcoin/bitcoin/issues/1985
Anyway, looks like he still can't handle having the stratum pool protocol mentioned first on the Stratum page and likes to list a bunch of meaning less complaints about it:
https://en.bitcoin.it/wiki/Stratum
The "Displacing GBT" complaint has to be the funniest - how dare someone displace GBT with something that is so much better than it.
Pity it also contains outright lies. But that is to be expected of Luke.
Meanwhile we have the retard doing rubbish like this to try blocking the dissemination of information about Stratum:
https://en.bitcoin.it/w/index.php?title=Stratum&action=historysubmit&diff=46202&oldid=46194
https://en.bitcoin.it/w/index.php?title=Stratum&action=historysubmit&diff=46202&oldid=46194
I cannot rationalize those changes, short of malice.
Meanwhile we have the retard doing rubbish like this to try blocking the dissemination of information about Stratum:
https://en.bitcoin.it/w/index.php?title=Stratum&action=historysubmit&diff=46202&oldid=46194
https://en.bitcoin.it/w/index.php?title=Stratum&action=historysubmit&diff=46202&oldid=46194
Jump to: