But when it is all running, were do i see the node rewards ?
What do you mean by rewards? Full nodes are not rewarded for running. Only miners who find blocks are rewarded. |
|
|
|
So better downgrade to 0.18 ?
It's a GUI bug. It doesn't really affect the functionality of the client as a full node. You can still get the mempool information albeit you'll have to input a few commands. Other than that, it functions the same as any other node. |
|
|
|
this is how my screen looks like. So i get incoming and outcoming peers. But i have 00000 numbers of transactions  And why my image doesn't show up ? You're a newbie so the images won't show up. Its normal as per the forum rules. As for the mempool stats not showing up, it is a known bug [1] for Bitcoin Core 0.19.0.1. It's a GUI issue and should be fixed within the next release. [1] https://github.com/bitcoin/bitcoin/issues/17576 |
|
|
|
|
Did you send to the correct address? If the address is in your blockchain wallet, the problem would be with the wallet itself. And thus you'll have to contact Blockchain's support instead.
|
|
|
|
Transaction Inputs are interesting. Is there an easy way to view this via bitcoin-cli without having to loop and make many calls? Or would it be best practice to just loop through the vins and check if they're confirmed?
You don't have to make many calls to check if your UTXOs are confirmed. You can just use listunspent to check all your confirmed UTXOs at once. If you'd like, you can add arguments to filter out the transactions with less than or more than X confirmations. |
|
|
|
I apologize for the concern, but I am concerned about one question, how vulnerable the transaction can be, until the first confirmation, since I used to consider the blockchain bitcoin flawless at all levels of its use. Is it possible to cancel a transaction before the first confirmation in the bitcoin blockchain? I understand that many blockchains and different coins have flaws and especially the facts of vulnerability, but there is nowhere to get information about the real possibilities of loss.
It's somewhat alright to accept zero-conf transactions if it ticks a few criteria. Generally, with opt-in RBF flag in the transaction, it is a very high risk transaction since the ease of double spending that transaction is extremely high; anyone can easily replace it with another transaction to an alternative address. In a brick-and-mortar store where the customer would want a fast transaction settlement, it would be more advisable to accept zero-conf transaction following a risk assessment. Once it has one confirmation at least, it is generally safe to accept transaction of a decent value. |
|
|
|
Doesn't running multiple nodes, by miners, increase inefficiency in broadcasting? Plus do miners run nodes? I believe they only connect to mining-pools' nodes, which are more incentivized to run a well connected node to broadcast their block as fast as possible.
Running multiple nodes does ensure that the pool is less susceptible to sybil attack. I'm sure miners run some sort of modified client to ensure that their pools are the most efficient possible; the reference client is too resource heavy. Since the SPV mining fork back in 2015, its widely established that several pools connect to each other's stratum mining server directly. They would be listening directly to their stratum mining channel so that they would know if there's a new block solved ASAP. I don't think selfish mining by the bigger pools would be possible since they would have to send the information of the new block to their miner when it's solved immediately. |
|
|
|
Allowing to input addresses through the smartwatch by typing them would be a bad, bad idea.
The best thing that could happen is eventually a wallet that lets you send funds to a preset list of addresses. But then again, security becomes a concern.
Most smart watch which allows payment right now uses NFC to transfer data. Since the Bitcoin URI is rather small, it wouldn't be too much of an issue to transfer data across to the watch. Security is still somewhat alright since you can set smartwatches to require a PIN to authenticate. The screen should be big enough to be able to display at least majority of the address. |
|
|
|
Exactly. The more confirmations a transaction has, the lesser the probability of "rollbacks" will be. Since Bitcoin is the most secure Blockchain network today, a single confirmation might be all you need to feel safe without worrying about getting your funds "double-spent". The real deal will be with smaller blockchain networks which are easily prone to a 51% attack. Maybe the Ethereum developer team have been concerned about transaction finality because of security issues within the chain? After all, Ethereum is not as secure as Bitcoin is in terms of hashrate.
The smaller coins have encountered 51% attack before and it was profitable for them due to the relatively lower cost of the attack as compared to the amount double spent. It is important to consider the number of confirmations required to the total value of the transaction. For the lower value transaction, it's possible for the transaction to be instantaneous if the merchant is willing to take the risk for the sake of a faster and smoother checkout. For exchange, they usually require a much higher number of confirmations. Up till 5 confirmations, the risk of double spending with less than 51% of the network is still possible (albeit still rather expensive and requires some luck). |
|
|
|
Both, my wallet and the blockchain states fee and does not diversify between relay fee and transaction fee.
If the fee is split in relay and transaction fee, who receives the relay fee and technically how and who receives the transaction fee and technically how?
The reference client take the transaction fee as a metric to see what is the minimum transaction fee for the client to include the transaction into their mempool. They term that as a minimum 'relay' fee. The node does not take a cut from the transaction fee. The nodes say for how much they are willing to relay the transaction, but do not receive the relay fee?
If yes, who receives the relay fee and technically how?
Relay fee = transaction fee. Its just that the reference client choose to call it a 'relay' fee. The miner will still take the full transaction fee. |
|
|
|
Miners usually pick the transactions with higher fee. But there is a factor called priority based on which the transactions are mined. The formula is as follows:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Miner usually don't actually look at the priority nowadays. There is no reason for them to look at the priority when the mempool is always filled and that fees are the determining factor as to which transaction gets included in the block. In addition, the priority system is irrelevant with the mempool being filled all the time and has already been deprecated.
For OP, there is a difference between relay fee and transaction fee. For the relay fee, it is termed as such for the nodes as a parameter. This is the minimum fee for which the nodes are willing to relay the transaction. Nodes do not take a cut from this. For transaction fees, the miners take the entire transaction fee. |
|
|
|
One volunteer a day keeps the 51% attack away right?
It doesn't. 51% has absolutely nothing to do with helping to resist 51% attacks. Since the blocks generated during 51% attack, the ease of executing an attack with 10 nodes is the same as 10,000. Nodes would just accept the rogue blocks since they are still within the protocol rules.
In terms of security, it does help to improve the network's security by potentially make sybil attack harder. For a sybil attack to be executed with a large number or nodes, the attacker needs a lot more resources and nodes to have a chance at executing one. |
|
|
|
|
The miners are actually pretty incentivised to fill blocks. Most of the empty blocks that you see are generated in when the miner starts removing transaction that were already included in the block from their mempool. This creates a time delay with the verification of the block itself and other overheads. To better utilise the time gap, miners usually just mine an empty block so they do not have to care about the transactions that has to be included in the block.
The propagation of the block isn't that big of a problem anymore. The time delay for a smaller block compared to the bigger block is much lower right now.
|
|
|
|
That seems impossible. because the transaction is just one of the completed blocks and it is only stored in history but does not show any information to locate it. not even our wallets are made to identify their owners. We can only know how many wallets are created in this country and can only sum it up as facts. That's why governments often don't like letting their citizens use crypto to pay for services, which will lead to mass money laundering that can't be controlled.
A transaction can be easily traced back to its origin with the inputs and the outputs of each individual transaction clearly discernible from each other. Linking an address to a person is not hard either; the pseudonymous property of Bitcoin allows the addresses to be clearly identified and for them to be linked to an identity. It's not possible to determine how many wallets/addresses are generated either.
There seems to be a massive confusion about the difference between pseudonymous and anonymous. Bitcoin is pseudonymous, NOT anonymous. |
|
|
|
Minerjones bud. He runs mantis distribution and has reshipped a shit ton of things for me
Contacted him prior to this post. He said he can only ship them to PO boxes and that won't work for me. You can use Shipito (Bitcoin accepted). Yes, Nike won't ship to their warehouse, but you can use the ' assisted purchase' instead. I've tried it before and it works just fine. I can't use Nike's sales with their assisted purchase which is not ideal. Their shipping fee is steeper too. |
|
|
|
Tried:
14:39:37

