|
Some times, the price follows volume. Number of transactions is an indication of volume.
|
|
|
|
Usually if bitcoin goes up, altcoins go up too.
That happens when bitcoin goes up a lot and for some time. |
|
|
|
|
Some people in the north mines as it generates free heat.
|
|
|
|
|
None of the altcoin will reach $500 within two years.
|
|
|
|
All that is needed is a grand economic event such as Europe collapsing. A few million people looking for a safe place to put their money. That event may be sooner than later.
This happened when Cyprus collapsed about two years ago. The price shoot to £266. |
|
|
|
They will be the Rothchilds of the 21century.. all because the real Rothchilds have absolutely no idea of whats going on outside their circles.
Rothchilds control and manipulate the market. They are not there yet. |
|
|
|
|
GPU or CPU mining for certain coin is still profitable is your electricity price is low. ASCII mining is usually not because large farms are situated in low electricity area.
|
|
|
|
|
If you want to mine profitably, you have to pay to buy a miner. The donations are not enough to keep fast miners public.
|
|
|
|
.....This is worth 20KH/s on my 280X......from 343KHs to 363KH/s at 1020MHz clock .....now somebody needs to find 20KH/s more for me....  change the XORBytesInPlace call from XORBytesInPlace(B + bufidx, input, BLAKE2S_OUT_SIZE);
to XORBytesInPlace(B + bufidx, input, bufidx);
and change the function itself to perform some byte alignment checking //
// a bit of byte alignment checking goes a long ways...
//
void XORBytesInPlace(void *restrict dst, const void *restrict src, uint mod)
{
switch(mod % 4)
{
case 0:
#pragma unroll 2
for(int i = 0; i < 4; i+=2)
{
((uint2 *)dst)[i] ^= ((uint2 *)src)[i];
((uint2 *)dst)[i+1] ^= ((uint2 *)src)[i+1];
}
break;
case 2:
#pragma unroll 8
for(int i = 0; i < 16; i+=2)
{
((uchar2 *)dst)[i] ^= ((uchar2 *)src)[i];
((uchar2 *)dst)[i+1] ^= ((uchar2 *)src)[i+1];
}
break;
default:
#pragma unroll 8
for(int i = 0; i < 31; i+=4)
{
((uchar *)dst)[i] ^= ((uchar *)src)[i];
((uchar *)dst)[i+1] ^= ((uchar *)src)[i+1];
((uchar *)dst)[i+2] ^= ((uchar *)src)[i+2];
((uchar *)dst)[i+3] ^= ((uchar *)src)[i+3];
}
}
}
Later you said Very interesting. I get about 2% gain on 7950 and need to use (mod % 2) with the case statements adjusted accordingly.
My 280X gains almost 6% as is, but the gain difference between (mod % 2) and (mod % 4) is pretty small, like 1-2 KHs
When you used (mod %2, same as mod &1), what are the case statements inside XORBytesInPlace(void *restrict dst, const void *restrict src, uint mod)? |
|
|
|
Lots of new investors including BBVA, a bank
So material change of shareholder base
A Spanish bank is good for the adoption in Spain and southern Europe. |
|
|
|
Very interesting. I get about 2% gain on 7950 and need to use (mod % 2) with the case statements adjusted accordingly.
My 280X gains almost 6% as is, but the gain difference between (mod % 2) and (mod % 4) is pretty small, like 1-2 KHs
My SMix call is a bit different, I simply put the sub-calls inline so it doesn't bother with ScratchpadStore and ScratchpadMix.
Perhaps this fits nicer into the core and needs less swapping.
I have tried, unsuccessfully, to further streamline the SMix, but any other way I do it, its either all HW errors or vastly slower. Any guidance here would be appreciated.
How do you adjust the case 2 accordingly? (number % power_of_two) should be a shooting offense when coding for a brain dead compiler. Do you mind telling us how to do it? (number & (power_of_two - 1)) of course. A bit more detail for non programmer? |
|
|
|
Very interesting. I get about 2% gain on 7950 and need to use (mod % 2) with the case statements adjusted accordingly.
My 280X gains almost 6% as is, but the gain difference between (mod % 2) and (mod % 4) is pretty small, like 1-2 KHs
My SMix call is a bit different, I simply put the sub-calls inline so it doesn't bother with ScratchpadStore and ScratchpadMix.
Perhaps this fits nicer into the core and needs less swapping.
I have tried, unsuccessfully, to further streamline the SMix, but any other way I do it, its either all HW errors or vastly slower. Any guidance here would be appreciated.
How do you adjust the case 2 accordingly? (number % power_of_two) should be a shooting offense when coding for a brain dead compiler. Do you mind telling us how to do it? |
|
|
|
The explaination is simple, payment processing companies and other ones that accept bitcoin dump once a week most of the times.
I do not think so. Your source? |
|
|
|
Chasers gonna chase. And if btc has a deadcat bounce... well, just imagine it's not the ordinary cat. It's highly volatile and very subject to emotions and China and who knows what. I don't think that any one assignment of blame for the price of btc has ever been entirely accurate... well maybe obvious ones like mtgox but for the most part it's volatile just because.
It is volatile because it is new, uncertain and speculative. As time goes on, it will be less volatile and used more. |
|
|
|
You guys are seriously going to trust a brand new account posting something like this? The price is on the increase but it's very steady at the moment, nothing dramatic is going to happen yet, I'm expecting it to return to $300 - £350 and stay there if nothing goes horribly wrong.
That is my hope too. Stable price is what we want. |
|
|
|
I think we will stabilize on or around 200 for now. We need to really be 250+ to be comfortable with the way cloud mining and other bitcoin economy is right now
this is really what is need to happen. It has just happened. |
|
|
|
Very interesting. I get about 2% gain on 7950 and need to use (mod % 2) with the case statements adjusted accordingly.
My 280X gains almost 6% as is, but the gain difference between (mod % 2) and (mod % 4) is pretty small, like 1-2 KHs
My SMix call is a bit different, I simply put the sub-calls inline so it doesn't bother with ScratchpadStore and ScratchpadMix.
Perhaps this fits nicer into the core and needs less swapping.
I have tried, unsuccessfully, to further streamline the SMix, but any other way I do it, its either all HW errors or vastly slower. Any guidance here would be appreciated.
How do you adjust the case 2 accordingly? |
|
|
|
The price is volatile. When it gets more used, adopted, the price will be stable.
pipedreams Bitcoin is impotent. If it were potent it would already have shown what is possible but it can't. Poor little Bitcoin suffers from a little inflation. But people like their coins worthless and volatile ... There are more adoptions than 1 year ago. |
|
|
|
|
The price is volatile. When it gets more used, adopted, the price will be stable.
|
|
|
|
Second problem:
Elasticity & The mining/ difficulty adjustment mechanism
Pretty flawed in my opinion, here's why:
If the demand for mining is lacking, due to small prices ( as miners wont mine if the incentive is small/ the profit margin)
, then the difficulty will decrease ,yes ? Yes.
A decrease in difficulty will mean that, the other miners which have better equipment /a.k.a can mine at a cheaper price, so their profit margin is higher, they will keep mining, further more, at a lower difficulty level, they can mine more.
=>WHICH RESULT'S IN: HIGHER INFLATION. => EVEN LOWER PRICES
The mere fact that the difficulty drops due to lack of demand and lower prices, will make the other miners mine more faster, which will create more inflation, and will decrease the prices even further.
This is a huge flaw, I cannot believe nobody saw this before, so this mining mechanism is completely flawed, it will forever decrease the price, as the difficulty will drop, and create more inflation which will decrease prices even more!
The supply of coin is somewhat constant when the difficulty changes. Some miners get more does mean some other miner will get less. The total is the same. |
|
|
|
|
Show Posts
