The exact same thing happen to me yesterday. Around 5000 EUR was drained out of my account.
First everything was transferred to BTC->XMR and afterwards traded on pairs with almost no liquidity.

I was completely sure my account was secure. Still have no idea how someone could access my password.

It doesn't help that Poloniex requires you to click a link in an email to withdraw. This gives you a false sense of security.
I was considering this to be my 2FA and never taught about this attack vector with low liquidity pairs.

I'm sure many more people fall victim to this attack that are not posting here. It's also a bit discouraging that Poloniex doesn't show even a bit of interest in fixing or informing users that this can happen. There are many simple things that they could do, just requiring an email confirmation when you first time trade something "strange". They have insight into the whole system, fraud detection should be one of their priorities. This looks like the most common attack right now.

I was lucky as I will survive without this money, but many others could have their lives destroyed. It's also sad to see the community react in such a victim blaming way. Saying, you should have done this or you should have done that. Why are you not as smart as me? Don't keep your money on an exchange!

This is not really helping anyone. We are all humans. Sometimes we forget to set up something (I should definitely change the brake-fluid in my car) or make mistakes. Why don't we work together to try to fix problems and save others? It's not someones fault to assume he is not going to get robbed.

During the GalacticTalk content creator challenge many reviews have been written about Stellar Wallets. If you need more information to choose one, here are some links:

Stellar Desktop Client & Stargazer desktop
Centaurus, Stargazer mobile & Lobstr
Stellar Term & Ecliptic

Only 15 days left to participate in the Galactic Talk content creators challenge. Don't miss out on winning up to 800.000 XLM.
https://galactictalk.org/d/48-galactic-talk-content-creators-challenge

Hi,

Bernard from solorider.io here. Thanks for the interest in our pool.
Still didn't have an official launch, but we are getting there. Even during this "beta" we have over 400 miners connected to our pool and mining without hiccups.

We are constantly improving our technology. As we developed our networking layer from scratch we had an opportunity to use top of the class technologies to assure highest performance possible. Now we are indeed focused more on the frontend and giving our users the best overview with most useful statistics.

Before our official launch we are implementing a 0-trust API, where miners can check that the coinbase provided by the stratum protocol is actually their address removing any need to trust our pool.

And many more things are coming in the near future.

I see that many people here don't understand the core ideas behind Stellar/Lumens.
Calling it pre-mined when there is no actual mining going on and smilier misunderstandings.

I wrote an overview of Stellar if someone is interested in learning more about it:
https://galactictalk.org/d/1-start-here-everything-you-need-to-know-about-stellar

Regarding the price of Lumens. When the Bitcoin giveaway was announced the price already adjusted. I think it was a 20% drop.

