Run bitcoin from get.  Use getrawtransaction with the decode flag.

Because they are generally a terrible thing. Terribleness of checkpoints is mitigated by the fact that we never place a checkpoint except in the far past where there is no chance of a legitimate competing fork existing (legitimate meaning the product of the honest community of bitcoin participants, rather than attackers trying to rewrite history in order to commit fraud). If any client developers try to push a recent checkpoint the community better insist on a double darn good reason; because when checkpoints are used to decide between competing legit chains they're a violation of the decentralized design.

Why have them at all?  They cheaply mitigate a number of stupid DOS attacks (including, probably, some yet undiscovered DOS attacks), and they reduce some new node bootstrapping isolation attacks to the problem of getting a good copy of the software.  These justify having them.  That they also add additional uncertainty/risk to someone trying to make a deep fork in secret is just a bonus.

And during that time newer software _might_ be deployed that happens to move a checkpoint past the point where they decided to fork, even if we don't know about the impending attack.  When that happens the attack would be pointless and all those resources wasted— a very risky gamble.   And even if it didn't happen, a 6-month dee out-of-the-blue reorg would be obviously rejected by the Bitcoin using community; even after the fact people would gladly accept a checkpoint that killed it. This would reduce the damage from the reorganization to a dramafest, some moderate denial of service, and some small window of theft for transactions which get double spent on the tip of the reorged chain and accepted by people who haven't heard the news.

Personally I don't lose even a moment of sleep worrying about deep reorganizations, and I don't think you should either.

Why are we still responding to this explicitly trolling thread?

And also doesn't give you any assurance that the delivered good is as described, except via witholding— which can still be done if the good is as described: holdup / extortion: "Thanks for the car, if you want me to release the payment you'll need to prepare a transaction returning half of it, cheers!".  If you just want to have sender locked transactions you simply use a two of two output, or a plain hash locked transaction, absolutely no need for ZKP or anything fancy.

Right— but why not require that both be provided to decode the private key?

Address:
Passphrase:
Privatekey:


Right, Addr+privkey is smaller than addr+privkey+salt.



32 bits of address are still way better for error detection than 16 bits of CRC under most error models.

I'd still rather use the whole address, but this isn't sounding so bad.... now, using a good KDF instead?

You can do more impressive things with ZNPs, https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked

But it's all just armwaving unless someone bothers writing code to actually do something useful that way.

Yes, I'm well aware of it— but practical usage will want to include the address too— or you won't be able to tell which encrypted key is which and which you currently need without decrypting them.

"largely impossible", no— well, totally salted it's still unhappily possible especially with the CRC giving you a ~2^16 speedup and such a fast cracking friendly KDF. But, yes, it would largely remove batch and precomputation speedup.   Though a 32 bit random salt takes up more space than an address they you'd be sending anyways. Using the address also gives you absolute correctness confidence, but without giving any speedup at all (its soundly on the expensive side of the KDF).

Please don't submit a BIP for an encryption scheme which is unsalted and uses a weak KDF on user supplied passwords. Especially don't do this with a fast error detection value.

Far less importantly, If there is an error detection value at all, it really should be large enough that errors are very unlikely to make it through— "everything works" and "only the right values work" are both reasonable from a UI perspective (though the latter is much better).  "Unlikely, but likely enough that people will still hit it" is very confusing in practice.

Use of the resulting public address as the salt kills two birds with one stone, since it lets you keep track of which is which before decrypting them, so perhaps you should consider that?

How did you end up with that?

The rule nodes apply is MINFEE per KB, so no a single 0.0005 fee wouldn't help you. A single fee works when creating many tiny outputs.

I stopped reading at this point.   Ten years of headers is about 40 megabytes. One hundred years is 400 megabytes. A boring computer _today_ could validate 100 years of headers in a second or two. And even this could be skipped up to a fixed reference point. There are interesting challenges in Bitcoin, reading headers isn't one of them.

Also, from this discussion it sounds like some people are confused wrt difficulty. The difficulty of a block is its target, not the hash value.

No. It wouldn't.  Anyone making a real effort to crack private keys would have dictionaries in every language, including Klingon.  In almost every post people underestimate what the attacker will do. Here is a hint: If you think to say that he won't do something, then in fact he will think of it too and some will eventually do it— unless he simply can't, and getting more/larger dictonaries is something anyone can do. He will do things you can't even imagine.

