Bitcoin Forum
May 23, 2024, 02:40:37 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 »
461  Bitcoin / Development & Technical Discussion / Re: [CORRECTED] Script calculates 71% freeable transactions on: May 24, 2011, 01:25:48 PM
I get similar numbers using BBE data. 391288 transactions and 124638004 bytes over 126191 blocks.

Thanks for checking.
462  Bitcoin / Bitcoin Discussion / Re: Gavin will visit the CIA on: May 23, 2011, 04:34:37 PM
Vouts to Gavin for playing spokesperson.  I find his politics too American-mainstream, but this very quality probably lets him keep a straight face while speaking to the establishment in its language.  I only hope he manages a smooth succession when he gets tired of his technical leadership role.
463  Bitcoin / Development & Technical Discussion / Re: Script calculates freeable transactions on: May 23, 2011, 02:32:09 PM
This seems wrong to me, but I haven't given it serious thought.

OOH!  Bug fix.  "tx[txin['prevout_n']]" should be "tx[txin['prevout_hash']]".  This improves the stats quite a bit:

loaded  125925  blocks
387616 of 544296 tx freeable   (71.2%)
123285900 of 168627001 tx bytes freeable  (73.1%)

(387616*32+123285900)/180119823 = 75.3%, still too high I suspect.

Updating wiki...
464  Bitcoin / Development & Technical Discussion / Re: Script calculates freeable transactions on: May 23, 2011, 02:15:36 PM
Great work! Simulating the merkle tree collapse is probably much harder, but even so the fact that 36% can be deleted today is great. I'd expect that number to only go up as the economy picks up pace.

Could you update the wiki page with your findings?

Updated: "As of May, 2011, the software does not implement pruning, and the savings are calculated {link here} at 37% of transactions or 35% of raw block bytes."

I will not have time to calculate the Merkle tree prunings.  I guess a lower bound is the transaction count times 32, and an upper bound is double that.  Adding the former number to the freeable tx bytes and dividing by the raw file size gives me 38.7%, which is slightly higher than the rate in both transaction count and transaction bytes.  This seems wrong to me, but I haven't given it serious thought.
465  Bitcoin / Development & Technical Discussion / [CORRECTED] Script calculates 71% freeable transactions on: May 23, 2011, 07:05:33 AM
"nobody has done studies of the existing block chain to see how much space could be reclaimed."  --https://en.bitcoin.it/wiki/Scalability

So I gave it a go.  I hope someone will check my logic, especially as I am new to Python.

$ time src/bitcointools/freeable.py
loaded  125925  blocks
201085 of 544296 tx freeable (corrected: 387616 of 544296 tx)
63328760 of 168627001 tx bytes freeable (corrected: 123285900 of 168627001 tx bytes)

real   0m47.131s
user   0m43.799s
sys   0m2.744s
$ ls -l .bitcoin/blk0*.dat
-rw------- 1 jtobey jtobey 180119823 2011-05-23 00:42 .bitcoin/blk0001.dat

