OP did actually host a tracker.
"I then started the tracker. After about an hour, it peaked at about 1.7 million distinct torrents across 3.1 million peers!"
486 karma · joined May 1, 2016
"I then started the tracker. After about an hour, it peaked at about 1.7 million distinct torrents across 3.1 million peers!"
This is not real encryption, it picks only one byte of shared secret and XORs it into the plaintext. Therefore, there are only 256 possible decryption keys to check, which is trivial.
Instead, you'd want to use the shared secret as a key to something strong and symmetric like AES.
Naming Baritone after Fit is actually a coincidence / joke, the repo github.com/cabaletta/baritone was the result of random brainstorming for something untaken. We only later realized it described Fit and thus added that to the readme :)
The reveal of the script is actually time-delayed. See https://en.bitcoin.it/wiki/Pay_to_script_hash
Essentially, you "send" the Bitcoin to the hash of the script, then whenever a transaction spends those coins it must reveal the script (whose hash must match), as well as some data (normally a digital signature or two) that fulfills the script's conditions.
So, the block explorer doesn't get to deal with it until the coins are spent, up until that point all it knows is a hash, which is represented as beginning with a "3", to differentiate it from the simple single-key addresses that begin with a "1".
When it's spent, a block explorer could show the revealed script contents if it wanted.
Perhaps the issue was that Philip Roth was unable to sufficiently demonstrate his identity? Of course, Wikipedia can't take a random editor's word when they say "I am this person and this is the truth", then anyone could say anything. There has to be some citation, for example I've seen someone cite a tweet for simple biographical information (e.g. "today is my birthday").
But your point is good - miners are not really in a traditional supply/demand relationship with transactors, because block space is perfectly inelastic. There will be 7 slots per second (amortized), no matter what. Although... a petulant miner could artificially restrict this supply, by perhaps declaring that they'll never mine a transaction that pays less than X fee. This would only apply to the blocks that they mine, but the effect on overall supply could be nontrivial?
The difference is in the authority of who gets to reverse transactions. For example, Tether can freeze and generally arbitrarily control USDT token. USDT therefore isn't really a cryptocurrency, since now a central authority can seize it. It seems to me that this authority undermines why one might want to use crypto in the first place. I don't think you can have it both ways.
Clearly there's much more to it. For example, cryptocurrencies with those two properties you mentioned are a dime a dozen. I could make one right now by git cloning bitcoin, changing some properties, then running it. And in practice there are thousands with high volume exchange-value. Digital currencies, when combined with ubiquitous exchanges, have such substitutability that I'm not sure there's much of a "network effect" or "lock in", when it's so easy to swap and pay with any of them. "value decided by the market" might be flimsy in this case.
I think it is vaguely accurate to say that fees and mining costs are linked, *however*, currently the coinbase block reward is a bigger deal. Example: most recent block https://www.blockchain.com/btc/block/743055 created 6.25 bitcoin out of thin air, plus 0.186 bitcoin from all its fees. In the future, when fees make up a larger share of this, miners will indeed start to get income from fees. Then, we will see an interesting dynamic where automatic difficulty adjustments and competition between miners entering and exiting the market will result in miners electricity costs aligning with bitcoin transaction fees. In other words, every unit of value that goes into a bitcoin transaction will result in that much value being spent by a miner on their electricity bill.
Quote: "The least viewed article in the sample, Erygia sigillata, has a page_random value of 0.500764585777. The article Katherine Hanley is right on its tail with a value of 0.500764582314, which is just 0.000000003 less, or 3e-9 in scientific notation. This is 98% smaller than the average random gap. In other words, Erygia sigillata is an extremely unlucky article as far as the “Random article” button is concerned! It’s 50 times less likely to be landed on than an average article."
"MakeMKV is a format converter, otherwise called "transcoder". It converts the video clips from proprietary (and usually encrypted) disc into a set of MKV files, preserving most information but not changing it in any way."
I wasn't around for when the patch was engineered into Paper, but from what I'm told, yes that was the idea. :)
But for what I actually changed, off the top of my head, I set the recordsizes in ZFS large enough that Postgres could safely (because of ZFS CoW) have full_page_writes off, and combined with synchronous_commit off, that really sped up the overall system and made the WAL logs much smaller. After looking just now at postgresql.conf, various other things were tweaked, such as seq_page_cost, random_page_cost, effective_cache_size, effective_io_concurrency, max_worker_processes, default_statistics_target, dynamic_shared_memory_type, work_mem, maintenance_work_mem, shared_buffers, but those were not quite as important. (plus some uninteresting tweaks to WAL behavior, since we had replicas that got WAL logs shipped every few minutes with rsync)
For downloading bases, it is an essentially perfect recreation. Some things are missing, such as the color of banners, but for 99% of blocks, just setting the correct blockstates will recreate the build. Some disconnected sections of the build might not be found by the paintbucket floodfill algorithm though, so floating parts could be missing. We counteracted this by having a few random blocks in the chunk be checked on a schedule, so eventually it would get everything.