Bitcoin $50,000 Next Stop; XRP Not A Security?

Monero Community Activists

A meeting place for Monero community activists. Put your talents to use by sharing the word of Monero!
[link]

Bitcoin boom! Price now above $9,000 – American Security Resources Corp. (OTCMKTS:ARSC)

submitted by bitnewsbot to bitnewsbot [link] [comments]

Crystal Ball Prediction for Next Bull-run!

Crystal Ball Prediction for Next Bull-run! submitted by tralxz to btc [link] [comments]

Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

Unpopular opinion - the economy has to become dynamic in order for it to have any longevity (and other musings on the progression)

Ain't no one gonna read this but here it goes!
The issue of progression has recently been gaining some traction in the community with Klean and DeadlySlob covering this topic recently.
Now any solution to this has an inherent issue associated with it - it'll be uncomfortable to someone. Whatever is done, it'll negatively affect someone, just by the fact of change alone. You cannot make something better by not changing anything. So anything you do or don't do, you will alienate a portion of your playerbase.
Early/Mid-game vs Late game.
Early and mid game is lauded, late game is considered boring. But why? For startes, firefights last longer, require more skill, movement, tactics and outsmarting your opponent. You value your life, you feel respect even for the shittiest of bullets. You have a feeling that the kill is earned. Guns have tons of recoil so you need to pick your shots. It's... I know it's illegal... but it's fun.
Late game however is plagued with a number of issues. Gear gets dominated by very similar loadouts that cover approx 10% of the gear in the game. There's nowhere to progress as you've reached the ceiling. The excitement from killing a kitted player diminishes as time goes as the economy saturates. People start being picky with their loot and only the good stuff brings any sort of satisfaction. The hideout provides a steady, predictable stream of income.
You let it run long enough it becomes a mindless PVP battleground.
Side note - the black and white fallacy of the makeup of the community.
Casuals vs hardcores. Rats vs Chads. Whenever a discussion pops up this dichotomy is always present. "Feature X hurts casuals but doesn't bother hardcore gamers playing 8h a day". No. Like anything in life the population of EFT is subject to the bellcurve distribution. There are hardcore sweaties grinding out the kappa within a week and there are also sunday gamers. Then there's everything else in between. Let's keep that in mind.
You don't need to be a streamer or play the game as a full time job to make money. We have a discord for 30+ yr old gamers with families and all of us were swimming in roubles and gear after 3 months of the past wipe. Sure it takes us longer than streamers, but still.
The meta
Taking weapons as an example. Different items have different stats (recoil, ergonomics, etc), some are obviously better than others which obviously makes them more sought after. There are also different ammo types for every caliber. Then lastly we come to the guns which directly tie into the first point, by their base stats and how much those can be brought down/up by attachments.
If you have a plethora of items that have different stats, there's sure to be an optimal loadout. If that optimal loadout is always available at an attainable price to the point where you can run it consistently, then there's really no reason to run anything less. This is the meta and at the moment it's basically a synonym for best in slot.
Appealing to a greater good such as gameplay variety is in vain because people will do everything to put themselves in the best possible position. If that means running whatever flavor of meta weapon that is - VAL, M4, FAL alongside top tier lvl 5 or 6 armor over and over and over and over again, so be it. We all know that's not the only way to get by in EFT, but all else being equal - top gear puts you on equal footing at minimum.
Trash contextualizes treasure. A rare item is not rare if everyone is running it. It's a normal item.
Gear minmaxing combined with a ceiling in progression create a situation where the game becomes stale, people get bored and we get chants for a wipe to releave the pressure.
Wipes
Wipes however, even at set intervals, are not the solution. Every wipe, in the absence of something fundamentally new, gives you (rapidly) diminishing returns. Doing the same quests over and over is an absolute drag. It's my 7th wipe and this time around I've really hit a brick wall with them. Now imagine doing them every 3 months. Maybe just do an inventory and trader level wipe? Yeah, that's just skipping one part of it and arriving at the same point but even quicker, considering how quickly you can make money.
The endpoint being - having enough money to run anything you want all the time without the fear of getting broke. Or in the abstract, having a big enough cushion to make any blow from a bad streak become inconsequential.
All of that is just a perpetuation of the same sawtooth progression. Grind, saturate, wipe, grind, saturate, wipe.
Side note - persistent character vs wiped character
I know there have been talks about having two characters - one persistent that's not wiped and one seasonal that is. On paper this might look like a good solution, but there are some problems.
POE players would have to chip in, but I reckong, that in a way this might become a form of matchmaking - the persistent character would be a mode for "sunday" players, while the wiped one for the sweats. I mean, maybe that's the way to go, but if the game is to gave any longevity, the persistent character will eventually face the same issues as the current game, it'll just take longer to develop.
Unpopular opinion - The economy is just a set of time and effort gated unlocks.
There have been multiple ideas to prolong a wipe, but in my view the fundamental issue with those is that they're based off the same linear progression - start from scratch and acumulate wealth until saturation. Some of these ideas include restricting labs till level X, locking behind a quest or just disabling it for a month. The problem with these is that it's just delaying the inevitable, while also giving a direct buff to those who get there first as they'll have the place virtually to themselves.
What follows is also the concept of "starting mid wipe", which essentially means that the gear disparity is so big that the further into a wipe, the more difficult it is to catch up. That effort is directly correlated with experience - the more experience you have the easier it is for you to reset or jump in midwipe. Extending a wipe potentially alleviates that by giving people more opportunity to catch up, but also pushes away from coming back/into the game if they recognize that it had passed their personal breakpoint where it's too hard / frustrating.
Perpetual mid-game
So out of all of that, a clearer picture emerges. We have to somehow find a solution to always have something to work for, but also not give the impression that you're up against an impenetrable wall.
That means that the game needs to pivot around something colloquially known as mid game. How would we define mid-game? That's another debate, but for the sake of the argument we could define that as something in the range of:
That would be the sort of mean loadout you can run on a consistent basis and you'd see the majority of the time. From the sentiment across the community, this seems to be the most enjoyable state of the game, where the sweetspot is in terms of protection and vulnerability, but allowing a lot of headroom for both variety and
Solutions
Now we must have to remember that there's a number of changes inbound that will alleviate some of the issues:
But those are sill far on the horizon.
The uncomfortable reality is that in order to truly balance that you have only a few choices. One is to go down the route of typical FPS tropes where every weapon type is perfectly balanced (i.e. shotguns powerfull but limited range, smg's low recoil, high ROF but weaker, dmrs powerful but high recoil and low ROF, etc). I don't think this will be ever a thing in the game.
Another one is to make attachments roughly equal and just attribute the differences to the tacticool visual factor. This would be realistic in a way, but would take away from the game.
The last one is to price them out. Literally. I'm of the unpopular opinion that endgame should not be a stage, it should be a state.
Dynamic pricing
I know I know, last time it failed spectacularly. However, that was a different flea market and the implementation was poorly thought out. Since it didn't have a pivot point to relate to it caused widespread inflation of even the most basic items and was prone to manipulation.
However the concept in principal has proven itself to work - M995 was essentially priced out of existence and forced people to look for alternatives like M855A1 or M856A1 or different calibers alltogether. Even the sweaties of sweats got a bit excited when they killed someone with 3 60rounders filled with M995. See where I'm going with this?
The execution was poor and poorly thought out.
But how about a different implementation? Adjust the prices based on how much an item is (or is not) bought compared to other items of the same item type. Most popular items' price (of a specific category) increases, while the least popular one decreases.
This could also be coupled with (or as an alternative) an additional rarity factor which would sort of specify how volatile the price is. Continuing the ammo example M995 would have the highest rarity factor and would be very prone to price increases, while the likes of M855 would be considered common and have a much more stable price.
Obviously this would be subject to long term trends and would not happen overnight. But the main aim is to dynamically scale the economy to the general wealth of the playerbase around a certain pivot point which we established before as the mid-game.
This would be a quite significant blow to the uberchads as they would unironically struggle to maintain a profit from their runs. And yes, some of them would still probably be able to pull this off, but remember what we said about the bell curve? It's just about making them so insignificant in the global player pool that they'd be a very rare occurance.
Global item pools
This idea has been floated around by Nikita some time ago but we have no ETA on this. In short - for some items, there is only a set amount that is present in circulation. For example there are only X amount of ReapIR's in the entire economy - spawns, traders, player stashes. If everyone hoards them in their stashes - thats where they'll remain. They don't spawn on maps, they're not sold on traders. Only until they're lost they get reinjected into the item pool.
This idea should be reserved only for the absolute top tier OP items. Something that you'd get all giddy if found/looted and you'd contemplate taking it out.
Side note, the X amount should scale to the active playerbase, which could be something like a weekly or biweekly moving average of people actively playing the game in a set period.
Insurance
This one is a bit controversial but also attributes to some of the in game inflation and gear recirculation. If you run a large squad, even if one of you