are the backups in 0.6.0 for windows encrypted?
No |
|
|
|
The most important re-implementation of Satoshi's oroginal code, from my point of view, is Libcoin from Michael Grønager. Libcoin is not a reimplementation, it is just the Satoshi client made into a library. Perhaps you meant Amir's libbitcoin? |
|
|
|
i'm new to bitcoin so still learning. how are things like the progress bar usually addressed? is it community driven or does gavin get to decide whatever he wants? In practice, Gavin does what he wants, usually with all other developers in agreement or at least neutral. The recent P2SH argument was the rare exception, and neither side really had more developer support than the other. |
|
|
|
|
There's a bug in the new testnet mining code, so I'm running 0.5.4 now with that and a few other fixes. (Sorry guys, the progress bar is not reverted in 0.5.4.)
Edit: Nevermind, Gavin wants to hold off on 0.5.4 until BIP16 is ready, so it'll probably be another week or so. Also, both Wladimir and Gavin disagree with reverting the progress bar fix, sorry.
|
|
|
|
why? isn't bitcoin something that could really benefit from the jump to 64-bit? In short, no. The only benefit to 64-bit userspace is large virtual machines (over 2-4 GB RAM) and applications where a small boost in performance matters more than memory usage (64-bit uses ~twice as much memory). Also, no Bitcoin developers actually use Windows, and I don't think Ubuntu supports targeting Win64. |
|
|
|
why does the Sourceforge link say 0.5.2 for win 32? Fixed. the choices below don't indicate a 0.5.3 win 64 bit version as far as i can see.
Win64 is not, never has been, and is not planned to ever be, supported... Win32 builds should run fine, since Win64 isn't really pure 64-bit (it's hybrid; both 32-bit and 64-bit) |
|
|
|
is there an ebuild and / or a USE flag for bip30 in the gentoo ebuild ? There are 0.4.4 and 0.5.3 ebuilds. It's not optional, so no USE flag. |
|
|
|
Bitcoin version 0.5.3 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/This is a bugfix-only release based on 0.5.1. It also includes a few protocol updates. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesStable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gzPROTOCOL UPDATES- BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
- On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.
BUG FIXES- Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
- Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
- Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922). - Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
- Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
- Skip splash screen when -min is used, and fix Minimize to Tray function.
- Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
- Correct various labels and messages.
- Various memory leaks and potential null pointer deferences have been fixed.
- Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
- Several shutdown issues have been fixed.
- Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
- Check that keys stored in the wallet are valid at startup, and if not, report corruption.
- Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
- Various build fixes.
- If no password is specified to bitcoind, recommend a secure password.
- Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
- Show a message box for --help on Windows, for Bitcoin-Qt.
- Add missing "About Qt" menu option to show built-in Qt About dialog.
- Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
- Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
- Add checkpoint at block 168,000.
Thanks to everybody who contributed code or helped test this release: Pieter Wuille Luke Dashjr Wladimir J. van der Laan Gavin Andresen Matt Corallo Lars Rasmusson Janne Pulkkinen Gregory Maxwell Daniel Folkinshteyn Chris Moore |
|
|
|
If I had that many cards I would join a pool that sends a text message when a miner is down.
This is probably the best suggestion yet. |
|
|
|
Also I don't see the advantage in making all payments to a scriptHash, the need to save the script adds extra complexity.
^This. Although I see the value in P2SH or any similar system, I am deeply concerned about the backup issues. I put in a lot of work to make paper backups in Armory, to make it as simple as possible for users to make one backup ever, and not have to worry about it again. "Regular users" who must rely on a consistent backup solution will fail. It doesn't happen. No matter what you do, they will forget to set it up, not realize their backup drive was disconnected, not set it up again after a system restore, or reinstall OS, etc. But with proposals that require all everything to be hidden behind script hashes: your wallet must be backed up (or at least the script information) after every single transaction. Your system dies right after a transaction before you've had a chance to save the script, and you'll never recover it again. This is something I'm battling with multi-sig scripts, but was comforted by the fact that at least regular users who want to avoid all of it don't have to deal with it and can use regular addresses which can be scanned for in the blockchain. That's what this thread was about. Gavin addressed the issue for multi-sig and escrow. I don't see why this is any harder to do with P2SH... |
|
|
|
By officially deprecating it, that could mean that we will remove the ability to make new legacy transactions in a future hard fork. This wouldn't even require a hard fork, really. Eventually, another hard fork could remove it altogether, destroying any still-unspent legacy outputs. Legacy outputs could be safely converted to P2SH in such a hardfork. |
|
|
|
Unfortunately, with the advent of Deepbit adding BIP 16 support, the possibility of BIP 17 being implemented is pretty much gone. I therefore regret to announce the official Withdrawl of BIP 17. If anyone else wants to take over as its "champion", feel free to re-open it, but I am convinced it is a lost cause at this point. Short of something major happening within the next day or two, I will be switching Eligius (my pool) over to BIP 16, and merge backported BIP 16 support into the future 0.4.5 and 0.5.4 stable releases. However, BIP 16 isn't completely irreparable: I am proposing BIP 18 as the next step forward. This proposal is 100% protocol-compatible with BIP 16 and requires no software changes at all. It is simply a formal rewriting of the specification in a more consistent manner, and implies developers will make a full commitment to P2SH, using it for all new address/transaction types (without breaking compatibility with "legacy" addresses). Finally, Gavin's BIP 16 backport does not merge cleanly into 0.4.x/0.5.x, and seems to have fallen behind on a few fixes made in the "master" branch. I have attempted to resolve this, but would appreciate as many reviews of it as possible before merging to stable. Unlike BIP 17, the code to implement BIP 16 is very complicated and hard to follow, so there is plenty of room for error.  Edit: Gavin noted the backport doesn't need to actually mine P2SH into blocks, so here is a simpler patch that only validates them. Please audit this one instead. |
|
|
|
p2p vs "normal" pool There is no significant difference here. The difference lies in who creates the blocks: miner or pool. If the pool makes the blocks, the miner is blind and powerless over what goes into them. If the miner makes the blocks, it restores the integrity we had with solo mining. To date, there are 3 pools which support it: BitPenny was the first to move this to the "miner makes blocks" design, with a proprietary Bitcoin-based protocol; p2pool was the second, with yet another different proprietary protocol; for Eligius, I chose to adopt the new "getmemorypool" JSON-RPC method and make it a standard capable of general mining use. |
|
|
|
We need to get 0.5.3 final out by Wednesday, so it'd be especially helpful if people can test and report on this RC, even if it's as simple as "I run Windows 7 64-bit, and the installer version worked fine for me." Note that 0.5.3 is not compatible with 0.6rc wallets, so these will probably only work if you have never run 0.6rc before. Still need test results for: Windows installerWindows ZIP- Linux binary
- Mac binary
|
|
|
|
Bitcoin version 0.5.3 release candidate 4 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3rc4/This is a bugfix-only release based on 0.5.1. It also includes a few protocol updates. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesStable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3rc4#.tar.gzPROTOCOL UPDATES- BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
- On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.
BUG FIXES- Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
- Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
- Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
- Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
- Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
- Skip splash screen when -min is used, and fix Minimize to Tray function.
- Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
- Correct various labels and messages.
- Various memory leaks and potential null pointer deferences have been fixed.
- Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
- Several shutdown issues have been fixed.
- Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
- Check that keys stored in the wallet are valid at startup, and if not, report corruption.
- Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
- Various build fixes.
- If no password is specified to bitcoind, recommend a secure password.
- Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
- Show a message box for --help on Windows, for Bitcoin-Qt.
- Add missing "About Qt" menu option to show built-in Qt About dialog.
- Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
- Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
- Add checkpoint at block 168,000.
Thanks to everybody who contributed code or helped test this release: Pieter Wuille Luke Dashjr Wladimir J. van der Laan Gavin Andresen Matt Corallo Lars Rasmusson Janne Pulkkinen Gregory Maxwell Daniel Folkinshteyn Chris Moore |
|
|
|
Do we have an ETA on the patch getting merged and included in rc3 or whatever?
This is already part of 0.4.4rc3 and 0.5.3rc3. |
|
|
|
My best guess, at this point, is that your wallet has a corrupt private key which was not properly detected in older versions. Could you check debug.log?
I copied 0.4.4 back, and now I'm getting a slightly different error. Does 0.4.2 still work? This looks like blkindex.dat got corrupted somehow. Nope, 0.4.2 doesn't work either now. Although i got it to work by deleting everything except for wallet.dat. 0.4.4 still doesn't work though. Can we get debug.log with the original issue (ie, when 0.4.2 works)? |
|
|
|
Nonsense
P2pool has the variance of a 300GH/s pool, that means like 1 block every 6 hours
Eligius is 350GH/s, so it's pretty much the same thing p2pool is PPLNS (high variance). Eligius is SMPPS (low variance). Once again nonsense. SMPPS has low (essentially no) variance in rate funds are EARNED (similar to PPS) but unlike PPS it has high variance in the rate that funds are PAID. Most miners care about the variance in their payments and there is no difference between the two. Lastly even if PPLNS had higher variance your claim that it is similar to solo mining is just pure biased FUD. I mean it is shit Luke. A miner with 1 GH/s of hashing power has the same variance solo mining or using p2pool? Really that is the fucked up claim you are putting your name on? Sorry you don't understand, but it really doesn't justify the profanity. |
|
|
|
Nonsense
P2pool has the variance of a 300GH/s pool, that means like 1 block every 6 hours
Eligius is 350GH/s, so it's pretty much the same thing p2pool is PPLNS (high variance). Eligius is SMPPS (low variance). |
|
|
|
In the short term there is variance same as any other pool. p2pool variance is almost like solo mining. Eligius has almost no variance. |
|
|
|
|
Show Posts
