Quote from: gmaxwell on Today at 02:36:42 PM

Quote from: goatpig on Today at 07:47:41 AM

I'm guessing that's part of the vanity prefix and not something they're willing to let go unless offered a better solution.

There is no requirement to use uncompressed keys to use vanity addresses-- in fact, vanity addresses can be generated slightly faster with compressed keys.

If their prefix is just '3BMex' that's pretty short and easily found in any case.

I was saying this more in the context of "we already have them, why bother?". Of course compressing the keys would make more sense, but how motivated would they be to at least gradually replace their current "fleet" of addresses (which obviously isn't trivial to generate)? I'm guessing there is some form of key ceremony they're not so willing to either modify nor run through (I assume they're not generating these keys deterministically). It would be significantly easier with a script merklerisation scheme where you can separate the vanity search from the public key generation.

I'm trying to play devil's advocate here.

Quote

These things are not mutually exclusive, batching into a modest number of outputs per txn could halve the load they place on the network-- and that's true regardless of when they emit the transactions. (doubly so if someone created a two-sided version of the branch and bound search in Bitcoin core that can often result in changeless transactions when run with large wallets)

Most certainly the optimal solution would lay at some intersection of batching and broadcast delays. Broadcast delays would take them 5 minutes to implement. Batching? Who knows.