pull down to refresh
A classic programmer's joke is relevant here:
There are three hard problems in computer science: naming things and off-by-one errors.
Off-by-one errors are things like buffer overflows. But the first problem, naming things, is most relevant in this case. You reference a name and somehow get the wrong data/code -- it's odd that this isn't well-understood at places like Github and NPM, despite being the subject of an old joke.
You've heard of Not Invented Here syndrome (NIH). If you generalize NIH, you get Not Learned Here syndrome (NLH), in which a person/organization only learns lessons through their own experience, rather than through the experience of others. This is a syndrome, because the sufferer is all but guaranteed to learn the wrong things from their experience, whereas reading about others' experiences all but guarantees that you'd learn the right things.
If you further generalize NIH, you get Never Gonna Learn syndrome (NGL), in which the person/organization is totally incapable of learning certain categories of lessons. At this level, the sufferer is so tied up with unproductive tasks (e.g. meetings, regulatory compliance, etc) that they barely have time to do their work. As a result, they have no time to learn anything that isn't related to specific work tasks. When you are designing a new feature for your PaaS, you don't even realize that you need to learn about certain security edge-cases.
There was a bug, we accidentally sent out a push notification to everyone who had them enabled when a territory was unarchived.
If someone transfers you a territory should there be an accept or reject option on that, if you reject it goes to archived? Just to prevent anyone from accidentally getting billed for territories that have been erroneously assigned to them.
Ohhh, good point. I actually didn't consider automated billing. When I implemented this, I thought people could simply transfer it back/away or not pay and let it get archived. But with automated billing setup, this would indeed be a problem. If you time the transfer right, someone would get billed and pay for a territory they didn't want.
Good catch!
This tool allows you to steal funds from nodes that attempt to pay an invoice a second time after the first succeeds. Soon we will add the wormhole attack in it so that routing nodes can get more money by shortcuting other routing nodes in the middle. You can safely run this and sit back and watch your node get more sats than it was getting before. There's also a mode that doesn't steal in case you want to see if you could have stolen funds.
Could you inspect the mempool in the days leading up to the prize block and outbid competing transaction's miner fee?
I doubt it, because you state that this is "well-known", so miners would know too. A miner would cherry-pick her own transaction to spend the UTXO. The only way it would be rational for the miner to mine your tx instead of her own, would be if you offered a fee worth more than the UTXO itself.
What's are your tactics to spend it first?
Assuming it's a large enough UTXO to justify it, I'd try to time the purchase of some cloud mining, and try extra hard to win that block, and include my own tx in the block.
Curious to hear the answer about propagating a "not-yet-but-soon-will-be"-transaction. I believe it would, or at least should, propagate.
Fun discussion.
Oh @Siggy47! Absolutely blown away by this text about my work. The best description anyone has written! Thank you so much for all you do!
Yes, the old tale of "jUsT bE yOuRseLf", lol. It's true but it's often very unhelpful and can make you feel even worse since it sounds so easy. But I think the problem is that people don't know who they are. How should they be themselves when they don't know what that means?
When I think about it there's an additional wrinkle -- it's not just "be whoever you happen to be, you special snowflake" but rather: you are a person with a very distinct configuration, and if you find ways in which that configuration can find a place in the world, nobody will be able to out-you you.
One additional wrinkle, though (there are two wrinkles, apparently) is that you -- whoever you happen to be -- isn't static. You can add things to your self, and refine it. That's the vibe underlying this post, actually -- what is it, exactly, that we should add or change?
I've said this in other places, but there's lots of room between impersonal company holding your keys and only holding coins in a cold hardware wallet.
I think that's where the sweet spot is, because instagibbs is more or less correct. People don't trust themselves with self-custody. But that doesn't mean they have to trust Coinbase. They can, for example, trust a techy relative. I know I'm that guy for my extended family because none of them are comfortable with self-custody.
What we need to do is acknowledge this reality and take advantage of it to make more scalable solutions. Something like Fedi for families or communities where there are existing trust relationships would do really well, especially if there was some strict multisig controls over the Bitcoin.