It has a 550 MHz Nvidia "Reality Synthesizer" GPU. If experience from the mining community is any guide, it's probably vastly inferior to current and previous generation ATI GPUs for integer hashing operations. On the other hand, if there are legions of 12-to-25-year-old gamers living at home and more than willing to burn their parents' electricity, it could strengthen the network considerably.
Willing? Hell, I was thinking of millions of virus-infected zombie machines... |
|
|
|
|
With the recent crack of the PlayStation 3's DRM, it's only a matter of time before botnet code emerges to take advantage of the console's sweet GPU for distributed bitcoin mining.
Discuss.
|
|
|
|
|
2ⓑ|!2ⓑ, that is the question!
|
|
|
|
FYI, they won't accept it until there is significant real-world adoption of the symbol. Indeed. As I noted on another thread, it took a year and a half for the euro currency symbol € to be put into Unicode, and that was an "official" government currency. Piggyback on stuff that already exists. |
|
|
|
You simply cannot use an already existing currency symbol for a new currency. Period.
Currency symbol MUST be unique, you can't use existing ฿ unless you want to confuse someone during transaction
Hogwash to both of you. Go tell that to the Mexicans, who don't seem to have much trouble distinguishing their $ (peso) from $ (USD). Or to the Canadians or Australians or Kiwis who use $ for dollar. Or to the Danes, Norwegians, Swedes, Icelanders and Estonians, all of which use(d) "kr" for local variations of "crown". Or the Costa Ricans and Salvadorans, both of whom use ₡ for their currency symbol. IMHO, introducing a new symbol that's not already in Unicode is a poor idea. It took a year and a half for the € (euro currency) symbol to be included in the Unicode standard after the European Commission released the design, and that's the kind of lead time you might look forward to for an "official" government currency. There are a whole bunch of viable existing "b" codes already in Unicode. Some of them here: http://www.fileformat.info/info/unicode/char/search.htm?q=B&preview=entity I'm partial to the circle-b/B ones myself. |
|
|
|
I'd start off with strict sh compatibility, though, not bash, unless there's really a big advantage of requiring bash over lighter posix-compliant sh implementations (e.g. dash).
Not that I've got any skin in this game, but it would be worth considering targeting the more limited toolset offered by Busybox: http://busybox.net/The profusion of embedded linux devices these days means Busybox is everywhere. |
|
|
|
|
Hello Hiro,
Check around here for uc_bitcoin, which uses the library and is already a working payment method for Ubercart.
I'm a bit behind on keeping the library synced to the latest API version, but that shouldn't be a problem as yet, since the deprecated label functions are still in bitcoin.
Peace,
Mike
|
|
|
|
CVS??? That's quite hideous.
No doubt, right? CVS is against Gh0d's plan for H1s creatures. |
|
|
|
It is convenient to have the project integrated into drupal.org website though.
That's true. Go make it happen? |
|
|
|
Hm.. Drupal coding standards are not hideous at all. As I understand, this code is public domain and I can take it, reformat or do anything to be accepted in drupal.org and put it under GPLv2+? If so I might consider to fork it and post it under my account. But for you to become co-maintainer you still need to apply for a CVS account on drupal.org.
My code is public domain, so please go do what you want with it. In fact, it's not even mine any more, it's yours! Meanwhile, drupal.org wants me to do bogus shit like this: if (condition1 || condition2) {
action1;
}
elseif (condition3 && condition4) {
action2;
}
else {
defaultaction;
}
when this would suffice quite neatly: if (condition1 || condition2) action1;
elseif (condition3 && condition4) action2;
else defaultaction;
I minimize code for my own benefit, not for that of others who can't deal with where to stick a // when they need to get a little job done. Selfish, I know. So, frankly I don't care to swim in that pool. Call it a religious dispute if you will. The MUCH bigger issue is that I'm not going to put out first-release code of my own under the awful GPL, which is a requirement to register a project at drupal.org. I'm *never* going to try to compel people, under state penalty, to do anything with what I publish. |
|
|
|
Hey there. Doing that would involve putting the loathesome GPL on my code, reformatting it to meet Drupal's hideous coding standards, and doing a lot of work to support internationalization that I don't really have the motivation for. That said, if someone else puts that effort in, I might become a maintainer... |
|
|
|
|
I can see the motivation for davux's request. In developing the e-commerce plugins I've released, I've wondered about the viability long term of using a "dump" method against the wallet, since over time the data returned is just going to grow and grow.
What I'd prefer is being able to attach a JSON-RPC callback URL to an account or an address, maybe to be invoked each time a confirmation or any other status change to that account or address comes in, until the callback is cleared. That would eliminate the need for polling the wallet entirely.
I threw a "feature request" post in about that someplace.
|
|
|
|
|
The on/off switch makes sense. I'd also be very happy to see more debug detail available, preferably grouped by power-of-2 categories that can be ORed together. For example, when I'm working on ecommerce plugins, I don't really care to see anything but JSON-RPC debug output (and I wish there was more of that, too, including incoming connections, failures, ssl details, etc).
|
|
|
|
Well, what's stopping me is that I don't have the necessary expertise with C++ (which, unimportantly, I consider an atrocious language) to implement either handler type in Bitcion. I've also got no experience with Mac OS X programming, or with programming for the Linux desktop environment. That leaves me only able to do the NSIS scripting for installing the bitcoin handler on Windows. I haven't tested it, but this oughtta work: DetailPrint "Registering Bitcoin URI Handler"
DeleteRegKey HKCR "bitcoin"
WriteRegStr HKCR "bitcoin" "" "URL:bitcoin"
WriteRegStr HKCR "bitcoin" "URL Protocol" ""
WriteRegStr HKCR "bitcoin\DefaultIcon" "" "$INSTDIR\bitcoin.exe"
WriteRegStr HKCR "bitcoin\shell" "" ""
WriteRegStr HKCR "bitcoin\shell\Open" "" ""
WriteRegStr HKCR "bitcoin\shell\Open\command" "" "$INSTDIR\bitcoin.exe --protocolhandler=%1"
The "--protocolhandler=%1" bit would need consideration. |
|
|
|
lemur4bitcoin.com - lemurs for all!
syadasti@nobody:~/.bitcoin$ dig lemur4bitcoin.com ns
; <<>> DiG 9.7.0-P1 <<>> lemur4bitcoin.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16483
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;lemur4bitcoin.com. IN NS
;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1291404117 1800 900 604800 86400
;; Query time: 146 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 3 20:22:21 2010
;; MSG SIZE rcvd: 108
syadasti@nobody:~/.bitcoin$ ZOMG! |
|
|
|
...less than 200 lines of PHP, plus my bitcoin-php library. I'm looking for the best ideas, though.
The best idea I could give you is : switch to Rails my friend  Sure, because being able to curry my lambdas is really going to address the key problems you mentioned before. Still, if you let me have your lemur, I will consider your proposal  |
|
|
|
Gee Mike, do you have to use the "L" word? ;-)
Are you familiar with 1MDC? I'm familiar with 1MDC. Does L stand for something? I get what you're saying, but miss the reference unless it's simply to "ledger". The more I think about this, the less I want to be a service which holds balances on behalf of depositors. I want my clients' risk exposure to be ephemeral, the duration of generation of a block or three. I also want to maintain the absolute minimal state data on my clients during and after their transactions. I don't want to be the dick who gets his walled seized by Teh Man and leaves thousands of depositors cursing my name. Still, I like Davout's vision, lemurs and all. What I'm thinking about is a model in which depositors can stake a certain amount of value for a period of time they specify themselves, and after which it's returned to them automatically in full if there isn't a request submitted to make use of their deposit. Am I right in thinking that since my system would take a commission and thereby build up a balance that over time that balance itself would introduce useful entropy? |
|
|
|
It would be better to enter amount which will be received, not paid. Commision should be added to final amount to send. Currently, when I want to send 1 BTC to someone, I have to calculate commision itself.
Are you performing some scrambling in transaction? For example, when I send 1BTC, it should pay some amount instantly and some amount later even from another sending address. This way it should me much harder to pair both transactions.
By the way, I see you are living in Slovakia. Do you speak Slovak or Czech?
Okay, amount received not paid is a different use case. The use case I was thinking of was a payment back to oneself on a different one-time address. No scrambling at the moment. The code is dead simple, less than 200 lines of PHP, plus my bitcoin-php library. I'm looking for the best ideas, though. Most of my income the past 4 years comes from translating Slovak text into English. I still have a hell of a time carrying on a conversation, but I can read the newspaper pretty well. |
|
|
|
You obviously didn't get anything about my idea.
Dude, I'm still trying to catch up on your idea, the background, and why the issues you raise are important. And on this message I wasn't replying to ya  BTW, it looks like you have a lemur on your shoulder. Is that safe? |
|
|
|
|
Show Posts
