This patch adds one form of an opt-requested feature, wallet encryption: http://yyz.us/bitcoin/patch.bitcoin-wallet-crypter or git://github.com/jgarzik/bitcoin.git#crypter BIG FAT WARNING: This patch is dangerous, and could create unspendable coins. Do not use, unless you really know what you are doing. Implementation details: With this change, encryption (and associated passphrase) is now required, otherwise the program will exit. The user may set their passphrase in the WALLET_PASSPHRASE environment variable, or in a GUI dialog if GUI is present. A new type of wallet record, "ekey", is used to store a public key + AES-encrypted private key. All new private keys are stored in "ekey" records. Old keys stored in "key" and "wkey" records will continue to be read and supported indefinitely, but bitcoin no longer writes these records. Caveats: - Totally untested rough draft. It compiles and makes logical sense, that's about it. I haven't even bothered to test it, though I welcome feedback from brave souls!
- The implementation is bare-bones. No provisions for wallet recovery, or detecting use of the wrong passphrase (easy way to corrupt!), etc.
Let the comments begin. Hopefully this will spark discussion about the proper solution for wallet encryption, now that code is out there. |
|
|
|
*** QUICK UPDATE ***- Fixed a bug in the payment system to process payments payments for blocks at 120 confirmations instead of 121.
- Changed the system that deactivates accounts to mark an account inactive after 28 days of inactivity, up from 7.
We're still working on fixing payments to reduce the number of transactions and hopefully have them process faster. We'll keep you posted. The RPC 'sendmany' was added to bitcoin specifically for pool operators and situations like this. |
|
|
|
|
As long as UPnP is off by default, it's just an easy way for the user to proactively drill a hole. The bitcoin network will benefit from UPnP users, and other P2P technologies such as bittorrent clients already use UPnP.
|
|
|
|
If we remove the CPU miner from bitcoin, then people starting alternative block chains will not have a self-sustaining system.
Wait, what? Alternative block chains? You didn't think The Chain would be the only one, did you?  Competition is practically inevitable in this space. |
|
|
|
|
Hum, this sounds like either impersonation or spamming?
|
|
|
|
Did you get a core dump? It might be useful. There must be a memory corruption or race in there. Maybe time t break out Valgrind.
Unfortunately c3f140033c531e9c5eae920c16fe2ecc80faa1a2 in bitcoin.git catches SIGSEGV, which means no more core dumps :/ |
|
|
|
|
Have you played around with -rpctimeout ?
|
|
|
|
|
FYI, the longpoll specification should say POST, not GET.
It is incorrect for GET to be receiving data in the body of the HTTP request (the JSON-RPC payload). This confuses HTTP libraries.
|
|
|
|
|
If Amazon made that announcement, there would be a sudden increase in demand, vastly outstripping by supply available from miners, in the short term.
|
|
|
|
Paying a fee was always likely necessary in the long run. You might like sending free transactions, but that also means spammers can spam unlimited numbers of transactions, unless there are some counter-incentives in place.
If that's the case than I'm afraid that bitcoin will fail. I can't be the only one that absolutely despises fees. There is no doubt that everybody likes a free lunch. |
|
|
|
As we can see, someone keeps flooding transaction queue with hundreds of small payments, possibly to force everyone into setting a mandatory transaction fee.
Already more than 1/4 of network is not accepting free transactions, which I don't like because at this time free transactions are a great bitcoin advantage when comparing to another online payment systems.
Use -limitfreerelay in current git. That will reduce spam, while still allowing free transactions. Non-spammy transactions with larger amounts and older coins will still have higher "free" priority over spam transactions, while continuing to avoid fees. |
|
|
|
I'm glad to hear that. Slush's decision to stop including free transactions was the main reason why I switched from his pool to yours. I hope the spam problem can be resolved. In my opinion, if paying a fee will become necessary, bitcoin will die. What is the most hated thing about traditional banking? IT'S THE FEES!
Paying a fee was always likely necessary in the long run. You might like sending free transactions, but that also means spammers can spam unlimited numbers of transactions, unless there are some counter-incentives in place. |
|
|
|
|
I think they are generally useful, as the topic of anyone-can-spend transactions comes up repeatedly.
I was thinking it would be useful to make a small service for redeeming scratch-offs, but no concrete plans have been laid.
|
|
|
|
The patch/git and example at top-of-thread have been updated with several changes. We are getting closer to a pull request. Security parameters are now dynamic, offering a range of security modes, depending on available real world UI constraints, or lack thereof: - Low security: 64 bit random password, no salt
- High security: 1024 bit random password, plus user supplied salt
...or any range of settings in between. You could generate a 64-bit random password, then supply a 100 gigabyte salt string. This is accomplished by the following changes: - Key generation algorithm changed to init pipe1, pipe2 with variable-length password and salt. See this updated post for details.
- 'sendscratchoff' RPC now takes a JSON 'options' object, allowing the TX creator to specify range of bits (64-1024) and optionally supply a salt string (default "bitcoin" if not provided).
- 'sendscratchoff' RPC returns full txid (see example in top post). JSON object return value "id" renamed to "txid".
- 'scratchoff' RPC takes optional salt string
- 'scratchoff' RPC now calls AddKey() to store key (fix for bug noticed by sipa)
The following to-do items remain before this can become a pull request: - 'scratchoff' must create a transaction to spend the coin, not just store key/TX in wallet
- 'scratchoff' ignores 'toaccount' param
- 'scratchoff' requires full 256-bit txid, even though btree database enables lowering number of bits required to find tx significantly
Nevertheless, it should be working (famous last words). You should be able to test with an empty wallet (thus guaranteeing you can spend the scratchoff coins), or on testnet. |
|
|
|
We should remove the option, but not the miner.
If we remove the CPU miner from bitcoin, then people starting alternative block chains will not have a self-sustaining system.
Just disable it from the GUI, so that new users won't find "Generate coins?"
People starting alternative block chains can download the official getwork miner. Yes -- that's what they're doing right now. So why add an extra step. |
|
|
|
Hello, I install CPU Miner ( https://github.com/j16sdiz/cpuminer ). But when I execute configure, I have a problem with the libcurl : ./configure: line 4830: syntax error near unexpected token `,'
./configure: line 4830: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,
Your libcurl installations is broken. It lacks autoconf macro(s). As another poster noted, you should build from tarball instead of git, to avoid having to regenerate configure. |
|
|
|
|
We should remove the option, but not the miner.
If we remove the CPU miner from bitcoin, then people starting alternative block chains will not have a self-sustaining system.
Just disable it from the GUI, so that new users won't find "Generate coins?"
|
|
|
|
I just can't see bitcoin taking off in a big way, when it is capped at 21 million. Imagine 21 million divided between the facebook population (lets leave country and nationality out of it) 500 million or half a billion users . That's not a lot of bitcoins to go round, it won't buy you a lot.
This is a FAQ (or "FMC", frequently misunderstood concept?). 1) Bitcoins can be divided into millionths of a bitcoin, leaving plenty for everyone on Earth. 2) "it won't buy you a lot" There is no economic reason why 0.000001 BTC cannot be worth $1,000 USD. It is entirely supply and demand. Where you place the decimal is completely irrelevant. |
|
|
|
|
Version 0.8.1 released. Some non-critical bugfixes, and one feature (User-Agent) that assists pool server operators in isolating problems to specific miner clients.
Changes:
- Make --user, --pass actually work
- Add User-Agent HTTP header to requests, so that server operators may
more easily identify the miner client.
- Fix minor bug in example JSON config file
SHA1: 0e60652fb0d29c6d20ed40bfce721bcd7a231b51 cpuminer-installer-0.8.1.zip
MD5: cc42cf0ff88958325dfedbd199f71a9e cpuminer-installer-0.8.1.zip
|
|
|
|
|
Show Posts
