Hi can anyone tell me what to do if you use MtGox and Google-Authenticator and your phone packs up or you loose it. Thanks.
If you made a copy of the OTP key at the time you scanned it from Mt. Gox's site, you can add the same key to Google Authenticator (or any OTP app) on another mobile or as a desktop application if needed, using this: - http://code.google.com/p/cuteauthenticator/or - https://github.com/mclamp/JAuthTo keep your backup of the key available online somewhere, you could encrypt it with GPG and store the encrypted version someone where you have access even if your phone is gone. (e.g., if your e-mail also requires OTP authentication and your phone is gone, you aren't getting into that either to get access to your encrypted Mt. Gox OTP key.) If you haven't made a backup of the key, be prepared to provide identification (again) matching the verification info the exchange has on file, know recent account history, ..., e.g., last deposits and trades, etc. |
|
|
|
|
Bitcoin, being a digital currency that can be used anonymously, introduces challenges in numerous ways.
One area where using Bitcoin is a challenge is when there is a dispute regarding a payment. Traditionally, payment records are used to support a customer's claim during a dispute. If that payment was made using a credit card or bank transaction, that information can be verified from those external sources, if necessary. If the payment was made using cash, usually the customer is provided a receipt for the transaction at the time of purchase.
If I pay using bitcoin and my trading partner wishes to defraud me, there are ways to do so. For instance, I cannot prove the address that I sent my payment to was truly an address provided to me by my trading partner.
Another instance is where a counterparty claims to have sent funds to me where there's little I have available to prove that if funds were truly sent, they didn't end up at an address that I had provided.
So if in a dispute if the two parties aren't cooperating with each other, it essentially becomes a he-said she-said as to what actually happened.
This likely is a factor contributing to keeping merchants hesitant to start accepting bitcoins. The last thing a merchant wants is some dishonest person (or a disgruntled customer) claiming the payment was sent and then the merchant has a hard time coming up with a rock-solid defense that the funds were never really sent. The customer can't prove it was and the merchant can't prove it wasn't.
Will all payment requests need to be digitally signed? [Edit: i.e., using GPG or some other signing / certificate method?]
In the example above, if the customer requires the payment request to be digitally signed by the merchant then the blockchain gives evidence that that merchant's payment request was fulfilled. If the merchant provides a payment request only after digitally signing it, then a dishonest customer claiming funds were sent would be harder pressed to explain where the address came from (i.e., can't simply photoshop a screenshot, for instance).
Or does the fact that cash has many of the same problems mean that this isn't different enough to warrant any change in procedure?
|
|
|
|
(1) Physical cables connecting the two computers can make people really unconfortable. I feel really uncomfortable, even knowing that nothing can happen
(2) There are some extra lockdown procedures to execute to make sure that your version of linux doesn't allow logins over the serial connection. I was already aware of this, but it dawned on me that this could actually have a net negative impact if I convince people to use this system and a certain number of them don't set it up properly.
I was just reading about how the security industry doesn't like the "air gap" network concept (apparently) because it gives a false sense of security: - http://colinrobbins.me/2012/07/03/overcoming-air-gap-security-failures/ - https://www.tofinosecurity.com/blog/1-ics-and-scada-security-myth-protection-air-gap - https://www.tofinosecurity.com/blog/scada-security-air-gap-debate-over - http://www.blog.beldensolutions.com/scada-air-gaps-a-philosophy-issue-not-a-technology-issue/One weakness they identify though is that their data on the USB drive can be sensitive and needs to be wiped or destroyed but with Armory transactions that's not a concern. To be fair, their systems are control systems and have a much higher frequency of transfers between the air gapped system and networked systems, where an offline Armory system conceivably would not need any more subsequent transfers after it is operational other than transaction data. I'd rather use USB keys than risk impatient people just hooking up the cable and carrying forward because they don't realize that issue. I see one step in their air gap checklist is one not considered so far here -- and that is to use yet another separate offline or otherwise well-secured system that scans the USB drive (they refer to it as "sheep dip"). |
|
|
|
Maybe a QR code could be an alternative for shuttling the offline transaction that would be more secure than mounting a USB storage device? I now see that something like this has already been considered ... I had considered this idea for Armory's offline wallets (webcams to move data around between offline and online devices). It turns out to be kind complicated and cumbersome, and subject to driver issues because webcams do not always work easily on every OS.
[...]
Webcams + QR codes would theoretically work, but honestly I think it would be a mess. Multiple sequential QR codes, driver issues, designing a real-time-feedback UI for using the camera, resolution issues, wires everywhere,
[Edit: But then re-considered here as well .... Absent a dedicated device/dongle, I am still interested in other ways that might work. The webcam+QR idea is in the right direction, but there's a variety of reasons why it's not good for the general user (I've mentioned it before).
] |
|
|
|
to send Stephen a buck (minimum payment) and it evidently went through. Well, I never knew there was a minimum. - https://getsatisfaction.com/dwolla/topics/using_dwolla_to_sell_digital_goods#reply_8333823And I did get two payments, each of $1. (Stephen , I paid him back for his trouble!). So one of these I should return to you then? If so, PM me your Dwolla a/c number. Once I know that then I'll know which one I can send a return (refund) payment to and which one would now get sent to you. So I guess it is quilt by association. There also could be another factor I just realized, my account with Dwolla is a business account, and I'm verified. |
|
|
|
So you think a block every 4 days is about where it becomes beneficial?
I think it will depend on a number of factors. If I expect difficulty will be going down in the future I'm more inclined to lengthen that duration from 4. If I expect difficulty will go up and go up by a large amount, I might want to make the duration target well under between now and when the next adjustment is to occur. For example, say the difficulty adjustment happens in five days. I can use the calculation from above to learn that with my hashing capacity I have a 50% chance of solving a block in three days, and an 80% chance in five days -- or whatever the results are after calculating the probability. So if I want to use as my target a 70% probability, I then will know that I should continue mining solo for another half day or so, until that 70% is reached. For any probability target, hashing capacity and difficulty level, I should be able to calculate the exact block at which I want to switch over to pool mining. But there are other factors as well. The fees for pool mining weigh in. My cost of electricity weighs in as well. If I have electricity included in my rent, I might be more willing to take the chance with a lower probability target as the risk of not getting a block is lower (simply just lost income). Whereas if I'm barely profitable and I am unlucky, I still have to pay the electric bill out of pocket and didn't get any mining revenue to cover it. So that's a deterrent. So determining the "right point" for going solo is dependent on each individual's risk tolerance and expectations for the direction and degree of the next difficulty adjustment. |
|
|
|
I was just investigating USB auto-run vulnerabilities, and was surprised by the number of attack vectors that Ubuntu has (mainly due to tendency to "auto" do stuff for the convenience of the user, despite exposing attack surface).
A QR code can hold up to 4K of alphanumeric data. - http://stackoverflow.com/a/3964342[Edit: Online Armory --> Offline Armory could be 100Kb+. Thus not a workable plan. Thus was described here: the data you're moving from online to offline is the bulkiest (could be 100kb+, not quite right for QR codes The rest of my argument is invalid.] A USB barcode/QR code scanner acts as a USB keyboard: - http://bitcointalk.org/index.php?topic=105824.0Maybe a QR code could be an alternative for shuttling the offline transaction that would be more secure than mounting a USB storage device?If the online and offline systems are not sitting right next to each other then the QR code would need to be transported over somehow. If that's needed then a $100 Android (or any other) mobile smartphone works for scanning the QR code displayed by Armory on the online system and then the mobile's display will present the QR code to the barcode/QR code scanner connected to the offline Armory:
Or a little $50 thermal printer could print the QR codes for transfer to the scanner for the offline Armory: - http://learn.adafruit.com/mini-thermal-receipt-printerThen the Android mobile could scan the QR of the signed transaction and send it without even needing Armory by sending it as a raw transaction like is available from Blockchain.info/pushtx or the raw transaction feature of BrainWallet.org right?
- http://blockchain.info/pushtx
- http://brainwallet.org/#tx [Edit: Looks like the signed transaction from Armory is its own format, and not compatible with raw transaction ?] |
|
|
|
At what point is it considered more profitable to solo mine, rather than mine at a pool? 1 GH/s? 10GH/s? 100GH/s?
- https://en.bitcoin.it/wiki/Difficulty#How_soon_might_I_expect_to_generate_a_block.3FCurrently difficulty is 2,694,048. From the wiki page: time = difficulty * 2**32 / hashrate Thus hashrate = difficulty * 2**32 / time When the difficulty is going up, you really get penalized if you didn't solve a block before the difficulty goes up. So you might want to target a block every four days, let's say. 4 days = 4 * (24 * 60 * 60) = 345,600 seconds. hashrate = 2,694,048 * 2^32 / 345,600 hashrate = 33,480,463,118 hash/s or 33.5 Ghash/s. |
|
|
|
I haven't found a definitive answer as to whether or not standard YubiKeys use OTP on blockchain.info.
And ... ? |
|
|
|
If anyone can help me out with a bitcoin purchase I would appreciate it. While I'm not interested in a trade, I am curious to know if everyone who ever touched an exchange is guilty by association (i.e., also requires the counterparty to have passed the 30-day probation) or if those without much exchange activity can receive funds from accounts still on probation. You can try sending to me. If it barks about 30 day, then I'ld be surprised because I don't use Dwolla often and for smaller amounts. - https://www.dwolla.com/hub/812-588-3659?amount=0.01 |
|
|
|
Pension fund, hmmm...
So you say it wouldn't be wise to buy $10 worth of btc each month for the next 20-30 years?
An individual investor might consider a penny stock or gold and silver or AAPL shares at $685, whereas a pension fund is probably going to stick to treasuries, bonds, some blue chips maybe and some REITS (or whatever it is that pension funds invest in) -- Bitcoin won't be in their portfolio anytime soon. Here's a very long thread where precious metals (gold / silver) investors are pitted against BTC investors. Ddon't bother reading through it .. just add it to your watchlist if you care to keep on the, ahem, discussion: - http://bitcointalk.org/index.php?topic=68655.3080 |
|
|
|
but isn't there still a problem with newly-generated coins contaminating many of the transactions? If some of the coins in a transaction don't "exist" on the mainline chain (or at least not in the same coinbase from the island), they can't be spent on it. (assuming the island can't make a longer chain than the Internet's chain.)
Yup, good point. This is really an unrealistic hypothetical though. If these desert islanders have computers they have data service. If they don't have computers they'll have some local form of money and one person will do exchange and that person will have data service. Wifi and other data services are becoming ubiquitous. Not necessarily wi-fi everywhere, but everywhere you can find wi-fi nearby somewhere. Here's a related post - a backpacker was talking Bitcoin to chalet owners on islands in Malaysia. - http://bitcointalk.org/index.php?topic=105464.0 |
|
|
|
Yeah well, 25 for 103 is fine considering it's a small amount. If it was a bigger quantity I wouldn't have offered that much at this point.
If you get confirmation that BTC amounts can be transferred account-to-account, then you'll probably find plenty of offers for cents on the dollar. |
|
|
|
Also, on this occasion, transaction limit has been raised to 100 BTC.
Presuming you are able to offer this service because you have those 100 BTC on reserve at Mt. Gox, does that make this service vulnerable to a denial of service attack? I would bet that after you get a few fake anonymous requests made for 100 BTC each that at some point your reserves are gone and you can't offer this service until those requests time out due to no payment sent. |
|
|
|
Is there no time limit for the how long after a transaction is created that it would be rebroadcast?
Correct. Until the transaction is included in a block the client will sporadically (e.g., once every half hour) rebroadcast it. What happens if a transaction is based on another one that has not been rebroadcast? The client would have to have both transactions so it broadcasts them both. |
|
|
|
My reason for asking this is I am developing a product for deployment in the Third World that Bitcoin is a great fit for, but it must be able to function with only intermittent access to the blockchain and support 50-100 users.
Well, just to clarify ... if the users are running nodes and are connected to each other (e.g. on a LAN), then only one node needs to get blocks from the main net, and can peer with the remaining ones locally. The bandwidth to receive the blockchain is about 100 MB per day. Dialup internet provides way more than that even. Mining requires continuous communications. Mining doesn't require much bandwidth, (the same 100 MB per day would be plenty) but the worker continuously needs to be getting new work from the pool as mining is the process of verifying transactions and that batch of transactions can change second-to-second. So if there's no continuous communications then there's no mining. With your scenario of once-a-week connectivity, that would only work if all parties could trust each other that there was no double spending until connectivity is re-established. Thus the nodes on the desert island would be stuck with whatever block was last received. They can use Bitcoin just fine, just that the transactions will stay at 0/unconfirmed until the connection is restored and the transaction is relayed out resulting in blocks that have confirmations for those transactions. Because the blockchain can be transmitted on a thumb drive, you could cut the time down before connectivity is reestablished by having the next motorcycle delivery bring a copy of the blockchain from somewhere that had connectivity. The motorcycle could then also take a copy of the desert island village's blockchain back to where connectivity exists so those transactions will get confirmations in the longer blockchain. Spend transactions could even be sent to the main network via smoke signal if you needed as there's not a whole lot of data. A text message holds 160 characters and a raw Bitcoin transaction is typically under 500 characters. These can be created using BrainWallet.org: - http://brainwallet.org/#txBut overall, bitcoin is an online digital currency and doesn't work for desert islands without at least sporadic (e.g., hourly) occurrances of connectivity. Casascius physical bitcoins (or similar) do, however, work in such an environment. |
|
|
|
The great thing is that the city doesn't have to adopt anything. Bitcoin’s breadth can be widened by parties found in all reaches of the globe without the endorsement, backing, permission or even participation by governments or by the giants of today’s banking and finance centers.
- http://www.bitcoinmoney.com/post/30784275380There is a discussion on this here: Bitcoin in Honduras' new charter cities - http://bitcointalk.org/index.php?topic=53990.0 |
|
|
|
|
Show Posts
