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.
|
|
|
|
OK, thanks for the explanation. That's indeed a valid counter-argument. According to the blog post (as I understand it) the Payment Protocol can be used via Tor/VPN, but the merchant in this case can refuse payment if he detects this. Is this correct?
I took a superficial look at the developers' guide and haven't found a statement that the IP address is necessary to confirm validity of the payment. If my understanding is correct, merchants could use the Payment Protocol "the right way", without forcing users to reveal their IP address. However, the fact that the Payment Protocol requires a direct connection between wallet and merchant server (without routing through the Bitcoin network) isn't ideal. Wallets can offer easy-to-use Tor/VPN assistance but it adds hassle for a non-expert user that wants to stay anonymous.
I'm not sure if the merchants have any say in this, but the breakdown is this: If Bitpay detects you are making a connection through a VPN or Tor, they will not call back and make it impossible for you to pay your invoice until you reveal your IP. That is, similar to how one may get Cloudflare CAPTCHAs when browsing with Tor, in this case the BIP70 server simply denies your connection. This is unrelated to how you as a developer would implement their API. Working on the application level, you don't know anything about which connections the underlying server decides to block. 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. |
|
|
|
Counter-argument: BIP70 deanonymizes users and should not become the de-facto standard for Bitcoin payments. I guess it de-anonymizes the payee/merchant only, right? Anyway, I would like it to become supported by all major platforms and wallets. In cases where the payee is already known, like in the case of exchange deposits and merchant payments, this "de-anonymization" should be no issue. No, I'm indeed referring to the paying party. Problem being that while the invoice pages themselves are usable via Tor, BIP70 is not [1]. Therefore unless you get out of your way to protect your privacy they can unnecessarily track your IP address. [1] https://blog.bitcoin.org.hk/bitpay-is-using-the-payment-protocol-to-take-your-privacy-8093bf91eda7Of course, the most simple way of transacting (manually entering amounts and addresses) should always be allowed, too. Here I agree that BitPay - and all merchants - should offer it as a fallback method, also for people with hardware wallets. But the Payment Protocol could be highlighted as the "recommended" way.
That's exactly what BitPay did for a while... IIRC they offered BIP70 and the "old way" in parallel for quite some time. By default you would get an easy to use QR code / invoice link but then also a small hidden link to an advanced payment mode with a big fat warning that you should absolutely know what you are doing. In my opinion this was the best of both worlds, easy payments by default but also a non-obstrusive fallback method for more experienced users. Alas they decided to get rid of the advanced payment link, a move which at least to me seems rather arbitrary. |
|
|
|
BACK LATER
---
MICE SLEEPING D'awww Looks like a fun project, I'll keep an eye on this thread and hope to soon see a live race. Treat those little champions well!  |
|
|
|
I like Bitpay's Payment Protocol ( BIP70) - it is - in theory - very easy to use because the merchant you want to pay generates something like a "pre-transaction" you simply import to your client and it will transact the Bitcoins to the correct address. As you only see the correct payment receiver in the wallet if you imported it correctly, there is practically zero risk to do it wrong. So it's just the method non-experts need ... [...] Counter-argument: BIP70 deanonymizes users and should not become the de-facto standard for Bitcoin payments. As such I dislike BitPay having made BIP70 their obligatory means of payment without any fallback method (apart from using external scripts such as the one by achow101 [1]). I fully agree though that it absolutely does improve user experience, I just wish it wouldn't be the only option offered by BitPay. [1] https://github.com/achow101/payment-proto-interface |
|
|
|
Of course not, but for example, the Electrum is the only computer wallet i know that supports RBF (Replace By Fee) function, i dont know other computer wallet that supports it and i had some big problems in the past not doing RBF supported transactions, so, if id like to do RBF support transactions i can only use Electrum, what type of decentralization is that?
Bitcoin Core has been supporting RBF since 0.12: https://bitcoin.org/en/release/v0.12.0#opt-in-replace-by-fee-transactionsGreenAddress also supports RBF: https://greenaddress.it/en/faq.htmlArmory: https://btcarmory.com/0.96.0-release/And probably some other wallets as well that I'm not aware of. So there you go, RBF choice galore. And that's just desktop. I should have the possibility of using bitcoin core node wallet, without need to install the full node or prune, because i dont even have a good internet to install it. This way bitcoin core software would have 3 modes of running, full node mode, prune mode and wallet mode.
Maybe some time in the future, if there's demand. I've got a feeling that there's more important things to tackle in Bitcoin development than yet another SPV wallet. Until then there's plenty of other open source choices with great track records. |
|
|
|
I know 0.00000000000000000001 its possible, but its not pratical and human, im not trying to go back to traditional banking system and i agree with you that USDT its a scam, but if we could turn bitcoin payments more human stopping using a lot of decimal parts why not?
If in the end of the 21 millions we make one airdrop to double the bitcoins of everyone or multiply by 100000000 that dont makes any difference and the bitcoin would look more easily to normal people figure out is value, if you could buy almost exactly the same things with one bitcoin and 1 dolar you will have a better idea of the money you are wasting without doing calculations 0.00001 x $5700 = ?
As mentioned above: Hence why you got mBTC, uBTC, Satoshis, etc. The question of terminology of fractions of Bitcoin is long solved and a non-issue.
The usage of mBTC (ie. 0.001 BTC) is already fairly common. I think some wallets even default to displaying your balance in mBTC rather than BTC, precisely to get rid of those decimals  Currently mBTC 1.00,- equals USD 5.43,- which is not much different from calculating foreign fiat currency exchange rates. For smaller amounts you can use uBTC (sometimes called bits) with uBTC 1.00,- currently equaling about half a penny. Then there's sat (satoshis), msat (millisatoshis)... and just like that you get ever smaller, manageable units of account. |
|
|
|
However, if the structure of the wallet.dat was fundamentally changed on disk by compressing it (using an archiving tool like WinRar)... Or by encrypting the file using an external encryption tool... Or "hiding it" in another file using stenography... Chances are that finding that data will be next to impossible as it will just look like any other random block of data of disk.
It depends... if OP used a steganography tool or something like a hidden encrypted volume than there's pretty much no chance of finding the file (which is the whole point of steganography and hidden volumes after all). If OP merely renamed the extension of a zipped wallet file it should be possible to scan the files for meta data indicating a file archive (ie. zip utilities don't try their hardest to hide). |
|
|
|
Just to be clear, I think bitcoin.COM recommends the "Electron Cash" wallet. I think bitcoin.ORG recommends Electrum. IIRC, Electron is for Bitcoin Cash, Electrum is for Bitcoin.
That is correct. Electr um is the Bitcoin wallet, Electr on is the Bitcoin Cash fork. Be sure to get the correct one. I read that we can use prune mode, but prune mode needs for about 10GB, so, that is not solution and prune mode keeps validating transactions, but many people (my case) only search for a trusted wallet and some existing software wallet recommended by bitcoin.org could be easily compromissed.
Unless something changed since SegWit the minimum requirement for a pruned node is 550MB (ie. prune=550), not 10GB. You still won't get around downloading and verifying the whole blockchain first though. As far as SPV wallets are concerned Electrum is the most trusted however. |
|
|
|
When you say that you hid the wallet.dat in a file what exactly do you mean? Did you put it in an archive together with pictures, MP3 files, used an icon changer to change its appearance and used winrar to archive it? I'd like to know this too Depending on what you did, pywallet can be used to search the entire partition. Don't forget to create one or more backups before continuing your search. I think I used Winrar but I'm not sure, it was a long time ago  So you used something like WinRar / WinZip / 7zip to compress the file and then changed the file extension? If so, did you also use a password or did you merely zip the file? |
|
|
|
|
I'm not sure whether I'd actually use it, but I think that's pretty damn neat. Looks slick, works fine (at least for me), quick sign-up process... good luck, if it takes off it might just make crypto more attractive and accessible.
Also it was nice to see that satoshi's page was still up for grabs ;p
|
|
|
|
|
Show Posts
