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. [...] Given Bitcoin's current blocksize policy.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.
|
|
|
You can only post technical comments on the forum if you believe that Bitcoin is the best software ever invented and the price of bitcoin can only ever go up. [...]
Incorrect assertions and repeated off-topic ramblings about "CPU-wars" and "casino operators" while adding little substance to the topic at hand are not technical comments. They are just incorrect assertions and off-topic ramblings, regardless of whether they are "Pro" or "Anti" Bitcoin. As such they may eventually fall victim to deletion, especially in the more technical sections of Bitcointalk.
|
|
|
To also chime in: If I'd wanted fiat rates I would have joined one of the campaigns that do so. I also very much appreciate ChipMixer sticking to their rates even during the last moon phase.
|
|
|
The main vulnerability of Bitcoin or any system are the users. [...]
Now if the goal is to hack bitcoin users, then i can think in 2 ways, the first one is with trojans and keyloggers you know... the old school way. I have seen users who get hacked trying to play Mario for bitcoin, lol. And the other way i would recommend is the MITM attack, of course, you need to do this attack in the same network of the victim, but if you go to a bitcoin conference and poison the network, every guy there will be vulned.
Good point. I guess social engineering is more effective than any direct attack on Bitcoin can ever be, so I'd probably add: 1) Create a shitcoin or shitfork for pump-and-dumping (disclaimer: I don't believe all alts are bad) 2) Create an ICO and spend years "developing" your "project" (disclaimer: I'm not so sure about ICOs though) 3) Run a HYIP 4) Offer cloud mining (essentially a HYIP without the H) (using a rather loose definition of social engineering, that is)
|
|
|
So Bitcoin has 21,000,000.00000000 in existence. How does someone determine how many zeros are placed behind it? Could someone make an asset that has 1 coin but 1.910980182309824791827981240912094109249129837 in total token supply ?
Yes? Not using 64 bit Integers such as Bitcoin uses. Even using unsigned 64 bit Integers the largest number that can be stored precisely is 2^64 or roughly 10^19. OP's example of 1.910980182309824791827981240912094109249129837 being in the range of 10^45, would require 256 bit Integers (ie. 2^256 or roughly 10^77) as even 128 bit integers (~ 10^38) would lack precision. Note that in common programming languages 64 bit integers is all you get (if even that), 128 bit if you have long doubles at your disposal. Everything beyond that requires a custom implementation. Side note on precision, for those unfamiliar with software development: Storing a number beyond the precision level of a numeric data-type leads to one of the following outcomes: For (a) integers, the number wraps around, like it would with the odomoter of a car (ie. starting from zero, if the integer is unsigned or starting from the lowest negative number, if the integer is signed), for (b) floating point numbers (ie. if the the position of the decimal point is stored as well), it essentially starts truncating the last few digits. Neither which is desirable for monetary transactions. Not as part of token supply calculations. This paper is suggesting an alternative to RSA's asymmetric encryption scheme and is unlikely to make any sense as far as storing transaction amounts is concerned.
|
|
|
Actually, hack is the last label one ever could find appropriate for brute forcing hashed public keys. A lot of literature out there showing how dumb it would be attempting such an attack. And it is brute force, clueless naive brute force, forget about AI and QC, neither of the two would be of little help in this context.
I prefer the first two methods. Keep generating as many key pairs as you can and wait. As much chance of getting lucky as solo mining. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) If you solo mine with a single Antminer S9 (ie. 14.5 TH/s) your chance of finding a block within a year is approx 1.9053% (assuming an average total network hashrate of 40,000,000 TH/s [1]). 14.5 TH/s of 40,000,000 TH/s = 0.00003625% 144 blocks/day * 365 = 52,560 blocks/year 52,560 blocks/year * 0.00003625% = 1.9053% If you bruteforce Bitcoin's key space using all computational power currently available to the Large Bitcoin Collider at roughly 365 Mkeys/s [2] your chance of finding an active private key within a year is approx 0.000000000000000000000000055% (assuming 550,000 used addresses [3]). 365 Mkey/s = 31.5 Tkey/day = 1.14975 * 10^16 keys/year 10^16 scanned keys * 550,000 used addresses of 10^48 (ie. 2^160 of 2^256 due to RIPEMD-160) = 5.5% * 10^-25 TLDR; You're approx 10^25 times less likely to find a private key with balance using hundreds of machines than you are to successfully mine a block using a single miner. That's the likeliness of getting hit by lightning during the same timeframe -- four times [4]. So not quite the same chance as getting lucky solo mining ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) [1] https://www.blockchain.com/en/charts/hash-rate[2] https://lbc.cryptoguru.org/stats[3] https://www.blockchain.com/charts/n-unique-addresses[4] https://www.cbs17.com/news/odds-of-winning-powerball-jackpot-less-than-being-hit-by-lightning-twice/1082701256
|
|
|
I'm not going anywhere, so I'd prefer a slow but steady growth. This would also be more beneficial to Bitcoin's usage as a currency or store of value, rather than being the high-risk high-reward kind of asset it currently represents. Profits are nice, but I want a long-lived technology as well.
It can't be denied though that Bitcoin's growth spikes are what lead to its popularity in the first place. Volatility and drama catches more eyes than reliability. As such I think of Bitcoin's growth spikes as a necessary evil until we've reached widespread adoption.
|
|
|
I guess when you connect fake Trezor to original UI it should work same as original, otherwise it would not make sense for forgers to make and sell them. The only question is whether such a device is made for intention to steal users coins, or it is just a identical copy made with a reason to profit on sales.
Does the Trezor not show a warning about using a modified firmware? I was sure that it had a warning if a firmware that was not signed by SatoshiLabs was loaded... at least as far back as March this year anyway... https://blog.trezor.io/trezor-one-firmware-update-1-6-1-eecd0534ab95So are these 1:1 copies using modified Firmware AND Bootloaders? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) SatoshiLabs haven't really mentioned much... and seem to say that only by looking at the box and label... no onscreen warnings??!? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) Trezors come only with the bootloader pre-installed, the firmware is installed when first initializing the device making sure one can start from a clean slate. Presumably the Trezor clones use the same bootloader, allowing it to install and run the official firmware. If that's the case no warning will be shown on the web interface. Problem being that while the software may be verified, you have no way of knowing whether the hardware is trustworthy. They could have used less secure components, they could have installed a backdoor on the hardware level, etc.
|
|
|
I do think it's important to point out that a 51% attack (however unlikely) is not a mere double-spend attack which can be averted by awaiting an appropiate confirmation count. Any adversary holding 51% of the hashrate will always outmine their competitors, for as long as they are able to uphold the majority hashrate. (again, completely ignoring the economics of such an attack) Sure they will but why ignoring economics? It is all about economics isn't it? [...] Because we're talking about the hypothetical! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Do you look at a drawing of a Pegasus and are like "Wait a minute, those wings are way too small for a creature of this size, why would someone even draw this it makes no sense!"? Your arguments about the attacker switching back to another coin after ruining the one under attack is correct, but does not lead to anything new, once he leaves everything is restored and he has been rewarded by a bunch of now worthless coins, given he has not managed to fool some reckless merchant or exchange to buy a reverted transaction. Assuming they are after the coins. Considering all the drama going on I wouldn't dismiss mining attacks out of political reasons (*cough* Bitcoin ABC vs Bitcoin SV *cough*) The cost of attacking your cash cow is: Electricity + Deprecation of the mined coins + Making your mining equipment useless The cost of attacking a minority coin is "only": Electricity + Deprecation of the mined coins And please note, bitcoin started with a few desktop computers and took almost a decade to reach the current state in which like 200k$ a day (at least) worth of electricity is being spent for its security and yet it has been always secure against 50%+1 attack from the first day because of the beauty of PoW and the equilibrium state between incentives and costs involved in such an attack.
Excellent point, but back then all computational power that went into mining simply went into Bitcoin. Nowadays there's massive computational power floating between whatever coins are most profitable to mine at the time. Well, there is one thing that we should consider: "genesis block mined by CPU". This obviously influences the early consensus estimations of PoW. Just like the effect of center of mass in Pisa Tower, the granted tolerance of forces is important to the final stability. Even adding equal huge amounts of forces in different direction of Pisa Tower may still preserve its stability, but this time they are far above the granted tolerance and absence of one force in one moment will break down that beautiful tower..
[...]
How does this analogy apply to Bitcoin and PoW? A blockchain is not less stable merely because early blocks were mined at a lower difficulty. and let me add another note here.. the incentives are different among FARMERS (huge facilities of mining) and MINERS (rigs at home). miners do mine for fun, opinion, curiosity, learning or investment. miners also 100% own their tools (paid in cash) and usually have no employees and are loyal to some coins. but farmers are a group of stakeholders who invest in setting up huge mining facilities (paid by loans) just for PROFIT and have employees for physical security, accounting, operation, etc. farmers also are not loyal to a specific coin - even if they equip their farms by ASIC devices.
therefore these two group of miners show different reactions in pricing crisis. it seems we always could count on MINERS group.
Commercial miners will usually be able to mine much cheaper than hobby miners, due to economics of scales. So while a hobby miner may be willing to mine less profitably, commercial miners are able to stick around longer due to larger profit margins. Therefore I don't think hobby miners are necessarily more likely to keep mining during a bear market than commercial miners. I do think that hobby miners are more likely to hold onto their mined coins than commercial miners though, due to the latter's requirement to keep a consistent (fiat) cashflow.
|
|
|
One problem with TA is that nobody actually keeps track of its results. The result is that people remember the times that it worked for them, and they discount or forget the times when it didn't. People want to believe that there is a magic formula so much that they ignore the evidence against it. that's not really a claim about TA so much as a claim about most of its practitioners. serious traders always backtest their trading systems. one of the reasons i transitioned from poker to day trading was because i saw opportunities to repeatedly grind out statistical edges. [...] If you backtest a sufficient amount of strategies you're statistically bound to find a "successful" strategy eventually though. Put differently, you can find "patterns" in any snippet of random data if you look long enough, that doesn't make the pattern applicable to larger amounts of random data from the same source though. How to ensure that the backtesting results are actually sound and not just some random fluke? Serious question, not a rethorical one.
|
|
|
Bitcoin won't face this problem in 2038 as bitcoin use unsigned 32-bit/4-byte int
Yep, in the case of Bitcoin it will be a year 2106 problem [1]. I don't think migrating to another dataformat will be of much trouble though. If other software is able to mitigate the year 2038 problem in time, so will Bitcoin. [1] https://en.bitcoin.it/wiki/Block_timestamp
|
|
|
2- Limited user vulnerability: The main targets of 50%+1 attack with its short-range chain rewrite consequences are merchants and exchanges that do not take proper security measures by waiting for enough confirmations (blockchain growth) for high stake transactions. This vulnerability could be mitigated if users closely observe the network overall 50%+1 attack cost and wait for more confirmations up to safe thresholds.
I think this piece of code in JavaScript could help merchants to understand how much confirmations would be enough for their trades - so mitigate the vulnerability. Wallets could generate such information for end users: https://people.xiph.org/~greg/attack_success.htmlThat's the thing about 51% attacks though, there is no safe confirmation count for as long as a 51% attack is going on. As much as I appreciate your good knowledge in the field, I strongly denounce above argument. It contradicts with the most fundamental idea behind security of bitcoin and other PoW cryptocurrencies. I think you are underestimating the importance of such a claim. [...] Let me clarify: I don't think a 51% attack on Bitcoin is even remotely viable for a variety of reason that I probably don't need to enumerate -- you summed it up pretty well in your post above. I do think it's important to point out that a 51% attack (however unlikely) is not a mere double-spend attack which can be averted by awaiting an appropiate confirmation count. Any adversary holding 51% of the hashrate will always outmine their competitors, for as long as they are able to uphold the majority hashrate. (again, completely ignoring the economics of such an attack) People with little knowledge and journalists talk too much about coins with low hashrate and their vulnerability to 50%+1 attacks. it is not true. There exists and will exist no PoW coin vulnerable to this attack, users could always calculate the stakes involved and the costs of running an attack and spot the right length for their security.
Here I (partially) disagree with you. I fully agree with your assessment that users can always calculate the stakes involved and adjust their expected confirmation count accordingly. That's pretty much what happened with Bitcoin Cash, for example, when exchanges upped the required confirmation count to 10-20 confirmations IIRC. I disagree that alts with low hashrates are just as safe from 51% attacks as the larger coins in which shadow they stand (assuming that's what you're saying). Problem being: If you attack the largest coin within your mining space (be it Sha256 or Scrypt ASIC, be it GPU) you kill your cashcow and are highly disincentivized to do so. If you attack one of the smaller coins, the stakes are not quite as high, since you can always point your miners back to the larger coin (ie. you don't turn your miner into an expensive paperweight by such an attack). Obviously the benefit of such an attack would still be questionable -- as you rightfully pointed out above the more worthy of an attack a coin is, the better it is secured and vice versa -- but the incentive is not quite as beneficial.
|
|
|
To be honest I don't think you'll be able to fully rid your service of an automated hot wallet / manual cold storage set up.
Problem being, even if the private keys are securely encrypted in a way that is not accessible by an adversary, as long as they are able to call an API that even just sends a transaction, your safeguards are down. Even automating cold storage can be tricky. I remember there was a site (an exchange or a casino, I can't recall) that automatically moved coins out of cold storage to its hot wallet once the hot wallet reached a certain threshold, only to have its cold storage emptied by an attacker emptying the hot wallet (which got automatically replenished whenever the attacker had emptied the hot wallet). Put differently, keeping the private keys safe is just one part of the equation.
That's just my 2 sats though, maybe someone else has a suggestion that could actually help you with your problem.
|
|
|
If you're receiving transactions from or to a German bank account, be aware of the AWV Meldepflicht: http://www.zahlungsverkehrsfragen.de/auslandszahlung/awv-meldepflichtTLDR; Any in- or outgoing bank transaction larger than EUR 12,500,- "crossing" German borders needs to be reported in advance to your bank and local authorities. Your bank may or may not be alerted by smaller transactions as well though, I think LeGaulois is right that even international transactions as little as EUR 5,000,- can already cause suspicion. In that case it will mostly depend on your relationship with your bank though. What do you mean by additional documents or proofs btw? In general your bank should already have your ID and address... or are you referring to things like documenting the source of income?
|
|
|
It could have easily been another coin that was up 100% I'm more looking for that one coin that goes up 1000%. KingZee calls it "the burden" carried by a few coins, but I'd say it's a pretty good result if one or a few coins carry this whole thing into a profit. IMO this aspect is inherent to this type of investment strategy, similar to why VCs invest in a wide range of startups rather than going all-in on a single one. You can't know which one of your investments will succeed, so have to diversify, assuming that most of your investments will fail but that the few successful ones will make for an overall profit. Either way, I hope to take part in the next round of this, assuming there is one ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Thanks for the update, I'm happy that my Monero is still on plus ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Ya, just don’t look at that USD value. ![Cry](https://bitcointalk.org/Smileys/default/cry.gif) Blasphemy! :O 1 BTC = 1 BTC
|
|
|
I think it was simply deleted for not being a very good post. Obviously seems kinda unfair knowing that there are lot worse posts out there that fly under the radar. Don't worry too much about it though, that just happens sometimes.
|
|
|
A friend of mine once wrote a script to generate random chart patterns, for testing. Candlestick charts, based on randomly generated buy and sell orders. They looked really good, pretty natural.
So good actually, that we started to apply some basic TA to the charts as they were generated in real time, just for the lulz.
And it worked.
Subjectively speaking, of course. They were just random patterns generated in real time but we could still make out "resistance" and "support" levels, ascending and descending triangles, etc. and their predictions seemed to hold true. But in the end it was still just random data without logic or reason.
So yeah, so much for TA.
I really want to believe in TA and maybe it does work on some weird level that can't be taught but must be experienced. However in general I think odolvlobo's post summed it up pretty well: TA appears to be mostly a reflection of Confirmation and Survivorship Bias.
That being said, I still think TA is fun. I just wouldn't rely on it.
|
|
|
"Lightning network" == Mini banks They're not. I did warn you all and no the so called new "Off-Block" hubs did not save BTC as we can see from the price
Caring about short-term fluctuations are usually a sign of a lack of long-term thinking. CPU-Wars, mere 9 transactions per second from 20,000 miners and fees hitting $55 per transaction is what the BTC code will be remembered for as it enters our history books just like Tulip Mania did in the 1700's Irrelevant to the discussion. Casino managers are not the best people in the world to take financial advise from and the same goes for the dis-information moderator here that keeps pressing the delete button here because he hates the truth being exposed.
See above, which may also be the reason why some of these posts got deleted, rather than a hidden conspiracy by big crypto.
|
|
|
2- Limited user vulnerability: The main targets of 50%+1 attack with its short-range chain rewrite consequences are merchants and exchanges that do not take proper security measures by waiting for enough confirmations (blockchain growth) for high stake transactions. This vulnerability could be mitigated if users closely observe the network overall 50%+1 attack cost and wait for more confirmations up to safe thresholds.
I think this piece of code in JavaScript could help merchants to understand how much confirmations would be enough for their trades - so mitigate the vulnerability. Wallets could generate such information for end users: https://people.xiph.org/~greg/attack_success.htmlThat's the thing about 51% attacks though, there is no safe confirmation count for as long as a 51% attack is going on. To illustrate: AttackerSuccessProbability(0.51,1)=1 AttackerSuccessProbability(0.51,6)=1 AttackerSuccessProbability(0.51,100)=1 The question is then not how many confirmations suffice, but how long an adversary can hold 51% of the network's hashrate.
|
|
|
|