|
The reason why the QR codes doesn't work across different wallet is because Electrum encodes the PSBTs in Base34. If you need to sign them, then encode them back into the original format.
I don't really recommend old phones as cold storage because it is quite well known that most wallet developers don't really care about mobile wallets. Some of them are littered with bugs and vulnerabilities. I'd very much rather just get a dedicated device (ie. RPi or an old laptop) if you want an air-gapped non-HW wallet. IIRC, I was able to extract the MPK out of a rooted phone quite sometime ago. Not sure if it has been patched yet.
|
|
|
|
|
If you don't include that in your businesses' TOS, then you're just plain dumb. The terms of service of almost any service out there requires the user to agree to this clause so that in the event that something happens, they have the rights to do something legally. Having that broad statement is a necessity if you don't want to face an expensive lawsuit (ie. having the user using their account in a way that harms your business but the narrow TOS doesn't give you the rights to stop it).
|
|
|
|
I suppose it depends on whether the attacker controls 51% of the hashrate or not. If they do, and are guaranteed to eventually overcome the main chain, then they are guaranteed all those block rewards. If they control say 30-40%, and are just "trying their luck" so to speak, then there is the risk that they manage to mine several blocks but not enough to overcome the main chain, and then they lose all those rewards.
I think then selfish mining also plays a part. In certain scenarios, intentionally delaying the propagation of a block would make it more profitable than to broadcast it immediately. There are specific conditions for it to happen though, but generally the trend makes it kind of feasible. I don't think most exchanges or services actually enforce 6 confirmations, for which the threshold hashrate is 51%. Else, you can get away with a lot less than 51%. |
|
|
|
|
What issues do you have to connect to your peers if only your port 80 is open? You should still be able to establish outgoing connections unless something is actively blocking connections to your peers.
If you want peers to connect to you, then you can specify a non-standard port without any webservers.
|
|
|
|
Thanks ranochigo, yes on both.
If you've got the transactions, then does the balance tally with the transactions that are displayed? Before you upgraded, was the wallet fully synchronized to the current date and time? If it was, then you can try to use your backup instead, though I'm more inclined to think that the balance that you saw might've been outdated. |
|
|
|
|
Are there any transactions in the transaction tab? Is your wallet fully synchronized?
|
|
|
|
How do you store wallet.dat files in a safe way in all possible scenarios? Including:
1) Having all of your physical copies destroyed by a flood/fire
2) Having your physical copies stolen by a totalitarian government (yours become one, or you get stopped in an airport etc)
3) The people you trusted to hold backups also get theirs confiscated, they get bribed and betray you, etc
4) You get put to jail by totalitarian government and come out 5 years later (online backups in free sites may get removed due lack of use/host goes bankrupt, and paid ones require you to pay a membership to maintain the files)
Im trying to come up with an alternative, without having to use Electrum. This is the only way I've thought it could be done. In extreme scenarios the only way you could have any hopes in recovering your funds is if you managed to have a plan B hosted in your mind and practicing daily to not forget the seed.
If there is a possibility of a total and irrecoverable loss of your backups, then you probably didn't ensure that there is sufficient redundancy. You should store them at different geographical locations and there are numerous ways of protecting them against everyday elements. That is not a good excuse to argue that digital backups are not suitable. If you were to live in a totalitarian government, then you probably would have better things to worry about. There are ways to hide your data via stenography anyways.
Of course, there are merits to both mnemonics and a wallet file. The answer to your question is that, you can. I would rather use a known standard, BIP38 to do so. However, if you plan on memorizing your seed, then I would urge you to think twice. You are far more likely to straight up forget your seed, either by human nature or through amnesia, alzheimer's disease, etc. |
|
|
|
A quantum computer would still need to brute force all the possible hashes until it finds the right block. It's just that those individual hashing calculations could happen much faster -- or rather, within many fewer steps -- than with a classical CPU. Bitcoin's difficulty adjustment algorithm is therefore not affected by it, ie. at worst we'd face shorter blocktimes followed by steeper difficulty increases, similar to when the first ASICs went online.
It is unfair to compare classical computers to quantum computers because they are fundamentally different. Reason why Quantum Computers are better at breaking ECDSA or other public-key cryptography is due to Shor's algorithm which can provide an exponential speedup, as compared to the quadratic speed up of classical computers. The qubits required to actually run Grover's with a pre-image would be fairly high, presumably (3+ times) far higher than Shor's just to outpace ASICs alone. That would mean that when QCs actually outpace the ASICs that we have today, then QC would be so mature that ECDSA would've been cracked more than a few decades ago. I remember reading another research paper on this issue and the conclusion was that this isn't really a problem at all. [1] [1] https://arxiv.org/pdf/1710.10377.pdf |
|
|
|
Do we ever expect for QC to become a threat for mining though? Keep in mind that when talking about operations where QC is faster than classical computing the comparison is usually drawn to CPUs. ASICs are a few orders of magnitudes faster than CPUs so it will be pretty hard for QC to catch up. Once QC catches up to ASIC mining it's more likely that QC will simply be used for mining as well.
No. QC remains too expensive for most tasks and the task for which it excels at requires specific algorithm, Grover's and Shor's for example. You can possibly do the operations faster than classical computers, but it would be too difficulty for it to match ASIC in terms of speed and efficiency. I'm not really sure why pre-image would necessarily benefit them in the context of mining. You still need a very specific inputs for the block to be valid; finding a pre-image to a block hash doesn't do anything unless it is also a valid block header. |
|
|
|
Got it, they get isolated in P2P network because honest guys won't talk to them. Maybe there are papers in research level, but it would be interesting to visually see them as a network like nodes and minders are points and they are connected by an edge if they talk each other. I think dishonest guy would be disconnected. There is https://bitnodes.io/ which has some info, but I don't think it has data about if they are connected like they are talking. Are there such data so one can analyze? The methodology that Bitnodes used to find and determine Bitcoin nodes is inaccurate. The crawler essentially asks the nodes for their version and waits for a response and then subsequently requests for the other peers as well. This doesn't provide an accurate representation of the network as a whole. In fact, there is no way to actually accurately determine the node size. |
|
|
|
This is an address. You don't need to back up addresses, but keys/seeds.
You can actually set your own hdseed through sethdseed. The hdseed that Bitcoin Core accepts is in WIF format so any new addresses will be generated from that. That is however not the recommended way to backup your wallet, backing up the entire wallet file would be far more prudent. Mnemonic is meant for easier memorization and it is fine to memorize it ontop of your physical copies. However, if you run into the issue of possibly losing your wallet file, then you probably didn't ensure enough redundancy. |
|
|
|
|
If you propagate an invalid block, then your node would just be disconnected and added to the ban list of each node. This makes sure that only the malicious block of nodes are segregated from the others but not the honest nodes. This doesn't actually affect the rest of the network as they would just wait to get an honest peer which doesn't propagate invalid blocks.
It is perfectly possible to execute a Sybil attack against the network, and the attack that can happen would be an eclipse attack. However, Core has countermeasures against it as well.
|
|
|
|
|
Satellite used by internet providers like starlink uses radiowaves to transmit information to their users. Starlink's bandwidth is sufficiently fast for Bitcoin nodes to operate so it would be perfectly feasible to run Bitcoin nodes using a constellation of satellite.
It might not be feasible for HAM radios to be used, unless you are talking about transmitting transaction data only (ie. SPV and block headers only). Depending on your setup, your bandwidth might be excessively low for anything like that to be feasible.
|
|
|
|
|
ScriptPubKey does not actually contain the public key. It is just the conditions that can be used to spend the funds, in cases like P2PKH outputs, you will find the HASH160 of the public key and only if you have the P2PK output, then you can see the actual ECDSA public key.
For normal scenarios like P2PKH, P2WPKH, since it dictates the HASH160 (SHA256 and then RIPEMD-160), the conditions to be fulfilled requires for the public key to be revealed. As such, you can validate that the public key hashes to the key in the unlocking script and for the signature to match the public key. With a public key, you can use it to produce the various scripts that requires your public key, and from there you can derive the possible ScriptPubKeys that corresponds to it.
|
|
|
|
Sorry, I lost the nonce / block height. It was in the first half, probably first quarter of 2021. It was an award of 1 bitcoin, which can help separate out which of the mining rewards did this. There was absolutely this sentence within the mining nonce, whatever the cause is.
Hmm, can't find it. The lowest I can find thus far would be 0 back in 2017. Maybe someone else can find it. (Even if untrue, I do wonder what the effect of having previous transactions help lead to future mining nonces would be. This might be a way to balance layer 1 and layer 2 needs, as you don't want layer 1 to be completely abandoned, and there should be benefits for transacting on layer 1, while at the same time miners should benefit for keeping the systems running. Proof of transaction+work is an interesting model.)
As of now, the only reason why you can get a block is if the hash of your block header meets the target. If you want any other conditions to affect it, then there will be a hard fork and the supply would be quite difficult to balance. Layer 1 won't be abandoned, settlement is done on it. |
|
|
|
|
That is untrue. You can choose to fix a specific nonce and change something else in the block header. It is just terribly inefficient in most cases. Miners are entitled to claim up to the current block rewards, which is at 6.25BTC and the transaction fees. Any miners which is building a block can choose to include all of block rewards, part of it or none of the block rewards. This has absolutely nothing to do with nonce or the choice of it.
Let me know the block height, might've missed this before.
|
|
|
|
|
That is not a mistake. Did you sell your Bitcoins with the knowledge that the price of Bitcoin would grow even further after that period of time? If the answer is no, then you didn't commit a mistake. You merely didn't have the hindsight that Bitcoin would grow even further.
Contrary to this, if Bitcoin tanked before you managed to sell, then it also becomes a mistake, for you didn't manage to sell in time. That surge in Bitcoin price wasn't particularly predictable either so I wouldn't call it a mistake.
|
|
|
|
As far as I can tell, if a pool could test your miner by messing with transactions or other block data that would quickly hash to a "winning" nonce then I'm sure the bad miner could be made to notice such manipulated blocks (unless I'm missing something which seems to happen a lot lol). Perhaps by connecting to his own node to verify what the pool is sending him.
You probably won't notice, if your own pool can just send the work template for another miner. Of course, this isn't accurate by any means and would probably not be that ideal given how stratum and the mining software differs. It would be far more likely for the assumptions to be made on the likelihood of a block being found given X shares. |
|
|
|
|
Block withholding attacks has happened before. Eligius had an attacker that was witholding several blocks in the past and was discovered and the account was locked. It worked for awhile but it really doesn't make that much sense to attempt this on a pool. You would probably be subjected to the pool 'testing' your miner by sending parameters that would result in a block and you'll still be incurring costs in the midst of it.
PPS, FPPS and other schemes tends to pay lesser than PPLNS in certain cases so that is also a mitigating factor.
|
|
|
|
Independent audit/open source firmware could reduce the risks. But rogue firmware update (e.g. forcing fixed k value on ECDSA during signing transaction) signed/released by rouge employee is theoretically possible.
The risk exists across all of the platforms/devices and wallets. Your OS could've had the entropy being compromised inadvertently, or your wallet could've wrongly implemented the CSPRNG calls. The only real way to mitigate this is to review the code yourself to ensure that it isn't broken or to check if the signature of the firmware is checked and signed by someone you trust. |
|
|
|
|
Show Posts
