Here is the aforementioned other threads.

Indeed, reindexing will now work if after the reindex you leave the node running long enough to process the trigger block and the next ~100 blocks. However if more of these transactions get mined it will break again.

It's ~mostly harmless to have the check level down, it just changes the checking at startup. ... it means _if_ you suffer disk corruption your node may eventually produce a bad block if mining or get stuck processing the chain in the future.  That said, after this we may rename the checklevel knob in the next version just to turn it back to the normal level for people who've stuck in this workaround.

0.8.4 had three-ish changes, but they also had at least three weeks of testing (more much more for some of them). Partially this was possible because we were able to keep the bug that triggered the release a secret until publishing the fixed version.  Because of the workaround is basically as good as the fix and factors mentioned above getting a fixed version out is slightly less urgent than it was for the first day after the issue happened, and I'm not inclined to rush out a version which isn't thoroughly tested.

The fix for this is now merged in the git development branch. There will be an updated release soon.

Slowness these days is mostly due to cruddy peers combined with bitcoin's poor handling of cruddy peers. The work in progress for 0.9 (headers first) improves this enormously. (e.g. down to a couple of hours on my DSL test)

Oh, you're flooding the network with unconfirmed transactions and then noticing further sends start taking forever?

The part of coin selection which traverses unconfirmed change has complexity exponential in the amount of unconfirmed coins in your wallet.

To recognize K=11 you do a comparison with a constant.  To recognize K=secret key you do a comparison with a dynamic value.  In either case the operation is the same and you only recognize one possible K. Maybe you can argue that you save a word of memory, but this is a trivial cost.

If you obtain an explicit change address from the user there won't be any confusion or mistakes. And it does reduce privacy— otherwise a third party is still unsure about the ownership of the change, if less unsure than they are about the other outputs.

Are you planning on writing software that does this? if not, the debate is kind of moot.

I just generated 10,000 fine. Are you using a locked wallet and draining your keypool?

Very cool.

Though I'll repeat what I've told alternative implementers,

_Please_ do not mine on this until it at least passes the block tester. Inconsistencies in block validation can result in devastating forks which would be harmful to all Bitcoin users and not just the users of the inconsistent software. This is more of a risk today than it ever was since a majority of mining is just in three hands and so many people use SPV wallets.

This wouldn't have news to us, go look at bitcoin-dev logs around june-july 2011.  I wish you wouldn't have ignored the rest of my message.

It's isomorphic to a majority hashpower DOS attack and an altcoin.  The challenge in saying that its different is that if a majority of hashpower violates the contract then the security assumptions underlying Bitcoin (and any similarly constructed altcoin) are invalid.

Bitcoin is secure if:

(0) Various cryptographic constructs do what they're supposed to.
(1) A majority of the involved computing power behaves honestly (correctly imposed the rules of the contract)
(2) If information is easy/cheap to spread and hard to stifle so that its participants cannot be isolated (including excessive delays) from the honest majority.

And we argue that (1) is probable because faithful behavior is what makes performing computing valuable.

This is a terrible idea. You have to specify the input you want to spend, just specify the address you want change to be assigned to too.

Because you're wrong.

Ignoring potential problems with RNG, K=secret-key is no more a special value than K=11 (or 12 or 13 or any other specific value). All of them result in a trivally identifiable R.

Ignoring RNGs,  you are no more likely to crack ECDSA by recognizing K==secret from R than you are to crack it by recognizing K==11 from R. You're aware that if the attacker knows K they can recover your private key, right?  K doesn't need to be reused to expose you.

Colin Percival is the author of the only recent notable hash-function with significant data-dependent-timing attack problems, so perhaps thats why it's on his brain.

If you have non-memory access related power or timing side channels (e.g. like adders leaking data, which is what would be required for HMAC-SHA512 to leak) then there is going to be no way to avoid the ECDSA point math leaking like crazy. Using non-deterministic DSA does not save you from side channels. Maybe deterministic makes a really side-channel heavy implementation more vulnerable, but people have already demonstrated recovery on devices with randomized DSA, so I am a little skeptical that it matters. Some masking behavior would be fine, but it wouldn't require making the output non-deterministic.

