Last time Bitcoin was at USD 43,- it was quite healthy and part of a flourishing (albeit admittedly largely illegal) economy. Why would that be the "dead of Bitcoin"?
On a less serious note that would also solve the scaling problem as fees would be in the sub-cent area again, even with full blocks.
You clearly didn't bother to the read and understand the article. Typical of "Bitcoiners" when they research something. They cannot read more than one sentence before dropping reading the rest, and then demonstrating their ignorance Besides your quote the article is mostly devoid of content though, what's there to miss? There's not even any mention of how this guy came to that very specific evaluation of USD 43,-. For example this: Unless Bitcoin is able to become more efficient at mining, and more stable overall, it is likely to die. These higher mining costs and the fact that more retailers are failing to accept bitcoin as payment as they are unable to convert it as it is too expensive will mean the end of it. The quote above shows both a lack of understanding of PoW's security principle and is at odds with their prediction of BTC @ USD 43,-. If Bitcoin were to hit USD 43,- or a similar low Bitcoin's mining cost would sink proportionally -- as would its transaction fees in fiat terms, as I jokingly mentioned above. And then this bit: The last situation is when Bitcoin loses its value among people and stops being useful as a payment method. That's just a statement without any backing argument. There's... nothing else. What to say about an article that essentially says nothing? |
|
|
|
|
Last time Bitcoin was at USD 43,- it was quite healthy and part of a flourishing (albeit admittedly largely illegal) economy. Why would that be the "dead of Bitcoin"?
On a less serious note that would also solve the scaling problem as fees would be in the sub-cent area again, even with full blocks.
|
|
|
|
|
All of the above are valid concerns but hold true for gold and precious metals as well. Do you regard those as scams too?
|
|
|
|
|
"Unconfirmed parent" means that the transaction funding the transaction hasn't confirmed yet.
If you are receiving this transaction, then wait for it to confirm.
If you are sending a transaction that is not time-critical, you can also wait.
If you are sending a transaction that is also time-critical, follow BitCryptex's suggestion and increase the fee (you should be able to do so by right-clicking on the affected transaction within your transaction history).
|
|
|
|
But in a realistic scenario, how can Bitcoin hard fork to a new POW algorithm, with consensus, if what it will do is amputate the network of full nodes and hashing power? It will reduce the network's security by a lot.
The proposal of the idea itself is already stupid, unless the mining cartel started to censor transactions.
I seem to remember proposals of doing a gradual shift from SHA-256 to whatever hash Bitcoin would use next, precisely as to avoid (or at least alleviate) this issue, however I can't find the respective threads right now. IIRC this would include a transitional period of hybrid mining. AFAIK these proposals haven't been discussed in earnest though and I'm not quite sure about their viability. Impossible, people who say this are SW people who don't understand HW, the HW people have already said, "No matter how difficult you make your algo or how much memory it uses, we will emulate that algo on an ASIC".
I doubt that "HW people" would say that, given that you emulate hardware using software, not the other way round  |
|
|
|
[...]
Another thing that can be done post 2013, as public-keys were no longer available, is there is a lot of non-noise high quality data in the digital-signatures posted in the block chain. There are endless ways to hack bitcoin
Brainflayer can be re-deployed to find private-keys based on public-keys, and no-noise data, rather than simply hashing strings and using that as a priv-key compare
Vanity-Gen can be re-deployed with bloom-filters and used to search for all used addresses for all clones&bitcoin at once,using optimized private-key blocks using DLP algo's
What's preventing a would-be attacker from deploying any of these methods? What are the challenges they are facing? Serious question. At least to me the above sentences read pretty much like bullshit and a random assembly of technical terms but maybe it simply requires a more precise description of said techniques. As described they sound neither theoretically plausible nor practically feasible. |
|
|
|
Problem being, where to get the mining hardware? You'd still need current the hashrate and them some to mount an attack.
I think an attacker having the funds to buy the necessary hardware should also have the funds to develop it straight away and pay a foundry to produce the ASICs. Also, an 51% attack most likely isn't a goal accomplishable in some days or weeks - but the attacker has all the time he wants to prepare it (and buy/develop/rent hardware). Oh yes that's true. To elaborate, I was thinking about the case of an attacker buying / developing / producing a sufficient amount of mining hardware at rather short notice. That I deem close to impossible, even given generous funding (ie. money can speed things up only within a limited margin as the law of diminishing returns kicks in). Time for preparation may be plenty, but once the preparations are done the clock is ticking -- an attacker only has a limited timeframe before their hardware becomes obsolete. Come to think of it, I believe there's a flaw in trying to suppress Bitcoin's price to make 51% attacks easier -- you'd have to buy in first, which would likely prop up the price and consequently the overall hashrate. I might underestimate OTC markets and the impact of derivatives though. |
|
|
|
|
Yep. I guess many people are still drunk on the bull run of 2017, some newcomers may even believe that it's the norm. But it definitely isn't, as anyone that followed crypto from 2014 - 2016 can attest. Currently it looks like we're about to enter another crypto winter, let's see how long it lasts.
|
|
|
|
[...]
I could imagine a consortia of farmers who decide to have their own coin as a new rival to bitcoin. they should be insane to break down the bitcoin and then advertise their new coin, this is not how the market work - a continuous pumping/dumping in prices of all coins do. do a little math, assume that you have 2000 BTC in your pocket and you also have a farm with 1 PH/s processing power. you are also a member of consortia which enrolls 20 PH/s of the bitcoin.
now when BTC is in 7000 USD, you could sell 1000 of your coins and divert your hash power into a fork that you could buy 10'000 of them at 5 USD. you tell me, what happens if the price of BTC dumps down to 4000 USD and the price of new forked coin pumps up to 15 USD (downgraded hash-power and electricity usage)?
just in the BTC part, you can save 3000 USD x 1000 BTC = 3'000'000 USD for investment in a new fork just by diverting your hash power and by (buying those 1000 BTC back) diverting you hash-power back to BTC when the price is 7000 USD again you could earn another 3'000'000 USD, why you should attack it?! I call it a shadowed social attack to BTC users. Are the parallels to Bitcoin Cash intentional? :3 Currently it definitely seems like social attacks would be the most effective way to damage Bitcoin in the long term. sometimes I think about 10 miners that 8 of them have 10% of hash power and the ninth with 9% and the tenth with 11% and while they all are in parallel processing, why the tenth miner won't be able to hide himself and solve the nonce quicker than the other miners?
The miner with 11% of the hashrate is able to check more nonces within the same timeframe, therefore they will find on average more blocks than their competition causing their hashrate superiority to be visible to the public (within a margin of error). That all miners are working in parallel doesn't change that. |
|
|
|
UPDATED: I found this website with amazing collection of coins and the theoretical cost of a 51% attack on each network: https://www.crypto51.app/Thanks for the provided link. Upon checking it out, I found out that the cost needed to successfully launch a 51% BTC attack is just $285,785 at the current hash rate of 42,023 PH/s (an one hour attack). Does this mean the attack would work for one hour as soon as someone pays around $300k for rented equipment? It seems quite cheap in my opinion. For us it might be extremely expensive and unimaginable to spend this much just for a 1hr attack, but what if a millionaire - or billionaire - decides to do this? It's possible, right? Could someone explain the NiceHash part? It says BTC is 1% NiceHashable, what does that mean? That attack cost is calculated using NiceHash's pricing which sounds like a nice metric in theory, but given a sufficiently strong network is completely useless in practice: Using the prices NiceHash lists for different algorithms we are able to calculate how much it would cost to rent enough hashing power to match the current network hashing power for an hour. Nicehash does not have enough hashing power for most larger coins, so we also calculated what percentage of the needed hashing power is available from Nicehash. BTC being 1% NiceHashable means that purchasing all available hashing power of NiceHash would only yield you 1% of Bitcoin's network making this a rather losing proposition. So no, you can't simply waltz in and buy Bitcoin's majority hashrate. |
|
|
|
Holy shit so that was the mystery payload of the event-stream backdoor! :O Here's the GitHub discussion for anyone interested; when the backdoor was first found its intention was not yet clear: https://github.com/dominictarr/event-stream/issues/116Despite the severity of the issue, I don't fully agree with the article's condemnation of BitPay's practices. I also don't think that event-stream's original maintainer deserves all the flak he got. However it goes to show how shaky modern JavaScript development is from a security perspective. Event-stream is an extremely popular npm package and as such is rather trusted and used in a lot of other applications. As such it could have hit any other Node.js based wallet as well. This is a problem with modern JavaScript development in general, rather than with BitPay specificially. |
|
|
|
|
Nah man, there's still way too little despair in the air. The streets need to run red with the blood of traders and hodlers alike as everyone loses their hope and feels their investments turn to ash. There's no bottom as long as people even dare calling the bottom.
|
|
|
|
No. A block that includes a double-spend is invalid and as such will be discarded by the other nodes. (both mining and non-mining nodes) Edit: If I recall correctly a misusage of this function is what caused vulnerability CVE-201817144, which would have potentially allowed for double-spend attacks the way you described. Thank you. You're welcome. I did a little digging and if I'm not mistaken this was the commit that fixed it: https://github.com/bitcoin/bitcoin/commit/4b8a3f5d235f40be8102506ab26caad005cc40d6I'm not sure why they didn't remove the comment about skipping this check in CheckBlock() though. |
|
|
|
No. A block that includes a double-spend is invalid and as such will be discarded by the other nodes. (both mining and non-mining nodes) Edit: If I recall correctly a misusage of this function is what caused vulnerability CVE-201817144, which would have potentially allowed for double-spend attacks the way you described. |
|
|
|
|
How much did you intend to send to each address?
Can you double check with both recipients (the exchange and whoever the other recipient was) that the addresses you sent them to are correct?
There is known malware out there that changes recipient addresses when copy-pasting, maybe you've become a victim of one of those.
|
|
|
|
|
Sounds neat, but I personally wouldn't use it.
The Bitcoin price I keep track of as is and what little alts I hold I only pay attention to during bull markets. Smaller day-to-day price fluctuations I don't act upon and beyond that I don't see any practical use for me except for maybe aggrevating an already unhealthy habit of regular chart-checking.
|
|
|
|
[...]
Most of this stuff is right-time, at the right-place, many a people had tried to launch and digital-cash, this was the first that stuck to the wall,
Columbus being at a party with many noble Spaniards, where, as was customary, the subject of conversation was the Indies: one of them undertook to say: "Mr. Christopher, even if you had not found the Indies, we should not have been devoid of a man who would have attempted the same that you did, here in our own country of Spain, as it is full of great men clever in cosmography and literature." Columbus said nothing in answer to these words, but having desired an egg to be brought to him, he placed it on the table saying: "Gentlemen, I will lay a wager with any of you, that you will not make this egg stand up as I will, naked and without anything at all." They all tried, and no one succeeded in making it stand up. When the egg came round to the hands of Columbus, by beating it down on the table he fixed it, having thus crushed a little of one end; wherefore all remained confused, understanding what he would have said: that after the deed is done, everybody knows how to do it; that they ought first to have sought for the Indies, and not laugh at him who had sought for it first, while they for some time had been laughing, and wondered at it as an impossibility. The only thing novel in satoshis orginal paper was his estimation on how to solve the double-spending-problem [...]
Solving the double-spending problem in a trustless, decentralized system is one of the most revolutionary singular breakthroughs in computer science though. It was one of the problems that prior to satoshis work was deemed unsolvable by many. That's not too shabby. |
|
|
|
|
I doubt a 51% attack would be viable (or close to viable) just yet, the cost is simply still too high.
Problem being, where to get the mining hardware? You'd still need current the hashrate and them some to mount an attack.
The currently known large mining hardware producers are unlikely to defect this way, as that would be throwing away a profitable million dollar business.
The hardware that dropped off the network could probably be bought for cheap but that would be (a) an enormous logistical challenge, assuming we're talking about multiple unrelated operations across the globe, (b) hardware that is most likely outdated, given that unprofitable miners will drop off first and (c) still way too little hashing power.
What is left is either (a) buying miners wholesale from mining hardware producers or (b) developing mining hardware from scratch. Both incredibly expensive and both options that would take a lot of preparation time (ie. in case of (a) only a limited quantity of miners are in stock at any given time so you can't buy all at once, in case of (b) research and development and having the miners produced).
In short, the only ones potentially capable of attacking Bitcoin, even considering a continuous decline of hashrate, are the ones that already have skin in the game. At the point that Bitcoin becomes effectively attackable for an outside adversary it's likely not worth attacking anymore anyway.
|
|
|
|
How can Nodes protect me from Double spending? What if i have like 10000 and ever more of Raspberry Pis at my home and therefore the maxm. no. of nodes in the network wid all of them saying DOUBLE SPENDED transcation is the real one??? Would it mean, if i as i miner, successfully double spended my coins?
To extend on achow101's comment: The attack scenario you describe is also known as a Sybil attack. It's one of the reasons why Proof of Work was introduced as a consensus mechanism -- it's relatively easy to fake being multiple peers (e.g. by using thousands of Raspis), but it's impossible to fake Proof of Work. |
|
|
|
Or should the block chain history be packed for storage scaling problems?
Storage scaling problems ? The size of the blockchain isn't a problem at all. Storage is getting cheaper each year, way faster than the blockchain can grow. 9 years of BTC gave us ~180 GB. With a 1TB HD at about 60$, thats not even close to being a problem. [...] I doubt that storage could keep up if Bitcoin were to use, say, 1 GB blocks like some on the extreme end of on-chain scaling have been proposing. I do agree though that storage is the lesser problem. More acute problems regarding blocksize are bandwidth and network propagation. |
|
|
|
|
Show Posts
