You cannot be stopped apparently.
Topic: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion - page 3604. (Read 26608145 times)
April 22, 2022, 06:22:15 AM
Guys, if you want to hang around women's bathrooms all day you can simply enrol at the University of Plymouth.
You cannot be stopped apparently.
You cannot be stopped apparently.
April 22, 2022, 06:03:28 AM
April 22, 2022, 05:48:10 AM
April 22, 2022, 05:46:59 AM
April 22, 2022, 05:19:35 AM
Hopefully, you'll find it interesting:
The expensive average transaction fees in the article you posted is not correct, from my understanding and experience it is centralized exchanges that charge outrageous fees like that and maybe their high fees is also used to build up this statistic, if you use non-custodial wallets you will pay a normal and cheap fee especially when you use a segwit address, consolidate your inputs, check the mempool first, and use lightning network in exchanges that have integrated it.
Banks like high fees. It's their MO.
April 22, 2022, 05:14:53 AM
~snip~
~snip~
~snip~
Hey CB please stop this $40k gameplay as we are fed up with this and want now to move on because the pump for ants is also coming back and forth taking us back to $40k range only each time.So step up and take us to next doors :
Now it's getting hard for us so please push us and feed yourself with some green pump sandwiches and pump smoothie
April 22, 2022, 05:04:55 AM
April 22, 2022, 04:39:54 AM
My friend is a serious guy, he will likely ask various others and move slowly. (I am not all that serious, but do move slowly.) I did tell him to edge into any purchases, I should have mentioned JJG's Dollar Cost Averaging thoughts in regards to his budget, goals and financial means. He DID tell me he is OK with volatility and thinking long term, and I believe that.
I hope that he does not get suckered into ALTS, but that is his decision.
He's not a programmer either -- I hardly know any of them, looks like I come from a different space than most here..
I hope that he does not get suckered into ALTS, but that is his decision.
He's not a programmer either -- I hardly know any of them, looks like I come from a different space than most here..
For sure, DCA and incrementalism is a practice that goes way beyond my thinking - even though I do harp on it quite a bit regarding the main part of any common practice that someone just getting into bitcoin should consider.
I share a lot of your frustration with your friend because a lot of people might already know about DCA and they are receptive to the idea of DCA - yet when they are into not seeming to sufficiently understand the difference between shitcoins and bitcoin, they also end up applying DCA to shitcoins (at least many of us bitcoiners who might have some dabblings with shitcoins recognize and appreciate that they are not long term investments - but surely even long term bitcoiners get confused about that point, too).
I frequently seem to be throwing out the idea that DCA works as a method for long term investing because there has already been a determination that either fundamentals are strong in the underlying asset or that there is reason to believe that a determination can possibly later be made that fundamentals are strong in the underlying asset - which for bitcoin has largely come to mean that there are pretty decent odds that no matter what period that anyone starts investing into bitcoin, the price has quite likely strong chances of being higher 4-10 years later in real terms than it was at the time of the purchase, and the odds of the DCA investor to continue to bring down cost per BTC in the event that the price ends up turning against him/her and going down. So in some sense DCA works best when the BTC price is waffling all over the place including getting stuck in a spiraling downtrend, but DCA does not work as well when the BTC price gets on one of its decently long term UP trends. Lump sum investing would work better in those instances - but still lump sum investing takes way more knowledge regarding market dynamics than a DCA approach.
One way of attempting to partially address the dilemma of a problem in which the BTC price may well go up a lot in the short-term is to engage in a bit of a frontloading of the investment - and of course, another dilemma will still be presented regarding how much to frontload.. .We can also recognize that not everyone has the luxury of frontloading their investment either because they do not necessarily have a lump sum amount in which they can choose how to "get started," but for those who do have some kind of potential lump sum amount that they can potentially frontload into their bitcoin investment I tend to consider to strt by dividing that lump sum amount and also a period of cashflow for the next 6 months for example, and then adding all those up and then dividing into three parts one part lump sum, one part DCA and one part buying on dips... the answer regarding how to divy it up exactly over those first six months is not necessarily be obvious - because there would surely need to be quite a bit of accounting for individual circumstances and the employment of discretion that also attempts to account for timeline, other investments, view of bitcoin compared with other investments, risk tolerance and time, skills and abilities to plan, strategize and to learn and tweak along the way and in more advanced approaches (surely not necessary to get started) may well include the use of financial instruments and leverage, trading and reallocation from time to time (also reallocation may or may not be necessary or even advantageous... but of course, discretionary and individuals should be attempting to engage in their investment at least sufficiently to take responsibility over each and all of their investment portfolio - initial allocations and then managing it as it "hopefully" grows.).
So for sure what I am saying is that people tend to get quite confused (I did as well, and probably quite few other people got confused early in their coming to bitcoin), and then we end up wanting to diversify into some various shitcoin projects and attempt to pick the "best of the shitcoins" or the "better of the shitcoins" which does not tend to be a great approach rather than just picking the sector leader, which is quite obviously bitcoin. It seems that people have to learn that bitcoin is the sector leader on their own and probably takes some time - and maybe having them watch around 30-50 Michael Saylor videos might help them out in terms of coming to the conclusion that it makes little to no sense to diversify into shitcoins once the sector leader has been identified.... For starts on a great Saylor clip, go back to that Saylor clip that AlcoHoDL had provided from 2021 and click on the youtube link therein.... it took me a while to find that post.
Great advice.
I watched that clip again, thanks for the reminder. It never gets old. Recommended for newbies and for everyone really.
As for shitcoins and exploring them at the beginning of our Bitcoin journey, I will confess that I also experimented with a few shitcoins back then. Nothing major, I really can't remember the exact allocation then, it was probably something like 95% Bitcoin vs. 5% shitcoins. I still own those shitcoins, I have almost forgotten about them, and the current allocation is more like 99.9% Bitcoin vs. 0.1% shitcoins, which, in itself is a good indicator of Bitcoin vs. shitcoin performance over the 5-6 years I've had them. In terms of numbers, and these are very rough estimates, my Bitcoin investment has grown to about 25x, while my shitcoin investment has grown to a meager 2x. Had I thrown everything in Bitcoin back then, I would have ended up with a few more BTC in my stash.
25x vs. 2x. Something to think about, for those who still have faith in shitcoins...
April 22, 2022, 04:03:33 AM
April 22, 2022, 03:58:01 AM
CasaHODL went woke SJW, so, it's nice to see they are looking to lose so much business with their bravery.
See Twitter, tl;dr: "we need more womens and colored hoomanz working 4 uz!"
Fucking retarded space rock.
See Twitter, tl;dr: "we need more womens and colored hoomanz working 4 uz!"
Fucking retarded space rock.
They don't need to go woke to go broke.
$5000 a year to help look after your stash, that's a lot of pizzas.
Their pricing alone will sink them.
April 22, 2022, 03:45:57 AM
King make its own history.
April 22, 2022, 03:03:27 AM
April 22, 2022, 02:55:40 AM
Bitcoin Firm Crusoe Energy Raises $505 Million to Grow Flare-Gas Mining Business
https://decrypt.co/98424/bitcoin-firm-crusoe-energy-raises-505-million-grow-flare-gas-mining-business
April 22, 2022, 02:28:43 AM
Climate measures: Behind closed doors, EU officials talk about banning Bitcoin
Quote
If Ethereum is able to shift, we could legitimately request the same from BTC. We need to “protect” other crypto coins that are sustainable. Don’t see need to “protect” the bitcoin community.
Quote from: Patrick Hansen (@paddi_hansen)
These are older minutes and docs from meetings back in Nov 21 or Feb 22, even before the PoW-ban amendment made it into MiCA and was thankfully voted against in the EU Parliament.
So although the policy discussion around PoW will continue, this article is mainly FUD right now.
So although the policy discussion around PoW will continue, this article is mainly FUD right now.
https://twitter.com/paddi_hansen/status/1517120815187337216?t=prsg2LdKQGcV-Fll6Xl2QQ&s=03
April 22, 2022, 02:23:04 AM
April 22, 2022, 02:03:28 AM
April 22, 2022, 01:10:46 AM
My friend is a serious guy, he will likely ask various others and move slowly. (I am not all that serious, but do move slowly.) I did tell him to edge into any purchases, I should have mentioned JJG's Dollar Cost Averaging thoughts in regards to his budget, goals and financial means. He DID tell me he is OK with volatility and thinking long term, and I believe that.
I hope that he does not get suckered into ALTS, but that is his decision.
He's not a programmer either -- I hardly know any of them, looks like I come from a different space than most here..
I hope that he does not get suckered into ALTS, but that is his decision.
He's not a programmer either -- I hardly know any of them, looks like I come from a different space than most here..
For sure, DCA and incrementalism is a practice that goes way beyond my thinking - even though I do harp on it quite a bit regarding the main part of any common practice that someone just getting into bitcoin should consider.
I share a lot of your frustration with your friend because a lot of people might already know about DCA and they are receptive to the idea of DCA - yet when they are into not seeming to sufficiently understand the difference between shitcoins and bitcoin, they also end up applying DCA to shitcoins (at least many of us bitcoiners who might have some dabblings with shitcoins recognize and appreciate that they are not long term investments - but surely even long term bitcoiners get confused about that point, too).
I frequently seem to be throwing out the idea that DCA works as a method for long term investing because there has already been a determination that either fundamentals are strong in the underlying asset or that there is reason to believe that a determination can possibly later be made that fundamentals are strong in the underlying asset - which for bitcoin has largely come to mean that there are pretty decent odds that no matter what period that anyone starts investing into bitcoin, the price has quite likely strong chances of being higher 4-10 years later in real terms than it was at the time of the purchase, and the odds of the DCA investor to continue to bring down cost per BTC in the event that the price ends up turning against him/her and going down. So in some sense DCA works best when the BTC price is waffling all over the place including getting stuck in a spiraling downtrend, but DCA does not work as well when the BTC price gets on one of its decently long term UP trends. Lump sum investing would work better in those instances - but still lump sum investing takes way more knowledge regarding market dynamics than a DCA approach.
One way of attempting to partially address the dilemma of a problem in which the BTC price may well go up a lot in the short-term is to engage in a bit of a frontloading of the investment - and of course, another dilemma will still be presented regarding how much to frontload.. .We can also recognize that not everyone has the luxury of frontloading their investment either because they do not necessarily have a lump sum amount in which they can choose how to "get started," but for those who do have some kind of potential lump sum amount that they can potentially frontload into their bitcoin investment I tend to consider to strt by dividing that lump sum amount and also a period of cashflow for the next 6 months for example, and then adding all those up and then dividing into three parts one part lump sum, one part DCA and one part buying on dips... the answer regarding how to divy it up exactly over those first six months is not necessarily be obvious - because there would surely need to be quite a bit of accounting for individual circumstances and the employment of discretion that also attempts to account for timeline, other investments, view of bitcoin compared with other investments, risk tolerance and time, skills and abilities to plan, strategize and to learn and tweak along the way and in more advanced approaches (surely not necessary to get started) may well include the use of financial instruments and leverage, trading and reallocation from time to time (also reallocation may or may not be necessary or even advantageous... but of course, discretionary and individuals should be attempting to engage in their investment at least sufficiently to take responsibility over each and all of their investment portfolio - initial allocations and then managing it as it "hopefully" grows.).
So for sure what I am saying is that people tend to get quite confused (I did as well, and probably quite few other people got confused early in their coming to bitcoin), and then we end up wanting to diversify into some various shitcoin projects and attempt to pick the "best of the shitcoins" or the "better of the shitcoins" which does not tend to be a great approach rather than just picking the sector leader, which is quite obviously bitcoin. It seems that people have to learn that bitcoin is the sector leader on their own and probably takes some time - and maybe having them watch around 30-50 Michael Saylor videos might help them out in terms of coming to the conclusion that it makes little to no sense to diversify into shitcoins once the sector leader has been identified.... For starts on a great Saylor clip, go back to that Saylor clip that AlcoHoDL had provided from 2021 and click on the youtube link therein.... it took me a while to find that post.
April 22, 2022, 01:03:32 AM
April 22, 2022, 12:53:49 AM
Quote
“It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs.”
The bug, tracked as CVE-2022-21449, carries a severity rating of 7.5 out of a possible 10, but Madden said based on his assessment, he’d rate the severity at a perfect 10 “due to the wide range of impacts on different functionality in an access management context.” In its grimmest form, the bug could be exploited by someone outside a vulnerable network with no verification at all.
Other security experts also had strong reactions, with one declaring it “the crypto bug of the year.”
A mitigating factor is that Java versions 15 and above don’t appear to be as widely used as earlier versions. Data collected in February and March 2021 from security firm Snyk showed that Java 15, the latest version at that time, accounted for 12 percent of deployments. While Madden said that the specific ECDSA implementation flaw affected only Java 15 and higher, Oracle also listed versions 7, 8, and 11 as vulnerable. Madden said that the discrepancy may result from separate crypto bugs fixed in the earlier releases.
a/0 = valid signature
ECDSA signatures rely on a pseudo-random number, typically notated as K, that’s used to derive two additional numbers, R and S. To verify a signature as valid, a party must check the equation involving R and S, the signer’s public key, and a cryptographic hash of the message. When both sides of the equation are equal, the signature is valid.
In a writeup published Wednesday, security firm Sophos further explained the process:
S1. Select a cryptographically sound random integer K between 1 and N-1 inclusive.
S2. Compute R from K using Elliptic Curve multiplication.
S3. In the unlikely event that R is zero, go back to step 1 and start over.
S4. Compute S from K, R, the hash to be signed, and the private key.
S5. In the unlikely event that S is zero, go back to step 1 and start over.
For the process to work correctly, neither R nor S can ever be a zero. That’s because one side of the equation is R, and the other is multiplied by R and a value from S. If the values are both 0, the verification check translates to 0 = 0 X (other values from the private key and hash), which will be true regardless of the additional values. That means an adversary only needs to submit a blank signature to pass the verification check successfully.
Madden wrote:
Guess which check Java forgot?
That’s right. Java’s implementation of ECDSA signature verification didn’t check if R or S were zero, so you could produce a signature value in which they are both 0 (appropriately encoded) and Java would accept it as a valid signature for any message and for any public key. The digital equivalent of a blank ID card.
Below is an interactive JShell session Madden created that shows a vulnerable implementation accepting a blank signature as valid when verifying a message and public key:
| Welcome to JShell -- Version 17.0.1
| For an introduction type: /help intro
jshell> import java.security.*
jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@626b2d4a
jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true
// Oops, that shouldn't have verified...
Organizations that are using any of the affected versions of Java to validate signatures should place a high priority on patching. It will also be important to monitor for advisories from app and product makers to see if any of their wares are made vulnerable. While the threat from CVE-2022-21449 appears limited to new Java versions, its severity is high enough to warrant vigilance.
The bug, tracked as CVE-2022-21449, carries a severity rating of 7.5 out of a possible 10, but Madden said based on his assessment, he’d rate the severity at a perfect 10 “due to the wide range of impacts on different functionality in an access management context.” In its grimmest form, the bug could be exploited by someone outside a vulnerable network with no verification at all.
Other security experts also had strong reactions, with one declaring it “the crypto bug of the year.”
A mitigating factor is that Java versions 15 and above don’t appear to be as widely used as earlier versions. Data collected in February and March 2021 from security firm Snyk showed that Java 15, the latest version at that time, accounted for 12 percent of deployments. While Madden said that the specific ECDSA implementation flaw affected only Java 15 and higher, Oracle also listed versions 7, 8, and 11 as vulnerable. Madden said that the discrepancy may result from separate crypto bugs fixed in the earlier releases.
a/0 = valid signature
ECDSA signatures rely on a pseudo-random number, typically notated as K, that’s used to derive two additional numbers, R and S. To verify a signature as valid, a party must check the equation involving R and S, the signer’s public key, and a cryptographic hash of the message. When both sides of the equation are equal, the signature is valid.
In a writeup published Wednesday, security firm Sophos further explained the process:
S1. Select a cryptographically sound random integer K between 1 and N-1 inclusive.
S2. Compute R from K using Elliptic Curve multiplication.
S3. In the unlikely event that R is zero, go back to step 1 and start over.
S4. Compute S from K, R, the hash to be signed, and the private key.
S5. In the unlikely event that S is zero, go back to step 1 and start over.
For the process to work correctly, neither R nor S can ever be a zero. That’s because one side of the equation is R, and the other is multiplied by R and a value from S. If the values are both 0, the verification check translates to 0 = 0 X (other values from the private key and hash), which will be true regardless of the additional values. That means an adversary only needs to submit a blank signature to pass the verification check successfully.
Madden wrote:
Guess which check Java forgot?
That’s right. Java’s implementation of ECDSA signature verification didn’t check if R or S were zero, so you could produce a signature value in which they are both 0 (appropriately encoded) and Java would accept it as a valid signature for any message and for any public key. The digital equivalent of a blank ID card.
Below is an interactive JShell session Madden created that shows a vulnerable implementation accepting a blank signature as valid when verifying a message and public key:
| Welcome to JShell -- Version 17.0.1
| For an introduction type: /help intro
jshell> import java.security.*
jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@626b2d4a
jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true
// Oops, that shouldn't have verified...
Organizations that are using any of the affected versions of Java to validate signatures should place a high priority on patching. It will also be important to monitor for advisories from app and product makers to see if any of their wares are made vulnerable. While the threat from CVE-2022-21449 appears limited to new Java versions, its severity is high enough to warrant vigilance.
https://arstechnica.com/information-technology/2022/04/major-crypto-blunder-in-java-enables-psychic-paper-forgeries/
Jump to: