 Show Posts
|
|
Pages: [1]
|
This thread title is misleading.
mtgox itself wasn't hacked. It was just a whale account that was.
It was. Their entire database was posted on the forums (with hashed passwords). The link has been pulled, so I'm not going to post it here, but MtGox was definitely compromised. |
|
|
|
yes. quite possible. easy, in fact.
see the documentation for TrueCrypt - and especially that part relating to 'plausible deniability'.
EDIT: although, for crossing borders, it is simpler and even more secure to email wallet.dat to yourself in encrypted form. or to have an internet wallet with enough (but no more than enough) Bitcoin in it for your trip...
With TrueCrypt, you don't have plausible deniability of "This is not an encrypted file", just "this does not contain more than what I am showing you" using hidden volumes. TrueCrypt files have a header, don't they? |
|
|
|
Wow - Thank you. I'm really new to Bitcoin, it's really excited me. I'll have a good look through that wiki now. The difference with your idea is that the money is more of a deposit, and it is returned to you eventually (if you leave the site or the site leaves). It's also possible to return it if you earn your spot, or whatever. The possibilities are quite endless, that's the beauty of Bitcoin's scripting. |
|
|
|
Question 3: Why are we advised to turn off the bitcoin client before copying wallet.dat?
Because otherwise it's possible that the client is writing to it as you're backing up. You can also backup using the RPC interface if you run it using -server. |
|
|
|
You insert the credit card into the machine, you enter your password and buy whatever you want. The machine contacts your bank with the payment, and the bank provides the machine a wallet.dat with the exact amount to pay (or a number of wallet.dat). The machine has to recognise the bank as a trusted third party, otherwise the bank could have spent some money that has not been confirmed yet.
Why would it provide a wallet.dat? Wouldn't just the transaction suffice? |
|
|
|
This doesn't actually require someone to hold your Bitcoins to confirm. Here's my solution to this problem.
1. A trusted third-party is chosen. This third-party does not have to be trusted by the person paying the snack machine, just by the person who owns the snack machine.
2. At least an hour before the tasty snack purchase, the hungry customer-to-be sends a transaction with an input to the value of the maximum he wants to spend on merchants trusted by the third party. The script requires a signature from both you and the third-party before any outputs can be added, and if it isn't claimed after a certain period (like a month) it's refunded to you.
3. You wait for this transaction to get 6 confirmations.
4. You go to the snack machine and your phone prepares a transaction with the price of the snack sent to the merchant, and the rest sent back to you as change. You sign this transaction and send it to the third-party.
5. The third-party signs it, releases it and gives the snack machine the green light to sell you tasty snacks.
If the third-party is unable or unwilling to sign the transaction, the money is eventually refunded to you.
The point of this is that the third-party will only sign one transaction for that input, and therefore it can't be double-spent, so long as the third-party is trustworthy.
Thoughts?
That's basicly escrow, but it doesn't solve the fast transaction problem because if you knew that you were going to want something from a snack machine in an hour, then you don't really need rapid confirmations anyway. It's not really escrow, because the third-party only checks whether it has signed this transaction already. Anyway, the idea is that many services will use the same third-party. So you'll just need to know whether you'll want something from anything in an hour. You could do this at the start of the day, for example. |
|
|
|
|
This doesn't actually require someone to hold your Bitcoins to confirm. Here's my solution to this problem.
1. A trusted third-party is chosen. This third-party does not have to be trusted by the person paying the snack machine, just by the person who owns the snack machine.
2. At least an hour before the tasty snack purchase, the hungry customer-to-be sends a transaction with an input to the value of the maximum he wants to spend on merchants trusted by the third party. The script requires a signature from both you and the third-party before any outputs can be added, and if it isn't claimed after a certain period (like a month) it's refunded to you.
3. You wait for this transaction to get 6 confirmations.
4. You go to the snack machine and your phone prepares a transaction with the price of the snack sent to the merchant, and the rest sent back to you as change. You sign this transaction and send it to the third-party.
5. The third-party signs it, releases it and gives the snack machine the green light to sell you tasty snacks.
If the third-party is unable or unwilling to sign the transaction, the money is eventually refunded to you.
The point of this is that the third-party will only sign one transaction for that input, and therefore it can't be double-spent, so long as the third-party is trustworthy.
Thoughts?
|
|
|
|
Have a look at the wiki page. Basically, the way it works is, for every coin you reference the output at which it was sent to you as an input. Those have your public key in it. You then sign the transaction using your key. The nodes check whether the two match. |
|
|
|
|
Bitp.it uses slush's pool, and they take their cut. It should be possible to have it work with any pool, though, the mining code is open-source. However, I would only use this if you really have no other option. CPU mining using Javascript is probably the slowest way possible.
|
|
|
|
So there was never an issue to begin with?
Seems crazy that so much can be charged!
Also: Who decides how much is charged? What if you can't even pay the fee?
The miners decide whether they include a transaction in their block based on the fee. By default, miners ask for a 0.01 BTC fee per KB. Additionally, bitcoin isn't meant for micropayments.
It was my understanding that it was, in fact, meant for micropayments, especially since 1 BTC exceeds $10 now. |
|
|
|
|
