Show Posts
|
Pages: [1] 2 »
|
Am I right that LevelDB stores information like number_of_block -> name_of_file_for_that_block and it's done for downloading blocks in parallel? If so, then what is the format of data in LevelDB for blocks? And why data of blocks are not sent like block_data + block_num so the receiver can save the file with the got number and we don't need a database?
|
|
|
Thank you a lot! You've really helped me 
|
|
|
It is possible that there could be a txid collision (and in fact they have occurred in the past due to a specific oversight in the protocol), but normally they are extremely unlikely because like private keys, they are effectively 256-bit random numbers. However, collisions are avoided by rejecting new txids duplicating txids of any transactions with unspent outputs (see BIP-30). Are these transactions actually rejected and deleted from mempool or these transactions are skipped and still waiting for the moment when the previous transaction with the same txid will be deleted from LevelDB? I'm actually asking this question cause I've seen somewhere that when the UTXO is spent, it would be deleted from DB, am I right about it?
|
|
|
But what happens to the transaction if the same txid already exists? Cause it can’t be 100% impossible of creating transaction with the unique txid, can it? This transaction will be be waiting in the mempool for the moment when existing txid will be deleted from the LevelDB?
|
|
|
I understand this, but I'm talking about absolutely different transaction with the same txid because it's possible due to collisions cause it's not possible that every transaction will have the absolutely unique txid. I mean, that I have created a new tx with spending my own UTXO and the tx got the txid of a tx that is owned by a man who has lost his password, but one his UTXO if from the tx with the same txid. So, my transaction will not be ever added to the blockchain?
|
|
|
I know, that LevelDB stores information about all UTXOs. The pairs in there are key + value, where keys is txid + number of vout. But if one man has some UTXOs and has lost his password, then these UTXOs will be in the DB forever? If i have created a new tx with the same txid that this man had, then my transaction won't be added to the blockchain ever?
|
|
|
Can one explain please what does " 'C'+ 32-byte transaction hash + output index length + output index" mean? In this answer https://bitcoin.stackexchange.com/questions/28168/what-are-the-keys-used-in-the-blockchain-leveldb-ie-what-are-the-keyvalue-pair/29418#29418Firstly i decided, that hex C is stored in DB, but then I saw in there other letters, like T, or R, which are not hex numbers. So does that mean, that it's real letters, which are decoded in bytes via utf-8 for example? And also it's not clear what output index length means. It means that if real vout index is 16 for example, then in bytes it's compared to '10' which has length of 2, and this output index length == '2' in bytes? And for vout 4096 for example hex representation is '1000', which has length of 4 bytes. If so, then it's a bit strange. Is there any limit for the number of vouts per transaction, or I can send coins for a million users for example?
|
|
|
What do these letters at the beginning mean? 'c' + smth it means that a key consists of the letter c at the begging + smth?
|
|
|
But what kind of data about UTXO is stored in there? I've heard that it's like txid -> data about all UTXOs, but what kind of data? Saw that there are some bits that indicates if a vout is spent or not. And when all bits show that all vouts are spent, this pair txid -> vouts will be deleted
|
|
|
I know that LevelDB stores information about current UTXO in the whole network. But what data exactly in this database, that allows nodes create transactions? For example in a block the fields are: previous hash, timestamp, merkle root, nonce, difficulty and etc. But what are the fields in LevelDB?
|
|
|
Yes, I know this, but I need mathematical proof
|
|
|
Everywhere it's said that 6 blocks is enough but why? I'm not talking about the probability that is in Bitcoin whitepaper, but I've heard that it was proven mathematically that it's impossible to attack the chain if the difference is 6 blocks and more. Maybe someone knows where I can find this thing?
|
|
|
Yes, miners need to know about unconfirmed transactions, but they do so via nodes. Usually what happens is that mining pools run several nodes, and then create candidate blocks which are sent to individual miners. The individual miners themselves don't need to keep their own mempool or run their own node, because the mining pool gathers the necessary data for them via its nodes.
In here you’re taking about miners which are a part of a mining pool? Cause if so, then okey, I didn’t actually look through technical part of these mining pools. But what about a node who launched his own Bitcoin Core client? Does he have a mempool? Cause as far as I know — yes, he does. But maybe I’m mistaken
|
|
|
It's not miners which are holding the tx in their mempool, it's any node connected to the network.
Why did you say that not miners hold these transactions? Anyone in the network, who have to mine, have to hold it, if I'm not mistaken. Cause a miner just takes some transactions from a file and puts it in a new block. Nodes can be far away from each other and it can take some time to get new transactions from another node. (Longer, than just to read them from a file) And in here https://www.politico.com/newsletters/digital-future-daily/2022/06/21/inside-the-mempool-where-crypto-risks-hide-00041132 it's said: "“Mem” is short for memory, and the mempool is where each network node keeps a list of spending crypto transactions." If I'm mistaken, correct me please
|
|
|
According to BIP-30 it's said, that new transaction with the same txid of unspent one won't replace that one, that's still unspent. But what is happening to this new tx that must be inculded to the chain? Miners are holding this new one in the mempool and this tx is waiting for the moment when the existing one with the same txid will be removed from LevelDB that is in chainstate folder? (I'm talking not of doublespending of the same transaction but when it's two different transactions and they have the same txid)
|
|
|
When a new node connects to the network, other nodes start to share new transactions with this new node they got. But do they share their mempool, when a node disconnects from the network for some time for example? I think that the mempool size is too large and it would be difficult to share their mempool state, but maybe I'm wrong...
|
|
|
Oh, no. Not after each transaction, ofc. The question was about updating it every block and deleting spent transactions with all spent utxos after each new block. Does it work that way or it deletes spent transactions every 5 blocks for example
|
|
|
I know that LevelDB stores information about UTXOs in the way like txid->utxos. And when all utxos are spent in this transaction, it is removed from DB. But is it an instant action after new block was created, where the last unspent vout becomes spent? I mean when the last unspent vout is in DB for txid X and it is spent in the block N, it will be removed from DB after block N instantly? And also I can’t understand the thing about the structure of value in LevelDB which is in chainstate/ folder I’ve seen smth that it stores data like hight, number of vout, is this vout spent or not, and smth else but I don’t remember what. If I’m not right, correct me please.
|
|
|
But what kind of data is stored there? Vins, vouts or both?
|
|
|
I remember that I somewhere saw an article that not only files of blocks are stored, but also the information about vouts in these blocks. I mean file blk_n.dat and a file for blk_n.dat that stores all vouts for this block. It's used for situations when you got bigger chain, but your last block isn't in it and you have to restore your leveldb whic stores vouts with the help of this file. And I can't find any information for this topic and that article I said about before
|
|
|
|