Exactly.


Luke is talking about block withholding. We know how to fix it for centralized pools in an incompatible way— as luke points out, though not for fully decentralized pools.


Even most SHA256 "breaks" would not necessitate or justify a POW change (though might require the replacement of SHA256 _everywhere else_ in the protocol). E.g. the existent breaks for MD5 wouldn't make us move away from an MD5 POW if we were using it for that.

As Luke says, there could be reasons to justify altering the POW, but they're not things that would come quietly or subtly.   E.g. things like an active monopolizing super-majority attacker on the current POW.  Breaking everything is justified when the alternative is everything being even more broken, but not otherwise.

Or, potentially fictitious income.

A plan for extreme profit:
(1) Create highly blockchain visible service
(2) Use it yourself in high volume to create the appearance of large income
(3) Raise 34500 BTC from selling shares in an IPO
(4) PROFIT!

I don't have any reason to believe this to be the case here— beyond a remaining flicker of hope that so many of my fellow men are not actually stupid enough to throw away thousands of BTC on what is apparently the least entertaining gambling site ever created— but nor can I exclude that possibility from the data made available.

Caveat Emptor.

We do want that functionality, mostly to make it so that users using the raw transaction api can mix it with regular wallet usage without stepping on themselves.


This is very much incompatible with how encryption in Bitcoin works today. And I think we'd be unlikely to accept patches to change it to make that work.

Today there is a master key which is used to encrypt all the private keys, and the master key is encrypted with a KDF expanded passphrase from the user. This makes it possible to change the passphrase without rewriting all the private key material.

It's also important to note that bitcoin's account feature is __NOT__ multiple wallets, spending from any account can spend any coins, including ones that were previously paid to another account.


If you make use of a private key then someone going through memory could get a copy of it, end of story.

What you are asking for could be accomplished via the raw transaction API, but you'd end up having to implement all of the wallet functionality in your own code. It could also be accomplished through multi-wallet support, which is something that I think we want long term but isn't being directly worked on right now.

But I think what you actually want really involves multisig or at least client side signing... because without that a sever compromise still results in compromising at least the private keys that get used during the compromise.

You've basically got it. You don't need to dump or provide the private key: Those parameters are optional— they're used for cases where the relevant keys aren't in your local wallet.

Here are some quick walk-throughs I'm working on that use this api:

https://people.xiph.org/~greg/escrowexample.txt
https://people.xiph.org/~greg/signdemo.txt

Thats not the official git repository, thats gavin's staging repository for pull requests.

The official one is https://github.com/bitcoin/bitcoin/ and it's linked from the bitcoin.org site.

The RPC is getrawtransaction (no s).

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.