Regulatory friction is mostly smaller outside the US. And probably the demand for more/improved financial services is probably larger outside the US. That's why I believe emerging markets are among the best opportunities to get BTC started on a larger scale. It might come to developed economies through the backdoor.
The push for smaller markets is basically a search for a cannon fodder that is willing to use a software that is non-compliant with any sort of accounting software guidelines, be it GAAP, IFRS or whoever else's. "bitcoind" is well-nigh impossible to integrate with any existing transactional finance package that is using 3-phase commit protocol or any other customary reliability and accountability protocols. My current best guess is that the adoption of Bitcoin will somewhat parallel the (non-)adoption of http://en.wikipedia.org/wiki/Secure_Electronic_Transaction . Technically it was remarkably similar, e.g. use of dual-signatures instead of multi-signatures. It was also remarkably similar in the human-factor realm, that is the core cryptographic developers of SET displayed disdain and openly denigrated the needs of accountants and other operations personnel. Thus SET was "adopted" by organizations that were already running into red ink as a way of spreading the responsibility for the failure and further muddying the accounts. Obviously there can be no direct analogy for every aspect of SET and Bitcoin. Primarily because SET had high-level commercial sponsors from the outset and the whole budget of e.g. The Bitcoin Foundation is smaller than the fuel budget for a single private jet of any of the SET-sponsoring executives. |
|
|
|
Spammer. I never contacted him nor I ever wrote anything suggesting that I'm on the market for his type of services. Hello 2112, iam a young professionell graphic & webdesigner. Some references:https://bitcointalk.org/index.php?topic=249680.0Assumed you like my graphic stuff and if you have graphic jobs in future or questions about don't heasitate to contact me. I would be very happy about a possible future cooperation with you... kind regards jan |
|
|
|
Does anyone know of a C/C++ program someone else has already written that does what I'm trying to do here; just walk the block-chain and track transactions? All of these code bases have sooo...many dependencies that you dive into crytographic hell trying to decipher them.
Yes, user znort987 did just that. But then he couldn't stand the pressure, deleted the key posts and quit participating in the forum. His thread starts here: https://bitcointalk.org/index.php?topic=88584.0And the source code is still available: https://github.com/znort987/blockparserYou may want to check his thread and his post to understand a bit of what had happened and avoid any possibility of future stress or nervous breakdown. |
|
|
|
It seems that this tactic now evolved. I think somebody wrote a program to synthesize an English language drivel out of the phraseology gathered from BitcoinTalk. Case in point: thermos. I'm making a full quote of just one message for the future reference and analysis, in case you'll delete all his posts.
' Question. How can it be, that everyone has another size for the block chain. I read here sometimes about 11Gig, now you have 8,09. I have 9,79? From which factors the size it dependend?
Blockchain.Info says 8280 MB, it's 8.09 GB.
Hm cool, but on my harddrive the chain requires 9,81 Gigabyte. This is the size of my folder "blocks". So how can that be? "
Core developer paper clues : https://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/ECDSA one name for the bitcoin double-spending attack. Dead blocks, so they won't store them in disk neither. it is a old dust blocks, double spent coins they secretly store them on your hard drive disk. Warning did you send a report to Microsoft support Money client i'd start there it takes 24 hours online support. I haven't gotten much feedback on the #bitcoin-otc WOT yet, I am registered there and that registration is linked to my localbitcoins who is skimming many coins you have to dump escrow service because it goes against satoshis' white paper . Justice crew upload to your computer. Then back it up and encrypt it. Don't leave your coins up on an uninsured site that could lose or steal them. Please explain how the site could steal his bitcoins? I don't think you understand how blockchain.info works.Please also explain how the site could lose his bitcoins if he manages to get a backup of his wallet blockchain private key sniffer project. This is nothing more than the twins and their lawyers doing some p&d disclosures. Absolutely correct the SEC filing has to include warnings for investors. Cryptocurrency online gmabling. Indeed any completely new coin has the risk of a heavy United States goverment regulatory response.This whole bitcoin netwotk started as a role playing game there is an unusual animosity towards bitcoin from the established Wall Street lawyers consider bitcoin "game coupons" cult. I just got hacked with a: "you just received bitcoins click here" / chat box type malware client wallet worm. I'm all good now i caught the hacker i'll post pics of you want, I rmanually removed the bad code. It seems to me Bitcoin core developers prefer snitch policy. The blockchain keeps growing, backdoor is not implemented yet today, Gavin spoke about everything except the IRS issue. Is there any progress? Or is the game over? That's not nice, you've completely ignored all the dust code Peter Wuille has done with ultraprune, which sets the stage for pruning the currently 8GB blockchain that takes up a whopping 1.6% of my laptop's hard disk (at this rate it doesn't matter if it takes him another year or two to fully implement pruning). Not to mention his fast signature checking implementation. Gavin's recent payment protocol work is equally important, and maybe he's lazy not working on these things simply because Peter Wuille already is. Problem with syncing up on NOVA computer and now i know why it's too big and buggy The wiki says " In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent... As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers." Read the Satoshi pruning description on reclaiming Disk Space Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree, with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. Current methods won't detect colluding malicious miners, just an accidental split of the network or an split attack performed by a party controlling the links of a node. " Collaborative malicious mining sounds like something the bitcoin community needs to look into, we never heard of that party network it's based in the U.S.A!!!! our best friends ~> PEACE LOVE AND FREEDOM TO ONE AND ALL ! |
|
|
|
If you go ahead and rebuild the same database in parallel, that's fine, but unless pruning is implemented you'd eventually end up with the same disk space usage as today (well, more as you need space for the extra indexes).
I don't know if Mike Hearn doesn't know it or just pretends to doesn't know. But it clearly fits his pattern of producing misdirecting arguments. He applied nearly the same misdirection almost a year ago in the "[POLL] Multi-sig or scalability--which is more pressing?" thread. https://bitcointalk.org/index.php?topic=94453.msg1046473#msg1046473Full undo/redo logs for a UTxO database will indeed consume the same (or slightly higher) amount of storage as a raw blockchain storage. But unlike raw blockchain storage undo/redo logs are temporally clustered. The older and older transaction logs can be put in a slower and slower storage. All good DBMS-es have a way of efficiently backing up old transaction logs and restoring them on demand. This isn't a place to repeat the same old set of arguments that led to creation of the database management systems as an efficient way to exploit temporal clustering in the data sets. Any decent DBMS textbook will have them. |
|
|
|
Not totally, it still needs a PC running a stratum proxy.
When there is time and the poor little ARM can handle
the workload it would be nice to have truly it stand-alone.
Thank you very much for your reply. Felipeo and I were using the term "standalone" in the old software engineering sense: not using the OS services like network stack, dynamic linking and memory management. A lot of Bitcoin software is hopelessly entwined with humounguos OS-dependent components like Python interpreter or OpenSSL library. I was just trying to confirm my guess that your miner software isn't dragging that baggage. Thanks again. |
|
|
|
Code is running on the ARM Cortex M3, getting work from
the pool and sending results back using on-board Ethernet.
Just one quick question about your miner: is it running standalone (no underying OS, but using a lightweight TCP/IP stack) or hosted (by an OS like Linux, and if so, which OS)? Thanks. |
|
|
|
Yeah I wouldn't touch anything you do with a 10ft pole. I had my hands on all fpga from all manufacturers that were available, yours were clearly far worst.
This seems a bit unfair on Enterpoint/yohan. My CM1 boards are still running strong after about a year of continuous usage I think you and kakobrekla are talking about two completely different measures of quality. kakobrekla is talking about the signal integrity dimension of the overall quality. norulezapply is talking about the manufacturing and reliability dimension of the overall quality. Those two dimensions are nearly ortogonal and incommesurate. This thread is proof for both: it took the longest time from the delivery of assembled hardware to the delivery of correctly and efficiently operating bitstream. Apparently CM1 has some sort of ringing/standing wave problem in the clock distribution networks and the USB interface on the PCB. But once working CM1 proved themselves much more reliable than the majority of the consumer grade GPU boards used for mining. Those GPU boards had almost no problems with statrting up minning but became a real challenge to operate continuously because of the component failures. I'm just an observer here but there is one striking thing about all the Enterpoint PCBs: they are all very symmetric geometrically. On the other hand I know that the PCB designers often intentionally make their designs geometrically asymmetric as a simplest and cheapest way to reduce the Q-factor of the possible parasitic resonators made of the PCB traces. yohan had mentioned several times that the CM1 product was not developed using the full human resources of Enterpoint. It makes me wonder if Enterpoint even has a full time analog signal integrity specialist. I certainly have seen several organizations where the signal integrity issues were resolved purely by trial-and-error process. I'm just contrasting Enterpoint's approach with bitfury's approach: he seem to be the only one who made the analog simulations of the signal and power distribution when designing his ASIC. Professionally I have only experience with the methodology very much like bitfury's which results in the software (bitstream) being delivered ahead of the hardware (PCB). |
|
|
|
There is some sort of combination Wordpress/Javascript/Java exploit being pushed by that site. It is just a single line of document.write() before even DOCTYPE html. So yeah, visit with your guards set to high. This is some non-deterministic exploit, disappears upon refresh. Anyway, I'm going to paste the main text here for the safety of our readers. Is the National Security Agency Behind Bitcoin?
Friday, June 21st, 2013
by Anthony Migchels
Recently a 1996 NSA report surfaced, ‘predicting’ a crypto-cyber unit eerily close to Bitcoin. So eerily close, that, knowing their M.O., the question arises whether this report is a prediction, or a plan.
The report can be found here. I don’t know how long it has been circulating in the Alternative Media, but it seems it just surfaced. It is stunning. It looks very much like an architectural design of the kind of issues this cyber unit should solve. It is stunning not only because it so closely resembles the architecture of Bitcoin, but also since it so conspicuously avoids all the real problems with our monetary system, i.e. Usury, scarcity of money and the manipulation of volume.
If we look at similar ‘predictive’ reports on for instance population control, which have had such a major impact on the Truth community, we must conclude that this particular NSA report on crypto-cyber currencies looks more like a design than a prediction.
Meaning that Bitcoin just officially became a Money Power meme.
Bitcoin architecture
The NSA report goes deeply into the challenges a crypto currency faces and lists the various security and implicated regulatory risks. Both from the point of view from regulators and developers of such schemes.
Amazingly, a key writer of the report is called Tatsuaki Okamoto. In the Bitcoin community this has been picked up as remarkably similar to Satoshi Nakamoto, the pseudonym of the enigmatic developer of Bitcoin.
As we have been discussing, Bitcoin was designed to be scarce and deflationary. Interest-free credit is impossible with Bitcoin and this year we have seen wild trading in the cyber-unit, with a massive bubble and the unavoidable crash. Nonetheless, Bitcoin’s rate at this point is about $110 today, up from $5 November 2011. Its total market capitalization topped $1 billion at its peak and is still substantial.
Implications
An interesting issue is In-Q-Tel’s involvement. In-Q-Tel is the ‘not for profit’ investment arm of the CIA. Undoubtedly just another control mechanism. In-Q-Tel is investing or planning on investing in Bitcoin, presumably by buying some of them. The CIA has been involved in an extensive dialogue with Bitcoin people. It is unclear as to what this ‘dialogue’ amounts to, but obviously, combined with this shocking NSA paper, the whole thing looks pretty suspect.
So what are the bad guys up to? Are they creating a unit with which they can finance their international drug trade without risking money laundering in the banking industry, which is forced to be more and more transparent?
Perhaps it’s not for nothing that American legislators have shown alarm at the uncontrollable flow of funds?
Or is it all just a ruse to undermine free market currencies and regulate them to death, using Bitcoin as some sort of monetary false flag?
This latter scenario would explain the heavy handed and totalitarian way the DHS recently seized some account owned by Mt. Gox, the biggest Bitcoin exchange. Note the DHS is not some financial regulatory body, but the Gestapo itself.
Conclusion
Even today it’s too early to come to conclusions about Bitcoin. Perhaps it’s still a well-intentioned try, destined to failure by its faulty design, or destroyed by the agencies. Or it was designed from day one as a tool to help maintain control of the money supplies of the world.
But it is amazing how the NSA report addresses the ‘need’ for privacy with transactions as the main monetary issue, ignoring all the far, far more important problems we have with our money, and how Bitcoin answers exactly the challenge put forward.
Knowing the ways these people think and operate, this NSA report basically puts to rest the notion that Bitcoin was a completely innocent ‘free market’ or ‘human action’ kind of thing to begin with.
+++
|
|
|
|
Anyways, if that's still the case I'd be uneasy about including those numbers… they could be fudged quite a bit at zero risk of getting caught.
I fully understand that you don't want to consider the pre-tape-out numbers for the inclusion in your table. But out of three columns there only one is unknown. But fudging isn't zero-risk for those who ship their hardware to the end-users. It is only a matter of time until one of the Block Erupters that were sold gets accidentaly damaged and the chip will get decapped. Check out this thread: https://bitcointalk.org/index.php?topic=231400.0 and the recent post of this user: https://bitcointalk.org/index.php?action=profile;u=23585 . For now it is just a re-confirmation of the Avalon data. |
|
|
|
What's missing is enough of my free time to dig through a 42-page thread.
Fair enough. But I gave you a link to a two page thread where all the relevant information was in the first half of the first page. Calm down dude.
I'm calm, just confused, like many others here. I see you writing posts then almost immediately deleting them, it only adds to the confusion. Anyway, here's the available Block Erupter a.k.a. ASICMINER information. Update
Chip Specification
Technology Summary:
130 nm
1 Ploy
6 Metal
1 Top Metal
Logic Process
Core Voltage: 1.2 V
I/O Voltage: 3.3 V
Core Frequency: 335 MHz
Core Frequency Range: 255-378 MHz
PLL Multiplier: 28
Power Consumption: 4.2 J/GHash
Number of Pads: 40
22 Data
18 Power
Package Type: QFN40
Packaged Chip Size: 6 mm x 6 mm
Our chips
Generation 1: Block Eruptor. 130nm with 6-8J/GH. Each chip's rated frequency is 336MHz at 1.05V. It translates to 336MH/s because it does one hash per cycle. The chips work stable and well at 392MH/s at 1.15V. Further overclocking needs proper handling of heat and power supply.
There are still no definite information about the die size. There are two posts that predate the tape-out. Hashrate: 1.25GH/s per chip
Area: 17.5mm^2 per chip
Power Consumption: 13.3W
Hashrate: 1.00GH/s per chip
Area: 21.7mm^2 per chip
Power Consumption: 8.23W
I'm also positive that friedcat made other posts that he subsequently deleted, at least one in direct response to my post. It must have been commercially sensitive at that time. |
|
|
|
That's weird, I wonder if he edited his post, the very next one is a post by me complaining that he posted the packaged size instead of the die size (in Oct 2012).
The original post date is 2012-10-24, with last edit on 2012-12-22. The code block with the process data is quoted exactly on 2012-12-13. Quite possible! I can't keep up with the tangled mess of threads this forum has become… Case in point, I cannot find Avalon's statement on the hashrate per chip. If you can post a link to that I'll add them.
I gave you already the link to the thread with posted photos of the hashing module. Avalon advertised 3-module 66Ghash/s and 4-module 88Ghash/s device. The picture clearly shows that each module has 80 QFN chips. What else is missing? I'm somewhat experienced with human factors in the technology education and businesses. Anytime I see PhD-level personnel unable or unwilling to do GED-level arithmetic problem there's always an interesting human story behind that situation. I can't stop wondering what is the story here. Or maybe it is just my sense of humour failing? |
|
|
|
Avalon chip count and power usage are available. You can now update your comparison table.
Thanks, but I need the actual die measurements, not the number of chips-per-wafer. Please let me know if/when they are posted by either the Avalon manufacturers (I'll take their word for it) or some third party (must include a photo). That information was available since last year. https://bitcointalk.org/index.php?topic=120184.msg1294431#msg1294431TSMC
TMEM91
================================================
Chip Size : X = 3.9760 ,Y = 4.0560 mm
Reticle Size : X/cell = 3 ,Y/cell = 3
Offset Value : X = -3.7668 ,Y = -2.2990 mm
Alignment Mark : (118.80,83.20),(-118.80,-83.20)
Alignment Mark Tolerant Distance : 1.6 mm
Notch Reserved Distance : 7.75 mm
Start Distance : 7.75 mm
Ring Edge : 3.0 mm
Photo Die Number: 4055
|
|
|
|
Can someone translate what bitfury said in his long post?
OK, I'll try... Bitfury did just a short burst tests (lasting at most few seconds) of his chip at various voltages and various speeds. He still need to test it under a continuous load and at various temperatures. Now I switch to explaining what he didn't do. He didn't use any "standard cell", "library" or other purely digital logic EDA tools, which were thus far used by all other competitors. They used unrolled pipeline designs and their simulations were very inaccurate-purely digital. Due to the very approximate simulation and high toggle rate of the flip-flops in SHA-256 the real power used by competitor chips was significantly higher than the simulated power usage. Now I switch back to what he did do. After completing the initial digital logic design he had switched to a full-custom design process: he no longer designed at the gate or flip-flop level but at the individual transistor level. He no longer dealt with zeros and ones but with volts and amperes. He had used a very precise analog models of the transistors from the foundry and used analog circuit simulators: SPICE and/or BSIM. This was possible without multimillion budget because he didn't unroll the hashing kernels but kept them rolled and replicated them several hundred times over the area of the chip. The additional benefit was that his power simulations were very accurate: the simulation error margins were lower than the wafer manufacture process error margins. One of the goals he had choosen for his chip was to have them work with rather wide ranges of the supply voltages, in particular with uncommonly low voltages. To achieve that he had paid extreme attention to minimizing the switching noise both inside the chip and on the chip pins. In particular despite of the relatively low clock speed (100MHz or low hundreds MHz) the I/O design methodology was the one used for GHz signals (or high hundreds of MHz). Because of the above goals his chip isn't really plug-and-play for designers used to deal with typical digital logic design workflows and tools. To get all thats possible out of his chip requires familiarity with analog and mixed signal design. In particular it requires familiarity with transmission line modeling to design the best PCB with a large quantity of his chips. His goal is to publish http://en.wikipedia.org/wiki/Scattering_parameters required to accurately model the I/O terminals of his chip. He probably already has a good idea of what those S-parameters are from the high accuracy simulations using SPICE/BSIM. But possibly he either can't (because of NDA with the foundry) or doesn't want (for competitive advantage reasons) release his internal models and their parameters. Additionally, the S-parameters are affected by the quality of packaging of the chip and there is no real substitute for making the actual measurements, for which he plans to use devices made by http://www.signalhound.com/ . Obviously, I'm not bitfury, and the above is just my educated guess. |
|
|
|
So there's nothing to worry. And we can start planning for further testing and production.
Congratulations then! As far as further testing you should measure hashing rate of the chip when immersion-cooled in champagne. At the same time you could test your own hashing rate while ingesting champagne.  |
|
|
|
And it looks like there's a progress...
OK, nobody funnier than me came forward... Bitfury's saying that the "transmogrification" of the "winning nonces" will be doable all in software without having to implement the "decryption" in an auxiliary FPGA. From the quick glance at the code snippet it looks like bit order in bytes need to be swapped, amongst the other things. Remember that the bitfury's chip implements the sea-of-hasher-kernels design. The nonce is not a straight linear 32-bit counter. The 32-bit output nonce is a combination of the kernel number (there are several hundred of them in the chip) with the sub-nonce counter for each kernel. And the kernels don't all work in the round-lockstep, they work in the wavefront fashion such that the k i round constants can use a distributed storage similar to a racetrack. The true error rate of the chip under a full load is still to be measured. |
|
|
|
Can we get back to talking about what the ACTUAL chips are doing here? Sheesh!
Somebody who has an experience in sportcasting should just keep refreshing the last posts of bitfury and narrate them, the tension is so palpable. Apparently the output circuitry isn't working as expected. bitfuty had soldered a level shifter out of a discrete audio-frequency transistor BC817-40 and clocking the SPI circuitry down to 100kHz. The test vectors still didn't match. Leszek, the Polish coworker of bitfury has created a bit correlation matrix for the simulated and actual test vectors. Bitfury has referred to the process as "decryption". It is hard to guess if the smiling emoticons are straightforward humour or gallows humour. The whole thing reminds me of a stay in a mountain hostel during a sudden inclement weather. There was some high-level ice hockey match, e.g. Soviet Union vs. Canada or Czechoslovakia vs. Switzerland. The weather got worse and disabled the radio and tv relay station on the nearby mountain, cutting off all the regular mass media. So all the sports fans had to resort to the short-wave receivers with improvised antennas and the very spotty short-wave reception during the bad weather. The corridor in the hostel was a bedlam of screams as the listeners in the separate rooms tried to make sense of the few words that could be understood in each of the transmissions. |
|
|
|
|
Three quick comments:
1) Your proposal doesn't seem to handle chain reorganizations in any way, i.e. negative confirmations (or de-confirmations) of blocks and transactions.
2) Your proposal doesn't solve the most glaring misfeature of the current bitcoind/bitcoin-qt, i.e. inversion of control related to the ThreadSafeAskFee() function.
3) I don't see how your proposal will interoperate with any of the existing distributed transaction coordinators, e.g. Tuxedo, MSFT DTC, just anything really that would allow Bitcoin software to correctly execute three-phase commit protocol.
I'll admit that I haven't throroughly audited your proposal, all I did is just a quick skimming looking for the same problems exhibited in all previous proposals floated here.
Thanks.
|
|
|
|
Simulate the HDL to verify no functional errors. If issues persist even after that, drop in chipscope to take a closer look.
Ha, ha! I like this! Eyeball check invalid hashes with chipscope. His design starts failing when air-conditioning is off. So debugging all this with AC off in TX/NM summer heat will be a fitting punishment for not architecting the fault-tolerance properly.  KC705 is a great educational toy, really is. I have nothing against learning when no innocent living creatures are harmed. |
|
|
|
Since the board comes with an ethernet port, DDR, FLASH, etc., the next part of the project would be to instantiate a small Microblaze CPU and load Linux off it and make this board a stand alone miner.
And when you'll get a miscompare you won't know whether the fail was in the hasher or in the CPU. |
|
|
|
|
Show Posts
