Not being able to answer that was why I spent a bunch of time trying to come up with "attacks" that selection of a non-obvious G could yield. But all I could come up with doesn't seem to be too much. ::shrugs::

Not just that, but if there are subgroups there are reductions that allow you to solve the DLP with basically no more work than solving it over a field thats the size of the largest factor.

Your request seems a little backwards.  It's not your obligation to prove an address isn't yours— thats basically impossible— if someone owes you money its their responsibility to prove to you the address they paid was one you gave them.

There have been a bunch of people showing up in IRC in the last couple months with BC.i wallets with stuck double spent transactions from concurrent use. Be careful.

Hm. I would have expected an _underclocking_ service to be more valuable: increase reliability, increase power efficiency.

I absolutely agree that should be done, and I didn't intend this to be an alternative. There are protocols which this suggestion cannot help.

But, I believe it will take a minimum of two years remove malleability.

Fully eliminating malleability requires a soft fork with fairly invasive changes in script validation because you need to catch things like "Push onto the stack that had no effect" and "Used something other than the smallest possible push". It may be difficult to convince some alternative implementers to make these relatively risky changes, since the removal of malleability is only really essential for transaction patterns which are nearly non-existent today (chicken and egg: until the malleability is removed, you can't grow the use of transactions which depend on it not being there).

... and this is assuming that it doesn't turn out that there are any more ways to mutate DSA signatures (e.g. by jointly modifying R and S). Adam Black was very concerned that there were.

In any case, having a workaround means that someone who wants to do something the work around works on has an alternative... and doesn't have to wait for the network to believe their use case is justified.  A simple extortion free escrow for doing instant payments or the like is possible this way with entirely standard transactions.

I've finally come up with a way to exploit ECDSA given control of only the generator.

Basically, you set the generator to some random multiple of an existing "public key". Then you can effectively use the "public key" as the secret for signing arbitrary messages from that "public key".

In quotes because the whole idea of a public key is ill defined if you don't yet have a generator.

Imaging a Bitcoin' where all coins had to be assigned to some pubkey. And lets also imagine that coins in this system expire, to make them unspendable it assigns them to SHA256("expired"). If I can pick G I can set G to SHA256("expired")*N ... and 1/N is now effectively the private key for SHA256("expired")!  So what _looks_ like a nothing up my sleeve address really isn't one, and I can spend those coins.

I don't think this exposes us to any particular risk, since it only works for one key, and we have no nothing up my sleeve pubkeys, and the parameters for our system were fixed before Bitcoin existed.

But if some nice man from the NSA or Certicom claims to have a nothing up his sleeve pubkey for some protocol or another... perhaps you'd be wise to not believe him.

I know a number of people are running bitcoind on odroid U2 http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451 quite successfully.  It's super fast (for an arm), easily 32x faster than the rpi on some workloads, and not terribly expensive either.  Quad core cortex-a9 1.7GHz, 2GB dram.

(Odroid now seems to have a new 4x A15 + 4x A7 system, but I've not yet talked to anyone that has one)

For anti-coercion refund transactions, you actually want them to _not_ be in the mempool... since having them in the mempool will block the legitimate spend. At one point I was going to submit a pull to make penultimate sequence unlocked transaction be non-relayable/mempoolable specifically for that reason, but then we went and made all unlocked transactions non-relayable/mempoolable.

I've helped users many times with self-doublespends when they have stuck transactions that aren't confirming in a timely manner due to low fees. If miners were accepting higher fee replacements these issues wouldn't exist. So I'm quite confident that at the moment they aren't.

I've also never seen a complete patch to produce this behavior and as far as I can tell very very few miners today write their own software.

Thats not true. I don't believe any miners today will accept a later _conflicting_ transaction even if it has a higher fee, except by accident (e.g. restarting their nodes at just the right time).

Some people argue that eventually some miners will do this because its obviously the greedy-rational optimal behavior, and further that because some miners will do it that it should be the default for all in order to reduce avoid incorrect expectations and to facilitate the fee burning solution to double spending.  This argument hasn't yet convinced everyone.

They may not stop at all.  The behavior fixed in BIP50 is non-deterministic. They'll likely stop if they see a reorg of a couple large blocks, but it depends on the minutia of how the database records aligned to page boundaries.

All of those (save BIP50) are reductions in what the network will accept, so they don't break compatibility.

Then you aren't thinking with an adversarial mindset.

The person standing at a till is running a special "deluxe doublespender" wallet, that automatically attempts to double spend every transaction they make according to appropriate preconfigured parameters (like delays, connections to known miners, fees, etc).

And sure, there are plenty of things you can do to cope with or mitigate the risk.  None of them, however, begin with being anything less than completely frank about what the risks are.

No, anything 0.2.9 or higher should work with no more effort than helping it find a peer (ignoring the fact that the BIP50 stuff means that there is a good chance it'll get stuck), prior to 0.2.9 and back to the original release will work so long as you provide a gateway node that will accept the old checksumless version messages.

They do— they trust the peers they speak to more than a regular node does. E.g. if they show unconfirmed transactions they trust their peers to only tell them about valid unconfirmed transactions. When they receive blocks, they trust their peers to only tell them about valid blocks (and failing that, miners to only produce valid blocks. Especially when they display 1-confirmed transactions as "confirmed"). I don't believe _any_ SPV node software has a secure peer discovery implementation either, which is frustrating because they are somewhat more vulnerable to naughty peers.

IIRC electrum connects only to a single server at a time. It's SPV from there out but because it makes a single point of attachment it's pretty vulnerable. It also does no SSL certificate validation.   BitcoinJ wallets are differently bad: They connect to multiple, but they're only what get returned from DNS. Of course, the Bitcoin protocol itself is unauthenticated, so a network attacker near the node can isolate it easily.

Obviously SPV wallets will improve in the future. ... But they are no replacement for full nodes. If it wasn't important for many regular users to run full nodes then we wouldn't need full nodes at all.  When you don't run full nodes you are trusting miners to always follow the rules faithfully— to not steal from the users by inflating the coin, etc.  But if users are not rejecting unfaithful blocks, because they are SPV and can't validate them, what incentive is there for miners to behave quite so faithfully?  Will they watch themselves, mutually distrutful?  Not so clear, because of cloud mining and pooling the majority of hashpower is under the control of approximately 3 people right now. ... and increasing their income would be uniformly beneficial to them.

In classical currencies and banking the people with equivalent trust are the central banks and governments. There are many reasons the behavior of fiat currencies and banking in democratic regimes trustworthy: They are highly regulated, privileged institutions— not anonymous entities like mining— arguably controlled by elected officials.  And yet they are observably not trustworthy, and their lack of trustworthness— the lack of any institution depending on human fallibility— was a motivation for Bitcoin's creation.

But if you leave network security to a handful of self-appointed anonymous miners without the check of tens of thousands of regular users with uncorrelated interests outside of Bitcoin's integrity then the result is something even less trustworthy. I think that Bitcoin's value argument is too weak to be worth keeping it around if it doesn't offer an integrity improvement over the alternatives.

Then perhaps you should read it? It's eight pages long and written in plain English.

At times I want to start banning people from this sub-forum who haven't read it. It is far from answering all questions, but there really is no excuse not to have read it.

IIRC change addresses are. But the unused keypool is not— your very next transaction will invalidate your backup. There is a backup rpc (and menu option) for a reason. Mucking about with keys manually is inadvisable.

Computing power has nothing to do with hardforks.

Hardforks are not a great path to evolution. They're dangerous and potentially coercive. They must be undertaken with the consent of effectively _all_ users. They should be avoided unless there are no other reasonable alternatives.

Although many things have changed and advanced, it's arguable if we've ever had a hardfork or not: Very old nodes can still validate the chain, though they will non-deterministically fail because of semi-hard-forking database management bugs that have been fixed.

Fortunately, we don't have to have hardforks to evolve:  The P2P protocol is a matter between individual peers. They can negotiate whatever options they want. We have replaced the p2p protocol.  Most interesting and important changes to the blockchain validation rules can be accomplished via softforking changes. E.g. P2SH is effectively a radical change in how transaction spending rules are encoded and was accomplished without a hard fork.

In Bitcoin evolution is slow.  There are wallets which cannot be updated because they run on platforms controlled by corporations which are hostile to user-freedom (in particular, there is an i phone wallet app that produces signatures with an invalid encoding). There are multiple implementations of the Bitcoin protocol, but even with the BIP process their implementers have simply declined to implement some functionality, and its lack of universal availability makes it unusable to users. etc. But the system itself is a gigantic moving machine and failure is difficulty— even impossible— to fix, if something goes wrong so it's hard to say that slowness is a bad thing at all. Slowness helps ensures there is understanding and consent and reduces risk.

Anti-malleability is _far_ more complicated than just the S value. We've been slowly working on this in Bitcoin-QT on and off for a year now. There are at five types of malleability that I know of (± allowances for differences in how you might count)... and at the moment I am not entirely sure that it isn't possible to jointly change R and S to mutate DSA in additional ways, though I don't know how to yet.

In any case, using the transaction version to signal a soft forking protocol restriction is almost certainly what should be done.

Nothing much, until the world ends.

It's really really inadvisable to run multiple wallets with the same keys in them. If you manage to make a transaction on one before it learns of a transaction made by the other one you can end up double spending yourself.  This isn't directly a problem, but in doing so you can end up with stuck coins which are then impossible to spend without going and blowing away the history of your wallet.

In general key importation seems to be dangerous for most users, since if they're at all confused about how Bitcoin works under the hood (e.g. if they think the Bitcoin network has 'balances' it maintains) they can easily end up losing coin forever.

By spending the funds out from under it before the refund transaction becomes valid. The refund is nlocktimed so that it will not be valid until the sufficiently far future.  If you get too close to the refund time then there is a possible race and any payment out of the escrow shouldn't be trusted without confirmations.

The refund exists just to prevent the other party from attempting extortion or in case they get hit by a bus... but its locked and not valid until the future. Normally you wouldn't use it... you'd pay them from the escrow, which is safe because it needs their signature too. If you pay them less than the full value of the escrow either the rest is returned to you or paid into a new escrow (which you also get a refund transaction for before announcing).

I've split the thread since we've gone offtopic:

Key management is super-duper important, and also super hard and I certainly agree with the usefulness of finite key lifetimes.

What I've found is that backups are only intuitive if you must backup every time you get a new address (and only then). This unworkable unless you constantly reuse a small number of addresses, and the reuse is itself both bad key management and devastating for privacy.  As soon as you introduce the keypool people are completely confused by the backup requirements, and we get the worst of all worlds: Constant reuse (hurting privacy and preventing old keys from aging out), and missed backups resulting in coin loss.

I think using BIP32 use isn't completely incompatible with good key management though.  E.g. the backup UI could present an option to "Expire old keys after verifying backup" which would create a new additional master seed and save that in the backup.   If you want to be more elaborate, it could automatically make a new master seed right before your backup if the last one was generated more than three months ago... and then have a UI option that lets you switch how old the backups you want to still be good (e.g. which master key its using for new addresses)— it could even have an option to move any remaining funds to new keys.

The important thing here is that it decouples usage patterns from key management. E.g. making 100 txn today shouldn't make your backup expire right away, and then you don't make 100 over the next two years and it doesn't expire.

The above rotation ideas could be triggered by passphrase change, by default. If coupled with a feature to automatically move funds to new addresses it would actually protect users from that falacy.. by making it true.