New answers tagged

0

You can use btcposbal2csv.py script to export the list to CSV. To get current addresses with positive balance, let the full node client sync with the network. Stop the bitcoin-core client before running this utility. If you not stop the client, the database might get corrupted. Then run this program with path to chainstate directory (usually $HOME/.bitcoin/...


0

You can use btcposbal2csv.py script to export the list to CSV. To get current addresses with positive balance, let the full node client sync with the network. Stop the bitcoin-core client before running this utility. If you not stop the client, the database might get corrupted. Then run this program with path to chainstate directory (usually $HOME/.bitcoin/...


0

There is now also the Esplora explorer / REST API. It's completely open source and you can host an instance yourself. A public one runs at blockstream.info.


0

Most complete list of blockchain explorers is present in the Bitcoin wiki: https://en.bitcoin.it/wiki/Block_chain_browser Note that some of these API providers are not maintained anymore. So be careful about selecting one. Also, only few explorers in the market support SegWit but it is used widely now so it should be taken into account.


1

As a third party to the transaction, its hard to say what the most likely case is. You can guess, but there are a number of possibilities, and some wallet software will deliberately create transactions which confuse this sort of analysis. To add to your list of possibilities: Someone sent 25.99 bitcoin to another person/organization Someone sent 1 bitcoin ...


2

You cannot say for sure. The three options are potentially true. However, many clients build transactions with the change output as the last output. So, following this convention, I would say option 2 is the most likely.


1

2 confirmations means the transaction was included in a valid block and that block was continued by another valid block. Option 3, although it should be next block (older than the one that contains the transaction) instead of previous block.


0

The block hash is the output obtained when hashing the header of a bitcoin block. The header of a bitcoin block is comprised of several pieces of data, one of which is the merkle root. So having the merkle root alone is not sufficient to calculate the block hash, you would need additional information (the rest of the block header). You could write some code ...


1

Distributed Ledger Technology is totally reliant on participation to establish the principle of Distributed Trust. If there are not enough independent actors in the network, you cannot rely on the immutability of the ledger. This is always an advantage of blockchain over every other technology and never a disadvantage. Think about this for just a second. ...


5

You don't necessarily need to "buy" external participants You can have a not-a-cryptocurrency blockchain that's maintained and controlled by a single mostly-trusted entity without any proof of work requirement. This makes the maintenance of the blockchain cheap and efficient, while still enforcing some technical constraints on what that entity can ...


4

This answer kind of jumps around a bit, but I think it's all relevant info. There is a TL;DR at the bottom that more directly answers the question. Distributed Ledger Technology is totally reliant on participation to establish the principle of Distributed Trust. If there are not enough independent actors in the network, you cannot rely on the immutability ...


36

There are a number of research papers that cover the question "Do you need a blockchain?", e.g. the eponymous paper by Wüst & Gervais (2017) and the extensive Blockchain Technology Overview by NIST (2018). At a quick glance, the article When do you need blockchain? Decision models. by Meunier appears to provide a survey collecting a broad range ...


0

It's normal, because the number of transactions are bigger. The blockchain size is very big one, and it depends in your internet speed, it can take even 4 weeks to download the entire blockchain


1

To be short: Without a ledger recording everything, it won't be possible to know whether Alice had ever signed another double-spending transaction. Even if we have a ledger, or even better, a tamper-evident, append-only ledger (which is the inherent nature of blockchain), it's still enough, because the ledger itself could still be maliciously truncated & ...


3

My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain? A node has no concept of who controls certain outputs. So there is no way to 'check all of Alice's outputs', how would the node be able to ascertain which outputs belong to her? Rather, the ...


1

Simply, the block chain is to prevent double spending. Otherwise Alice could present different transactions to different people, all with valid signatures, that spend the same money in alternate ways. With a ledger containing every transaction that has been executed, we know that the money can be spent exactly once.


5

I thought 3 random "validators" could be picked to do the hash-math. Only if all 3 get the same result, it is stored to a "temporary" blockchain. And only if say the next 3 blocks worked with that result, it will be placed in the actual Blockchain. If 1 of 3 gets a different hash, 3 other random people are selected to validate. The devil ...


0

Yes, it's the whole block. The hex text is 2.5 MB. Hex has 50% efficiency, so the block is 1.25 MB. Since SegWit, blocks can be larger than 1 MB. There's a 4 MB hard limit which is almost impossible to reach. (With the largest block to date being 2.4 MB, 4.8 MB in hex)


1

First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g. round numbers (e.g. three outputs with round amounts and one not) wallet fingerprinting (e.g. all inputs are ...


2

I assume that you are actually asking about the order in which miners include transactions into their block template. Miners will group each transaction grouping them its ancestry. The effective fee rate of such a transaction group is Σ(fees)/Σ(size) over all transactions in the group. Let's assume there are two transactions waiting, A and B, where B is a ...


1

No it doesn't. Only the ancestor size is taken into account.


0

Version, hashPrevBlock, Bits (a representation of the current difficulty) are static for the current block, the timeStamp is a unix representation of the current time, the miner can change it to change the blockheader too (untill 2 hours in the future)


2

While calculating the Transaction fee miners usually take Ancestor size into the account. But does the descendant/Output also effect the transaction fee calculation? The descendant transaction(s) do not restrict the inclusion of the examined transaction in a block, while the ancestor transaction(s) do. Hence, it would seem rational for the miner to only do ...


1

Cryptographic hash functions are collision resistant and the digests produced by SHA-256 are approximately uniformly distributed. This suggests that if the input space to the hash function is magnitudes bigger than the projection space of a hash function, we would expect that every value of the projection space can be hit. The block header is 80 bytes, and ...


1

An alternative method, (working with recent versions), that does not depend on external websites, is to use bitcoin-cli getblockchaininfo and compare the headers field and the blocks field. Currently, in order to sync the blockchain faster, headers are downloaded before the actual blocks. This is known as Headers-First Sync As a consequence, the number of ...


-1


1

No, not necessarily, but mining in both locations is infeasible. As Pieter explained in Is it possible to use bitcoin as interplanetary money/store of value?, exorbitant latency between miners would cause perpetual forks especially when the latency exceeds the targeted block interval. Only one of the two latency-separated mining clusters can be profitable: ...


0

Yes, I'd say it's guaranteed to fork because a longer block time wouldn't mean higher latency is tolerated; it's assumed that all miners have infinitesimal-latency access to new blocks. However, lots of blocks being orphaned doesn't mean a fork has to happen. I'm telling you a fork is guaranteed because of economical reasons: It's much healthier for every ...


Top 50 recent answers are included