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.
|
|
|
|
"When I see a new block with transactions that I didn't see broadcast previously, mark those transactions as suspicious. If I see double-spends of those transactions, stop building on that block-- assume it is cheating. Switch to the previous block (or alternate block if there's a block race going on)."
There are no incentives for doing that. If 98% of the network "discourages" a block, then those miners have a small chance of losing their blocks to the 2% that does not discourage the block. However, not discouraging a block has no penalty at all. |
|
|
|
Yes, the code that allows for transaction replacement is disabled. Unfortunately the comment there just notes that it's disabled "for now", not why it was disabled in the first place.
I'm guessing it's disabled because it would make accepting 0-confirmation transactions much less safe than it is now. If there was some flag that allowed replacement (maybe nLockTime>0), merchants could ignore such totally unsafe transactions until they get in a block. |
|
|
|
|
The trailer is horribly-constructed. I almost laughed at how they set all that "boring dialogue" to action music. The film does look somewhat interesting, though, if slow-paced. I've never read the book, so I can't compare.
|
|
|
|
|
I've read on this forum that you do keep the old address, though I don't have a MyBitcoin account, so I can't be sure.
|
|
|
|
I can see an inconsistency. I argue that creative brains are *way* more scarse than whatever real property you're talking about - particularly ink & paper, electronics etc. I mean, what's to stop me making a contract "I'll tell you about the products of my creativity, but you must use them only in these ways", and then enforcing that agreement through whatever means at my disposal. Thence, Intellectual Property.
Brains are scarce, but a single idea is not: it can be reproduced infinitely. An IP-like contract would be perfectly alright. However, if someone breaks this contract, then those who are receiving the item without agreeing to the contract are free to spread the idea. For example, movie studios would probably still have a theater-only release period. If a "screener" is released, though, then only the person who leaked the video is in violation of a contract. |
|
|
|
It is the downloading part which takes some time. Not the verification.
It is therefore a matter of bandwith, not computing power.
Downloading and verification are actually quite fast. It's creating the index file that's slow. |
|
|
|
|
I agree. A reference CPU miner should be part of the project, though.
|
|
|
|
Aren't payments to self not supposed to have credit/debit numbers? It could be a bug. See if it ends up being rebroadcast successfully. Payment to self -- credits/debits are indistinguishable, so the "net amount" appears to be zero:  |
|
|
|
If I make a copy of my wallet what prevents me from useing both copies? for example if I have 2bct and make a copy then load it onto another computer what happens?
You won't be able to spend the coins twice. The network will prevent it. However, Bitcoin is not meant to be run like this, and you might lose coins by accidentally making invalid transactions. |
|
|
|
|
You need >50% of the computational power to get 6 confirmations. For 1 confirmation, 1% of CPU power will give you about a 1% chance of being able to reverse the transaction, regardless of how well the original transaction propagated.
If the attacker can't do that, then broadcasting and waiting a few seconds does give a good chance that there will be no double-spending. However, nodes will not relay transactions they consider bad, so you might not see bad transactions until they're in a block. This is why a centralized "super node" with many connections is desired. And Bitcoin doesn't currently warn you about double-spends, anyway.
|
|
|
|
|
This has been discussed over and over again. The entire economy can function on 1 bitcoin. Deflation is not a problem.
|
|
|
|
Well, the point of all this is to ensure all chains benefit from the same pool of cpu power. So they'd need to have related difficulty in some sense.
They do share CPU power. You only have to increment/hash once to try for a whole set of chains. If the Merkle root is below one of the targets, then you claim just that one (leaving the invalid branches so the root stays the same, but not announcing them as solutions). If the Merkle root happens to be below all of the targets, then you can claim all of them. What's the advantage of that, compared to declaring that the "new" block chain will start with the same difficulty as bitcoin (and will automatically stay in step after that)?
Not everyone will work on every chain. To maintain 10-minute (or whatever) targets, separate difficulty is necessary. |
|
|
|
First block makes more sense. USD is a measuring stick made of wormwood.
I agree. January 3 rd should be Bitcoin Day. |
|
|
|
|
That does sound like what Satoshi was thinking of. He specified that each chain would have separate difficulty, which I suppose could be achieved by leaving invalid headers in the tree when the Merkle root is below the target for any of the chains.
|
|
|
|
How do I issue the RPC from command line?
Just "bitcoind setgenerate true threadNumber". Bitcoin acts as its own RPC client when it's given any parameters that don't start with a dash. |
|
|
|
|
As far as I know, no one ever figured out exactly what Satoshi meant in that post.
|
|
|
|
|
You can't currently run as a full network node without full blocks, since there's no way to represent on the network that you're sending just a partial block. Would the vectors currently used for Merkle trees even work if part of the tree was removed?
I haven't seen any relevant code. I don't think transaction trimming is intended for use in the near future.
|
|
|
|
|
Show Posts
