I'm looking at the BitCoin white paper which says "He can't check the transaction for himself,but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confim the network has accepted it."
The attack I outlined is the one implied in Section 8. The implied "Simplified Payment Verification" behaviour results in it inferring positive balances if it can see a confirmed transaction.
The whole point of the "Simplified" bit as far as I can tell is that it doesn't bother checking the whole block chain as that's potentially quite a lot of work. THAT's why this attack is possible.
ByteCoin
A) That functionality hasn't been programmed yet and is only speculative (it's called a Merkle hash tree) B) That would be used for some smaller actions like checking balance and such. Verifying the entire block chain (which happens when connecting to a network after a long period of time, or when first downloading the block chain, would still catch inconsistencies AFAIK. C) I took "Simplified Payment Verification Clients" to mean that the client does nothing but verify, (aka, not generating), thus saving huge amounts of CPU. |
|
|
|
|
satoshi: How many other developers do you have working with you?
Martin (another forum member and I) were talking about writing a .Net compatible library for integrating bitcoins into other programs.
|
|
|
|
=P Still, kind of humorous. Also, it occurs to me, Whole Foods seems like the kind of company which would get really excited about the whole concept of Bitcoins. I wonder what they would say if someone approached them about being the first major retailer to support bitcoins?  |
|
|
|
Ooops! Yes! You're quite right if the PGP key is compatible with the key type used in BitCoin. I still associate PGP with RSA and I believe BitCoin uses ECC so I was thinking you'd have to update the software to understand RSA keys.
A production version of BitCoin will probably have to accept a number of different Public Key algorithms.
ByteCoin
Right, I thought we were talking about a private key that was the same type as the client (and assuming the client uses some known standard). Obviously it wouldn't work if you were to provide an unrecognized type. =P However, changing the client to recognize multiple types of PKA's WOULD most likely be a breaking change, unless satoshi is including some kind of version information about what keys were used in the block chain. |
|
|
|
Interim steps like you suggest don't really change anything. What matters is the total number of transactions processed between the time Black Bart spends his coin and the point at which you (unrevokably) transfer something to him in return. (Called "confirmations" in the current UI.)
Not quite accurate. It relies on the number of BLOCKS generated, which is a collection of all transactions made in a rough timespan. So, if only one person out of all bitcoin users transfers money in 10 minutes, or every bitcoin user spends bitcoins like mad for 1000000 transactions in 10 minutes, only one block has elapsed in either case. Then, each block is "buried" under the blocks after it, resulting in more and more security for said transaction. The attacker can buy computer time from a botnet owner which provides access to a large amount of hash generation power or alternatively he has access to many HPC Amazon EC2 instances. The price of the computer processing is the power multiplied by the time.
The attacker also runs modified BitCoin software at a huge number of different IP addresses but because the software just acts like a network node and doesn't do any block generation it doesn't cost much to run.
He perhaps waits until the "difficulty" is lower than average and then generates a transaction which represents a huge transfer of bitcoins from one address to another. The originating address does not have the BitCoins but that doesn't matter. He then fires up his vast computing resources and generates enough sucessive hash blocks by himself to make the transaction go confirmed. He only transmits these hashblocks to merchants running the "Simplified Payment Verification" who only connect to IP addresses that he controls so the rest of the network doesn't even know anything is wrong. He does not forward network traffic which might alert the merchants to the fraud such as contradictory hashblocks. He then buys goods from those merchants using the credit implied by the transfer he's just rendered confirmed. He continues to generate enough hashblocks to render those transactions confirmed. The scammed merchant transfers the goods. The attacker shuts everything down and walks away with the goods.
ByteCoin
The transfer requires the private key of both parties. Thus, it's impossible to "create" faulty transactions. Also, transmitting directly by IP still alerts the rest of the network. You can't initiate ANY transaction without either a) propagating said transaction throughout the entire network of nodes, or b) creating an isolated graph, where you control ALL the nodes, and aren't connected to anyone else. As soon as an outside client connects to your "bad island", he starts downloading your block chain. He can easily verify each step in that block chain, tracing the validity of coin transfers. He can't "transfer" coins out of thin air, nor can he transfer coins away from an unwilling party, as he doesn't have their private key. The merchant in your example, running the "simplified payment verification", would need to download the block chain, and thus would see that it was invalid. |
|
|
|
Heh, my mom works at Whole Foods, and they have a sign that says "We Accept ALL forms of payment."... I wonder how well it'd go over to try paying in bitcoins.  |
|
|
|
This could be done if we change the software and convince everyone to use the new version.
ByteCoin
Not necessarily. The key is used to sign the coins, and right now it's generated by the program. The REST of the program, however, doesn't care where that key comes from. I could write a custom client which accepted keys from the user, even if noone else did this, as it would just look like the program happened to generate that key for me. It would count as a new user, with a balance of 0 (aka, you couldn't "reprogram" your wallet to accept a different key, you'd have to make a new wallet, and send the coins from the old wallet to the new, so that they were signed by your "external" key. |
|
|
|
|
Can you somehow indicate how many times each has been picked?
|
|
|
|
|
Doh. I assumed this was like the previous lottery I saw, and didn't read the whole post. ^.^
|
|
|
|
|
I'd like to buy lot 314, 271, 161, 141, and 020. PM me an address to send the 5 bitcoins to?
(If anyone's curious, those numbers are the first 3 digits of Pi, e, phi, sqrt(2), and i^i, 5 of the most famous transcendental numbers.)
|
|
|
|
No no, we don't take the money from the scammer/honest businessman. We can't. One possibility, though, is to implement a secondary client where specific coins are marked as "dirty money" on a secondary DHT. Anyone running this client would be notified when they've recieved "marked" money. If they know who it is they're dealing with, they know he's the scammer and can report it to the community... or something. ( Disclaimer: Completely freeballing ideas off the top of my head here ) |
|
|
|
|
The system relies on being able to trace the history of a coin to make sure it's not bifurcating in it's history. The anonymity comes in the fact that there's no identity attached to your purchases, not in the fact that you can't correlate purchases together. Theoretically, there's systems in place to help obfuscate such connections between income and purchases, but I believe it'd still be possible to trace the history of coins through "some entity". Likewise, there'd be no way for him to transfer said coins into another wallet without a transaction, which is, effectively, public record.
Think of it as people know that a transaction happened between two addresses, but they don't know who those people are or what the purchase was for. At least, this is my understanding of the system.
|
|
|
|
|
BitDollar, perhaps, when "contracting" the monetary unit (1000 -> 1)? BitCent or BitPenny if expanding it (1 -> 1000)?
|
|
|
|
We wouldn't want to say "1000BTC is now 1 BTC." This would create all sorts of issues. For one, imagine the dismay of those individuals who had not yet converted when they called up their "suddenly wealthy" friends. Rather, we would create a new unit, and convert bitcoins into that unit at some fixed exchange rate. The change I was talking about would be the equivalent of taking everyone's dollars and giving them back cents - an equal number value-wise, just easier to deal with because of eliminating leading 0s
Well, no, it's not changing the backing value of the bitcoin. If 1000 bitcoins is worth 1000 dollars at said point, and there's a public announcement that now, every 1000 bitcoins is equivalent to 1 bitcoin, then each bitcoin would be worth 1000 dollars. The only issue is making sure the message/notification is high-profile enough so that all the major exchanges re-price themselves accordingly. Making a new unit solve the same problem with less confusion, but they're essentially the same thing. As for distinguishing between "old" and "new" bitcoins, the coins are timestamped, so that wouldn't be too difficult. The advantage of the "new unit" system, I guess, is that it eliminates confusion among the users. As for the arbitrary precision data structure: Having thought about it some more, I guess it wouldn't be too difficult, too inefficient, etc. However, to me it seems like an ugly/hacky solution, and just gripes my "sense of the world" a bit. |
|
|
|
|
Hahahaha clever. I'd donate 1 bitcoin, but that would make my balance an uneven number >_>
|
|
|
|
|
Floating point and double precision have precision issues. Which is something that you do NOT want to deal with in money. If you were, for example, to have 1.0000000000000000000000000000000000000000000000000000001 bitcoins in a floating point, the actual stored value would be either 1, or 0.00000000000000000000001 (can't remember which off the top of my head).
Building a data-structure to hold arbitrary precision would be cumbersome and space inefficient. (There'd be a lot of overhead to talk about how big the number is, as well as the data about the number. Similar to how strings/vectors work).
It could be done, and isn't very difficult, but it'd be a breaking change to the protocol, and increase the packet size for ALL transactions, not just very small/very large. (Because you'd still have that overhead for "regular sized" numbers).
Also, I realize my original post didn't address the technical feasibility, but was tangentially related. It wasn't so much a "here's an answer to your question", more so a "Oh, hey, that reminds me..."
|
|
|
|
|
I was thinking about this the other day. IMO, if we ever get to such low levels of transactions for a long period of time, a "split" could occur, whereby we say "Alright, everyone who was operating with .0001 bitcoins, that now acts as 1 bitcoin, and you have another 8 decimal places after that to divide up". It wouldn't change the value of the bitcoin, it's simply a "relabeling" for sanity's sake. Likewise, if the economy improved after that, a relabeling the other way could occur, saying "Alright, 1000 bitcoins is now 1 bitcoin".
Not sure how this would be implemented in a decentralized fashion (some globally agreed upon threshold, I would assume). I haven't put too much thought into it, just an idea I had while walking to work the other day.
|
|
|
|
|
When a transaction occurs, it's broadcast and distributed across the entire network, and everyone is supposed to add it to their block. If the client who made the transaction sees that it isn't in the next solved block, it rebroadcasts the transaction to everyone, so it makes it into the next block. From what I've heard, it's pretty relentless about this: It'll keep trying, forever, until it makes it into the block chain. Until it does, it shows up as 0/unconfirmed under status.
|
|
|
|
|
The network operates on standard DHT node discovery principles. As of yet, there is no TRUE way to COMPLETELY decentralize the node discovery (without getting stupid like scanning entire subnets for someone listening), as you must know at least one person on the network. After you connect to that one person, they notify you of other connections, and you connect to them, etc.
The client comes with a list of "likely candidates" to be online, but there's still the chance that all of them will be offline at some point. The IRC server is provided simply as a backup, last-ditch resort for finding ANYONE to connect to. Try blocking the IRC port to see that it's not strictly necessary.
As for the transaction fee:
Right now, transaction fees are only used in one instance, when dealing with extremely large amounts of bitcoins in a single transaction. Even in that case, it's extremely low (something of a fraction of a percent).
Later on, when bitcoin generation stops "paying off", people will have less of a reason for solving these blocks (and thus transactions will take more and more time to be confirmed, the target value will become easier and easier, making it more likely that an attacker can violate the system.) In order to keep the "block generational powerhouses" in business, a small transaction fee will be introduced, to keep their profit margin ever so slightly above the electricity/cooling costs of solving said blocks.
(At least, this is my understanding from the PDF.)
|
|
|
|
|
Bytecoin: If it was implemented in that fashion, what's to stop people from running a modified client with an advantage over the other? Person A, running a legitimate client, spends half his CPU cycles hashing, and half his CPU cycles solving useful problems. Person B, running the modified client, spends all his CPU cycles hashing, thus doubling his chance of solving the current block.
The verification and proof of work have to be one and the same problem, so that you can't do one (thus getting paid for your verification service), without doing the other (thus ensuring you're not cheating the system).
|
|
|
|
|
Show Posts
