1) Being peer to peer based, doesn't the network becomes very vulnerable to impersonation attacks? when clients start up, then have to log to 'trackers' to get the list of other clients, but one only need to replace/hack the tracker(s), and successfully redirecting all new clients to a fake list of clients where all kinds of new transactions took place, since the last time they were logged in, and cause massive amount of damage?
This is the most feasible attack against the network, in my opinion. It's not trivial, though: all of your peers need to be evil, and Bitcoin requires that your first eight peers be on different /16 networks. Couldn't the same kind of technique used by hackers for DoS could be used in the bitcoin network to 'take over' the official bitcoin network (become the majority), so when a new client connects, it sees the massive rogue bitcoin network as the valid one, and rejects the legitimate bitcoin network as the one being inconsistent? Only if the attacker can come up with more CPU power than the real network... If / when corruption, massive attacks , etc... happens (this is a computer network we're talking about here, so we'd be delusional that it would always keep its integrity), how could the network be reset to a previous 'valid' state before the attack? The block checkpoint would be moved up, causing you to reject all chains except the real one. finally: How can one re-appropriate bitcoins that was fraudulently acquired? Say, someone sells for millions of $ worth of bitcoins through fake ebay auctions, and get convicted by a judge of that action. How can the victims be compensated if the thief simply refused to give his private key (or has destroyed it)? With real money, his bank account is simply frozen/ confiscated. You can't. Allowing governments/criminals to steal money from people is not the goal of Bitcoin. |
|
|
|
There is no PGP signature, no chain of trust, so a hacker could easily replace the binaries and hashes.
Satoshi has published a public key for a long time -- I don't know why he doesn't sign the hashes... |
|
|
|
As others have mentioned, this would be pretty easy to follow in the block chain. It's not much better than creating a new address and sending some bitcoins to yourself. I outlined a somewhat easy-to-implement method for totally secure mixing on the wiki's anonymity page: *Set up two Bitcoin installations.
*Put some amount of BTC in installation B. This is the maximum amount of BTC you can deal with at once (for all customers).
*Customers send BTC to installation A. You send them an equal number of coins (or minus a fee) from installation B. Send as 10-50 BTC increments.
*Send all coins from A to B when all orders are satisfied. You can't send coins from A to B if you have any orders that have not been satisfied from B.
*This can be automated, or you can do everything manually. |
|
|
|
However, in theory, if the majority of the users agree on the fact that bitcoins should keep being created without a limit it wouldn't be a problem (except for the part where you convince lots of people to accept a diminution of their assets value  ) It's important to note that a majority can't force the minority to accept new rules. If most of the network wants to eliminate the 21 million limit, they will split into a separate network and the original Bitcoin network will still continue to operate under the old rules (probably devalued, but still working). |
|
|
|
|
You said that the project is supported by "world-renowned cryptographers", but I doubt anyone here is actually a cryptographer (or "world-renowned" in anything). Even Satoshi has not made any new crypto -- he just used existing tools in innovative ways.
Also, Satoshi has probably never been to Japan, and he is not known for anything except Bitcoin as far as anyone can tell.
It was an OK overview, though. The interviewer was really good -- he added a lot. It's probably as good as could have been hoped for the first-ever interview about Bitcoin.
|
|
|
|
So i just noticed this thread (and your pm) as I have not been on the forums for a while. I am not the guy you are looking for I am afraid, though that is my flickr account and I am a technical guy. The 20btcs you are talking about came from http://bitcointalk.org/index.php?topic=588.0 . Hiroe is the one who sent them to me, I do not know Hiroe outside of that single transaction. Hope that helps in someway. Interesting. We move closer to finding the scammer! Who sent Hiroe 400 coins at 14PG5GCfmGfr2wWLLS9V9B2YeeqiwzNyxj? Whoever that is received coins directly from the scammer. 13PR (scammer) -> 1C3N -> 14PG (Hiroe) -> 1HKY (omegadraconis) |
|
|
|
|
That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.
It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.
|
|
|
|
x-btc was designed with QR codes in mind. In particular, it has concise syntax to keep code size small, and to avoid reaching the QR code maximum size (~4000 characters). Equivalents of your first two examples: x-btc:addr=1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3;store x-btc:addr=1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3?My%20Bitcoin%20Inc.;value=300;send Sending to a merchant API service would be better done through the standard Bitcoin IP interface, I think, with the merchant ID and other info as a message. (Authentication extensions would be necessary, of course.) QR codes already have checksum data, so it seems wasteful to include entire addresses (which also have check codes). It would be better to convert the address to a hash160 and include that, encoded in base64. It can be losslessly converted back to an address at the receiving end. 1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3 becomes 02ikqmJrjm4wJIqMf42kYPiwxks
|
|
|
|
My question is in a couple parts: Is this in the roadmap for getting implemented in the future or is this simply an idea that hasn't really been completely thought through? What kind of security issues are there in terms of a 3rd party "changing" the transaction information and simply updating to a new transaction version? Or is this a "no later than" type of notification where the transaction expires after a certain block number has been created?
It is an interesting feature to Bitcoins if it could be pulled off. Apparently most miners are not paying attention to this attribute as well, and it may be something to reconsider.
A transaction can't be included in a block if its lock time is in the future. Even now blocks breaking this rule will be rejected. The feature is designed to work with in-memory transaction replacement, which is currently disabled (it was enabled in older versions): // Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (!IsNewerThan(*ptxOld))
return false;
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)
return false;
}
break; IsNewerThan() checks that the input's sequence number is lower than the other version. Lower sequence=newer. This disabled feature is not network-enforced in any way, so it could be enabled at any time. You can't replace a transaction unless you can sign it. So it should be safe. It might be unsafe if you're using inputs that can be redeemed by more than one person: the other person could make your transaction invalid (but not steal your other inputs). It was probably disabled because it makes accepting transactions with 0 confirmations really unsafe. It could be safely re-enabled if transactions were only replaceable if they actually specify a non-zero lock time, and this was marked in the UI. nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.
|
|
|
|
So, the only new data you would need to gather is the block generation dates... don't the block themselves have timestamps?
Yes. Here are the timestamps if you want to try that: http://www.mediafire.com/?bqamkafj1lvqkbl |
|
|
|
|
It's pretty easy to do. Bitcoin already contains an alternate network with a different genesis block and different network parameters (the minimum difficulty is lower to make generating easier).
Competing with Bitcoin will be almost impossible, however. You'd have to offer something really good.
|
|
|
|
Will there be a default fee amount included in future clients, or will be have to guess/check what the average miner is charging to process transactions?
Bitcoin will look at network conditions and make a guess for you. |
|
|
|
|
It's possible, but not yet implemented.
|
|
|
|
When a block is rejected obviously the "mining" transaction for that block is also rejected (as you suggest here), so there is at least some loss, plus there is entropy in the system where from time to time (as people turn on and off clients) that over time transactions will be dropped.
Pre-0.3.9 clients are still trying to include the overflow transaction. Generation transactions can't be spent for 100 blocks, so a split would have to last longer than that for any problems to occur there. The chance of a transaction being accidentally reversed after 1 confirmation is nearly 0. It requires a real attack. |
|
|
|
Current copyright law allows for personal fair use, where you can use use your computer any way you see fit as long as what you do is for yourself. Reverse engineering, for example, is explicitly indemnified and mentioned in copyright code as legal... contrary to what some EULAs would have you think. What it doesn't permit is for you to take the hard work of others and give it to 3rd parties without permission.
That still allows you to control the property of people who have not dealt with you. Contracts can enforce non-distribution of works (and even prevent reverse engineering), but if someone breaks this contract, later users of the "leaked" work can't be held to the contract terms. If I have not agreed to give up some of my property rights with a contract, then under no circumstances can you control my use of my property. |
|
|
|
|
That's one of the Faucet's change addresses (probably -- I haven't traced it to the start). It's sending 0.05 to a Faucet visitor and the rest to a new change address owned by the Faucet.
|
|
|
|
|
Bottom line: intellectual property of any kind infringes on my real property rights. Your copyright prevents me from using my computer in the way that I choose, and is therefore immoral.
|
|
|
|
|
It's just the number of blocks that were generated by the network after the transaction. It goes up without limit.
|
|
|
|
What is the actual consequence of me moving that file? Or what is stored in that file?
It contains journaling information for the block database files (blkindex.dat and blk*.dat). It's possible that deleting that could damage the block database. I recommend deleting the other block database files, too. |
|
|
|
|
Try deleting your blkindex.dat and blk*.dat files.
|
|
|
|
|
Show Posts
