Okay, this still doesn't prevent the issuing of extended public keys being orthogonal with the gap problem.

On this point you now have to weigh the privacy vs reduced unzip attack security. I don't expect people to actually do what you're suggesting, especially since there is also the alternative of just asking for multiple addresses from the webserver (which also works for your application even where there is no public derivation available).  We're also taking a tradeoff of increased ecosystem dependance on the possibility of public derivation when you we do that, which I think is unfortunate as it'll be incompatible with any other cryptosystems bitcoin adds in the future.

As an aside, I note that if you invoke petertodd's take on cut-through payments you get the quadratic gap problem.

It doesn't matter if the customer is given an extended public key or a regular address. In fact, in the worst case the additional level of indirection makes the gapping problem quadratically worse, though if you allow no gaping of the leaf chain it's merely no better (because there can be gaps between customers who have successfully paid).  Nor is there a need to give customers in many cases an extended public key such as when there is no reoccurring payment relationship. (and avoiding doing so avoids disclosing a chaining code, thus reducing your exposure to the unzip attack should a private key get disclosed).

So you are just willfully ignoring a use case used by thousands of people, one which likely dwarfs many of the reoccurring payment applications... and instead propose a solution which doesn't need BIP32 at all, which works fine today, and which people _do not use_ because it is too costly relative to the privacy provided.  I don't think anyone would be at danger of not realizing that the forum would know about forum issued addresses, but even if they were— the alternative you propose can already be used and observably isn't in very many cases.

I believe you're allowing your dislike of third party delegation to blind you to all forms of delegation.  I run a website on a not very secure VPS. I would rather it not be the case that someone who compromises the VPS be able to steal all the funds. So I delegate an extended public key to the VPS to allow it to compute new addresses for payments, the spending of which is handled by an entirely air gapped wallet.  Because some people may fail to pay the usage may be sparse, and you can not depend on advancing only to the next unused address or payments will be missed.

If you start to respond that my VPS would be a honey pot and I shouldn't have an extended public key on anything which isn't completely secure, please just don't reply. If you have an issue with one of the design objectives of BIP32 then please feel free to ignore that objective completely.  Other people live in a world where security involves complicated tradeoffs and are going to go ahead happily using it for what it was specifically invented for.

Because I'm an evil nasty person out to do you harm. Because thats totally more likely than us just having an honest misunderstanding and me not being able to figure out how you're not crazy here. 

I'm really very confused by your comments.

Being able to delegate address generation to less trusted things, like a VPS— allowing you to have unique addresses where otherwise reuse would be required was a major design goal of BIP32.

Yes, you could have some always online trusted server communicating over some strongly private channel. But that just isn't practical in many cases.  As evidenced by the rampant use of static addresses in these places.  Allowing the less trusted device to generate addresses is a _strict improvement_ in privacy over the alternative of equivalent usability, because it reduces the space of parties who can deanonymize these particular transactions to only those who can compromise the less trusted issuer.  True, it does not replace issuing from a trusted location— thats still preferable— but presumably people would still do that where its actually possible, as they already do.

I am struggling to come up with any remotely rational basis for your complaint.  Are you under the impression that a user could only have a single chain, and thus this practice would reduce their privacy for all their addresses rather than just the subset which would have instead used a single static address?

Under any circumstance where it happens when the receiver is not looking forward at least 1000 addresses.

Where?

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.