There are lots of proposed solutions, lots of hardfork made to increase size yet many still uses bitcoin (1mb), now we used segwit to reduce much more transaction data (separate signatures in transaction data)
Segwit doesn't reduce transaction data, the segwit transactions could actually still be bigger than legacy transactions under some circumstances. Segwit is essentially just a block size increase. It was quite obvious from the onstart that Bitcoin wasn't going to scale, bandwidth-wise. There wasn't any block limits initially until quite a bit after it was released. Bandwidth was a far greater concern then and it was obvious that it wasn't going to scale at that time. Lightning network is not the panacea to the problem. You still have to make on-chain transactions to open and close channels. Perhaps it could alleviate the problem but onchain capacity will remain an issue. |
|
|
|
Really? I'm running blockchain on external drive since 2013 and there was no problem so far. When my old HDD was out of capacity I just replaced it with the faster and bigger SSD preliminary coping all files to that new drive. Either I'm a lucky man or you’re exaggerating the danger a little bit.
Disconnecting it suddenly would be akin to an unclean shutdown which can cause database corruption. It'll be fine unless the disconnection happens while Bitcoin Core is writing data into the disk. |
|
|
|
I'd argue that people should not be using PRNGs seeded with cryptographically secure entropy to make private keys especially on browsers in particular (which is the only method they have, they got no CSRNGs) because you're relying on the webpage to supply a good-enough entropy. Mouse and keyboard input that's made during (not before) entropy gathering can also be tracked within the browser and webpage itself so all it takes is a malicious addon that tracks such movement and they can re-derive the entropy. When a PRNG is used this also allows them to make the private key too.
The script itself is secure enough and provides sufficient randomness from any bruteforcing attack and that is the main point of the topic. I think we have to eliminate any malicious party that could intentionally modify the entropy sources to make it less random... Running a phishing site with a pre-defined seed is sufficient for this. Malicious add-ons and stuff like that shouldn't matter because the webpage isn't designed to run on a compromised computer. As for the randomness, I've done a quick pass over their entropy collection[1]. I think the way the entropy is generated is sufficiently random, barring any possible interference externally. [1] https://github.com/pointbiz/bitaddress.org/blob/72aefc03e0d150c52780294927d95262b711f602/src/securerandom.js |
|
|
|
Shut down Bitcoin Core then move the entire data directory elsewhere. Afterwards, run Bitcoin with -choosedatadir and select the folder which contains all the contents that you've moved. You'll have to either run it with command prompt, ie: cd c:/program files/Bitcoin
bitcoin-qt.exe -choosedatadir
. Or create a shortcut of Bitcoin Core, right click on it to properties and append -choosedatadir at the end of the target. |
|
|
|
|
It doesn't hurt to try to run something like Recuva to see if there are any files that aren't fully overwritten. I would probably prefer it to be mounted externally so nothing gets written on it any further. I have doubts that you'll get anything. Chances are it'll be overwritten if it has been formatted and used.
Pywallet will work as well.
|
|
|
|
The heat pump's heater has to work to heat incoming air up to the thermostat setting, say 25 deg before it automatically cuts off The incoming cold air can be near zero deg. If you preheat it using GPU heat, it will save the pump's heater some initial work from zero to say 6-7 deg celsius. This happens all the time in Thermal power plants where waste gases from furnace are redirected to a Air Preheater for raising temperature of air going into the furnace.
So I assume that somehow the GPU is more efficient than the heater at lower temperatures? If that is somehow the case, then it'll make more sense. The heater must be pretty bad given such a huge disparity can be offset by another supposedly less efficient device. To OP, This is not really a good example for off-setting Electricity consumption of Bitcoin Mining anyway. Most Bitcoin miners are huge farms and not really home-installed GPU rigs. Those are generally mining Ethereum. I doubt that the huge farms do anything with their heat output except vent it out using industrial fans and radiators.
I'm 100% certain the miner isn't mining Bitcoin. I've seen quite a few of them mining using old Antminers though. |
|
|
|
|
Not sure how the comparison makes sense at all. If anything you wouldn't take the energy used to mine that amount of Bitcoins but you would take the energy that is used to mine the block that the specific transaction is included in. The Bitcoins are mined regardless and the carbon footprint is distributed on those who happens to use those UTXOs so it makes little sense to count the energy used to mine it. Tesla is a tech company that ventures into EV but their primary concern is not to tackle climate change; else they would stop producing luxury cars and instead focus on vehicles which can accommodate much more people/sqft. Doesn't help that some countries are using non-renewable sources which would just exacerbate the problem as they're thinking it's good for the environment but it is not in actuality.
Not really that big of an issue. Bitcoin mining is most profitable if the miners are able to siphon off the excess energy that energy companies produces. It's no secret that most of them are situated near power plants which produces clean energy so the environmental impact is probably blown out of proportion.
|
|
|
|
|
How would preheating the air to a heat pump reduce the electricity bills? GPUs are not very efficient at energy output as they are primarily designed for other purposes and a significant amount of energy are not wasted as heat. I don't doubt the mining profits covering parts of his bills but I can't seem to wrap my head around that point.
Anyhow, yeah nothing new. I've seen a few members using it for solomining during winter and someone rigging a huge radiator for it.
|
|
|
|
|
Miners will always flock to places with lower operation cost to maximize their profit margin. There is really no telling as to which country will dominate Bitcoin mining in the future. If certain countries subsidize it for some reason, then people would just flock there.
Honestly, China probably wouldn't bother about Bitcoin mining. Bitcoin is already restrictive enough in the country. Trying to drive out the miners would result them losing potential revenue in multiple levels, from the profits to the capital gains and to the ASIC producers. The benefit of the operations outweigh the cons by far. If China wants to launch their own coin, they wouldn't have any problems with adoption within the country and the western countries wouldn't even think about using it. Trying to drive out the miners to weaken Bitcoin doesn't do anything beneficial for them.
Anyhow, centralization is probably a problem but not anywhere near the more pressing ones that we currently have.
|
|
|
|
Then you are exploiting potentially flawed PRNG which has been done and is completely feasible. Bitaddress uses randomness from different sources which would make it harder as you'll have to replicate both the tracked mouse movement as well as the randomness that was generated when the user enters the page. These attacks can only work if they are using predictable variables as an entropy source. If and only if you can find a pattern in that generation, then you can reduce the search space significantly. Under no circumstances should any wallet be generating using flawed PRNG. Brainwallet stealing works similar to the above as humans are generally terrible at producing anything with sufficient entropy. |
|
|
|
I really can't recommend you to run a full node if you do so only because you think that it is a good idea. Unless you are going to prune your node, you'll be looking at 360GB+ of data to be stored in your SD card. SD cards are not exactly suitable for constant I/O activity for extended periods of time so you'll probably have to get an external HDD as well. Given that it's quite underpowered, initial synchronization can take quite awhile as well. If your purpose is to use Bitcoin, then using an SPV client like Electrum on your Raspberry Pi might be better. I've had some experiences running a full node on RPi. You have to get an SD card and install RaspBian on it, while adding a blank file called SSH. You'll be able to access the SSH interface on your local network with your IPad and a SSH app. The default username:password is pi:raspberry. To get Bitcoin Core, you'll need the ARM version: https://bitcoin.org/bin/bitcoin-core-0.21.0/bitcoin-0.21.0-aarch64-linux-gnu.tar.gz. There's a nice guide on the page itself: https://bitcoin.org/en/full-node#linux-instructions. |
|
|
|
How is that? Pruned nodes "benefit the network" just like any other full node, with just one exception: they are not helpful with the stupid bootstrap process in the current (experimental) implementation of the protocol, nothing else, not a tiny bit of any sign of being inferior compared to a historian full node ... I just made it up   And that is why I think we have fundamentally different ideas of how Bitcoin should function, based on your past response about how verification of block data is not necessary, etc. If your view is that blockchain data is not important, then I believe that you'll probably disagree with everything that I say. We can only argue that more Archival Full Nodes are going to benefit the network only if there is a shortage of them that makes syncing hard for new nodes that come online or puts extra pressure on the existing Archival Full Nodes. I don't think this is the case since we have enough of them to supply the historical blockchain. I believe that there is nothing wrong with making it more available. Having more "archival" full nodes would be far more useful for initial synchronization both in terms of it's speed and availability. I'm aware that pruned nodes can almost function like an "archival" full node but I fail to see how it would be as beneficial than the other, given that the bulk of the benefits falls on the user using the full node. If the blockchain size grows even further, people that are hosting them on RPis and servers may not want to run it anymore. |
|
|
|
Mining is an all or nothing race. This is why miners join mining pools. Only a tiny fraction of the total hash power of the network is saved in the block that gets accepted. Maybe there's a more fair and efficient way to mine. What if miners could mine cooperatively, taking turns generating each block and helping to hash the same block.
Most miners join a mining pool to put the responsibility of maintaining the messy back end to someone else and just focus on their own hardware. That and if they are a smaller mining operation, they can choose to mine at a pool for a more regular payout. The mining profit is roughly the same before deducting the pool's fees. When a miner joins the network the other miners respond by indicating their position in line and what position the new miner can take.
Mining happens in rounds. In each round, the next miner gets a turn to generate the next block- just the block data not the hash. They then allocate workloads to the other miners based on their speed. A workload is a range of nonce values. The miner who generates the block essentially hosts their own temporary mining pool.
As each miner completes a workload, they broadcast it to the network so that everyone can confirm it. The host credits them and supplies another.
Confirmation of work doesn't require re-checking every hash in a workload. The number of hashes checked at random can be based on the number of miners online. With every miner checking only a few random hashes, each workload gets checked a lot. If any miner finds errors in a workload, they inform the host who then scans it more thoroughly. Rewards are only allocated for actual work.
When a block is solved, it gets broadcast to the network as usual and the next round begins with the next miner in line assuming the role of host. If a miner drops from the network the round goes to the next miner.
The block reward and fees of the current block cannot be allocated among the miners in the same round so they are allocated in the block that follows it.
Unfortunately, Bitcoin network does not allocate mining this way. The block reward is claimed by whoever submits a valid block with sufficient Proof of work. There is no concept of individual miners on the Bitcoin network. You could probably do this queue system if you could allocate some central party to regulate this which could possibly idealize in an altcoin. Miners don't actually "check" hashes but it is a matter of bruteforcing and finding a block header hash that meets the current target. |
|
|
|
by studying the algos that create those wallets and patterns that may exist i think that number will be much lower, add to that if somehow you found thousands of people who are willing to brute force using a good algo for couple of years straight, then what are the chances that you maybe find a wallet with a large balance,
The complexity of those would still be fairly high, unless a weak RNG is used which could possibly lower the keyspace due to it's non-random generation. That's what some of the bruteforcing projects are attempting to do by getting these weak keys. and for people who may say this theory is crazy and not possible i refere you to the guy who actually done just that for couple of years and found private keys of 3 small wallets.
Possibly weak keys. This is like digging for gold and by technology going up i believe oneday it will be possible to brute force about 20-100 wallets each year using some crazy asic machine and a whole industry will be built around just this idea.
this is just a theory of mine which made me curious, would love to hear what you think other than no it's impossible.
Current ASIC cannot be used to generate addresses but it should be fairly simple to do so as well. Other than the speed (which we have established that it would have to generate addresses extremely quickly), you'll have to compare the addresses generated to those addresses that currently have any Bitcoins which could present itself as a slight bottleneck depending on the way it gets designed. |
|
|
|
I don't get it.  Why People are so concerned about HDD capacity? We have pruning already, a pruned full node works just fine. Pruning works just fine. I think we have fundamentally different concepts of what true decentralization is; which is for everyone to have a copy of their blockchain for me as we're touching on the topic of decentralization. You may correct in your own right and I can't really dispute that either. I'd prefer having more nodes with the entire blockchain rather than nodes which only stores the last few GBs of the blockchain which really wouldn't benefit the network more than the others. |
|
|
|
I agree, however wallet such as Wasabi (which uses Tor, BIP 158 or both of them) usually took some minutes for first time sync.
They would still have lower requirements than Bitcoin Core; less bandwidth, less time taken, more privacy, etc. Definitely would outweigh any disadvantages. Few years ago I purchased 4TB HDD disc and that is now even cheaper, and SSD disc are now also affordable and much faster.
When I purchased my first SSD it was expensive and had limited storage, but now you can find 1TB or 2TB SSD M.2 like Samsung or Adata in reasonable prices with good five year warranty.
I think current size of Bitcoin blockchain is around 330 GB, and with current yearly growth of around 25% I think that having few TB disc will last for years without any issue.
At current capacity, Bitcoin can't stay at that rate of growth if we want to accommodate more transactions. I'm not too sure about the rate of growth for HDDs, price might have gotten cheaper but the growth of Bitcoin could be faster than the growth of HDD capacity. I have doubts that most people can have enough space for a full node ontop of their own files and would probably just to forego that completely. Coupled with a fairly long initial synchronization as well as a catchup after not opening it for a while. |
|
|
|
I knew I would get a comment like this.
Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret? Or can we go with the simpler explanation of not many people are bothering to spin up a node and we shouldn't be making it harder to do so because at some point it may or may not be a problem.
Well, yes. If the service only records nodes that it can establish a connection to, then it wouldn't reflect those which aren't allowing it. There really isn't a reliable way to get every single node in the world. There isn't anyone trying to make the synchronization any harder than it is. Loads of optimizations have been made but older computers will still suffer due to their hardware. IBD will be the longest process for most so it really isn't that big of a concern as you're only doing it once. Samsung SN550, if a QLC drive causes it to take 4 weeks to sync something is really broken with the network. But like I said when I manually added a bunch of nodes that had either TELUS or Google Fiber as their ISPs my sync time dropped to 40 hours. Slowly as they disconnect and I go back to the 8-9 nodes my sync time goes back to 3 weeks.
Definitely shouldn't take 4 weeks, especially with NVMe if you're talking about WD SN550. My synchronization took a day with my HDD and 6 hours on my SATA SSD but they had 6GB of dbcache. Is your ISP throttling your connection by any chance? |
|
|
|
Those are the nodes which allows incoming connection. It's methodology gives an inaccurate sampling of the actual node count as it doesn't take into account the nodes that doesn't allow incoming connection.
Based on the estimate and how much I've managed to sync over the last three days.
More importantly when I added a bunch of Nodes manually the estimate dropped to 40 hours. and speed of sync dropped dramatically.
Adding nodes may not always help. Some nodes are crawlers which will not help in your synchronization and would infact slow it down. The synchronization estimate will fluctuate quite wildly, when it hits a patch closer to the present day, the synchronization would slow down a lot as the more recent blocks contains much more transactions to be validated. Increasing the dbcache will help quite a lot. Depending on your SSD model, some QLC SSDs will slow down significantly after the cache gets filled. |
|
|
|
1) how much of these transaction details do I need to share, and/or should I share publicly, without potentially being duped by someone else allocating my bitcoins (if the bitcoins are even retrievable)
Transaction's details are public on the blockchain, unless you're sharing your 12 word seed or your private keys, you should be fine. Sharing it does mean that your privacy would be gone; people can link the transaction to the account that you're using right now. 2) At the time I entered my coinbase wallet 'address', or so I thought, but nothing showed up, even after weeks of checking. so if I did end putting in the wrong coinbase number - does this mean coinbase could potentially help me in retrieving the bitcoins, or does this simply mean the bitcoins are lost in the deep ether of the internet?
I assume you are checking your transaction on a blockexplorer like blockchair.com? If it didn't show up on the blockexplorer, can you try searching up the address that you have sent the funds from? If the transaction ID cannot be found on the blockexplorer or if the address is wrong, Coinbase can't help either. |
|
|
|
|
Show Posts
