The individual here happens to own the other 95% of the company. He created the shares in the first place. It's without a doubt he's entitled to the profits.
It would help if the "individual here" would disclose his agreements with fireduck. The "individual here" is well known for his sales skills, but not for mathematically proving anything, least of it mathematically provable bets. I'm not trying to flatter myself at all. I'm trying to flatter Bitcoin. Blockchain enables mathematically provable bets, and this is a game changer for gambling around the world.
I wonder how the link below will become a mathematical proof of corruption in wagering. https://s3-eu-west-1.amazonaws.com/satoshidice/hash.keysI think this is the first case in the history where somebody sold the racetrack, but kept the list of horses that are going to win on it over the next 10 years. So, who else has the full secret list? |
|
|
|
I was little disappointed after reading the strategy, basically just saying "keep promoting and developing bitcoin". Thread starter must be a genius  While I identify with the OP's positive attitude, I too expect a little more from a strategy than a series of platitudes. My strategy has been to inform others like myself about the Bitcoin project. I'm met with varying responses, and that's all well and good; the 95%-male computer-savy community of ~100K is a great foundation. But now it's time to branch out. We need to start selling bitcoin (small b) to average joe's as an investment, similar to gold. Here's the pitch: Bonds are inflation-prone. Stocks and RE are risky. Gold has high storage and transfer costs. Here's an alternative: bitcoin. Cheap to buy. Free to store. Likely to appreciate over time. Private. Can never be confiscated. Recommend ~25% of your portfolio. How's that for a strategy? I was thinking the same thing. If BTC could be bought like a mutual fund it could be pitched as a unique, risky but futuristic option for automatic monthly IRA contributions. We'd just need some fund manager to set up the automatic purchase at market price and storage of BTC is some sort of insured bitcoin bank. They take a percentage and report fund value daily just like a mutual fund. With the flood of new money the price would skyrocket, then word of mouth takes over and everybody else wants in. We early adopters get rich, the fund manager gets mega-rich, and suddenly Joe the Plumber knows about bitcoin. Ah, the wet dreams of every pump-and-dump strategizer. Quoted for posterity. |
|
|
|
Within a few seconds there was a new order...
Remember that you see MtGox through an anti-DDoS proxy run by Prolexic. If your behavior of accessing MtGox resembled in any way a DDoS then your access to MtGox is being throttled. Prolexic's detection algorithms are secret and neither your nor MtGox can obtain any detailed information about them. If you have an access to different IP space try accessing MtGox from a different source IP. The throttling that Prolexic uses takes into account the behavior of whole subnets, not just singular IP addresses. |
|
|
|
By the way Nevada is working on making online gambling legal. There is nothing public yet but industry and the political efforts are moving that way behind the scenes.
Yeah, this agrees with the recent observations made at the CES'12 in LV. In the past both NGCB and LVMPD would both follow the leads on some small-time payments being directed (or diverted) to the online games of chance. This year officers of both NGCB and LVMPD closed small-time investigations immediately upon confirming that the payments are (or could be) used for non-gaming related transactions. So apparently the winds in Nevada had changed direction. |
|
|
|
Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...
I can assure you that RHEL5.* is widely used, probably still even more than RHEL6.* . Think of all the people who already have things/projects going on for them and making money (or at least sleeping peacefully at night). They were maybe thinking of adding Bitcoin to them as a trial. The stridency of the core developers with respect to supporting only the most recent Ubuntu was really off-putting for them. |
|
|
|
Don't use the system provided Boost library?! There's nothing wrong with it, as far as I know. Or did you mean something else?
I took the following quote at the face value, maybe incorrectly. Q. Do you support Red Hat Enterprise Linux 5?
A. I have no plans to support Red Hat Enterprise Linux 5 at this time. Certain libraries (such as Boost) included with RHEL5 are too old to support current versions of Bitcoin and cannot be safely updated without risking breakage to other parts of the existing system.
I'm familiar with the "upgrade treadmill" as a way of revenue pumping and padding the billable hours, but my position is that the only way to win is to not play. I'm positive that RedHat will change the key libraries from underneath of your program, so prepare early. Ubuntu does that all the time, but the core developers are happy to play. Edit: I'm not proposing that you support GNU C++ 2.96 and RH7.2/RHEL2.1; but I see that RedHat still actively supports it in RHEL6. Apparently they have enough customers/partners who refused to jump on the treadmill: compat-libstdc++-296-2.96-144.el6.i686.rpm 2010-05-17 - Jakub Jelinek <...> 2.96-144 - ensure libstdc++.so is linked with -Wl,-z,noexecstack (#592519) 2010-04-26 - Dennis Gregorovic <...> - 2.96-143.2 - Rebuilt for RHEL 6 Related: rhbz#566527 The above is just one of the things I had memorized from many years ago. I actually never installed that release except in virtual machines. But I see that the general strategy is still working for many of the RedHat's customers/partners. |
|
|
|
This is a reasonable concern. I hate DLL hell myself, and I'm perfectly willing to give this another go. I actually tried this at first, and RPM did not want to cooperate. So I'll beat on it some more.
Thank you for your understanding. I know my position on software updates isn't the most common, but it did and it does hold the value pretty well. May I suggest that you also "privatize" boost:: ? My reasoning is the same and I know that the potential market (for consulting, support, etc.) would greatly increase. I'm not on the market myself, but I see people needlessly shutting themselves out and find that regretfull. This really depends on the default GNU compiler for particular RHEL, not on the boost:: itself. But if you already have a test installations then the additional work required is fairly small. Admittendly I'm somewhat extreme in software conservatism having supported RHEL2.1 until the beginning of this year. The money was good, and the savings for my clients (from e.g. not upgrading ColdFusion from Macromedia to Adobe) were staggering. |
|
|
|
The packaged files are supposed to be owned by root. That's bog standard security. The binaries should not have access to modify themselves.
I'm sorry, I was expecting "bin:bin" not "root:root" as the owner of the read-only files. There's a fine line between distrust and paranoia. It's very easy to verify that the RPMs are good. That's why we have source RPMs in the first place. A distrustful person would inspect the source RPMs carefully to ensure there was no funny business going on, and perhaps rebuild them himself if they appeared OK.
The main motivation is neither distrust nor paranoia. The main problem with the RedHat package manager is the difficulty of recovering from the situation where a RHN system update kills customer's own applications. The secondary problem is that by replacing an RH-provided library you implicitly break the RedHat's service contract agreement; i.e. RedHat gets off the hook on the support of such a system. The ternary problem (but for me primary problem) is basically a replay of the "Windows DLL hell" game under another operating system. I'm not going to play it and would not recommend anyone to play it unless they get paid by the hour for refixing the same problems. Side-by-side is the way to go and Linux supports it fairly well (using -rpath and $ORIGIN). I say all this as a long-time RedHat Partner. |
|
|
|
Since you didn't even bother to look, you are probably unaware that I do not run bitcoind as root.
I apologise, I was wrong. Indeed the /etc/rc.d/init.d/bitcoin starts the app as user "bitcoin". I couldn't find any "useradd" and "groupadd" calls, but they are there in the RPMs. As it turns out my rpm2cpio tool is buggy and doesn't do the proper conversion for some RPMs. It appears that the packaged files are owned by "root", but it may be another bug in my tool. As you may have expected I wouldn't dare to actually install the RPM. |
|
|
|
Now that this has been out a couple of days with zero issues reported, Only yourself and desperadoes would try your RPMs. May I suggest that: 1) don't replace any RedHat libraries, everything private should be linked with "-rpath" to a private directory or "$ORIGIN" 2) don't run bitcoind as root, but as a regular user (despite all your SELinux configuration) or: 3) get yourselves hired at RedHat Good luck. |
|
|
|
I heard that Litecoin Scrypt can become more memory intensive by just changing a variable, is that right?
So what? You can make an ASIC that drives a DIMM socket or even a whole bank of DIMM sockets. It really isn't a rocket science. Same with FPGAs. The only wrinkle is that the current favorite: Spartan-6 has a MCB (Memory Control Block) that is designed to work with single memory chips, not the multiple chip memory modules. So the DIMM memory access logic would have to be soft-synthesized instead of the using hard MCB macro. |
|
|
|
I think if this could be added to the URI spec, it would be useful and easy to use. For instance:
Sir, I beg you: please don't reinvent Acrobat Reader secure form signing. Please leave the attempts to embrace, extend and fuck up the electronic commerce by unnecessary integration to the giants like Adobe. Please! Thanks. |
|
|
|
Fireduck is a skilled guy, ... But of course, SD might well be more fun  Especially since he knows the winning numbers for the next 10 years. There's always an opportunity for "self help." |
|
|
|
The blockchain makes the Nevada Gaming Control Board irrelevant. I doubt they'll be impressed much at all with Bitcoin  Dude, don't try to flatter yourself. NGCB officers know quite well what is going on. In fact one of them talked at length and shook hands with Casascius and Bit-Pay crew when they were exhibiting in LV during CES. NGCB is a worldwide recognized authority in gaming regulation, far wider than their real authority reaches. At every moment bots scrape the http://gaming.nv.gov/ ; and if they detect any change all gaming executives worldwide will have that change translated into their local language and given appropriate interpretation first thing in the morning. |
|
|
|
The statistics would bear that out and it would be caught, then the algorithms altered. It could be a short term loss, but not a long term loss.
Yeah, but why tempting the fate by precomputing the winning numbers for 10 years ahead? Nevada Gaming Control Board wouldn't be impressed. |
|
|
|
Oh! Heh...well, I figured "Owner is seized" (under External) covered that.
No those are two completely different risks. Seizure of the owner would be effected by some government to stop the operation of SatoshiDICE. Secret leakage would be effected by some non-governmental entity to continue operating SatoshiDICE in a completely predictable manner. Libertarians (like Erik) are particularly easy target for the later kind of the risk. |
|
|
|
I updated my post. Should I start a new thread with the subject "S.DICE: Risk Analysis" ?
But you updated it to imply server hack. I was thinking more along the lines of hacking off fingers of evoorhees or fireduck. |
|
|
|
Internal Risks
- Running low on cash reserves
- Taking a long time to rebuild cash reserves (small dividends during this period)
- secret.keys leaked (those are precomputed until 2022.01.14) - secret.keys non-random (e.g. Debian'08-like flaw) |
|
|
|
This is rubbish, IF the DOMAIN is seized.....then they need to get a new one and your assets there are fine. It's if the server is seized (don't even think there is much of a server for this) then it's a different story.
What if the manager gets seized? As far as I know Erik operates out of UAE, or some such. And according to Islam gambling is not compatible with Quran. On the other hand one of my classmates sold remote car door opener "testers" out of UAE and still has both hands. |
|
|
|
|
Show Posts
