|
The front page doesn't show anything?
|
|
|
|
- Suport --user/--pass options (and "user" and "pass" in config file), as an alternative to the current --userpass
--user/--pass is broken in version 0.8. Either obtain the latest -git for a fix, or continue to use --userpass until the next release. |
|
|
|
Goonie in this forum is working on an Android client based on BitCoinJ but I think it'll be at least the end of the summer before anything is working really well.
A native client, among other things, is essential for mainstream acceptance. I'm looking forward to seeing it in the market. Bitcoin, the original C++ implementation, was first built on Android months ago. That's as native as you can get. |
|
|
|
One of my major bitcoin criticisms remains non-deterministic transaction behavior, from the user PoV. Transactions that are non-standard, or too large for the included fees, will be resent hopelessly, without the user ever having any resolution whatsoever. I call these "zombie transactions." In the real world, transactions tend to be more binary: they either succeed or fail. They don't sit around in limbo forever. Therefore, I propose a new network rule: - Note the current block height, when a TX is received at a node, X.
- When block height increases to X+T, and the TX has not yet been put into a block, remove it from the TX cache. T could be 150 blocks, around 24 hours, but that's open to discussion.
In the short term, this should have little effect, as clients will continue to resend transactions ad infinitum, until they get into a block. And TX cache is flushed in any case, when a bitcoin node restarts. In the long term, this guarantees predictable behavior for each transaction. With this network rule in place, a user will know that their TX will probably either make it into a block, or disappear from TX caches [and thus be eligible for resubmittal]. This should open up the possibility for users to recover spent coins that never made it into a block (never confirmed). The current inability for a user to recover unconfirmed-and-never-will-be money is a flaw that should be corrected, though luckily these are rare cases today. However... Such unspending is difficult: a spend potentially creates a change transaction, which itself could then be spent, and so on. Of course, these zombie coins will never confirm, because their originating transaction is a zombie transaction. But it is difficult to unroll a chain of spends reliably. Comments welcome. |
|
|
|
I think byte swapping is simple enough that we can afford to create compat/byteswap.h, and include inline versions of byteswap macros for the case where the OS does not provide. This seems like an area of breakage that we could solve permanently. #ifdef __APPLE__ is fine, but we should provide fallbacks nonetheless. Volunteers?  |
|
|
|
Those with the ability to test can add AC_CHECK_HEADERS(byteswap.h) to configure.ac, and then check #ifdef HAVE_BYTESWAP_H ... current code ... #else ... OSX code ... #endif after running ./autogen.sh with proper autoconf/libcurl/etc. build dependencies, to regenerate configure. |
|
|
|
Making IsStandard() return true if fTestNet is a good idea.
The process for getting a new transaction type into bitcoin would be to test it thoroughly on the testnet, get general consensus on its API and/or GUI and that it is useful, safe, and unlikely to be abused, and work with the 'infrastucture' sites (like blockexplorer and bitcoinmonitor) to make sure the right APIs or hooks are in place so they can do something intelligent with the new transactions.
+1 agreed |
|
|
|
Version 0.8 released. See top of thread for URLs. Changes: - Support long polling (beta): http://deepbit.net/longpolling.php By default, cpuminer will enable long-polling automatically, if the X-Long-Polling HTTP header is present. To disable this autodetection, pass option --no-longpoll. - Adjust max workload based on --scantime (default 5 seconds, or 60 seconds for longpoll) - Standardize program output, and support syslog on Unix platforms - Suport --user/--pass options (and "user" and "pass" in config file), as an alternative to the current --userpass SHA1: 2b89588a99912d3980a9d5871b439fdbbd1d806b cpuminer-installer-0.8.zip MD5: 12464cf941dee3e317d98c643dfaee5a cpuminer-installer-0.8.zip |
|
|
|
Sometimes I'll get a "Floating point exception" which kills it on my Debian 6 VM. Anything build-wise I should be doing to avoid that?
I spotted one potential problem source, and pushed a fix out to git. |
|
|
|
Which algorithm are you using?
Which cpuminer version? Longpolling/git or a release version?
I'm using sse2_64 with the Longpolling/git version. Does it happen with any other algorithm, such as 4way? |
|
|
|
And, as I said, trying to maintain backwards compatibility is a fool's errand. You might be able to carry it on for a short period, but sooner or later you're going to have to put in some really complicated, hard-to-maintain and error prone code in the name of "backwards compatibility."
Perhaps, but I think we should continue on this fool's errand of backwards compatibility a while longer... |
|
|
|
Sometimes I'll get a "Floating point exception" which kills it on my Debian 6 VM. Anything build-wise I should be doing to avoid that?
Which algorithm are you using? Which cpuminer version? Longpolling/git or a release version? |
|
|
|
|
Because scripting is mostly disabled and difficult to get right in a secure way, I would rather just strip it out, for btc2.
You can do signed validation and multi-in, multi-out without a script engine.
|
|
|
|
|
Well, the usage so far has been backwards compatible AFAIK. You start out unversioned, and if a field is added, an nVersion check is also added. If no nVersion check exists, that data structure is unchanged.
The current system seems straightforward and is backwards compatible, so why add superfluous checks?
|
|
|
|
So IMHO that actually makes the scratchcards useless.
With the original algorithm, yes. Not with the current, totally different algorithm. |
|
|
|
Guys, I really respect your hard work providing another pool. But please cut all this 'efficiency' pseudo-science. There is no correlation between searching whole 'nonce space' and the results you find. Yes, it affects server load, but there are other methods to solve this.
+1 agreed |
|
|
|
According to the Department of Justice press release, the Liberty Dollar far too similar to the US dollar, to the point that the US mint had to issue warning that LDs were not official currency. Bitcoins have zero similarities with US dollars. Let's add this to the FAQ: the Liberty Dollar case is not relevant to bitcoin. |
|
|
|
The modification to repeatedly hash the 64 bit password is a good idea, and should prevent square root attacks. I would probably have used a simpler iterative formula, but that one seems safe enough. SHA512 is notorious for speed variations on different architectures, but compared to the time to type in the password, that should be ok. Where does the magic number 108333 come from?
Largely arbitrary. 8333 is bitcoin's TCP port, and 100,000 was the number of iterations required for a single thread on my 3Ghz CPU to take a noticeable pause during computation. RFC 2898 suggested at least 1,000, and I thought 1,000 was far too low. Thinking about some more modifications, though: - Allow user to specify number of bits in password. Range 64 - 256, must be divisible by 8. Or perhaps as low as 57 bits (limit of 16 decimal digits), with some brute force to bring it up to 64.
- Allow user to specify optional plaintext string (salt). Default is "bitcoin" if not supplied. If no salt is supplied, due to limitations of what can be presented to the consumer, then the current minimal implementation stands as is, with 64 bits of brute force security. However, if the scratchoff creator is able to communicate an additional string, be it an order id, or even "bitcoin.example.com", we can hash that at the beginning of key derivation, thereby getting much better security than 64 bits alone.
|
|
|
|
|
Show Posts
