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  Thanks for the update, I'm happy that my Monero is still on plus Ya, just don’t look at that USD value.  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. |
|
|
|
Whoever that is, it's most likely not satoshi. As pointed out by other posters, the majority of his stashes are publicly known and none of these coins point towards satoshi's old addresses. Of course, Satoshi did not sell his Bitcoin as if he wanted to do it, then he would do it at the peak of the price.
Even satoshi wouldn't be able to call the top. But you're right in that satoshi's sell order would like cause the end of a bull run  peoples wallets do not contain the coins hidden away. the only thing in a wallet is the private key
this is the failure of buzzwords because a "wallet" should actually be called a "keyring"
Oh even if you'd call them "keyrings" people would still find ill-fitted metaphors... |
|
|
|
Note that a long range 50%+1 attack is impractical and won't e carried out in real world because the attacker will ruin the coin under consideration by such an attack while spending too much resources (electricity, rents, ...) it turns the whole purpose of the attack to be void.
I agree as it's not impractical, expect it happened once with Bitcoin Gold (a fork of BTC). AFAIK attacker borrow hashrate from various mining rental services such as NiceHash to reverse 22 blocks, which is far higher than average confirmation needed by most merchants/exchange (1-6 confirmation). While it can't happen to Bitcoin as there's no services which could provide hashrate enough to perform 51% attack. All cryptocurrency which it's hashrate is lower than hashrate of mining rental service combined should be very careful. That's the upside of ASICs vs GPUs. As an ASIC-mined coins you have fewer coins to compete with than being one that is GPU-mined. If you're the largest coin that can be profitably mined via GPU you're golden. But as soon as you're one of the smaller ones you're a potential target. Since the infrastructure already exists, the hashing power merely needs to be pointed in your direction at the flip of a switch. True also for ASIC-mined coins, of course, but less pronounced than with GPU mining. Obviously it also helps that Bitcoin has by far the largest Sha256 hashrate, so there's little hashrate that can come "out of nowhere" as was the case with Bitcoin Gold. |
|
|
|
For what I have seen and what I understand bitcoin uses double sha256, but what I didn't knew is that sha256 (the normal, not double) is used for governments, banks and others. In my opinion this is good for bitcoin because it's much more secure than all the other information in the world (double>single). But I also see a bad part in this, since, what would happen if someone found a vulnerability in sha256 which made possible to find the original hash? Sha256 is part of the NSA Suite B Cryptography standard [1], which is a set of cryptographic hashes and encryption schemes that have been both defined and reviewed in a formal and academic process. Those are some of the most well understood and therefore most trusted and most widely used cryptographic algorithms out there. Even if you weren't using a cryptographic hash that is part of an industry standard, you'd still want to use a cryptographic hash that is well understood and reviewed in depth by some of the smartest minds out there. As such you'll always want to rely on commonly used cryptographic hashes and not some home-brewn solution since cryptography is hard and you're more likely to fuck it up than not. [1] https://en.wikipedia.org/wiki/NSA_Suite_B_CryptographyIf the algorithm is used for every important information on the net, chances are higher than if only was used in bitcoin and other cryptocurrencies. I am right or I am missing something here? Because if sha256 is "broke", would be only a matter of time that double sha256 became broke too, right? Any cryptographic algorithm is prone to break eventually. The point of using well-reviewed standards is to make sure that this happens later rather than sooner (and optimally, can be anticipated in advance). It would not only be a matter of time until double Sha256 is broken. Double Sha256 is broken the instant that Sha256 is broken. So, who should be noticed in that case? If sha256 was used only in bitcoin I understand would be the bitcoin foundation or some of the first people who became miners and owners of bitcoin. But being sha256 something global, who should be contacted about this and would manage this situation?
Thank you and let me know if there is something unclear
Cryptography is a huge academic field with a lot of research going on. Vulnerabilities within a cryptographic algorithm are most likely to be found within academic circles and will thus be addressed within research upon which future cryptographic standards and recommendations will be based on. For example NIST has been working on post-quantum cryptography recommendations for quite a while now: https://en.wikipedia.org/wiki/Post-Quantum_Cryptography_StandardizationOnce these algorithms are well understood and the most solid ones are determined, new cryptographic standards will emerge and replace the older ones, just as has happened many times before. After that it will be up to companies and their developers to upgrade their software and systems. Optimally all of this happens long before actual attacks on current cryptographic algorithms become feasible. Be aware that the effects of an attack on Sha256 will be rather limited in the case of Bitcoin. At best a vulnerability within Sha256 will enable an adversary to calculate the hashes faster than a regular "user". Since the most prominent usage of Sha256 is within Bitcoin's mining progress, this would most likely merely lead to faster miners, rather than a full-on attack. The only scenario that would be worrying is if a single party manages to break Sha256 while also building mining infrastructure surpassing existing one without anyone else noticing to then lead a 51% attack. However this would be both unlikely and highly uneconomical. |
|
|
|
[...] What to do here, not even having some faucet for testing the site? [...]
As mentioned in OP their site is currently running on testnet coins only, so any testnet faucet will do, eg: https://coinfaucet.eu/en/btc-testnet/ |
|
|
|
Large price moves such as we've seen the last few days (regardless if up or down) often lead to an increase in transactions due to people moving their coins to and from exchanges. In that price movements do indirectly influence confirmation times or rather the transaction fee to be paid for a timely transaction. As long as the transaction shows up on the blockchain explorer of your choice I wouldn't worry to much, the coins will arrive eventually. If you're in a hurry and assuming localbitcoins paid a low, yet sufficient fee, you can give the ViaBTC transaction accelerator a try: https://pool.viabtc.com/tools/txaccelerator/They offer a free service where they accelerate a limited amount of transactions for free every full hour. Maybe give it a try, but be sure to submit your request at the full hour sharp, as contingents are limited. If you're successful you'll be included in the next block mined by the ViaBTC mining pool. |
|
|
|
Seems like quite an undertaking! Despite c# being as popular as it is, I'm not sure how much usage such a project would see in practice, as I believe most c# developers are fine with simply using wrappers. I'm not a c# developer myself though, so I know little about what's commonly used. Still I could imagine such a project being a welcomed addition to the ecosystem. not loooking forward to doing teh gui, maybe I'll just make it console based to start with)... I think it's fine to start with a console-only version, if the project gains traction you might easily find someone else supporting you with the GUI. IS there alos a list of when each version is planned to be released or is there no such planning involved in bitcoin core's programming?
As far as I'm aware of there's neither a planned release cycle nor an official development roadmap for Bitcoin Core. To stay up-to-date with current developments it may make sense to join the mailing list, if you haven't already: https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-devThere's little being discussed in terms of timelines though. |
|
|
|
Since "dust transaction" topic come up, I am curious what exactly is current limit of minimum amount of BTC can be sent?
I read a very old post from satoshi where minimum was set at .01 BTC ,but I guess at that that time 1 BTC value was also less than a cent.
546 sats for legacy transactions and 294 sats for (I guess native?) SegWit transactions. It appears to be implementation dependent though, so to my understanding you could in theory run a node with a smaller dust relay fee and then mine blocks containing transactions below the dust limit (whatever good that would do). // "Dust" is defined in terms of dustRelayFee,
// which has units satoshis-per-kilobyte.
// If you'd pay more in fees than the value of the output
// to spend something, then we consider it dust.
// A typical spendable non-segwit txout is 34 bytes big, and will
// need a CTxIn of at least 148 bytes to spend:
// so dust is a spendable txout less than
// 182*dustRelayFee/1000 (in satoshis).
// 546 satoshis at the default rate of 3000 sat/kB.
// A typical spendable segwit txout is 31 bytes big, and will
// need a CTxIn of at least 67 bytes to spend:
// so dust is a spendable txout less than
// 98*dustRelayFee/1000 (in satoshis).
// 294 satoshis at the default rate of 3000 sat/kB. |
|
|
|
I'm not sure if the merchants have any say in this[...]
I meant BIP70 users in general - payment processors like Bitpay and merchantes using the payment protocol in an independent way, but not BitPay-using merchants. Sorry for being not clear enough. The thing is, I understand if credit card providers or banks don't want Tor users to access their pages (if they do block them, never tried it), but a BIP70 server that merely serves payment metadata? Seems kinda unnecessary, especially given the fact that payments could still be easily accepted if they had simply continued providing the advanced payment mode.
Yep, that's what I meant - so I interpret BIP70 server operators (between them, Bitpay itself) can decide if they wanted to be accessed by Tor or not. My point is that then not the protocol (BIP70) it at fault, but the operator of the server who handles it - in this case Bitpay. I wonder if it was possible to detect BIP70 servers rejecting Tor/VPN connections, so users could be warned beforehand (this could even be implemented in Bitcoin clients) - but I guess it is not ... Ah, sorry. You are right of course. That is indeed not a problem with BIP70 itself but rather with how BitPay implemented it. |
|
|
|
Nice, thanks for the insight KingZee. The script works fine on Windows 7 Professional. On my Xubuntu 16.04 machine I wasn't quite as lucky, when trying to run it after installing findwallet via npm I got the following error: /usr/bin/env: ‘node\r’: No such file or directory Which seems to be an issue with how npm publish handles linebreaks on Windows: https://github.com/darkguy2008/parallelshell/issues/58(note that I just picked this issue at random, not sure whether it's relevant for your specific case but there's a bunch of related issues describing this error) |
|
|
|
|
The script as of the initial commit #07e0fb4 looks fine to me. It really is quite simple and easily readable with very few but well-known dependencies. With a few tweaks it should also work for finding lost zip and rar files, if you know what file header to look for.
Where did you find the values that you are checking for, btw?
I'll give it a whirl and let you know if I stumble upon any issues.
|
|
|
|
|
Show Posts
