It's been 11-12 years, so most likely the website is either dead, drastically changed or owned by different people. You could try these option to find the website link, but you probably only waste your time. 1. Check your email or browser history, because membership website usually require you to register with email. 2. Check website such as https://en.bitcoin.it/wiki/Main_Page which have article about old website/service about Bitcoin. 3. Use https://ninjastic.space/search to find old post/thread on this forum (this forum have search feature, but it's quite limited). Set the end date to late 2010 and use relevant keyword (such as "membership", "faucet" & "free"). |
|
|
|
At least if you use 1.1.1.1 as DNS, this issue is already few known for past few years. According at https://webapps.stackexchange.com/q/135222, the problem is complicated and looks like won't be solved anytime soon. I would recommend people to use different archive service if they wish everyone could see archived page easily. |
|
|
|
people want to argue that you can't trust the new genisys block. bullcrap. you cuold. if enough big websites published the genisys block then people could come to a consensus pretty fast. i'm sure bitcoin.com and coinbase would oblige. (also I heard twitter is useful for publishing new genisys blocks).  and twitter has "verified" accounts so we could be sure! Rather than trust few for-profit company, why don't you just don't remove older block and replace "new" genesis block with snapshot block? In this scenario, new node could either 1. Trust the snapshot block, which means only sync starting from snapshot block. 2. Sync starting from snapshot block, then download & verify all older blocks. 3. Download and verify whole block sequentially (just like how Bitcoin Core currently works). but seriously, bitcoin was never designed to be able to verify the utxo set without having the entire blockchain so trying to put that feature into place now results in something that probably shouldn't even be tried to be done. a redesign of bitcoin might be more appropriate. from the ground up.
That would require hard-fork on Bitcoin protocol & major changes on Bitcoin software. i mean why not just stick the entire darn utxo set into a block once a month. that seems way simpler.
Simpler, but whole UTXO set is very big & quickly bloat blockchain. On Bitcoin Core, chainstate folder (which store UTXO) is around 4GB. Assuming each block has 2.5MB size, in 1 month (30 days), blockchain size would increased by ~10.5GB. If you also store whole UTXO set on blockchain every month, blockchain size would increased by ~14.5GB. |
|
|
|
how do I ensure Bitcoin core isn’t running when I go to copy the .dat files? I have been using qt and so I can “exit” it and I assume that closes it and stops it running but being new to Ubuntu I’m not sure. If you exit Bitcoin Core (right mouse on the system tray icon), it gives a popup telling you to wait until it's done. Once the popup disappears, you're good to go. Take note the way you exit Bitcoin Core doesn't matter (unless you use command kill), using shortcut Alt+F4 or press "X" on Bitcoin Core window will also show the pop up.
But if you're being very careful / paranoid, you could use this command (on terminal) to check if Bitcoin Core is still running. If Bitcoin Core (and other application name which contain "bitcoin") isn't running, the result should look like this. user 157604 0.0 0.0 6256 2376 pts/1 S+ 09:53 0:00 grep bitcoin
|
|
|
|
I'm unsure about this terminology. Is outgoing connection for me to get new block information from other nodes and is incoming connection for me to broadcast my own transactions out there if I were to use my full node with my hardware wallet?
Incoming connection means other peer/node which connected to your node, whereas outgoing connection is the opposite. As @ranochigo said, the connection is bidirectional which means your node can do every task without incoming connection. You definitely don't need incoming peers to use Bitcoin. If you're behind a NAT, you have to port forward your port 8333.
Alternatively you could add upnp=1 to bitcoin.conf if your modem support and enable UPnP (Universal Play and Plug). |
|
|
|
Similar technology already exist and it's called "UTXO commitment". The difference are,
1. It doesn't delete all older block before snapshot. So it;s possible to verify whether the snapshot itself is valid.
2. The goal is to speed up node sync process. Node have option to blindly trust it or verify it later after downloading whole block.
If it's go great then how come no one ever introduced it into bitcoin? There are discussion about it into Bitcoin, but the community generally not interested or don't like because some trust is required. There has to be some downsides as well, right? Exactly how does this utxo commitment thing work? We should go into some details so we can see if it really is any good or not. The thing we dont want to do in bitcoin is add alot of complexity and overhead in terms of processing and storage. But other than that, I'm all ears. Obviously there are downside. I don't remember if there are any standard for UTXO commitment, but here are few past discussion about UTXO commitment or other similar idea, 1. Idea:Add the UTXO set to blocks2. Proposal: including (UTXO) state hash in blocks (to eliminate IBD for new nodes)Especially if it would finally allow me to execute "sendrawtransaction" out of btc core without having to download an entire blockchain.
You could always use Electrum or block explorer though. |
|
|
|
|
Merit button probably unnecessary since you might need to read the thread to understand the post better (especially because few member don't bother quote above reply). However, the "Delete" button could be useful if you want to delete your posts for various reason (such as older shit post, protect privacy or wish to leave the forum).
|
|
|
|
|
Since you're asking this question on Bitcoin forum, many people would answer Bitcoin.
|
|
|
|
It doesn't... Relative to the rest of the spam that the network has to deal with. UTXOs are always getting added and deleted so the growth shouldn't be that significant. If your logic is that each UTXO imposes a burden on the network, then each transaction imposes a much higher burden than that, for which there is zero compensation to the nodes. How do we go about solving that?
I get the feeling that your question is somewhat rhetorical in nature and that you don't really believe that anything needs to be "solved". But there are possible solutions to the blockchain size issue. I even thought of one myself recently. Actually 2 of them. I'll share one of them here. the other deserves a bigger platform like its own thread maybe! Just take a snapshot of the utxo set after mining block #XYZ. The utxo set at that time will becomes the new genesis block. And that is all that would need to be saved. Rince and repeat every 10 years or so. Bitcoin purists and crypto historians can enjoy keeping the old blockchain and actually seeing how things got to the state they are in if they want to while the network goes on about its business in a more efficient manner. Similar technology already exist and it's called "UTXO commitment". The difference are, 1. It doesn't delete all older block before snapshot. So it;s possible to verify whether the snapshot itself is valid. 2. The goal is to speed up node sync process. Node have option to blindly trust it or verify it later after downloading whole block. Or just use SPV wallet if you can't or don't want afford to run full node. |
|
|
|
The news headline now updated, you could close this thread. In general, are there any stats for the number of clicks on that link, I think a lot of people ignore it.
It's direct link without referrer tag, so i doubt there's such stats. Besides, i doubt theymos care about how many people who actually see the news or click the link.. |
|
|
|
Usually it took some time before theymos (or whoever have such privilege) update the news. Similar thread always appear every time major update of Bitcoin Core is released. P.S. the correct version is 22.0 and it's intentional decision to change the versioning scheme (see https://github.com/bitcoin/bitcoin/pull/20223). |
|
|
|
Another issue, the bitcoin upgrade is coming, and I heard that Bitcoin may include a potential smart contract, but it would still make it appear centralized, is there any way for devs to do that while keeping decentralization?
If you're talking about Taproot, 1. Taproot doesn't enable "smart contract", but allowing more complex script potentially at lower cost (such as signature aggregation on multi-sig setup and only reveal necessary part of the script for HTLC). 2. There's no correlation between Taproot and centralization. There are time for Bitcoin community (node, exchange, wallet developer, etc.) to support Taproot after majority miner signal that they ready to support Taproot. |
|
|
|
Damn right I do. It's none of anyone's business if my wallets are lost or it's just my choice to not touch them.
The only problem with that unspendable utxos impose a burden on the bitcoin network (the rest of us). The only way to deal with that is by cleaning out the utxo set periodically. It's not serious problem, UTXO grow rapidly in last few years, but AFAIK it doesn't have big impact on cost of running full node. Raspberry Pi still can run full node at ease. I would argue that the nearly 400GB of block data would be a better point to argue from. Block data grows linearly while UTXO doesn't necessarily have the same growth.
yeah that really needs to be looked at because I have no interest in storing 400GB on a hard drive. Let alone ten times that. Then you should use pruned mode on Bitcoin Core or just don't run full node. |
|
|
|
Yes, it's different from what other member talking about. While it's open source, this is first time i heard this wallet and looks like it's not popular (total star only 51 & 7 on GitHub). As I understood, an private key starting with 5, give a legacy address only, and also give an uncompressed adress. Yes. Uncompressed WIF keys start with 5 and should only generate uncompressed legacy addresses. You can use them to generate other addresses, but these address will be non-standard and it will be very difficult to successfully spend any coins sent to such addresses. And here's example how difficult it is, https://bitcointalk.org/index.php?topic=5192454.0. |
|
|
|
Another option which haven't mentioned by other member is using online service such as pastebin where you just need to share 8 character long after pastebin.com (pastebin.com/XXXXXXXX). Obviously it's not ideal option if both party have privacy concern. Transfer the address to a clean and formatted USB drive or other removable media and physically give it to the other party or us the USB drive to transfer the address to an internet connected computer and send it to the other party.
IIRC you need admin/root access to mount any partition which isn't part of Tails OS. |
|
|
|
He did something good by copying the transaction information :
Relayed by IP 138.68.64.155 (whois)
If he got the information from blockchain.com (used to be blockchain.info), "relayed" only means Bitcoin full node with IP 138.68.64.155 relay/share the transaction to blockchain.com. It's very likely the node receive that transaction from another node. |
|
|
|
I think it's mathematically possible to get as final output a valid and randomly generated QR code that represent a privkey. It's possible, but unlikely. QR-codes include error correction too. You also need to choose which QR code standard and error correction level (there are 4 available levels) you're going to follow. I've tried it and it's possible to run the tool offline. |
|
|
|
|
Show Posts