(edited: fixed bug http://forum.bitcoin.org/index.php?topic=9461.msg137059#msg137059) diff of bitcointools:
Code:
diff --git a/deserialize.py b/deserialize.py
index fe0cb09..a67645b 100644
--- a/deserialize.py
+++ b/deserialize.py
@@ -75,6 +75,7 @@ def deserialize_TxOut(d, owner_keys=None):
 
 def parse_Transaction(vds):
   d = {}
+  start = vds.read_cursor  # XXX breaks BCDataStream abstraction, do we care?
   d['version'] = vds.read_int32()
   n_vin = vds.read_compact_size()
   d['txIn'] = []
@@ -85,6 +86,7 @@ def parse_Transaction(vds):
   for i in xrange(n_vout):
     d['txOut'].append(parse_TxOut(vds))
   d['lockTime'] = vds.read_uint32()
+  d['tx'] = vds.input[start:vds.read_cursor]
   return d
 def deserialize_Transaction(d, transaction_index=None, owner_keys=None):
   result = "%d tx in, %d out\n"%(len(d['txIn']), len(d['txOut']))
diff --git a/freeable.py b/freeable.py
new file mode 100755
index 0000000..c79f458
--- /dev/null
+++ b/freeable.py
@@ -0,0 +1,87 @@
+#!/usr/bin/env python
+#
+# Read the block database, find out how many transactions
+# could be purged and how many bytes they take up.
+# TODO: find out how many Merkle hashes could be purged.
+#
+from bsddb.db import *
+import logging
+import os
+import sys
+
+from BCDataStream import *
+from block import scan_blocks
+from deserialize import parse_Block
+from util import determine_db_dir, create_env
+import Crypto.Hash.SHA256 as SHA256
+
+import binascii  # debugging
+
+def main():
+  import optparse
+  parser = optparse.OptionParser(usage="%prog [options]")
+  parser.add_option("--datadir", dest="datadir", default=None,
+                    help="Look for files here (defaults to bitcoin default)")
+  (options, args) = parser.parse_args()
+
+  if options.datadir is None:
+    db_dir = determine_db_dir()
+  else:
+    db_dir = options.datadir
+
+  try:
+    db_env = create_env(db_dir)
+  except DBNoSuchFileError:
+    logging.error("Couldn't open " + db_dir)
+    sys.exit(1)
+
+  blockfile = open(os.path.join(db_dir, "blk%04d.dat"%(1,)), "rb")
+  block_datastream = BCDataStream()
+  block_datastream.map_file(blockfile, 0)
+
+  blocks = []
+  def gather_stats(block_data):
+    block_datastream.seek_file(block_data['nBlockPos'])
+    blocks.append(parse_Block(block_datastream))
+    return True
+
+  scan_blocks(db_dir, db_env, gather_stats)
+  blocks.reverse()
+  print 'loaded ', len(blocks), ' blocks'
+
+  tx = {}
+  total_tx = 0
+  freeable_tx = 0
+  total_bytes = 0
+  freeable_bytes = 0
+
+  for data in blocks:
+    coinbase = True
+    for txn in data['transactions']:
+      tx_hash = SHA256.new(SHA256.new(txn['tx']).digest()).digest()
+      #print '> ', binascii.hexlify(tx_hash)
+      tx_bytes = len(txn['tx'])
+      tx[tx_hash] = (tx_bytes, len(txn['txOut']))
+      total_tx += 1
+      total_bytes += tx_bytes
+
+      if coinbase:
+        coinbase = False
+      else:
+        for txin in txn['txIn']:
+          #print '< ', binascii.hexlify(txin['prevout_hash'])
+          (bytes, live) = tx[txin['prevout_hash']]
+          if live == 1:
+            freeable_bytes += bytes
+            freeable_tx += 1
+            del tx[txin['prevout_hash']]
+          else:
+            tx[txin['prevout_hash']] = (bytes, live - 1)
+
+  db_env.close()
+
+  print freeable_tx, 'of', total_tx, 'tx freeable'
+  print freeable_bytes, 'of', total_bytes, 'tx bytes freeable'
+
+if __name__ == '__main__':
+    main()
466  Bitcoin / Development & Technical Discussion / Re: [PULL] 52-line patch supporting offline key generation on: May 23, 2011, 04:12:33 AM
Note: To be convenient, one (I) would write a little script to read one of these PEM files and print a Bitcoin address.  All key handling would be possible offline, and certainly in the absence of a block chain, until spend time.

Update: The script both creates the PEM file (using the openssl command) and prints the Bitcoin address: https://github.com/jtobey/bitcoin/raw/importkey/contrib/genkey.py
467  Bitcoin / Development & Technical Discussion / Re: Post-inflation security on: May 22, 2011, 04:05:47 PM
Right, it's not implemented in the software. It's tricky because the codebase assumes you aren't trying to double spend.

Regardless, I don't think it's necessary. "Guessing" the right fee level like this is going to be very slow. There are better ways.

Better ways for end users, sure, like your idea (if I remember) of servicers who, for a fee, would guarantee an acceptance time and assume the associated risk.  I see nothing wrong with that.

I worry, though, about worse ways being proposed, such as changing the block payout policy, which amounts to messing with monetary policy.

Double-spending as a strategy to speed payment already exists, in a sense.  It is implicit in the protocol.  I wouldn't be surprised if someone has already tried it (using wallet backups or custom software).  I would be surprised if it never becomes an at least occasional standard practice.
468  Bitcoin / Development & Technical Discussion / Re: [PULL] 52-line patch supporting offline key generation on: May 22, 2011, 12:27:10 PM
I have written a patch that allows extraction and insertion of bitcoin private keys in a custom base58-based format, only containing the secret parameters itself, without the field and curve parameters.
Is it on the pull list or otherwise available?
Yes, here: https://github.com/bitcoin/bitcoin/pull/220

Oh, that's you?  Thanks for the contributions!

I read your summary (hadn't got to the code yet) and the comments about "rpc.cpp too big" and "import to an account" and saw value in a patch that addresses those two issues and a more narrow use case.

Quote
Just checking upon import is fine. I suppose the easiest way would be extracting the private parameters, reconstructing the full private key from that, and check whether that results in a structure identical to the one imported. The pull request above contains code in CKey for doing those.

Good idea.  Interestingly, the keys I tested with do not have the same structure as client-generated keys.  The new kind have a shorter private key length.  You might think they have fewer bits of entropy, but the client-generated keys (in DER/wallet form) have long strings of all 1's and other common subsequences.  I have not figured out why.
469  Bitcoin / Development & Technical Discussion / Re: Post-inflation security on: May 22, 2011, 12:11:28 PM
Replacing transactions like that isn't possible today. Making it possible would be, to quote Satoshi, "easier said than implemented".

You mean it's not implemented in the software, right?  As far as the protocol is concerned, I believe it is possible.  Yes, it would present an accounting challenge for the current wallet model.
470  Bitcoin / Development & Technical Discussion / Re: [PULL] 52-line patch supporting offline key generation on: May 21, 2011, 10:59:07 PM
I have written a patch that allows extraction and insertion of bitcoin private keys in a custom base58-based format, only containing the secret parameters itself, without the field and curve parameters.

Is it on the pull list or otherwise available?

Quote
Import and export of DER-encoded keys would also be useful (I have code for export laying around somewhere) for certain purposes though. You should check whether the imported key is a real bitcoin key though, as the public keys and signatures over the network do net encode the field and curve parameters, and would be invalid if the corresponding private key doesn't match.

Good points, but I do not want to lose sight of my motivating use case.  For generating a key pair and receiving BTC outside of Bitcoin, obviously Bitcoin can not do the checking in advance.  I agree it should check when importing, though.  I'd appreciate hints at code that will do that.
471  Bitcoin / Development & Technical Discussion / Re: [PULL] 52-line patch supporting offline key generation on: May 21, 2011, 09:04:35 PM
isn't "offline key generation" against basic BitCoin ideas ?

Not at all.  The most sensitive data in the system is the private key associated with a Bitcoin address.  That the current software requires private keys to be generated by a process that participates in the network and downloads blocks is a big design flaw.  (Early on, when BTC was under $0.01, it might have been justified in terms of simplicity and time-to-market.)

The network never needs to see private keys.  If you have a lot of BTC, you should keep your private keys well separated from the network and the threat of malware.  This patch will let you generate keys on an unconnected machine, perhaps booted from read-only media, and keep them away from the network until you are ready to spend their coins.

Even better would be a standalone transaction signer (and bitcoind importtx command) that would let you send, too, without putting your private key on a networked machine.  That is my next project, if I get around to it.
472  Bitcoin / Development & Technical Discussion / Re: Post-inflation security on: May 20, 2011, 05:33:29 PM
Some of us seem worried about how payers will know what size fee to offer.

I don't understand the problem.  Payers can effectively expedite a slow transaction by submitting a similar one with a larger fee while the first tx languishes unprocessed.  To guard against double-receipt (the flip side of the double-spend problem) the wallet software must simply:

  • make the transactions mutually incompatible by having them share inputs
  • use inputs that are unlikely to receive BTC (such as hidden change addresses), (edit: not needed; inputs on the wire reference earlier transactions, not addresses) and
  • prepare to handle the possible outcomes: tx 1 accepted, tx 2 accepted, or both languish.

As Gavin eloquently explained, miners will have different and evolving cost structures and preferences.  For a given received tx, a miner will have an algorithm by which to:

  • drop it and treat it as spam or DoS attack (block the sending node, sue the sender)
  • just drop it
  • keep it for possible later processing, or
  • include it in the current block

and either relay or not relay it.

The result will be a "fee curve" of cost over expected processing time for a given tx size.  People will invent ways to compute the curve, if nothing else, then by periodic experiment, and the curve will be generally published as a guide to payment software.

I hope this alleviates the worry.
473  Bitcoin / Development & Technical Discussion / [PULL] 52-line patch supporting offline key generation on: May 20, 2011, 02:28:15 AM
Yet another Feeping Creature, but it's tame, oh so tame...

https://github.com/bitcoin/bitcoin/pull/245

import key from PEM file

Motivation: Create keys on a secure system using only OpenSSL or similar software. Receive BTC, then when ready to spend them, use importkey in a running client.

importkey <file> <account>
Reads a PEM-encoded keypair from file and adds it to the wallet.
To create a keypair with OpenSSL, use:
openssl ecparam -name secp256k1 -out NEW_KEY.pem -genkey
Returns the key's bitcoin address.

$ bitcoind importkey ~/NEW_KEY.pem TestAcct
mt5M3Qa7fXsUV3bK6WtWTZEvXY2M1UPEgv

Bug: I'd like to safeguard against overwriting a key in the wallet with bogus data.
Bug: I don't understand what has to be mutexed.
Bug: Should do anything possible to make sure the imported key is valid.

Note: I did not implement the corresponding export function, because my use case does not require it.  I will be happy to implement it if this will improve the patch's chance of acceptance.

Note: To be convenient, one (I) would write a little script to read one of these PEM files and print a Bitcoin address.  All key handling would be possible offline, and certainly in the absence of a block chain, until spend time.  For my next trick, expect offline transaction signing and an importtx function.

Kind regards,
John
474  Bitcoin / Bitcoin Technical Support / Re: help with wallet.dat on: May 18, 2011, 04:06:03 AM
Are you running Linux or Cygwin, and do you know how to edit and run shell scripts?  This is the best I can offer at the moment.  Tested using testnet.

Code:
#! /bin/sh

# This script writes a file named recovered_wallet.dat.
# Make plenty of backups when manipulating wallet files.
# This software is offered freely without warranty of any kind.

# These instructions are for people who have a corrupt copy of a
# wallet.dat file with a nonempty balance and no other means to
# recover the coins.  The wallet.dat format currently (Original
# Bitcoin Client 0.3.x) is a Berkeley DB file.  You should search for
# and try the usual Berkeley DB recovery mechanisms before you attempt
# this method.

# Replace the values of PUBKEYHEX and KEYPAIRHEX below with a
# hex-encoded public key and full key pair, respectively, from your
# corrupt wallet.dat.  In a hex dump, the public key is 65 bytes
# following a sequence "03 6b 65 79 41".  The keypair consists of
# another copy of the public key (somewhere else in the file) preceded
# by 217 bytes, which presumably encode the private key.  The 217
# bytes always seem to begin with 0xfd (253).  These observations are
# a result of reverse-engineering the file format and may not always
# apply.  If you can confirm or correct this, please post!

# The following short Perl script may find the values in a file called
# CORRUPT_wallet.dat:

# #!/usr/bin/perl
# $_ = `cat CORRUPT_wallet.dat`;
# while (/keyA(.{65})/sg) { $k{$1}++ }
# for my $k (keys(%k)) {
#     while (/(\xfd.{216}\Q$k\E)/sg) {
#         print("PUBKEYHEX=", unpack("H*", $k), "\n");
#         print("KEYPAIRHEX=", unpack("H*", $1), "\n\n");
#     }
# }

# A typical wallet.dat contains 100 or more of these key pairs, which
# you would try one by one if you don't know which one contains your
# coins.  http://blockexplorer.com/q contains tools to convert from a
# public key to an address, and you can look up each address (with
# http://blockexplorer.com) to see if it has a balance.

# To convert the example public key below to an address:
# http://blockexplorer.com/q/hashpubkey/04ff5443fcd00b8f3844569dcaa42662d90e0c8afb1fe35804c320e5bb08ea6dadc3231767aa13b9dd6abcb45a8cd0497490d5c2a78ff85ea61711394b3b08e5c9
# returns the "hash" 37A85118AD7DBE78132CF13DCD90F35D701172C5, which,
# if given as the last component of
# http://blockexplorer.com/q/hashtoaddress/37A85118AD7DBE78132CF13DCD90F35D701172C5
# yields the address 165HoQXzxc26xxkECD95icTAscZW8TngFU.
# (In the testnet, this is mkbF6TcymdTMk5Dqun7TYXfVjcAD2g5cSj.)
# The bitcointools package contains Python code for doing the same.

# If this script succeeds for a given address, exit any running
# bitcoin process.  Back up any existing wallet.dat and install
# the new file (recovered_wallet.dat) as wallet.dat.  Run "bitcoind
# -rescan".  (Maybe the GUI will work, but I've tested only the
# daemon.)  After the program updates and scans the block chain,
# "bitcoind getblockcount" will show the current block count as shown
# by http://blockexplorer.com.  "bitcoind listaccounts" should show
# one account with an empty name and the coin's value, for example:

# {
#     "" : 123.456
# }

# Get a known good address and send the full balance to it using
# "bitcoind sendtoaddress {KNOWN_GOOD_ADDRESS} {BALANCE}".  If you
# send less than the full balance, the remainder will go to a change
# address in the recovered wallet, complicating matters.

# "bitcoind sendtoaddress ..." outputs a transaction hash.  Check the
# block explorer for confirmation.  Stop the program with "bitcoind
# stop" and restore your real wallet file.

#PUBKEYHEX={your public key}
#KEYPAIRHEX={your full key pair}
PUBKEYHEX=04ff5443fcd00b8f3844569dcaa42662d90e0c8afb1fe35804c320e5bb08ea6dadc3231767aa13b9dd6abcb45a8cd0497490d5c2a78ff85ea61711394b3b08e5c9
KEYPAIRHEX=fd170130820113020101042044b1585492c83e83fd917783c1b74ec25e3e6b3ca8722cc41eabe05249a46288a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200$PUBKEYHEX

# Replace "db4.7_load" with the name of the db_load utility installed on
# your system.
DB_LOAD=db4.7_load

# Output file name.
RECOVERED_WALLET=recovered_wallet.dat

# Refuse to modify a previously created file.
test -e "$RECOVERED_WALLET" && {
    echo "$0: exiting because $RECOVERED_WALLET exists" 2>&1
    exit 1
}

$DB_LOAD "$RECOVERED_WALLET" <<EOF
VERSION=3
format=bytevalue
database=main
type=btree
db_pagesize=4096
HEADER=END
 036b657941$PUBKEYHEX
 $KEYPAIRHEX
 0776657273696f6e
 027d0000
 0a64656661756c746b6579
 41$PUBKEYHEX
DATA=END
EOF
475  Bitcoin / Bitcoin Discussion / Re: A simpler explanation, please... on: May 17, 2011, 08:32:24 PM
It has been said a number of times and referred to in the FAQ that the value of fiat currency comes from gold.

The last pretence of gold backing fell away in 1971.  Look for the video "Money as Debt" or the (lengthy) audio series "Wizards of Money" for an understanding of fiat.

Quote
Quite how that kind of power/value can be injected artificially is not clear.

Consider the work put into creating and maintaining the Bitcoin system and the currency's advantages (such as inflation immunity) as the source of that value.
476  Bitcoin / Bitcoin Discussion / Re: A simpler explanation, please... on: May 17, 2011, 04:28:29 PM
I just heard about Bitcoin this morning and have spent an hour or so trying to get my head around it.

An hour?  It took me two weeks to get past basic questions!  Smiley

Quote
But taking a leap of faith from that, neither do I fully see how/why there should be a 50 Bitcoin credit for every new block other than it being something like a Premium Bond (lottery) which may reward persistent client use.

I'll try this one.  The network must reward whoever processes transactions, i.e., miners/processors.  In the long term, if Bitcoin is popular, users will find it worthwhile to include transaction fees, and those fees will support the processing.  Until that trend has a chance to become firmly established, the network will pay a fixed BTC amount per block, roughly 300 BTC/hour (more when the network hash rate grows, less when it shrinks and after the block reward goes to 25).  The hope is that this reward will go to electricity, but also optimizations probably leading to the development of highly specialized, efficient hardware (Bitcoin chips).  Whether this happens depends on the value of BTC (or a similar currency) in the near to medium term.  (One of my gripes is that whoever controls the chip fabs will control the economy, with probably more centralization than the central banks of today.  But such "control" over the economy may be less open to abuse.)

Note that "the network pays..." means that the software, which users choose to run, accepts or rejects blocks according to rules that implement this effect.

Quote
It is not my intention to be antagonistic or to instigate any kind of combative debate, I simply wanted to convey that to those who designed the system, it may seem perfectly elementary and early adopters and those of a particular aptitude may also find it simplicity itself. I find my own work, some of which involved video editing and prepress graphic design very easy but impossible to convey - I'm not a natural teacher.

Or should I just blindly comply as if putting a SIM card in my iPhone - not questioning how it works? Just accepting?

I feel your pain!  For the first week or two, my CPU (brain) was at 100% with the comp-sci and economics parts talking up a storm.  It is one of those rare developments that stimulates, and puts demands on, both.  The early adopters who most "get it" probably have both technical and financial backgrounds.  Those who don't will ultimately have to put some faith in those who do, if the project will succeed.
477  Bitcoin / Bitcoin Technical Support / Re: help with wallet.dat on: May 16, 2011, 05:11:53 AM
I get 11ddb exception, so I think the file is somehow corrupted or damaged. When I open the file with hex editor or notepad I can still see the address to which the bitcoins were sent.

Have you tried the Berkeley DB tools?  Does "db4.7_dump wallet.dat" give an error?  (db4.7_dump may be called "db_dump", depending on your installation, and you may have to install the "standalone utilities" separately from the main library.)  I have managed to fish a keypair out of db_dump output and paste it into another wallet (modifying its db dump and recreating it with db_load).

If db_dump can not handle the file, I suggest either googling Berkeley DB recovery or trying to find the key pair with your hex editor.  For example, in this partial dump of a wallet.dat file:
Code:
00003e80: 1a01 01fd 1701 3082 0113 0201 0104 2044  ......0....... D
00003e90: b158 5492 c83e 83fd 9177 83c1 b74e c25e  .XT..>...w...N.^
00003ea0: 3e6b 3ca8 722c c41e abe0 5249 a462 88a0  >k<.r,....RI.b..
00003eb0: 81a5 3081 a202 0101 302c 0607 2a86 48ce  ..0.....0,..*.H.
00003ec0: 3d01 0102 2100 ffff ffff ffff ffff ffff  =...!...........
00003ed0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00003ee0: fffe ffff fc2f 3006 0401 0004 0107 0441  ...../0........A
00003ef0: 0479 be66 7ef9 dcbb ac55 a062 95ce 870b  .y.f~....U.b....
00003f00: 0702 9bfc db2d ce28 d959 f281 5b16 f817  .....-.(.Y..[...
00003f10: 9848 3ada 7726 a3c4 655d a4fb fc0e 1108  .H:.w&..e]......
00003f20: a8fd 17b4 48a6 8554 199c 47d0 8ffb 10d4  ....H..T..G.....
00003f30: b802 2100 ffff ffff ffff ffff ffff ffff  ..!.............
00003f40: ffff fffe baae dce6 af48 a03b bfd2 5e8c  .........H.;..^.
00003f50: d036 4141 0201 01a1 4403 4200 04ff 5443  .6AA....D.B...TC
00003f60: fcd0 0b8f 3844 569d caa4 2662 d90e 0c8a  ....8DV...&b....
00003f70: fb1f e358 04c3 20e5 bb08 ea6d adc3 2317  ...X.. ....m..#.
00003f80: 67aa 13b9 dd6a bcb4 5a8c d049 7490 d5c2  g....j..Z..It...
00003f90: a78f f85e a617 1139 4b3b 08e5 c9bd ca00  ...^...9K;......
00003fa0: 4600 0103 6b65 7941 04ff 5443 fcd0 0b8f  F...keyA..TC....
00003fb0: 3844 569d caa4 2662 d90e 0c8a fb1f e358  8DV...&b.......X
00003fc0: 04c3 20e5 bb08 ea6d adc3 2317 67aa 13b9  .. ....m..#.g...
00003fd0: dd6a bcb4 5a8c d049 7490 d5c2 a78f f85e  .j..Z..It......^
00003fe0: a617 1139 4b3b 08e5 c9c2 57f9 0400 0102  ...9K;....W.....

You can see the 65-byte public key beginning at offset 0x3fa8 (04ff 5443..., right after the ASCII word "key" and a 65 byte that I guess is a length of what follows.)  The full key pair is in a sequence of 282 bytes that ends with those same 65 bytes, in this case starting at offset 0x3e83 (fd 1701...).  The lines for db_load here are:

 036b65794104ff5443fcd00b8f3844569dcaa42662d90e0c8afb1fe35804c320e5b\
b08ea6dadc3231767aa13b9dd6abcb45a8cd0497490d5c2a78ff85ea61711394b3b\
08e5c9
 fd170130820113020101042044b1585492c83e83fd917783c1b74ec25e3e6b3ca87\
22cc41eabe05249a46288a081a53081a2020101302c06072a8648ce3d0101022100\
fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010 704410479be667\
ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a\
3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffff\
ffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004ff5443fcd0\
0b8f3844569dcaa42662d90e0c8afb1fe35804c320e5bb08ea6dadc3231767aa13b9\
dd6abcb45a8cd0497490d5c2a78ff85ea61711394b3b08e5c9

(Remove the backslash-newline sequences, which I added for formatting.)

A normal wallet.dat will contain over  100 such key entries.  You have to find the one(s) that match your coin-containing addresses.  The Block Explorer can convert a public key (in hex form) to an address using the hashpubkey and hashtoaddress functions in combination: http://blockexplorer.com/q

If the DB tools don't work, you are probably looking at a few hours' work for an expert, and you can't be sure the key pair itself isn't corrupt, so you'd have to consider the value of the coin relative to the work.  I think a tool could be written to help with this.

Good luck.
478  Other / Off-topic / Re: Can the Hashes from block generation be useful? on: April 30, 2011, 03:13:38 AM
i know that. but anything not bitcoin related?

Ah, then I must confess a lack of curiosity.  It's a little like asking what an automated teller machine is good for, other than money-related things.  If it's heavy enough, it might protect you from a stampeding herd of elephants.  Kind of like the lotto application, mildly cute but shrug-worthy.
479  Other / Off-topic / Re: Can the Hashes from block generation be useful? on: April 29, 2011, 06:56:35 PM
can they for example be used in cryptographic research, or anything else useful?

or are they just completely useless?

I answered this in another thread.  Block hashes serve as the hashing community's signature attesting to the completeness of the block chain.  The strength of the hash on a block and its subsequent blocks is what gives receivers confidence that their coins are not double-spent.  By hash strength, I mean the "number of zeroes" or difficulty score.  They are not useless at all... until someone breaks double SHA-256.

http://bitcointalk.org/index.php?topic=6459.msg98999#msg98999
480  Bitcoin / Bitcoin Discussion / Re: concern for bitcoin and the environment on: April 29, 2011, 04:09:01 AM
So to that point, I guess Bitcoin miners should be concentrated in places with an abundance of energy. And I suppose the free market forces will make sure that this happens.

Not only in places with an abundance of energy, also at times with an abundance of energy.


willmoss and forever-d are onto something that most everyone has missed.

As I see it, the product of the computations is a "super-signature" on the block chain.  A block solution carries the hashing community's endorsement of the transaction history and attests to its completeness.  This is what protects receivers from double spends.  Far from being wasteful or frivolous, this resource is essential to the currency's usefulness.  Those hash values that start with all those zeroes function like a digital signature on email, but rather than a person or bank, it is the Bitcoin hashing community whose approval they demonstrate.

Bitcoin provides very little economic incentive to expend energy that would otherwise be usable.  It provides plenty of incentive to salvage energy that would go to waste if not for Bitcoin.  If someone is paying for electricity to mine bitcoins, something is wrong.  Solar panels fit the model at sunny times when nobody but Bitcoin needs their output.

The electricity spent in hashing is not wasted. It creates a product of value to the Bitcoin economy. The product is a supersignature on the complete list of transactions to date (the Block chain). This supersignature attesting to the chain's completeness is Bitcoin's defense against double spending.

Many sources of energy vary in their availability in ways that do not match the variations in demand. The law of supply and demand should require Bitcoin to soak up a lot of energy that is currently "wasted" before it makes a big dent in the otherwise usable energy supply. [Perhaps cite estimates of the break-even point for mining profitability that imply near-zero-cost electricity.]

I plan to replace the reply at https://en.bitcoin.it/wiki/Myths#Bitcoin_mining_is_a_waste_of_energy_and_harmful_for_ecology with the above text, or a revision thereof if comments so warrant...
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!