I've found for serious uses, those APIs generally create more problems than they solve. You've got to deal with (malicious) wrong data, usage restrictions, privacy concerns, up time problems.

They're definitely useful for some ad-hoc shit though. But for an actual commercial service, I think the only API service I can recommend in good-faith (in special circumstances) would be blockcypher's confidence stuff for some 0-conf transactions. They seem to do a good job on that, and the data is not easy to get yourself. [I wouldn't recommend their other APIs though, but I don't want to digress too much]

Kind of funny, I always thought bitcoin core's wallet did rather well with large amounts of addresses. I tried probably over 5 wallets that supported importing private keys, and most of them shit themselves at 1-2k addresses. While I didn't have any real problem with a few million in bitcoin core. Can't say I ever tried 150 million keys though...


It's hard to tell what you're doing, but .. I guess you're doing some bitcoin service type thing. Core's wallet is really not designed for sort of heavy commercial use, but all the limitations can be worked around (with a bit of effort).

Some things I did, and would strongly recommend for a hardcore service:


a) Store addresses in your own database. Scan blocks (and optionally the mempool) manually, and track user balances/deposits outside of bitcoin core
b) Only import addresses/funds after the address has been used. e.g. if a user requests an address, only add it to bitcoin core after actually been used
c) If you're using bitcoin core's send (well coin selection), try have a strategy for dealing with dust (either locking it, or not importing it or something). I've seen people (accidentally) lose thousands of dollars cause they have been dusted with hundreds of utxos and their wallets coin selection then spent it during high fee times
d) bitcoin core's wallet gets very slow (O(n)) when you have a lot of transactions in your wallet. If you're a busy service, you'll find any `listunspent` (or something that depends on that) is taking 30+ seconds, which can be pretty problematic if you want to instantly send people funds. You can solve this by writing a script that calls `removeprunedfunds` to delete transactions your wallet doesn't need to care about any more. You have to be very very careful about this, because it's extremely easy to corrupt your wallet state if you delete the wrong thing, or delete in the wrong order. Most people I talked to solve it by cycling wallets (like create a new wallet every few months, and import everything still relevant they need from the last one. But I find that a little inelegant.

Nice domain name!

