Depending on capacity of your external storage, you could try compress all files/folders into .rar or .7z file with maximum compression. I did quick experiment with blockchain data for Bitcoin Signet (similar with Bitcoin testnet) where ~798MB folder compressed into ~505MB .7z file.
The result isn't bad, but we know strong compression/decompression process require more CPU/RAM. It's much more impressive than I expected. 7z is probably also more powerful than what was previously proposed, depending on the compression level of choice, still, I'm impressed. To be specific, that 7z use LZMA2 algorithm which is known to be slow. Does the node need the entire blockchain "at hand" in order to validate transactions, or it has the UTXOs somewhere else?
No, Bitcoin Core has directory called chainstate which contain all UTXO. That's why people say pruned node still perform full verification. Because if it needs to continuously unpack old blocks then indeed the computing power spent probably not worth it.
It's also not worth if you need to look up for specific transaction or block frequently, which is needed when you run self-hosted block explorer or Electrum server. And if one wants to save space he can just use pruned node.
People also could try built-in compression feature on the disk format. IIRC NTFS and BTRFS have such feature. |
|
|
|
Compressing data into a format like .zip or .tar can roughly decrease file sizes by a factor of 1/3rd.
500 / 3 = 166 gigabytes.
While I do not support most updates or amendments to bitcoin core, I do wonder if compression of file sizes may become necessary at some point to maintain node support.
Did you actually try this out? I would be overly surprised if you get for real these numbers. Plus, as LoyceV said, your math is wrong. Some time ago i did that, although using Bitcoin Signet (similar with testnet, except SegWit is always enabled). Depending on capacity of your external storage, you could try compress all files/folders into .rar or .7z file with maximum compression. I did quick experiment with blockchain data for Bitcoin Signet (similar with Bitcoin testnet) where ~798MB folder compressed into ~505MB .7z file.
The result isn't bad, but we know strong compression/decompression process require more CPU/RAM.
Student got 1 terabyte gdrive when login in using college email. and maybe more than 5 terabytes when you have enough shrewd to modify your friend email using Cbackups software.
Hosting anything that is not student related on that cloud account is against their terms of service and could mean that the cloud storage gets terminated. It is only limited to the time that the person is a student to so you would have to think about long term solutions even if you could host the blockchain in the student cloud that a couple of years. It is not a permanent solution but a cheap 1tb, 2tb, 4tb hard drive is a permanent solution. Unless you claim your study/research is related with Bitcoin  . Although AFAIK storing file which violate copyright is more risky. |
|
|
|
it's all very easy without the header, there's no way to prove that a disk is encrypted so: - encrypt disk
- copy header
- fill the header up (on encrypted disk) with random data
It could work, but this is definitely overkill considering OP mention his goal is holiday and very complex even for tech geek. There is no gurantee that this distribution i.e. Linux Tail is not Eavesdropping on you.
But compared with most OS, Tails is probably one of best OS for privacy. It's open source, has been around for >10 years, trusted by various group and actively used by people who really need privacy/security. If you talk about Linux then there are many tools (Linux Unified Key Setup (LUKS) that can encrypt your data and even if someone was able to login to your device he wont be able to see the data.
But on device with disk encryption, you usually need to decrypt it before you can login to OS user account. |
|
|
|
Energy usage of bitcoin is high enough as it is and should be reserved for more worthwhile applications.
The actual problem is limited block size capacity, not energy usage to mine Bitcoin. Theoretical transaction/second isn't affected by total hashrate/energy to mine Bitcoin. Full node developers should get to work and non-standard that to prevent such spams from growing on the chain.
But what can be done to prevent this kind of spam? Adding more hard limit (such as maximum tx size or maximum redeemspend script size) require hard fork and it can be mitigated by creating multiple transaction. |
|
|
|
Or just read Electrum protocol documentation[1]. But as mentioned above, most Electrum server implementations have even smaller limits than blockexplorer APIs, which is set by default.
And the limit is rather complex. Aside from maximum data size, there's also response delay after hitting soft limit and maximum connection[2]. I thought maybe these servers are limit less and work like nodes where we can query data. Was thinking to make a custom payment processor but it seems not possible with this approach.
Thank you
But unlike Electrum server, you can't just request specific data based on known address/txid to Bitcoin node. Most node implementation also have limit maximum upload/day. [1] https://electrumx.readthedocs.io/en/latest/protocol-basics.html[2] https://electrumx.readthedocs.io/en/latest/environment.html#envvar-INITIAL_CONCURRENT |
|
|
|
What was the use of the OP_RETURN Wars if Taproot would allow people to put arbritary data in the blockchain again freely?
1. Omni layer and other kind of colored coins (nowadays it's called NFT) use OP_RETURN as part of their protocol. 2. Using OP_RETURN allow you to create only 1 transaction. 3. Many block explorer show decoded text from OP_RETURN output, which means higher accessibility. 3. Easier to use. You can even use Electrum to do that. |
|
|
|
ETFbitcoin yes I did it. By this problem is not from AV. I tried via local host and via web server. Version 0.12.0 works the new 0.13.0.
And I can't use 0.12.0 since I'm with RTX 4090 that is not supported till hashcat 6.2.6 and I was able to run hashcat till 0.6.0 on 0.12.0 after this it's an Hashcat error from hashtopolis forum I found that the command error is connected with newer version of Hashcat that is not supported by Hashtopolis 0.12.0 and I'm stuck with 0.13.0 and at this point very curios what is the problem for even self education.
If some one have any ideas here a the server credentials for root login maybe someone can find something that I have missed.
I've no idea to use Hashtopolis, you might want to ask help on https://hashtopolis.org/ instead. Server IP [REDACTED]
User: [REDACTED]
Password: [REDACTED]
OS [REDACTED]
Server hash only hashtopolis on it so there is nothing to hack, provider [REDACTED]
I strongly recommend you to remove those information and purge the server immediately. It's just matter of time before someone take over the server, change the password, turn your server into botnet and your server provider decide to purge the server (and possibly ban/freeze your account). @LoyceV and @TryNinja please redact those information from your website. |
|
|
|
--snip--
And what are you going to say under a targeted search when they ask you why you have an airgapped phone with no SIM card in it?
On many country, there are prepaid SIM card which targeted towards foreign tourist or businessman. So you could say you'll buy it later (e.g. after you pass the border or enter hotel). I'm fairly sure you can buy one at most airport. I think a USB live distro with encryption + persistance could do the trick. Electrum / pruned node on it
We're going back to circle. Someone already mention the worker at border might perform random search and ask you to decrypt it. If they find cryptocurrency wallet/software, they could suspect you're trying to evade "crypto travel rule" from FATF or other similar rule. |
|
|
|
Don't forget reward from merge mining, assuming it's still a thing in next >100 years.
Maybe it is the term you are using but what is merge mining? Basically it means you mine Bitcoin and other cryptocurrency at same time. The other cryptocurrency rely on Bitcoin mining security, where no change is needed on Bitcoin protocol/consensus. If you really curious about it, i'd recommend you to read https://blog.bitmex.com/the-growth-of-bitcoin-merge-mining/. |
|
|
|
Who decides on those 20 minutes anyway?
This is good question. On Bitcoin Wiki, 20 minutes only mentioned since early 2013[1]. But afterwards i found out Gavin Andresen propose this[2] and create pull request some time later[3]. I checked the last 2 days, and to my surprise only 115 blocks per day get mined.
Mining difficulty on testnet keep rising which discourage some people to perform mining, where people with CPU/GPU only expect to earn tBTC from 1 difficulty after 20 minutes. I'm surprised because the total block height is much higher than for Bitcoin.
Probably because now we have separate testing network dedicated for newer Bitcoin feature (e.g. signet and segnet) and in past people attempt to attack/stress Bitcoin testnet by mining with tons of ASIC.
[1] https://en.bitcoin.it/w/index.php?title=Testnet&oldid=35502[2] https://bitcointalk.org/index.php?topic=50223.msg627957#msg627957[3] https://github.com/bitcoin/bitcoin/pull/686 |
|
|
|
What if the Bitcoin community could get consensus on building another chain, let's call it "The Miner Chain", that's merged mined with Bitcoin to continue incentivizing the miners through the "Miner Chain" with block rewards, for them to keep securing the network? Would that be a possible solution? Or would it just be something that could make some problems on the incentive structure?
It's possible and some pool already perform merge mining, BitMex wrote good article about it 3 years ago[1]. RSK sidechain even made claim their coin is most profitable merged mining[2]. [1] https://blog.bitmex.com/the-growth-of-bitcoin-merge-mining/[2] https://mining.rsk.co/, section "3. Start Mining" |
|
|
|
Setting up a full-node to use during a week or two of holiday seems excessive.
I agree, although it's less excessive if you create your own or use someone's else snapshot of pruned node (such as https://prunednode.today/). HW's are anti privacy because it already reveals by default you are holding Bitcoin.
Actually this is mostly incorrect. At least the HW I have doesn't write anywhere it's a HW and also doesn't write Bitcoin on it. So your HW is just another electronic device most will not even know what it is and for what (I don't know how all HWs look like, do you..? And then what you expect from the customs employee?) But with recent "crypto travel rule" from FATF which followed by some country, there's higher chance border employee would know existance of cryptocurrency HW. |
|
|
|
Don't you think that there will be a serious problem and panic in the industry?
No. The only concern is half of miner permanently stop mining which reduce difficulty/Bitcoin network security by half. Although looking at current mining condition, IMO half current hashrate is still more than enough to secure Bitcoin network. |
|
|
|
Although id like to see in the future is nodes that can download in reverse so full nodes can function. but have a minimum of the last year of data.
It's not matter of time, but rather whether someone would bother modify existing full node software to add such feature. It can be done by downloading all block headers then download blocks in reverse which skip many verification. to mitigate initial sync /initial block download time there are some options
one is a 'ball&chain'
where say for instance its assumed that block 0-630,000 are assumed as immutible. and mile stoned where you just download a ball of UTXOset(lump of data of utxo with its own string ID) of which you then build a chain from block point 630,001 assuming and calling the block 630,000 as the 'genesis' (first block of full chain data)
thus not needing to keep any "spents" of blocks 0-629,999 in the form of a chain
ofcourse it would need some coding and activation for nodes to understand this concept, but thats a discussion for the future
UTXO commitment also has similar idea. #2) they probably won't last as long as older lower capacity hard drives until they die for one reason or another.
Is this statement based on your own experience or certain article/research? |
|
|
|
Take note most light/SPV wallet isn't designed with privacy in mind. If you wish to have better privacy without running any node/server, seek wallet which use BIP 157/Neutrino. It is the same when it comes to the verification they do. Electrum downloads and verifies all block headers (each header is just 80 bytes) and it is capable of detecting chain splits and can verify things with multiple nodes. Other implementations sometimes don't have those options.
Take note few implementation such as Electrum heavily optimize block header size[1], while other implementation might implement it naively which require user to download >100MB worth of block header when they run wallet for first time. [1] https://electrumx.readthedocs.io/en/latest/protocol-basics.html?highlight=80#block-headers |
|
|
|
- Show wrong balance or modify your balance.
Take note Electrum is SPV wallet (which perform some verification), which make this kind of attack more difficult. Although there's exception where the server choose not to return specific relevant transaction. |
|
|
|
|
Show Posts
