Competing with myself in mining doesn't make any sense. You aren't "competing with yourself." Difficulty is programed to adjust periodically to a target of 6 blocks per hour. Mining slower to only get 6 blocks per hour will prevent a difficulty change, but won't change how often you get a block vs mining faster once difficulty is done adjusting. If you want difficulty to stay low, you could CPU mine (although not with cgminer). If you need more than 6 blocks per hour, maybe modifying the code for your testchain would make more sense. If you want to use less power, then it probably makes sense to "detune" your video card. In that case, I would recommend starting with the tuning suggestions in the readme and trying to use logic to get the results you want (IE, underclock the video card). Well, underclocking the video card is a quite involved process, especially on a laptop. It seems like the AMD drivers keep the set of clock settings per power state of the OS. So when underclocked while plugged in the machine upclocks when unplugged and put on the battery power. And vice versa: when underclocked on the battery it upclocks when plugged in. The goal is to be able to mine at least one blockchain without triggering the increase of the difficulty and without raising the temperatures of the CPU & GPU to trigger the internal fan of the laptop. With the fan working I could mine at least three competing branches of the blockchain without raising the difficulty; all on the low-end laptop. This is really helpful for the reorganization testing, but not really required for the usual tests. I absolutely want to mine against the official binaries without changing anything or even a recompilation. This is an explicit goal of the test process: to successfully interface with the official Satoshi clients. Mining on the CPU even with a single core always results in the fans spinning and produces blocks at the annoyingly slow rate that would needlessly prolong the test runs. Yes, I fully understand that cgminer is 99.99% designed for the production mining and not for the development mining. I have to rethink how to cover the remaining 0.01% use case: R&D on the testnet. I'll maybe need to think about a creative use of cgminer API to slow it down or maybe come up with a simple slow-it-down mining proxy server. |
|
|
|
|
For speed: either none or negative
The hUMA targets the common bottleneck of copying buffers from the CPU memory to the GPU memory. When mining scrypt() (or anything else) GPU first writes to the buffer then reads from it, there is no bulk copying.
Most likely use will be the cost and power savings for the low-end systems. So the positive thing will be that the whole system will not need to have dedicated VRAM chips near the GPU and therefore it may be cheaper. Those cost saving will be offset by the increased contention for DRAM, therefore the mining systems will have to be throughly purged from any stray tasks that use the CPU.
By the way: SGI used UMA with their low-end MIPS systems (O2) about a decade ago. AMD seems to learned the lesson and from the start intends to provide better UMA software support for the regular graphics programming than SGI did with OpenGL.
|
|
|
|
I'm just quoting this for posterity. The kookiness of proposing a deterministic test for the presence of random numbers is very high. Not as kooky as BenRayfield, but getting there. Haven't read the document, but this could probably work. If you can seed the random number generator, you can use the data that is now being hashed (Block Header + Previous Block Hash + Nonce + extra's) to seed the generator and create a random number, and compare this with a target (difficulty). The problem with this design, is that anyone that wants to verify the block _needs_ the exact same implementation as well. So not that many people will be able to run full nodes. Again, this assumes you can seed this generator and that after seeding the generator will produce the same numbers. Haven't actually looked at how this RNG works. Sounds promising! Come on programmers, we could create an ASIC and GPU resistant coin - a key differentiator from other coins. This could be what LTC was intended to be. Scrypt + DRNG. All 3rd generation Intel core CPUs support this feature and ship in most new PCs. We can create a little exclusivity for miners too  |
|
|
|
The thing that cripples GPUs is the lack of significant memory per thread on the video card.
Have a scheme that uses scrypt and requires 2GB per thread (or even as little as 256MB per thread perhaps) and your quad-core CPU with 8 GB of RAM will beat any video card. The GPU can do many threads, but they aren't very fast. Attach large memory requirements to each thread and the GPU (as well as FPGA and even ASIC) is dead in the water.
This is only GPU-defeating. FPGAs will trivially beat that, not to mention an ASIC with eDRAM instead of DRAM. Or there already may be an existing SoC-s with ARM CPU attached to sufficient eDRAM, but almost all of them are under NDA. All of those will massively beat Intel/AMD on power efficiency and easily compete on speed. |
|
|
|
|
Dear ckolivas & kano!
I have an unusual request: I use cgminer to mine testcoins. The problem I'm having is that your software is too good and too fast even on a low-end laptop and causes an increase of difficulty. Competing with myself in mining doesn't make any sense.
Thus far I've used "--shares" switch to periodically mine a handfull of blocks, but the problem with this solution is that it causes thermal cycling and cycling of the fans on and off.
I was wondering if you could suggest a way to quickly detune the CGminer to a slower speed: I know how many miners I run and I culd just make sure that they in total don't go above 7Mhash/s (or the equivalent for scrypt).
If this is currently impossible to do, please let me know where to inserts the appropriate waits/sleeps in your code. I could then rebuild my own version.
Thank you for any suggestions you may have.
|
|
|
|
Would it be possible to make a coin that could only be mined if you had SSE instruction set 1,2,3, etc? As far as I know no GPU would be able to decode something that required one of those instruction sets.
This doesn't make sense: the code has to be open source and therefore any competent programmer could rewrite it from SSE/AVX/etc. to the vector instructions of the GPUs. And the GPUs are much faster at single- and double-precision floating point (32-bit and 64-bit). The thing that handicaps GPU is the extended-precision (80-bit) floating point. It isn't impossible to emulate it on the GPU, its just that the results will be significantly slower and will require significant development effort that will be of little use anywhere else. There are various quad-float (128-bit) libraries is where the multiple-precision floating point development work is geared. |
|
|
|
Here's the useful idea for an effectively CPU-only coin: use 80-bit extended floating point arithmetic to compute several iterations of a chaotic system, e.g. http://en.wikipedia.org/wiki/Chua's_circuit or http://en.wikipedia.org/wiki/Lorenz_system . Sandwitch those between the first and the second SHA-2 computations. Implementing a full 80-bit FPU is quite complex and resource intensive. Moreover, the implementation is unlikely to get faster than a dedicated hardware implementation inside Intel or AMD CPUs. No existing GPU has 80-bit floating-point arithmetic implemented. And future GPU-style computational accelerators most likely implement 128-bit extended precision, not the 80-bit version hailing from the historical 8087 coprocessor. Quite obviously it is impossible to completely prevent FPU or ASIC implementation, but the money and time required to implement a copy of 80-bit FPU conformant to IEEE-754 is several orders of magnitude higher than re-implementing e.g. scrypt() or anything else discussed by the cryptographic community. In particular there are no pre-existing complete implementations that are open source or free from licensing encumbrances. The main obstracle is that unfortunately you'll have to spend some time to make sure that you aren't implementing a coin that forks into an AMD-coin and an Intel-coin. There are known differences in the implementations of transcendental functions between those two vendors. You'll probably will have to limit yourself to using the +,-,*,/ operators and square-root,reminder and the two BCD conversion operations. This problem already has significant research available, but not in the context of a Bitcoin variant but in a context of verifying the results of numerical computations. http://stackoverflow.com/questions/13102167/do-fp-operations-give-exactly-the-same-result-on-various-x86-cpus/13102431http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdfAlthough this will not yield truely CPU-only coin, the coin will be CPU-only for several years, probably about 3 or 4. On the other hand implementing the numerical http://en.wikipedia.org/wiki/Chaotic_map in an x87 assembly language will take at most couple of weeks. |
|
|
|
This algorithm uses a type of finite impulse response filter
(exponential moving average or EMA), to smooth out short-term
fluctuations in delay between blocks.
You guys need to send your programmer(s) back to school to take a basic control theory course. Expotential moving average is a kind of infinite impulse response filter (IIR), not a FIR. Neither of those are really applicable to regulating the coins based on the Bitcoin architecture: IIR & FIR theory is valid on the assumption of causality. Bitcoin block timestamps are acausal, in other words the time in the blockchain can flow backward (with certain limit, 2hrs in the original Bitcoin), which completely breaks the underlying theory of discrete-time fixed sample rate filters like the common FIR and IIR designs. ArtForz in the past used his knowledge of this to exploit the original Solidcoin chain, and maybe others. http://en.wikipedia.org/wiki/Lyapunov_stability |
|
|
|
|
If there are two competing blocks with two different timestamps at the end of the retarget period you end up with two sub-chains, each with different difficulty. They have to converge globally to the one longest chain.
This convergence is slower than the normal "orphan block/branch/sub-chain" convergence in the middle of the retarget period.
gmaxwell wrote several detailed posts about the issue, search his past posts for the word "convergence" and its variants.
|
|
|
|
|
This look like a satellite recever board: the gold-plated connector on the bottom right looks like a high-frequency coaxial antenna connector.
If somebody is near a place that regularly deals with Sat-TV boxes they could probably recognize the board on sight and maybe let you make a comparison photo without the 10 CedarTec black squares.
|
|
|
|
Do you have any further ideas.
At this moment all I can say is "works for me". I put some more comments into my previous post above, to clarify the usage and describe the common pitfalls. I tested on my Windows 7 US English version both for command-line and graphical-user-interface passphrases. The program was used essentially unchanged to help an user who had to restore German Windows Vista backup into a replacement machine made for the US market (or an opposite, don't recall the details.) Test it character by character, umlaut by umlaut, both command line and GUI, until you find what's wrong. Or just hire somebody to do that for you. |
|
|
|
Did someone said that?
Cold wallet:
Your bitcoins are stored in cold wallet only, and the servers only use watch-only wallet, powered by Armory, to monitor deposit and balances.
There is 676 bitcoins AND 500k USD borrowed. The two are unrelated.
Seriously, you have a question, just ask, I think we are pretty transparent and never hide any facts.
Likewise, I'm not interested in doing free financial auditing over the web forum. As just a numbered account on a web forum I have absolutely no credibility. On the other hand financial auditing is performed by independent professionals that are getting paid for that service by the very subjects of their audit. I'm looking forward to the discussion after the current class of Bitfinex.com students graduates. The class of MyBitcoin.com and the class of Bitcoinica.com have already graduated from their schools and a way more interesting interlocutors. |
|
|
|
I hope to have cleared all of your doubts.
In case I didn't, I believe using a piece of paper and a pen will greatly help your understanding.
Please let me know if you need further help.
Thanks, I don't have any doubts. In fact I think you are doing a great job of educating young people. It is kind-of boring and fruitless to harrangue the youth to learn about bucket shops, capital at risk, financial audit and other such obscure stuff. While participating in Bitfinex they can learn with their own lunch money about the basics of finance, e.g. capital cannot be simultaneously safely stored in a cold wallet and profitably invested in an exchange trading. Bitfinex will also teach people how to be their own bank and their own accountant, e.g. how to reconcile the statements like "676.52 bitcoin borrowed" and "500k active loans". Yeah, nearly 100 years of various consumer protection laws contributed to the creation of generations of irresponsible people. Let them learn how to have a cake and eat it too. |
|
|
|
Maybe this will help someone with mistyped password on Windows. This is a short Powershell script that tries the passwords read from standard input as rapidly as the particular cryptocoin client will allow. #
# Please put the correct RPC username/password below
#
$h = new-object Net.WebClient
$h.Credentials = new-object Net.NetworkCredential("user","pass")
$h.Encoding = [Text.Encoding]::Default
# Above "Default" works for original encryption from the command line
# Change to "UTF8" when the GUI was used to encrypt
#
# read the password guesses from standard input
#
# Change "$Input" to a known good password in single quotes
# to test the program, e.g. 'Kongreßstraße'.
$Input | foreach {
try {
$p = $_
Write-Output "Trying '$p'"
$r = $h.UploadString('http://localhost:8332/','{"method":"walletpassphrase","params":["'+$p+'",1]}')
# Write-Output $r
Write-Output "Correct password found!"
break
}
catch [Net.WebException] {
$e = $_
switch -wildcard ($e.Exception.Message) {
"*(401) Unauthorized*" {
Write-Output "Fix the user/pass!"
Exit-PSSession
}
"*(500) Internal Server Error*" {
continue
}
default {
$e | Format-List -Force
Exit-PSSession
}
}
}
}
#
# Exiting without success!
#
Write-Output "Exiting!"
# Note about saving the text of this script: Please view it with an hex editor,
# and look for the character representing the German "sharp s".
# If it is __ , then the file was saved as ____ .
# DF - Windows-1252 or ISO-8859-1
# E1 - Code Page 850 or 437
# 41 4E 38 2D - UTF-7
# C3 9F - UTF-8
# 00 DF - UTF-16 Big Endian
# DF 00 - UTF-16 Little Endian
# Make sure that the powershell.exe, cmd.exe and any other programs
# you used are appropriately configured. In particular your Command
# Prompt window may need the fonts changed (from Raster to TrueType)
# and you may need to run CHCP. There are too many combinations
# to enumerate them here.
You can either feed it a file/dictionary of possible passwords: powershell -executionpolicy bypass -file bitcrack.ps1 < dictionary.txt or a pipe in the one-per-line output from the password generator: generator.exe | powershell -executionpolicy bypass -file bitcrack.ps1 . For someone who already has the Ruby installed on their Windows machine you can take those programs and delete the system() call and the case/end statement below it. Also change 'print phrase, "\t"' to 'puts phrase'. They should speed up the checks to the maximum achievable without hacking the wallet-handling code in the Satoshi client. Edit: I put some more clarifying comments into the source code. |
|
|
|
But in this case the problem will be much bigger than the loss occurred on the lending side.
In this case it will be the end of our dream.
More people working at Bitfinex but still the same fundamental problem: 1) when going long on Bitcoin the maximum possible loss is 100% but the maximum possible gain is infinite 2) when going short on Bitcoin the maximum possible gain is 100% but the maximum possible loss is infinite Bitfinex has no way of assigning this infinite loss to the trading entities that incurred them. Therefore the excess shorting losses will have to be spread over the Bitfinex's own capital (next to none) and the Bitcoin capital of those who lend it to Bitfinex in exchange for interest. Long & convoluted essays will not change the above short & simple explanation. |
|
|
|
It is a very unlikely scenario.
Bitcoin was optimized to be decentralized so I don't see any reason why should anybody use a bitcoin like system for a centralized currency.
For a centralized and more traceable currency already exists better concepts and they are in use.
If you think of cryptocurrencies as a spectrum of M-of-N possibilities the limits are: 1) M=1 N=1 cryptocurrency where cryptography is just a form of error detection, but it otherwise has properties of the traditional database/ledger currency 2) M=1 N=infinity describes the exact Bitcoin design: any one miner (M=1) out of unlimited set of miners (N=inf) is all thats required to confirm the transaction But in general many more combinations are possible. For example with M=N/2+1 we have a traditional majority consensus organization. It is also possible to make N variable, require M=N for unanimous consensus to increase N by 1 and M=N-1 to decrease N by 1. I would agree that the organization as big as IMF doesn't really need or have a motivation to switch to cryptocurrency model. I think that the opposite side of the size spectrum is where the M-of-N model becomes useful: small trans-national and trans-jurisdictional partnerships that utilize the cryptocurrency as a means of shareholding transfers and voting. The crypto aspect gives such an organization some degree of invulnerability to a legal expropriation of one of the partners in one of the jurisdictions. |
|
|
|
Could you please speculate wildly on why the idle power usage is so high? Originally advertised values for a Single SC: 40 Watt while hashing (at 40GHash/s). Actual values for this little prototype board (with unknown hashrate): 42 Watt idle (!!), 160 Watt when hashing.
The ratio of loaded/idle is unlike anything CMOS that I have ever seen. It reminds me of ECL or linear analog designs. How can one get to such predicament? I've heard of latchup in CMOS circuits, but it becomes a short circuit and therefore completely prevents the normal operation until powered down. |
|
|
|
If reliability is main concern, you can use RAID1 (preferably staggered in such a way that two disk in each array have different wear level). Also, larger disks will last longer before wearing.
I wish the life would be so simple. The flash storage sector is so full of cheats and fly-by-nights, that the total cost of building a reliable and long lasting Unix server simply approaches or exceeds the cost of an equivalent mainframe solution. C.f. the recent trend of using supercapacitors to power hidden write-back caches. Combined with the various wear-leveling cheats it produces failures that are extremely hard to locate. Consider this trivialized example of a circular on-disk-buffer of 3 blocks: 1 2 3 4 5 6 7 8 9 If you read it after simple reboot you'll get "7 8 9". If you read it after proper power down with super-cap discharge, you'll get "7 5 9" or "7 2 9" or various other combinations. The culprit really isn't flash technology, it is nearly always firmware problem due to its extreme complexity and trivialized testing. There are various options available on the market, but they aren't openly advertised because they tend to use some technologies that IBM has either patented or keeps a tight contractual grip on the channel partners. e.g. SCSI disk drives with AS/400-like formatting with 520 bytes per block for 512 bytes of user data per block. On the other hand we've never suffered a bug in a true RAM drive, possibly because of the extreme simplicity of the required firmware. I apologise for contributing to a derailment of this thread. |
|
|
|
Thank you very much. Those are primarily aimed at the "IOPS desperation" market niche. We aren't there yet. I would call our niche "rapid reboot & real reliability" for write-ahead-logging internal drive. The flash EEPROM storage is so full of misinformation about reliability that its is nearly impossible to make sensible product choices. |
|
|
|
Dude i'm really having trouble understanding what in tar-nation you mean by this. Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them? Solidifying Gavin & co's benevolent dictatorship?
Try to forget for a moment everything that you know about software engineering and think about yourself as a brand manager of a consumer product. From now on the discussion isn't going to be about technical facts, it is going to be about the perception of facts amongs the non-technical people. Do you think it possible to reverse engineer the recipe to the Kentucky Fried Chicken to such an accuracy that nobody will be able to distinguish it in a blind tasting? I think yes, but people will insist on sighted tasting and will claim that they are capable of distinguishing the true KFC from your Clone Fried Chicken. If you don't like popular American consumer products then how about French wines? Why for example Veuve Clicquot is considered more valuable than many other "Appellation d'Origine Contrôlée, Méthode Champenoise" beverages? How did they achieved that value and how they maintained it? Do you think that it is impossible to produce a Californian sparkling wine that 99.9% drinkers will not be able to distinguish in a blind tasting from the original? I think that this will be relatively easy, but the clone wine will have much lower market price because everyone buys wine while looking at the labels, not by the taste. For a non-engineer it is very easy to distinguish between say Bitcoin and Litecoin. For now everyone knows that the first Appelation d'Satoshi Controlee and the second is sovetskoye shampanskoye. What if the market gets flooded with Bitcoin clones, e.g. Bitcoin over port 8888 (marketed to Chinese, with some Confucius' proverb in its block 0), etc. And every one of those clones will be able to show that they are produced exactly according to the original Satoshi method. Or they will be able to easily show how they improved the original recipe. Bitcoin currently has a lot of very valuable brand equity, simply because it was first in its niche. The situation may however easily change once experienced brand managers decide to enter this niche with their clone products. Currently all the clones are marketed in a completely amateurish way. Or even much worse than amateurish, like the self-destructive marketing of SolidCoin. |
|
|
|
|
Show Posts
