Some of these servers are managed by Chainalysis and some transaction tracking services and not part of the wallet team. Therefore, connecting it to your full node is a better option for anyone who wants to enhance their privacy.
Sure, but most of the servers are run by the community and there is no verifiable way of ensuring that they are not keeping any logs. However, this shouldn't discourage people from donating funds to the servers if they want to. Running a server is expensive and they aren't being compensated. Not everyone has the capability of running an Electrum server or a full node. |
|
|
|
|
Electrum does not accept donation and the code is maintained by anyone who wants to contribute to it. They aren't paid for their efforts.
Each server does incur a running cost. You can donate to your server by going to Help>Donate to server if they have put a donation address for it. Else, they can also put it in their server banner which is in Console. To see console, go to View>Show Console and press the console tab.
|
|
|
|
1-can I check it first without sending any fund
Sure, you can. Creating a wallet doesn't require the user to send any funds. If you'd like to test it out, you can run Electrum as a testnet and get coins from testnet faucets. These coins are worthless but you can experiment using them. To do so, you have to run command prompt and go to your directory bef, and run electrum.exe --testnet. 2- also can I check the entropy of 12 word
You cannot check the entropy of your seeds. Electrum's seeds should have 132bits of entropy by design, and unless you have a catastrophic failure of the randomness generated by your computer, you should be fine. |
|
|
|
|
CPFP, and to a certain extent, RBF aren't defined as per the protocol but RBF is built into the mechanism of the reference client. There is a chance that miners wouldn't consider RBF transactions (fairly rare) or not consider CPFP (which can be more common). Whilst CPFP can help to convince certain miners to include your chain of transactions into your block, RBF would be more straightforward and elegant.
An issue that CPFP faces is also if the parent transaction has a poor propagation. The resultant child transaction would also have a poor propagation as well.
|
|
|
|
Correct me if I'm wrong but afaik that's not accurate.
The 50coins in the genesis block can't be spent, but they exist nonetheless.
That is correct, but it is still a block that was mined and it wasn't created in the protocol by definition. Going by this definition, then Satoshi would have far more than 50BTCs, because he was the only person mining at that point in time. The 50BTCs would still be considered to be a part of the total supply. |
|
|
|
Then how many of the bitcoins were put out in the Blockchain from the onset by Satoshi. I always thought it's 21million and these is quite different from the number of blocks . Aren't they?
0, Satoshi started Bitcoin with no Bitcoins. The distribution mechanism of Bitcoin is actually dictated by halving itself. Satoshi used a base of 50 Bitcoins and halved it for every 210,000 blocks. The distribution of Bitcoin's supply would be a geometric progression with a ratio of 0.5. If you use the formula to calculate the limit of it, you will get approximately 21 Million, but not exactly. As such, there will actually be less than 21 million Bitcoin in existence in the future. |
|
|
|
This is what I plan to try.
creating a Bootable Linux OS on a USB Flashdisk with Elecrum Wallet inside.
The goal is to make a portable hardware wallet from a USB Flashdisk, with good enough security and of course cheaper.
Only used to do a few main transactions and include protection when you want to open the Bootable Flashdisk.
The Linux distro that is suitable for Electrum and has been integrated is Tail OS.
It also uses TOR servers, so using the electrum wallet on Tail OS we get more privacy than others,
but on the other hand, because TOR uses a lot of unknown server circuits, it will certainly be dangerous if we use the default electrum server.
For that, we need to reset the Electrum server in Tail OS.
Electrum connects to multiple nodes to determine the block headers but fetches data from only one server. MITM is still difficult in this case; connections are secured through SSL with the certificates. This makes MITM difficult unless you're intentionally choosing one that doesn't have SSL. Routing doesn't impact security, especially so for onion servers. |
|
|
|
|
It should generally follow a normal distribution, which is quite normal. I expect the trend in the distribution to tend to that as time goes by. I'll expect more addresses in the 50BTC region as well.
However, note that a lot of the addresses can be change address. If you were to send 0.99BTC, you would have a change address of 0.01BTC. With that in mind, you would have a lot of people having the coins separated in this manner.
In addition, a lot of the services tends to move their coins to another address rather slowly. I imagine that would be a non factor.
|
|
|
|
It's a risk I'm willing to take.
That's great, but certainly not for the average Joe. Don't tell people you have money in your head. I already said too much.
That is a given, if you want to keep your money safe. Running your mouth and telling everyone about your wealth is possibly the worst thing that you can do. With that out of the way, we have already established that the difficulty will be determined by how complex your passphrase is. What would the downsides be, if you were to encrypt your seeds with AES and a less complex but sufficiently secure password? The attacker cannot do anything without having access to your password and the added benefit is that the attacker would have to execute a targeted attack against you to crack the password which would exhaust quite a bit of resources. |
|
|
|
A backup can be found by someone, my brain is all mine.
I sleep fine, thanks.
--Knight Hider
To each their own and the most popular xkcd of all time: https://xkcd.com/538/. The human brain cannot think of anything random, simply because we are not wired to be able to do so efficiently. Even if you think that whatever you're thinking of is random, there isn't a provable way of doing so. That only leaves you with the option of generating a seed randomly, rather than using your own passphrase that you've thought of. Back to the topic, if you are capable of memorizing a sufficiently long string of characters that consists of all of the alphabets (both capitalized and uncapitalized), numbers, symbols that is presented in a completely random and non-uniform manner, then you can do it. I'm confident that most wouldn't be able to. |
|
|
|
Even that is not proof. "I sold an old laptop to my friend. He wanted to pay me in bitcoin, so I gave him my deposit address for my Coinbase/Binance/whatever account. He paid the coins directly from the mixer to my account."
The bottom line is that as soon as a transaction has happened, you cannot say the bitcoin haven't changed hands. As soon as a transaction has more than 1 input and 1 output, you cannot say which bitcoin ended up where - indeed, "which" bitcoin is a concept which doesn't actually exist. The very concept of taint is provably nonsense. It is a triumph of blockchain analysis companies that they have convinced governments to force centralized exchanges to pay them hefty fees to peddle this nonsense.
Of course you can't and that is a perfectly logical explanation. Generally, the clause of the exchange's TOS forbids the association of these tainted coins. Even if you were to argue from this narrative, they have the rights to not serve and allow you to trade on their platform. Bitcoin is not fungible to them but what can you do? You have two options, build your case by intentionally running your coins through multiple hops and come up with an easier and more believable story or use another exchange if you'd like. Bitcoin is supposed to be fungible but the key issue is that they could care less about closing one account so long as they conform to the regulations. |
|
|
|
You mean Amdahl's Law does NOT apply to the blockchain?
If yes, then there is probability to increase the transactions or may be speed up the processing power and reduce the network difficulty so that we can more hashing power thus indirectly giving out more outputs of confirmations.
Am I right to think this way or this assumption is just going to the south pole? Since your statement and whatever NotATether has referred to, contradicts a lot.
Having latency due to addition of Data Sharding architecture is like calling for the roadblocks intentionally. This is based on the Amdahl's Law as explained by the NotATether. On the other hand there are different assumptions to the Sharding architecture by other members.
It seems the concept is either a mismatch or it has not been properly understood.
You have to read and understand the law yourself. That law encompasses the problem surrounding parallel computing and the likes of it. That is very different from sharding and how we can apply it to Bitcoin. You can think of this as being applicable to IBD when we improved the speedup through parallelization. Confirmation or block intervals is NOT related to mining or anything similar. It is purely a design choice and can be improved albeit with tradeoff. You have to understand how sharding with blockchain really works to be able to understand what we are getting at and what we have to address before even thinking about adopting it. Please do read up more on how sharding could be applicable. Good resources to look into would be articles by Vitalik Buterin, danksharding, and those stuff. These are complex topics and I wouldn't be able to give you as thorough of an explanation. Feel free to cite and raise any issues afterwards. |
|
|
|
Yes but there's a limit to how effective the concurrency is because of Amdahl's Law. It basically says "The performance speedup in a program is limited by the amount of time that the parallelize-able part uses". So in this case the methods that verify the transactions inside the block can work in parallel, but there is a host of other things inside that process that can't be sped up: - Time spent obtaining the block from a peer (even if multiple peers are queried at the same time, the code running the block retrieval runs at least once) - Writing the block and chainstate to LevelDB - For each UTXO in the block, rewinding the transaction history to check that it's indeed not spent - All of the checks involved in CheckBlock and CheckBlockHeader functions must ultimately be performed in one way or another, so there will always be a minimum resource consumption associated with it. Sharding is not going to make any of this go faster, assuming that theoretically the system had enough threads to verify a single transaction in a block per thread, if all this stuff is already running in parallel. That's not entirely the concept behind sharding when we are talking about blockchain. Yes, you are right if you want Bitcoin to work as is, but retrieving the blocks individually, checking all of them is computationally difficult and doesn't scale linearly. However, sharding works with the nodes having their groups of shards and storing them. You have fraud proofs, ZK-SNARKS and other detections as counters to penalize rogue actors within the system. If you were to use random sampling to sample the correctness of the blocks, you'll probably be able to ascertain that the blocks are available to the network and corresponds to the fraud proof. However, you need to evaluate the efficacy of the measures again. The problem doesn't lie with the parallelization of it, but rather the tradeoff with security. Bitcoin doesn't exactly need to make that decision as of now. |
|
|
|
With example you mentioned, 1GB RAM isn't enough. Even if you only use CLI, use tricks to reduce OS ram usage (e.g. recompile kernel with only bare minimum feature) and configure Bitcoin Core to use less RAM, it'll be very slow and you might face unexpected error. I wouldn't recommend you to use thin client which has less than 4GB RAM and 4 thread CPU to run full node, especially considering Bitcoin blockchain and UTXO count keep rising over time.
If you disable wallet and stuff, it might be possible. I was running Bitcoin Core on a 1GB ram VPS at one point in time, though it was extremely, extremely optimized and it was definitely struggling with regards to IDB. However, CLI was perfectly responsive, and it didn't crash though you had to use your resources wisely. Anyhow, thread count doesn't matter as much as IPC. Raspberry Pi 4 isn't very good at synchronization even if you were to use multi-threading. It was constantly overheating and throttling itself. Unbearable to use. |
|
|
|
|
There is no way of finding out and the transaction broadcast timing. The timing that you see is basically the timing for which it is seen by any of Blockchain.com's node. This can be wildly inaccurate depending on the extent and the speed of propagation.
For certain transactions which are not very well broadcasted, the timing will be inaccurate depending on when the node sees it.
Even the block timestamp is not accurate. Blocks can drift from the network adjusted time by quite a significant amount. There is no way to enforce accuracy of timings on the blockchain.
|
|
|
|
If I remember it correctly, somebody said their mixed coins were classified as tainted even though they already move them through some addresses. So some exchanges might trace back to more than just one past transaction to see if your coins are "bad" or not. Although if you use a mixer that doesn't really make it hard for exchanges to see that you use them is a bad idea to begin with.
Most of the TOS that exchanges are using specifically bans the usage of such services. However, the problem arises when you consider Bitcoin should be fungible. Exchange can absolutely do so, but if you can prove beyond reasonable doubt that you weren't aware or otherwise associated with them, then it is fine. They have to actively prove that you are the one that is using it and you can use plausible deniability to your advantage. Afterall, they cannot prove that you were the one using the service unless you were to send it directly to your exchange without any hops. |
|
|
|
He received feedback from ranochigo 3 years ago: User has absolutely zero idea of what's going on in the thread. It's still the same. @Royse777 Are you sure you want this shitposter in your campaign? Yeah, I generally don't really care about people shitposting, I would just report and move on. It becomes far more dangerous if people are blatantly spreading misinformation with the potential of causing harm, which was what I observed at that point in time. Neutral feedback was probably necessary in those situations. |
|
|
|
|
Bitcoin is an inflationary currency, and it is always going to be a inflationary asset if you consider Bitcoin alone up until mining stops. In theory, assuming ceteris paribus, if you peg Bitcoin to a fiat which has a higher inflation, you are going to have Bitcoin always appreciating against fiat; fiat becomes less valuable and Bitcoin becomes more valuable.
However, that is contingent on the fact that Bitcoin is not currently overpriced. Based on recent and historical price fluctuation, Bitcoin is overpriced at most of the point in time. Hence, I'm not very much confident on Bitcoin always outperforming inflation or performing better than other investment vehicles for that matter.
|
|
|
|
12 Chars passwords are hard to crack, some people would say they aren't secure enough, I was looking to some sites to verify how long it would take to crack it. Trying with: XtugqR6OKOe2 (12 chars, upper and low, and numbers) For Password Brute Force Calculator: https://www.proxynova.com/tools/brute-force-calculator/Time: 2 years, 11 months For Brute Force Calculator: https://www.lostmypass.com/tools/bruteforce-calculator/Time: 1624 years Hashrate: 63 GH/s Maybe now is secure to do it, but I don't think is a good practice. Maybe if you play more with the encryption, something like sha256(12Chars)=R1; sha256(R1+12Chars). And this way you can get the second sha by only knowing the 12 chars password. Not really. SHA256, even double SHA256 and salted might not be good enough. SHA256 is naturally a pretty low resource hashing function to bruteforce as compared to other commonly used hash functions, Scrypt for example which is memory hard and expensive. I would recommend using a hash function with a better parameter, if you absolutely have to do it. |
|
|
|
|
Perfectly possible. Generally, you wouldn't want to run a Raspberry Pi as a production server because it is quite underpowered and the alternative isn't that much more expensive. There is no vulnerabilities with it, it is just another computer but smaller and cheaper.
If you want to run a node on it, be prepared to use HDD instead of an SD card. The constant IO operations will stain your SD card and you would suffer from slow synchronization as well. You can synchronize it on another computer before copying it over. It is a pain in the ass to set it up on Raspberry Pi and it would probably be better to just get a used computer to run your node. The cost differential isn't too significant.
|
|
|
|
|
Show Posts