Many people will not claim the Bitcoin reward and many Bitcoins are already lost (Satoshi's coins). So you should worry more about the October giveaway:
https://www.stellar.org/blog/build-challenge/

And I think Jed said somewhere this will be the coins not claimed now. So Stellar.org is only expecting 1B to get to users now.

Usually the trading volume is not too high for Lumens, but if you look at last week it exploded and the price increased again 20%.

Obviously someone was buying a big amount until exhausting the "cheap" supply.
With such love liquidity it's impossible to predict how the price will behave in the future.

Also note that Stripe bought 2 billion Lumens for 2 million USD:
https://stripe.com/blog/stellar

What results in a price of $0.0015 per Lumen. If you look at the last 6 months you will see that the price was always fluctuating a bit above this value.

So please check everything before trading Lumens. You don't want to end up in a margin short while some financial institution is buying a few millions.

I see a lot of people suggesting it's a good time to buy.

How about everyone just takes a walk instead? No need to risk anything. Just get away from the computer sit next to the river and relax.

I hope people are not that blind on this forum. You can't make up some numbers and claiming that's what the price should be.
100% of posts here claim the same with 0% evidence.

It could be that we are now extremely overpriced and the price is correcting itself and will get lower over time until ti reaches real market value. Be aware, you are not investing, you are gambling.

It was a https://mailinator.com/ generated email, but should still work.

I pointed around 150 Th/s at it. The reject rate looks fine and the auto diff adjustment went to 8k and also looks fine.

Yes, I had a look at the wiki.


Why do we send mining.set_difficulty in this case? Only to show the client we support this method?

I saw other examples that don't do it, only send back mining.notify. I guess the mining.notify subscription id is useful to resume the connection if it drops (I can't find now the method used by the client to do so, but I'm sure I saw it once).

And I can't think of any use case of the mining.set_difficulty subscription id. What was the original idea behind it?

In this case the default difficulty is 1 until the server sets a higher one, right?

In the end wouldn't it make much more sense to set the difficulty per worker if we already support multiple workers per connection?

I have a question about the mining.set_difficult method.

In the example here https://mining.bitcoin.cz/help/#!/manual/stratum-protocol

the first time the parameter here is a string (I would say it's the target), but the second time its a number.
Is it supposed to be a string only if it's a result to mining.subscribe or should the client handle both?

Another question is about the result to mining.subscribe. Can the result have an arbitrary number of [method, params] pairs or am I missing it completely?

Hi,

I have some money on NiceHash that I used for personal testing. I could throw some power at you.
After registering I never got an email and can't login without verifying my email address. You should check this out.
And also during the registration my token expired (less than 2-3 min), this was a bit annoying.

Are you using an already existing solution, because I'm sure I saw this web interface before.
Or are you implementing the backend and protocol from scratch? I just finished implementing GBT and stratum servers, but now I'm thinking of rewriting both with an unified interface. Because the documentation is all over the place and some of the extension are not well defined maybe we can compare notes on it

How much of stratum do you intend to support?
Do you have any testing with different miners and how well they work with your implementation?

Your terminology is a bit off and I'm not sure what you mean with "hashes" and "clicks". I will try to write a short explanation if it helps.

All miners connected to the pool are mining for the pool. So if anyone finds a block the block will belong to the pool (gets paid out to the pools address).

Now the pool has the responsibility to split the reward (25btc currently) between miners depending how much work (hashpower) they put in to find this block. Usually this is done by pools setting a lower difficulty for the miner when sending them jobs. Miners will send back results (called shares) earlier when they find a block matching the lower difficulty set by the pool. The pool will count this shares as proof that the miner actually did the work.

Shares are like real blocks that just don't match the full target (difficulty). One of those shares will actually match the current real difficulty and the pool will submit it as a valid new block.

Different pools use different ways to count the shares (determine your payout) and you will see terms like PPS, PPLNS, ....

You can find more information on wikis:
https://en.bitcoin.it/wiki/Mining_pool_reward_FAQ
https://en.bitcoin.it/wiki/Pooled_mining
https://en.bitcoin.it/wiki/Why_pooled_mining

The hashrate is on a steep curve going up right now and it looks like each week a new mining data center is announced. I personally would wait a bit now before investing into mining hardware.

Thanks for checking it out and sorry about this. I didn't get any feedback here and didn't bother to update the post with development progress.
I did now (see first post again). Basically the biggest change is that you specify your payout address as part of the domain name.

Hi,

I'm working on a new pool software and I need your help to test it.
I would really appreciate if you could point a miner to my pool for a few minutes.

Mostly I'm interested in this questions:
1. Does the miner pick up correctly work?
2. After 2-3min the miner should get the right difficulty and submit shares on average every 5sec?
3. Does the web interface display correct information about the miner?

The testing pool I set up points to testnet so don't throw too much hashing power for too long at it.
And you need to use a tetnet address as part of the domain name and your username.
If you don't feel like generating one here are some random to choose from:

n13929Pf1DBebZZPMQyuZtkDXF3L4wXEkT
mgL9sWu1rAdyuuDjYMk6fRyFKSaNea22TM
mw6sRqMTDm9qqLuB4gH8DZkQunuQp23pV9
mnanrpuUok6jmbwYBovHc172MDwWoVqA1d
myNKMAEXnR6TUsX3ZirKEmf86VBMsRfrw6

Point the miner to: http://<testnet-address>.encrypt.li:7
username: <testnet-address>
password: <miner-name>
e.g. cgminer -o http://n13929Pf1DBebZZPMQyuZtkDXF3L4wXEkT.encrypt.li:7 -u n13929Pf1DBebZZPMQyuZtkDXF3L4wXEkT -p fastAsic

Use the web interface to get data about the miner
e.g. http://n13929Pf1DBebZZPMQyuZtkDXF3L4wXEkT.encrypt.li

For now I only support GBT and no stratum .
Does anyone know a cloud mining website like nicehash, but that is not stratum only?
I would like to rent some hashing power for future testing.

As I said, I would be grateful if you took some time and gave me feedback here.

Cheers!

UPDATE:

If somebody finds this googling and is looking for a similar solution.
Luke-Jr suggested to me on reddit to proxy NiceHash to GBT with bfgminer's --stratum-port option.
Because of some special requirements NiceHash has you will need to recompile bfgminer and change some hardcoded  stuff (extranounce2 size & difficulty) to accomplish this. I never got it really working. Everything looked fine but the shares never arrived to the GBT server. But I guess if you need to test GBT with some strong hashing power this one of the options.

After spending 2 days debugging getblocktemplate requests my conclusion is:

Most mining software implements a subset of GBT to make it work for them and doesn't follow the standard strictly.
Miners also introduce some other rules in agreement with pools that are not documented.
If you are working on a pool you will have to manually test it against miners to be sure it works (good luck).

I couldn't get cgminer to work with my pool proxy. The problem is that it differentiates between solo and pool mining (what I don't think is part of the getblocktemplate specification). After reading the source code I found this https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L6512. So, cgminer will only treat you as a pool if you submit "coinbase/append" and "submit/coinbase" as mutables. This is not really explained anywhere and it took me some time to figure it out. I can understand the idea behind this choice, but it still looks a bit arbitrary to me. It will just reject you with a message that you are not a pool without clarification. I can see users breaking their head over this.

To answer some of the questions myself after 2 days of researching:

1. Stratum is much better defined and smaller. It is also more popular between pools. This makes it easier to implement and find information about. It's straight forward, there is basically only one way to do it. You loose some flexibility, but at least you don't need to deal with the mess of BIP22 and BIP23. I will try to write a tutorial how to implement GBT correctly if I find time.

2. Because of cgminer behavior the proxy needs to do much more. Now it needs to understand "submit/coinbase" and keep track of the transactions submited to the miner. It makes it more complicated. But using a bitcoin node to get information from the network and not implementing your own is still a good idea.

I didn't get to experiment with setting the difficulty. I hope I will soon have a proof of concept pool running on testnet to try more advanced stuff.

P.S. What is wrong with you guys? Accusing me of scaming. Casually requesting me to send you 25btc. Promoting your own pools. From my perspective this doesn't look like a welcoming community.

I don't think I will be running a pool. I'm far from having anything working yet, as you can see from my questions.
I just have some technical questions and this discussion is already diverging.

Now I realise that maybe I'm posting in the wrong subforum.
Would Development & Technical Discussion be more appropriate?

I'm developing a pool software and would like to test it against a fairly modern GPU miner on testnet.
Everything that I found is super outdated and braking most of the time.

I currently don't have an ASIC, this makes real testing impossible.
So I figured out that maybe using a GPU on testnet would work (difficutly arround 4TH/s).

Is there maybe a software only mode for cgminer? Just to check if ti picks up jobs correctly from my pool?

Regarding question 5, I guess the bitcoin client will always answer with coinbasevalue because he expects you to solo mine and you need to provide your own address. Now I built a little proxy to intercept the answer and populate the value coinbasetxn data field and remove coinbasevalue. But if I run cgminer against it he complains with "No BTC address specified, unable to mine solo on http://127.0.0.1". Shouldn't he already have an address that is part of coinbasetxn. Why would I need to specify another one?

Hi,

being fairly new to mining pools I wanted to clear some doubts about the approach I'm taking.
I hope that experienced pool developers will be able to point me in the right directions.

Here is my set of questions:

1. I would prefer to use the getblocktemplate protocol instead of stratum. Are there any non-obvious drawbacks in doing so? Do all popular miners support it correctly?

2. For the beginning I would just use a regular bitcoin node and a proxy before it. The proxy would ask the bitcoin node for work and update all miners. Does this sound like a good approach?

3. I guess the bitcoin node also provides the current network difficulty so I would need to change the getblocktemplate in the proxy, lowering the difficulty so miners can actually produce shares. In this case I would keep track of submitted shares with the proxy. Does this sound good?

4. As in BIP23 (https://en.bitcoin.it/wiki/BIP_0023#Basic_Pool_Extensions) explained, the miner can request a new target. Do miners use this? Are they good at choosing the perfect target? Would it be better to adjust the target on the server depending on the shares received from the miner and ignore this?

5. Playing around with bitcoin-qt I noticed when using getblocktemplate and submitting coinbasetxn as one of the capabilities the server answers me with a coinbasevalue and not coinbasetxn. Contrary to the documentation in BIP22 (https://en.bitcoin.it/wiki/BIP_0022#Block_Template_Request). Is this a bug or am I missing something? And it's not really clear to me if I just forward the information without coinbasetxn to miners will they be able to do their work. This whole process of generating coinbasetxn in getblocktemplate is a bit unclear and confusing. Would be great if somebody took the time to explain it.

And of course I would appreciate all other suggestions you have and stuff I maybe missed/overlooked.

Cheers,
Bernard