Bitcoin Forum
December 04, 2016, 06:21:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Version 0.3.12  (Read 2903 times)
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
September 07, 2010, 07:17:55 PM
 #1

Version 0.3.12 is now available.

Features:
- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
- json-rpc command line returns exit codes.
- json-rpc "backupwallet" command.
- Recovers and continues if an exception is caused by a message you received.  Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard.  See this thread:
http://bitcointalk.org/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/
1480875665
Hero Member
*
Offline Offline

Posts: 1480875665

View Profile Personal Message (Offline)

Ignore
1480875665
Reply with quote  #2

1480875665
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
September 08, 2010, 12:25:04 AM
 #2

What does the prohibition of "nonstandard" transactions do?

Code:
main.cpp:506
// Rather not work on nonstandard transactions
if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
  return error("AcceptToMemoryPool() : nonstandard transaction");
What is included in "GetSigOpCount", and what does "GetSerializeSize" measure?

This is "lightly" enforced by the network:
Code:
main.cpp:1425
// Check that it's not full of nonstandard transactions
if (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)
  return error("AcceptBlock() : too many nonstandard transactions");

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
September 08, 2010, 06:06:04 PM
 #3

Bitcoin clients currently only create and recognize transactions that match two possible templates. 

Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit.  Nodes will only work on adding those transactions to their block.

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 08, 2010, 06:48:13 PM
 #4

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.

Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
September 08, 2010, 06:56:31 PM
 #5

Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?
They just won't include them in blocks they generate. So the transactions might be slowed down a bit, but not stopped entirely.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
September 28, 2010, 02:23:38 PM
 #6

satoshi et al: I have been thinking long and hard about security of the wallet, as I implement other web services that will (I hope) move larger sums of bitcoins. The backup wallet is great, I'm now doing automated backups every time I create a new address, including on sending transactions.

But will this scale on a site that sends many transactions? I always have to backup the whole wallet, and that takes addresses, key, transactions, and grows considerably with usage. For more intensive usage I believe either less backup points or better separation of data is needed.

The two simple solutions I can think of for this are:
1) separate addresses/keys from everything else, so it is easy to do incremental backups or at least limit the backup size to that really needed to recreate the funds in a hardware failure event.
2) implement what has been talked as a future feature, the ahead of time creation of address bundles to be used, so one backup of the wallet is good for 1000 future transactions, or something like that
2.1) to use this efficiently, one should have the possibility to query how many addresses are still left in the unused pool and request creation of a new batch if needed so backups can be timely created and we drop to 0 the possibility of loosing data between address creation and backup

Of course doing both 1) and 2) would be perfect, but can we expect any of the above for a future release? Should we start hacking our own patches?
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!