Topic: Why not 10 coins per block and a block every 2 minutes? - page 3. (Read 5975 times)

Given constant latency, waste increases EXPONENTIALLY as block generation time decreases until waste is greater than effect. Splitting DOES matter. Forget about the general users. Focus on the MINERS and the problems of latency and splitting will become clear.

Suppose splits represent 0.5% of blocks today and wasted cycles during latency 1%. If you divide the block generation time in half to 5 minutes, waste become 3%. 2:30 minutes 6%, 1:15 minutes 12%, 37.5 seconds 24%, 20 second blocks 50% waste, 10 second blocks 100% wasted cycles. The numbers might be off, but that's the general gist of the problem.

Now does a user care about waste? No not directly. Does he need confirmations? Not in most cases. Does the network care about waste? Absolutely. Does waste make the network less robust and insecure? YES.


Interesting. Thanks for the response. Would you expect miners will at least try to connect to the majority of big miners/pools? I do, because it will cut down on their wasted cycles the faster they hear about new blocks generated and each miner will want the network to begin hashing away at his newly awarded coins/fees. It should be in all miners best interest to connect to each other very tightly.

I'm not concerned about non-miners (in regard to block generation). They will get their confirmations soon enough. As long as users have the ability to inject their transactions in reasonable time, their latency is nearly irrelevant. I would love to receive confirmations within a second, but I value a robust network far more.

Latency can increase due to both an increase in the nodes of the network as well as a concurrent increase in per node bandwidth.  As more transactions are flying around, the load upon the nodes' cpu's also increase as this cannot be performed by GPUs at this point, and must be performed by the CPU.  High loads will result in a buildup of unconfirmed transaction queues, at least occasionally, even on dedicated hardware.  The transactions cannot propogate to the next set of nodes until they are verified, so this compounds the latency.  The same is true with a released block solution, as they cannot propogate until they are verified.  Increasing the number of peer connections would compensate for this effects somewhat by reducing the average number of hops necessary to flood the network, but at the cost of permanently increased bandwidth consumption.  At some point of increase, the cost of adding new peers outweighs the value of lower latency, and then new peer connections will cease.  Some nodes won't even have as many peer connections as the current client expects, as I already intentionally limit the number of peers my own node communicates with.  It's not in my own interest to have more than enough peers to be fairly certain that I'm not being screwed with, since I don't mine.  I'd say that it's a reasonable expectation to expect that average network latency will increase at a rate greater than linear against the growth rate of network nodes.