importwallet "C:\Users\Ingvar\Desktop\WalletsDesktop\DumpedWallets\UsersAdministratorDesktopWalletsDesktopDBitcoinBUwallet.dat"
Resonse:
Importing wallets is disabled when blocks are pruned (code -4)
Solution??
It's a known limitation of pruned wallets. When the wallets are pruned, the client automatically deletes the blocks as it synchronizes. When a new wallet file is imported, the client is unable to determine the full transaction history of that specific wallet due to the deleted block files. The only solution is to resynchronize the entire blockchain with your new wallet unfortunately. |
|
|
|
|
I'm looking for a cheap laptop just for casual usage. The specifications of the laptop doesn't matter that much. PM me with your specs and offer. I'm located in Asia and I'll discuss the shipping fees too.
|
|
|
|
|
No. The main problem is not about their lack of computational power. Miners uses ASIC which are designed to only mine Bitcoin (ie. Only do double hashing of block headers to produce SHA256 hashes). This means that those ASICs can never ever be used to generate addresses.
That aside, even if you convert the hashing power directly to the number of keys per second, you would still need a astoundingly huge amount of time before you hit the jackpot. The probability is so small, it might be more worthwhile to just buy a huge bunch of lottery tickets and its more likely for you to hit every single one of them than to be able to bruteforce addresses that are securely generated.
|
|
|
|
|
When you use the decoderawtransaction command, was your raw transaction signed? Signed raw transaction has a higher size than the unsigned ones due to the inclusion of the signature.
|
|
|
|
Well.. this is another important issue that has been ignored by the core team for quite a long time. A huge number of people believe that in order to purchase Bitcoin, you need to buy one full BTC. A lot of awareness campaigns were taken out, with limited outcome. I had proposed to redenominate the BTC some years back. Each of the existing (old) Bitcoins should be replaced with 1,000 new coins. The total circulating supply will increase to 21 billion from 21 million. A lot of people argued that Satoshi is already there and we don't need redenomication. But the issue is that Satoshi is too small to be used as an unit. As of now the price of one Satoshi is just $0.000094 and it is very difficult to use that unit.
No offense intended but I don't think it is a very bright idea to increase the coins by tenfold. Its a more viable option to just divide the coins smaller than satoshi. You don't have to use satoshi as an unit either. Just use mBTC as a more suitable denomination. There is no issue with the denomination until a satoshi becomes equivalent to a dollar. I really don't see the point behind increasing the supply instead of increasing the denomination. |
|
|
|
|
Show Posts
