|
Interesting, mystery miner is a single entity/machine. Probably a commercial or academic cluster or supercomputer then. Wonder what incentivises them to be on/off the bitcoin network? (Besides having spare cycles).
Could be electricity cost, when bitcoin gets economic they crank it up. Certainly puts some punch behind the security of the network having something like that lurking out there ... how many more mystery miners might potentially come out of the woodwork when the price is right?
|
|
|
|
Of course, I will have to stop this thing when I use the computer for graphically intensive purposes  When I started mining, I had the same plan. What happened is that it made me stop doing graphically intensive stuff  I have another machine in the basement which blew it's power supply. I can put a "spare" overclocked 460GTX card in it. I just might make that a project as well This mining this is rather addictive You got it. But there are worse things you could be doing than saving the world from the perils of centralised fiat currencies controlled by meglamaniacal banksters. |
|
|
|
|
It needn't be any extra mining but just a lucky streak by the mining network that jacks up calculated hash rates over an extended period.
Deepbit.net had an epic day on April 13, solving ~80% more blocks than it normally does ... so for that day the pool's has rate power comes out higher. Similar episodes are likely to occur for the whole network.
|
|
|
|
what if there was some kind of some proof-of-work required by the sending client? It would not need to be large but enough of a drag to discourage large numbers of sends from a node with an intent on attacking the network.
There already is, to some extent, as the signing and hashing process involved in sending a transaction does put some weight on the sending cpu. More would be a burden for collective wallet systems like mybitcoin. So increasing the difficulty of this signing process is a possible solution to discouraging bogus transaction prevention. Collective wallet systems shouldn't really be a consideration in this though since they are secondary user in the sense they are centralising pools of users, so they should be prepared to do the same amount of work as the equivalent number of distributed nodes. User pays. |
|
|
|
Why would 'most users' move to client mode only (like BitCoinJ)?
Most users are on PC sized devices at present I'd guess.
Because the initial block chain download/indexing process takes ages. People don't want to wait 30 minutes+ to get started with BitCoin. That's a serious brake on adoption. I'm not saying everyone should switch to a different implementation (no such implementation exists anyway). But rather that finishing one off is the solution to these 'spam' issues, as then the block size limit could be lifted significantly without hurting initial setup time so much people stop entering the community. Oh ok. But lifting the block size limit to accommodate bogus transactions seems wrong, although it may have merits for other reasons ... what if there was some kind of some proof-of-work required by the sending client? It would not need to be large but enough of a drag to discourage large numbers of sends from a node with an intent on attacking the network. If the miners are expected to pick up the work and not get paid maybe a commitment from the clients that transactions are valid, in the way of some proof-of-work, from them is needed? Kind of like a proof-of-work handshake to the veracity of the send transaction. If it would make the network more robust also having the clients do some more work there are none actively mining anymore (are there?) so all that CPU power can add up to a lot if they do a little bit each time they send. As a bonus maybe the client work could be put towards anonymising the send in some way, coin selection?, blind-sign?, dunno still thinking about it, but some clients definitely already have an incentive to do this anyway. |
|
|
|
Today that means finishing off the client mode work in the main client, or, having most users move to an alternative implementation that is client mode only (like BitCoinJ). It'd be better to do the first one but nobody seems to be working on it right now. Why would 'most users' move to client mode only (like BitCoinJ)? Most users are on PC sized devices at present I'd guess. |
|
|
|
I removed one of my video cards for a bit and noticed the poclbm was not using 100% of a cpu core any more. The second I added back in my 2nd card cpu usage jumped up to 1 full core pure instance of poclbm. Apparently the high gpu usage is tied to dual card setups.
Although, the problem is not seen on Windows XP. I have a miner running XP, that has dual 5870s, and poclbm doesn't eat cpu there. It may only be a Windows 7 issue.
Maybe this can help track it down.
On Linux Ubuntu 10.10, I think it maybe a bit more complicated than this ... I've noticed that when you run a graphical tool to monitor CPU/Mem usage (whilst miners are running) then the CPU usage skyrockets. If you use the command line tool $top the CPU usage stays low around 3-5%, and it is mostly on Xorg that is using the CPU. In fact, I think if you run any process that has graphics GUI or other then Xorg goes nuts, it must be competing with poclbm for the GPU, even when you give it a -f 30 .... A slightly related anomaly I noticed one time, after loggin in on boot-up I set all miners off and they were getting ~2MHash more than they normally do for about 10-15 seconds, but then something happened and they dropped back to normal speeds ... so i suspect Xorg hadn't woke up and stuck its nose in yet ... so to test the theory i rebooted and ran fgl_glxgears immediately on logging in. Similar behaviour, for 10-15 seconds I was getting 3000+ fps and then it stopped and throttled back to < 1000 fps ... so something (Xorg most likely) is definitely jumping in and throttling poclbm and fglrx from running at optimum ... unfortunately it also eats CPU as it does it. Managing GPGPU processing with Xorg is a kludgy idea, can't believe this is the best AMD can come up with. |
|
|
|
So why would someone send transaction spam? What do they get out of it?
Miners have an economic incentive to accelerate the implementation of fees ... not saying that anyone is doing that just that it is a possibility ... either way it is a mild form of attack, like an annoying rash you might get from a lap dance ... |
|
|
|
Too late. They are racked and mining. Sorry  I will have more time for optimizing the power consumption when/if I get a next batch of cards. guys, how do I go about reducing the mem clock using ubuntu? As I understand it one could use afterburner under windows but I am not too sure about ubuntu. Doesn't help on linux, apparently, althought yet to test this myself ... you might find some useful tips here. http://bitcointalk.org/index.php?topic=4806.0I think you might have your hands full just getting the 6990 up and running on ubuntu with full driver/OpenCL support etc ... |
|
|
|
|
As you well note, that kind of volume would be a noticeable portion of total BTC float.
By default this makes you a market-maker to some degree.
My advice, hire someone or come in behind an established player and become a market-maker and BTC exchange. That's where you can make the gains in the next phase and you will get your 200K BTC and more, back in spades imvho. E.g. buy Mt. Gox.
|
|
|
|
What about an infinitesimal, but non-zero transaction fee on all transactions?
Is anyone but the spammers going to notice that they just got 0.00000001 clipped off their transaction?
The problem with that idea is if the transaction fee is that low spammers won't notice it either. They can just invest 0.01 BTC and send millions of "non-free" transactions. Yep, good point. It's a thorny one alright .... the problem there is the relative size of the fee to the size of the transacted amount, but if you have a fixed 'tiny' but non-zero percentage fee then anything that is prohibitive to spammers will also be noticed by legitimate users. E.g: a 0.001% fee (BTC 0.01 on a BTC 100) would still get spammer a large number of transactions and any higher it'll get noticed I guess ... |
|
|
|
|
What about an infinitesimal, but non-zero transaction fee on all transactions?
Is anyone but the spammers going to notice that they just got 0.00000001 clipped off their transaction?
At some point free transactions are unsustainable because they do not reflect the true cost to the miners for maintaining network integrity. Workaround code to defend an ideal will get kludgy after a point.
|
|
|
|
|
Here's a thought.
Basically a lot of new bitcoiners are using the faucet to just 'see that it works' incoming to their account ... they put in a request for coins and out some pops in their local account. I don't think they really care too much that they just got ahead by BTC 0.05.
So in that vein, could we not set something up so that they can then immediately, and easily, just send some BTC back to the faucet (probably those same BTC 0.05 that they just got, so that they can 'see that it works' going the other way, i.e., outgoing from their account?
And then have some kind of confirmation at bitcoin faucet site for them that it was their BTC that just went through back the other way?
It would be closer to a net zero sum game for bitcoin faucet.
|
|
|
|
I saw connectivity problems with some of the users, looks like peering failure. Trying to find cause of this.
And i ordered a new server in Europe to use as backup (automatic failover) for this kind of situations, will be available in a couple of days.
Good stuff ... so out of interest, the new European server will not be co-located with the main server which is where ? |
|
|
|
|
DeepBit is DOWN
... get it sorted.
... and UP
... and DOWN
... and UP
this is getting old, was it planned or is it some kind of outage?
|
|
|
|
|
Well done genjix ... fear not, enough will "get it".
Corollary: some big tests to the architecture will not be far behind.
Remarkable is i have found it obvious the difference in reactions when explaining bitcoin to various people ... the people who get it (5-10%), must be those who recognise the totalitarian nature of our current electronic fund transfer system, you can see their face brighten, eyes light up and the grey cells start humming.
|
|
|
|
|
We need to tabulate the data contained in the previous 9 pages of this thread to speed up trust checking somehow.
A simple table with the user and number (or list of counter-parties) with thumbs-up (down) next to them.
|
|
|
|
Idea #3: What if our company could provide a "forex" marketplace for BTC/USD? This has certainly been done already (MtGox, etc.), however it seems there is still a lot of barrier to entry for many participants. How might a big player help? Would it hinder bitcoin's progress in any way?
Idea #4: Does bitcoin need a market maker in its exchange markets? Market makers usually help narrow the spread between the "bid price" and "ask price" by taking some of the risk in moments when there are no natural market participants (e.g. if you want to sell, but at this moment no one is willing to buy, you either have to lower your price to gain attention, or wait a while for more buyers to show up). My sense is that bitcoin is too young to need a market maker, and perhaps does not yet have enough volume to make the role worthwhile. What are your thoughts?
Bitcoin could do with as many exchanges and market makers as are willing to have a go ... ... especially a market maker that could have multiple exchanges in diverse locations dealing in separate currencies. Consider the utility and desirability of a single trusted exchange entity whereby a local cash or electronic bank transfer (EFT), in say Germany, France, Switzerland or U.K. can be made to acquire Bitcoins and then using an agent of the same trusted exchange partner located in another country say USA, Canada, Hong Kong or Australia can be used for a Bitcoin to cash or for local EFT. |
|
|
|
|
Got a guy with 12+ years SAP Financial thinking about how Bitcoin could fit into SAP .... is there a good open source SAP clone out there?
|
|
|
|
|
Show Posts
