Search content
Sort by
Showing 16 of 16 results by Dr.Z
Hello Oschoir,
There are a lot of different questions you are asking here so we will try to answer most of them. When a miner forms a block he choses transactions based on several factors such as the transaction fee, age of the coin and size of the transaction. All transactions and other related information stored in a block creates a unique blockheader related to these factors. However, every second there are new transactions being added to the mempool. This means the transactions included in the block are also constantly changing leading to a different blockheader as well. On top of this each miner makes their own unique block and miners can choose to add their own transactions.
It is important to understand that this does not impact the chance of mining a block since you are trying to calculate the hash of the blockheader. Whether the nonce changes or the included transactions change they have an equal chance of finding the hash below a certain value.
With kind regards,
The Anycoin Direct team
There are a lot of different questions you are asking here so we will try to answer most of them. When a miner forms a block he choses transactions based on several factors such as the transaction fee, age of the coin and size of the transaction. All transactions and other related information stored in a block creates a unique blockheader related to these factors. However, every second there are new transactions being added to the mempool. This means the transactions included in the block are also constantly changing leading to a different blockheader as well. On top of this each miner makes their own unique block and miners can choose to add their own transactions.
It is important to understand that this does not impact the chance of mining a block since you are trying to calculate the hash of the blockheader. Whether the nonce changes or the included transactions change they have an equal chance of finding the hash below a certain value.
With kind regards,
The Anycoin Direct team
If the transactions included in the block change during the mining process, when new transaction added in, will the nonce start over from 0, or just keep plus 1.
I can not find the location where to put the wallet.dat
In BitcoinGold Core, look at the following menu: "Help -> Debug Window -> Information"There is an entry labelled "Datadir":
https://i.imgur.com/blMrpD8.png
That is the location of your BitcoinGold Core data directory and should contain the blocks folder and wallet.dat etc.
Got it, Thank you.
How comes Blockchain.info generates private keys using block hashes or tx id instead of random numbers. Who had the privilege to change the key generation methods?
The do not. Stop spreading FUD. Don't be an idiot, read the thread.What I am saying who put those code there and why Blockchain.info did not aware that the key generation program had been modified.
Your words make zero sense, stop replying me. Thank you.
Nearly there. The orphan pools serves primarily those without a parent transaction that can be found in their UTXO. For those transactions, they are stored in a orphan pool with a max transaction size of only 100, if I'm not wrong.
You can't do much with it. Even if you want to spam up to their limits, its fruitless and it won't be relayed to other nodes.
Oooh wait, I found it: https://github.com/bitcoin/bitcoin/blob/3c098a8aa0780009c11b66b1a5d488a928629ebf/src/net_processing.h#L13.
You can't do much with it. Even if you want to spam up to their limits, its fruitless and it won't be relayed to other nodes.
Oooh wait, I found it: https://github.com/bitcoin/bitcoin/blob/3c098a8aa0780009c11b66b1a5d488a928629ebf/src/net_processing.h#L13.
Thank you. What happens when it reaches the limit. Drop existing transactions or refuse new coming transactions.
I think although the spams won't affect other transactions, it will somehow interrupt the service of orphan pool.
If you did read the thread, then you must be smoking something good
Blockchain.info checked their code repository, these addresses are not generated from them.
It is well explained in the thread why it was not a hacked wallet. Because if someone hacked into the wallet, he was no need to import a "blockhash or txhash based address", just hardcode one will be good.
How comes Blockchain.info generates private keys using block hashes or tx id instead of random numbers. Who had the privilege to change the key generation methods?
The do not. Stop spreading FUD. Don't be an idiot, read the thread.What I am saying who put those code there and why Blockchain.info did not aware that the key generation program had been modified.
When a node receives a transaction, it first verifies the signature is valid or not. If the transactions pass the validation with a correct signature, they are added to the transaction pool. If a transactions inputs refer to a transaction that is not yet known, the orphan transaction will be stored temporarily in the orphan pool.
DOS attack: Just simply fake some transactions with randomly generated key pairs, they will pass the validation and fill up the orphan pool(since the nodes cant find the input address).
Am I wrong with the transaction validation mechanism on the node or do I miss other technical details? Because this sounds trivial and no one thought about this?
DOS attack: Just simply fake some transactions with randomly generated key pairs, they will pass the validation and fill up the orphan pool(since the nodes cant find the input address).
Am I wrong with the transaction validation mechanism on the node or do I miss other technical details? Because this sounds trivial and no one thought about this?
How comes Blockchain.info generates private keys using block hashes or tx id instead of random numbers. Who had the privilege to change the key generation methods?
Definitely highly probable. Which client are you using as a wallet? If you are using a desktop wallet, you would most likely be able to get the raw transaction and broadcast it yourself.
Those transactions are payouts I got from a cloud mining service. Maybe they create transactions using Chain.so and pay low fees, the transactions were in Chain.so'queue and not even in the mempool(and maybe Chain.so's explorer shows transactions in the queue as well). And after days it finally got broadcasted into the network.[quote ]
Chain.so's mempool is not reflective of every mempool in the network. This means that even if only chain.so has the transaction on their block explorer, it doesn't mean that the miners doesn't have it on their mempool.
[/quote]
I think if most of the block explores not showing it, then miners dont have it on their mempool.?
Chain.so's mempool is not reflective of every mempool in the network. This means that even if only chain.so has the transaction on their block explorer, it doesn't mean that the miners doesn't have it on their mempool.
[/quote]
I think if most of the block explores not showing it, then miners dont have it on their mempool.?
Chain.so is not a miner. If your transaction is not in anyone else's mempool (and determining this is impossible to do), then your transaction will not be mined. You can remedy that by rebroadcasting the transaction to the network so that it does enter all nodes' mempools, but it may drop out of them again later, so you would have to rebroadcast again later.
Thank you. What happened to me was, the transaction(5225cff0ac48fa59ff85553cb515e21560abbcdd0711f1179f8cd189a792d121) had been on Chain.so for 48hours while no other block explorers were showing it. However, a day later, that transaction finally went through. Any thoughts on what was happened?Now I have another one in the same situation. No one is showing it except Chain.so
0a031d2e72904b7d90cc6de55f913b489be2613f9b5acd43a5cd5158d1cf7c76
Address = RIPEMD160(SHA256(Public Key))
The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: K = k * G where k is the private key, G is a constant point called the generator point and K is the resulting public key.
The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: K = k * G where k is the private key, G is a constant point called the generator point and K is the resulting public key.
My question is, for those unconfirmed transactions shown in the block explorers, are they in the explorer's own mempool, or they can also be transactions from other nodes' mempool?
Would have to be the transaction from the block explorer's own mempool.If one transaction has been on Chain.so for 24 hours but not on other explorers, does it means that this transaction is created by Chain.so, and Chain.so has not broadcast this transaction into the network?
No. Each nodes have their own set of rules to accept transactions. They can select which set of rules they want to follow or which they don't. For most nodes, they differ in the minimum relay fee. Which is the fee/kb requirement to accept transactions into the pool. Either the transaction's fees are too low or the transaction isn't well propagated.
I know the fee is too low. But Chain.so shows the transaction, does this mean that this transaction is in Chain.so's mempool?
Also, do all nodes have a mempool? or just miners?
If the fee is too low that other nodes won't accept this transaction, only Chain.so has it in the mempool, does it mean that I have to wait until Chain.so successfully mines a block?
Thank you!
I know each node has its own mempool for transactions to be mined. My question is, for those unconfirmed transactions shown in the block explorers, are they in the explorer's own mempool, or they can also be transactions from other nodes' mempool?
If one transaction has been on Chain.so for 24 hours but not on other explorers, does it means that this transaction is created by Chain.so, and Chain.so has not broadcast this transaction into the network?
If one transaction has been on Chain.so for 24 hours but not on other explorers, does it means that this transaction is created by Chain.so, and Chain.so has not broadcast this transaction into the network?