This can already happen, say, if a person has a copy of their wallet on their Linux partition and another on their Windows partition. If you spend the money on the Linux partition, and then a few days later boot to Windows, it will appear you are richer than you are until the blocks all download.
... and that's exactly why I discourage people from doing things like that. It is too easy for two "copies" of a wallet to get out-of-sync. You have to be a geek and muck around with copying the wallet.dat file from one place to another to get into trouble, and that is by design. I have no problem at all with geeky tools that let you do dangerous things (like PyWallet). The JSON-RPC interface is trickier, because adding dangerous functionality there might encourage web services to do not-so-smart things like sending private keys over unencrypted/unprotected channels ("Email the private key as a Christmas gift" works great for a while, and then the bad guys start looking for privkeys in traffic they're sniffing and spend them before your Dad can....) |
|
|
|
.... If a deterministic wallet is used then the computation and software complexity/trustworthyness requirements are significant.
I only half-paid-attention to all the previous deterministic wallet discussions, but isn't it pretty simple? Start with a random private key and a random nonce. ECC multiply the key by SHA256(nonce+n) to get the n'th derived key. (I think you could even get away with using the private key as the nonce) (and, of course, I defer to the expertise of people who know way more about ECC crypto than I do) There's also the question of key management for the WPS. Would they issue one key for all their customers, one key per customer or one key per transaction? Every different WPS key either needs to be securely stored separately or else sent to the offline device to be logged. If stored separately there's another secure storage problem and there may be a problem matching up the WPS key with the user's keys if the WPS disappears. If sent to the offline device then that's another infection vector, storage and key matching problem.
It seems to me these issues will be the same no matter what solution is implemented. I agree that the problems can be somewhat mitigated through the use of deterministic wallets but unless deterministic wallet operation is standardized before "2-of-3" solutions go online then it's going to be chaos when people try setting up and using WPSs with various behaviours.
I think the next step is starting to prototype and standardize a protocol for communicating with WPS or escrow services to request new public keys, get keys signed, etc. Supporting deterministic wallet schemes at the same time makes sense, in my humble opinion. I imagine an API call that is something like "I'm customer gavin@acm.org. Please use whatever private key you're storing for me and this 256-bit number to derive a new public key, and send it back to me." (details to be worked out, but note that the WPS wouldn't necessarily have to store that new keypair if the "Please sign" request included the same ( gavin@acm.org,256-bit-number) ....) It will be difficult to ensure that the standard client can interoperate with different WPSs if they distribute keys or implement deterministic wallets in different ways.
As long as the API is consistent, I don't think the details of the deterministic wallet matter. You might imagine that similar concerns operate with the "or C" solution. The situation is considerably better as the standard client can always ensure that the transactions are recoverable irrespective of the operation of the WPS. This means that the issue of recovering transactions is orthogonal to the WPS implementation whereas in the "2-of-3" solution, they are intimately bound together.
I don't see the difference: if the WPS becomes unavailable, then either solution requires that the "C" key be transferred from paper (or wherever) to the online client. |
|
|
|
I spent some time today looking again at the state of quantum computing: I'm still not worried. The D-Wave system is not a general-purpose quantum computer; it is pretty specialized for solving certain problems (I'm reasonably certain cracking ECDSA encryption is not one of the problems it would be good at, but I am definitely NOT a quantum crypto expert). Skimming the research, it looks like you'd need a specially-constructed quantum computer with 515 qbits and over 100million quantum gates, running more than 16 million quantum operations to crack Bitcoin's 256-bit ECDSA private keys using Shor's algorithm. There's was a good reality-check article in the New York Times just last week: http://www.nytimes.com/2011/12/06/science/scott-aaronson-quantum-computing-promises-new-insights.htmlUnfortunately, while small quantum computations have already been demonstrated in the lab, they typically fall apart after only a few dozen operations. That’s why one of the most-celebrated quantum computations to date has been to factor 15 into 3 times 5 — with high statistical confidence! The problem is decoherence: basically, stray interactions that intrude prematurely on the computer’s fragile quantum state, “collapsing” it like a soufflé. In theory, it ought to be possible to reduce decoherence to a level where error-correction techniques could render its remaining effects insignificant. But experimentalists seem nowhere near that critical level yet. I've said it before: I'll start to worry when quantum computers can factor 64-bit numbers. |
|
|
|
If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.
Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way. The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time). For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept. It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work? |
|
|
|
|
I like "sweep" -- it has very clear semantics that I think users will understand: "Take all the funds that were sent THERE, and send them to me RIGHT NOW."
Automatic sweep-every-once-in-a-while functionality would be fine, as long as it was coded properly (sweeps should only be done if you have the full block-chain, not if you're busy catching up, and shouldn't be done immediately to avoid a flurry of accidental double-spends if you have several wallets setup to sweep the same key(s)).
I don't like "import" -- it has muddy semantics that I think users will not understand. "You kind-of-sort-of own the funds that were sent THERE, unless somebody else happens to have a copy of THERE that you may or may not know about."
Import is bad because it can lead to a situation like:
Start up bitcoin, see you have 1 BTC in your wallet (sent to an imported private key in block 111,000)
So you send half of it to your friend to pay for lunch.
... bitcoin chugs away, and it turns out that 1BTC was spent already, in block 190,000.
User is all "wtf??? where did my BTC go???"
If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.
|
|
|
|
In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.
So what happens when two users import the same private key into their wallets? (or you accidently or on-purpose import the same private key into two of your wallets?) You can say "Don't Do That", but if they CAN do that, then they WILL. |
|
|
|
Anything I'm missing here?
... if you're sending a transaction, then its timestamp should be the time it is sent. And coinbase transactions should be assigned the block timestamp. I think. It is odd that different machines may assign the same transaction different timestamps... |
|
|
|
|
I'll be uploading Release Candidate 2 binaries this afternoon, with two bug fixes from RC1 (text was being truncated in the wallet passphrase dialog box, and previous versions of bitcoin-qt did not display "alert" messages).
|
|
|
|
I dont' see the OP_EVAL nor OP_NOP1 in this block ?
And how many pools is supporting this "OP_EVAL"?
These bytes at the end of the coinbase: 074f505f4556414c ... are the 7-character string "OP_EVAL" (07 is the length, 4f is the letter O, etc). There are no OP_EVAL transactions in that block; it isn't safe to send OP_EVAL transactions until after a majority of miners support it. I believe Eligius is the only pool supporting OP_EVAL right now; Tycho of DeepBit has finished integrating the backport and has said he'll start supporting it after more testing, before the end of this month. Last I heard slush was also working on supporting it. |
|
|
|
Please help sanity test version 0.5.1 release candidate 1. Why a version 0.5.1 ? To fix the bugs listed below before starting on 0.6 release candidate testing. After doing some testnet testing to make sure it works properly, I plan on using the "alert" system built in to the client to warn 0.4 users that if they have an encrypted wallet they need to upgrade to be secure.
Bitcoin version 0.5.1 release candidate 1 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/test/This is a bugfix-only release. This release includes 13 translations, including 5 new translations: Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese. More translations are welcome; join the project at Transifex if you can help: https://www.transifex.net/projects/p/bitcoin/Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesProject source code is hosted at github; we are no longer distributing .tar.gz files here, you can get them directly from github: https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type sudo apt-add-repository ppa:bitcoin/bitcoin in your terminal, then install the bitcoin-qt package. BUG FIXES --------- Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 release binaries). The code that finds peers via "dns seeds" no longer stops bitcoin startup if one of the dns seed machines is down. Tooltips on the transaction list view were rendering incorrectly (as black boxes or with a transparent background). Prevent a denial-of-service attack involving flooding a bitcoin node with orphan blocks. The wallet passphrase dialog now warns you if the caps lock key was pressed. Improved searching in addresses and labels in bitcoin-qt. =============================== Thanks to everybody who contributed code or helped test this release: Alex B Clark Gaebel Dylan Noblesmith Gavin Andresen Luke Dashjr Matt Corallo Michael Hendricks Nick Bosma Nils Schneider Wladimir J. van der Laan |
|
|
|
Here's how to figure it out from the Satoshi client code: The IMPLEMENT_SERIALIZE macro is used to both store transactions on disk and to serialize them into a byte-array that can be hashed. For class CTransaction, that looks like: IMPLEMENT_SERIALIZE
(
READWRITE(this->nVersion);
nVersion = this->nVersion;
READWRITE(vin);
READWRITE(vout);
READWRITE(nLockTime);
)
READWRITE is a wrapper that is overloaded to Do The Right Thing for all the types bitcoin deals with; for complex types like CTxOut, IMPLEMENT_SERIALIZE is (essentially) called recursively. Expand out all of the types and, assuming I didn't screw up (always an iffy assumption), it looks like a CTransaction is serialized as: nVersion
vin.size (vectors are serialized as a compressed count immediately followed by their contents)
vin[].prevout (vin->prevout->hash followed immediately by vin->prevout->n, as 36 bytes)
vin[].scriptSig (CScripts are serialized as a vector of bytes)
vin[].nSequence
... repeated for each vin
vout.size
vout[].nValue
vout[].scriptPubKey
... repeated for each vout
nLockTime
String all those bytes together, SHA256 them twice, and you should get the transaction hash for the merkle chain. |
|
|
|
|
Can we come up with a scheme that uses 2-of-3 that solves the problem?
Key 1 is the Wallet Protection Service Key. Your wallet only knows the public half of that key.
Create two random keys, Key 2 and Key 3, offline. Save them, they're needed for backup.
Transfer the private part of Key 2 and just the public half of Key 3 to the online wallet.
The wallet can generate the 2-of-3 required bitcoin payment address (it has all 3 public keys), but can only sign for Key 2.
Normally, it will ask the wallet protection service to sign for Key 1.
If the WPS goes out of business, the private key for Key3 can be imported and the wallet will be able to spend without the WPS.
If the online wallet gets lost AND the WPS goes out of business, then Key2 and Key3 can be restored from the offline backup.
If you care about privacy and want to make it harder for people to track your transactions, then you could implement a deterministic key scheme on top of all of that-- start with keys 1, 2 and 3 and ECC multiply them by some random number to get derived keys. The random number would need to be stored with the backup, in the online wallet, and sent to the wallet protection service, but that's OK because you need the random number plus 2 of the 3 secret keys to spend the coins.
|
|
|
|
I've not seen any way to resolve the problems with my original proposal; it seems too easy to use a large amount of cash to reach back arbitrarily far in the block chain to re-write history (and hence, invalidate transactions where you spent money).
... or, even worse, invalidate competing proof-of-stakes. I might like proof-of-stake schemes better if somebody has a good plan for how to get them started-- you've got a genesis block, so the creator starts with 100% stake. Now what, exactly, happens to create block number 2 for proof-of-stake systems? |
|
|
|
If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.
+1 |
|
|
|
|
So netrin:
I asked before and I'll ask again, I'm genuinely curious:
Are there password-cracking algorithms that attempt passwords from lowest-entropy-to-highest-entropy?
Is it even theoretically possible to sort passwords by "entropy" ? (seems like a hard thing to easily measure; password "a.b..c...d....e.....f" has low entropy, but would any password-cracking algorithm try it before 6 random characters?)
|
|
|
|
|
Neat idea!
I don't get the economics of it, though-- how do I convince the network to run/check the calculations I want the MerkleWeb to run rather than somebody else's? And does anything prevent me from asking the MerkleWeb to do some useless busy-work that is just designed to chew up computing resources? Who decides what gets run on the Turing machine, when?
|
|
|
|
Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all.
small question... is that possible ? Sure-- it has to be possible, there is no guarantee that you'll see blocks announced on the network in order. An orphan block may just be one that you can't connect to the main chain yet because you haven't seen it's parent yet (maybe you're downloading blocks and haven't got them all yet, or maybe a miner got lucky and only needed eleven hashes to build on a block and you see her block before the parent because of network delays). |
|
|
|
I dont understand this: How do we know if the block is coming from a misbehaving client (eg which sends "orphan" blocks on purpose), or a block that comes from a slow miner, so the block cannot go into the blockchain because that node was too slow and another node was first, and thus that block becomes orphan?
The misbehaving client creates orphan blocks with very low proof-of-work; the unlucky miner creates orphan blocks with valid proof-of-work. The misbehaving client gets away with their misbehavior by either anchoring their bogus blocks deep in the chain, when blocks had very easy proof-of-work. Or giving them a bogus "previous block hash" so they're not anchored anywhere in the chain at all. |
|
|
|
https://github.com/bitcoin/bitcoin/pull/686Testnet difficulty calculation changes, to take effect Jan 1 2012Allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. Normal rules apply every 2016 blocks, though, so there may be a very-slow-to-confirm block at the difficulty-adjustment blocks (once per month, assuming testnet is in it's normal "difficulty too high for number of people mining it" state). This will almost certainly cause a testnet blockchain split after Jan 1. After pulling I'll update the Testnet Faucet, I'll ask theymos if he can update the testnet block explorer bitcoind. I didn't implement any "shun blocks from the future" or "prefer blocks with more memory-pool transactions", I want to see how well the simplest-thing-that-might-possibly-work solution works first.
|
|
|
|
|
Show Posts
