The Qt client does not use deterministic addresses. It pre-generates a pool of keys and uses them, so you don't have to back up after each new address, but you DO need to back up: a) after every 100 operations which use an address from the pool (new address, or transactions that send change to a new address), b) after you encrypt your wallet (the old key pool is flushed).
|
|
|
I thought Shor's algorithm will break elliptic curve encryption once quantum computers are sufficiently large? It just cuts the effective key size in half. The current 160-bit signatures will be brute forced in 2^80 operations. That sounds weak, but it's going to be a long time before quantum computers reach 160-bit levels (if ever), and even when they do the operations per second will be very low and 2^80 will be infeasible for a long time thereafter. The OP was talking about ECDSA, though. There's certainly a chance that a weakness will be found, but there's no expected timeframe for that. It's not a case where increasing computer power will break it in 5-10 years.
|
|
|
most proposals for "expiring" old coins involve sending them to miners Personally I'd like to see them simply destroyed. If coins go up in value a large amount then someone's old 10KBTC wallet they abandoned when it was enough to buy a pizza will suddenly come on the market, along with hundreds of others, whenever the first expiration date comes up. It might also create weird distortions in hashrate. Overall it's bad from a market perspective. Simply destroying them will reestablish the number of coins that are still in circulation; overall I consider that a good thing. It'll have to wait for an alt coin though since it's unlikely to happen in BTC.
|
|
|
There are instructions in the thread linked above.
If you know the passphrase +/- 2 characters it might be recoverable. How much do you know?
|
|
|
It's a matter of supply and demand. You're only considering the supply side.
|
|
|
Perhaps I misunderstand. If the game is based on guessing random elements of a block then it can't be based on already confirmed blocks.
In my scenario the block would be confirmed eventually.
|
|
|
What about using 5 least significant (right) symbols from the block's hash? Is it possible for miners to cheat?
In theory yes depending on how you will use it. The right x digits of the blockhash are random and the only way to produce a block with a different hash would be by brute force (throwing away non-matching ones). Given each thrown away block is worth 50 BTC that is a large barrier for most prizes. If the prize was 1,000,000 BTC you might need to reconsider. The one area where a miner could cheat without it "costing" anything would be to generate entries until they find one which matches a block they already solved and them submit the block. You can avoid this by requiring the entry to be in the "winning block" or prior block (i.e. unconfirmed entries can't win). They can cheat by generating a secret block, playing a move in the game, then broadcasting the block.
|
|
|
Yes, miners can control every field in the block. Your game would be especially vulnerable to a Finney type attack.
|
|
|
This would allow miners to cheat by choosing a timestamp.
|
|
|
If you add the port-forward you'll use more bandwidth since you're relaying to more nodes. It's not a big deal if you have any kind of broadband though.
There are some security implications. It means that the whole world can see you're running a Bitcoin node, which might make you a target for other hacking attempts. If a security hole is announced in the Bitcoin client it might mean that you could be hacked through Bitcoin itself. So far this has never happened, but it's always a possibility.
|
|
|
All Satoshi-client (bitcoin-qt or bitcoind) nodes are full nodes. Even if you only connect out you're still maintaining and distributing the full blockchain and relaying transactions between the hosts you're connecting to.
If you want to accept incoming connections to provide some extra benefit to the network, configure your firewall to forward port 8333 to your PC.
|
|
|
Should be fine but you shouldn't expect a lot in fees.
|
|
|
+1 I think this was a terrible idea. What happens if we send bitcoin to terracoin addy? Lost coins?
No. The intended recipient can export their TC key pair and import it into a BTC wallet.
|
|
|
It's a pointless fork.
So let it die on its own merits. The market will take care of it without your help.
|
|
|
256 bits of entropy is not possible on any budget, but OP was asking about 64 bits.
With an unlimited ($700T) budget it could be cracked in less than a day with a very large number of GPUs or ASICs. The lead time on hardware would be the longest part.
With a much smaller budget ($50M) you could have 10,000 ASICs at 50M/s and crack it in about a year.
|
|
|
Depends - what's your budget?
|
|
|
Rubbing alcohol (isopropyl) should take it right off.
|
|
|
Paper wallets are usually more about secure storage than a convenient form of in-person commerce.
Paper coins can be used for face to face transactions though: You give the merchant a slip of paper with the secret key in a QR code; they immediately import it and "sweep" the coins to their own address while you wait; they then issue your change either as a key on a paper receipt (and you sweep it when you get home) or transfer it to a pubkey you specify. This is reasonably secure method for everyone.
|
|
|
should not trust someone who thinks being dishonest is funny.
And what of someone who thinks being funny is dishonest? It's too obvious to be deceitful. On the other hand posting private PMS publicly is poor form if it's true.
|
|
|
I'm for it. The orphan rate will be jaw-dropping, and if nothing else that will give us great insight into how the protocol behaves when pushed hard. I suspect it'd work.
One per second is perhaps too extreme, but it might have an interesting positive effect: pools would be unnecessary for a very long time since anyone could jump in and reasonably expect to strike coins several times a day even on a Bitcoin-scale network.
|
|
|
|