So for merchants, would they generally keep an account for each person they deal with?
Yes. Then you can transfer coins between users with "move", and Bitcoin can automatically generate new addresses for users when the last one was used. This is how most Bitcoin sites should work: When a user registers, you create a new account for them. Get the address they should pay to with getaccountaddress. Poll getreceivedbyaccount to see when they've paid. Notify them at 0 confirmations, and record the balance in your database at 6 confirmations (or less, depending on the size of the purchase). Thank you, I sent 1BTC to the address in your signature Thanks!  |
|
|
|
|
Accounts are mostly for merchants to manage users more easily. For standard users, they function just like labels.
"From" isn't shown in the UI because it's not reliable. The "from" address could belong to some random MyBitcoin user. (I think it should be shown when you double-click the transaction, along with a warning about never sending money to the address.)
The "from" field works with IP address transfers only, since there is no support for sending messages over the normal network. It works with IP transfers because you send the info directly.
"All transactions" shows generations.
|
|
|
|
Clearly the wallet simply missed this transaction. Yet it picked up a transaction to the same address 8 hours earlier and one two hours later.
He probably just restored his wallet to a version that was a few hours old. - He received the transaction - He restored his wallet - The transaction is not in his wallet any more, but the block is already accepted, so Bitcoin won't notice the transaction again |
|
|
|
If they want to find "free money" like they do in their sofa, perhaps they should. On a related note, one thing that occurs to me is that if the database can take hours to download now, what happens when there are 20 times as many blocks out there and it takes a day. Moreover, if I understand correctly, the database we all share is an accounting of EVERY transaction that ever took place with bitcoins. What happens if bitcoins gain wide acceptance as payment and it takes weeks to download the complete database? Are we hoping for higher internet speeds? Will someone mail out a bitcoin database DVD?
Only generators need to generate all the blocks. The "lightweight" mode for clients just hasn't been implemented yet. |
|
|
|
So the updates coming in do not make sure that my block database perfectly matches what's out there? There should probably be some function within the program to check the integrity of my database against what's out there, or a mechanism for updating all of the blocks without a complete delete and restore of the program. Maybe it could check checksums of the block database instead of having to download the whole database again for several hours. You say this is common, but I see it as a problem. If I don't see my money in my wallet, it's almost as bad as not having it. And people are going to scream someone is stealing money from them with minor errors like this.
0.3.20 has a -rescan switch that will re-check blocks without downloading them again. It only happens after you restore your wallet.dat file. Most people don't do that very often. |
|
|
|
|
Very good talk for just 5 minutes! You covered many of the most important points in an interesting way.
|
|
|
|
|
Bitcoin saw a transaction, but it didn't recognize it as yours at the time. This is common after restoring a wallet backup without deleting your block database.
|
|
|
|
Am I missing something?
You can still have the nonce in the "master header". Each chain doesn't need its own nonce to have its own difficulty. You don't need the full headers/blocks for the chains you don't care about. You only need the full Merkle tree for the multi-chain. It doesn't matter if the person who created the set is using valid hashes or just random numbers, since it's still just as hard to get the Merkle root below the target. |
|
|
|
I think that could be fixed by only allowing replacing a transaction with one where inputs and outputs are a strict superset of the original.
So you could replace [some set of inputs] -> 80 to A, 20 to B with [some set of inputs + some more inputs] -> 80 to A, 20 to B, 9 to X, 1 fee.
Unless I'm missing something, that shouldn't make trusting 0-unconf transactions any more risky than it currently is.
The new outputs might trigger a "dust spam" fee or otherwise make the transaction unacceptable for most miners. Right now the client can detect all of these cases, but in the future it might not know all the various miner rules. It also reduces the functionality of replacement. Transaction locking still couldn't be used for escrow, for example. |
|
|
|
OK, here's a strawman proposal. Knock it down :-)
This proposal is interesting. It does seem to help against many attacks that assume miners can't be blacklisted. Some thoughts: - An attacker could stockpile many valid keys over a long period of time. - It would slow the network in regaining control after an attack of >50% CPU. Big Bitcoin-based businesses might want to put some machines online in such a case, but they wouldn't be able to do so right away without some sort of pooling. - The entire network needs to act in a coordinated way to prevent frequent chain splits. However, some section of the network might not get the double-spend transaction. |
|
|
|
Yes, but this option is ultimately annoying, because i can't have both GUI and daemon running.
Yes, you can. Run Bitcoin with the -server switch. |
|
|
|
If it's right, then what happens when I create a block that doesn't contain a certain transaction (because I didn't receive it)? Does it get lost in time and never is deemed official?
It gets in some later block. The transactions in the block are hashed, though indirectly through the Merkle tree. |
|
|
|
|
Blocks are generated at a certain rate regardless of the number of transactions. Blocks can contain no real transactions.
Broadcasts are basically as you describe, though you actually only announce the hash of the item at first. Then the peer will request it if they don't already have it.
|
|
|
|
I admit this is something i did not think about. Maybe part of the bandwidth can be prevented by only sending the list of tx ids + the block header over the pool-network as proof-of-work, instead of the full blocks. However, this will still be a significant amount of bandwidth (at 80 tx/s), and increase the difficulty of verifying the proof-of-works.
The quoted bandwidth is for 2000 transactions per second. 80 tx/s is for verification of transactions on a CPU core, which will probably become a factor sooner. The pool needs to somehow spread around block verification so that each node doesn't have to receive and verify every block and transaction. |
|
|
|
This seems more reasonable. But...
1. Film studios might never release their products for DVD after the theatre period - what's in it for them?
2. I once saw a film that was pirated by using a hand-held in the cinema. I didn't realise until someone in front of the camera got up and (presumably) went to the toilet.
3. Musicians would have a hard time making money - after their first concert all the music would be copied and distributed. Lower quality yeah, but we're not all audiophiles.
4. How about authors and journalists?
5. Computer games writers?
I don't care about consequences to certain groups. I don't even care if the economy as a whole is less productive without IP (though I bet this would not be the case). I only care that IP is immoral. |
|
|
|
So knowing that most people who use bitcoin are rational, why would anybody report a block that he just mined?
You can't change the block after you've mined it, and the block contains payouts to all pool participants. So your choices are either: report it and get only your share, or don't report it and get nothing. |
|
|
|
|
That's a terrible idea. I always immediately leave a forum if I can't see the content, since I don't create an account until I want to post.
|
|
|
|
I think the scheme can work, but I don't think it could remain popular for too long. One of the main benefits of pooled mining is the ability to mine without verifying transactions or downloading/storing blocks. This will become a huge factor in the future: So this means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 80 transactions/sec. A solved block [for a VISA-size network] will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block. Adding a flood of pool-related bandwidth on top of that doesn't help. |
|
|
|
|
If every person on Earth makes ten addresses per second for 20 years (2x1018 total addresses), then the probability that two of these addresses collide is about 1.57x10-12.
|
|
|
|
|
Show Posts
