Bitcoin Forum
April 25, 2014, 03:50:27 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Poll
Question: Which version are you testing?
0.5.6rc2 - 2 (100%)
0.4.7rc2 - 0 (0%)
Total Voters: 2

Pages: [1]
  Print  
Author Topic: Please help test: Bitcoin 0.5.6rc2 and 0.4.7rc2 (FIXES STUCK BLOCK BUG)  (Read 1411 times)
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
June 15, 2012, 01:23:55 AM
 #1

bitcoind and Bitcoin-Qt version 0.5.6 release candidate 2 (sigs) are now available for download at:bitcoind version 0.4.7 release candidate 2 (sigs) is now available for download at:bitcoind and Bitcoin-Qt version 0.6.0.8rc2 is also tagged in git.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

  • Fix BIP16 validation to not enforce non-standard size limit of 200 bytes. Fixes being stuck at block 177617 (0.4 and 0.5)
  • Do not select first address automatically in the address book when sending (Bitcoin-Qt)
  • Hopefully final fix for the stuck blockchain issue
  • Fix various database crashes and improve error checking
  • Properly escape double-quote character in strings when exporting CSV
  • Fix #952 by checking if we have a new address or an updated label
  • Don't call exit() in Shutdown() for Bitcoin-Qt (fixes a tray-icon issue)
  • Filter out whitespace and zero-width non-breaking spaces in Bitcoin address validator
  • Properly store source addresses in database
  • Remove redundant tooltip on optional transaction fee. Fixes #1218 (Bitcoin-Qt)
  • Change initial balance on Overview page from "123.456 BTC" to "0 BTC" to not confuse users, whom might see it before we initialize with the real wallet balance (Bitcoin-Qt)
  • Fix various places where Bitcoin-Qt was being shutdown improperly
  • Hide UI immediately after leaving the main loop (Bitcoin-Qt)
  • Various documentation corrections and debugging fixes



Thanks to everybody who contributed code or helped test this release:

Pieter Wuille
Philip Kaufmann
Luke Dashjr
Wladimir J. van der Laan
Matt Corallo
Jeff Garzik
R E Broadley
Fordy
Gavin Andresen
Michael Hendricks
Chris Moore
Christian von Roques
Peter Todd

1398397827
Hero Member
*
Offline Offline

Posts: 1398397827

View Profile Personal Message (Offline)

Ignore
1398397827
Reply with quote  #2

1398397827
Report to moderator
Private Internet Access™ - No logs, Unlimited Bandwidth, PC Magazine's Editor's Choice
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398397827
Hero Member
*
Offline Offline

Posts: 1398397827

View Profile Personal Message (Offline)

Ignore
1398397827
Reply with quote  #2

1398397827
Report to moderator
1398397827
Hero Member
*
Offline Offline

Posts: 1398397827

View Profile Personal Message (Offline)

Ignore
1398397827
Reply with quote  #2

1398397827
Report to moderator
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
June 15, 2012, 03:17:31 AM
 #2

Regarding the stuck block bug...

Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these versions also enforced the 200-byte "is standard" rule, they were effectively treating it as a network rule. This was not a problem in 0.6 because the original OP_EVAL commit (e679ec9) moved the check outside of IsPushOnly.

This problem could have been avoided if either IsPushOnly was renamed when its semantics/behaviour changed significantly, or I inspected the OP_EVAL commit in detail instead of skipping it over as a new feature and not bugfixes. Additionally, it might have helped, if the commit message mentioned the change, but I'd probably have still missed it as it wasn't relevant until months later.

To get unstuck, follow these instructions:
1. Ensure you have the minimum required 1280 MB memory available
2. Create a new file in your bitcoin directory (the same one with wallet.dat) called DB_CONFIG with the following two lines:
Code:
set_lk_max_locks   1000000
set_lk_max_objects 1000000
3. Start bitcoind or Bitcoin-Qt
4. WAIT AT LEAST SIX HOURS; Your client will NOT show any signs of making progress during this time
5. When complete, your client should be up-to-date on block count
6. At this time, you may wish to delete the DB_CONFIG file and restart your client, to use less memory

Phraust
Full Member
***
Offline Offline

Activity: 204


Mostly Harmless...


View Profile WWW

Ignore
June 15, 2012, 03:22:10 AM
 #3

Tried the bitcoind binary out in OSX Lion (10.7.4), seems to work fine.
ErebusBat
Hero Member
*****
Offline Offline

Activity: 546

I am the one who knocks


View Profile

Ignore
June 15, 2012, 03:20:16 PM
 #4

Tried the bitcoind binary out in OSX Lion (10.7.4), seems to work fine.

^^^ Verified

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
Gavin Andresen
Hero Member
*****
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
June 15, 2012, 03:36:27 PM
 #5

This is why I think the so-called "stable" backports are a bad idea. I want people to spend time finding and fixing bugs in 0.6.2, and I want people to realize that the core developers are not supporting older releases.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
June 15, 2012, 03:42:10 PM
 #6

This is why I think the so-called "stable" backports are a bad idea. I want people to spend time finding and fixing bugs in 0.6.2,
People running production services don't need the risk of new bugs, and will run old versions even if they're buggy. Stable branches let these people keep patched against bugs without the huge risk of new ones that comes with bleeding edge. I've been holding back on pointing out that the real cause of this was the huge complexity of BIP16, and that it would have probably not been a problem if we had adopted the simpler BIP17 instead. Nobody writes perfect code, so the risk of bugs in new versions is impossible to avoid.
and I want people to realize that the core developers are not supporting older releases.
I am, at least.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!