I'm sort of in the same boat.
Have you tried the 32-bit version?
I don't remember seeing a 64-bit version.
I can sync, but it stops, and I had to exit and launch again.
I started from scratch.  It loaded 23000 blocks and stopped.
It is running again and hasn't stopped, for very long, again yet.
This all started because it would not sync the last 1300+ blocks.

I'm sorry BrowenHarley, I do not have the experience for which you are looking.
Kind Regards.

Hi Revalin.

First, thank you for the crypto info and the wallet suggestions.  Your suggestions are almost the same as what I concluded.

Regarding: In 2001 IBM successfully used Shor's Algorithm to factor 15 into 3x5,
See: https://en.wikipedia.org/wiki/Shor%27s_algorithm  and  https://en.wikipedia.org/wiki/Nuclear_magnetic_resonance_(NMR)_quantum_computing
"NMR quantum computing experiments are likely to have been only classical simulations of a quantum computer."
So the IBM experiment does not satisfy true quantum requirements.  There are other experiments that did demonstrated entaglement, but only for a couple qbits.
There is a huge problem bridging classical and quantum mechanics.  The general relativity equivalence principle (the heart of GR) has been verified through measurement to at least 12 decimal places. That is more accurate than many laws of physics.
Single photon measurements are not sufficiently accurate to confirm some very basic quantum properties like in a Mach-Zehnder interferometer.
Vacuum energy density esimates are not even close between classical and quantum predictions.

The proof of concept examples only demonstrate a very small/simple factorization that has only one answer.  Does this demonstrate by measurement the polynomial time factorization speed?

Sorry, this is off topic.  I do find it fascinating though.

Kind regards.

Thanks DeathAndTaxes and DeepBit.

I also found: https://bitcointalk.org/index.php?topic=78471.0
and that Revalin is an expert.  As the founder of Tangible Cryptography LLC, DeathAndTaxes probably is also.  It is great to get comments from people that really know what they are talking about.

The main issue with using the public key instead of the Bitcoin address appears to be what Revalin stated:
"Once coins have been sent FROM the address the pubkey is known and ECDSA is probably the weakest link (about 128 bits of security equivalent).  This may be plausible to attack in the distant future, but probably not in my lifetime unless a cryptographic flaw is discovered."
Using the address hash appears to be actually more secure than ECDSA, so the drop in security bits from 256 to 160 is not actually real, only perceived due to the weakness of ECDSA.

So, it appears that trying to use a long term account is not really worthwhile.  For anonymity, it tends to tie all your other accounts/transactions together in the blockchain.  Not good either.
Using a new account number for each receiving transaction, including for change accounts, appears to be the safest solution.
It also is about as well as one can do for anonymity.  It is very difficult to purchase anything using Bitcoins that requires delivery of the purchase by a commercial carrier (to a street address or PO Box) without compromising yourself to some extent.  For online only there is TOR.
The key for anonymity appears to be to minimize linkages between accounts (all permutations for sending/receiving).

This seems to imply that a wallet should try to minimize the number of transactions used for the source coins and also avoid using a change account if practical.
The wallet is definitely the weakest link.

Am I on track here?

BTW DeepBit, how does one do multi-signature transactions on Bitcoin?
Do you know a good website link?

Thanks.

Thank you Gavin Andresen, gmaxwell, Revalin and DeepBit for your replies.  They are very helpful.

I am starting to understand this better.  My concern is based in the long term safe storage of Bitcoins.  Directly using a single account for this would leave many transactions in the blockchain for both receiving and spending coins.  While this could be masked by using temporary (wallet) accounts to transfer coins into and out of the long term account before transfers from or to other's accounts, it will still be in the blockchain, so the public key would not be completely hidden (like if not used in any transaction), and would be easy to obtain from the blockchain if one knows one of the temporary account numbers.

I don't believe that the quantum computer threat is very immanent. I find it very difficult to believe that quantum computers will ever physically exist.
Quantum physics is based on a purely mathematical formulation rooted in probability, not physical phenomena.  It does not have a direct tie to reality.

The Bitcoin address does hide the public key using a hash {RIPEMD160(SHA256())}, which does a very good job of protecting the public key.  It makes a lot more sense why it is recommended not to spend from the same account number more than once.  Then, the public key is not exposed except for a very brief duration, leaving very little time to try to exploit it.  Does exposure of the public key really matter?

I do not disagree that the probability of an accidental address collision is incredibly improbable.
My concern is the intentional collision possibility.  Guessing a private key that will result in the same public key seems less likely than a key pair that has the same address hash.  However, depending on how many public keys have the same address hash, the guesser gets an advantage due to the increased possibility of a collision at the address hash level, relative to the public key level.

