A: Botnets can only easily gain control of computers run by those who are not technically savvy. Non-tech-savvy people very RARELY run powerful GFX cards. The Botnet owner would need thousands of computers in the Botnet to hope to achieve the power of a couple dozen powerful computers, or even a dozen duel-GPU systems.
That's a pretty sweeping assumption... Are you saying all gamers are tech savvy? I know plenty of die hard gamers that still think RAID-0 keeps their data safer because it's got RAID in the name. B: Accessing the GFX card is one of the most difficult operations to do remotely, meaning this would only be achieved by a small minority of genius programmers capable of writing and constantly rewriting code to keep up with the nuances of security that gets in the way of accessing the GPU. In almost all cases, even these Botnet owners would be lucky to access even half of the GPUs in their Botnet.
bollocks... I can download, configure and start a GPU miner from the command line. From the command line I can check for signatures in the registry to detect the graphics card driver, I can download and install the appropriate OpenCL SDK. None of this is hard for someone capable of writing the code for a botnet. C: Mining requires very high levels of GFX performance. The Botnet operator would need to either choose between having the GPUs in the Botnet run at full speed (causing both system slowness and crashes that would encourage the non-tech-savvy person to either buy a new computer or reformat the OS, likely increasing security as they do so, removing their computer from the Botnet. OR, the Botnet operator would have to run the GFX cards at a slow enough pace not to interfere with performance on these lower-end machines, which means conservatively 25% utilization at maximum to avoid the owners resetting their systems to factory spec and wiping away the Botnet software.
Detecting downtime for the machine is also not hard. Any botnet operator worthy of the name would understand the risk of running the slave pc flat out 24/7. Simply setting a low aggression with some kernels allows gaming without any noticeable impact yet when the PC is unused you get 95% of the hash rate you'd get if you had high aggression settings. Your talking 10000 but the biggest known botnet today is 4 million. Even it was only 25% utilization and they could get the GPUs working on only a fraction we're still talking massive processing power. Between these points, it quickly becomes clear that a Botnet consisting of 10,000 computers will not be nearly as effective as originally considered. Point A takes the 10,000 and makes them as powerful as about 500 high-end dual-GPU systems, Point B drops this number to around 200, and point C drops the utilization to around 50. Assuming 500 Mhash/s per system, that is a grand total of 25Ghash/s for the ABSOLUTE BEST and well run Botnet. In all likelihood for the average Botnet owner (a few hundred systems) it simply wouldn't be worth the time or effort.
Even if 100 'Absolute Best' Botnets came into existence (or a few less with more computers under their control), a change of 2500Ghash is only 20% of the existing network today. Sure, these Botnet owners would make a profit, but if they all joined the network today (and none of them were previously in the network) we'd only see difficulty increase by 15-20%. And its fairly safe to say that there are substantially less than 100 Botnets capable of running 10,000 computers with the absolute best software.
This delusion, however pervasive, should be outright ignored. Mining will continue being hosted primarily by the network of GPU owners for the foreseeable future, so stop creating panic and paranoia.
You can call it a delusion but you've made some very assertive calculations based on completely false assumptions. |
|
|
|
|
You mean that botnets might rent out their processing capacity? If so then I guess it's possible but it doesn't change the point, they will control large portions of the total mining pool at price point that makes it unprofitable for miners that have to pay their own energy costs.
|
|
|
|
I thinkyou mean cpus not gpus i highly doubt operators will spend over $800 or more for shared hashing just to make a couple of buck although pluasable.
No I mean GPUs. If you've can run arbitrary code on slave PC its pretty trivial to detect the presence of a suitable GPU and send it the appropriate code to run. Even to install any necessary drivers. Why would the botnet operator be spending money? |
|
|
|
|
1/ Why adjust difficulty so infrequently?
2/ Why diminishing rewards on such a staggered basis?
On point 1: The 2 week cycle exposes the network to a number of attacks. It's safety is based on the assumption that no one party could obtain near majority control easily but this is really not the case and won't be until BTC has grown an awful lot more. A simple attack vector is to throw masses of power in at the beginning of a block, greatly accelerating the rate of generation and the difficulty on the next block. As soon the difficulty adjustment happens withdraw all that processing power. Rate of coin generation drops dramatically transaction processing slows down, miners start dropping out, less coins come on the market so prices go up and said owner of mass processing power can trickle out his coins from the last block to keep prices steady, towards the end of the difficulty cycle they can come back in and take an even bigger slice or wait until the next cycle and clean up on the lowered difficulty. . Why not a shorter cycle? In theory enough power could put the network in a stagnant mode for a long time until the next difficulty change.
On point 2: There are a lot of unproven assumptions about the incentive of transaction fees as block rewards drops. No one really knows if they'll be enough to keep driving mining. Let's be clear, the system doesn't just need miners, it needs a LOT of miners to maintain it's integrity and prevent the kind of manipulation outlined in point 1. If you're going the change the reward why do it in such spaced out and dramatic fashion? Once every year or two a 50% cut. That's going to create shocks to the market every time it happens. Why not a more graduated approach? In fact why drop the reward at all?... Even if the goal is a deflationary currency (and the jury is still way off calling whether that's better than a non-inflationary or deflationary currency) a constant block reward still achieves that goal. Each block currently adds 50 BTC to the total money supply. Each 50BTC is a smaller proportion of the total money supply than the last one.
|
|
|
|
|
It's inevitable. The widely held assumption is that the mining rate will stabilize around about the point where profits = energy costs + a nominal amount for new hardware investment. But that assumes a level playing field. Botnet operators will eventually build functionality into their user agents to tap into GPU's if they're available, when they do they'll have the power of a botnet behind them without power costs. Botnets just became that much more profitable.
What are the implications of the block chain being under the effective control of botnet operators? Well at least we can be confident they're unlikely to work together, competition in the black markets is probably more fierce than in legal markets.
|
|
|
|
|
Exactly what tradehill needs to grab some market share from mtgox. No easy way to get money from mtgox to Australia. Expect to see a lot of trade from aussies champing at the bit.
|
|
|
|
|
I think I get your point... I understand the fact that time since last block has no bearing on likelihood of finding the next. At any given time there's a 50% chance that the next block will be found in the next 10 mins.
By the theory you put forward then it seems the advantage of pool hopping is proportional to the ratio of total pool hoppers vs single pool miners. i.e. if every miner mined each block from the pool with least shares the advantage would be cancelled out. So why is this 30% figure bandied around? Surely the advantage is highly variable?
|
|
|
|
|
Further to that, why don't pools simply pay out for shares earned during a winning block? I presume pool members see the round system as an advantage but surely the long term average is just the same as long as you don't happen to switch your miner off during the winning block.
|
|
|
|
|
I've read about all the payment methods and the apparent 30% gain that can be made by pool hopping between PPS pools but I just don't get it. Where does the advantage come from?
I presume a 'round' is the number of blocks between the pool's last winning block and next winning block. So for argument sake let's say we have 4 equal sized pools. Average round for each pool consists of 1000 shares and I'm a miner who can generate 10% of total shares per round if I stick with one pool for the whole round.
for an average round I generate 50 shares with pool 1 and 50 with pool 2. Pool1 wins so I get 50/1000 * 50 = 2.5btc, same for pool2
If I stick with Pool1 I get 5 btc but expect to win block only half as often.
For a large number number of 1000 round shares I expect to win on average 1/2 with each pool, say 100 rounds
50 * 2.5btc = 125btc
50 * 2.5btc = 125btc
total = 250btc
For a short round say 600 shares I generate 50 shares with pool1 and 10 with pool2
If pool 1 wins I get 50/600 * 50 = 4.16btc
If pool 2 wins I get 10/600 * 50 = 0.83btc
For a large number number of 600 round shares I expect to win on average 1/2 with each pool, say 100 rounds
50 * 4.16btc = 208btc
50 * 0.83btc = 41.5btc
total = ~250btc
For a long round say 2000 shares I generate 50 shares with pool1, 50 shares with pool2, another 50 shares with pool1, another 50 shares with pool2
If pool 1 wins I get 100/2000 * 50 = 2.5btc
If pool 2 wins I get 100/2000 * 50 = 2.5btc
For a large number number of 600 round shares I expect to win on average 1/2 with each pool, say 100 rounds
50 * 2.5btc = 125btc
50 * 2.5btc = 125btc
total = 250btc
What am I missing?
|
|
|
|
|
People please stop replying to this thread. Can't you see it's just spam, I doubt he's even being hacked. Look at the thread title. First half is a sensational claim all in capital letters, the second half is basically an advertisement.
Ask yourself if you owned an allegedly successful site that was being hacked right this moment, would you try to lock down the server or would you make long posts about how good your forum is?
|
|
|
|
Where are all these small posters coming from?
 You sir are a tool. It just gets better and better, where's the popcorn. |
|
|
|
|
whether it's BTC/USD or BTC/BTC2 what your proposing is still pegging one currency to another. That means neither currency is free float to it's real value. BTC is value is always going to be deflated due to diminishing supply and unless the population starts to decline that will always be the case. If you peg them via a feedback loop between BTC2 supply and BTC value you will always have the two floating a nearly fixed ratio to each other. End result, even it there's a compelling reason to abandon one currency entirely for another it won't happen. That is why I proposed a solution where the supply of BTC2 is part of a feedback loop related to it's demand. The feedback loop is closed, the currency is free to float relative to it's utility value (the rate of circulation) and not relative to any other currencies that have artificial external influences.
The most important impact of a decentralised currency is a juxatposition with fiat currencies to highlight their inadequacies the the ways they are used as political tools by a small minority.
|
|
|
|
I will be honest, I didn't understand half the stuff you said. Most of it was irrelevant, but you had a good way of putting your points out.
Vegetta do you self a favour and read every word she's written until you DO understand. Read it a thousand times if necessary, it's some of the best advice you're ever gonna get and she's giving it you free despite the torrent of abuse you're throwing at her... Maybe she likes it, who knows. I'm a professional web dev and I've lost count of the number of times I've been approached by someone with a great idea that's going to be the next facebook and as long I can work for free I can have a little cut. I would do it if she asked me, I don't give my respect to whores easily but she earned it in one post and built on it in every one that followed. You on the other hand have shown yourself to be petulant with an out of control ego. If you want to succeed don't take all advice as criticism and when it is criticism listen to it instead of getting defensive. There's something to be learned even from the most unjustified of criticism. |
|
|
|
|
I take you point, lack of volatility is desirable, but what you were talking about is pegging which a very different think to stability. The rate MUST be able to move free relative to fiats or will certainly fail. You simply can't have a deflationary currency pegged to an inflationary one sooner or later there will mass rush to one or the other until the spread grows too wise, the suckers run out and a whole lot of people are left holding the ball.
The kind of stability you are talking comes from one thing and one thing alone, liquidity. It takes a hell of a lot to move the forex market. It took one small sale of a few million USD worth to crash mtgox. If the market was more liquid that sale would have been absorbed and we'd have seen barely a blip on the chart.
|
|
|
|
|
excuse me continuing to talk to myself...
Just notices that my bitcoind client is returning 1379192.28822808 from getdifficulty so it was decoded properly.
Odd though that blockexplorer is returning a different difficulty?
|
|
|
|
this is very odd... Sent my whole balance of 0.03 btc less 0.0005 transaction fee to 1HrFjc5Mpz5agn8dk6LDF98V8sxDrWvUqY. Status: 419 confirmations, broadcast through 7 nodes
Date: 23/06/2011 17:07
To: 1HrFjc5Mpz5agn8dk6LDF98V8sxDrWvUqY
Debit: -0.0295
Transaction fee: -0.0005
Net amount: -0.03 7 hours later I get 0.0295 BTC returned? |
|
|
|
ok so I've just learned about compact form vs long form... and I seem to be decoding difficulty close but not precise: L.println("************************************************************************");
L.println("offset: " + i);
L.println(block.toString());
String diff = block.getDifficultyTargetAsInteger().toString(16);
long highestDifficult = 0x1d00ffff;
BigDecimal highestDifficulty = new BigDecimal(Utils.decodeCompactBits(highestDifficult));
diff = StringUtils.leftPad(diff, 64, '0');
L.println("max diff: " + StringUtils.leftPad(Utils.decodeCompactBits(highestDifficult).toString(16), 64, '0'));
L.println("hex diff: " + diff);
BigDecimal ratio = highestDifficulty.divide(new BigDecimal(block.getDifficultyTargetAsInteger()), 7, RoundingMode.FLOOR);
L.println("ratio: " + ratio.toPlainString());
L.println("************************************************************************");
gives me: ************************************************************************
offset: 0
v1 block:
previous block: 00000000000003fc392bab7a327a019fce4b48c98d5bc4b0d8d20f6e21e4ce1f
merkle root: 2891334d6466ea274ac50cdb2af50afc889d236689cfe6ace9682b752900985a
time: [1308977962] Sat Jun 25 14:59:22 EST 2011
difficulty target (nBits): 437004818
nonce: 0
max diff: 00000000ffff0000000000000000000000000000000000000000000000000000
hex diff: 0000000000000c2a120000000000000000000000000000000000000000000000
ratio: 1379192.2882280
************************************************************************
which is pretty damn close to blockexplorer: 1379223.4296725 It seems odd that difference is very close to 32 (31.1414). Perhaps I've mashed a bit somewhere. |
|
|
|
got it... had to brute force it with ever permutation I could think of but finally got an almost result: public static void checkByteSwapped(String data) {
byte[] bytes = Hex.decode(data);
byte[] rev = new byte[bytes.length];
for (int i = 0; i < bytes.length; i += 4) {
byte[] chunk = Arrays.copyOfRange(bytes, i , i + 4);
chunk = Utils.reverseBytes(chunk);
System.arraycopy(chunk, 0, rev, i , 4);
}
checkBytes(rev);
}
produces: offset: 0
v1 block:
previous block: 00000000000008ee4076724291e1656d84ac61d98bf89dd3656680782aad1a4a
merkle root: 8de49d9cc1dce6cf0a89b95cd5d683eb787e3f6a02072acf69ddab88b8ae01ff
time: [1308974260] Sat Jun 25 13:57:40 EST 2011
difficulty target (nBits): 437004818
nonce: 0
which matches the last block from blockexplorer. The only part that doesn't match up is the difficulty target. Block explorer says: 1379223.4296725 but at least it's progress... |
|
|
|
|
Stable exchange rate is definitely not desirable. Stable purchasing power of a bitcoin is though, i.e. no excessive infaltion or deflation... Made the following post elsewhere but it got buried, it's appropriate to this discussion so will repost:
----------------------------------------------------
The hard limit on supply of bitcoins is the biggest problem IMHO. The deflationary spiral threat is well documented so I won't repeat it except to point out that it gives bitcoin far more characteristics of an asset rather than a currency and provides a disincentive for circulation.
Monetary policy should be internally regulated and dynamic. I'd propose something along the lines of a feedback loop where the rate of coin generation is proportional to the incentive to hoard coins. Thus if you have excessive deflation more coins are produced, if you have inflation less coins are produced. The hard limit would disappear and the real world value of the coins stays relatively stable. The difficulty is that you can't tie it to any externality like exchange rates because then you need gateways to those externalities which creates points of potential manipulation.
My first thought was to tie it to the inverse of the rate of circulation which is easy for any node to calculate. The more people are hoarding, the more new currency is added to the market thus devaluing the hoarded currency or at least finding an equilibrium and removing the hoarding incentive. But that would need to balanced with a disincentive to spam transactions or the rate of circulation could be manipulated (and probably choke the network if the effort was big enough). My next thought is to tie it to the number of unique coins that have been transacted in the block (or the average of the last n blocks) compared to the total generated. Each coin can only be counted once no mater how many times it is transacted thus preventing spamming with circular transactions to manipulate the rate. Very large holders could still have an effect by ensuring their coins were moved at least once every block so perhaps it could actually be a one way test:
if circulation > threshold --> create normal number of new bitcoins
if circulation < threshold --> create normal number of new bitcoins + (threshold - circulation) * factor
Obviously not a fully fleshed out idea but hopefully greater minds can add to it...
-----------------------------------
|
|
|
|
|
Show Posts
