|
If we want to be taken remotely seriously by the banking and merchant communities, floats need to go. Whether the end result is "1000000000" or "10.00000000" is largely cosmetic. But I do agree that -- long term -- JSON's "number" and internal floats fall short of what is needed for proper money handling software.
But.... it just hurts to change the API right now, because we will see very little payback for a large amount of pain.
|
|
|
|
I'm not a C/C++ programmer, but wouldn't... ...be even more readable? It would be if it were correct but it's not, the program flow would change regardless of whether or not rc were initialized. LMGTFY's code is correct, and you are mistaken (about not only this, but macro abuse etc. also) |
|
|
|
I wanted long pool cpu miner before summer comes  cpuminer already supports long polling. |
|
|
|
I've seen problems when porting C test functions to ARM a few years ago, you definitely can't trust a floats to behave the same on all platforms.
Actually, as long as you make sure all your IEEE compliance options are turned on... |
|
|
|
|
cpuminer's sse2_64 should be the fastest, but it only works on 64-bit Linux (sse2_64 is a port of ufasoft's code).
ufasoft's miner works on Windows.
puddinpop's stuff can do CPU mining, but is slower than cpuminer or ufasoft.
|
|
|
|
|
Yep, I've been thinking about this idea for a while. In general we need more merchant-friendly APIs (and more merchant-friendly depositories, like MyBitcoin).
PayPal even has a "sandbox" where developers can test their software against PayPal's API, without spending / losing real money. Bitcoin has testnet, and a PP-compatible API would be a perfect complement.
|
|
|
|
Ufasoft's SSE2 CPU Miner gets me about 2.5MHash/s per core on a 2.2ghz Core2 Duo. ~5MHash/sec total.
Same with cpuminer's "sse2_64" algorithm. |
|
|
|
Also a security flaw, you are using a constant IV everywhere, it looks like. You need to use a different IV for each encryption.
I'm not an AES expert, so permit a dumb question: does AES decryption require knowledge of the IV used to encrypt a given ciphertext? With the only information persisting between sessions being the user's passphrase, that would seem to imply storing the IV for each encryption? |
|
|
|
|
I don't know about hung, but Pecunix withdrawal is not automated, because Pecunix does not offer an automated payment API to the public.
That means Bitcoin Central's PGAU deposits are automated, but withdrawals probably have to wait for davout to return to his email.
|
|
|
|
Shocking: he discovered the "> 50% power" attack. |
|
|
|
|
A setup that user might reasonably be expected to understand could be: one password to unlock the wallet (whole-file), and a second to spend money (ECDSA private keys).
However... It remains a PITA with the current bitcoin implementation to perform whole-file encryption on the wallet. db4 has whole-environment encryption, so that implies an encrypt-everything solution would encrypt the wallet, addr and blkindex databases.
One could encrypt the 'value' part of each db4 key/value pair, by modifying bitcoin's database Read() and Write() methods. But with the keys being plaintext, I'm not sure that's useful.
With the current implementation, you are locked into a lot of design decisions, where if you deviate you must rewrite a lot of code all over the codebase.
For that reason, I had hoped a patch would focus discussion on what is reasonable with the current codebase, rather than a perfect solution that will never see the light of day.
|
|
|
|
I just went through the installation of minerd on Ubuntu 10.10. I have one request for the maintainers.
Could you put in the README or INSTALL a list of the packages that will be required for the "configure" to complete. I was able to get most of the required packages right away, but the libcurl one threw me for a while. I had installed libcurl, but the configure script was not happy. I finally had to install the libcurl-dev package. This wasn't apparent from the error message that the configure script gave. The error just says that libcurl needs to be of a certain version, not that you needed to install the dev package.
The dependencies are listed in README. The need for a "-dev" package is just required general knowledge: to build any source code, not just minerd, you must install each -dev package required by that source code. |
|
|
|
b) list them as 'immature' -- a new transaction category.
I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).
The only drawback I can think of is that adding a new transaction category might confuse existing code.
xlisttransactions shows immature blocks as "mixed_debit": {
"address" : "1111111111111111111114oLvT2",
"label" : "",
"txid" : "81862a4db4edb6b919355f5f70c32e5cecaae0c7f6f67f86ea586a9392ae33bd",
"txtime" : 1301242706,
"category" : "mixed_debit",
"amount" : 0.00000000,
"confirmations" : 10
},
And so several miners already use a different transaction category in the field (those that patch it in, which apparently several big miners do). |
|
|
|
That's a bit self-referential -- they were removed with a comment referencing your complaint. MyBitcoin is pretty prominent and continues to work for a lot of people, so I do not think they should yet be removed from the Trade page. |
|
|
|
Where is Bitcoin actively traded for gold? Must be very thin trading.
Bitcoin Central and Bitcoin Market (v2). |
|
|
|
I've noticed that from time to time the gold conversion value is incorrect. This is one of those times. It should be on the order of 4000 ounces of gold currently.
Where do you get that 4000 oau figure from? Is there any bitcoin/gold market I don't know about?
This might be a bitcoinwatch FAQ. Many people often assume that the gold/BTC value is simply calculated from the BTC/USD price, after getting a spot gold quote from some third party financial website. But bitcoinwatch tries to calculate directly from the most recent BTC/GAU trading prices, which can sometimes appear "outdated" versus current GAU/USD price due to slow BTC/GAU trading. |
|
|
|
A typical service converts bitcoins to something else, or something else to bitcoins. A service that converts bitcoins to bitcoins? That sounds like a laundering service. Is that what's being offered?
No, this service converts bitcoins for almost certainly less bitcoins. But as added bonus, it is doing it significantly cheaper than competition. I "offered" such a service (as a proof that it is not worth it) in this thread: http://bitcointalk.org/index.php?topic=4922.msg72471#msg72471To be fair, such a service is not completely useless. It can be used for hedging difficulty changes (a bet what the future difficulty is going to be) but priced above 440 BTC a month, you are almost guaranteed to lose money because at current difficulty it pays 439 BTC a month and the average difficulty going down is very unlikely and going down by more than 10% is almost impossible. If there were a liquid market for such contracts, the price of such a contract would be about 410-420 BTC for the next month and likely about 350 BTC/month if bought upfront for the next 3 months. Well, my weekend project for last month or two has been building a useful bitcoin P2P backbone, on top of which I hope to provide services such as smart payment processing, transaction services, private wallets (private bitcoind nodes), private pool servers and other gadgets. Buying mining capacity makes sense for this microbiz, even if the generation comes at a slight loss. This is of course assuming that it is even possible to negotiate with the provider to obtain RPC mining to my own servers, rather than simply a zero-variance payout (some providers are zero-variance only, which is not useful to me). Anybody with reliable > 1 Gh/s to sell, with stable power and not in mom's basement or next to the cat's litter box, feel free to post on Marketplace forum... If Raulo is right, surely there will be offers under 500 BTC/month... |
|
|
|
Using the latest plain vanilla bitcoind (0.3.20.2) I'm testing the getwork interface for remote miners, but I miss one feature from the listtransactions call, and that's the generated blocks before they are confirmed. Can I do that at all with the plain bitcoind, is there a reason for that not being in there?
The xlisttransactions patch will show that to you. It was built with the intention of showing precisely what the GUI shows, in the GUI transaction list. |
|
|
|
Not sure if that code is useful now, but dumping it anyway...
There's been a lot of feature-requesting and demoing and such. By posting real code against current bitcoin, it was hoped that we could move on to a more focused discussion (w/ real code) about what wallet encryption should look like. We need to answer questions such as Is the presented method cryptographically strong? Should we encrypt the entire wallet, and not just private keys? Should we encrypt the plaintext data concatenated together as a single huge memory buffer, enhancing cipher block chaining, or encrypt invididual records as my patch does? How to handle wallet upgrade + downgrade? "ekey" creates unspendable coins, when moving to older clients. How to check for invalid passphrase? It seems cryptographically unwise to use the naive implementation (encrypt a static, well known string; check for invalid passphrase by attempting to decrypt to well known plaintext). |
|
|
|
|
Show Posts
