1. Yes (double click its cell to edit) 2. (for online) Yes, it does require the blockchain. You can set the directory to be where ever you want it to be, though (e.g. I have it on a large HDD instead of my primary SSD). See the datadir and satoshi-datadir command line options at the bottom of https://bitcoinarmory.com/download/troubleshooting/3. The primary concern would be that it's not part of your paper backup, only in digital backups created after you imported the private keys.
|
|
|
1. Where can I get your utility? 2. Which license is it ? (needs to be open-source, preferably BSD-style, so it can be integrated into Android and FreeBSD later on)
1. Two posts above yours is: https://github.com/theymos/passphrase2. The source at the above link says "Public domain" I would highly recommend that nobody use this to create a wallet. This is highly insecure. Practically anyone who knows you could get in based on what they already know, or with a tiny amount of work (e.g. researching you on Facebook). People who don't know you would first need to identify you, and then get in with a tiny amount of work. And "but the attackers wouldn't know I'm using that algorithm!" is not a good assumption or argument. "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." ( Kerckhoffs's principle) Someone could also brute-force randomly-generated names/birth dates/cities.
|
|
|
I am using online wallet (blockchain.info) as my hot wallet. As I understand, to run a hot wallet for automatic withdrawal I have to keep the wallet password in the server. The withdrawal URL requires it to pass in a plain text format...
Can someone suggest me, what is the best way to secure it ? As I can see, at any point of time, it is open to the server guys !!!
This is not accurate. The blockchain.info wallet is designed so that the encryption password is never sent to the server. In short, the encrypted wallet is stored on the server, and decrypted on the client side only. It's re-encrypted before sending it back to the server. You have to trust that the server won't modify the code (web page/JS) to send the unencrypted wallet back to the server, but everything else requires no trust and is verifiable (it's possible to read the client code). This is more of a problem on a web-hosted wallet like blockchain.info than on an app like Bitcoin Core, Armory, or Electrum since a web server can swap out code any time, while the others have to be explicitly updated/installed. Client-side malware could also steal your money in the brief time that it's unencrypted on your side (but this is a problem with any hot wallet, and is a big reason why cold storage is safer). If you're still concerned about the security of your hot wallet, I'd recommend any desktop wallet from https://bitcoin.org/en/choose-your-wallet except MultiBit (I've heard that it can lose your private keys in some circumstances, and the creator doesn't seem concerned with fixing that major problem). I use Armory.
|
|
|
But with bitcoin if that is done, that means the final hash (all that matters) is done from a limited set of characters of known length.
So generating a random sha256 sum and then doing repeated rinse and repeats *may* boost your odds of a collission.
2^256 is a really, really big number, though. I really doubt this constitutes a feasible attack. Let's make up some numbers to show you what I mean: let's say that people typically repeat their hash 1 million times, and there are a million such addresses in use. 1 million * 1 million ~= 2^40. This means there are 2^40 random sha256 hashes that, if you repeatedly hash them up to 1 million times, will result in you spending someone else's money. Unfortunately, there are 2^256-2^40 (or roughly 2^256) sha256 hashes that do not result in anything useful.
|
|
|
This course is talking about public key encryption/decryption, e.g. RSA, and how that's used to share a secret key. This and the public key signing algorithm (ECDSA - for signing only, not encryption/decryption) are quite different technologies (although you'd probably find both interesting). I'd look for some sort of introduction to elliptic curve cryptography.
|
|
|
I actually wanted to know this; what exactly about bitcoin can change and what can't? things like the hard limit obviously, but what else? Could we hop onto a new algorithm once SHA-256 is broken?
From a technical perspective, you can change anything (in pseudocode: if blockNum < X: oldBehavior() else: newBehavior()), but it's only meaningful if nearly-everyone agrees that's what Bitcoin should do. So from a realistic/human perspective, you can only change things that people agree you can change, e.g. none of the changes on this Prohibited changes list can be expected to happen, because they fundamentally change what it is to be Bitcoin. Anything that doesn't fall under that heading is fair game. Changing the hash algorithm because the old one is failing is something that I think nobody would object to (although they're sure to have different ideas about how to deal with the problem). If SHA-256 were to be broken (e.g. in the same sense that MD5 is - we knew it was coming for years before it became easy to find collisions), we could and would move to a new, more secure hash algorithm. I think the most likely scenario would be (calling the new algorithm H): A change is announced that at block X (some weeks/months in the future), we will add OP codes for transaction scripts to hash using H instead of SHA-256. People will be expected to move all money stored in older addresses to the new format. Those who wait too long risk their money being stolen due to the vulnerability in SHA-256. A change is announced that at block Y (some months/years after X, to give people time to transition), we will switch from SHA-256 to H for transaction IDs, block headers, etc. (with appropriate difficulty adjustment so that we can still target roughly 10 minutes/block to start with) Transactions using SHA-256 will become non-standard to discourage their continued use. Old outputs will still be valid, although they might be easily stolen.
|
|
|
How do you propose the shipping address, etc. be encrypted in the blockchain? ECDSA, as used in Bitcoin currently, is only for signing data, not encrypting something that can later be decrypted. You might include an RSA public key in the poster, and encrypt with that. Including this encrypted data could easily bloat the message to the point that a larger transaction fee is required (not to mention bloating the blockchain). And you have to be online to broadcast your transaction to the network, anyway, so I'm not sure why "enabling shopping directly from a printed poster" is a big deal. I'm not sure this gives you much over BIP 0070. And I'm ok with having the website validate that it understands my details before paying it for its goods/services.
|
|
|
I included a transaction fee of 0.0001 on the transaction of 243 bytes ( 0.001+ 0 input, 0.0008 out to me, 0.0001 out to any, 0.0001 remaining as tx fee), well above their required "0.1 TBC (0.00004096 BTC) per 512 bytes." I realized that no pool would process this transaction (doesn't fall under the free rules, plus it's non-standard) without a fee, which is why I included the second input in the first place (made this much more complicated, by involving real money/wallets instead of just handwriting a transaction).
|
|
|
Actually looking at the debug.log it looks likes the error is simply indicating the txn is non-standard. 2014-07-11 15:53:13 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
You would need to find a method to relay this txn directly to a miner that accepts non-standard txns. Thanks. I pushed it to Eligius at http://eligius.st/~wizkid057/newstats/pushtxn.php, since Eligius accepts non-standard TXs. I got this result, so I guess it was added to their pool of transactions: Trying to send... array(3) { ["result"]=> string(64) "ce7d73cba662af3dfbd699384111115f4ccd24b3748a88bf9bc70c1cc4d08660" ["error"]=> NULL ["id"]=> string(1) "1" } Response = 0 They find several blocks a day, so I should either see it confirm or find that they didn't actually include it some time soon.
|
|
|
Is it possible that your anti-virus is thinking Armory is a virus and removing it? Try seeing if Avast keeps a history of virus removals.
|
|
|
I'm attempting to spend the output from this thread. I used Bitcoin Core's createrawtransaction, some manual fiddling to add another anyone-spend output (worth 0.0001 this time) and signrawtransaction to create this transaction: 01000000023c25123a6db0122f8987e52afae8835ee521cad7d7b9e2012bd88aae6aedd88700000 0000151ffffffff982e3c5df57e9fb59a397794552b6162b5afb22e45d3f5141ec4c05cbf258fe6 000000006b483045022100bdb2202b620991c98d8d7650219af5ff7762ab0b949fd4c329da4b6e6 97cb59f02201e183c9f3a7780c4dadbe818b22e11922279db615495b7823f2d2527acfc66f70121 03683cff3601cff805af6a43cd49a80f8571e2509643cd7be725aaae498d291ea6ffffffff02803 80100000000001976a9142befe08e305ac175088ad56c5d003bbc041b27bb88ac10270000000000 000000000000 Which, when decoded, is: { "txid": "ce7d73cba662af3dfbd699384111115f4ccd24b3748a88bf9bc70c1cc4d08660", "version": 1, "locktime": 0, "vin": [ { "txid": "87d8ed6aae8ad82b01e2b9d7d7ca21e55e83e8fa2ae587892f12b06d3a12253c", "vout": 0, "scriptSig": { "asm": "1", "hex": "51" }, "sequence": 4294967295 }, { "txid": "e68f25bf5cc0c41e14f5d3452eb2afb562612b559477399ab59f7ef55d3c2e98", "vout": 0, "scriptSig": { "asm": "3045022100bdb2202b620991c98d8d7650219af5ff7762ab0b949fd4c329da4b6e697cb59f02201e183c9f3a7780c4dadbe818b22e11922279db615495b7823f2d2527acfc66f701 03683cff3601cff805af6a43cd49a80f8571e2509643cd7be725aaae498d291ea6", "hex": "483045022100bdb2202b620991c98d8d7650219af5ff7762ab0b949fd4c329da4b6e697cb59f02201e183c9f3a7780c4dadbe818b22e11922279db615495b7823f2d2527acfc66f7012103683cff3601cff805af6a43cd49a80f8571e2509643cd7be725aaae498d291ea6" }, "sequence": 4294967295 } ], "vout": [ { "value": 0.0008, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 2befe08e305ac175088ad56c5d003bbc041b27bb OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a9142befe08e305ac175088ad56c5d003bbc041b27bb88ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "151KRCz9zHfCGJSWUKjwrFUL9oKwJhw4KD" ] } }, { "value": 0.0001, "n": 1, "scriptPubKey": { "asm": "", "hex": "", "type": "nonstandard" } } ] } All seems good so far, but when I try to sendrawtransaction, I get the error:  64: scriptpubkey (code -26) I've also tried submitting through https://blockchain.info/pushtx, which says "Script not of right size, expecting 2 but got 1", and http://blockr.io/tx/push which says "There was an error pushing your transaction to network! Did you sign your transaction? Is this double spend? Have you already sent this transaction?". Can anyone tell me what's wrong here? Are these all rejecting it simply because it's nonstandard, or is there something else wrong with the transaction?
|
|
|
You don't have to include any transactions, although there are incentives (primarily the transaction fees) for you to do so. Some miners don't include transactions, for one reason or another.
It's also possible that the miner didn't hear of any transactions between the time of the last block and when he found his block.
|
|
|
1. Do all transactions of bitcoin form one address to another incur a transaction fee (I think it was half a cent or something)? What about just transferring my BTC to another a friend's address?
Not all transactions require fees, but the rules are kind of complicated. If you want to keep things simple, and maximize the likelihood that your transaction will be included in a block quickly, include the standard fee of 0.0001 BTC (currently ~6 cents) per KB (most transactions are under 1 KB, so usually just 0.0001 BTC). 2. Can you choose 0 confirmations for any transactions (whether as a merchant accepting many transactions, or from 1 address to another address)... and does that make all transactions free?
These things aren't really connected. Accepting transactions with 0 confirmations should only be done when you trust that the sender won't go back on their word. 3. Miners are basically solving puzzles to verify transactions.. and once the transactions are verified they are put in the block chain.. which happens in approx every 10 mins... and at the same time 25 bitcoins are released as a reward to the miners. Is this a proper way of thinking of the process?
Yes, that's a very good summary of it in my opinion. 4. What is this 1MB transaction limit about? Can someone explain what it means and why some people are worried about this limit.
Each block is currently limited to 1MB. A small size helps the block go across the network quickly, which helps prevent orphaned blocks (and DDOS attacks). If two blocks are found as children of the same block (typically because they were found at about the same time, because the network wasn't able to get the first block to the second miner before he found his block), only one of them can become part of the permanent blockchain. The other is ignored, or "orphaned". Keeping the blocks small reduces this window of time, and thus reduces the number of orphans (which are wasted work, and make mining less profitable). This limits the transactions that can be included to around 1000-5000 per 10 minutes. If Bitcoin grows to the point that this is not sufficient during peak times, some transactions will take longer to become confirmed, because they won't fit in the block.
|
|
|
Private keys are integers modulo p (where p = 2^256-2^32-977, as defined in secp256k1). For the sake of an example, let's use a curve where p = 7, and the private keys in question are 4 and 5. Add private keys: 4 + 5 (mod 7) = 9 (mod 7) = 2 (mod 7) Multiply private keys: 4 * 5 (mod 7) = 20 (mod 7) = 6 (mod 7) As you can see, there's really no elliptic curve stuff going on at this point: we're just dealing with adding and multiplying integers in modular arithmetic, which is quite easy.
|
|
|
I made a few tests this morning : with 5 dices it takes less than five minutes to generate a 256 bits key. And not so much noise. The disturbing thing is that the dices don't "look" random. I can see a lot of "patterns" in them : 23423 23451 ... I think it's my imagination...
It's (almost definitely) your imagination. Humans are great at seeing patterns in random data, even when it's just that: random. Compare your data to a true-randomness-generated list at http://www.random.org/dice/?num=50 (this site has high quality true random numbers, not pseudo-random, but it's not a secure thing, so don't try to use it for your crypto/private key) Is there any test to make on the root key before using it ? Are some of them bad/weak ?
To the best of my knowledge, the only weak keys are ones whose addresses happen to correspond to ones with easily-guessed private keys. (e.g. because the private key is 0x000...0002, or comes from a brainwallet passphrase "duck", or from a poor PRNG) The probability of you hitting one of these accidentally is so small it's not practical to worry about it.
|
|
|
My recommendation is to use a deck of cards. Shuffle it to your heart's content, then type in the order of the cards into a string, such as "Ah9d3s3h...". Hash that and use the resulting 32 bytes as your seed. You can use armoryengine to do the conversions: hash256() to hash the string, and "makeSixteenBytesEasy()" to convert each half of the string to a line that can be entered into the wallet restore window. The order of a deck of cards has 225 bits of entropy, which is plenty big enough. I tried the dice thing before, but it's a lot of dice rolls and it makes a lot of noise. The deck of cards is much more pleasant (highly scientific statement here ) Sometimes when I shuffle a deck, the cards are too similar to the original. Dice sounds like a better method to me if you want a great real-world entropy source (and you have the time to spare), especially if you're not experienced at shuffling cards well.
|
|
|
This would make DoS attacks much easier: instead of flooding the network with expensive transactions, you can flood the network with worthless blocks (ones that don't really meet the target difficulty). Since nobody can tell it's invalid before they've received the whole thing, honest nodes will be tricked into relaying the majority of the junk block.
|
|
|
|