|
Electrum works differently than bitcoin-qt. It doesn't randomly generates new addresses like B-QT but produces them off the seed in a deterministic way (but yet unpredictable for someone who doesn't have the seed). The seed is all you need to recover your addresses. If you are uncomfortable using this mac, install electrum on a different computer and restore from the seed.
Once again, as long as you know the seed you haven't lost anything. All is good.
|
|
|
|
I was talking about the main mining pool. I meant centralized - not mature. You are free to disagree though.
As I understand it, there are centralized mining farms, but not centralized mining pools. Miners on pools are free to jump to other pools. Mining farms don't mine on pools, but compete with them instead. Miners don't generally allow a pool to get too large. I realize that pools can conspire. As cypherdoc is fond of saying, it's not a fault with the Bitcoin protocol, it's a human choice. True, but still looks pretty centralized to me. https://blockchain.info/pools. If a merchant connects to the top 5 pools, he has access to more than 51% of the total hashrate. I'm not criticizing the network, it's working as intended. I'm saying that it wouldn't take much for a merchant to accept 0-confirmation transactions while getting reasonable security. |
|
|
|
|
I was talking about the main mining pool. I meant centralized - not mature. You are free to disagree though.
|
|
|
|
|
The network is more centralized than we think it is. Once the first transaction reaches the main mining pools, it's practically impossible to do a double-spend. A merchant could maintain a direct connection to them and make sure that it was propagated there before handling the goods. It would only take a few seconds of waiting.
|
|
|
|
Where do you get the 99% figure? In my experience, every merchant waits for at least a confirmation. Bitpay min is 1, max 6. Exchanges: 6. Poker sites: 4, etc.
If I remember correctly (from my last BitPay transaction), doesn't BitPay send you (the buyer) a confirmation as soon as you have sent the payment? They don't wait for a full block confirmation to send you your email receipt. The merchant gets the full payment after it has been fully confirmed in a block. But this is another good comparison to what is happening with credit cards and merchants who accept fiat/credit. The details of the protocol are irrelevant to the end user.
Exactly. Which is why (eventually) when enough Bitcoin user applications have been built to make the use of bitcoin super user friendly, easy and seamless, you won't even need to know what a "block confirmation time" is, nor worry about it. It will be so buried beneath the surface of the whole transaction procedure that it won't matter. A comparison would be like you and I fully understanding how a cell phone works right now. We don't need to know. We just need to know how to use a phone and have a use to find it useful. 99.9% of the population is never going to understand the technology and mechanics of bitcoin. They are just going to use it (once the applications and use are easy enough). We are definitely the geeks in the space and will remain so. I think you misunderstood what I meant. You're saying that block confirmation times shouldn't be considered and instead we should look at the time it takes to relay a transaction. It's all good if merchants were actually accepting 0-confirmation transactions. For the most part, they aren't. Maybe they are too uncomfortable with the risk of double-spend, the bottom line is that as a user I have to wait for several confirmations. To follow your metaphor, today most merchants require wire transfers. Until they change their policy, we can't ignore the block confirmation times. There could be an opportunity for a service that covers the risk of a double spend and acts as insurance. I heard that Coinbase (no affiliation or recommendation implied) is basically doing that. |
|
|
|
|
Where do you get the 99% figure? In my experience, every merchant waits for at least a confirmation. Bitpay min is 1, max 6. Exchanges: 6. Poker sites: 4, etc.
The details of the protocol are irrelevant to the end user.
|
|
|
|
|
It's not safe to do this, you'd better use EC IES. First of all, there is no reason to use your private key. Secondly, AES CBC is not authenticated encryption and subject to chosen ciphertext attacks.
|
|
|
|
|
Once you reveal your method for producing the pass phrase we can see that many fall short of the recommended entropy level. It's not saying your coins are unsafe because
1. The entropy is high enough for the moment
2. We don't know which addresses are yours
However a good method should not rely on hiding anything but the secret.
If you truly choose random 7 words from a good English dictionary you get 128 bit of entropy. It's all in the 'random' part
|
|
|
|
But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.
Tampered firmware can just feed you a copy of the correct firmware.  (sane oil certification even gets the clueful folks, I guess). No no, I know they could have used a shadow rom but I think you have to trust them eventually if you want to use it. At this point, you can compile from source, check that the hash is the same as the signed package and then flash the later. I have some experience with embedded devices so I have some ideas on how to circumvent this but it's as good as it gets IMO. (Besides, the easiest is to avoid reusing any address) (I don't use any hardware wallet) |
|
|
|
|
You can use anything for a brainwallet. It obviously includes seed words or a long hex string. In theory, a brainwallet has as much security as a random number generator. So why even argue that it's not the case?
@CIYAM, your experiment proves that you are capable of having a good brainwallet. Great - you have good memory and the skills to pick a high security sentence. Unfortunately, that is not the case for most of the other people and that's for them that the recommendation is.
I don't recommend jumping from buildings but if you are an expert at Parkour it's easy as walking.
@Danny, I have no idea why you want to prove than any brainwallet is bad. It's easy to prove that they have the same security if used properly.
I have crappy memory so I don't use a brainwallet. Besides, there are much easier way to keep your money secure. So what's the point?
|
|
|
|
Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization. While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.
Is there any hardware wallet that supports multisig? AFAIK Trezor doesn't yet. I was only concerned about subliminial channels because of the need to trust the wallet software. But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them. |
|
|
|
|
If you did that, anyone can compute k and the secret key.
|
|
|
|
Did you try vSeeds.push_back(CDNSSeedData("alexykot.me", "testnet-seed.alexykot.me"));
vSeeds.push_back(CDNSSeedData("bitcoin.petertodd.org", "testnet-seed.bitcoin.petertodd.org"));
vSeeds.push_back(CDNSSeedData("bluematt.me", "testnet-seed.bluematt.me"));
vSeeds.push_back(CDNSSeedData("bitcoin.schildbach.de", "testnet-seed.bitcoin.schildbach.de"));
bluematt used to work for me. |
|
|
|
|
These quantum signature schemes don't help solving the problem. A malicious implementation can reuse the same branch multiple times and effectively reveal your secret key.
|
|
|
|
If not ECDSA then what (RSA)?
DSA has the same problem. I don't know what would work well. Subliminal free signatures introduce other issues or are impractical IMO. But smart people are working hard in this field... |
|
|
|
Huh ... many wallets already have this RFC implemented: nbitcoin, bitcoinj, libbitcoin, bitcoinjs. The notable exception is bitcoin core but it's just a matter of time. It's in the dev branch and the next release will have it. ( https://github.com/bitcoin/bitcoin/pull/5227) Unfortunately, you cannot check if it was used because you would need to know the private key. IMHO, we shouldn't use ECDSA at all but I may be missing the big picture. Anyway, until then - no hardware wallets for me. I can't check that the software installed isn't doing anything harmful. |
|
|
|
|
To cover all cases, you need to scan both inputs and outputs for your address. Tally the amount on each side. You receive money if the total outputs > the total inputs.
Remember that you can be spending more than one prev output and could be receiving into several outputs.
|
|
|
|
|
To Op, I was replying to your first message.
It's true. Air gap wallets can leak your keys by the way they sign. They can hide a message while forming a valid signature. When you spend some funds, a crafty signature can leak your master key and it can be done in a undetectable way.
A malicious attacker can later get all your funds. It's very powerful with deterministic wallets because even your future funds can be stolen.
|
|
|
|
|
A modified signing code can leak all your data onto the blockchain - airgap wallet or not. I can do it in 2 signatures but it could be lower. So check that your download hasn't been tampered with.
|
|
|
|
|
Show Posts
