It's ~one line of code to change to do it the simple stupid way. There is actually a patch ready to go sitting on github.  Several large pools have intentionally orphaned a block in the past, so they're already experienced at it.

Please take a step back and consider how you're responding here.  Some people want to post addresses online so an anonymous party can pay them, even when they aren't online.  They can and do currently do this by throwing up a static address.  You are instead saying they need to be online 24/7 and use bitmessage or torchat or any of a bunch of other things that they aren't already using.

You have failed to improve anyone's privacy. With your response practically anyone, including _myself_ would just continue what they've been doing. Good job.

No. The worst he can do is send nothing to 1000 addresses and then someone else sends 100 bitcoins to the next one. Knowing how many addresses gap there are permitted to be is important information!

What if there is no "last transaction"? How else but a lookahead bound to you propose to avoid scanning forever?

The places where mod n is used are not EC operations.

Thanks for the other report: It looks like someone confused edited the page while no one was watching:
https://en.bitcoin.it/w/index.php?title=BIP_0032&diff=40588&oldid=39104

AFAIK The Bc.i message thing is purely local, its not on the network.

Please don't go inventing your own cryptography when it can be avoided.

Scrypt did the work to write up an extensive analysis of their effort, and it was reviewed by many people at great cost. And even then the result has not been totally criticism free (http://eprint.iacr.org/2013/525).

With a quick glance at the shape of your implementation, it could have trivially failed to be memory hard at all had you appended instead of prepending. I expect that it's actually spending all of its time shuffling around strings, and that a gpu implementation of it would still end up being a zillion times faster...

No. The Bitcoin network is a global broadcast medium. The Bitcoin blockchain is a globally replicated authenticated data structure which must be preserved forever. A typical transaction is around 200 bytes in size, so adding an encrypted message would be a substantial increase. Encouraging arbitrary encrypted messages just for ephemeral signaling would adversely impact the scalability of the system.

Commercial encrypted communication software is also more frequently subject to export restrictions which mere authentication is not.

Normally what you do is establish your arrangement with the person you are transacting to in an encrypted channel and do all your communication there. You provide them with a new, never before used address to pay to, and you can recognize the relevant payment by the use of that address.

It was an intentionally trolling thread and off-topic because it wasn't about custom hardware. But not a funny one. I made it funny or least _I_ found it funny. No accounting for taste, I guess.

These sorts of things generally only work in the model where there is some central party to validate the authenticator response (and said central authority has the freedom to steal all your funds without the token), they also don't protect against more sophisticated malware that waits for you to log in and then takes over. (And I've heard reports of this kind of thing being used against mtgox, for example: You think you're yubikey authorizing a withdraw to address A but it's really swapped out the form with address B).

Hardware wallets like Trezor will largely fix this (https://bitcointalk.org/index.php?topic=122438.0).

Be very careful:  We don't know what the world will look like in ten years. Security fixes may make transactions authored today no longer valid.

At a minimum any such transaction should be sighashed anyone can pay so that extra fees could be added in the future, if fees are required to get acceptable transaction processing time.

It's effectively impossible to search for my old posts on the forum via google because my name is on every thread in the subforums I moderate.

LOL. I _fully_ welcome half the hashpower to go try this. I'd love to have twice the mining income again.

Here is a hint: This won't work.  You cannot do this with "51%" of the mining hashpower, nor 90% or whatever. There is no amount of hashpower which is sufficient to accomplish the proposed steps.

An extended public key only lets you see the transactions in the subchain its on. Not all your transactions!

It's not terrible for privacy, its essential for privacy because the alternative is the addresses people put in their signatures/profiles which get automatically scraped and listed on the web.

Instead you give the forum a public chain code for a little stub chain which is used only by the forum, and it replaces those static address.  It's less private than individually giving out addresses, but thats not what its an alternative to.

We've generally called this block discouragement, and it's been proposed not as an attack but as a safer way to implement some kinds miner behavior shaping. E.g. "discouraging"  blocks that we know reorg the chain, or which do not include transactions (when we know our mempool had many). You can google around for it some.

Your name is better.

So now you need a 100,000 address lookahead?

I think you're not following what I'm saying here.

I am saying that FORUM USERS. Like you and I. Can provide the forum with an extended public key so that other forum users can requests addresses for us without making all of those addresses public.

Pre-reserving addresses for every user would require huge lookahead.

Right, but at a minimum we need well defined conventions.

I do wonder about things like griefing a forum donation forum. E.g. I give the forum an extended public key so it can give each donor a fresh address, and then some clown asks for 10000 addresses and never pays.  Writing advice to address this is part of having a good spec for the usage of extended public keys.

I'm unsure. It doesn't communicate anything about the permitted range of the index, just a single index. It doesn't communicate anything about further structure being permitted. (E.g. I might want to allow the forum to generate not just addresses for me, but more extended public keys)

I load paythru.to.

I type president@whitehouse.gov

The site returns "president@whitehouse.gov can be sent bitcoins at 1NCbXKdyo9xhwN9EhLc6jKgtDSFQZ1MAUj"

And you're telling me this isn't an address that you control, but instead it's really a key controlled by the president? AMAZING.

And that if I send coins there, they'll actually be received by he president for sure, and not end up in a black hole or "refunded" to some random address of mine, where I'll never figure out it was a refund vs someone else donating to me? AMAZING.

... In any case, this was all on the OPs topic: You can try to infer out working addresses that way, but its unreliable. And at least several people believe that doing so smacks of the kind of irresponsible behavior that goes along with the moral hazard of handling third party money without enforcement or regulation stronger than reputation.

Sure, but we need an address type that encodes an extended public key that can be handed over.