 Show Posts
|
|
Pages: [1] 2 3 »
|
With a decentralized system, it's very difficult (impossible?) to enforce an exact timestamp. Once you accept that there will have to be some variability, it's just a matter of deciding how much variability is acceptable. If 1 second is acceptable, then why isn't 2 seconds? If 2 seconds are acceptable, then why isn't 3? The actual designed purpose of the timestamp drives the decision on how much is acceptable.
Transactions don't have timestamps. Bitcoin doesn't care when a transaction happens. The entire purpose of the blockchain itself is to declare an ordering of transactions BECAUSE there is no reliable way to determine the time that a transaction happened. Rather than trying to decide exactly when on a clock a transaction happened, Bitcoin works by declaring the order in which they happened (regardless of time). Per the "rules" of the blockchain-based system, any transaction in a block at a lower block height "happened" earlier than any transaction in a block at a higher block height.
Since the blockchain eliminates the need to know the clock-time when a transaction happened, the sole use for the block "timestamp" is to compute what the average time between blocks was during the previous 2016 blocks, so that a new target difficulty can be computed for the next set of blocks. A variability of a few hours over a period of approximately 2 weeks isn't significant to managing the difficulty target.
Keep in mind that Bitcoin is designed to behave as much like a currency as possible. It isn't designed to be an accounting system or a historical record. It's designed to make it possible to receive a transaction and to know, beyond doubt, that the transaction is real and the sender actually had control over the value being received. If I hand you a $10 bill, there is no timestamp attached to the transaction. You just walk away. with control over that $10 value. Anything else that Bitcoin is capable of beyond that is simply a consequence of the best-known attempt to make such a transaction system functional in a digital/electronic form.
this is helpful. thanks |
|
|
|
The timestamp is set by miners, so it can be in the past or future. It must only be greater than the median timestamp of the last 11 blocks, and less than 2 hours in the future when received by a node. That's a multiple hour range, and variability is expected and normal.
thanks for the reply. i dont think i ever noticed it happening before. i would have thought a timestamp could not be variable. |
|
|
|
anyone notice this weird time stamp for block 915130? says mined 0 seconds ago or in the future (if that makes sense) https://imgur.com/a/9iT07eM |
|
|
|
|
looks like i'll have to upgrade to 1gb at least. i just have 300mb right now
|
|
|
|
I cant imagine having to do a full IBD in a few years time when the blockchain is over 1TB. That's not going to be a problem. Computing power is still growing at exponential rate, while Bitcoin's blockchain is only growing linear. maybe they'll be a need to start sharing pruned blockchains with people who cant or dont want to go through an IBD. See Bitcoin Core pruned blockchain: download it here! (DON'T DO THIS!)  so what's the approximate time now for an IDB to complete these days? and i think it will be a problem as the blockchain grows. if you always have to download the entire chain first before pruning, it's going to be prohibitive for more and more people to run a node. |
|
|
|
i have a full node running on my rapberry pi with a 1TB m.2 ssd. when i bought the ssd 3 years ago i think the chain was 450GB(?) about. now the storage is up to 700GB. I'll have to set my sights on a 2TB soon  I have this pruned node on my desktop which I daily drive so I can experiment with different settings and not have to constantly reboot the server on the raspberry pi. I took the 1TB storage from the raspberry pi and mounted it to my pc to copy the blocks and chainstate files. still took a few hours but better than waiting for a full IBD. I cant imagine having to do a full IBD in a few years time when the blockchain is over 1TB. maybe they'll be a need to start sharing pruned blockchains with people who cant or dont want to go through an IBD. |
|
|
|
hello there. i accidentally deleted these directories. i was running a pruned blockchain. i was hoping that when i restarted the server it wouldn't have to download the entire blockchain since i have it set to prune=2000. but it looks like it is downloading the entire chain. so i stopped it since i do have another copy of it that i can copy over what i need. but before i do that just wanted to do a quick verification that it's necessary to copy the entire chain before pruning. maybe there is some magic alternative?? thanks |
|
|
|
|
thanks for replies. i'll keep troubleshooting
|
|
|
|
|
anyone having trouble reaching mempool.space? can't load their website or use their APIs the last few hours
|
|
|
|
|
thanks for the great answer.
|
|
|
|
|
I have 2 separate nodes (version 26) running, each using their own wallet.dat file. the wallet.dat files have the same keys though.
if i migrate the legacy wallet on one of the nodes does it affect the other node's wallet? meaning do the legacy wallet's keys become invalid at all?
|
|
|
|
i mostly use linux but wanted a copy on a Windows machine in case a family member needed to access it since linux would be totally foreign to them. I'm laughing now because it probably doesn't matter what OS it's on. Bitcoin will harder to explain to them than linux Anyway, i had the blockchain on another hard drive separate from the Windows OS that just had files/documents on it (formatted as NTFS too). I did have that location in the config file. So from the comments here i decided to just move the blockchain files to the Windows default location and now Bitcoin is running without a problem with the pruned blockchain. A little annoyed it didnt work the way I wanted it, but I'll call it a win nonetheless. |
|
|
|
|
I'm using a pruned blockchain with bitcoin core version26 without any issues. I copied the blocks and chainstate folders and wallet.dat file over to another computer. but when i start bitcoin core it tells me i need to reindex the blockchain which will redownload the entire blockchain.
copying a pruned blockchain like this should work right?
|
|
|
|
Have you tried to use bitcoin-cli help instead of using -? it might only show limited commands compared to using "help".
"bitcoin-cli help" was it. it's funny because i has tried "bitcoin-cli --help" but that just gives the abbreviated list too. thanks for confirming my memory! |
|
|
|
running bitcoind -? or bitcoin-cli -? at the command line used to give me a pretty exhaustive list of options. I am noticing now many are now not listed (dumpwallet, getblockcount,getaddressbylabel,sendtoaddress,etc.) i found them here https://developer.bitcoin.org/reference/rpc/index.htmlBut why were they removed from the help pages? Or am I missing something. Back 3-4 years ago this is how I learned to use bitcoin at the command line. |
|
|
|
|
I've been running Bitcoin Core using bitcoind -daemon for the last few years. I have it running on my RaspberryPi and yes it uses the config file at ~/.bitcoin. I have the maxconnections set here to 30. Bitcoind always adhered to the maxconnections setting.
Just this week I decided to use bitcoin-qt (for the first time in a while) to teach someone about Bitcoin. So I shutdown bitcoind and started bitcoin-qt. Bitcoin-Qt always created a config file at ~/.config/Bitcoin/Bitcoin-Qt.conf. When I noticed the number of connections going higher than I set it, I thought I needed to add a maxconnections setting to that bitcoin-qt.conf file.
But I am realizing now that the bitcoin-qt.conf isn't the place to manually add settings. I guess it contains changes settings strictly made in the GUI. I decided to delete the current bitcoin-qt.conf file and restarted bitcoin-qt. It regenerated that bitcoin-qt.conf file and then somehow magically now it is adhering to the original maxconnections setting. Maybe the file was corrupt or something(?)
Anyway thanks for feedback, it helped me get back on track.
|
|
|
|
|
yes i've shutdown and restarted but it is still ignoring the max setting.
and i just dont want over a 100 people accessing my network.
|
|
|
|
|
I have maxconnections=20 set in the bitcoin-qt.conf file but it seems to ignore the setting. right now network connections at 48 inbound and 10 outbound.
When i run it as bitcoind, instead of using bitcoin-qt, the maxconnections works fine, but that is in a different config file.
|
|
|
|
Most sites don't update the total size, so the longer ago someone typed it, the smaller the number.
I currently have 4.6GB chainstate and 420 GB blocks.
thanks for the verification on your data |
|
|
|
|
