2012-01-14 911579996 /etc/bitcoin/blk0001.dat
2012-01-15 914759556 /etc/bitcoin/blk0001.dat
2012-01-16 917831173 /etc/bitcoin/blk0001.dat
Still under a gig and growing by just over 3 megs a day. And exporting the wallet is still trivial. In windows, just make a scheduled task to run a .bat file to export the wallet and then use your choice of upload tool. In unix, use crond. |
|
|
|
The crowning moment of writer stupidity was when they actually said an IP address that was incoherent.
That is usually done on purpose, especially with phone numbers. They used 127, the 555 of IP addresses. They didn't need to make it 5 octets long. I haven't watched the episode yet so I have no idea what they actually used. In that case it is a bit absurd  Usually it's using numbers larger than 256. ~29:40 on my copy. "127 zero nine zero one" |
|
|
|
The crowning moment of writer stupidity was when they actually said an IP address that was incoherent.
That is usually done on purpose, especially with phone numbers. They used 127, the 555 of IP addresses. They didn't need to make it 5 octets long. |
|
|
|
|
What the hell are you guys smoking?
|
|
|
|
Why not allow all the implementations to coexist for a while? Different miners/pools can support whatever implementations they want. When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all. Basically, I think we should let the market decide. If one method bloats the chain, require higher fees. If one method introduces a security issue, exclude it.
Because... In this case, Bitcoin is like a car that is easily stolen. That might work for you, but is preventing a lot of other people being interested in it. Not very many people can effectively ensure malware won't get on their system. So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal. In my opinion, rushing things has the potential of causing far more harm than individuals getting their wallets stolen. Introducing a serious security vulnerability into core Bitcoin is incomparably worse than individuals getting their wallets stolen. |
|
|
|
In Satoshi's own words : "The only way to confirm the absence of a transaction is to be aware of all transactions." Transaction pruning appears to contradict this principle. All is fine if I am pruning the transactions myself after having downloaded the unpruned block chain and verified it fully. But if I am accepting a pruned chain from another node, both versions of the tx history shown above are equally believable and I have no way of knowing which is genuine.  So, er, don't do that then. Pruning is intended to be an endpoint operation. Each node must see and verify each block for itself. After that, it can prune local storage, but it can't pass pruned blocks on to other nodes. |
|
|
|
Personally, I like the compromise of P2SH, but with it's own OP code. Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?
Adding an op code is not a problem, satoshi designed this as the intended upgrade path. scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly. As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack. OP_P2SH doesn't have to be OP_EVAL. See here. |
|
|
|
Ok, since none of the options are perfect, how about we try to satisfy everyone with a hybrid solution? How about we just redefine OP_NOP1 to mean "do nothing right now, but if the rest of this script is valid in the normal sense, then unpack the second script and run it too". It'll break old clients, and we have to deal with that, but this way we don't have a special case second code path. Essentially do exactly what P2SH does, but make the recognition explicit with a dedicated opcode, and not implicit. Make it a flag that can only be set by the OP_P2SH opcode and can't be cleared, maybe even make the new opcode trigger an immediate validation failure if found by the second pass interpreter so that people can't try to sneak recursion in with it. So, the default P2SH scriptPubKey would become: scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
|
|
|
|
Assuming a BTC success scenario, anyone care to speculate if it would be better to shift the decimal sooner or later?
Heh. Where have you been? It really looks like everyone wants to speculate about that. Thing is, there is no reason to try to make this a broad decision. In the long run, there will be multiple clients, and each user will be able to decide on the representation that they prefer. |
|
|
|
Exactly what protocol problem is this trying to solve? Is something broken that needs fixing? Or are we talking about 'fixing' something that isn't broken?
Did you read gmaxwell's long post above? I'm guessing he's looking for a TL;DR explanation  That text wall (I did read it) covered an entire page on my 2048x1154 monitor at full screen The short version is that right now the sender has to provide everything up front. Say I want to set up my wallet to require "(A and B) or C" keys. To create a transaction that can only be redeemed in that way, I need to provide three public key hashes, or about 480 bits, which makes for long addresses. It gets worse if I'm a large corporation that wants to require 7 of 13 keys, for example, since then the address is 13*160 bits long. P2SH lets me create my own script, then give only a single 160 bit hash (of my secret script) to someone that wants to pay me. I'm sorta coming around to Luke's side, at least a little. Piuk's reply to me makes it much more clear. I still haven't figured out how OP_CODEHASHCHECK is intended to work, so I wouldn't say that I'm a convert exactly. The problem is that there doesn't seem to be any good way to do this. Anything we do will break old clients, potentially in dangerous ways. Dangerous for the people using them, of course, not the network as a whole (except that one could argue that harming some users harms us all). |
|
|
|
|
There isn't any mechanism for this. You really do have to wait for the old spends to get mined.
|
|
|
|
However, this replacement is far worse: it basically replaces the scripting system Bitcoin is built on with a single special-cased template. I've been trying to figure out your opposition to P2SH for a while now. Your premise seems to be wrong, as far as I can tell, so you are coming to an incorrect conclusion. Your premise, clearly stated here, is that Gavin is trying to replace the current script system. That does not appear to be the case at all. P2SH uses the exact same script system that we've been using all along, the only difference is when the script appears. In the current system, the script is presented to the network when the transaction is created. In P2SH, the script is presented when the transaction is redeemed. There is no other change that I can see. No one is suggesting that we abandon the current scripting system. P2SH actually uses the current system to expand itself. It also enables addresses that correspond to arbitrary protection schemes, rather than needing a new type of special address for every type of recipient wallet. Also, can you try to explain OP_CODEHASHCHECK better? I really can't see what problem it is attempting to solve. |
|
|
|
Ok, I'm not sure I understand this change thing but I can accept it. Can you explain what the addresses on the left are?
Well they are related to change. <snip> Excellent post. Should be required reading for all newbies. But, addresses don't have balances, and spends don't empty addresses. Addresses have keys, and keys have transactions, and transactions have balances. And when you spend, the client selects a subset of transactions to redeem that meet or exceed the spend amount, not a subset of addresses. If you've received multiple transactions to the same address, a spend won't necessarily empty all of them at once. |
|
|
|
That sounds indeed horrible. But is that 20-60 bit thing an implementation issue or is it like that in principle?
Also, the use case is special! The idea is that you create a wallet, ideally on an isolated computer. You create one address. You delete the wallet. You transfer the funds on this address. Not requiring any backup means you can't lose the backup. But if you lose your backed up wallet.dat you're screwed. And after 30+ years, I can imagine many ways a backup can get lost.
For cryonics patient, another consideration applies: What motivation does anyone after 30 or 50 or 80 years have to revive you? But if they know that you (edit:and only you) have access to considerable funds, they do have a motivation. At least you can pay for the procedure, provided Bitcoin develops the way we hope.
It is a conservative (high) estimate of how much entropy would be present in an excellent passphrase. Actually "guess" would be a better word than "estimate" because I pretty much pulled it out of my ass without doing any research, but I would "guess" that nearly no one can remember anything with 60 bits of entropy for 30 years. You should have several backup wallets, in places where you can verify their continued safety frequently. And by frequently, I mean with a period shorter than the expected time to crack the password/passphrase you use. If you ever suspect tampering, make new deep storage wallets with new passphrases, and use an untampered copy of the old wallet to transfer your coins to the new wallets. Finally, pick better storage locations this time around. Oh, and use M*Disc for long term storage. They rock. For extra paranoia, you could set backup copies up in a N of M scheme where you have M parts in different places and someone needs to gather N of them to recover the wallet. Just be careful in your choices of N and M. The cryogenics thing is an interesting twist. But I think it reveals a problem with cryogenics, rather than with bitcoin, to be honest. Personally, I expect to be thawed because someone needs my mad COBOL skills, and not for my financial wealth. |
|
|
|
It seems to me that using a deterministic wallet allows one to delete all wallet data associated with one's account. As long as one remembers the pass phrase, the keys should be recoverable and the Bitcoins should be accessible again, even after a very long time. It seems to me that deterministic wallets are somewhat fringe and every client is using a different, ad hoc algorithm. It might be that the software is no longer available once one needs recreate the keypair, leaving one with the passphrase and no way to recreate the keys. Having this feature in the official client would help. Is that planned?
Eww. Please, no. Deterministic wallets are a horrible idea already, and they just get worse when standardized and widely adopted. With the standard bitcoin client, each address has about 160 bits of security, and are all unrelated so if an attacker can spend some of your money, the rest is safe. With a deterministic wallet, each address has ~20-60 bits of security, and are all related, so if an attacker can spend some of your money, they can spend all of it. |
|
|
|
|
I would just use bitcoin.
The local thing is pretty silly. If people need encouragement to use local merchants, the local merchants are doing something wrong and need to shape up. Also, if your local currency catches on, you will have huge problems with counterfeiting unless you put some effort into making them hard to copy. Better to just use bitcoin.
|
|
|
|
If i was a bad guy, and saw that it is almost impossible to steal bitcoin,
I would try to destroy other people's bitcoin
by erasing wallets or uninstalling or whatever.
There will be some people that will not make backups of their wallets.
No one will lose a wallet without a backup twice. And my hat is off to anyone that can find my long term storage wallet burned to several M*Disc DVDs and erase them all. |
|
|
|
The only cryptographic algo that is provablely secure from brute force forever is the simple Vernon Cypher, which has no applications here.
Is that known by another name? Searching Google and Wikipedia for "vernon cypher" didn't return useful results. It is a one time pad. It requires one bit of key for each bit of message, and no key bits are related so all potential decodes are equally likely. Just make sure that the key bits really are unrelated. That is, you must a have a real source of randomness like a geiger counter, not just pseudorandomness, otherwise the PRNG seed is the real key. |
|
|
|
SHA-256 is big. Far bigger than most people can comprehend. It won't be brute forced. Not today, not in a century. The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things. SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.
Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else? The private key is a 256 bit random number, the public key is derived from that random number. His discussion is still totally valid, since he is really talking about any 256 bit keyspace. It is even more valid since you don't have to recover the original private key, just any private key that corresponds to one of the public keys in the chain. |
|
|
|
If we ever expand beyond the current 64 bit integer representation of 1e-8 BTC, then mining could go on for quite a while, if I recall correctly. I'll poke through the source code in a bit, but if I recall, the subsidy is right shifted off the end until it goes to zero. Switching to 128 bit integers would let it keep shifting off longer than the current setup. Of course, we are talking about tiny amounts, even with massive deflation.
int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
Yup, the subsidy is right-shifted out (without carry). Which means that the end of the subsidy depends on the size of the integer we are using. So, unless there is a further code change, the subsidy will last about 128 more years (4 * log 2 50E+8). An expansion to 128 bit integers will give roughly 64 more shifts, or about 256 more years. This would have a negligible impact on the total amount of coins. Actually, we are really only using the bottom 51 bits right now, so if we are changing formats, we could change the pseudo-mantissa from 10e-8 to 10e-30 rather than 10e-17. 21,000,000 * 10^30 just barely allows exact representation in 127 bits (allowing signed math). If we want to contemplate projects with costs that are many multiples of the total amount of money in the world (which isn't as silly as it sounds), but still allow them to use 128 bit signed representation, we could pick 10e-24 or 10e-21. Oh, but the value of the subsidy starting in block 2,310,000 will be different in 128 bits than it is in 64 bits. So, we really should plan how we want to expand sometime in the next 30 years or so. Sorry, this is mostly off topic, but interesting. I sometimes get carried away when I calculate. |
|
|
|
|
Show Posts