However, there's a lot of red-flags. The code looks like it's pirated from bustabit. Your site pretends to be in the crypto gambling foundation (which is something that was explicitly added, it's not in the bustabit v1 code) even though it's not. And the site is obviously faking volume/activity with bots (with painfully randomized names lol). And you are scamily promoting some way to beat the house.

But I got to admit, I do like that domain name. Maybe not enough to lose my money here though...

All scripts run in your browser (except the "payout" part, where the server will automatically cash you out at that point, even if you're not connected). So if you want to stop a script, you can always just close the browser tab (or hit the pause button).

The simplest script to look at is the "FLAT BET" one. You can hit the "view source" button thingy, and if you can read javascript you'll see it's pretty trivial and representative of how the vast majority of script works. The "flat bet" script simply says "when ever a game starts, bet". But if you wanted to write some code, you could easily hook into to a disconnect/pause event, set some state. And then only bet if the game hasn't paused before etc.

The point I was trying to make earlier though is that even small amounts of privacy leaks can end up add (multiply?) up to be a big deal. And it's really hard to imagine or enumerate all the different ways that can happen.

Like even if the ip address is changing, but they come from the same residential ISP -- the can be incredibly valuable -- as those (dynamic) ip addresses will generally geo-locate you to a ~city type level. I might be using some totally unrelated data to suspect person X of making those transactions. I know person Y lives in a particular city. And it appears the transaction originates from city Y.

So not only does this increase my confidence that person X made the transaction, but it also strengthens my confidence in the information that lead me to that track in the first place. Which sort of feedback to how easily people underestimate the affect of slight privacy leaks.


Don't make the mistake of thinking government accessible data is only accessible to the government. I had private information (that I provided directly to law-enforcement and no one else) come back and be used to harass me (via a leak?). And I've seen various (failed) attempts at "social-engineering" by court orders for information (and even specific action!) that have been caught (and only because some services notified me of pending requests, and I warned them to triple-check for authenticity). I am almost 100% sure various stuff went through without me even knowing about it.

In short: If someone knew your IP address and a time, and they forged a subpoena to get your information. There's a very large chance they would get it.

Sorry, but you are not quite correct.

Let's say I have a bunch of spy-nodes observing the network. And I'm interested in knowing more about a particular address. First a transaction spends from that address, and with my spy nodes, I find it looks like IP address X originated the transaction. But there's a lot of noise and uncertainty to the point that the observation on its own is ~worthless. But lets say I now send dust to that address, and it again gets spent by what also looks like the IP address of X. Now I might have enough confidence to actually believe that X ip address originated the transaction.

And also, don't forget that all the analysis techniques kind of "signal boost" or "back propagate" () each other. e.g. the dust attack might link cause you to spend from an address is well-understood (e.g. a withdrawal address you made from a chainalysis powered exchange) and you have just clusted your entire wallet to your personal information. Like even tiny privacy leaks can end up causing outsized implications.

I've had (indirect) access to chainalysis and was able to run a few little experiments, and I think people don't appreciate how wtf effective they can be (and if they did, there would be more energy at trying to fix some low-hanging fruit of privacy leaks, e.g. (bip69 vs normal wallets).

The silver lining though, is that the analysis techniques are very fragile. Like my hunch is if we got 1% of transactions to now use bip78 it would cause a catastrophic increase in uncertainty in attackers models.

It'd really suck balls to not be able to convert an arbitrary public key into a bitcoin address. But I guess you could make it opt-in by using a prefix like "bcN" which means the first N bytes are implied to be zero.  But hard to imagine the complexity is worth it and not to mention it'd create yet another heuristic (grinders vs non-grinders) attackers could use for analysis

Because they (inherently) don't look like other addresses, which is information that heuristics can exploit.

Well, if you wanted to do that -- you'd use the HD derived value for "Step 1" part. But you wouldn't actually use bip32 to try brute force a vanity address.


Actually if you wanted to make a "vanity hardware wallet" it's not too hard, and the cool thing is the hardware wallet can safely outsource the work to a computer without [realistically] compromising security. (In short: The hardware wallet keeps `p` a secret, but gives you `P` and then you keep track of how many times you need to add `G` to P to get a good vanity address.)


I don't think there's much demand for this sort of thing though, as it'd be pretty toxic for privacy

That's not nearly the case. A normal vanity generation is something like:

Step 1: Pick a random private key `p`
Step 2: Compute  the elliptical operation `P=p*G`
Step 3: Let V = to_bitcoin_address(P)
Step 4: If V matches our vanity filter, we are done. And the private key is p.
Step 5: Compute p = p+1
Step 6: Compute the elliptical operation P = P + G
Step 7: GO TO step 3.


This is insanely more efficient than using an HD seed which every iteration requires a lot of pointless, slow and complex steps (hashes, EC multiplications) . And also you can resume the process easily by just substituting "Step 1" for using the last `p` you want to continue the process from. In short: Using an HD seed makes absolutely zero sense. I can't think of a single upside.

The bible quote in your signature reminded me of a fanatical Christian dude who maintained (maintains?) a patchset that blacklisted certain prefixes of bitcoin addresses. The blacklist worked by looking at the start of an address and rejecting vanity addresses corresponding to some gambling sites (e.g. satoshidice).

As I recall there was some drama at the time (2014?) when this ridicilious patchset was snuck into the default build in gentoo.

The intuition is simple: Each time you create a transaction, there is a (large) potential to leak information. Attackers can use heuristics to guess your ip address. Or guess you're using tor (which itself is interesting information) and most powerfully: guess what other addresses you own (if the transaction spends from/to other addresses).

Normally someone only uses an address once, so you only get to apply these heuristics once. But if you send money to an address, you might get them to make an additional transaction. It's not particularly economical to send people large amounts of money, so you generally send them the smallest you can (AKA dust).

Before trying to educate people on something, you should make sure you know the subject matter yourself. In this case, you're exactly wrong. Assuming the vanity-address generating software is written correctly, a vanity address is no easier to brute force than any other address.

At it's most fundamental level, vanity address generation is just generating addresses in a loop until you find one that looks pretty and you use that.

A worked example: this is the ultimate vanity address:   tell me the private key, and I'll give you 13.24 BTC.

The article links to this explanation of what it means. It's probably reasonably effective in the hands of a skilled attacker, when the sender uses the standard relay network in a normal fashion

A virtual byte is simply 0.25*weight. So converting between the two is simply a case of multiplying or dividing by 4, so if you're sorting by one you're sorting by the other too. Most wallets do indeed expose "virtual byte" at the interface level, which while it did help a smoother transition, I think the whole has been a big net negative. I often see mistakes, most commonly it's by people (and some wallets!) who use "byte" as a short-hand for "virtual byte". Which then leads to problems like where the OP (incorrectly) thought "sat/byte" was the useful measurement said you assumed he was wrong and actually meant "virtual byte" (but he meant what he said) etc.

So yeah, I think we should just kill "virtual byte" and expose SPW (satoshis per weight) as the preferred fee rate.

I printed out a bunch of paper wallets over the years to give as gifts. I also kept the private keys to help restore if needed, and just checking now, only one of them has moved (in 2015). No one has ever asked me for help, so I don't know if I volunteer to "help" them restoring their bitcoin. A few of those are for 1 BTC (although most are 0.1), which is now a decent chunk of money. I like to think they kept the paper wallet in a safety deposit box or something, but probably the reality is it's both lost and forgotten.


But my actual main motivation for the "utxo-giftcards" was actually as a (very trade-offy) way of making payments. Very often when people are sending money to an exchange or a casino, they really just want to "send everything" and a big service would be able to very efficiently redeem such "utxo-giftcards"  (e.g. using them to process someone's low-priority withdrawal)

I think you're the one confused here. There is nothing weird or wrong about 0.4 sat/byte. It just isn't a perfectly descriptive way to describe a fee rate, as miners sort by fee/weight rather than fee/size. We can make a pretty good guess though, because we know a byte can't be more than 4 weight, and we also know that transactions paying less than 0.25 sat/weight aren't generally propagated or mined.

As a worked example, the largest (?) block explorer:
https://www.blockchain.com/btc/tx/b4c40b96695e17bdcb6a5794a24c06af7d0d1fd0d8640c2db01e01d87c15d02c

You'll see it shows and calculates: "Fee per byte" of 0 0.525 sat/byte correctly.

I think the real problem is the whole "virtual byte" system. It's a total understandability disaster to even experience bitcoin users, and I regularly see people confusing size for virtual size and confusing virtual size of physical size. I think we really need to kill it with fire, and just measure stuff in weight. And use something like (SPW: satoshis per weight) as a standard way to measure free rate.

I'm not sure it's very useful, as not only did I not get it working -- I'm not sure how to do so. But I think the "project scope" was pretty interesting.

Basically the idea was to build a "commercial wallet" that sits behind a trusted bitcoin node (avoid a lot of validation nonsense and risks etc.). And then provided a really robust API for sending/receiving payments. And I made a very strong distinction between a "payment" and a bitcoin transaction. As in a payment might be: "I want to pay X with N BTC with Z priority" and you could track that payment and see which "bitcoin transactions" it gets reified into (which might keep changing until it eventually confirms).

The other feature I was trying to build which I'm a huge fan of, is something I call "utxo-giftcards". Where a "utxo-giftcard" is basically a (txid:vout:privatekey). So when you import someone elses utxo-giftcard the wallet knows that it's "untrusted" and that because a 3rd party also has the private key it could be double-spent easily. And a "utxo-giftcard" is considered "redeemed" when the wallet itself spends it (as opposed to a 3rd party does). And when adding a "utxo-giftcard" you could specify the "redeem priority".

The reason I'm such a huge fan of the idea of "utxo-giftcards" is that it's pretty phenomenally space-efficient (as you can give someone money without even making a transaction) and a death-blow t entire classes of bitcoin analysis attacks. (Of course there are drawbacks in transferring a private-key, but I feel those are pretty obvious and understood enough that it's easy to use what is most suitable)

---

But doing it again, I'd just try have the same interface -- but not try code any of the logic myself -- and instead try use some sort of logical solver -- and then execute the results of that. I think maybe Microsoft's Z3 Theorem Prover could work for it. But don't have the time or energy to try that at the moment

Dooglus' calculation is correct. The "trick" behind it, is when someone invests they make the entire bankroll bigger, thus each % of stake will make less returns (for a given amount of revenue). If the investment is large, the effect will be large.

But still the fundamental: "If you own X% of the bankroll, and the bankroll makes Y ... you will make X% of Y" applies

Except "batch on replacement" is ludicrously hard to do.  I called it super sending and spent like 6 months working on the (generalization of that) problem (fully decoupling "payments" from "bitcoin transactions" and handling inbound/outbound correctly) and I like to think I'm a decent programmer, but had to give up as I could never figure out how to handle get a handle on all the complexity (which really explodes when you consider reorgs, inbound payments being replaced etc.).

I actually think it's the hardest (pure) programming problem I've worked on, and don't feel like I'd even be able to do it given another 6 months. I've never done "logic programming" but I almost feel like something like that would be essential, where you sort of logically describe all the high level concepts and ask it to solve what you should do. As just trying to handle all the cases imperatively just seems impossible to not end up in an exploded spaghetti nightmare of a gazillion states.


[Bit off topic, just ranting here incase you have any insights]