The data in these "Block.dat" files is not raw text anymore
It never was in the first place. but it seems like i need to read the files using
Berkeley-DB format which does not compile for me so does anyone know where I can download a Berkeley-DB Dll that
will work in VS .Net or any short cuts using .NET file streams
I think Berkeley-DB for the file format has been dumped and they now use LevelDB that is something
that Google started but getting a copy that will compile and works in MS-Dot.Net is no easy task
The blk*.dat and rev*.dat files - the files that actually contain the block data - are not database files. They are just files with the raw blocks dumped into them. You don't need BDB or LevelDB in order to read them. Those databases are stored separately. The format of the blk*.dat files is network magic (4 bytes) followed by length of the block in bytes (4 byte unsigned integer) followed by the block itself serialized in network format. This repeats until the file reaches a certain size. Then the next numbered file is used. |
|
|
|
Any timeframe when the site will be able to return to work or if it is final?
Consider it down forever. |
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
At this point, if I were to just save the wallet dat. file and completely uninstall and reinstall bitcoincore, is there any possibility that I will run into any problems with creating my wallet from the seed/passphrase?
That won't work. Firstly, the problem is with your wallet.dat file, not with your installation of Bitcoin Core, so reisntalling isn't going to change anything. None of Bitcoin Core's data is removed when it is uninstalled, only the exectables are. Secondly, Bitcoin Core does not use a seed or passphrase which can restore your wallet from scratch. You must have a backup of your wallet file. |
|
|
|
Ok so if I'm getting what you are saying is, once the block is solved below markel_root becomes a transaction id to send newly generated coins which is already included in blocexplorer's transactions
merkle_root = sha256(sha256(unhexlify(coinbase)).digest()).digest()
No, not at all. The coinbase transaction's txid is included as part of the merkle root. The construction of the merkle root is described here: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L9. Basically you concatenate the txids of pairs of transactions and hash them, then concatenate pairs of hashes, and so on until there is only one hash remaining. The fields Coinbase1, ExtraNonce, ExtraNonce2, and Coinbase2 are used to construct the coinbase transaction which pays the miner. The transaction id of that coinbase transaction is then used to construct the merkle root. |
|
|
|
No because I haven't recieved yet as I sent it back to my original bank I originally deposited the money from. When I click on transactions it says in red "sending", and when i click on the transaction itself it says "status": confirmed below where it says the date.
Then that is a service problem with the service not crediting your Bitcoin. The transaction is confirmed, that means it is completely and absolutely final. Contact the customer support of the service you are trying to send money to. |
|
|
|
It's in block 500010 it says. I use Blockhchain. Other info when I click on the transaction: "Confirmations": 3962. "Weight": 768. "Size": 192 bitgroups. "Status": Confirmed.
The transaction is confirmed, what's the issue? Confirmed means that the transaction is finalized. It has been confirmed for more than 3 weeks. |
|
|
|
Not just transaction ids, all of the parameters below
Coinbase1
ExtraNonce
ExtraNonce2
Coinbase2
Transaction Ids[]
Those parameters are part of the transaction ids. All of those parameters except for transaction Ids[] are for constructing the coinbase transaction. It's txid is then used in the merkle root. |
|
|
|
|
The merkle root is computed from the transaction ids.
|
|
|
|
I don't find it, the "main.cpp" file doesn't exists anymore, I've looked for the Genesis Block hash in validation.cpp and net_processing.cpp but i don't find anything  It's in chainparams.cpp |
|
|
|
By permission do you mean to be able to open the wallet?
Both read and write to the file. If you right click it and choose Properties, there should be a tab labeled Permissions or Security and there you can see whether your user has the permission to read and write to the file. And would you be able to suggest what may have caused this condition to occur? The wallet on this client is encrypted and is on my own personal machine. I haven't attempted to open the wallet in months but I have access if needed.
Copying files from different machines can result in conflicting file permissions. Could this be an attempt to open the wallet from someone connecting to my node?
Also, I did not think anything of it at the time because nothing seemed to happen but I did hook up a 21bitcoin computer to this computer about 4-5 days ago just to see if there was anything I could do with it but there did not seem to be any prompt or files I could see so I unplugged it and thought nothing more of it. Could it have begun to try to access the wallet because of the mining chip days later even if it wasn't connected anymore?
No. |
|
|
|
How can I make a vanity Bech32 address?
The same way you make a P2PKH vanity address (begins with a '1'); generate random private keys, calculate their public keys, hash the public keys, and encode it using bech32. You will need some software that can do that, but I don't know of any that currently exist. Are there any guides you can link me?
No. |
|
|
|
|
You make a block that follows different consensus rules and is consensus incompatible with the current blockchain such that it will be rejected by nodes not running your software.
|
|
|
|
What does bc1 mean? Is that the address that starts with a 1?
It's the beginning of every bech32 address, the ones that start with a "b". Another question, can you make a vanity Bech32 address like with the adressess that start with a 1 or is that not possible?
Yes. You can make a vanity address with any type of address. |
|
|
|
|
Bitcoin Core is unable to write to your wallet file. Make sure that your user has the permission to write to the wallet.dat file.
|
|
|
|
My question is essentially: is there any way to make it so that Alice could not spend the output after the relative locktime has passed?
No, there is no way for that currently. |
|
|
|
what is that, btw?: P2SH-P2PK. pay to public-key? isn't that an old relic from the past? wasn't the Base58 format introduced way back when to obscure the public key? unless of course, the P2SH part obscures it via the redeem script...but for what purpose?
Yes, it is pay to pubkey. The P2SH part obscures that because the pubkey is part of the redeem script. The reason for doing P2PK instead of P2PKH is that it takes up less space than P2PKH nested in P2SH. |
|
|
|
On high level, I understand that all wallet addresses private/public keys are define from single private key,
No, they are not. Each address has exactly one corresponding public key, and each public key has exactly one private key. The seed is used to derive the private keys. What I do not get, how the wallet app that I would use for potential recovery process "knows" how many addresses I actually generated/used and have unspent outputs (meaning BTC).
As Ledger generates new derived address for each tx and presumably new address for each tx change, there can be arbitrary number of addresses that had been used - and this is uknown to the recovery seed / wallet.
It doesn't know, it just guesses. Private keys and their addresses are derived in the same order and thus are given out and used in the same order. So when you restore a seed, the wallet will scan the blockchain for transactions and generate some number of addresses ahead of the last address known to have a transaction currently in the scan. This number of addresses is called the gap limit, and is typically 20. Every time a transaction is found corresponding to an address in the gap limit, it will refill the gap limit by generating more addresses. How does then the recovery wallet app rebuilds from seed the wallet with all relevant addresses?
Read BIPs 39 and 32. BIP 39 specifies how the mnemonic is generated and then interpreted as a seed value. BIP 32 specifies how that seed value is used to generate the master private key and then how all other private keys are derived from that master private key. |
|
|
|
|
Show Posts