You must defend against all attackers, now and in the future. An attacker can find any victim, and with the same effort of attacking one victim he attacks all. The economics of these attacks strongly favor the attacker.  The only way to have reasonable confidence is to move things into the realm of cant: e.g. having tractable strong entropy and accepting reasonable upper bounds on the sum total energy expendable by all attackers on computation you can say an attacker _can't_ crack a key with greater than negligible probability.

It's excellent but:  It's presuming e.g. bruteforcing a website where the site effectively rate limits the attempt.  His impossible to crack passwork at 1000 attempts per second is only a few hours work on a GPU cracker that does a billion attempts per second in an offline attack. So people should be careful not to carelessly generalize the conclusions there.

The only sane approach for a threat model where the attacker can mount a fast offline attack is to use a strong CSPRNG to generate 128 bits or so of random data.. then convert that to some thing you feel like typing be it 'random' letters words from some dictionary, etc.  And... much of the time its perfectly fine to write it down, broken into two parts if you like— because the attackers that matter today are mostly in places far far away from you.

The kind of advice often given for passwords commonly gets people exploited. You think you're being quite clever using ")qww!83w" but this an every other clever scheme you can imagine can be easily generated by the cracking tools. You think you're being quite clever using "What all agree upon is probably right; what no two agree in most probably is wrong" but a fast GPU attack can scan through every phrase in a whole library of books in short order.  Actually random is safe, anything else is guesswork and hoping that the sum of all attackers over all the future is less smart than you in this instant. — especially for something like private key material where there is no strengthening, and where an attacker attacks all users with almost O(1) effort.

Not a new idea and the flooding problem has a solution too, e.g. http://sourceforge.net/mailarchive/message.php?msg_id=27901281

Ideas are cheap. Got code?  

Though this provides no protection against finny attacks.

Imagine a mining pool. You have shares— they're really all failed blocks, they still have hashes that connect down to the transactions so you can show that the shares were an attempt to mine a particular transaction.

Now, add an extra hash to the coinbase, like merged mining, except its the hash of a prior share (of at least some difficulty). Bam. Now you have a share chain.   You can use this for a byzantine consensus of who's putting how much hash power into the pool. This is what p2pool does— nodes share shares with the difficulty adjusted so that on average there is one per ten seconds. They use this to decide who gets paid and they impose some validity rules on the candidate blocks before they'll be considered valid shares, e.g. that they pay the right people relative to the share chain consensus.

There is no reason that the validity rules can't include something like "your block must include txn XXX" where XXX is some txn that previously made it into the share chain with enough fees and without yet being conflicted in the bitcoin chain.  Then the sharechain itself is proof of past, current, and future effort being put into mining a transaction, as leaving out that txn would prevent you from getting paid by the pool, and you can easily extract this proof and show others. No signature validations either, just a bunch of small headers and cheap hash operations.

A centralized pool could generate such a sharechain itself internally— although if the pool was the only participant in a particular share chain there wouldn't be an incentive to not drop the txn out prematurely, so it's only evidence of past effort.  To improve on that centralized pools could participate in sharechains among themselves (probably slower, e.g. 1 minute, for latency reasons), meta-pooling their payouts and providing more trustworthy evidence of future effort (and lowering their variance too, I suppose).

There is a very long and detailed 'comment' in the code that documents the design and much of the rationale behind it.

