Easy to say, but how would you define that wager?  You can't identify how many use it now, you would have to make guesses.  How many users do you think there are?

That's true, but garbage posts that can usually tell us if you are a bot or not. 

They still represent an average difficulty to find one, which is why they are used as a standard unit in the probability calculations to start with.  Just because someone could get lucky and find a block on the first try doesn't mean that the odds of an attacker have improved, nor does it mean that the block represents just what work one node preforms to create the block.  It represents the, often unknown, average amount of work that the whole honest network must perform to produce a block.  The point that the percentages of hashing power still apply regardless of the block interval is true, for if an attacker can produce 51% of the hashing power of the network it doesn't matter what the target interval actually is.

It likely doesn't change the risks of a Finney attack in any meaningful way, either good or bad.  Such an attack requires 1) a large minority percentage of the hashing power 2) excellent timing and 3) luck.  It's also very easy for the party that has been defrauded to know what happened, even if the transaction is a fairly anonymous in-person transaction.  It's extremely unlikely that such an attack would even be attempted for anything except a highly portable and high value item, and there are not many that fit that bill that an anonymous buyer can just walk into a store and buy with cash and walk out.  Certainly not without  being on video.  There is literally no single item in a Wal-Mart store that would qualify.  Maybe a gold coin dealer, but those guys don't even assume that the cash is genuine.  I know of no case of anything that you could buy for cash and carry that would remotely justify the resources required to even attempt such an attack.  Although a finney attack can theoretically reduce the percentage of network hashing power to perform a double spend to less than a majority, the risks of such an attack are IMHO remote.  Anyone selling such a high value item is just going to insist upon confirmations, and you will get used to the idea.  We wait a half hour or more to buy a new car while they check our credit, why would it be different with bitcoin?

The topic of workable instant POS solutions for bitcoin have been worked to death on this forum.  I've participated in many of those threads.  Is the search function, I'm not the one obligated to make the case that anything needs to change, nor that I'm wrong about the security model.  The math presented in this thread is incomplete, IMHO.  All a block is in this regard is a unit of measurable proof-of-work performed.  Just because such proof-of-work can be conveiently modeled around the unit, doesn't mean that the unit doesn't still represent the work that is done to create a block; and the work done is a continuous stream of proof-of-work.

As far as a POS system, there are a number of workable models that have been proposed by myself and others.  The most likely future solution, IMHO, is a side-channel network that allows bitcoin 'banks' such as more sophisticated online wallet services to securely communicate with each other in real time, verifying to each other that the client does have such a balance with much the same result as how an electronic check is processed today.  No, this would not be terriblely anonymous; but still more so than using a credit card for purchases today.  The vast majority of people don't need anoninimty in every little daily transaction anyway.

That's not at all what I said.  And no, simply switching the target interval from 10 to 2 does not mean that the confirmations are as secure after any particular number of blocks.  At two minutes, 30 confirmations are roughly as secure as 6 are now.  The confirmations themselves are not magic, they only represent an amount of time passed since your transaction was recorded.  It's the time(multiplied by the difficulty) that creates the security.


Maybe, maybe not.  The interval is still arbitrary and the logic for 10 minutes remains as sound as it would be for 2 minutes.  IT would certainly be much longer for edge of network solo miners.  Keep in mind, at a Visa level of transaction processing, each block would be around 10 gigs.  At 2 minutes, each block would still be around 2 gigs, but the multi-connection thing multiplies the burden  upon the nodes.


It's not a myth.

Which is fine, such institutions don't actually produce anything.  They will continue to exist to whatever extent the market requires them, which would likely be a fraction of the current need.

Yup, that's the point.  And nor is the newbie section unwatched.  If you have an unanswered question, ask it.

The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be.  But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block.  The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is.  No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block.  The choice of a 10 minute target interval is certainly arbitrary, but a 2 minute target is no less arbitrary; and the rational for choosing 10 minutes is sound.  Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network.  The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.

Even theft of real property isn't always aggression, it's theft.  A 'cat burgler' is a sneek thief, but does not threaten anyone in doing so.  Copying of copyrighted data isn't theft, it's copyright infringement.  Theft is taking something that belongs to another, and thus denying them the ability to utilize their own property.  Copying of copyrighted data does not prevent the copyright holder from utilizing the data in exactly the manner originally intended.

Yes.

Yes.  My Voip provider is very proud about being entirely a debt free corporation.

The last thing that we want to happen is the bankers gain access to the legalized force of the state even more directly than is presently so.

We've had this discussion, and several like it, many times on this forum over the past two years.  I can assure you, the answer is no the target interval will not be changed.  For all the reasons already presented to you and others as well.

This would only work once, because it would be evident that such an event has occurred after the fact.  It would be fraud, and easily provable, and thus carries the same legal risks; and would immediately crash your "credit" with those affected vendors.  If this happens enough, those vendors will not accept bitcoin so easily without identifying information; but anonimity was never a certainty.  I have no anonimity with any of the vendors that I have traded with, it's just that no one else outside of the transaction has that data like is necessary with Paypal or Visa transactions.  Said another way, the transaction isn't tied to my identity in records except those that the vendor may keep.  Don't count on being anonymous to your vendors.

I think you might be thinking of the supernode being spoofed in Solidcoin, which was a different event.  Bitcoin doesn't use supernodes for this exact reason.

If such a method exists, sure.  But once that method is known, there will be countermeasures.  The double-spend attack is defensible, even with zero confirms, if the vendor has good connectivity.


That's not true, it's just that the current client doesn't presently offer sidechannel checks.  For example, a vendor's client could accept a zero confirm transaction at face value with very little risk by doing the following...

1) check that the transactions presently have the funds according to the client's own copy of the blockchain (presently done)
2) send the transaction out to all of it's peers except one, and wait until it returns to itself via the final peer.  (not presently done)  

If the saved peer returns the transaction, or no double spends are discovered from this peer in ten seconds, then assume that the transaction is valid and give the guy his Big Mac.  If there is a double spend attack underway, then either the saved peer will return the transaction that your client sent, or another one.  If it sends another one, deny the purchause.  If it sends back your transaction, it doesn't likely matter that there could be another transaction out there, because your's dominates the network.  The finney attack alters the picture somewhat, but unless you're trying to sell a new car via a drive up window, the values justify the (small) risks of accepting that transaction.  If you are selling stuff online, you can accept the transaction tenatively; and cancel the shipment of goods if the transaction fails.  If you are selling something digital in nature, such as an mp3, simply use delayed redirection for the download to allow the above ten second checks to occur.

There are numerous reasons for not reducing the target interval, both present and future.  No network would be able to handle the propagation delays with a target of two minutes and a transaction volume anywhere near what Paypal processes on average.  There have been numerous threads in the past about how to process real time bitcoin transactions via channels external to the bitcoin network, as well as simply gauge the risks of accepting an unconfirmed transaction at face value for lower value transactions.

In short, no.

This might be a good time to bring up Bitcoin as an alternative payment method for Steam.  I've brought it up before, but they just ask me to put it up on their forum to gauge interest, and I don't have a forum account at all.  I play games, but I don't talk there.

He did, but forgot to mention that the QR code must also include the bitcoin address for the change.  If a private key, a bitcoin address, and perhaps a small checksum of the first two, can be included on a qr code that fits onto a cell phone screen, this is a doable solution.

Dash7 would still be better, though.