This is worth preserving against future edits. I had to glue two posts with an edit. did i read the fine print right, 100,000,000 shares at .0032 or 3,200,00 btc or more than 30 million usd?
that is insane... Your math is a little broken there, but as they say practice makes perfect. yeah, i was like lulz.... Me too. Cause of the math. In general money people are good with numbers. what is stopping someone from coding up a clone of satoshi dice over a weekend and taking a piece of
the pie... thus reducing your profits.
it seems that is a major threat i would love to hear countered. I'm not a tech, but I would guess the same thing is stopping someone today that stopped someone up until today. And also the same thing that stopped all the groupon clones from becoming groupon and all the facebook/twitter clones from becoming facebook/twitter. In the words of the once-famous Jerry Seinfeld, No Resources, No Skills, No Talent, No Ability... Go with the flow, hate less, live longer. Investing in SatoshiDICE actually peaked my interest. These returns are ridiculous though... AAPL pays ~2.5 dollars a year in dividends. The share trades for ~650 dollars. You may think the reason you don't own AAPL is because "they're insane". The truth however is that you don't own AAPL because you don't have money. 0.0033278 BTC for 1/100M of 10%? Are you insane? I don't think you read the offer very carefully. 0.0032 BTC (lowest tier) buys someone 1/100M of the revenue of SatoshiDICE! The dividend yield works out (if worked out by people who actually can do division and multiplication) at an estimated 0.00036 BTC a year per share, or a little over 10%. This revenue has some very marked advantages over any available alternatives. To wit: a. It is better than Ponzi. This should be self explanatory. If it is not self explanatory you are not an investor and do not belong discussing securities. b. It is better than mining bonds. Mining bonds depreciate. You pay 1.5 BTC to buy one today, it's worth 1.0 BTC in four months and in the interim it's paid 0.1 or 0.2 dividends. You've not made 10 or 20% a month. You've made a 30% loss over the quarter. A 30% loss compares disfavourably to a 1% gain a year. c. It is insulated from fiat-world risk. The government of Japan decides to arrest a person from MtGox staff? Your MtGox investment is now worth zero. Game over. Dwolla decides to lock the accounts of TradeHill? Your TradeHill investment is now worth zero. Game over. The only thing that can kill pure-BTC plays like SD is the collapse of BTC itself, which is no extra risk to the BTC investor: you already have those BTC. Here's another way to look at this: 320,000 BTC is a little more than 1.5% of all bitcoins that will ever exist. And for now, and possibly for a little while longer, SatoshiDice is a lot more than 1.5% of all that's worth owning in bitcoins. There are some good companies out there. Maybe ten, maybe twenty, certainly not one hundred. This is one of them. Subtracting expenses out before the reported revenue numbers skews the profitability. Net profit is calculated as the difference between revenue and expense. Why would this be problematic? What would it skew? I still have a hard time grasping how these voluntary associations are being referred to as companies and corporations. Because that is exactly what a company or corporation is: a voluntary association. Furthermore, milk is the white liquid seeping out a cow's udders, not the item found in a government approved package announcing to the world that within lies milk. This is an important point and I think too easily forgotten. When someone is talking about raising something like $7K for a project that you'd never get a loan for from a bank or never would see finding through an Angel, for instance, then I think these cyber equities are a fantastic innovation. But raising over a quarter of a million dollars, with a valuation of several million dollars -- I wonder if this cyber-equities approach should be reconsidered. This is a very limiting, unfortunate and in the end destined-to-fail way to regard bitcoins. They are not this exotic pet, to play around the "serious" fiats and fill the cracks they leave. Bitcoin is the harbinger of doom for all fiat currencies. That is its role. That's what it is supposed to do. The notion that it should be relegated to denominating scams and ridiculous penny-ante endeavors of bizarre internet denizens with visible mental handicaps (yes, not being able to do basic math is a mental handicap for an adult human) is loathsome. Bitcoin will support million dollar ventures, and it will support billion dollar ventures. And then it will support trillion dollar ventures, and quadrillion dollar ventures, and as the dollar slowly I mean quickly devalues into irrelevancy bitcoin will support everything. That's the paradigm. And as shocking as this may sound, nobody needs nobody's permission for this. Now, here's the question, and it lies in front of everybody: do you have some money for which you want to make some money, or do you have some time to kill for which you want to waste people's time? That's the whole story. |
|
|
|
Bitcoin now is kind of like the web was a couple of years after it was created: complicated, limited, obscure and most people used AOL or CompuServe. Film trailers had AOL keywords in them, not web site addresses. Of course eventually people all switched to the internet/web even though it didn't have the same kind of simplicity and military-style marketing campaigns behind it, because of its inherent advantages.
You make some very good and valid points, but at the same time you omit crucial features. AOL,CompServe,Prodigy,etc. were: a) walled gardens b) vehemently against 3-rd party scripting languages due to their insecurity Netscape had: a) military-style maketing campaigns b) Javascript, as insecure as it was c) openness The same tug-of-war is versus safe prison and wild,wild world is right now happening between Apple iOS and Google Android. I'll let everyone else to make their own analogies with the current state of Bitcoin and the value of the protection they are getting from the helmsmen. |
|
|
|
Beautiful poem, but just a poem. But you've probably seen the videos shot from the top floors of some hotel next to the Indian Ocean during tsunami. You've seen people approaching the receding ocean waters in curiosity. Only few of them survived, those who managed to climb and hold to the tallest palm trees. An there also was this 5-th grade girl who recently had class about tsunamis, seen the receeding waters and told everyone in earshot to run thus saving lives of multiple people. Same thing is happening here, except the "blood on the streets" is only proverbial. And the cool cats won't really need nine lives to appreciate the value of learning from the mistakes of the other people. Edit: Ha, ha. I just re-checked the information from the poem. It appears that in English cats have nine lives, whereas in romance languages cats have seven lives. I didn't know that. Edit #2: Not 5-th grade but 3-rd or 4-th. I found the link: http://en.wikipedia.org/wiki/Tilly_Smith |
|
|
|
something in the human psyche where we don't calculate the odds
Why are you concentating on humans only? I'm sure you've heard of the cats that were killed due to their curiosity. It is a fact of life. Most cats on this board are young and can be more cautious in their remaining six lives. |
|
|
|
3) It would also be useful if the Satoshi client was refactored into three independent components:
* the library
* the node
* the client/GUI
What we have here is the classic old money/new money split. Old money wants control and protection of their hard-won assets. New money wants a toolset to integrate with their means of producing, well, new money. This will not be easy to reconcille. If you want to see how this worked here look no furter than the recent sidelining of Armory by the use of compressed keys in the wallet. Old money want protection first of all. Therefore they will push for the almost paranoidal security stance. The best example is the use of the deterministic build system Gitian. This is an exact opposite what a system integrator would need. Deterministic builders were pretty much discredited long ago, approximately during Star Wars (I'm sorry I meant Strategic Defense Initiative, not the George Lucas' film), then under the name of "Deterministic Ada compilers." But they recently had a revival amongst those unfamiliar with the history of the computer science. I'm going to predict that the refactoring of the existing Satoshi legacy code will not occur for a long time. |
|
|
|
Bitcoin sales will be slow
Sales? Once a copywriter always a copywriter. Maybe all the frustrated writers from Somethingawfull can pool their talents and come up with some great Groupon deal on Bitcoin? |
|
|
|
Sorry for the newb question: would you mind explaining how to defrag a single folder?
You know, it is hard for me to give a guarantee. There are so many different Windows extensions and so many file systems in Linux, etc. But the simplest thing to do is (on Windows): 1) Use Windows Explorer to copy files to another physical disk (not another partition on the same disk) 2) Delete the original files 3) Copy back from the backup disk to the original place 4) Keep the backup copy made in (1), well for backup. On unmodified Windows the above procedure will greatly reduce the number of fragments, frequently to the minimum (one per file). But the various online antivirus protection tools can completely screw this up. So at least exclude the Bitcoin directory from the online virus protection. The occasional scan only virus protection can stay. If you really don't have a separate physical drive then at least zip the files, delete, unzip and keep the zip for backup. |
|
|
|
How much hashing power could I squeeze from XC3S400-4PQ208C?
None, unless you plan on developing your own bitstreams. And then, when you develop your own bitstream not much, because this is an old Spartan-3, not the newer Spartan-6 that is used by almost everyone else. Great educational toy though. XC3S400 is supported by the free Xilinx ISE Webpack. Edit: I take back the "great" from the "educational toy" above. I took $127.15 as a total cost, but this is just postage. So the better description would be "great ripoff on an educational toy". |
|
|
|
I hope they work on optimizing the standard client soon, because it's going to get unmanageable very fast given the rate of transactions.
This isn't going to happen soon. Mike Hearn is at least acknowledging the problem: Re: storing scripts in the index. Yes, eliminating the blkN.dat files and putting all data into the key/value store may be a way to further reduce seeks in future.
Gavin is flat out against using any well known database techniques: blah blah blah blah
Gentle reminder to the other bitcoin developers: it is generally best not to feed trolls. Use the ignore button. So yeah, use either: 1) software RAM-drives 2) hardware RAM-drives 3) write-behind battery-backed RAID controllers 4) proper SAN filers EDIT: 5) or even an improper SAN filer: just a separate box running iSCSI target over GigE attachment. to store those vital files in your servers. |
|
|
|
Depends on your drive type tho, in the long term you'll extend harddisk lifetime via reduced disk seek at cost disk stress during defragmentation. I just wanted to make 100% clear that I didn't recommend the defragmentation of the whole disk. Just defragment the Bitcoin directory only! You can even save defragmenting the "Bitcoin/database" subdirectory because BerkeleyDB is smart enough to preallocate its log files in 10MB chunks. The other cheap way of reducing fragmentation is running with "-printtoconsole". Then the debug.log will scroll off your screen instead of mutually fragmenting itself with blkNNNN.dat. |
|
|
|
I dont understand how defraging will help the download speed... or anything else really for that matter. Care to explain?
During download every transaction in every blocks gets verified against its source transactions. The layout of the data: separate files for index of transactions and actual transaction scripts to causes immense number of disk seeks. Seeking into fragmented files is doubly slow, because the OS has to actualy first seek to the MFT (Windows) or indirect index blocks (Linux). So the block download process is disk bound not network bound. I wouldn't actually recommend interrupting the initial download to defragment. Just defragment the Bitcoin directory right before starting the bitcoin{d,-qt} after you haven't run it, say, over the weekend. This is a kind of pick your poison choice: it is slow on the rotational disks. If you try to run it off of SSD then bitcoin{d,-qt} exhibits pessimal behavior for the SSD media: very high write amplification of the blkNNNN.dat files and lots of writes with no reads whatsoever in the BerkeleyDB log files (write ahead). If you try to run in on MLC SSD the very act of initial blockchain download puts at least couple of months worth of wear on the MLC flash. People tried to run bitcoind on the ultra cheap Dell nettops with Linux and 8GB MLC disk drive. Quite often the 8GB SSD would fail before completing the initial blockchain download. This was where Satishi bitcoin was still with WX-widgets, not QT. But the underlying data storage hasn't meaningfully changed. The only otimization thus far was to keep just two most recent Berkeley DB logs instead of the higher, variable number from start to finish. |
|
|
|
as I see it its probably best described as a ledger.
Nobody will allow you to keep the ledger that silently wipes out the transactions and changes the timestamps on them. This is what bitcoin{d,-qt} does. And by nobody I mean that it doesn't matter wheter you run you accounts according to the rules of: 1) Uncle Sam who lives in Washington,DC and charges 28% APY for overdue negative balances. 2) Uncle Vinnie who lives over the bodega and charges 1 finger per month for overdue negative balances. It is relatively easy to actually keep the real ledger with modified bitcoin{d,-qt}. You need to override the db->put() BDB call to recognize writes to the wallet.dat and store the actual log of calls in some secondary database before calling the original C virtual function. This log will have proper timestamps (not the approximate to 2 hours and even possibly out of order timestamps) and will have a actual log of monies appearing and disappearing during the orphan/reorganization events. |
|
|
|
BSIM4 are more rich - but for BSIM3 I have data for example for TSMC for MANY real silicon runs extracted + also for many more foundries...
Thanks for your reply. Where I wrote "BSIM4", I should've written genericly "BSIM-family". I played only with BSIM4 and only on an artificial model that was intentionally non-realistic but at the same time consistent with the solid-state physics. A classic educational toy. Good luck with your designs. |
|
|
|
|
In addition to the above (bigger blocks) there is an issue of fragmentation on disk. The blkNNNN.dat files are pretty much maximally fragmented (as far as possible for an append-only file). Those files are also mutually fragmenting with the simultaneously written debug.log.
Just defragment the bitcoin directory after the chain download finishes for a significant speedup. And keep defragmenting it regularly.
|
|
|
|
0) There's no "blockchain format" for the on-the-disk file. 1) blkNNNN.dat files are simple concatenation of the blocks as seen on the network wire. 2) because of the above and the possibility of Satoshi bitcoin client crashing mid-append, there is a possibility that those files contain partially-written blocks. There will be a header and at least portion of the transaction part written, but not all the way to the end. 3) blkindex.dat is just an index, nothing more. Currently it is in BerkeleyDB but there's a planned switch to LevelDB. None of this matters for your parser because the actual block chain will stay being stored in the above described simple format. 4) If you are trying to write your parser in C++ I suggest first looking into the parser written by the user znort987. https://bitcointalk.org/index.php?topic=88584.0 |
|
|
|
This is one challenges for me - there's multiple ways to do it, but basically in flows that I saw before people
use simpler approaches. But - it would work ok for not too-power-hungry designs, while for such massive
crypto they may not work, as number of elements that are constantly switching is VERY HIGH.
This is interesting. What I've heard is that BSIM4 is the most accurate but also the slowest and least user-friendly. Pure-digital designers are happy using simpler models and more streamlined tools. It is more of a tool for the analog and mixed-signal designers. On the other hand BSIM4 is free, only the model parameters are secret and cost money. Not exactly needed, as you can put on borders of single round construction "mock" flip-flops that will just toggle at 50% of clock speed and feed it with data.
So you can perfectly simulate power consumption.
Oh I see, a miscommunication. You meant single physical round design sorrounded by a T-type flip flops, but run for all the cycles of the whole computation. I also meant single physical round design but also shorten the required count of cycles: 16 from the first phase and 16 from the second phase. To account for non-zero boundary conditions use standard modeling practice of topologically stitching top edge to the bottom edge and left edge to the right edge. This is cryptologically incorrect. But it is verifiable, and completely accurate as far as thermal, electric circuit and transmission-line behavior. Do you mean MLM or MPW ?
Actually both. See page 8: Multi Level Mask Single User Runs ... ... This technique is only available for technologies from ON Semiconductor, IHP, LFoundry and TSMC.
|
|
|
|
Botnets of rogue clients don't care about limits.
I doubt about any botnets pretending to be the Bitcoin clients. About the only botnet-like thing that I could correlate with with running a Bitcoin (and Litecoin) client were probes for misconfigured and easily exploitable home routers with remote configuration port open. On the other hand Bitcoin has a mechanism for statistically spreading p2p connections globally over /16 subnets. You may be running your bitcoin client on an ISP that has none or very few other bitcoin clients within the same /16 netmask. I observed this on one of my office ISPs which gave us several disjont /28 subnets. Depending on which IP range I exposed my client I would've gotten vastly different numbers of incoming connections. But they are were legitimately behaving. |
|
|
|
Power Integrity could be done with Spice or maybe better specialized tools (easier)...
Have you heard of anyone using BSIM4 commercially for the last, 100% analog stages of the verification? Maybe quick simulation of single round would help
I'm thinking minimum of probably 32 rounds: because of the multiplexer first 16 rounds are different than the remaining 48. From the non-cryptographic point of view one would want to simulate full shift register runs in both two positions of the multiplexer. MLM asic chip basically tells me that TSMC is foundry
Maybe on the merchant, commercial basis TSMC is the only one. But for the more R&D-oriented clients Europractice offers MLM flows through the other fabs. Anyway, this post is just an excuse to post the link for a really cool chip floorplan porn: http://www.europractice-ic.com/docs/Annual_report_2011.pdf |
|
|
|
It might be possible under CLI but there is no such feature in the QT Version.
It works both with bitcoind and bitcoin-qt. You can set it in bitcoin.conf. The flag is: maxconnections=125 with 125 being the default value. Set it to 9 or 10 if you have bandwidth caps. By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. If you are really pushed into limiting your bandwidth usage then put "listen=0" in the .conf file and set the maxconnections to less than the default 8 outgoing connections. Be aware that Satoshi bitcoin client does not check the spelling of the configuration flags and does not inform you about the ignored flags. This is entirely by design. |
|
|
|
The answer depends on the jurisdiction. For the USA John Nagle had posted some relevant links in the old thread: https://bitcointalk.org/index.php?topic=46486.0I guess the best summary is: it doesn't matter so long as nobody had lost any significant value when circulating and trading them. Once there is a significant loss (and a significant gain on some other side of the deal) then anything goes: the one with the better lawyers wins. Edit: Oh, and make sure that you don't market them as a suitable investments for the proverbial "widows and orphans," or in the Bitcoin parlance "grandmas." |
|
|
|
|
Show Posts