Being hard against an attacker with physical access is very hard, as I mentioned a simple bit error in our the multiply will put you on the twist and the largest prime factor of the order of SECP256k1's twist is only around 2^50.

No, I think this thread is foolish. But RNG's the break and return constant values do happen so I can't honestly say that its completely worthless.  I was trying to make clear that any (however small) value added here is because it detects a faulty rng, not because picking the same value as your private key is actually a threat.

uh wtf is with that novacoin page?  Did the author of that look at how script works at all?

There shouldn't be additional script pushes for this. This should use the existing push opcodes and add new CHECKSIG operators. :-/

There is no network rule that does anything with the transaction versions currently, there is no fork because the consensus algorithm doesn't care if its consistent. The startup database validation cares if the database is correct, however.

I think you need to think through your attack a bit more.

If you are imagining something as simple as "deny all new transactions, mine just blocks committing to MegaBitcoin auxblocks with 21 trillion coins instead" then it would be simple enough for the honest Bitcoin users to ignore blocks with the MegaBitcoin Commitments in them.

So instead I think your attack is a weaker versions of an attack where you merge mine Bitcoin with an altcoin and DOS bitcoin and do all your stuff in your altcoin. At least then it's harder for Bitcoin users to fork off your blocks by their shape.

Of course, if you're using a majority of hashpower to DOS bitcoin you've disprove one of the fundamental security assumptions (arguably the current hashpower distribution is already disproving them, but its not clear how fast that would change if there was an attack) and so what would be the point of your MegaBitcoin?  If you want to trust a cooperating conspiracy, there are far more efficient ways to interact with them for finical purposes.

So really this just sounds like "if you can get a conspiracy of a majority of hashpower you can kill bitcoin" but we've always known that— thats what it said on the tin.

... When I stop having problems with people paying to me on a P2SH address, adopted at the beginning of 2012— you can't send to them in half the clients apps, including ones promoted on Bitcoin.org, or via many popular webwallets or commercial services, even though the change is a couple lines of code and is economically neutral... I might start worrying more about "in practice" more. Experience shows that having some network rules does far less than you might guess.

But whats that even mean exactly?

I had some doofbrained researchers contact me to ask about adding tracking code to Bitcoin to help with their research. I told them to buzz off in perhaps excessively rude terms. If it was some law enforcement, some officer Obie from Stockbridge, Nowhere?  I'd have to resign?

Or maybe those researchers were really government shills (how would I know?) does that mean I'm already free?  ?? ?!? FREE?! IT WAS THAT EASY OMG I'M FREE   FREEEE FREEEEEEE!

This is why we don't have an auto-updater. We should eventually gain some kind of update tool... Without one a lot of people just keep downloading the software and not checking the PGP signatures, and every time they do it they're exposed to getting an exploited version.

The community should absolutely not accept just some tool that lets a single person or even a small number of people rapidly push out replacement software to all the users.  If you want to give the developers of your node software crazy power just in case of emergencies, give them a key that makes it shut off, but don't let them freely push updates.  If I ever come back asking for the ability to rapidly push updates that means I've be replaced by an alien symbiont. (And really: the same for any developer, you'd have to be evil or crazy to want that ability: It makes you a target)

I'd like to see is someday have a system where developers can push an update out and your computer will download it but not install it. And after a minimum delay of a couple days if it gets enough positive signatures and no (or not too many) negative signatures, it will wait a random amount of time (e.g. up to a week) and then start asking you if you'd like to make the upgrade (this way if it's busted you might hear about it or the update may be withdrawn after other people update but before you install it)... obviously you could go and manually trigger the upgrade at any point.  This would give time for a lot of people to review any updates and sound alarms if they found problems. It could also allow us to be very liberal in granting veto access, since the vetos would just make things fall back to a manually triggered install.

Woah woah, you've taken a reasonable point and exaggerated it here. A softforking rule that just denies some kinds of transactions is not the same as having clients that have to accept whole different kinds of invisible bitcoins. You still have to change the client software to be able to see or spend your bloatcoins.

(But then again with 200k users or whatever being on BC.i we can probably just dispense with the blockchain in any case…)

Fortunately since it would take a conspiracy or compromise of at least _three_ people to have control over 50% of Bitcoin's mining hashpower today, so we can be quite confident that such an outcome is completely infeasible.

Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks.