Is there any way to mitigate the risks of using electrum.
Aside from what @o_e_l_e_o said, consider Wasabi Wallet ( https://blog.wasabiwallet.io) which offer good balance between ease of use and privacy protection. What is this spying about? Recoding the IP associated with the addresses and transactions?
Aside from IP, address and transaction, there are few other things such as 1. Date/time when you connect to server. 2. List of your addresses. It means the server know address A, B, ..., N is owned by same person. 3. Range of your Electrum version which could be determined from version of Electrum protocol ( https://electrumx-spesmilo.readthedocs.io/en/latest/protocol.html). Is there any way to mitigate the risks of using electrum. The only way to fully mitigate the risks would be to run your own Electrum server and point your Electrum client at your own server. Take note your privacy already weakened if you use same wallet, you'll need to move your Bitcoin to different wallet without weakening your privacy (e.g. move all Bitcoin from different address in single transaction). |
|
|
|
True, but it requires user to use vulnerable software. Reusing k value (also called nonce) is well-known problem, so it's unlikely you could someone private key that way. The decision also won't be unilateral, whatever the decision may be. It will be a fork that like any other fork requires support from the majority. I meant unilateral in respect to the owner of the coins. The majority shouldn't get to decide what to do with the coins belonging to someone else, even if we think those coins have been lost or abandoned. Unfortunately people have different opinion on this matter. For example, few people think it's better to freeze vulnerable UTXO rather than letting thief stole it and potentially manipulate Bitcoin price. |
|
|
|
|
Neat tool, but definitely need improvement. Here are few feedback,
1. I really don't want to press "left click" at least 128 times. Consider keyboard support or other way to reduce press amount (such as drawing which already suggested).
2. Add option to fill all "?" with 0 or 1.
3. Do not discard user progress when they switch between BinaryGrid and GroupedBinary.
|
|
|
|
---
Are you sure the first results are not ads/sponsored? I did a quick google search of the term with a private tab and the first result was the forum followed by the board itself. I doubt theymos (or other member) bother use google ads to boost traffic of this forum. And DuckDuckGo is not actually better - it made me miss other results.
You might want to check StartPage which bought search result from Google Search. |
|
|
|
The wait time period only applies to newbies. Be patient it will end when you become Jr member
If you check the formula, the wait time actually applies to all ranks. But the wait time is significantly reduced if you have some activity, so most people don't even notice it. For example, if you have 15 activity, the wait time only become 75 seconds. |
|
|
|
I didn't include the Express VPN purposely. They have gone down in quality and I am not a fan of Kape Technologies. If anyone thinks that they are trustworthy, then I am open for discussion, it's very important for us to have a list of privacy-oriented VPNs.
I don't use ExpressVPN, so I had no idea that they went down in quality and they're not privacy-oriented provider. How about CyberghostVPN or PrivateInternetAccess? According to this article ( https://restoreprivacy.com/kape-technologies-owns-expressvpn-cyberghost-pia-zenmate-vpn-review-sites/), Kape now owns all of them. I would recommend you to choose different VPN. |
|
|
|
All post-IBD validation is processed within milli-seconds.
All? milliseconds? It's unlikely since there are many factor which affect verification time. Check this snipped answer by Pieter Wuille. - Signature cache size and CPU speed. The larger the cache, the more signature validations can be avoided. These validations - depending on the software version and hardware van vary from 0.01ms to 0.6ms per signature (45ms to 2.7s for a block).
- Correlation between the memory pool and the new block. If a block contains transactions that a node hasn't seen before, its inputs and signatures are less likely to be cached before.
There are several ways to speed up the bitcoin transaction and i will list them below:
- Replace-by-Fee (RBF (for transactions sent by you)To implement RBF you need to use a wallet thats upports this functionality
- Child Pays for Parent (CPFP)
- Transaction accelerators
if you need more info be welcome to reply to me to try to help you little bit more.
It's not wrong answer, but what OP means is increasing transaction speed (as in getting confirmed) by modifying Bitcoin protocol/node implementation. |
|
|
|
Intensive I/O activity won't make HDD suddenly fail, but only reduce it's lifespan (especially if you mine chia coin). I use 3-4 years old to store Bitcoin Core data without any problem. Another possibility would be the SATA cable.
It's unlikely, but another possibility is buggy chipset on motherboard. For example, Intel Sandy Bridge's chipset had bug on SATA port ( https://www.cnet.com/news/intels-sandy-bridge-chipset-flaw-the-fallout/). |
|
|
|
Hunt Brothers tried it in past with silver and they failed, besides U.S. government already aware of Bitcoin existence in 2011 and they didn't perform such action. So it's unlikely they'll attempt to buy all Bitcoin now. The idea of Russia buying Bitcoins is beyond my wild imagination.
IMO it's not that wild if you consider economic sanction faced by Russia. |
|
|
|
I check that sha256 hash matches then I compile it and I overwrite whatever was on the bitcoin folder previously. Is this ok, or should I first delete the bitcoin folder, and the compile it or any other steps I may be missing?
I don't know definition of "correct" in this case, but here are few common recommendation. 1. For security purpose, you may want to verify the signature (which contain hash of the files). 2. Do not overwrite/delete the Bitcoin directory (which contain executable file), but rename/archive it in case compilation failed or newer version has unwanted bug/behavior. |
|
|
|
From user side, they need to move their coin to "secure address". But from technical side, there are few dilemma such as,
1. Should we freeze UTXO with vulnerable cryptography or let it stolen?
2. Should node/miner reject transaction where the output contain "old address" after "secure address" is available? Shouldn't we come into an agreement now instead in a stressful period when everybody will scream for the sake of their money? I mean, do we have to wait until it becomes feasible enough to break the secp256k1 or rather gather as nice, calm Smurfs and vote for our decisions? Past discussion (at least on this forum) shows it's difficult to reach agreement, few example https://bitcointalk.org/index.php?topic=5191219.0https://bitcointalk.org/index.php?topic=5322061.0https://bitcointalk.org/index.php?topic=5355246.0Shouldn't we come into an agreement now instead in a stressful period when everybody will scream for the sake of their money? I mean, do we have to wait until it becomes feasible enough to break the secp256k1 or rather gather as nice, calm Smurfs and vote for our decisions?
It would be intersting to create a second Bitcoin testnet and implement these ''secure addresses'' just to test it. So we would have experience and were able to switch faster if needed. But i doubt it'll happen anytime soon since quantum computing isn't big concern for now. |
|
|
|
Hi, run ./bitcoind -server -daemon=1 -prune=2024 , why error?  Looks like hardware error to me, but i can't be sure without additional log.
~
Seems like your system got run out of memory. How much RAM does your PC have? Also, do you run some specific bitcoin.conf configurations? Unlikely, if his system ran out of memory he should see message such as "Killed" or "kernel: Out of memory: Kill process XXXXX". I agree, but i also recommend to include relevant line of your system log. |
|
|
|
Do we also have a plan how we will switch the old addresses to the secure addresses? Transfer the coins? Let's assume these guys Pollard's kangaroo ECDLP solver have a very very fast computer and can calculate ECC private keys in the 2^256 range and demonstrate it and reassure us. How would we proceed? From user side, they need to move their coin to "secure address". But from technical side, there are few dilemma such as, 1. Should we freeze UTXO with vulnerable cryptography or let it stolen? 2. Should node/miner reject transaction where the output contain "old address" after "secure address" is available? And what algorithm is that exactly? They always talk like one exists but I havent seen it yet. I'm also not an expert on the subject, however the one most commonly talked about at the moment is Lamport signatures, but probably only because they are the most developed. They have a couple of disadvantages, however, most notably their size, which effectively precludes them being used in their current form. There is plenty of researching going on in this area though, so I suspect the algorithm we eventually fork to is one which is still very early on in its development. Lattice-based and Multivariate-based cryptography also frequently mentioned. |
|
|
|
Thats the reason i sold all my bitcoins. I beleive in cypto tecnology, but sooner or later a Bitcoin Private Key will be stolen by bruteforce and the market will lost its value.
Your statement also apply to any cryptography which only deemed secure for some time. For example, NIST disallow SHA-1 usage in 2013 which is 18 years after SHA-1 is published. ...
2- With todays hardware technology is imposible to find a private key. ... I beleive in cypto tecnology, but sooner or later a Bitcoin Private Key will be stolen by bruteforce and the market will lost its value.
If that happens, we will switch to a stronger ECC. For example from 256 bit to 512 bit. It's more likely we will switch to different cryptography though, which likely to be quantum resistant while remain compact in size. |
|
|
|
The goal of burning is to skew the economic model towards being deflationary (current distribution model in bitcoin is geared towards constant supply and is not deflationary [Stop]).
Some Bitcoin already lost "permanently" due to 1. User mistake. 2. Software bug (e.g. pool doesn't claim transaction fee on mined block and generating private key outside valid range). 3. Sending Bitcoin to known burn address. 4. Sending Bitcoin to OP_RETURN output. IMO such thing will always happen, so your proposal is unnecessary. |
|
|
|
Are there other ways to get rid of this annoying warning besides forced upgrades? This is not to say that Taproot soft fork is bad or not beneficial for the network, but people may have different reasons not to upgrade their software.
There's no parameter/option to disable such. However, Bitcoin Core developer decided to remove such message field (see https://github.com/bitcoin/bitcoin/pull/15471). So if people bother to upgrade to newer Bitcoin Core version, they won't see such message in the future. Other than that, this warning may be misleading to some people making them believe that their wallet is no longer supported by the network, which is also terrible for decentralization.
I don't see how it's terrible for decentralization since the "problem" is the software, not the protocol/network. |
|
|
|
It would be great if you're being specific about what do you want to do and how much do you know about Bitcoin? Assuming you're not too familiar with Bitcoin script/protocol, but just want to look around you could try Minsc ( https://min.sc). But if you want interact with Bitcoin script directly and looking for introduction material, check https://blockgeeks.com/guides/best-bitcoin-script-guide/. Take note it's somehow outdated and doesn't cover Taproot. |
|
|
|
Sebenernya saya cukup kecewa dengan fatwa tersebut, faktanya ada banyak temen ku yg karna BTC bisa bangun rumah padahal mereka dari keluarga tidak mampu. Tugasnya Ulama kan melakukan kajian, menelusuri, mengeluarkan fatwa, memberitahu berdasarkan hukum Islam dan itu sebenarnya tidak salah. Saya bahkan tidak akan menyalahkan Ulama seandainya mereka memiliki pandangan bitcoin atau cryto itu haram hukumnya karena banyak digunakan untuk judi misalnya, transaksi narkoba, pencucian uang, penghindaran pajak ataupun hal lainnya yang mana juga melanggar aturan pemerintah.Apakah ada data atau laporan yang bisa membuktikan hal tersebut? Salah satu ringkasan laporan dari Chainalysis menyebutkan hanya 0.34% transaksi cryptocurrency yang terkait dengan aktivitas kriminalitas pada tahun 2020.  Source: https://blog.chainalysis.com/reports/2021-crypto-crime-report-intro-ransomware-scams-darknet-markets |
|
|
|
|
Show Posts
