274 karma · joined February 17, 2020
* E-bikes are popular among teens / people under 18-21. They are cheaper, and the law prohibits them from riding motorbikes with above 50cc engines (which the majority are, unless you're riding a Cub 50 or so)
* As you go up the age ladder, ICE motorbikes dominates. I also have a feeling that traffic congestion is getting worst, thanks to more people having access to cars.
* Some abandoned their international studies plan and attended local colleges instead.
* Some took a gap year to wait until 2021.
* A minority pushed on and took classes online until they're able to come to the US.
> The working resolution must be 1920x1080 or higher throughout the production, including drawing, scanning, background, CG and VFX.
At least a few years ago, there was a belief that most anime were produced at under 1080p, then upscaled if necessary. Therefore 1080p anime didn't offer and advantages compared to 720p releases. I wonder if this is still true to this day.
Every time I sees someone using iMessage, it pains me a lot because I feel like I'm being left out of the conversation, just because I refuse to bow down to Apple's monopolistic practices.
> A Phase 1, Randomized, First-in-human, Open-label Study to Evaluate the Safety and Immunogenicity
For those looking to travel to Vietnam, use Grab or Be. Grab is the most popular choice, while Be is a local competitor.
pub trait HashFunction<const OUTPUT_SIZE: usize> {
fn hash(data: &[u8]) -> [u8; OUTPUT_SIZE];
}
I believe this approach has some shortcomings in my case, but it has been a while and I didn't remember anything.Also for the Rust crowd, is it possible to do something like this?
pub trait HashFunction<const OUTPUT_SIZE: usize> {
// I want Output to always be [u8; OUTPUT_SIZE], but using associated type means
// whatever implements HashFunction can redefine Output.
type Output;
fn hash(data: &[u8]) -> Output;
}There are two ways to understand your question so I'll just answer both of them:
Fitting more transactions in a block leads to faster confirmation, and potentially lower fee. When a transaction gets into a block, the network confirms that the transaction is valid and can't be reversed. Right now each block can only fit ~2k transactions, and since a block can only be generated every 10 minutes, the mempool (backlog of unconfirmed transaction) is rather huge. This site shows how big it is: https://jochen-hoenicke.de/queue/. Miners are incentivized to only select transaction with high fee into the next block, which in turn incentivizes users to pay more fee to get their transaction to confirm faster. With bigger blocks, more transactions get confirmed quicker, which leads to lower fee.
Bigger blocks however mean miners with slow internet connection are at a disadvantage. When a miner finds a winning block, they broadcast the block to as many nodes in the network as possible. After a while, a majority of nodes accepts that winning block, and the miner is eligible for the mining reward. If A finds the winning block 10 seconds after B, but A is able to propagate their block quicker than B, then it's possible that A's block is accepted and not B'. In reality, it's possible that B might still win the race, but the rule is: faster propagation => more chance of being accepted.
Once someone finds a winning block, they're rewarded with a number of Bitcoin. This subsidies the cost that goes into mining that block. However the reward halves after every 210k blocks, so as the reward goes down, miners will prefer to only include transactions with high fee. Eventually the true cost of mining will reflect in the transaction fee.
And to add to the "it costs 657.6kWh to process a transaction": energy is used to produce a block, which contains an arbitrarily defined number of transactions. Right now, Bitcoin Core limits each block to 1MB, which works out to about 2k transactions per block. If Bitcoin Core were to increase the limit to say 10MB, the energy used to produce a block doesn't change, but the energy used to process a transaction goes down tenfold.