Anyway, if you downloaded a modified blockchain, there is no chance to lost your money with it, because if the transaction bradcast still works, the other nodes will verify if the transaction is valid and if you really have the sent amount, the worst case in this case is if the fake blockchain doesnt have your updated balance. (there is other problems too, but i think this is the biggest).
If you somehow download a malicious blockchain that is modified, your blockchain data will be different from others. You could potentially be tricked to seeing transactions that are otherwise invalid (with non existent) inputs. This is the potentially a serious problem when you're downloading a pre-validated blockchain from others. If your client validates everything, then it isn't a problem. IIRC, there's a command that rebuilds the chain state only and I don't remember having to validate all the blocks again. I could be wrong, of course. |
|
|
|
|
Bitcoin Core actually doesn't need the blocks once it has validated everything and created the chainstate. That is if you're using the client in a manner which is pretty minimal.
Pruning could reduce your blockchain size to 550mb. However, you cannot import addresses or search for transactions unrelated to your addresses in the wallet. You will still have to download every block.
|
|
|
|
Without the chainstate, it doesn't matter because your node will validate the blocks anyways and fetch whatever it doesn't have.
The argument only matters if you are copying over the chainstate too since then you have to trust that the chainstate you are copying has not been modified. Usually you can trust yourself and your computer so it really isn't an issue. It's only an issue if you have malware or someone has maliciously accessed your computer.
Doesn't the client just rebuild using the blockchain index only? Blockchain index contains information about the blocks and they are verified and inserted there if I'm not wrong. Does the client actually verify the validity of all the blocks again when remaking the chainstate? |
|
|
|
I wanted to check if a confirmed tx had the flag set or not.
Wouldn't it make more sense to show the actual flag?
IMO, no. If a confirmed transaction can't be replaced, it wouldn't matter if it had the flag. Doing so would just cause more confusion. You can get the raw transaction and check its sequence for that. People don't usually need to check it once its confirmed. |
|
|
|
|
The transaction still has a replacable flag, confirmed or not. However, the client ignores that once its confirmed; you can't use RBF on a confirmed transaction.
|
|
|
|
|
You're pretty safe with it. If you've downloaded it, then you have probably verified it yourself.
The main thing with this is that, AFAIK, the client only verifies the blocks 6 block deep and not all. The problem with this is that all of the other blocks are to be assumed to be valid. Unless you delete the block index or set your client to validate everything, you are trusting that everything is correct.
Edit: If you don't copy the chainstate and index, then your client would be verifying everything again so there wouldn't be any risks at all.
Sorry for the confusion, I was under the impression that Core still validates all the blocks at start up.
|
|
|
|
Is it just because there is less people using Bitcoin as of now ? Or was it because of a low fee transaction spam that took place back then ?
Or on the top of the hype, too much people tried to use it to transact ?
Quite possibly the spam attack. The change in the transaction volume was too drastic for me to consider it not to be partially due to someone spamming it up. Of course, it was pretty popular then.[1] The "attackers" can slowly raise the fee to drive it up, up to 1000sat+/byte as we saw. Miners could coordinate efforts to conduct this attack since they recover the fees.
With all the BTC/BCH drama, I don't know what Ver and his friends are up to in order to drag people on their coin.
Today, 40sat/byte will include your transaction in the next block.
What are your thoughts on this matter ? What explains the fees dynamics ?
I definitely have my reservations that major miners didn't have this idea. It's a pretty feasible method if they do control majority of the hashrate and hold large farms. They can easily create the impression that high fees are needed without actually losing much money. However, with the generally lower volumes, its effectiveness is much lower. [1] https://jochen-hoenicke.de/queue/#0,1y |
|
|
|
|
The end-user. Bitcoin works in a way such that the responsibility of making decisions and rules are shifted to the user only. By consensus, no one can force a rule change without a majority support from the community. Everyone is free to run forks of Bitcoin but they can't have anyone to run their client and follow their set of rules.
Arguably, mining has really destroyed the decentralised aspect of Bitcoin. With the monopolistic mining industry, it's pretty hard to say that the power lies solely with the user.
|
|
|
|
micro loan pls! any coin(bitcoin, altcoin)! any sum! end any TOKEN
20% back
PS - no have collateral(only my acc btctalk)
Good job. You've just destroyed your account. very need money!!!
I live in war, in donbass
sorry bad english
No one would lend you anything. Lock the topic and don't think about scamming any of us. |
|
|
|
can someoene explain why the fuck everyone cares about merit? everyone can trade/share his merit. who the fuck are you? you don't have any rights to tell them. everyone can sell his merits. you are fucking poor guy. now go fuck yourself and drink your milk. okay?
Lmao. Butthurt much? What's the point of merit system if everyone can trade them? It's meant to be earned and not given. Yeah, we certainly don't have the rights to tell you not to do it. But you don't have the rights for us to not give you a negative trust either. I doubt anyone else could be poorer than those that have to resort selling their merits. And contrary to your beliefs, most of us are actually not as poor as you think. |
|
|
|
Will Electrum compensate me for my loss? So many Electrum users have been compromised. My warning was ignored in the beginning.
No. It's not possible for Electrum to compensate everyone who lost their money. It's simply impossible for them to verify who was the one who has lost their money due to a bug in Electrum. Granted that there was a serious vulnerability in Electrum, I don't think anyone was actually affected by it. The most likely scenario is that your computer was infected and compromised. |
|
|
|
|
Segwit didn't eliminate ASICBoost completely. There are two kinds of ASICBoost; covert(can't be detected) or overt(can be detected easily).
SHA256 splits the 80byte block header into 2 chunks (of 512bits each) before hashing them. The merkle root overlaps from the 1st chunk to the 2nd. With ASICBoost, the last 4 bytes of the merkle root in the 2nd chunk is to be kept the same while the 1st chunk is varied. This allows for an improved efficiency since they don't have to calculate the second chunk over and over again. The merkle root can be changed by shuffling the order of transactions.
However, with Segwit, there is a witness commitment inside the coinbase transaction. With this, the covert attack with transaction reordering can't work since the witness commitment has to match the ordering of the transactions in the block.
Overt ASICBoost will still work since the versionBit is in the 1st chunk and the 2nd chunk wouldn't need to be recalculated. Everyone can see the change in the VersionBit so it's easy to tell.
|
|
|
|
Great point. But, just for the sake of argument, what's the possibility of this forum or Github being hacked?
Very very high. This forum was hacked many many times, through bugs or exploit or just good ol' social engineering on their host. The last serious incident was with the compromise of Bitcointalk's host and the user data were stolen. Github was also compromised IIRC. If someone have enough resources, compromising a website is relatively easy. If you don't verify your downloads through the PGP key, then you cannot assume ThomasV has validated it or it is authentic. |
|
|
|
The way I understand it's just a way to outsource the generation of your vanity addresses, essentially you will in the end get the pair of private and public keys while not exposing the private key to those who helped you in generating it
You will be generating a half of the private and public key. You will then be sending your part of the public key. They will use your part of public key to combine with their part of public key to form addresses. When they find the desired sequence when combining your public key and their public key, they will send you their part private key. Combining their part private key and your part private key will generate an address that corresponds to the desired address. It's called split-key generation. They cannot spend anything without your part private key. |
|
|
|
Fully agree with you, i also owner of Ledger Nano S and it's nightmare to manage it sometimes. I also don't understand why the price of it is so high, when it just a simple token similar to RSA tokens.
Whilst I don't find hardware wallets practical or as secure as I'd like, it's certainly justified for the price of hardware wallets to be slightly higher than expected. Hardware wallets doesn't employ directly the technologies that are matured. The whole device is designed by them and its not just a "token". It does store the private key and sign the transactions on it. RSA tokens literally just generates numbers and that's pretty cheap to make. |
|
|
|
|
The key pool is generated from your master key. In the past, the non-HD client maintain 100 private keys in the wallet file for the user to use, by default. This allows the user to use that file to backup the wallet file and restore the addresses for 100 transactions; Bitcoin uses a new address for every transaction.
I'm not sure as to why the keypool is still being used. The addresses in it is being generated with the master key. The 2000 keys that is generated is the same as the 2000 key in the keypool. They are used when your wallet needs a new address. The number is maintained whenever your wallet is unlocked.
|
|
|
|
|
Accounts are blocked if they are inactive for an extended period of time and if they were on the forum at the time of the hack. Resetting your password via the email method will not block your account but resetting it via secret questions will.
|
|
|
|
|
Bitcointalk username: ranochigo
Rank: Legendary
Current post count: 5490
Bitcoin address: 1Yzig3e8vx79XyYMjJShk4yBPp1YcvPbQ
|
|
|
|
Thank you.
So, if we assume that everything is OK with the block... then at the same time we have two blocks with the same "parent" (previous block). And possible those two branches could go like that for a couple of more blocks (the probability of that decreases exponentially). So until this situation is resolved, everything is OK... some nodes are using one branch, and some nodes are using other branch... And when the "problem" gets resolved, all of the transactions that were in the loosing chain get thrown back into the "unconfirmed" pool... where some other miner can pick them and try to include them in their block...
Yes. Until the the problem is resolved the miner could "spend" the fee he received for including the transaction in his block. After that the block chain decides to eliminate his block (because it was in the loosing team). What happens now?
He is not receiving the reward for his block because it was discarded?
The transactions that were included in his block need to be resent (by him or some other miner).
What happens with the fee he already spent (the one he received for including the transactions in the first place)?
He can't. The maturity for the block reward is 100 blocks. The miner cannot spend any UTXO (unspent transaction output) created by the coinbase transaction until the chain is has at least 100 other blocks mined on top of that. This should counter any possible block reorgs unless it goes to 101+ and that is unlikely. Also, I don't see why isn't it possible that two miners are trying to include the same transaction in their blocks? transaction is in the unconfirmed pool, both want to add it in their block (it is needed because the transactions in the block also have impact on calculating/mining the block), and possible both succeed at the same time... this of-course seem wrong so again, I am missing some info or got something mixed up  It is possible and probably is happening. If they mine a block at the same time, they could include the same transaction that is in their respective mempool since its not in a block already. |
|
|
|
|
Show Posts