Everything it does it does in order to bound the maximum store for addresses (so an attacker can't flood you to run you out of disk), while preserving the most useful addresses, and while making it difficult for an attacker to replace all your addresses with nodes he controls.

This appears to have scalability and security problems. From a scalability perspective unless mining is highly centralized you must communicate with many parties or process many signatures.  From a security perspective a miner signing saying they'll mine a transaction doesn't actually prove that they're even trying to do so or force them to continue trying (e.g. if a higher fee comes along).

Instead, I point out that P2Pool's sharechain approach already solves this.  Right now the included txn in p2pool shares can change freely, but in order to enable 10 second soft confirmations it would be perfectly possible for p2pool (or a similar system) to commit to some transactions (e.g. ones with sufficient fees) which can't be removed without making their shares get ignored.

This has the property that the proof of confirmation is actually also proof of really trying... and it doesn't have the same scale problem in the case of decenteralized miners where there are many possible ones. It could be done by existing pools for the pure confirmation purpose but there would be no incentive to participate other than providing faster confirmations and then defection is easy. When the shares are used for payout, however, there is a good incentive not to defect.

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

You still have to have the complete data that you would remove. E.g. when I spend txn X,  I don't specify all of X's data to spend it (thats burried elsewhere in the chain) only the hash. Order invariant wouldn't let me recover that. I need some kind of undo data, even if its just the location of the original txn so that I could fetch it. (though more efficient if you can serve me up a whole undo block)

One recent revelation I've had as a result of Pieter's ultraprune implementation is that any tree commitment scheme should also commit to undo logs so that nodes don't necessarily have to all individually store all the data required to reorg forever.

You usually work with the parties responsible for the thing you're reporting against and take whatever timeline they ask for, unless they're unresponsive or completely unrealistic.  As an ethical party your duty is to minimize harm, and harm is minimized when things go in an orderly and well coordinated fashion, though harm is not minimized if the vulnerabilities are not fixed so it's also not unreasonable to hold software distributor's (or site operators) feet to the fire if they're not being earnestly responsive.

Fourteen days is more than enough for somethings and far to short a time for others— it depends on how complicated the fixes are, how difficult the deployment will be, the resources available to fix the issue, what the risk of exploitation will be both before and after the disclosure and the amount of damage done. Communicate carefully, listen, and keep the good of the world in mind.

If changes in usage resulted in centralization of validation it would 'destroy' Bitcoin. No, it wouldn't stop existing— but it would stop having a point. We have other ways to have centralized money and Bitcoin isn't an especially efficient one.

However…


Technology like pruning and txout trees are things which _prevent_ centralization. What you're saying above right now applies much more strongly to block validation then they do to storage.  Storage has been growing at a rate faster than moore's law and slow nearline storage is very inexpensive. At home I already have enough storage for about 100 years of the current maximum blockchain growth.  But timely validation is much more costly and there is a risk of a tragedy of the commons on performing it and everyone moving to centeralized webwallets or lite nodes that trust other nodes to be honest.  Technologies that minimize the cost of fully validating nodes are not a threat, they are potentially a salvation.

(In particular: it's already trivial to mine without having the history— all of these centralized pool miners are doing so already, and unless you're using P2Pool, bitpenny, eligius-gmp, or solo mining you are guilty of it too, so these improvements don't create new ways of being anti-social)

I'm not too worried about your concern because the cost of storage is reasonably cheap, and preservation of the data is valuable for many reasons and not just preserving the autonomous trust-freeness of the system— e.g. historical, contractual, investigative, and academic reasons. But the autonomous validation is probably enough incentive alone, after all the whole Bitcoin system was created in order to have that property.

In addition to that it's possible to retain strong confidence of trustworthyness in even in an environment where many people don't have access to the long ago historical data— I suggested an idea I call "proof of treachery" on the Bitcoin-dev list:

If the rules are violated in a chain someone who observes the violation can copy out the minimum necessary data to _PROVE_ that a violation happened (which is always small: it's no more than two conflicting transactions or one bad-signature transaction, and the hash trees that connect them to the header) they can then broadcast these proofs and any node— even one without the history can see and understand the proof just on a purely 'mathematical' basis— without trust and then completely reject any chain following the point of treachery, even if that point was long before the history they have.  Because information is hard to stifle so long as there was at least _one_ honest node that observed the cheating it would be reliably defeated.  That is not quite as good as "you checked for yourself", but Bitcoin doesn't quite achieve that even with access to the whole history because someone could have potentially concealed an alternative history from you (e.g. there is another longer chain but no one has told you about it) so Bitcoin's autonomy already depends on it being too hard to effectively conceal the truth from nodes for too long. Plus, a proof of treachery is much smaller and more easily passed than a block (and it's origin more easily concealed from someone who would want to suppress it).

So I think so long as we build all these paranoid little tools that preserve the vision of Bitcoin and act with thoughtfulness and care when making adjustments to improve scalability which might result in centralization then Bitcoin will do just fine.