|
One thing you might want to do is use the hash to determine the result of a gambling game. You could bet with someone on whether the next hash will be even or odd. The problem is if your opponent is a miner, he could influence a certain percentage of the block hashes, gaining an advantage.
|
|
|
|
|
Got any Google Trends graphs that match this shape?
|
|
|
|
|
The second to last dot on the blue line is the last actual data point, right? I notice that it was farther from the trend line than any other point. Is this a sign that the trend is breaking down?
|
|
|
|
One of the influences on Bitcoin was Nick Szabo's idea of Bit Gold. I kind of wish it had been called Bitgold but that would have caused confusion with Nick's (somewhat different) idea. Maybe we should call block creation "panning".  |
|
|
|
|
You also deleted "deleted" in the title...
|
|
|
|
|
I added a step to the wiki:
# Recheck blockexplorer to make sure the address still shows the right amount, in case the block chain reorganizes
Checking the address balance once, then waiting for more blocks, is not safe by itself as the transaction may go away.
(Just realized my solution is still vulnerable: the transaction could pay you, go away, you wait n blocks, and a different transaction pays you, you recheck the balance and it looks good, but then the 2nd transaction goes away.)
|
|
|
|
|
Trying to review the diff - looks like UpdateSpent() could return fReturn uninitialized if it's false.
|
|
|
|
|
This is good because without it, someone can test whether 2 addresses are in the same wallet, by sending a payment to both of them. Then you can't spend one without the other.
|
|
|
|
|
Steve, the way the client works now, all the wallet keys are read into memory at startup. Subsequent changes are made in memory and written to disk. This proposed patch decrypts keys as they are read into memory at startup, and encrypts new keys as they are written out to disk.
Decrypting keys on use wouldn't be too hard. Add a popup to read the passphrase, perhaps cache it for a while as you suggest.
Strangely, the hard part is encrypting new keys, because Bitcoin creates keys at odd times. The oddest time is when receiving a payment to the "current address" displayed at the top of the window. Bitcoin likes to keep things fresh so it generates a new address to display, and new key. But it can't encrypt the new key without the passphrase, and in general no user is around to respond to a popup at random times.
|
|
|
|
From The Simpsons, "Homer at the Bat": Hypnotist: You are all very good players
Team: We are all very good players.
Hypnotist: You will beat Shelbyville.
Team: We will beat Shelbyville.
Hypnotist: You will give 110 percent.
Team: That's impossible no one can give more than 100 percent. By definition that's the most any one can give. |
|
|
|
|
Look at my sig, Bitcoin address with my name in it courtesy of Gavin's vanity patch.
|
|
|
|
|
Does your ISP also block incoming port 8333?
|
|
|
|
|
I have an even better idea. My transactions compete with those of others for free space in the blocks, so clearly I should forward only my own transactions and block everybody else's. Profit! Off to make a pull request...
|
|
|
|
|
Back in the 90's on the cypherpunks mailing list, Wei Dai (of Crypto++ and b-money fame) invented a system of anonymous lending. Of course the classic problem with anonymous loans is that you don't know whose legs to break if they don't pay it back. Wei solved this problem, with some conditions.
The participants in the protocol are borrowers, lenders, and bystanders (who don't want to lend or borrow right now, but might wish to do so on future runs of the protocol). The key is that all participants are fully identified, to the extent that they are vulnerable to that all-important leg-breaking. Nevertheless, the protocol conceals the role of each participant, and the amount they are borrowing or lending, if any.
There needs to be a system of anonymous payments, and a simple trusted machine called the Pot. (In practice, the Pot would be simulated by the participants, using a cryptographic multi-party computation.)
In a preliminary phase, participants would anonymously negotiate and agree on the amount each person would borrow or lend, such that the total amount borrowed equalled the total amount lent. The actual protocol then has four phases, two for borrowing/lending, and two for repayment.
Phase 1 is private. Each participant anonymously puts money into the Pot, and gets in exchange a signed receipt for the amount. Lenders would put the most money in, bystanders less, and borrowers little or none. You'll see why in a moment.
Phase 2 is public. The Pot now has a certain amount of money in it; this is divided equally and distributed publicly to all participants.
The borrowing/lending is now done. People who put more money in the Pot than the per-person distribution in phase 2 are net lenders; people who put in less are net borrowers; and people who put in the same amount are the bystanders, with no net change. No one knows whether anyone else is a borrower or lender.
When it is time to repay the loan, two more phases are run, the mirror images of the first two.
Phase 3 is public. Each participant publicly and verifiably puts back into the Pot the exact amount taken out in phase 2 (or, that amount plus interest). This is leg-breaking time! No excuses, everybody's got to pay up.
Phase 4 is private. Each participant anonymously presents his receipt from phase 1 to the Pot, and gets back that amount (or, that amount plus interest). This unwinds the earlier transactions and all the funds are back where they started.
All that is visible publicly is that everyone splits up the pot evenly in phase 2, and then returns that same amount in phase 3. But behind the scenes, transfers of value are taking place. And failure to repay a loan means failure to carry out phase 3, which be publicly visible and will lead to serious consequences.
|
|
|
|
|
Why did you put paytxfee=0.00 in your bitcoin.conf? Is it possible you had another value in the past?
|
|
|
|
There's good discussion of this feature here: https://github.com/bitcoin/bitcoin/issues#issue/3https://gist.github.com/803170Issues: - Symmetric (aes) vs public key (rsa) encryption - Decrypt at startup vs decrypt on use - Create new keys automatically (as now) vs create only on user action - Encrypt all keys with same passphrase vs different passphrases for different key sets One way to analyze these is via a threat model. What can the attacker do, that we will try to defend against? And what will we not defend against? We can distinguish three levels of attacker: 1. Can read user files 2. Can read/write user files but only read system files 3. Can read/write everything, root privileges Sorry, getting tired, will write more later.". |
|
|
|
tcatm's bitcoin-js-remote script gives you a "mybitcoin at home" functionality. Run the Bitcoin client and his code on your home machine, open up port 8338 incoming, and you can access your wallet remotely using your mobile browser. It even creates and reads QR-codes for easy phone to phone payments. You don't have to trust any third party service. Really this is such a great concept, I don't know why it isn't better known. |
|
|
|
That's a very concise implementation. I did spot one bug: + vector<unsigned char> Encrypt(vector<unsigned char> vchPlaintext)
+ {
+ // max ciphertext len for a n bytes of plaintext is
+ // n + AES_BLOCK_SIZE - 1 bytes
+ int len = vchPlaintext.size();
+ int c_len = len + AES_BLOCK_SIZE, f_len = 0;
+ vector<unsigned char> vchCiphertext(c_len);
The max ciphertext size is actually len + 2*AES_BLOCK_SIZE, so you should set c_len to that, and allocate that much space. Also a security flaw, you are using a constant IV everywhere, it looks like. You need to use a different IV for each encryption. One other point, Bitcoin uses a CPrivKey type for sensitive data like private keys. It zeroes memory when it's freed. |
|
|
|
|
Show Posts
