The obvious go-to choice was Cloudflare for us too, but then it turned out you can't use CF just as a registrar (at least on the basic plan or equivalent), you need to use Cloudflare's nameservers as well... But we use Google's Cloud DNS for everything, so that was a showstopper. In the end we went with AWS Route 53.
CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.
> CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.
Why would they want that? The whole point of CF as a registrar was so you could use the other services. The registrar is sold at cost. It's a way to lock you in.
It would lower the barrier to switch to Cloudflare for new customers, and once they are inside with a credit card on file it’s arguably easier to explore their product offerings
I don’t think it’s the case even on a paid tier, if it is I can’t find any reference to it. There are a lot of posts on their community support form where the recommendation is to use another registrar. https://community.cloudflare.com/t/use-cloudflare-registrar-...
That option means "your nameservers are now ns1/ns2 on your domain but they still map to Cloudflare", not "you get to pick your own third-party nameservers".
That's been a dream for nearly as long as the web has been around. I'm pretty sure there are mailing list threads from the '90s about turning micropayments into a standardized web API. As far as I can tell, this never caught on because it's almost always more profitable to operate your own paywall scheme or payment network than to participate in someone else's (provided that you're powerful enough to get away with it).
The point is you should be able to operate you own paywall. The tech is mature enough in 2024 to make it work.
Make the browser store you credit/debit card info, make the browser handle the payment UI, make the browser expose JS apis to invoke payments and receipt fetching against pluggable payment providers.
My ideal world looks like this. New html button element:
`<pay amount="1.00" currency="USD" reference="my-article-123" checkoutUrl="https://...">Unlock for $1.00</pay>`
Clicking it opens browser checkout flow. The url you get from stripe/paypal or another whitelisted payment provider that has implemented the spec, some flow similar to OAuth. On a successful tx, a signed receipt (something like a jwt) is returned from the provider and saved by the browser, on disk on your computer.
The webpage can then load signed receipt references from the browser api, sends it to the backend which can return the article content if the receipt jwt is valid.
It can be fixed if the right people from Chrome and Stripe got together in a room and brainstormed for a bit. Then everyone else would follow.
It would definitely heavily depend on the dataset you're querying... Very little value in cached search results if you're searching through time-sensitive data such as logs or other live-datasets.
Most datasets I've searched also has a concept of permissions, so person a couldn't be served the same cached result as person b... I think search can't be cached at the http level either, its too heavily dependent on the data you're searching through so you'd have to implement it in the application anyway.
the article does make a good point though: a `get` request that supports a `body` would be nice, and thats pretty much all they're arguing for with the `search` verb.
Been pretty useful for discovery of SDK functionality in open-source libraries, that otherwise takes a bunch of time Googling the answer for. For example;
- Using golang, how do I write a custom marshaller for uber/zap
- Given a list of protogen.Files, how do I parse protobuf options and their values
Unfortunately the generated code is more often than not incorrect or uses non-existing API methods, but can give an idea of methods to use or where to look in the official api docs.
Love this idea, and in general agree that using a proto model as the single source of truth is a neat concept.
Not sure you need a completely new db though; with protobuf’s native support for plugins, perhaps the missing piece you’re looking for is a protoc plugin that generates the table definitions for your db of choice? Could work well for databases with declarative schemas..
Don’t want to discourage you from creating a new database, but writing a proto plugin is arguably a quicker undertaking!
What I'm unsure of is how well proto can be modeled in various existing relational databases and what the performance and management consequences might be.
If I have a message defining a table and it has a field which is another message, how well can Postgres Structs represent that submessage? What are the performance implications? I'm not terribly familiar with the query semantics for Poatgres structs. How do migrations and backfills work for struct fields and nested structs?
These considerations may or may not justify a new database.
Yeah I’m sure there are all sorts of considerations. Also not saying it’s straightforward, just easier than writing a new db. You can for example write proto message extensions to support custom field behaviours.
But like a sibling comment said here, if you want the database implementation to dictate your models you can probably generate protos from something like EdgeDB. But then the db implementation is in charge, which seem a bit backwards.
If you’ve used graphql you’re presented with a similar challenge but on the other end of the spectrum - the graphql schema that needs to map to application models.
So one of the main considerations is to figure out how and where you want to define your source models. Is it the view layer, the model layer or the database layer.
I'm curious how this works. As I understand it, Bitfinex would have do this by not broadcasting the transaction to the network and instead keeps it on a single miner and it gets included when the miner snags a block but how does that help launder money?
Is it some sort of deniability thing to say your hilariously unreasonable miner tip was mined by a random miner who may or may not be you? Surely regulators/prosecutors aren't this gullible.
Regulation/prosecution is lagging way behind in this space. Even in traditional finance, Ponzi schemes and money laundering go on for years.
It's also important to consider the psychology of things like Ponzi schemes. A bright 12 year old can understand why a Ponzi scheme falls apart in the long run. But for most of the people running them, they aren't thinking about the long run. They're responding to short-term incentives. An investor wants money back? Well there's money, so let's give some to them. Low on money? Go out and sell more people on putting money in. People have concerns? Reassure them that everything's fine, better than fine, amazing in fact.
So the question of "do they think they can get away with it in the long run" is not really the right one to ask. 100% of their attention is on the short term. They carefully avoid thinking about the long run at all, because it's way too uncomfortable. As long as the problems are deniable enough in the short term, they're just going to keep going.
The cool part is all of these transactions are public and can be archived by regulators for long term forensics and enforcement activities while still within the statute of limitations. Might take years, but government can take its time investigating and prosecuting. Regulation can lag because there is no rush; the evidence is preserved by the very nature of the technology.
That's a positive for sure, but regulatory latency enables more scamming. That added burden to limited regulatory capacity mean the increased scamming makes it likelier that the small fry will get away.
While I don't doubt it's a method used for money laundering, this particular instance probably isn't it. For one, if you're money laundering, you don't want the transaction to show up on the front page of HN.
Yeah why not do this over time with smaller fees. With the ridiculous gas these days you might be able to sneak quite a few tx in under the guise of “nft bots” but not 7500 eth in one tx
Various claims on reddit using phrases like "set the gwei limit the same as the gas limit" and "new EIP 1559 transaction", which I can barely make sense of, but it sounds like they may have been in entirely different units?
Anyway, be your own bank, I'm sure you can figure this out. /s
Its not money laundering, lol.
a) Bitfinex is an exchange, they don't need to launder. They are the laundry!
b) You usually want to get the money back when your launder. This is handing 20 million dollars to a random on the street who takes your transactions.
I get that point, but I was asking for what is then the real reason. The only two I've seen proposed are money laundering (perhaps by collusion with the miner) or mistake (accidentally confusing the transaction amount with the tip - still meaning the intention was to pay $100k in transaction fees).
It's also potentially risky. What if a big mining pool, upon noticing the huge fee mined by another miner/pool, decides not to mine on top of that block, but in competition with that block in hope of snagging the fee for itself?
There's been a lot of talk about reorg due to MEV (which this could be considered MEV), but to the best of my knowledge it hasn't happened yet. This seems like a big opportunity because this is ~3000x bigger than the standard block reward
We need Ethereum to always prevent this. Or the big mining pool will just do this for every block and allow ONLY THEIR blocks to be processed. Then they get 100% of mining of the ETH mining fees.
This reinforces by most miners being willing to join, to get a share in monopoly rents over miners-never-earning. The big mining pool(s) could let in enough to stay big enough. But not too many to spread the monopolistic gains by too broad a base.
The recipient in this case absolutely appears to be "associated" with Bitfinex, who don't understand the concept of "arms length", so entirely 'nepotistic' transactions like this would be par for the course (remember the loan between Bitfinex and Tether, who were at the time being stated as independent and unrelated, yet somehow the same two people signed and countersigned the loan for both sides?).
> DeversiFi — a non-custodial exchange that spun out of Bitfinex in 2019
From the article.
And as said, given previous dishonesty from Bitfinex about all sorts of unrelated parties (they claimed to be independent of Tether, until that was proven a lie, and they are heavily intertwined with their bank, Deltec, who says that they have "insight into every transaction and Tether"), I'm going to consider Occam's Razor, here.
Etherscan indicates that the transaction was in the mempool [0]. My understanding is that this wouldn't show up if it was mined without releasing the transaction to the mempool.
Is this even still possible? Since EIP-1559 miners like ethermine stopped including their own tx for 'free' presumably because you cant pick and choose anymore.
You can still pick and choose, EIP-1559 forces miners to burn part of the fee, which means it's no longer "free" to the miner to include these transactions. In the case of this transaction, Bitfinex also included a very large tip that went to the miner.
No, there are 2 parts to the fee. The base and the tip. The base is burned and the tip goes to the miner. This transaction burned 0.008493159450499633 eth (~$25) and paid the miner the rest.
Yes. For instance on etherscan there's a "Confirmed within x secs" indicator, which is "Estimated duration between time First Seen and included in block".
Even if it is logged, there are ways this behaviour could be masked.
Say a colluding miner mines blocks including this unbroadcast transaction until they finally hit the block target with this transaction included.
Bitfinex then broadcasts the transaction to mempool. After some plausible delay (but a short enough one that no one else gets a chance to mine it), the colluding miner publishes a valid block including the transaction. No one can confirm that the miner didn't receive the transaction from mempool like everyone else, and then 'get lucky' shortly after.
I'm not saying this is what happened, I think user error is more likely. But it can neither be ruled out nor easily proven.
Demand grows, but the bitcoin supply is limited. Price increases. Also, after each halving the bitcoin miner payout gets cut in half, so price has to increase for the network to stay alive.
CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.