According to https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm
"public key: A number that corresponds to a private key, but does not need to be kept secret."  So one would either have to guess at the private key or determine a way to crack ECDSA using the blockchain info related to the address and/or public key.  Guessing at a truly random private key is incredibly improbable.  If the private key is derived from a passphrase (brain wallet), the possibility might become feasible or even likely.

The private key has a security level of 256 bits.  The MD160 has a security level of 160 bits.  It would appear that a single Bitcoin address would collide with about (2^256)/(2^160) or about 8x10^28 public keys.  It is probably not this simple, but an address collision certainly seems much more probable than a public key collision, if that is even possible.

If someone would be willing to comment on this, I would really appreciate it.

The key issues seem to be:
1) Approximately how many ECDSA public keys can have the same address hash?
2) How secure is the private key when the public key is known?
      (This is addressed a little at http://en.wikipedia.org/wiki/Elliptic_Curve_DSA, which seems to indicate it is as difficult as guessing the private key.  Also at http://eprint.iacr.org/2002/129.pdf   and   https://bitcointalk.org/index.php?topic=10697.0)
Also: http://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money

Thanks!

Hi Gavin.

I was reading at: https://en.bitcoin.it/wiki/Transactions#Types_of_Transaction

I am still a little confused and/or misunderstanding.  Let's look at a very simple transaction, using all the bitcoins from a single previous transaction sent to another single account.  Am I correct here?
For a transfer to bitcoin address transaction, the scriptSig contains the sig and the public key, where the sig is the altered current transaction encoded using the private key.  This is the first part of the transaction and specifies the previous transaction (transaction ID hash in the outpoint) that is the source of the coins.
The scriptPubKey is retrieved from that previous transaction and used to verify that this new transaction is authorized.
Now, the scriptSig should always be self consistent as it should have been generated by a private/public key pair.
For the scriptPubKey of: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
The public key from scriptSig is duplicated, hashed, compared to the scriptPubKey hash (to verify authority) and then the signature is checked for validity.  If the scriptPubKey was generated by a private/public key pair, it will verify, even if it is not the correct public key, as long as the public key has the same hash (Bitcoin address).  So this does not stop two public keys that have the same hash from each being able to access the coins.

For a transfer to IP address, which you seem to be referencing, the process is simpler and even more secure, as it splits the scriptPubKey data between the two transactions.
The public key is specified in the previous transaction in the scriptPubKey.  The current transaction only provides the sig in the scriptSig.  Now, both authorization and verification are combined into one step.  The public key from the previous transaction is used to verify the sig encoded using the private key in the current transaction.  There cannot exist two private keys such that a single public key can verify the sig generated using either private key, right?

Do I understand this correctly?

I like the latter method better as it avoids the hash issue and results in shorter transactions.  Its main drawback is it requires the previous sender to use the public address instead of the bitcoin address (short address).  It also precludes obtaining a balance from the block chain using the Bitcoin address.  The balance has to be obtained using both the public key and the bitcoin address to be complete (both types of transactions being possible in the block chain).

Why is it called a transfer to IP address if the IP address is not part of the transaction?

Thanks.

I'm trying to determine if the following variation for the script associated with the transaction receiving account is valid for processing by the Bitcoin network.
Can someone answer this?
I could just try it, but I decided to ask first to see if someone knows the answer or has other informative comments.

Instead of:
OP_DUP OP_HASH160 {hash of public key} OP_EQUALVERIFY OP_CHECKSIG

use:
OP_DUP {full public key} OP_EQUALVERIFY OP_CHECKSIG

The purpose of this being to avoid the possibility of two public keys having the same hash, which would allow either party to spend the bitcoins.
I am not familiar with how small this possibility actually is.
The only reason to use it would be to transfer coins into a "savings" type account (like a paper wallet) so they are more securely "stored" in the block chain.
This would be a transfer between two (or more) accounts belonging to the same person.
It is not appropriate for regular transactions since it is not part of the standard wallet and it is much easier to use the base-58 Bitcoin address for such transactions.

I appreciate your comments.

Thanks.

BTW:
The code only demonstrates the transaction generation and verification, not how to duplicate a Bitcoin address with a key-pair.
I have no idea how to do that.

Hi enmaku.

See my reply to my own Newbie post, subject: Offline generated transactions, how is a transaction signature verified?

That should address your concern.

The full public key is used to access the private key encrypted transaction hash (scriptSig), which is then verified against a locally computed transaction hash.
The address (hashed public key) is used only from the previous transaction (source coins) as a first test.
HOWEVER, both the public key and the signature are provided in the transaction, so that does not result in any security if two public keys hash to the same Bitcoin address.

So to spend the Bitcoins for such a "collision", you have to have a private key / public key pair (or set) for which the hash of the public key must be the same as another party's Bitcoin address.  Then you can create a transaction to take the coins.

If you would like a copy of the modified BTCurious "offlineTransaction" JavaScript code that demonstrates all this, let me know in a reply post or message.

Regards.

Please consider this post CLOSED.
Everything has been resolved.
Thanks.

Consider this post CLOSED.

I have determined the answer myself.  I find the documentation to be very confusing about this process.
I was reading at https://en.bitcoin.it/wiki/OP_CHECKSIG
The "How it works" section does not seem to make sense to me.
The very last sentence of the first paragraph at the top of the page explains it.

Transactions are verified using the requirement specified in the previous transaction by the entry that received the Bitcoins now being spent.
The controlling requirement for signature verification is defined by the transaction entry that transferred the Bitcoins to the account in the first place.
One would expect that the script for the previous_transaction receiving address will include:
OP_DUP OP_HASH160 {address} OP_EQUALVERIFY OP_CHECKSIG
so that signature verification will occur when the Bitcoins are "spent."  I don't know if that is required.  It is dependent on the Bitcoin sender's transaction "string."  The receiver has no control over this.  If this is not required, it seems like a flaw.

The process is:
For each Bitcoin transaction_source entry,
load the signature and the public key onto the stack,
look up the previous transaction specified in this entry's outpoint.hash and outpoint.index,
get the script from that previous_transaction entry,
duplicate and push the public key (already on the stack) onto the stack again,
calculate its RIPEMD160(SHA256(PK)),
push the Bitcoin address in the script just retrieved onto the stack,
compare the two, if equivalent, then, (note that this verifies the source of the Bitcoins from the saved transaction blocks)
generate a hash of the (usually) entire current transaction with all source entry's scripts removed and the current entry's script replaced with the script retrieved,
use the entry's public key and the signature and compare it to the hash for verification,
if verification is true, this is a valid entry, continue.

I hope that this helps anyone that views it.

Thanks enmaku.

I do like that strategy too.  It is not a true brain wallet since there are the dogtags.  Their content could easily be encrypted and stored in the cloud if necessary.  Not too risky.  Having a JavaScript program stored in the cloud does not help guessing a passphrase, password and pin.
It is clever.

Thanks for the entropy analysis.  It is consistent with what I have found.  I will save your comments.

I don't understand the RIPEMD160 issue completely.  To spend Bitcoins, one has to be able to correctly produce a signature in the scriptSig of the transaction.
The scriptSig contains a private key hash of the transactions and the public key.
I don't fully understand how signature verification works yet.  You seem to be indicating that there is a weaker link in the process because of RIPEMD160.
To spend Bitcoins you need a private/public key pair where the public key hashes/maps to the address of an account "holding" Bitcoins.  Right?
This way, you can create a scriptSig that will pass verification (however that is done).  This is not as strong as the private key because of the hash.  I may have just answered my question.

Is there a good resource I can use to understand this?

Thanks.

Thanks Ukigo.

 I understand the security in not sharing a method for a "brain wallet".
I would be interested in knowing yours, but that would not be in your best interest.  It is difficult to advance my understanding this way, but I can't blame you.
I understand that for my own best safety, I should not share anything like this.  I can always keep my own private method.

The purpose of sharing this is to have a method that anyone/everyone can use with realistic security.  Though this makes the strategy public, if the method generates unique enough keys for each user, it does not compromise the security of the result, any more than making AES public compromises its security.  The goal is to increase the possible solution pool to an all but impossible size, even though the seeds are not necessarily very complicated.  This is what cryptography is really all about.

Any suggestions you would care to share would be greatly appreciated.

I have been working with BTCurious' offlineTransaction JavaScript code.  It is nicely coded.
https://www.strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions
I have added to it to make it helpful understanding transactions as well as adding comments.
I can make it available if someone helps me with that.  I'm not sure how to accomplish it at this time.

It can now specify a change account and it shows the transaction structure (in my text format and JSON).  It can also show the transaction structure for a transaction string (what the original program was designed to generate) and change coding for a public key, a transaction hash and a Bitcoin address.  This allows one to verify the data in a transaction with a form that is more often seen/found.

What I have not been able to do yet is signature verification.  The scriptSig contains the signature and the public key.  The signature is a hash of transactions with the private key.  The code documents how this is done.  According to BTCurious and others, it is done correctly and works.  I would like to verify this for myself.  I am not a cryptography expert, otherwise, I probably would not have to ask.

How is the public key used to verify the signature in a Bitcoin transaction?

Thanks in advance for any assistance.

Hello everyone.

I chose the pseudonym BTime based on BTCurious.  Not very original.  Oh well.
I don't know BTCurious, just saw the name and liked the strategy.

My background is electrical engineering; hardware, software and firmware.  A couple decades of experience.
I am not the greatest programmer, but I do OK.

I find Bitcoin fascinating and a real attempt at a global currency that could break the banks.
Breaking the banks is something that is long overdue and the only way to stop this insanity of debt based currency.
The whole concept of debt based currency is both insane and evil.  I do not understand how or why the people of these united states allowed this to be instituted, except that they did not understand it at the time, or did not care.  The laws of mathematics ensure that it will collapse.  It is just a matter of when.

I am working on and looking into walletless transactions.  Some variations are called the paper wallet, brain wallet, etc.

Comments are welcome.  Thanks for reading.
BTW, this is my third post.  It should have been first.  Sorry.

I do not know your understanding of transactions.  This is not meant to be insulting, just hopefully informative.

I am not an expert, but based on my study of transactions, it depends on what the wallet generated for the transaction.  Only enough transactions should be included to cover the amount being transferred out.  Whatever generated the transaction appears might have included all unspent transactions in the wallet for the source funds.  It does not list what the amount in each transaction was at the time, so this is laborious to determine based on the info provided.  It does not show what happened to the bit-change.  I appears it went back into the source account.

Even if you have/use only one account number, a transaction is defined by previous transactions for the source funds.  This can make for a long list depending on how the transactions are selected.  Transactions are not pooled like a bank (except having the same account number); they remain separate.  If multiple account numbers are involved, the transaction gets longer.  The shotgun approach would be to throw everything at the transaction and let the change/excess go to the change account.  This would be a very poor approach.

See:  https://en.bitcoin.it/wiki/Transaction

I have been working with Bitcoin transactions for a little while.  I have modified the JavaScript for bitaddress.org for a brain wallet.
bitaddress.org provides a client side JavaScript page that can be easily run on an offline machine, either Windows or Linux, which is nice.
The code looks well written and was easy to modify.  The code will recognize a passphrase for a private key.  Doing this directly, I agree, is not very secure.  I added the ability to enter a password and a PIN.  The password is modified by bit reversing each character and then cyclically XOR-ing it with the passphrase (a very old and simple type of cipher).  This results in an unintelligible passphrase.  The PIN defines the number of times to apply the 256 hash to the XOR-ed result to produce the private key.  So the brain wallet gets bigger, having three things to remember, the long passphrase, the reasonable password and the 4 digit PIN, but these would not normally be related to each other and would make guessing at an easy to remember passphrase to try to steal Bitcoins pointless. Keeping the private key secure requires the same precautions as usual.  The public key Bitcoin address generated with the private key is all that is needed to start receiving Bitcoins.  The purpose being to use this as a savings account or hidden stash for Bitcoins; never used in a wallet.  The passphrase should contain personal information like birth dates, maiden names, etc. instead of just text from a book or poem.  The whole point of this is to be able to easily regenerate your private key.  The Javascript can be hidden anywhere out in the cloud.  It is not secret, it just needs to be available should the private key need to be regenerated (to spend the Bitcoins).

Any comments addressing the strength of such an approach would be greatly appreciated. 

I looked into the entropy argument, and while not understanding informational entropy completely, the measurement/computation of such entropy does not appear to be very straight forward except for relatively simple cases.  The bottom line appears to be the ability of someone to either guess your private key (for a truly random key, unlikely), or to guess at the input to the generation of your private key (this case) so they also can generate your private key.  These modifications make that guess significantly harder if not also impractical.

I don't know how to make the modified source code available on this forum at this time, but I am willing to share it.

The second part of this is BTCurious' offlineTransaction JavaScript code.  This generates an offline transaction (no wallet required).  I will post about this in a separate post. (I need 5 as a newbie)

The third part is submitting the transaction to the Bitcoin network.

Thanks for your comments.

I have been working with offlineTransaction from BTCurious.  The transaction I generated did not work through BTC Sender @ http://bitsend.rowit.co.uk/
Is this site still working?

It appears that BTC Sender sends the transaction in the URL query string, which limits the length of the transaction string.  This is another problem I am having; the transaction gets cutoff and the site does not post back.

I am trying to find a way to verify that the offlineTransaction I generated is valid.  I tried generating the same transaction using Electrum and outputting the transaction.  They were not the same length and it did not work on BTC Sender either.  Even when I used an account that resulted in a short enough transaction string.

Fortunately, my BTC accounts were not adversely affected.

I like the Javascript approach for portability and ease of use.
I would really like to contact BTCurious since he authored the code.

Any suggestions?

Thanks.