Either you or I don't understand what 'double-spend' means in Bitcoin.  I think that double-spend means issuing two conflicting transactions which would both spend the same bitcoin.  It doesn't mean both transactions being accepted into the block chain.  Having them both accepted into the block chain would require "51%" (which itself is not even likely to guarantee success; you'd need something more, like maybe 75%, to have a chance of consistently beating everyone else), but you don't need for them both to be accepted into the block chain to successfully execute double-spend fraud.  All you need to execute double-spend fraud is to get someone to believe that a transaction that spends a bitcoin is legitimate while getting someone else to believe that a different transaction that spends the same bitcoin is legitimate.  Now you've 'spent' the same coin twice, although one of those two (or maybe even both, who knows) will in the end never make it into the block chain and the person who accepted that transaction has been duped.

You don't need any hashing power at all to issue such a double-spend fraud; all you need is for the recipient to accept your transaction at face value without waiting for it to be confirmed multiple times in the bitcoin block chain.  And I'm saying that vendors will not accept this risk, so proposals that expect vendors to just accept that transactions will make it into the block chain "eventually" are dead before they even get started.


You expect every merchant to maintain a 500 kbps feed just so that they can accept transactions immediately while at the same time exposing themselves to the risk of double-spend?  Not going to happen, ever.  This problem has NOT been fixed.

Consider also that even if a merchant did bother to maintain a 500 kbps feed and assumed that just because they did, everyone else was doing the same and that transactions in Bitcoin were just about guaranteed to cross their feed nearly immediately.  Now this means that they have to *store* all of those transactions continuously as well, because they never know when someone is going to walk into their store and make a point-of-sale bitcoin purchase for which they'll have to evaluate the transaction to ensure that it's not a double-spend.  And in order to do that, they'll have to have a record of all of the outstanding transactions that aren't in blocks yet to know whether or not there was already a transaction that spent the bitcoin in question.  In other words, they'll have to remember all transactions not in blocks just to be sure that a user can't just send a bitcoin to himself 5 minutes before sending it to the merchant.

The only sane thing that merchants can do is to trust the block chain.  It is a much smaller set of data (one per 10 minutes), much more readily verified, and it already contains all of the work of tracking and filtering out double-spends.  THAT IS WHY IT EXISTS.  If merchants don't use the block chain then they might as well not require any validation at all.

I disagree.  Just because you saw a transaction doesn't mean that it will end up in the block chain.  Miners may never see it; especially in the hypothetical future in which bitcoin is used for point of sale transactions (I am very, very confident that this will never happen), then the number of transactions will be huge and I would not expect them to be very reliable.  Believing that just because you saw a transaction go by means that it will end up in the block chain is just like believing that just because a router saw a UDP packet go by, it will make it to its destination.  I can't imagine any significant retailer being willing to part with real goods based on the promise of a transaction that may or may not end up in the block chain.

Also this whole idea of trying to watch the transaction stream to detect double spend attempts is based on the opposite side of this flawed concept; in this case, that every transaction that will make it into the block chain will be seen by every peer.  If this were true, then in this hypothetical future, every peer would be spending a HUGE amount of bandwidth accepting and forwarding transactions (because there would be at least 100 transactions per second).

I can't imagine why the majority of people in this hypothetical future wouldn't just always send double-spend attempts with every transaction; since the transaction is pseudoanonymous you aren't risking anything.  It would be standard practice to wait until the vendor accepted your transaction (by seeing it on the network, not seeing it in the block chain) and then gave you the product, then you'd immediately send out a spend of the same bitcoin to yourself.  If you are lucky, you win and your second transaction ends up in the block chain first.  If you are unlucky, you lose, and really lose nothing since you just completed the transaction normally.  Even if you only won 1 out of 1000 times, why wouldn't people do this every time just so that every once in a while they got something for free?  And if people are doing this regularly, what vendor is going to accept a nonverified transaction for their goods when they know there is a 0.1% chance (actually higher than 0.1% chance because there is also the chance that the transaction will never make it into the block chain in addition to the chance that an attempted double-spend will succeed) that they will never see the money?

block chain splitting is irreverent AFAIK. this is because only the longest chain will survive. and if you are connected to a decent amount of nodes, then your transaction may very well make it into both chains so it would not matter. and as far as wasting hashing power goes, it does not matter, so what you wasted 30 seconds. that's only 10% of the total time, and nearly everyone else would be in the same boat. and 30 seconds is a large exaggeration. and as said before, we could make little miniature networks, where miners specifically make a point to connect to other miners, in addition to normal not mining nodes. in response to what was said earlier about this, i say that there be multiple lists where miners can submit their ip address.

Another solution to make the network more redundant would to create a new protocol. this would include a new type of node called an exchange node. it tells who to connect to who, to be the most efficient. you obviously would want to make it open source, and only connect to trusted exchange nodes.

here is an image i made of a network with exchange nodes, it does not show much, i mostly made it for fun

MoonShadow are you claiming that latency increases dramatically with more nodes in the network? Rather than requiring more hops, shouldn't all nodes of the network attempt to increase its share of connections? While worst case latency should increase, I would expect best and average case latency to be reduced (or at least scale O(log)) with a larger network size.

Keep in mind, that if the average interval were reduced, then the incidence of a blockchain split increases dramaticly.  In a future with many times the number of nodes in the p2p network, the odds that such a blockchain split could persist beyong one block, and even split again, also increases.  There is some, largely unknown, point of network size (and thus average network latency) with a low enough interval that such network splits become the norm, rather than the exception.  Although this is a self-healing issue, as network splits also split the hashing pool while maintaining the difficulty for both sides; frequent and persistant blockchain splits not only increase the average time between confirmations (from the perspective of any single transaction, not the network as a whole) it also could introduce a double spending 'window of opprotunity' on an often enough basis to make it a viable attack.  Mostly, the 10 minute interval was an arbitarty design decision, with a best guess as to the future size of the network.

Instead of screwing around with bitcoin's framework...  it's easier to just do transfers from ewallet to ewallet and it's instant that way...   

While it is true that faster blocks would require a lower difficulty, the constant latency means that the wasted effort grows with block speed. If you can cut latency 50% across all nodes then you can cut block speed 50% with insignificant loss of efficiency (this excludes memory and bandwidth requirements which will obviously increase).


But a faster confirmation will be more than proportionally less robust. With a doubled block speed competing forked block chain rates will more than double. As an extreme example, if the block speed were a few seconds (about the same as latency), then the network would thrash with the majority of 'confirmation' blocks being invalid. Less than a minute and the miners will spend twice as much energy producing the same number of hashes (with maybe 15% of all 'confirmations' invalid).

Miners could (and probably should) make direct connections to each other. However such a protocol requirement would make the network less robust. Indeed malicious miners would simply isolate the honest nodes.

not quite true, because some merchants only wait for one confirmation to credit you with the money

I did more research, and what i proposed before was actually being worked on by bitcoin labs. with that, the network as we see it now could completely propagate in around 3 hops. thats less than 20 seconds on average.

I asked this same question today.

I haven't had my scribble calculations confirmed, but it seems to me that the weighted average latency between miners is 2.11 seconds. Miners waste 2 seconds hashing away the previous block every time a new block is awarded as well as waste at least an entire block if they happen to be on the loosing end of forked block chain (~0.5% chance every ten min block). The chance of forks is directly related to latency/generation-rate.

The latency is the same no matter the block generation rate. If you double the rate, waste should be halved (and then a little). I estimate that the system is entirely broken with a generation rate less than 5 seconds. If the rate were every minute the waste might be around 15%. Ten minutes puts us in the ballpark of 99% efficiency.

I propose a theory

This theory will explain and confirm a few things

This theory has to do with the nature levels of security and the additional security granted at each level. for example, there is little or no security for a transaction just floating around in the network. however once the transaction makes it into a block, the amount of security granted is the greatest than any other jump. once block 2 as been generated, you don't have much additional security, so is it worth waiting for if you only have a small purchase.

That's the sort of answer I was looking for, thanks.

That is an excellent idea.  Perhaps we could even come up with some sort of relay system for the miners to use to automatically convey this information around so that we don't have to directly manage the connections ourselves.

Solution:
cooperate with other miners and connect directly to each other. then you know as soon as a block comes out. and you would be surprised how fast information propagates in the network. i normaly never wait longer than 5 seconds to see a transaction, but i also have over 60 connections at any given time.

The short answer is that the percentage of wasted computational time increases exponentially as the average block finding time decreases.  This is particularly not good for miners.

The reason computational power is wasted is because a new block is not sent to the entire network instantaneously; it goes out to some nodes, who send it out to more nodes, etc., and eventually hopefully the entire network gets it.  Until the entire network does get it, there are still lots of miners wasting time wasting computations on blocks that will no longer be the longest chain and will thus be invalid.  Ten minutes seems to be a good trade-off between computational waste and speed of getting that first confirmation on a transaction.

Note that expressing the certainty of a transaction is based on computing time, however, not raw number of blocks.  When we currently wait for six blocks before saying a transaction is confirmed, what we really mean is that we're waiting for one hour (on average).  With two minute blocks we'd wait for 30 blocks before saying a transaction is confirmed, because 6 blocks times 2 minutes each is only 12 minutes, which simply isn't long enough to wait (it's not "enough" computing power and would be reversible a lot more easily than a whole hour's worth of computation would be).

Don't forget that 10 minutes is the targeted average between blocks. Because the process is essentially random, you sometimes find less than 1 min between them, and sometimes closer to an hour. With a 10-minute average, the chances of getting two blocks too close together is low, but not impossible.

In addition, hashing power keeps increasing (albeit slowly these days), so even the average is less than 10 minutes.

You cant have blocks generating that fast, it would split the block chain. 10 minutes is the worst case propagation time for data in a distributed network. Every miner needs the last block to mine the next one, so if the time was lets say 30 seconds a block then two miners would find different solutions to the same block and then everyone near those miners would accept the new block and make new blocks based on it, this would mean that the block chain would split very often, leaving the transactions in those blocks lost and reversed. Currently two miners can find a block at the same time, but 10 minutes is enough for the network to chose one instead of making two separate chains.


Really transactions themselves are instant, broadcast through the network, confirmations are only required if your worried about double spending, if you see the transaction in your client, even if you have no confirmations you know that the transaction is valid unless someone has 51%, if you really think someone is going to pull a 51% attack for a sandwich you can wait a few minutes.