dig for a particular domain is more interesting, e.g. dig seed.bitcoin.sipa.be
Here you go: $ dig seed.bitcoin.sipa.be
; <<>> DiG 9.16.42-Debian <<>> seed.bitcoin.sipa.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61590
;; flags: qr rd ra; QUERY: 1, ANSWER: 25, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 0af475c1f0939a11a87af7a465a31ae45af798cbd8c77e88 (good)
;; QUESTION SECTION:
;seed.bitcoin.sipa.be. IN A
;; ANSWER SECTION:
seed.bitcoin.sipa.be. 2425 IN A 217.155.244.170
seed.bitcoin.sipa.be. 2425 IN A 192.222.24.54
seed.bitcoin.sipa.be. 2425 IN A 206.123.132.176
seed.bitcoin.sipa.be. 2425 IN A 78.21.167.8
seed.bitcoin.sipa.be. 2425 IN A 20.229.118.67
seed.bitcoin.sipa.be. 2425 IN A 174.61.110.113
seed.bitcoin.sipa.be. 2425 IN A 3.26.208.206
seed.bitcoin.sipa.be. 2425 IN A 95.67.18.102
seed.bitcoin.sipa.be. 2425 IN A 81.217.238.213
seed.bitcoin.sipa.be. 2425 IN A 143.110.147.13
seed.bitcoin.sipa.be. 2425 IN A 188.195.140.16
seed.bitcoin.sipa.be. 2425 IN A 95.216.242.49
seed.bitcoin.sipa.be. 2425 IN A 82.124.202.187
seed.bitcoin.sipa.be. 2425 IN A 158.129.140.201
seed.bitcoin.sipa.be. 2425 IN A 18.222.180.86
seed.bitcoin.sipa.be. 2425 IN A 35.199.123.23
seed.bitcoin.sipa.be. 2425 IN A 178.21.118.178
seed.bitcoin.sipa.be. 2425 IN A 46.188.30.118
seed.bitcoin.sipa.be. 2425 IN A 189.114.207.217
seed.bitcoin.sipa.be. 2425 IN A 18.222.209.13
seed.bitcoin.sipa.be. 2425 IN A 90.105.246.85
seed.bitcoin.sipa.be. 2425 IN A 35.170.55.36
seed.bitcoin.sipa.be. 2425 IN A 192.228.178.14
seed.bitcoin.sipa.be. 2425 IN A 18.224.59.88
seed.bitcoin.sipa.be. 2425 IN A 187.189.153.130
;; Query time: 11 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sun Jan 14 01:21:08 EET 2024
;; MSG SIZE rcvd: 477
There were some improvements made to stalling detection behavior made in the last year. Can you try using 25.1 or 26.0?
I just upgraded to 26.0. For about 10 minutes now, it has stuck at "initload thread exit": $ sudo tail -f /home/bitcoin/.bitcoin/debug.log
2024-01-13T23:12:58Z opencon thread start
2024-01-13T23:12:58Z msghand thread start
2024-01-13T23:12:58Z [tor] Get SOCKS port command yielded 127.0.0.1:9050
2024-01-13T23:12:58Z [tor] Configuring onion proxy for 127.0.0.1:9050
2024-01-13T23:12:58Z [tor] ADD_ONION successful
2024-01-13T23:12:58Z [tor] Got service ID ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd, advertising service ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd.onion:8333
2024-01-13T23:12:58Z [tor] Cached service private key to /home/bitcoin/.bitcoin/onion_v3_private_key
2024-01-13T23:12:58Z AddLocal(ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd.onion:8333,4)
2024-01-13T23:14:04Z Imported mempool transactions from disk: 245 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2024-01-13T23:14:04Z initload thread exit
I searched the Internet for "stale tip detected" and no stackexchange posts dive into the detail of what's this all about. Can someone explain me what's the problem? First time reading about "stalling detection". (I revealed the onion address, in case you want to diagnose it from your end) |
|
|
|
Hm. Weird. I added debug=tor to the configuration file, rebooted the device, and it now works. Tor runs fine, Bitcoin Core is syncing. I literally did not change anything else, and that's the bad part, because I don't know what was the fault so I can fix it in the future. (The debug.log didn't show any errors, but I can share it if you insist) Any new antivirus or firewall software or updates which could be blocking ports, etc? No, nothing. I had followed Raspibolt's installation tutorial quite a long time ago. No software blocks port 8333. It looks like the DNS server you are using isn't returning any responses for the DNS seeds. Have you specified any particular DNS server? What response do you get if you get DNS records from the DNS seeds with dig?
Oh, I must have screwed it up with DNS. Not entirely sure, but I think I had changed something around that last year. Here's dig's output: $ dig
; <<>> DiG 9.16.42-Debian <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56056
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 3bce0aa3567b5d1249fe618865a2decae8ab20eb1454add7 (good)
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 440064 IN NS i.root-servers.net.
. 440064 IN NS m.root-servers.net.
. 440064 IN NS a.root-servers.net.
. 440064 IN NS d.root-servers.net.
. 440064 IN NS f.root-servers.net.
. 440064 IN NS c.root-servers.net.
. 440064 IN NS l.root-servers.net.
. 440064 IN NS j.root-servers.net.
. 440064 IN NS k.root-servers.net.
. 440064 IN NS h.root-servers.net.
. 440064 IN NS e.root-servers.net.
. 440064 IN NS g.root-servers.net.
. 440064 IN NS b.root-servers.net.
;; Query time: 11 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sat Jan 13 21:04:42 EET 2024
;; MSG SIZE rcvd: 267
Edit: Just stopped again: 2024-01-13T19:37:11Z UpdateTip: new best=0000000000000000000240f175b8c1d2be32786af8fcad523989f39733c8ec91 height=825246 version=0x20400000 log2_work=94.658582 tx=950438404 date='2024-01-11T05:27:27Z' progress=0.999320 cache=217.7MiB(1461058txo)
2024-01-13T20:08:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2024-01-13T20:19:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2024-01-13T20:29:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2024-01-13T20:40:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2024-01-13T20:50:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)
$ bitcoin-cli -getinfo
Chain: main
Blocks: 825246
Headers: 825666
Verification progress: 99.9304%
Difficulty: 73197634206448.34
Network: in 0, out 0, total 0
Version: 230000
Time offset (s): -1
Proxies: 127.0.0.1:9050 (ipv4, ipv6, onion, cjdns)
Min tx relay fee rate (BTC/kvB): 0.00001000
|
|
|
|
|
Didn't Greek-Team shut down?
|
|
|
|
|
PREMIER LEAGUE: Manchester City, Liverpool, Arsenal
LA LIGA: Real Madrid, Barcelona, Atletico
BUNDESLIGA: Bayer Munich, Leverkusen, Leipzig
SERIE A: Milan, Inter, Juventus
LIGUE 1: PSG, Nice, Monaco
TOP GOALSCORER: Kylian Mbappe
BTC PRICE: $68,000
|
|
|
|
You can not get completely airgapped device as machine might be subjected to pre-shipment inspection by manufacture that includes the checking its connectivity to Internet.
If the machine is provably airgapped, then how can such inspection harm the user? As long as the wallet is legit, recommended and airgapped, there is nothing that will happen because you only want to use the device for signing transaction and also for other offline purposes. Technically speaking, there can be other attacks. If the manufacturer knows you're going to install a particular wallet software under a particular operating system, they can tamper with the BIOS and inject malicious code to compromise the security of the computer. However, I have never heard of any such attacks in practice. But, this is a reason why it's recommended to buy general purpose computers (like Raspberry Pi with SeedSigner) and not hardware wallets. |
|
|
|
Bitcoin Client Software and Version Number: Bitcoin Core 230000 (23.0). Operating System: Linux raspibolt 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux. System Hardware Specs: 3.7 Gi total memory (929 Mi used, 122 Mi free, 2.7 Gi buff/cache, 2.7 Gi available), 1 TB external HDD (153 GB left available). Description of Problem: My node finds no addresses to connect. I have tried removing peers.dat and restarting bitcoin daemon. I have also tried restarting the computer. I have confirmed it has Internet connection, and it does initiate connection with the DNS seeds. It simply finds 0 addresses. I have tried adding a node with addnode, but it remains at 0 incoming and outgoing. Log Files from the Bitcoin Client: $ tail -f /home/bitcoin/.bitcoin/debug.log
2024-01-13T11:04:50Z init message: Starting network threads…
2024-01-13T11:04:50Z net thread start
2024-01-13T11:04:50Z dnsseed thread start
2024-01-13T11:04:50Z addcon thread start
2024-01-13T11:04:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:04:50Z opencon thread start
2024-01-13T11:04:50Z msghand thread start
2024-01-13T11:04:50Z tor: Got service ID <deducted>, advertising service <deducted>.onion:8333
2024-01-13T11:04:50Z AddLocal(<deducted>.onion:8333,4)
2024-01-13T11:04:50Z init message: Done loading
2024-01-13T11:07:15Z Imported mempool transactions from disk: 278 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2024-01-13T11:07:15Z loadblk thread exit
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.bitcoin.wiz.biz.
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.btc.petertodd.org.
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.bitcoin.sipa.be.
2024-01-13T11:09:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:14:50Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl.
2024-01-13T11:14:50Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch.
2024-01-13T11:14:50Z Loading addresses from DNS seed dnsseed.emzy.de.
2024-01-13T11:14:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:19:50Z Loading addresses from DNS seed seed.bitcoinstats.com.
2024-01-13T11:19:50Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org.
2024-01-13T11:19:50Z Loading addresses from DNS seed dnsseed.bluematt.me.
2024-01-13T11:19:50Z 0 addresses found from DNS seeds
2024-01-13T11:19:50Z dnsseed thread exit
|
|
|
|
|
Bump. Available for rent.
|
|
|
|
Is Sparrow Wallet trusted for such task? It is good software for generating seed phrases, but it seems like you want to introduce more complexity than needed. I'm planning on doing it on an offline PC without ethernet cable and booting Linux from a USB installation disk (Example:"Try Ubuntu before Install" option). Just to clarify in case you didn't know about this: removing the ethernet cable alone does NOT make the machine airgapped. You'll have to isolate it from every network it can potentially connect. That means, removal of Wi-Fi and Bluetooth adapters at least. Once the seed phrase is generated I'll backup and import it into an air-gapped hardware wallet. My question is: why don't you generate the seed phrase on your hardware wallet? If you trust using it, then you should trust it for generating you the seed phrase. Also, another question: what's your hardware wallet? The majority are not airgapped. |
|
|
|
Our Supreme leader traveled to January 3rd, 10 minutes before the genesis block, and started the blockchain earlier, sending me this transaction. I bet she's currently drinking her morning coffee, reading the "brink of second bailout" newspaper, laughing about what she's about to do. |
|
|
|
Note that "blocks" directory is pruned, but "chainstate" is not. My bad. You can inject arbitrary data in UTXO. It's just more expensive. By the way: Bitcoin is not about storing data forever. It is about double-spending problem. And if some coin was created, then moved between many people, and then 100% of that was turned into fees, then that history can be safely pruned, because if a coinbase transaction, which collected those fees, is good enough to be spent, then everything below that is now rock-solid The history of those coins can be safely ignored in the sense that they were recreated, but you do need to know about their past to reach their future, so some nodes will still need to store that piece of information. |
|
|
|
I have an old legacy paper wallet that i would like to ideally "sweep" onto a Passport device while keeping my private keys airgapped. Is it in Wallet Import Format? Meaning, does it start with 5, K or L? If so, do what LoyceV has suggested above. You'll have to dedicate a spared computer for this operation, which will be used to safely create and sign your transaction without exposing the private key to an Internet connected machine. If you have any questions, we're here to help you get this done. |
|
|
|
Note that "status quo" is the default. I get it. The gamble is whether this conservative approach of not doing anything prevails on the long term. It is as much a problem as a feature. But, to not go off-topic, I believe this will not pass. No sane miner would accept working on a chain that censors this type of transaction. Because all limits are successfully bypassed, one-by-one. And UTXO set has no consensus-enforced limit. Which means, that if it is possible to abuse pruned nodes, and to make them store as much data as non-pruned ones need today, then someone will do that.
Pruned nodes keep the UTXO set, but you can't inject arbitrary data there, like Ordinals. So, how can you store as much data as non-pruned nodes? Maybe you can encrypt the content using your private key, this way nobody else can retrieve the content of the file you inscribed. Not a lawyer, but distributing illegal material encrypted sounds illegal. What if you post your private key publicly? Encrypted isn't local. |
|
|
|
No, it will happen anyway, even if you don't "censor" any transaction. It depends if UTXO-level batching will be there or not. But, why will it happen anyway? Do you mean that it is simply possible to happen given enough incentive? Every soft-fork causes that. It would be no worse, but in what other way you want to upgrade the network? I see. So you're arguing for softfork. I don't watch the mailing list lately, I think since the Linux foundation announced they will be shutting down their mailing servers. If I recall right, you were active in bitcoin-dev, so let me ask you, is there discussion about implementing a softfork for this very purpose? I mean serious consideration, not just beating the air. |
|
|
|
For example UTXO flood. That is probably what's going to happen if you attempt to censor Ordinals. The Ordinal users will find another loophole, and flooding the UTXO set is their last resort. It is possible to check only signatures for Ordinals, and skip their data entirely. They are just huge OP_NOPs. But if you can verify signature hash, then you don't have to store signature data. That is actually an interest approach. However: - That will split the network in terms of clients, similar as to how anti-segwit and segwit nodes operate separately (e.g., anti-segwit nodes ignore witness). - Everything inside OP_NOP will be ignored, including potentially genuine, non-Ordinal content. Also, how can you verify the signature hash if you don't have the full message? |
|
|
|
1. There are worse things than Ordinals. Like what? If you want to show, that you don't support Ordinals, then just enable pruning. If enough people will do so, then those Ordinals owners will need to start running their own full nodes (and taste their own medicine) to see their data. This sounds like a really bad idea. First things first, my full node only serves them bandwidth-wise. It does not act as their Ordinal explorer. If I don't serve them bandwidth-wise, someone else will, probably mining pools or just people who would rather buy a good Internet connection and a terabyte drive than their 1000th Ordinal. Secondly, suspending my node's access to the blockchain for the sake of the Ordinals sounds like an actual defeat. Pruning comes with disadvantages on an individual level and we all know about it. |
|
|
|
|
I remember spending more than 10 inputs and paying less than 20 cents. Good times.
|
|
|
|
|
At first, I thought he was thanking her in advance. Then, I thought she might have had a poor Internet connection. Now it is abundantly clear. Time machine.
|
|
|
|
and now those same good samaritans that are funding developers start pushing a campaign to engineer a rollback of the blockchain Vitalik style. There is one big difference here. Nobody thinks Ethereum is decentralized to begin with. Sure, when they hardforked, Ethereum Classic was born, but who gives a damn about Ethereum Classic? Ethereum is a premined, centrally controlled cryptocurrency, which is now even worse with their Proof-of-Stake model, operated by Vitalik and his rich friends. Apples and oranges with bitcoin. |
|
|
|
|
How come no one wants to rent ChartBuddy's signature?
|
|
|
|
|
Show Posts
